C needs a BOOST

[Douglas A. Gwyn]

Just out of curiosity: are all Frenchmen so wilfully ignorant as to drop
honorifics from names (as you habitually do), or is it just you giving
your countrymen a bad name?

Now, now, Heathfield, that isn't helpful.

 

[jacob navia]

That's not what I said.

Thanks. I was hoping for a misunderstanding.


I said that *much* new development ought

to be done in higher-level languages. (In fact, it often is.)

That means that the potential benefit of new facilities for such
applications is diminished.


I doubt that you did.

My opinion, based on considerable experience in this area, is that
C remains the best choice for much "systems implementation" work,
but that it is more cost-effective to use other, higher-level
languages for many "applications".

My opinion is based on the success of the lcc-win32 compiler.
This implementation of C99 under windows has been an enormous
success. In august this year we passed the benchmark of half a million
downloads, since we setup those counters, approximately 1 to 2
years ago.

We have many universities and schools that use lcc-win for
their introduction to programming.

Why?

Because in the bloated desktop environment of today, lcc-win
is just 5MB, installs in less than a minute, and can be
installed in 30 machines for a class in no time. People
like simple stuff, software that doesn't take ages to install,
that is simple to use.

That is why I am convinced that C is not only for systems programming

But even if we would accept your viewpoint, systems programmers
do need to use stacks, lists, hash tables, and many other
common data structures.

In my C consulting, as I explained you in my messages, I find at
each project the same software for linked lists and hash tables
rewritten from scratch and adapted to the particular project.

It is not that I do not know how to build a reusable one, but it is
the fact that if I bring MY list library I will have to change
the customer's software since he uses a slightly different one.

This is the crucial point that you never address:

It is not the difficulty if writing this small routines. It is the
fact that each one of us must write one, and there is no
CONSENSUS AS TO A COMMON INTERFACE, what would save us so much
WORK.

The standards body has a crucial role here and that is why this
dicussion is important here!

If the standards body proposes a COMMON list handling and
hash table handling INTERFACE, we would not need to write
at each project those routines again. This would of course
simplify systems programming, since a better tested
set of routines could be used either bought from some
software provider or used from the compiler library.

[snip]

It is (in my opinion) a mistake to try to push C (in any variant)
as a general solution for all programming problems. It's a
good choice for the systems programming that it was designed for,
although it still has deficiencies even for that. I would rather
the time spent discussing directions for C concentrate more on
remedies for its remaining deficiencies for systems work than on
trying to support applications where there are better choices.

Systems programmers use hash tables, lists stacks and many other data
structures. Making a common interface for those would simplify
their work.

 

[Douglas A. Gwyn]

Wouldn't it be a good idea to reduce the risk of conflicting with an
existing implementation of these valuable functions by working in a
clc "namespace"? E.g. clc_IntAdd() etc.

Certainly it points out the need for better namespace support.

One thing that can be done in Standard C is to embed function
pointers within a single extern "struct" object, e.g.
extern struct CLC_HOOK {
void *Allocator(...);
...
} CLC_HOOK; /* initialized in the library */
#define ThingAllocator CLC_HOOK.Allocator
...
Only a single external symbol to collide, and if it has to be
renamed a single #define will take care of it.

 

[Default User]

Richard Heathfield wrote:

Just out of curiosity: are all Frenchmen so wilfully ignorant as to
drop honorifics from names (as you habitually do), or is it just you
giving your countrymen a bad name?

I thought you Brits were used to that sort of thing.



Brian

 

[André Gillibert]

C didn't evolve continuously from B. C was inspired by B, but
had a new design and implementation of its own. C did evolve,
of course.

C was very very strongly inspired from B, to such an extent that the
intermediate language (NB) had a full backward compatibility with B, and C
had a good backward compatibility with B, so that, most of the code base
could recompile without problem.

 

[André Gillibert]

Well, that's not entirely accurate. Bjarne started out with
"C with classes", which I used to distribute as a freebie with
the BRL Unix System V emulation before C++ replaced it. "C
with classes" was implemented as a preprocessor selected by the
"cc" driver whenever "#class" had been detected in the source
code by the C preprocessor phase.

That's why I deem that C with classes is directly derived from C. It's
just C with an extension added through a special pre-processor. That's
similar to "C++ with the Qt pre-processor"...
This is not a complete refactoring of the language.

 

[André Gillibert]

As I am proposing C templates, there are no objects and function
overloading. Function and struct name expansion occurs from explicit
instantiation of the templated function or struct.

However, even without supporting the notion of C++ methods, adding the
notions of constructor and destructor to C structs would be
tremendously
useful (at the very least, it would provide an easy to use alternative
to using a "goto" to the end of the function to do common cleanup).

C + constructors/destructors + templates = C++ - overloading - exceptions
- inheritance/methods.

If we combine this proposal with jacob navia proposal, we get:

C + constructors/destructors + templates + overloading + GC = C++ -
exceptions - inheritance/methods + GC

Try to implement that. Do you think it'll still be "very small" compared
to a C++ implementation?

You cannot claim that it's small until you've not successfully implemented
it.

I believe I read an article about Bjarne Stroustroup where he mentioned
that if he had introduced templates earlier, he would have deemphasized
the use of inheritance as a mechanism for code reuse in his C++ material.

Which doesn't mean that C++ would have been small.
I don't think that the biggest part of C++ isn't in inheritance and
methods. Actually, I would rather think that every component of
C++ participates to the size of the language.

Maybe I'm wrong, and templates + constructors/destructors are very easy to
implement in a few LOC, but you've to give evidence in order to prove that
your proposal is realistic.

 

[jacob navia]

You cannot claim that it's small until you've not successfully
implemented it.

I have implemented all extensions that I propose,
and the resulting compiler has 2000 lines more of C.
(Including comments)
For operator overloading and generic functions!

 

[Richard Heathfield]

Default User said:

Richard Heathfield wrote:



I thought you Brits were used to that sort of thing.

No. In fact, we're not even used to being called Brits.

 

[André Gillibert]

I have implemented all extensions that I propose,
and the resulting compiler has 2000 lines more of C.
(Including comments)
For operator overloading and generic functions!

I was talking about templates, constructors and destructors.
Personally, I think that your proposal is more realistic than
templates+constructors/destructors... At least, there's a successful
implementation.

 

[Ian Collins]

As I am proposing C templates, there are no objects and function
overloading. Function and struct name expansion occurs from explicit
instantiation of the templated function or struct.

Isn't that just function overloading with a different name? Any form of
templates requires some form of function name overloading and name mangling.

However, even without supporting the notion of C++ methods, adding the
notions of constructor and destructor to C structs would be
tremendously
useful (at the very least, it would provide an easy to use alternative
to using a "goto" to the end of the function to do common cleanup).
Note that this is not advocating object oriented programming, since I
am not proposing methods or inheritance.

That would be useful, perhaps the only extension proposed here that adds
support for a new idiom (RAII) to C that can't be emulated in standard C.

 

[jacob navia]

I was talking about templates, constructors and destructors.

Wow, that would be C++.

There is no point in redoing C++.

Constructors and destructors look simple but are HELL to implement:

int foo(int n)
{
int arg;
// ...
if (arg > 0)) {
struct foo;
// ... some code
goto exit;
// ... some code
}
exit:
return 56;
}

The destructor of foo needs to be called before the goto gets
executed... This was a bug still in MSVC some years ago.

And you have to implement it with GOOD code generation, if not
the generated code will be a dog!

If you want C++, then you can use C++.

I think neither constructors/destructors belong to C since
the language should remain transparent.

You can always do it yourself by calling

FOO myFoo = new_foo();
destroy_foo(&myFoo);

Since generic functions are proposed, you can write your constructor
to take several kinds of arguments.

C doesn't need anything else. Just operator overloading and
generic functions.

 

[Ian Collins]

Constructors and destructors look simple but are HELL to implement:

int foo(int n)
{
int arg;
// ...
if (arg > 0)) {
struct foo;
// ... some code
goto exit;
// ... some code
}
exit:
return 56;
}

The destructor of foo needs to be called before the goto gets
executed... This was a bug still in MSVC some years ago.

The simple solution to that is to get rid of that decrepit relic from a
past age, goto!

The only possible justification for using goto is cleanup code, which
can be cleanly handled with destructors.

 

[jacob navia]

Isn't that just function overloading with a different name? Any form of
templates requires some form of function name overloading and name mangling.

That would be useful, perhaps the only extension proposed here that adds
support for a new idiom (RAII) to C that can't be emulated in standard C.

Why is this not a good idea?

Constructors and destructors look great in principle, but
they are
o difficult to implement correctly. It took the C++ people 5-6
years to get it right.
o They add too much implicit code to the language. And this is
a very important point.

C is very explicit. You see something, and you can (more or less)
see what the machine is doing. The program text is more verbose,
but precisely BECAUSE of that it is easier to understand. This
is great for maintenance, and we know that most of the time we will
be doing maintenance of our own programs .

This contradicts somehow the operator overloading proposal but
only in surface.

That feature allows the introduction of new numeric types and
for an uniform accessing of containers with the operators
[ ].

True, they introduce unseen function calls, but this stays in a
very specific context. It is true that this is a potential source of
problems.

One example is the "addition" of strings instead of concatenation as
a function call. When A and B are strings, A+B != B+A, what is not at
all clear to me. It is better to use a function call to do that
operation.

The general principle is to improve the language by making it
clearer, without losing its essential nature: simplicity.

The principal use of constructors/destructors is to make
memory management easier. In lcc-win, I propose the garbage
collector. That makes it even easier, without any heavy
language changes.

 

[Default User]

Default User said:

you >> giving your countrymen a bad name?

No. In fact, we're not even used to being called Brits.

Beats "Yanks" or "Seppos".

We like to call everybody by their first name. Do you prefer Ricky or
Richie?




Brian

 

[jacob navia]

The simple solution to that is to get rid of that decrepit relic from a
past age, goto!

The only possible justification for using goto is cleanup code, which
can be cleanly handled with destructors.

How do you get rid of the goto?

int Search_byName(char *name,int HowtoSearch)
{
switch(HowtoSearch) {
// ...
case 42:
for (int i=0; i<Len; i++) {
if (!strcmp(name,nameTab))
goto found; // <<<<--
}
fprintf(stderr,
"Not found\,%s is an illegal name);
return 0;
case 65:
// ...
}
return -1;
found:
// Some code
return 1;
}

The break statement has no arguments, and for breaking out
of several nested scopes you *have* to use gotos.

We have discussed this in comp.std.c several times. There were proposals
to give an argument to break, like in this case
break found;

but it was argued that this would be identical to goto...

 

[Ian Collins]

Why is this not a good idea?

RAII is a very powerful idiom that C does not support.

Constructors and destructors look great in principle, but
they are
o difficult to implement correctly. It took the C++ people 5-6
years to get it right.

That was then, the work has been done.

o They add too much implicit code to the language. And this is
a very important point.

Nope, if you don't want one, don't add it to the struct.

The principal use of constructors/destructors is to make
memory management easier.

Nope, it's to make deterministic resource management easier.

In lcc-win, I propose the garbage
collector. That makes it even easier, without any heavy
language changes.

Nope, it add some form of non-deterministic memory management.

Note I'm not proposing the addition, it's just that RAII is the one
thing I miss most when swapping from C++ to C. Just about everything
else can be worked around in standard C. The closest equivalent I know
of is pthreads cleanup handlers. Maybe something along those lines
might be a more acceptable extension to C?

 

[Ian Collins]

The simple solution to that is to get rid of that decrepit relic from a
past age, goto!

The only possible justification for using goto is cleanup code, which
can be cleanly handled with destructors.

How do you get rid of the goto?

int Search_byName(char *name,int HowtoSearch)
{
switch(HowtoSearch) {
// ...
case 42:
for (int i=0; i<Len; i++) {
if (!strcmp(name,nameTab))

{
someCode( nameTab );
return 1;

}
fprintf(stderr,
"Not found\,%s is an illegal name);
return 0;
case 65:
// ...
}
return -1;
}

The break statement has no arguments, and for breaking out
of several nested scopes you *have* to use gotos.

Um, I can honestly say I've never used goto in over 20 years of
professional C programming.

 

[jacob navia]

Note I'm not proposing the addition, it's just that RAII is the one
thing I miss most when swapping from C++ to C. Just about everything
else can be worked around in standard C. The closest equivalent I know
of is pthreads cleanup handlers. Maybe something along those lines
might be a more acceptable extension to C?

But...

What is wrong with

FOO myFoo = new_foo(67,"J. Smith");

I just do not see the difference to C++.

Why is this constructor worst than its C++ counterpart?

 

[Ian Collins]

But...

What is wrong with

FOO myFoo = new_foo(67,"J. Smith");

I just do not see the difference to C++.

Why is this constructor worst than its C++ counterpart?

Maybe you should read up on RAII.

A common C++ idiom is

struct HoldSomething
{
Something* held;

HoldSomething( Something* s ) { held = s; }
~HoldSomething() { delete held; }
};

or

struct HoldSomething
{
Something held;

HoldSomething() { held = AcquireSomething(); }
~HoldSomething() { Release Something( held ); }
};

Something can be any resource to be held by the scope. It is released
when the HoldSomething object goes out of scope.