Boost process and C

[extrudedaluminiu]

Hi,

Is there any group in the manner of the C++ Boost group that works on
the evolution of the C language? Or is there any group that performs an
equivalent function?

Thanks,
-vs

[Keith Thompson]

ex**************@gmail.com writes:

Is there any group in the manner of the C++ Boost group that works on
the evolution of the C language? Or is there any group that performs an
equivalent function?

I don't know anything about the C++ Boost group, but the rest of your
question seems clear enough without that information.

The ISO committee, JTC1/SC22/WG14, controls the C language standard.
Its web page is <http://www.open-std.org/JTC1/SC22/WG14/>.

Discussion of the C standard (as distinct from discussion of the
language defined by the C standard) generally takes place in
comp.std.c. (As with any newsgroup, I recommend browsing the archives
and/or lurking for a while before posting.)

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

[jacob navia]

ex**************@gmail.com a écrit :

Hi,

Is there any group in the manner of the C++ Boost group that works on
the evolution of the C language? Or is there any group that performs an
equivalent function?

Thanks,
-vs

I would like that such a group existed but... I have never found one.

It is a pity. Most people in this forum, for instance, that I thought
it would be suchg a group, refuse to discuss about any evolution
and seem nostalgic of some mythical past: they endorse the C89
standard (full 17 years ago) and will start getting VERY upset
if any improvement is proposed. Most of them think, as one of them
said:

"C++ is the future, we are just waiting that C programmers die out."

This precludes of course any attitude that would discuss the evolution
of the language

jacob

[jacob navia]

jacob navia a écrit :

Most of them think, as one of them
said:

"C++ is the future, we are just waiting that C programmers die out."

The reference is: (the guy that said that)

83
De : E. Robert Tisdale
Date : Mar 15 fév 2005 18:29
E-mail : "E. Robert Tisdale" <[e-mail]>
Groupes : comp.lang.c, comp.sources.d

Masood wrote: I know that this topic may inflame the "C language Taleban"
but is there any prospect
of some of the neat features of C++ getting incorporated in C?
No I am not talking out the OO stuff.
I am talking about the non-OO stuff
that seems to be handled much more elegantly in C++, as compared to C.
For example, consts, declaring variables just before use,
Already adopted by C99.
new & delete, references, etc.
Implies constructors and destructors (OO stuff).
I am asking this question with a vested interest.
I would really like to use these features in my C programs.

You can make C better by simply using these C++ features
and compiling with a C++ compiler.
This means that you should take care to ensure that
every C program that you write is also a valid C++ program.

The only reason that C exists
is so that C programmers can maintain legacy codes.
C programmers don't want C to evolve or grow.
They aren't enthusiastic about the new features introduced in C99
and compiler developers haven't fully implemented them [yet]
so I don't think that there will be much interest
in adding the C++ features that you have mentioned.
I was quite surprised that somebody can say something like that without
having anyone that would contradict him, that I started a new thread
the 1 Nov 2004 to discuss that...

[Michael Mair]

jacob navia schrieb:

ex**************@gmail.com a écrit :

Is there any group in the manner of the C++ Boost group that works on
the evolution of the C language? Or is there any group that performs an
equivalent function?
I would like that such a group existed but... I have never found one.

You really did not search that hard, did you? comp.std.c
It is a pity. Most people in this forum, for instance, that I thought
it would be suchg a group, refuse to discuss about any evolution
Because, as you have been told time and again, this newsgroup is
not such a group.
and seem nostalgic of some mythical past: they endorse the C89
standard (full 17 years ago) and will start getting VERY upset
if any improvement is proposed.
C89 still is the C standard effectively used.
I would prefer that it were not so. K&R C and C99 are discussed
in this group as well, and if there is a C0X, it will be discussed
here as well.

Most of them think, as one of them
said:

"C++ is the future, we are just waiting that C programmers die out."
If, as you indicated in <44***********************@news.wanadoo.fr>,
this is paraphrasing E. Robert Tisdale,
<cu**********@nntp1.jpl.nasa.gov>, then you just have done yourself
a disservice. Watch whom you quote.
This precludes of course any attitude that would discuss the evolution
of the language

*sigh* Go to the appropriate places or open one yourself.
I am certainly willing to contribute.

Somehow, "Embedded C" and "C99" evolved without your contribution.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.fr> writes:

jacob navia a écrit :

Most of them think, as one of them
said:
"C++ is the future, we are just waiting that C programmers die out."

The reference is: (the guy that said that)

83
De : E. Robert Tisdale
Date : Mar 15 fév 2005 18:29
E-mail : "E. Robert Tisdale" <[e-mail]>
Groupes : comp.lang.c, comp.sources.d

[snip]
I was quite surprised that somebody can say something like that
without having anyone that would contradict him, that I started a new
thread
the 1 Nov 2004 to discuss that...

E. Robert Tisdale is a notorious troll. If his absurd statement
didn't start a discussion, it's probably because most of the regulars
here have killfiled him, and the rest have learned that arguing with
him is a waste of time.

jacob, I honestly don't know where you got this idea that nobody wants
C to change. I'm losing count of the number of times it has been
patiently explained to you that *this newsgroup* discusses the C
programming language as it currently exists.

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

[CBFalconer]

jacob navia wrote:

jacob navia a écrit :

Most of them think, as one of them said:

"C++ is the future, we are just waiting that C programmers die out."

The reference is: (the guy that said that)

83
De : E. Robert Tisdale
Date : Mar 15 fév 2005 18:29
E-mail : "E. Robert Tisdale" <[e-mail]>
Groupes : comp.lang.c, comp.sources.d

I believe your soul-mate, Trollsdale, can be found on c.l.c++.
Maybe you should go there and join him on the universal plonk
list. Nobody with any sense ever paid any attention to him, and
any failure to plonk was due to his tendency to revise quotes. You
have certainly classified yourself nicely here.

How small words do we have to use to explain that language change
discussion belongs in comp.std.c, while c.l.c discusses the
existing language? Are two syllables allowed?

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Default User]

Keith Thompson wrote:

jacob navia <ja***@jacob.remcomp.fr> writes:

jacob navia a écrit :

"C++ is the future, we are just waiting that C programmers die out."

De : E. Robert Tisdale I was quite surprised that somebody can say something like that
without having anyone that would contradict him, that I started a
new thread
the 1 Nov 2004 to discuss that...

E. Robert Tisdale is a notorious troll.

And Jacob is becoming more and more like a troll himself. Typical troll
behavior of pretending not to understand the topicality of the group,
and supplying ridiculous motives to anyone who disagrees with him.

Pretty soon it's going to be plonk/ignore time for him. He can go join
his hero Tisdale in the land of the unimportant.

Brian

[Chris Hills]

In article <44***********************@news.wanadoo.fr>, jacob navia
<ja***@jacob.remcomp.fr> writes

The only reason that C exists
is so that C programmers can maintain legacy codes.
wow! there is some one who does not have a clue! There is probably more
new C written than C++ Many C++ users have moved on to C#, Java, C++/CLI
etc etc

C is THE language of choice for embedded systems IE anything with
electrical power on or near it. Near? smart cards use C. The average
modern car has over 4 million lines of C in it. Washing machines,
microwaves, elevator controls, missiles, batteries etc the list is
endless.

C is a LONG way from dead. Next you will tell me no one uses 8 bit
systems anymore.
C programmers don't want C to evolve or grow.
Ture. In most cases we need a compact language. I use C++ or C depending
on what the target is.
They aren't enthusiastic about the new features introduced in C99
and compiler developers haven't fully implemented them [yet]
That is true.
so I don't think that there will be much interest
in adding the C++ features that you have mentioned.
There is no point in adding more C++ features to C If you need those
feature use C++. IF there is no C++ compiler for your target there is
probably s good reason for that.


I was quite surprised that somebody can say something like that without
having anyone that would contradict him, that I started a new thread
the 1 Nov 2004 to discuss that...

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes

jacob navia schrieb:

ex**************@gmail.com a écrit :
and seem nostalgic of some mythical past: they endorse the C89
standard (full 17 years ago) and will start getting VERY upset
if any improvement is proposed.

There is C99
C89 still is the C standard effectively used.
You mean ISO C 90 + A1 and the two TC's

C89 is a local US standard.
I would prefer that it were not so.
Why?
K&R C and C99 are discussed
in this group as well, and if there is a C0X, it will be discussed
here as well.
*sigh* Go to the appropriate places or open one yourself.
I am certainly willing to contribute.

Somehow, "Embedded C" and "C99" evolved without your contribution.

What is "Embedded C" and who developed it?

Regards
Chris
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Michael Mair]

Chris Hills schrieb:

In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes

jacob navia schrieb:

ex**************@gmail.com a écrit :
and seem nostalgic of some mythical past: they endorse the C89
standard (full 17 years ago) and will start getting VERY upset
if any improvement is proposed.
There is C99

C89 still is the C standard effectively used.

You mean ISO C 90 + A1 and the two TC's
C89 is a local US standard.

True; I use C89 synonymously; considering how many people use
"ANSI C" or C89 for "ISO C 90 + AMD1 + TC1 + TC2", I am not too
alone out there :-)
Probably changing this habit is a good idea, though.
I would prefer that it were not so.

Why?

Because I fear that this means that C will not develop any
further:

The C99 (+ TC1 + TC2) extensions to C90 (+ AMD1 + TC1 + TC2)
have not been received well; they are, however, likely to be
part of a new standard.
As C99 is largely ignored[*] in the embedded community
(which often is quite happy with conforming freestanding
implementations plus one or two other goodies[*]) as well as
the target audiences for complex types and better floating
point environment support, no new add-ons are likely to draw
these groups to a new C.
Starting with language subsetting ("I am a happy fun C90
implementation with the following parts of C99 and C0X...")
IMO is the wrong way to go but may be the only way to
interest people who essentially only need and/or want
"C90+something".
Things I personally would like to have, e.g. a compile-time
typeof() for the base types, are not exactly what you may
need for generating customer-accepted C code via a production
code generator (customers probably want explicit "Result:Int32
Par1: Int32 Par2: Int16" macros used because of data flow
analysis) or to make C more interesting for use in numeric
simulation and optimisation projects or ...

If you cannot satisfy a substantial part of the C users by
a new language standard, then the language as a whole may
become less accepted or you effectively will have the
language standard which is used by most people as de facto
language standard version.
[*] This is my perception and may be wrong.

K&R C and C99 are discussed
in this group as well, and if there is a C0X, it will be discussed
here as well.

*sigh* Go to the appropriate places or open one yourself.
I am certainly willing to contribute.

Somehow, "Embedded C" and "C99" evolved without your contribution.

What is "Embedded C" and who developed it?

http://www.embedded-c.org
http://www.open-std.org/jtc1/sc22/wg14/
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Chris Hills]

In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes

Chris Hills schrieb:

In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes

jacob navia schrieb:

ex**************@gmail.com a écrit :
and seem nostalgic of some mythical past: they endorse the C89
standard (full 17 years ago) and will start getting VERY upset
if any improvement is proposed.
There is C99

C89 still is the C standard effectively used.

You mean ISO C 90 + A1 and the two TC's
C89 is a local US standard.

True; I use C89 synonymously; considering how many people use
"ANSI C" or C89 for "ISO C 90 + AMD1 + TC1 + TC2", I am not too
alone out there :-)
Probably changing this habit is a good idea, though.

I would prefer that it were not so.

Why?

Because I fear that this means that C will not develop any
further:

The C99 (+ TC1 + TC2) extensions to C90 (+ AMD1 + TC1 + TC2)
have not been received well; they are, however, likely to be
part of a new standard.
As C99 is largely ignored[*] in the embedded community
(which often is quite happy with conforming freestanding
implementations plus one or two other goodies[*]) as well as
the target audiences for complex types and better floating
point environment support, no new add-ons are likely to draw
these groups to a new C.
Starting with language subsetting ("I am a happy fun C90
implementation with the following parts of C99 and C0X...")
IMO is the wrong way to go but may be the only way to
interest people who essentially only need and/or want
"C90+something".
Things I personally would like to have, e.g. a compile-time
typeof() for the base types, are not exactly what you may
need for generating customer-accepted C code via a production
code generator (customers probably want explicit "Result:Int32
Par1: Int32 Par2: Int16" macros used because of data flow
analysis) or to make C more interesting for use in numeric
simulation and optimisation projects or ...

If you cannot satisfy a substantial part of the C users by
a new language standard, then the language as a whole may
become less accepted or you effectively will have the
language standard which is used by most people as de facto
language standard version.

[*] This is my perception and may be wrong.

Interesting perspective. I agree with a lot of what you say.

K&R C and C99 are discussed
in this group as well, and if there is a C0X, it will be discussed
here as well.

*sigh* Go to the appropriate places or open one yourself.
I am certainly willing to contribute.

Somehow, "Embedded C" and "C99" evolved without your contribution.

What is "Embedded C" and who developed it?

http://www.embedded-c.org
http://www.open-std.org/jtc1/sc22/wg14/

That is NOT "Embedded C"

It is basically a TR for extensions for DSP's I know I had some
(minor) input into it at various WG14 and other meetings.

There is no embedded C as there is EC++ (which was developed outside the
ISO process)

For embedded work most of the world uses MISRA-C. It is also what the
tool vendors support.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Michael Mair]

Chris Hills schrieb:

In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes

Chris Hills schrieb:

In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes <mention of "Embedded C">
What is "Embedded C" and who developed it?
http://www.embedded-c.org
http://www.open-std.org/jtc1/sc22/wg14/

That is NOT "Embedded C"

It is basically a TR for extensions for DSP's I know I had some
(minor) input into it at various WG14 and other meetings.

There is no embedded C as there is EC++ (which was developed outside the
ISO process)

I am aware of the difference between what I called "Embedded C" --
BTW: You can find exactly this TR and articles about it by searching
for "Embedded C" -- and C on embedded systems. I called the thing
by the name by which it was introduced to me (via CUJ, Embedded
Systems and friends).

For embedded work most of the world uses MISRA-C. It is also what the
tool vendors support.

Don't I know it...
Especially Japanese customers ask for MISRA compliance even in
generated code -- and, ideally, always all versions at once.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[websnarf]

jacob navia wrote:

ex**************@gmail.com a écrit :

Is there any group in the manner of the C++ Boost group that works on
the evolution of the C language? Or is there any group that performs an
equivalent function?
I would like that such a group existed but... I have never found one.

Well, there is also no group for discussing the *practice* of C
programming, the implementation of C compilers/libraries, common C
compilers and their extensions, algorithms in C or C variants either.
It is a pity. Most people in this forum, for instance, that I thought
it would be suchg a group, refuse to discuss about any evolution
and seem nostalgic of some mythical past: they endorse the C89
standard (full 17 years ago) and will start getting VERY upset
if any improvement is proposed. Most of them think, as one of them
said:

"C++ is the future, we are just waiting that C programmers die out."
Yes, but there is an inherent contradiction in this. C++ people also
refuse to extend the C-like subset of their language. They do this,
precisely because they incorrectly assume that the C standards
committee will be responsible and improve their standard over time in
all the relevant ways they might need or desire. (I may overstate
this, as the C++ people are very much aware of what a debacle the C99
standard was; at least from their point of view.)

So there is a big opportunity for other languages to step in an simply
deliver greater functionality than both C and C++.

A classic example of this is how Python uses GMP to support long
integers in its language. The key portions of GMP are written in
assembly language that is not generatable by any C compiler and thus
cannot be approached in performance any better than 25%. So while
Python is generally a *much* slower language than C, on the one aspect
of long integer computation portable and standard compliant Python will
embarrass any comparable standard C code in terms of performance that
tries to do that same computation.

The obvious question, then, is why can't C programmer just use GMP?
Well they can, so long as they are not bothered by including lots of
handcrafted assembly in their projects. But there are also issues with
using GMP -- GMP is not thread safe, and does not include some
classical cryptographic functions such as Barret-reduction or
Montgomery-reduction. So there are alternatives, like LibTom and
others with various other kinds of trade offs, but all them achieving
speed through assembly language. I doubt that all of them have been
ported to AMD64, which is clearly going to be the dominant platform
going forward.

Python gets away with using GMP, because its multithreading
implementation is standardized, and is coroutine based (they call them
generators) and is *emulated* rather than relying on system features to
do this. (Python also does not have special support for crypto in its
operators.) So the use of GMP is merely an implementation detail
rather than being an exposed part of their standard.

The sad thing, of course, is that C needs to add one single polymorphic
function or operator (a widening multiply) to the specification to put
an end to all of this. I will make a prediction right now, that such
an operator or function with *NEVER* be added to the C standard. The
standards purveyors simply aren't at the level required, nor are they
focussed enough to realize why this and similar issues are so
important.
This precludes of course any attitude that would discuss the evolution
of the language

Well it ends up promoting really *BAD* evolution, actually. Take TR
24731 for example. This is an extension to C that is supposedly
supposed to make C safer for string manipulation and is likely to
appear in the next standard. It does no such thing, of course (every
failure mode in standard C is direcly mappable to a failure mode using
TR 24731) -- but the standards people, somehow *BELIEVES* that it does.
It seemed promising in the sense that they at least tried something --
but one cannot help but think this is nothing more than a reactionary
move against those decrying against C as a ridiculously unsafe
language. The guilt of knowing that the C standards committee members
are, in essence, coauthors of nearly every single virus and exploit is
probably what caused them to endorse this nonsense. Of course they are
just being tools of a PR maneuver by TR 24731's authors. Most people
in this newsgroup, or anywhere else, probably have no idea what TR
24731 is. That's because there is so little open discussion about the
evolution of C.

One thing we have to ask ourselves -- is it possible to extend C in a
way that general C programmers would have to say to themselves: "I
*need* the new standard, because it will make me a better programmer"?
Look at the C99 standard and as yourself whether it rose to this level.
It clearly did not, and the next standard won't rise to this level
either.

The people in this newsgroup who have imposed their will that this
newgroup simply not discuss this issue are part of the problem of
course. If there is no clear place where the evolution of C can be
discussed, then it won't be, and C will not evolve. Or at least it
will not evolve from a process of open discussion. So people like
Microsoft have no trouble subverting the C standard for their own
purposes, and while system vendors just watch out for their own
self-interest.

Just compare how the proposed changes to the C standard (from C89, or
the new stuff from C99) to the proposals for the next C++ standard.
The next C++ standard is *clearly* going to be a much better language
than its predecessor -- the inclusion of "auto" is a brilliant maneuver
that really puts the question to the dynamic languages that have become
popular lately. I don't know if things are more open in the C++
universe, but clearly they have more activity amongst the creators of
Boost and STL; or maybe Stroustrup is just a brilliant guy. Whatever;
it really underscores how pathetic the C standard is.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Chris Torek]

In article <4b*************@individual.net>
Michael Mair <Mi**********@invalid.invalid> wrote:

As C99 is largely ignored[*] in the embedded community ...
[*] This is my perception and may be wrong.

One data point: Wind River (which sells in the "embedded" market)
is moving towards full C99 support, however slowly. It is at least
a "checkbox item", if not one of the high priority ones.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[jacob navia]

Well Paul, as often, I have to agree with you in most of your analysis.

Just some points:

[snip for brevity]

Take TR
24731 for example. This is an extension to C that is supposedly
supposed to make C safer for string manipulation and is likely to
appear in the next standard. It does no such thing, of course (every
failure mode in standard C is direcly mappable to a failure mode using
TR 24731) -- but the standards people, somehow *BELIEVES* that it does.
It seemed promising in the sense that they at least tried something --
but one cannot help but think this is nothing more than a reactionary
move against those decrying against C as a ridiculously unsafe
language. The guilt of knowing that the C standards committee members
are, in essence, coauthors of nearly every single virus and exploit is
probably what caused them to endorse this nonsense. Of course they are
just being tools of a PR maneuver by TR 24731's authors. Most people
in this newsgroup, or anywhere else, probably have no idea what TR
24731 is. That's because there is so little open discussion about the
evolution of C.
The problem is that instead of getting away from strings as zero
terminated array of characters they STILL hang to it. THEN all functions
must be explicitely be given the length of the strings/buffers/etc even
if it is immediately obvious that the programmer can't know in all cases
what that dammed length is nor should he care!

typedef struct _string {
size_t length;
char *Stringdata
} String;

is too much for the C standards comitee. This structure is split then at
each function call in a data and a length, and it is up to the
programmer to figure out the length without ever making an error.

I have proposed (and implemented) a demonstration how could that be
done. See the string library of lcc-win32.

One thing we have to ask ourselves -- is it possible to extend C in a
way that general C programmers would have to say to themselves: "I
*need* the new standard, because it will make me a better programmer"?
Look at the C99 standard and as yourself whether it rose to this level.
It clearly did not, and the next standard won't rise to this level
either.

Because everyone agrees that C is dead and should NOT be developed any
further. It should be left for embedded systems with small RAM footprint
where C++ can never run.

As the hardware evolves and even small gadgets feature megabytes of RAM
those niche applications will be more and more difficult to find.

The people in this newsgroup who have imposed their will that this
newgroup simply not discuss this issue are part of the problem of
course.
Of course, but they willl not agree with this, obviously. They are still
in C89 and the few points that C99 brought in the sense of a better
language are just denied. Each time I remind people about them, they
tell me that "not all compilers support C99" what is true but doesn't
make things advance at all.

If there is no clear place where the evolution of C can be discussed, then it won't be, and C will not evolve.
Yes, and that is why I still try to discuss serious perspectives in this
group. Maybe because lcc-win32 is the only compiler system that is
centered around C and it is not just a C++ compiler that can also do
some C compilations.

Or is maybe that the reason for the aggressivity the "OFF TOPIC"
discussions are led?

Or at least it will not evolve from a process of open discussion. So people like
Microsoft have no trouble subverting the C standard for their own
purposes, and while system vendors just watch out for their own
self-interest.

Just compare how the proposed changes to the C standard (from C89, or
the new stuff from C99) to the proposals for the next C++ standard.
The next C++ standard is *clearly* going to be a much better language
than its predecessor -- the inclusion of "auto" is a brilliant maneuver
that really puts the question to the dynamic languages that have become
popular lately. I don't know if things are more open in the C++
universe, but clearly they have more activity amongst the creators of
Boost and STL; or maybe Stroustrup is just a brilliant guy. Whatever;
it really underscores how pathetic the C standard is.

Yes, but the problem is that in the C standards comitee most people care
much more about C++ than C. There is no compiler for C today. All are
C++ compilers that can do C as an after thought. Gcc has implemented
most of the standard but still never makes it to finish it.

Microsoft doesn't care at all, and pursues its own standards through the
windows platform, where it can dictate whatever it wishes.

Apple has got objective C, and sticks to it.

-------------------------

Still, C has a big potential of growth with some minor additions like
operator overloading, something that is accepted by more conservative
languages like fortran for instance.

This small change would make possible to write good string libraries,
good numerical libraries, etc.

Another feature is the overloaded functions feature that could allow a
limited amount of generic programming.

And that is all. Small but essential changes that would make C a very
good language without loosing the simplicity, what is its greatest
asset. The problem of C++'s complexity is known. C with those minor
modifications would be a very useful language.

jacob

[jacob navia]

Chris Torek a écrit :

In article <4b*************@individual.net>
Michael Mair <Mi**********@invalid.invalid> wrote:

As C99 is largely ignored[*] in the embedded community ...
[*] This is my perception and may be wrong.

One data point: Wind River (which sells in the "embedded" market)
is moving towards full C99 support, however slowly. It is at least
a "checkbox item", if not one of the high priority ones.

OFF TOPIC

Each day I see the new images of Mars sent by two rovers running
VxWorks. It is more than two (earth) years that those systems are
roaming around in the surface of Mars.

Good work guys!

[Keith Thompson]

we******@gmail.com writes:
[...]

The people in this newsgroup who have imposed their will that this
newgroup simply not discuss this issue are part of the problem of
course. If there is no clear place where the evolution of C can be
discussed, then it won't be, and C will not evolve.

[...]

There is. It's called comp.std.c.

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

[jacob navia]

Keith Thompson a écrit :

we******@gmail.com writes:
[...]

The people in this newsgroup who have imposed their will that this
newgroup simply not discuss this issue are part of the problem of
course. If there is no clear place where the evolution of C can be
discussed, then it won't be, and C will not evolve.

[...]

There is. It's called comp.std.c.

No, it can't be discussed there. Standards comitees do not try to
advance the language but to standardize existing practice.

jacob

[Ian Collins]

jacob navia wrote:

Because everyone agrees that C is dead and should NOT be developed any
further. It should be left for embedded systems with small RAM footprint
where C++ can never run.
C isn't dead, it's mature, there is a difference.

Still, C has a big potential of growth with some minor additions like
operator overloading, something that is accepted by more conservative
languages like fortran for instance.
If you want overloading, use C++.
This small change would make possible to write good string libraries,
good numerical libraries, etc.

Another feature is the overloaded functions feature that could allow a
limited amount of generic programming.
Same here, these features exist elsewhere, if you want them, go there.
And that is all. Small but essential changes that would make C a very
good language without loosing the simplicity, what is its greatest
asset. The problem of C++'s complexity is known. C with those minor
modifications would be a very useful language.

It already exists, but it isn't called C.

--
Ian Collins.

[Michael Mair]

Chris Torek schrieb:

In article <4b*************@individual.net>
Michael Mair <Mi**********@invalid.invalid> wrote:

As C99 is largely ignored[*] in the embedded community ...
[*] This is my perception and may be wrong.

One data point: Wind River (which sells in the "embedded" market)
is moving towards full C99 support, however slowly. It is at least
a "checkbox item", if not one of the high priority ones.

I am looking forward to the discussions at my working place ;-)
("You see? _They_ started it. Now we should think about moving
in this direction...")
Is there any date by which Wind River wants to have arrived at
full C99 support?

Best regards
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[jacob navia]

Ian Collins a écrit :

jacob navia wrote:

Because everyone agrees that C is dead and should NOT be developed any
further. It should be left for embedded systems with small RAM footprint
where C++ can never run.

C isn't dead, it's mature, there is a difference.

Still, C has a big potential of growth with some minor additions like
operator overloading, something that is accepted by more conservative
languages like fortran for instance.

If you want overloading, use C++.

Why?

Why should I swallow that big fat language?

I just want a few specific features that are part of many programming
languages, from fortran to visual basic...

Operator overloading is a well known technique, no need to swallow
all C++ to get it. Thank you

This small change would make possible to write good string libraries,
good numerical libraries, etc.

Another feature is the overloaded functions feature that could allow a
limited amount of generic programming.

Same here, these features exist elsewhere, if you want them, go there.

Same thing. Why take all that machinery when it is not needed?
The problem with ultra FAT languages like C++ is their incredible
complexity!

Constructors and destructors?

Who needs them?

Just get a sensible garbage collector and be done with the need for them.

Object oriented programming can be nice in *some* situations but why
should it be FORCED into everyone?

[Ian Collins]

jacob navia wrote:

Ian Collins a écrit :

Still, C has a big potential of growth with some minor additions like
operator overloading, something that is accepted by more conservative
languages like fortran for instance.

If you want overloading, use C++.

Why?

Because it offers what you are looking for.
Why should I swallow that big fat language?

I just want a few specific features that are part of many programming
languages, from fortran to visual basic...

Operator overloading is a well known technique, no need to swallow
all C++ to get it. Thank you
If you want a chop do you eat the entire pig? Just use the bits you
want and ignore the rest.

Another feature is the overloaded functions feature that could allow a
limited amount of generic programming.

Same here, these features exist elsewhere, if you want them, go there.

Same thing. Why take all that machinery when it is not needed?
The problem with ultra FAT languages like C++ is their incredible
complexity!

Which you don't have to use.
Constructors and destructors?

Who needs them?
Do I detect a rant? Obviously you don't require them, so don't use them.
Object oriented programming can be nice in *some* situations but why
should it be FORCED into everyone?

Who said anything about OO? The subject was function and operator
overloading, which is a complexity C can do without, but other languages
offer.

--
Ian Collins.

[websnarf]

Keith Thompson wrote:

we******@gmail.com writes:
[...]

The people in this newsgroup who have imposed their will that this
newgroup simply not discuss this issue are part of the problem of
course. If there is no clear place where the evolution of C can be
discussed, then it won't be, and C will not evolve.

[...]

There is. It's called comp.std.c.

I and well known security expert tried to discuss TR 24731 there. Its
no use. That laughable embarassment is almost certainly going to be
included in the next C standard. The people in that newsgroup, some of
whom are presumably standards people are irrationally obstinant about
their positions. I mean, I was "wrong" because I didn't put together a
counter proposal to TR 24731 and Microsoft did (even if I did, I'm not
sure if that's what it takes to *delete* a proposal by a highly funded
contributor ...). So they are "right" because they happened to put
effort (read: money) into it.

I also lurked for a while and saw one of the regulars bite the head off
of a technical suggestion to clarify the description of one of the
functions -- objectively speaking this change is required, since the
current language technically allows for things clearly not intended. I
mean what the hell is that? Is there no concern for technical
excellence? Perhaps they are worried that producing the documentation
to make this change would take too much time (i.e., a cost that nobody
was volunteering to pick up.)

It seems to me that that group is all about weeding and filtering
people out. Perhaps, if I got myself hired at a system vendor and flew
half way around the world to their meetings, or something like that
maybe they might listen to me. But I don't even have a *stake* in this
-- *I* can program high performance bignums, multithreading, pool based
self-checking heaps, graphics, device drivers and safe strings without
the standard's help. So they undermine themselves because they cannot
be receptive to my comments, because I am unwilling to jump through
their hoops to make them listen (just posting doesn't count.)

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Chris Hills]

In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes

Chris Hills schrieb:

In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes

Chris Hills schrieb:

In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes<mention of "Embedded C">
What is "Embedded C" and who developed it?

http://www.embedded-c.org
http://www.open-std.org/jtc1/sc22/wg14/
That is NOT "Embedded C"

It is basically a TR for extensions for DSP's I know I had some
(minor) input into it at various WG14 and other meetings.

There is no embedded C as there is EC++ (which was developed outside the
ISO process)

I am aware of the difference between what I called "Embedded C" --
BTW: You can find exactly this TR

I have the TR and some of the drafts.
and articles about it by searching
for "Embedded C" -- and C on embedded systems. I called the thing
by the name by which it was introduced to me (via CUJ, Embedded
Systems and friends).

For embedded work most of the world uses MISRA-C. It is also what the
tool vendors support.

Don't I know it...
Especially Japanese customers ask for MISRA compliance even in
generated code -- and, ideally, always all versions at once.

There are only 2 versions. You can not comply with both at once.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Torek]

In article <4b*************@individual.net>
Michael Mair <Mi**********@invalid.invalid> wrote:

I am looking forward to the discussions at my working place ;-)
("You see? _They_ started it. Now we should think about moving
in this direction...")
Is there any date by which Wind River wants to have arrived at
full C99 support?

Nobody ever tells me that sort of thing. :-)

We have two compilers, though: Diab and GCC. GCC supports "whatever
GCC supports"; Diab's C99 is "getting closer but still not all that
close" as far as I know ("restrict" support just went in recently,
for instance). The RTP libraries in 6.x are from Dinkumware and
should be fully C99, to whatever extent the C compilers get C99
right.

(I do not work on either the compilers or the libraries, except to
whatever extent we run into problems with I/O, including 64-bit
file sizes and such.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[extrudedaluminiu]

One of the very best things that the original ANSI-ification of C did
was to write a standard that described a language that was in use, as
opposed to legislating a language from on high. That process should be
a model for all standardization attempts, everywhere - too many other
standardization processes attempt to go an invent something completely
new, which leads to standards that don't parallel reality.

Now, where did those features and ideas that came into common use after
K&R's first book was published come from? It seems that they just
popped up in compilers, everybody started using them, and so they made
sense to standardize.

These days, what groups are testing/working on new features or
extensions to the language? Comp.std.c is a great place for discussing
the current C language standards, but the C tradition seems to have new
features coming from places other than high committees.

I don't know what features would be great to have in the C of 2010 -
maybe a more powerful strings toolkit, maybe a collection of data
structures, maybe even quadragraphs. Who knows? But what is important
that someone is considering these things and asking these questions.
The Boost group seems to be doing that for C++; who is doing it here?

[Andrew Poelstra]

ex**************@gmail.com wrote:

One of the very best things that the original ANSI-ification of C did
was to write a standard that described a language that was in use, as
opposed to legislating a language from on high. That process should be
a model for all standardization attempts, everywhere - too many other
standardization processes attempt to go an invent something completely
new, which leads to standards that don't parallel reality.

Now, where did those features and ideas that came into common use after
K&R's first book was published come from? It seems that they just
popped up in compilers, everybody started using them, and so they made
sense to standardize.

These days, what groups are testing/working on new features or
extensions to the language? Comp.std.c is a great place for discussing
the current C language standards, but the C tradition seems to have new
features coming from places other than high committees.

I don't know what features would be great to have in the C of 2010 -
maybe a more powerful strings toolkit, maybe a collection of data
structures, maybe even quadragraphs. Who knows? But what is important
that someone is considering these things and asking these questions.
The Boost group seems to be doing that for C++; who is doing it here?

Quite frankly, a lot of us are happy with the C of 1980. In terms of
forward-looking features, C++ seems the place to go, since C itself will
(should) never use the object-oriented paradigm.

Try posting some ideas in comp.std.c; see for yourself what reaction
you'll get.
--
"Every prime number in a series as a joke
Made all the patterns clear when I took that final toke"
- - Andrew Poelstra <http://www.wpsoftware.net/blog>

[extrudedaluminiu]

The greatest strength of C I've seen is not the fact that it can run on
small machines (even though this is nice). The greatest strength is how
simply and cleanly we can construct arbitrary data structures in C. It
is very often clear how to construct whatever structure is desired, be
it a simple linked list or something like VLists. This is because there
are no artificial binds on how you can use/abuse memory.

In terms of forward-looking features, C++ seems the place to go, since C itself will (should) never use the object-oriented paradigm.

Not all forward-looking features are object-oriented. Take for example
gcc's nested functions or Java's for-each loops. Or glib's set of data
structures. And there are no reasons why C89 can't be used to write
clean OO code, should you want to write OO code.

Stuff I'd like to see? I'd love to have a small set of portable data
structures - cons cells, lists, arrays. I'd also love to have Java's
for-each loop and Lisp's defstruct. But I'm hardly qualified to know
what is worth suggesting.

What I don't think should be the case is that the future of C be
dictated by only what extensions compilers come up with. Instead I
think that it'd be nice to have a high-quality set of libraries (a la
Boost), developed by a group for the purpose of asking questions about
the future of C, that offer innovative features. Maybe 99% of these new
features fail the test of general approval. That 1% that makes it
through would be worth it.

[Ian Collins]

ex**************@gmail.com wrote:

The greatest strength of C I've seen is not the fact that it can run on
small machines (even though this is nice). The greatest strength is how
simply and cleanly we can construct arbitrary data structures in C. It
is very often clear how to construct whatever structure is desired, be
it a simple linked list or something like VLists. This is because there
are no artificial binds on how you can use/abuse memory.
I agree, a bit of therapeutic C is a good thing after a solid week of
scripting language programming :)

In terms of forward-looking features, C++ seems the place to go, since C itself will (should) never use the object-oriented paradigm.

Not all forward-looking features are object-oriented. Take for example
gcc's nested functions or Java's for-each loops. Or glib's set of data
structures. And there are no reasons why C89 can't be used to write
clean OO code, should you want to write OO code.

Conversely, not all C++ features are OO. The standard library is
anything but. So one can write clean procedural code in C++.
Stuff I'd like to see? I'd love to have a small set of portable data
structures - cons cells, lists, arrays. I'd also love to have Java's
for-each loop and Lisp's defstruct. But I'm hardly qualified to know
what is worth suggesting.
There are two subsets of wishes there, standard library extensions and
language extensions.
What I don't think should be the case is that the future of C be
dictated by only what extensions compilers come up with. Instead I
think that it'd be nice to have a high-quality set of libraries (a la
Boost), developed by a group for the purpose of asking questions about
the future of C, that offer innovative features. Maybe 99% of these new
features fail the test of general approval. That 1% that makes it
through would be worth it.

Again, consider the distinction between libraries and language features.
Boot is dedicated to the former, using the standard language as its base.

I think C would benefit form an active library group which, like boot
had members of the standard's library subcommittee as active
participants.

C is probably one of the only mainstream programming languages that
lacks an evolving library. Maybe C programmers just enjoy reinventing
wheels, if you don't believe me, look back though this group at all the
linked list problem posts.

--
Ian Collins.

[Rouben Rostamian]

In article <4b************@individual.net>,
Ian Collins <ia******@hotmail.com> wrote:

I think C would benefit form an active library group which, like boot
had members of the standard's library subcommittee as active
participants.

C is probably one of the only mainstream programming languages that
lacks an evolving library. Maybe C programmers just enjoy reinventing
wheels, if you don't believe me, look back though this group at all the
linked list problem posts.

An attempt toward creating a set of library tools was made
by some participants of this newsgroup a few years ago but
it fell by the wayside. See:

http://libclc.sourceforge.net/

The failure of libclc to take root is not surprising.
Minimalism has been a characteristic of C from the very
beginning. Practitioners of C tend to like that aspect of the
language otherwise they would be programming in something else.
It's no wonder that attempts to burden the language with
additional constructs/libraries/extensions have met with
resistance. The lukewarm reception of C99 is symptomatic of
that view.

--
Rouben Rostamian

[Andrew Poelstra]

Andrew Poelstra wrote:

ex**************@gmail.com wrote:

One of the very best things that the original ANSI-ification of C did
was to write a standard that described a language that was in use, as
opposed to legislating a language from on high. That process should be
a model for all standardization attempts, everywhere - too many other
standardization processes attempt to go an invent something completely
new, which leads to standards that don't parallel reality.

Now, where did those features and ideas that came into common use after
K&R's first book was published come from? It seems that they just
popped up in compilers, everybody started using them, and so they made
sense to standardize.

These days, what groups are testing/working on new features or
extensions to the language? Comp.std.c is a great place for discussing
the current C language standards, but the C tradition seems to have new
features coming from places other than high committees.

I don't know what features would be great to have in the C of 2010 -
maybe a more powerful strings toolkit, maybe a collection of data
structures, maybe even quadragraphs. Who knows? But what is important
that someone is considering these things and asking these questions.
The Boost group seems to be doing that for C++; who is doing it here?

Quite frankly, a lot of us are happy with the C of 1980. In terms of
forward-looking features, C++ seems the place to go, since C itself will
(should) never use the object-oriented paradigm.

Try posting some ideas in comp.std.c; see for yourself what reaction
you'll get.

Oops! I meant 1989... or whenever C89 was finalized.

--
"Every prime number in a series as a joke
Made all the patterns clear when I took that final toke"
- - Andrew Poelstra <http://www.wpsoftware.net/blog>

[Ian Collins]

Andrew Poelstra wrote:

Andrew Poelstra wrote:

Quite frankly, a lot of us are happy with the C of 1980. In terms of
forward-looking features, C++ seems the place to go, since C itself
will (should) never use the object-oriented paradigm.

Try posting some ideas in comp.std.c; see for yourself what reaction
you'll get.

Oops! I meant 1989... or whenever C89 was finalized.

I wasn't surprised by your original post, I've known C programmers who
scoffed at those mod-fangled prototypes :)

--
Ian Collins.

[websnarf]

ex**************@gmail.com wrote:

One of the very best things that the original ANSI-ification of C did
was to write a standard that described a language that was in use, as
opposed to legislating a language from on high. That process should be
a model for all standardization attempts, everywhere - too many other
standardization processes attempt to go an invent something completely
new, which leads to standards that don't parallel reality.
What? This is a very narrow and unbalanced view of the standard.

ANSI pulled together the largest common subset of all the incompatible
C's out there, then made a few tough choices, and in fact with C89
discarded the original K&R prototypes and other nonsense to make it a
practically useable language that compiler implementers could resonably
support.

The *PROBLEM* is that they did absolutely nothing outside of those
confines with C99 -- so why has C99 been such an utter failure? Didn't
they follow this supposed perfect recipe for standards?

The primary reason for the success of any standard is that it delivers
*REAL VALUE* that wasn't there before. In 1989, some degree of
unification (so that programmer skills became transferrable) was
extremely valuable (read: 100s of billions of dollars kind of
valuable). In 1999 we already *had* a unified standard, so what did
they add that had any real value? The rate of adoption, its actual
usage, and the culture that followed it tells us exactly: nothing.

Standards, where they just pushed forward with "ideas from on high"
include C++ and Java, which as far as I can tell are quite successful
and have plenty of buy in.
Now, where did those features and ideas that came into common use after
K&R's first book was published come from? It seems that they just
popped up in compilers, everybody started using them, and so they made
sense to standardize.

These days, what groups are testing/working on new features or
extensions to the language? Comp.std.c is a great place for discussing
the current C language standards, but the C tradition seems to have new
features coming from places other than high committees.

I don't know what features would be great to have in the C of 2010 -
I do, but I don't seem to have the right credo for anyone to care.
maybe a more powerful strings toolkit,
*Sigh* ...
[...] maybe a collection of data structures,
Ask the libclc people, how their project turned out. Actually the
SGLIB at least took a reasonable crack at it. Even the Boost people
started by writing C extensions.
[...] maybe even quadragraphs. Who knows? But what is important
that someone is considering these things and asking these questions.
And as Jacob Navia says, if they bring it here, they get shot down.
comp.std.c is not much better.

I have at various times posted about possible extensions I would like
to see -- the amazing negative reactions I get are just indescribably
disappointing. People don't care about the practice of programming
anymore, and they don't care about the capabilities of hardware they
paid good money for. And the idea of actually *taking something out*
of the language; that's just sacred ground that couldn't possibly be up
for discussion.
The Boost group seems to be doing that for C++; who is doing it here?

*Sigh* ...

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Michael Mair]

Chris Hills schrieb:

In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes

Chris Hills schrieb:

For embedded work most of the world uses MISRA-C. It is also what the
tool vendors support.

Don't I know it...
Especially Japanese customers ask for MISRA compliance even in
generated code -- and, ideally, always all versions at once.

There are only 2 versions. You can not comply with both at once.

I know ;-)
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Keith Thompson]

we******@gmail.com writes:
[...]

ANSI pulled together the largest common subset of all the incompatible
C's out there, then made a few tough choices, and in fact with C89
discarded the original K&R prototypes and other nonsense to make it a
practically useable language that compiler implementers could resonably
support.

[...]

What "original K&R prototypes" are you talking about?

K&R1 didn't have anything called "prototypes". It did have an older
style of function declarations:

int main(argc, argv)
int argc;
char **argv;
{
...
}

but that's still supported in both C90 and C99.

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

[jacob navia]

Ian Collins a écrit :

jacob navia wrote:

Ian Collins a écrit :

Still, C has a big potential of growth with some minor additions like
operator overloading, something that is accepted by more conservative
languages like fortran for instance.
If you want overloading, use C++.

Why?

Because it offers what you are looking for.

Why should I swallow that big fat language?

I just want a few specific features that are part of many programming
languages, from fortran to visual basic...

Operator overloading is a well known technique, no need to swallow
all C++ to get it. Thank you

If you want a chop do you eat the entire pig? Just use the bits you
want and ignore the rest.

This is not possible. For some operators, C++ decides that they
need to be defined only within a class, and there you are. You are
forced to define classes, constructors, destructors, copy constructors,
and all the stuff.

Besides, there are things that the C++ operator overloading
implementation gets wrong:

1) There is no overloading possible for higher dimensional arrays

array[2][3] is just impossible using overloaded operators.

2) There is no way to distinguish between assignment and reading when
accessing an array. This is specially important when you want to
implement read only data areas.

[jacob navia]

Keith Thompson a écrit :

we******@gmail.com writes:
[...]

ANSI pulled together the largest common subset of all the incompatible
C's out there, then made a few tough choices, and in fact with C89
discarded the original K&R prototypes and other nonsense to make it a
practically useable language that compiler implementers could resonably
support.

[...]

What "original K&R prototypes" are you talking about?

K&R1 didn't have anything called "prototypes". It did have an older
style of function declarations:

int main(argc, argv)
int argc;
char **argv;
{
...
}

but that's still supported in both C90 and C99.

If sizeof(int) == 16 and sizeof(void *) == 32 you needed to declare:

extern char *fn();

before you used it, if not, wrong code would be generated since an int
returning function would be assumed

jacob

[Ian Collins]

jacob navia wrote:

Ian Collins a écrit :

jacob navia wrote:

Why should I swallow that big fat language?

I just want a few specific features that are part of many programming
languages, from fortran to visual basic...

Operator overloading is a well known technique, no need to swallow
all C++ to get it. Thank you

If you want a chop do you eat the entire pig? Just use the bits you
want and ignore the rest.

This is not possible. For some operators, C++ decides that they
need to be defined only within a class, and there you are. You are
forced to define classes, constructors, destructors, copy constructors,
and all the stuff.

That's because they only make sense in the context of an object, you
have to (for example) add something to something else. The are no
restrictions on function overloading. You could use a simple struct.
Besides, there are things that the C++ operator overloading
implementation gets wrong:

1) There is no overloading possible for higher dimensional arrays

array[2][3] is just impossible using overloaded operators.
Indeed.
2) There is no way to distinguish between assignment and reading when
accessing an array. This is specially important when you want to
implement read only data areas.

There is a very simple technique known as proxy objects to solve this
problem, but that's a bit to OT for this forum.

--
Ian Collins.

[Chris Hills]

In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes

Chris Hills schrieb:

In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes

Chris Hills schrieb:
For embedded work most of the world uses MISRA-C. It is also what the
tool vendors support.

Don't I know it...
Especially Japanese customers ask for MISRA compliance even in
generated code -- and, ideally, always all versions at once.

There are only 2 versions. You can not comply with both at once.

I know ;-)

In any event "compliance" is anything you want as there is no official
certification or compliance testing for MISRA-C. Just like most C
compilers claim to be "ANSI C" or "ISO C".

However there will be an example suite for MISRS-C2 by the end of the
year. It will not be exhaustive so I expect it to grow over the next
couple of years.

Hopefully as MISRA-C3 is developed the example suite will be developed
with it and launched at the same time..

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[jacob navia]

Ian Collins a écrit :

jacob navia wrote:

Ian Collins a écrit :

jacob navia wrote:
Why should I swallow that big fat language?

I just want a few specific features that are part of many programming
languages, from fortran to visual basic...

Operator overloading is a well known technique, no need to swallow
all C++ to get it. Thank you
If you want a chop do you eat the entire pig? Just use the bits you
want and ignore the rest.

This is not possible. For some operators, C++ decides that they
need to be defined only within a class, and there you are. You are
forced to define classes, constructors, destructors, copy constructors,
and all the stuff.

That's because they only make sense in the context of an object, you
have to (for example) add something to something else. The are no
restrictions on function overloading. You could use a simple struct.

well, that's my point. In C++ I czan't avoid classes, constructors,
destructors and the whole complexity, even if I want to use a simple
thing like

typef struct __int128 { int32_t part1,part2,part3,part4} INT128;
INT128 operator+(INT128 *a,INT128 *b)
{
....
}

INT128 operator+(INT128 *a,long long b)
{
....
}

Besides, there are things that the C++ operator overloading
implementation gets wrong:

1) There is no overloading possible for higher dimensional arrays

array[2][3] is just impossible using overloaded operators.

Indeed.

It should be possible to do, I mean higher dimensional arrays are not
something new...

2) There is no way to distinguish between assignment and reading when
accessing an array. This is specially important when you want to
implement read only data areas.

There is a very simple technique known as proxy objects to solve this
problem, but that's a bit to OT for this forum.

No, it is not OT because that confirms what I said:

You can't just take a small piece. YOU GET THE HOLE PIG AT EACH SERVING!

:-)
jacob

[Bill Pursell]

jacob navia wrote:
<snip>

If there is no clear place where the evolution of C can be
discussed, then it won't be, and C will not evolve. <snip>
Still, C has a big potential of growth with some minor additions like
operator overloading, something that is accepted by more conservative
languages like fortran for instance.

Operator overloading is, IMHO, a really, really bad idea. I've only
been coding C for just under a year, and 11 months ago I was really
bent out of shape that I couldn't write:
struct foo A,B,C;
A = B + C;
but I'm really glad now that I can't, and I would hate to see operater
overloading be expanded in C. Operator overloading in C is the root
cause of a very large number of bugs already. How many bugs are a
result of "3+4" being different that "3.0 + 4.0"? Those bugs would
have been avoided had the programmer been required to type
"int_add(3,4)" or "float_add(3,4)". Now, I'm not arguing that the '+'
symbol be dropped for arithmetic on basic numeric types, but expanding
the language to allow '+' as an infix operator on user-defined structs
is just asking for trouble. The only gain is (arguably) cleaner code,
but quite frankly "A = foo_add(B,C)" is more informative than "A =
B+C" and less prone to error.

[Ian Collins]

jacob navia wrote:

well, that's my point. In C++ I czan't avoid classes, constructors,
destructors and the whole complexity, even if I want to use a simple
thing like

typef struct __int128 { int32_t part1,part2,part3,part4} INT128;
INT128 operator+(INT128 *a,INT128 *b)
{
....
}

INT128 operator+(INT128 *a,long long b)
{
....
}

struct int128_t { int32_t part1,part2,part3,part4 };

Other than that correction and the operator bodies, you've written all
you have to write.

2) There is no way to distinguish between assignment and reading when
accessing an array. This is specially important when you want to
implement read only data areas.

There is a very simple technique known as proxy objects to solve this
problem, but that's a bit to OT for this forum.

No, it is not OT because that confirms what I said:

You can't just take a small piece. YOU GET THE HOLE PIG AT EACH SERVING!

No, how would you differentiate between read and write to an array in C?

If you want the extra fat, you pay for it, if you don't, you don't.

It's a popular misconception that C++ has to be more complex than C. It
doesn't.

--
Ian Collins.

[jacob navia]

Bill Pursell a écrit :

jacob navia wrote:
<snip>

Still, C has a big potential of growth with some minor additions like
operator overloading, something that is accepted by more conservative
languages like fortran for instance.
Operator overloading is, IMHO, a really, really bad idea. I've only
been coding C for just under a year, and 11 months ago I was really
bent out of shape that I couldn't write:
struct foo A,B,C;
A = B + C;
but I'm really glad now that I can't, and I would hate to see operater
overloading be expanded in C. Operator overloading in C is the root
cause of a very large number of bugs already. How many bugs are a
result of "3+4" being different that "3.0 + 4.0"?

Sorry but 3+4 is identical to 3.0+4.0 : SEVEN in BOTH cases, only the
representtion of the number changes.

Maybe you meant 3/4 and 3.0/4.0 ???
Those bugs would
have been avoided had the programmer been required to type
"int_add(3,4)" or "float_add(3,4)".
Aaaahhh what an easy syntax...

What would you do with

z = sqrt((a+b)/(b-d) +0.5*d/(a*d-b*d);

???????

Yes, you have to COMPILE THEM by hand producing this incredible GIBBERISH!

tmp1=float_add(a,b);
tmp2=float_sub(b,d);
tmp3=float_div(tmp1,tmp2);
tmp4=float_mul(0.5,d);
tmp5=float_mul(a,d);
tmp6=float_mul(b,d);
tmp7=float_sub(tmp5,tmp6);
tmp8=float_div(tmp4,tmp7);
tmp9=float_add(tmp3,tmp8);
z=sqrt(tmp9);
IF you manage to compile that expression without making ANY MISTAKE.
That is MUCH MORE ERROR PRONE THAN

z = sqrt((a+b)/(b-d) +0.5*d/(a*d-b*d);
Besides there isn't a single maintenance programmer that can understand
that GIBBERISH without decompiling it (by hand) into
z = sqrt((a+b)/(b-d) +0.5*d/(a*d-b*d)
again!

And if you change the type of the data from float to long double you
have to edit all those function calls!

Now, I'm not arguing that the '+'
symbol be dropped for arithmetic on basic numeric types, but expanding
the language to allow '+' as an infix operator on user-defined structs
is just asking for trouble. The only gain is (arguably) cleaner code,
but quite frankly "A = foo_add(B,C)" is more informative than "A =
B+C" and less prone to error.

You are dreaming. LESS PRONE TO ERROR??????????

[jacob navia]

Ian Collins a écrit :

No, how would you differentiate between read and write to an array in C?

lcc-win32 proposes the [] operator for reading, and the []= for assignment

[Ian Collins]

jacob navia wrote:

Ian Collins a écrit :

No, how would you differentiate between read and write to an array in C?

lcc-win32 proposes the [] operator for reading, and the []= for assignment

Fine, but how would you do it in standard C?

--
Ian Collins.

[Ian Collins]

Bill Pursell wrote:

Now, I'm not arguing that the '+'
symbol be dropped for arithmetic on basic numeric types, but expanding
the language to allow '+' as an infix operator on user-defined structs
is just asking for trouble. The only gain is (arguably) cleaner code,
but quite frankly "A = foo_add(B,C)" is more informative than "A =
B+C" and less prone to error.

I think Jacob's example applies equally well to this case.

You end up with the same mess that Java has to put up with.

Operator overloading enables you to use a user defined type in the same
way as a built in type. Much more intuitive.

--
Ian Collins.

[Michael Mair]

Chris Hills schrieb:

In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes

Chris Hills schrieb:

In article <4b*************@individual.net>, Michael Mair
<Mi**********@invalid.invalid> writes

Chris Hills schrieb:

>For embedded work most of the world uses MISRA-C. It is also what the
>tool vendors support.

Don't I know it...
Especially Japanese customers ask for MISRA compliance even in
generated code -- and, ideally, always all versions at once.

There are only 2 versions. You can not comply with both at once.
I know ;-)

In any event "compliance" is anything you want as there is no official
certification or compliance testing for MISRA-C. Just like most C
compilers claim to be "ANSI C" or "ISO C".

There are "MISRA checkers", though, and I remember having seen
the option to activate MISRA-C checks in some lint tool, probably
PCLint.

However there will be an example suite for MISRS-C2 by the end of the
year. It will not be exhaustive so I expect it to grow over the next
couple of years.
Thank you for the information.

Hopefully as MISRA-C3 is developed the example suite will be developed
with it and launched at the same time..

This sounds promising -- I only can recommend this course of action;
the time and money usually are well invested.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Bill Pursell]

jacob navia wrote:

Bill Pursell a écrit :

jacob navia wrote:
<snip>

Still, C has a big potential of growth with some minor additions like
operator overloading, something that is accepted by more conservative
languages like fortran for instance.
Operator overloading is, IMHO, a really, really bad idea. I've only
been coding C for just under a year, and 11 months ago I was really
bent out of shape that I couldn't write:
struct foo A,B,C;
A = B + C;
but I'm really glad now that I can't, and I would hate to see operater
overloading be expanded in C. Operator overloading in C is the root
cause of a very large number of bugs already. How many bugs are a
result of "3+4" being different that "3.0 + 4.0"?

Sorry but 3+4 is identical to 3.0+4.0 : SEVEN in BOTH cases, only the
representtion of the number changes.

The representation is often significant, and my point is that
overloading the '+' operator obscures that detail from the programmer.

Maybe you meant 3/4 and 3.0/4.0 ???
No. I meant '+'.

Those bugs would
have been avoided had the programmer been required to type
"int_add(3,4)" or "float_add(3,4)".

Aaaahhh what an easy syntax...

What would you do with
z = sqrt((a+b)/(b-d) +0.5*d/(a*d-b*d);

As I said, I'm not suggesting that the basic arithmetic operators be
removed from the language, and this is an excellent example of their
utility. Can you come up with a similar example that doesn't rely on
fundamental types? I've never seen an object in any language that was
prone to this type of calculation, and certainly never seen a structure
in a C program to which this would apply. Any such calculation should
be performed by a function anyway, so rather than forcing the
maintenance programmer to parse:
z = sqrt((a+b)/(b-d) +0.5*d/(a*d-b*d);
that same programmer would have to parse:
z = determinant( A);
or the like.
Yes, you have to COMPILE THEM by hand producing this incredible GIBBERISH!

tmp1=float_add(a,b);
tmp2=float_sub(b,d);
tmp3=float_div(tmp1,tmp2);
tmp4=float_mul(0.5,d);
tmp5=float_mul(a,d);
tmp6=float_mul(b,d);
tmp7=float_sub(tmp5,tmp6);
tmp8=float_div(tmp4,tmp7);
tmp9=float_add(tmp3,tmp8);
z=sqrt(tmp9);
Which would be implemented as an appropriately named function.

<snip> And if you change the type of the data from float to long double you
have to edit all those function calls!
And since you've encapsulated the computation in a function, you now
only have to change the definition of that one function. If you had
overloaded the operators, you would have to change the definition of
the overloaded function, so you've gained nothing.

Now, I'm not arguing that the '+'
symbol be dropped for arithmetic on basic numeric types, but expanding
the language to allow '+' as an infix operator on user-defined structs
is just asking for trouble. The only gain is (arguably) cleaner code,
but quite frankly "A = foo_add(B,C)" is more informative than "A =
B+C" and less prone to error.

You are dreaming. LESS PRONE TO ERROR??????????

Yes. Less prone to error, because things are explicit. You choose to
code in a language because you are making a decision about what aspects
of the system you want hidden, and what aspects you want explicit. In
C (in my opinion), this is precisely the type of detail that should not
be hidden. Function overloading is really nice, it's very handy, and
most of the time I really like it. I just don't think it belongs in C.
And I'm far more likely to change my mind if you don't shout. :)

[Bill Pursell]

Ian Collins wrote:

Bill Pursell wrote:

Now, I'm not arguing that the '+'
symbol be dropped for arithmetic on basic numeric types, but expanding
the language to allow '+' as an infix operator on user-defined structs
is just asking for trouble. The only gain is (arguably) cleaner code,
but quite frankly "A = foo_add(B,C)" is more informative than "A =
B+C" and less prone to error.
I think Jacob's example applies equally well to this case.

You end up with the same mess that Java has to put up with.

I'm not familiar with Java.
Operator overloading enables you to use a user defined type in the same
way as a built in type. Much more intuitive.

I'm not convinced that it provides added intuition. As I pointed out
in my response to Jacob, any sufficiently complex computation should
have a function to perform it. If foo represents a mathematical object
and we want to perform some computation on it, then whether you have
operator overloading or not, you end up with the code:
compute_contour_integral (A, f);
Having the overloading might encourage someone to write the code
in-line rather than make a function call, leading to more diffictult
code, not less.