C needs a BOOST

Wojtek Lerch wrote:

Just out of curiosity, who were you responding to? My newsreader
displays posts sorted by time, not as a tree.

"jacob navia" <ja***@nospam.orgwrote in message
news:47***********************@news.orange.fr...
>[snip nonsense]

You can't contribute anything to this discussion, then, you
try to destroy it.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

To Sossman and Heathfield that post nonsense with no
other motive than to laugh about any proposal to do
something here.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 5 '07 #103

jacob navia said:

<snip>

To Sossman and Heathfield that post nonsense with no
other motive than to laugh about any proposal to do
something here.

Mr Navia: my reply was entirely serious. If you find it amusing, that's up
to you, but it was not intended so.

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?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Oct 5 '07 #104

Nick Keighley wrote:

On 3 Oct, 23:32, jacob navia <ja...@nospam.orgwrote:

>Note:
I used only ONE exclamation mark.

no you didn't.
Why do you say things like this!

He didn't for the post in which he said that he didn't.
In other words, he kindly accepted my criticisim about exclamation marks
and adopted a good style.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

Oct 5 '07 #105

"André Gillibert" wrote:

Douglas A. Gwyn wrote:
The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.
C can still be a good choice for many new projects.

Sure, and I haven't said otherwise. I use it myself.

I maintain that C is not a good choice for most "modern" major
applications. However, if you already have access to a good
C programming support environment (libraries, disciplines) then
that could influence the decision. Also, C still has an edge
over any of the alternatives when it comes to breadth of
portability.

Oct 5 '07 #106

Eric Sosman wrote:

_Bool IntGreaterThanOrEqual(int x, int y);
Comments?

Please don't continue the API design discussion in comp.std.c.
Once you have settled on something, it might be within the
charter of comp.std.c to suggest that it be standardized,
but until then it really is outside the charter of comp.std.c.

Oct 5 '07 #107

"André Gillibert" wrote:

(C99 broke the portability dream, ...

Only in that using its new features precludes easy porting to a
C90 environment. Since it is nearly a pure extension of C90
(with the exception of implicit int, which most programmers
seem happy to have removed), porting C90 code to C99 environments
is generally not a problem. Indeed, such forward compatibility
was the main constraint when revising the C standard. Stability
at this level is important for the industry.

Oct 5 '07 #108

"André Gillibert" wrote:

The fact that C99 is already to big and requires YEARS to be implemented
correctly (unlike C90 which is much simplier)

C99 didn't *require* years to implement. In fact, there was at least
one C99 front end (from Edison) not very long after C99 was published.

The bulk of the additions to C99 were in the library functionality.
The additional library facilities add no appreciable complexity, just
more work for somebody (Dinkumware, perhaps?). The added data types
don't much complicate the compiler, although some platforms have to
come up with additional run-time arithmetic support. The main
complication is <tgmath.h>, which generally is non-trivial to add to
a C90 compiler. VLAs could also require a bit of extra work.

The rate at which C99 conformance is being attained by GCC could be
explained by a combination of low customer demand (C90 being adequate
for most C programmers) and relative lack of interest by implementors.

Oct 5 '07 #109

jxh

On Oct 4, 1:02 pm, "André Gillibert"
<tabkanDELETETHIS...@yahodeletethato.frwrote:

user923005 wrote:
The problem I see with template support is that it requires operator
overloading.

It's simply huge, very complex, and causes linking issues.
It's also quite weak without function overloading support with complex
resolution rules.
Classes support, with constructors and destructors, also greatly help to
the functionality of C++ templates.

I think it is rather myopic to dismiss the potential usefulness
without
at least trying. The weaknesses and limited usefulness of C macros
has
not dampered attempts to use them for generic programming in C. Why
not
provide the generic programmers better tools? Adding template support
wouldn't even break backward compatibility (except for the creation of
new keywords, probably at least "template" and "typename").

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).
Note that this is not advocating object oriented programming, since I
am not proposing methods or inheritance.

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

-- James

Oct 5 '07 #110

Douglas A. Gwyn wrote:

"André Gillibert" wrote:
>(C99 broke the portability dream, ...

Only in that using its new features precludes easy porting to a
C90 environment.

Yes, that was my point.
When writing pure C90 code, you get the good feeling that it'll be easily
ported everywhere.
That's one of the reasons that explain why C99 has been adopted very
slowly.

Since it is nearly a pure extension of C90
(with the exception of implicit int, which most programmers
seem happy to have removed),

And size_t which can be larger than unsigned long or ptrdiff_t which can
be larger than long.

Otherwise, there're no big incompatibilities.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

Oct 5 '07 #111

"André Gillibert" wrote:

Did you know that C++ had slowly evolved from C?
"C with objects" was very small.
Then, it became C++ as new features were added.

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. The early "C++"
implementations were based on a similar architecture (the
"cfront" preprocessor).

Similarly C evolved continuously from B...

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.

Oct 5 '07 #112

Douglas A. Gwyn wrote:

jacob navia wrote:
>Douglas A. Gwyn wrote:
>>The only real use for such a library would be for new program
development, once the learning hurdle has been overcome. Much
new development really ought to use higher-level languages in
the first place.

>Actually then, you say it is better not to develop anything new in C.

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 would like that you claify this of course. Did I understand you
correctly?

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.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 5 '07 #113

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?

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

Oct 5 '07 #114

Fr************@googlemail.com wrote:

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.

Oct 5 '07 #115

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

Oct 5 '07 #116

Douglas A. Gwyn wrote:

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.
--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

Oct 5 '07 #117

Douglas A. Gwyn wrote:

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.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

Oct 5 '07 #118

André Gillibert wrote:

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!

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 5 '07 #119

Default User said:

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.

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

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Oct 5 '07 #120

jacob navia wrote:

André Gillibert wrote:

>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!

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.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

Oct 5 '07 #121

jxh wrote:

>
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.

--
Ian Collins.

Oct 5 '07 #122

André Gillibert wrote:

jacob navia wrote:

>André Gillibert wrote:

>>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!

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.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 5 '07 #123

jacob navia wrote:

>
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.

--
Ian Collins.

Oct 5 '07 #124

Richard Heathfield wrote:

Default User said:

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.

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

Oct 5 '07 #125

Ian Collins wrote:

jxh wrote:
>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.

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.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 5 '07 #126

Ian Collins wrote:

jacob navia wrote:
>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.

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[i]))
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...
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 5 '07 #127

jacob navia wrote:

Ian Collins wrote:
>>
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?

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.

Oct 5 '07 #128

jacob navia wrote:

Ian Collins wrote:
>jacob navia wrote:
>>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.

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[i]))

{
someCode( nameTab[i] );
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.

--
Ian Collins.

Oct 5 '07 #129

Ian Collins wrote:

>
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?
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 5 '07 #130

[csc snipped]

Default User said:

<snip>

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

No. :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Oct 5 '07 #131

jacob navia wrote:

Ian Collins wrote:
>>
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?

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.

--
Ian Collins.

Oct 5 '07 #132

Richard Heathfield wrote:

[csc snipped]

Default User said:

<snip>

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

No. :-)

Ok, Dickie it is.

Brian

Oct 5 '07 #133

Ian Collins wrote:

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.

Fine. But why can't you write exactly the same code in
your new_foo() function???

You can do ALL that in new_foo(). The *only* difference is that is NOT
called automatically!

The same for the destructor destroy_foo(). You can release the resource
JUST AS you do in your C++ destructor!

The only differences are some syntax and the fact that the
compiler will not call it for you!

And remember the problems you have with the copy constructors,
that end being called at odd places where you do not want them called,
and the dozens of recipes C++ books give us on how to avoid
calling the copy constructor implicitly, etc.

1) Constructors and destructors exist in C. They are just not
called automatically by the compiler but by the developer
when he deems necessary.
2) This simplifies the language and the compiler.
3) Since they are just *conventions* they are much more
flexible than in C++.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 5 '07 #134

jacob navia <ja***@nospam.orgwrites:
[...]

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.

[...]

That's a matter of taste. Personally, given a language that supports
operator overloading, I have no problem with using "+" for string
concatenation. The fact that it's not commutative just doesn't bother
me. The intended meaning of
"hello" + " " + "world"
seems perfectly obvious. It's a convenient notation; mathematical
purity isn't required.

Then again, I don't particularly mind "<<" and ">>" for I/O.

I've also worked with languages that have a dedicated operator for
string concatenation (Perl's ".", Perl 6's "~", Ada's "&", which is a
general one-dimensional array concatentation operator), but C has
pretty much run out of operator symbols unless you want to use
Unicode.

One minor drawback is that you can't use it to concatenate a string
with a character. For example,
"hell" + 'o'
already has a meaning (one invokes undefined behavior in every
character encoding I've ever seen).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 5 '07 #135

jacob navia wrote:

Ian Collins wrote:

>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.

Fine. But why can't you write exactly the same code in
your new_foo() function???

You can do ALL that in new_foo(). The *only* difference is that is NOT
called automatically!

The same for the destructor destroy_foo(). You can release the resource
JUST AS you do in your C++ destructor!

NO, you can not. HoldSomething's destructor is called when the object
goes out of scope. So even if you code uses early returns, the resource
is still freed.

The only differences are some syntax and the fact that the
compiler will not call it for you!

A very important difference.

--
Ian Collins.

Oct 5 '07 #136

Ian Collins <ia******@hotmail.comwrites:

jacob navia wrote:

[...]

>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.

In other words, having to invoke the constructor explicitly isn't a
huge deal, since you're declaring the object anyway, but having the
destructor invoked for you when the object ceases to exist is a very
nice convenience. jacob has argued against C++-style destructors
because they're difficult to implement; the point is to make the
compiler, rather than the programmer, do that hard work.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 5 '07 #137

Keith Thompson wrote:

jacob navia <ja***@nospam.orgwrites:
[...]
>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.
[...]

That's a matter of taste.

True. The operation "Concatenate this strings" is in
my mind quite different from "Addition" , but maybe is
just a personal problem.

More serious misuses of operator overloading are when you try to give
meaning to meaningless operations like adding two dates for instance.

In general mathematical operations should be reserved for
*numbers*. This is a rule I have tried to follow, but
I can imagine that many people will use + to concatenate strings
when is available.

"2"+"2" --"22"
:-)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 5 '07 #138

Keith Thompson wrote:

In other words, having to invoke the constructor explicitly isn't a
huge deal, since you're declaring the object anyway, but having the
destructor invoked for you when the object ceases to exist is a very
nice convenience. jacob has argued against C++-style destructors
because they're difficult to implement; the point is to make the
compiler, rather than the programmer, do that hard work.

This is the way C++ went. It means that every imaginable feature was
added to the language, in a baroque construction that defies
gravity.

No, it is not that I fear implementing constructors, but that I
fear that that feature will make the language more opaque, in the
sense of too much IMPLICIT code.

And that feature needs other features:

struct foo {
int a;
struct foo1 f1;
int b;
};

When we destroy foo, we should call the destructor of foo1
first, isn't it?

And what happens with:

struct foo {
int a;
struct foo1 *pf1;
};

Should we call the destructor of f1 with the pf1 pointer?
Or only when pf1 is not NULL?

This will produce the same complex set of rules that
C++ has.

Look. Let's NOT redo C++. C is simple. If you want
"the whole enchilada"... then program in C++ of course.

C and C++ remain distinct languages. C keeps things simple
and is fast, C++ has other uses, and can be as fast as C
sometimes.

:-)

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 5 '07 #139

Default User said:

Richard Heathfield wrote:

>[csc snipped]

Default User said:

<snip>

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

No. :-)

Ok, Dickie it is.

You might want to reconsider that.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Oct 5 '07 #140

Richard Heathfield wrote:

Default User said:

Ok, Dickie it is.

You might want to reconsider that.

You don't seem very friendly.

Brian

Oct 5 '07 #141

jacob navia wrote:

Keith Thompson wrote:
>In other words, having to invoke the constructor explicitly isn't a
huge deal, since you're declaring the object anyway, but having the
destructor invoked for you when the object ceases to exist is a very
nice convenience. jacob has argued against C++-style destructors
because they're difficult to implement; the point is to make the
compiler, rather than the programmer, do that hard work.

This is the way C++ went. It means that every imaginable feature was
added to the language, in a baroque construction that defies
gravity.

You're wandering of into rant land again... The topic was the automatic
calling of destructors.

No, it is not that I fear implementing constructors, but that I
fear that that feature will make the language more opaque, in the
sense of too much IMPLICIT code.

There I would agree with you, don't forget I wasn't proposing adding
them, just putting forward an example of where they can be useful and
enable an idiom not supported by C.

And that feature needs other features:

struct foo {
int a;
struct foo1 f1;
int b;
};

When we destroy foo, we should call the destructor of foo1
first, isn't it?

That's pretty obvious.

And what happens with:

struct foo {
int a;
struct foo1 *pf1;
};

Should we call the destructor of f1 with the pf1 pointer?
Or only when pf1 is not NULL?

Pointers don't have destructors.

This will produce the same complex set of rules that
C++ has.

C++ rules for destructor sequencing are pretty simple and logical.

--
Ian Collins.

Oct 6 '07 #142

Ian Collins wrote:

jacob navia wrote:
>Keith Thompson wrote:
>>In other words, having to invoke the constructor explicitly isn't a
huge deal, since you're declaring the object anyway, but having the
destructor invoked for you when the object ceases to exist is a very
nice convenience. jacob has argued against C++-style destructors
because they're difficult to implement; the point is to make the
compiler, rather than the programmer, do that hard work.

This is the way C++ went. It means that every imaginable feature was
added to the language, in a baroque construction that defies
gravity.

You're wandering of into rant land again... The topic was the automatic
calling of destructors.

>No, it is not that I fear implementing constructors, but that I
fear that that feature will make the language more opaque, in the
sense of too much IMPLICIT code.

There I would agree with you, don't forget I wasn't proposing adding
them, just putting forward an example of where they can be useful and
enable an idiom not supported by C.

>And that feature needs other features:

struct foo {
int a;
struct foo1 f1;
int b;
};

When we destroy foo, we should call the destructor of foo1
first, isn't it?

That's pretty obvious.

Maybe for you, but C has no classes, and it could be that we call
the destructor of foo first, that can decide if it calls the
foo1 destructor before doing something, or after, or not at all.

Here the rules are not the same, even if we could design similar
rules.

>
>And what happens with:

struct foo {
int a;
struct foo1 *pf1;
};

Should we call the destructor of f1 with the pf1 pointer?
Or only when pf1 is not NULL?

Pointers don't have destructors.

Same as above. Pretty obvious but why not? Does this means
that destructors can't be called ever with the result of malloc?

Ahh but wait... we should introduce "new" then, to do the
allocaton that will need cleanup.

You see the problems?

A feature leads to another feature, that needs yet another feature,
and people say:

"Let the compiler do the work"

and the language grows and grows
and swallows everyone of the implementors alive because
feature xyz interfers with feature zyx, the rules go for
pages and pages and pages.

The rules of operator resolution
go for something like 6-7 PAGES of incomprehensible specs
that can't be followed by a brain but only by a CPU.

Have you tried to read the C++ standard? I did.

>This will produce the same complex set of rules that
C++ has.

C++ rules for destructor sequencing are pretty simple and logical.

Yes, but it has the class hierarchy rules, that C doesn't have.

In C the rules can't be the same. We would need a new set of rules,
and some years of testing of those rules in the field, etc.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Oct 6 '07 #143

jacob navia <ja***@nospam.orgwrites:

Keith Thompson wrote:
>jacob navia <ja***@nospam.orgwrites:
[...]
>>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.
[...]
That's a matter of taste.

True. The operation "Concatenate this strings" is in
my mind quite different from "Addition" , but maybe is
just a personal problem.

More serious misuses of operator overloading are when you try to give
meaning to meaningless operations like adding two dates for instance.

In general mathematical operations should be reserved for
*numbers*. This is a rule I have tried to follow, but
I can imagine that many people will use + to concatenate strings
when is available.

"2"+"2" --"22"
:-)

Since neither "2" nor "22" is a number, I don't see anything
particularly odd about that. (I suppose you could define "+" so
"2"+"2" yields "4", but then you have to deal with "2"+"foobar".)

Pointers aren't numbers, but we can add an integer to a pointer in
standard C.

Similarly, adding two dates doesn't make sense, but adding a date to a
duration to get a date, or subtracting two dates to get a duration, is
quite useful.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 6 '07 #144

jacob navia <ja***@nospam.orgwrites:

Keith Thompson wrote:
>In other words, having to invoke the constructor explicitly isn't a
huge deal, since you're declaring the object anyway, but having the
destructor invoked for you when the object ceases to exist is a very
nice convenience. jacob has argued against C++-style destructors
because they're difficult to implement; the point is to make the
compiler, rather than the programmer, do that hard work.

This is the way C++ went. It means that every imaginable feature was
added to the language, in a baroque construction that defies
gravity.

You want to add features to C. It seems that every proposed new
feature that you like is necessary, and every proposed new feature
that you don't like is baroque and will destroy the language.

You think operator overloading is important. I think constructors and
destructors, perhaps along with exception handling, are more important
than operator overloading -- though I'm not really convinced either
should be added to the standard.

No, it is not that I fear implementing constructors, but that I
fear that that feature will make the language more opaque, in the
sense of too much IMPLICIT code.

In a sense, all generated code is implicit. Something as simple as a
function call can require substantial generated machine code to
implement it, including deciding when things are allocated and
deallocated. I'm very glad the compiler figures all that out for me,
so I don't have to.

And that feature needs other features:

struct foo {
int a;
struct foo1 f1;
int b;
};

When we destroy foo, we should call the destructor of foo1
first, isn't it?

When we destroy an object of type ``struct foo'', yes, we need to
destroy that object's ``f1'' member, since that member (which is an
object) reaches the end of its lifetime at the same time.

And what happens with:

struct foo {
int a;
struct foo1 *pf1;
};

Should we call the destructor of f1 with the pf1 pointer?
Or only when pf1 is not NULL?

No, no destructor would be implicitly invoked for the pf1 member, any
more than the pointer should be implicitly free()d. That would be
disastrous if the pointed-to object is "owned" by something else. If
the ``struct foo'' really owns the ``struct foo1'' object (which is an
issue of program logic), its destructor can invoke the ``struct foo1''
destructor implicitly.

This will produce the same complex set of rules that
C++ has.

Some of them, but not necessarily all of them. It might be possible
to define a simpler model for constructors and destructors than what
C++ has. (That's not to imply that I have any idea what such a model
would look like.)

Look. Let's NOT redo C++. C is simple. If you want
"the whole enchilada"... then program in C++ of course.

C and C++ remain distinct languages. C keeps things simple
and is fast, C++ has other uses, and can be as fast as C
sometimes.

Then why do you want to change C at all?

Yes, I know, you want to "improve" C without bringing in all of C++.
But it's by no means obvious *which* features are most important.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 6 '07 #145

jxh

On Oct 5, 3:01 pm, Ian Collins <ian-n...@hotmail.comwrote:

jxh wrote:
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.

It is only name mangling, not function name overloading.
Function overloading would not become a feature of C. But the
work of name mangling would be something taken care of by the
compiler in the case of templates (the analog of creating a
unique identifier with the paste operator in C macros).

-- James

Oct 6 '07 #146

santosh

jacob navia wrote:

Look. Let's NOT redo C++. C is simple. If you want
"the whole enchilada"... then program in C++ of course.

C and C++ remain distinct languages. C keeps things simple
and is fast, C++ has other uses, and can be as fast as C
sometimes.

The most sensible thing you've said in a while. :)

Oct 6 '07 #147

jxh

On Oct 5, 3:41 pm, Ian Collins <ian-n...@hotmail.comwrote:
....

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?

I had wondered about the feasibility of an "at_return()" API,
analog to "at_exit()", but it is hard to write functions that
handle cleanup without access to the local variables of the
function that is about to return.

The availability of template functions may alleviate that
problem, however.

template <FILE *fp>
void close_file_pointer () { fclose(fp); }

void foo () {
FILE *input = fopen("inputfile", "r");

at_return(close_file_pointer<input>);

/* ... */
}

-- James

Oct 6 '07 #148