Boost process and C

J

jacob navia

(e-mail address removed) 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
 
J

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" <[email protected]>
Groupes : comp.lang.c, comp.sources.d
> 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...
 
E

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
 
K

Keith Thompson

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

Michael Mair

jacob said:
(e-mail address removed) a écrit :

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 <[email protected]>,
this is paraphrasing E. Robert Tisdale,
then you just have done yourself said:
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
 
K

Keith Thompson

jacob navia said:
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" <[email protected]>
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.
 
J

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
 
J

jacob navia

Chris Torek a écrit :
Michael Mair said:
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!
 
J

jacob navia

Keith Thompson a écrit :
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
 
J

jacob navia

Ian Collins a écrit :
C isn't dead, it's mature, there is a difference.



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
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?
 
C

CBFalconer

jacob said:
jacob navia a écrit :


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" <[email protected]>
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/>
 
D

Default User

Keith said:
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
 
C

Chris Hills

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

Chris Hills

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
 
M

Michael Mair

Chris said:
There is C99


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.

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.

What is "Embedded C" and who developed it?

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


Cheers
Michael
 
C

Chris Hills

Michael Mair said:
Chris said:
There is C99


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.

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.

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

Michael Mair

Chris said:
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
 
C

Chris Torek

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

websnarf

jacob said:
(e-mail address removed) a écrit :

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

Keith Thompson

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top