Re: lcc-win32

From: jacob navia (jacob_at_jacob.remcomp.fr)
Date: 10/11/04 

Date: Mon, 11 Oct 2004 19:36:13 +0200

Flash Gordon wrote:
> On Mon, 11 Oct 2004 17:59:14 +0200
> jacob navia <jacob@jacob.remcomp.fr> wrote:
>
>
>>Thanks for your remark.
>>
>>Aside from polemic, the objective in this discussion is to determine
>>if C allows the programmer the use of simple data structures like
>>lists, hash tables, etc.
>
>
> So why did you start talking about operator overloading?
>

Operator overloading is just syntatic sugar.
For hash tables, for instance, or for lists, the normal call
syntax is perfectly OK.

Syntatic sugar is needed when you want to access data structures
like a length prefixed string using the normal syntax
String a;
...
a[2] = 'b';
instead of
setStringChar(a,2,'b');
what is more cumbersome.

Since the first message in this thread (admitted, polemic)
I wanted to take a critical look at remarks like "I never use any
data structures", and such, implying that C (or programming) can
be done without using containers like hash tables, lists,
queues, etc.

>
>>I stress the need of a common library, accepted as widely as the
>>string library, that would fill this gap, i.e. making a library where
>>a common interface to hash tables, to lists, to automatically growing
>>tables (vectors), etc is defined in the language.
>>
>>I admit that this is quite new to C, but I do not see this as a big
>>deal.
>
>
> As has been stated repeatedly, discussing the implementations of such
> things in standard C is fine here.

OK. That is what I wanted. I think that the language is making too
difficult to do that. Each time I need a list, I have to rewrite
a new set of:
DATA_LIST *AddToList(DATA *item);
FindInList(DATA_LIST *list,DATA *item);
etc

I have done it countless times, and I think this is one of the
reasons C is perceived as a language unable to program anything serious.

> The problem is you telling people to
> use your extensions to C such as operator overloading or telling people
> to use your implementation of such things if it is not written in
> standard C and freely available.

lcc has been always an experimental compiler where people can try
new ideas. The objective of my implementation of operator overloading
and other "extensions" is to *prove* that this can be done in a
simple way in a simple compiler. That was the objective. And I would
like that the community as a whole reflects on the possibility of
incoporating those extensions into the language, making my special
implementation unneeded.

But even without those extensions, a simple standard about lists,
would provide a much needed simplification of programs, increasing
portability and reliability. How many bugged implementations of those
lists primitives are there?

The polemic that I used (and that I regret now) arises from an
incredible feeling of frustration with a community that is slowly
drifting into obsolescence without noticing it.

I mentioned the reaction of the comitee confronted with the buffer
overflow bug written in the asctime() function in the standard.
I cited the answer to the first bug-correction proposal of Mr Cleaver
(memory overwrites are allowed) but nobody seemed to notice.

> If you want to discus extending the C language or the standard C library
> then that belongs in another group. Others have stated the name of the
> group but I can't be bothered to look it up.

Maybe, but in comp.std.c there are more or less the same people.
I doubt it that the reaction would be different. I mentioned
(in a long thread) the fact that asctime() had a bug, but the
reaction was the same:

Nobody cares.

I have been told in this group that C++ was designed to do this
kind of stuff. This implies that C should stay in the same level
as 1989 forever, what fits nicely for people that think that only
C++ has any future.

I think that the agnostic nature of C gives the programmer a lot of
creative freedom, freedom of expression. There isn't a single,
language preferred way of doing things (OO programming) but you
can use any paradigm that fits the application best.

The complexity of C++ is so staggering, that most people, even
experts, do not understand the language in all the facets it
has. C++ has gone the "let's complxify things" until ridiculous
heights.

Confronted with that, I think that is normal that people react strongly
when presented with something that seems to go in the same
direction.

But this is not the case here.

Relevant Pages

  • Re: Python or PHP?
    ... > every language here and there more ways to do something. ... The best the programmer can do, as you imply, is to ... parse out into proper perl expressions. ... > lists, dictionaries, etc. etc. ...
    (comp.lang.python)
  • Re: repeating groups
    ... I see no reason to add bags. ... much like the language they are modeling. ... Because logical nested bags, sets, and lists ... programmer who has never tried Java but is convinced that garbarge ...
    (comp.databases.theory)
  • Re: Python or PHP?
    ... >> every language here and there more ways to do something. ... The best the programmer can do, as you imply, is to ... I am curious of a list of extraneous methods in Perl (more about the ... I just had a glance on Python, ...
    (comp.lang.python)
  • Re: The War On HLA
    ... Take a look at the HLA compile-time language. ... Macros can be abused just like any other language feature. ... I find it amusing, however, that HLL programmers (e.g., Delphi, ... > feature is left to the programmer to invent his own uses for. ...
    (alt.lang.asm)
  • Re: Is Lisp a Blub?
    ... known in the abstract space of programming language design that "ought" to be ... When the source code changes the programmer ... business needs of the customers who pay the bills. ... What about the Transformation Programmer? ...
    (comp.lang.lisp)