GCC is re-implementing in C++ and C discarded

[lovecreatesbeauty]

Hello! Wise people!


Just read the shock news[1][2] that GCC is re-implementing in C++ and C will be discarded ( deprecated ? : )

But still not very clear on it.

. does it mean C++ is better than C?

. the re-implemention involves which one(s): C compiler, C++ compiler, and Java, Fortran ..?

. what will the man who said "C++ is horrible language" and his related linux project do?


-vvvv-

This page is meant to eventually help document the ongoing effort in the "gcc-in-cxx" branch to make gcc compile in C++ mode, i.e. as C++ source code.

So, the goal of this branch is to facilitate switching GCC's implementation language to C++.

-^^^^-

[1] http://gcc.gnu.org/wiki/gcc-in-cxx
[2] http://gcc.gnu.org/wiki/cxx-conversion

[Thomas Richter]

Am 22.08.2012 19:34, schrieb lovecreatesbeauty:
> Hello! Wise people!
>
>
> Just read the shock news[1][2] that GCC is re-implementing in C++ and C will be discarded ( deprecated ? : )
>
> But still not very clear on it.
>
> . does it mean C++ is better than C?

It means "use the right tool for the right job." What is "better"
depends on your metric. In my experience, designing large and
complicated projects in C alone is harder than to do it in C++ where you
have better ability to check for correctness of your constructions, and
a more expressive language to get the job done. If your goal is to
develop lean software on smaller systems, C is the better choice as its
overhead is smaller and its usually better supported on processors off
the mainstream.

> . the re-implemention involves which one(s): C compiler, C++ compiler, and Java, Fortran ..?

I don't know. Probably all of them one after another. Note that gcc has
a common code generator that will, likely, be in C++ for all those cases.

> . what will the man who said "C++ is horrible language" and his related linux project do?

Who the fuck cares? Linux requires a lot of arcane magic as far as the
linkage and loading process is concerned, and critically depends on some
of the internals how that goes for the gcc. It would be harder to keep
this magic working for C++.

Greetings,
Thomas

[fma...@gmail.com]

On Wednesday, August 22, 2012 7:34:37 PM UTC+2, lovecreatesbeauty wrote:
> Hello! Wise people!
>
> Just read the shock news[1][2] that GCC is re-implementing in C++ and C will be discarded ( deprecated ? : )
>
> But still not very clear on it.
>

It just means that gcc will be entirely written in C++ instead of C.
Is it a good move? Ask the gcc developers!
More on, one can think that it will be harder to build gcc (as it's easier to find C compilers than C++ compilers on different architectures), but to build gcc you need another gcc anyway, cross-compiling it on a different machine if needed.
So, IMHO, nothing to see here.
Ciao!

[James Kuyper]

On 08/22/2012 01:34 PM, lovecreatesbeauty wrote:
> Hello! Wise people!
>
>
> Just read the shock news[1][2] that GCC is re-implementing in C++ and C will be discarded ( deprecated ? : )
>
> But still not very clear on it.
>
> . does it mean C++ is better than C?

No, it means the developers of gcc think it's a better language for that
application. They might have a different opinion for other kinds of
applications. Their opinion might or might not be correct.

> . the re-implemention involves which one(s): C compiler, C++ compiler, and Java, Fortran ..?

gcc is the Gnu Compiler Collection; that implies to me that the correct
answer is likely to be "all of the above (and others too)".

> . what will the man who said "C++ is horrible language" and his related linux project do?

He'll probably say that gcc has made a horrible mistake. He might or
might not be correct. Keep in mind that people who go to extremes in
support or opposition to a given language are seldom reliable judges of
such issues.

[Angel]

Nice diplomatic answer. I fear it will be wasted on the thread starter
though, this guy is so obviously trolling it's not even funny.


--
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

[Keith Thompson]

lovecreatesbeauty <lovecrea...@gmail.com> writes:
> Just read the shock news[1][2] that GCC is re-implementing in C++ and
> C will be discarded ( deprecated ? : )

[...]

As far as I know, the only thing changing is the implementation
language. It has nothing to do with the languages that gcc
can compile, and there is no indication of C being discarded or
deprecated other than as the implementation language for gcc itself.

I have no comment on whether this is a good idea, but it's not what
you're implying it is.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Malcolm McLean]

בתאריך יום רביעי, 22 באוגוסט 2012 20:08:08 UTC+1, מאת Keith Thompson:

> lovecreatesbeauty <lovecrea...@gmail.com> writes:
>
> I have no comment on whether this is a good idea, but it's not what
> you're implying it is.
>
>

When any major program moves from C to another language it's something of a
disappointment to regs of this newgroup. Particularly when it's the compiler
in which a lot of C programs themselves are compiled.
But it's an outlier. The general trend is that C++ use is down, C use is
holding up.

[BartC]

"Malcolm McLean" <malcolm...@btinternet.com> wrote in message
news:d65cee92-f2b1-4ec1...@googlegroups.com...

It's no surprise that there might be better languages for implementing
compilers with than C. Especially with much faster hardware now that allows
more productive languages to be used.

But I wouldn't have chosen C++..

--
Bartc

[Vincenzo Mercuri]

On 22/08/2012 21:45, BartC wrote:

[..]

>
> It's no surprise that there might be better languages for implementing
> compilers with than C. Especially with much faster hardware now that
> allows more productive languages to be used.
>
> But I wouldn't have chosen C++..
>

Don't forget that GCC itself is a set of programs that need to run
"reasonably fast". It would take very long to compile the QT libraries
if GCC was implemented in any scripting language. C++ seems to offer
the best compromise between abstractions and performance.

--
Vincenzo Mercuri

[William Ahern]

People appear to be presuming that there's a single entity, "GCC", and it
decided that C++ is superior to C for its task.

This just isn't the case. The collective decision to move to C++ was long
and politely contentious (and not really news if you've been following
things). A large number, perhaps even a majority, were happy sticking with
C. But there was some number of contributors who strongly agitated to move
to C++, and keeping those contributors happy was apparently enough
justitication to make the move.

One of the biggest arguments for sticking with C was that more people were
proficient in C. However, major software vendors involved in the FOSS
community, including Google, have come to favor C++ for myriad reasons, most
not having anything to do with merit.

People like using languages in a FOSS project that they regularly use
elsewhere. Given the shift in the communities that foster GCC development,
it was only a matter of time that C++ would come into the fore. The question
is, how long will this last?

Like almost everything in life, the most prominent answer for "why C++" is
path dependence.

[Robert Wessel]

On Wed, 22 Aug 2012 20:45:19 +0100, "BartC" <b...@freeuk.com> wrote:

>
>
>"Malcolm McLean" <malcolm...@btinternet.com> wrote in message
>news:d65cee92-f2b1-4ec1...@googlegroups.com...

>> ?????? ??? ?????, 22 ??????? 2012 20:08:08 UTC+1, ??? Keith Thompson:

>>> lovecreatesbeauty <lovecrea...@gmail.com> writes:
>>>
>>> I have no comment on whether this is a good idea, but it's not what
>>> you're implying it is.
>>>
>>>
>> When any major program moves from C to another language it's something of
>> a
>> disappointment to regs of this newgroup. Particularly when it's the
>> compiler
>> in which a lot of C programs themselves are compiled.
>> But it's an outlier. The general trend is that C++ use is down, C use is
>> holding up.
>
>It's no surprise that there might be better languages for implementing
>compilers with than C. Especially with much faster hardware now that allows
>more productive languages to be used.
>
>But I wouldn't have chosen C++..

Well they're obviously *not* going to rewrite GCC from scratch. The
plan, as I understand it, is to first make the codebase (or much of
it) C++ clean (as with many C programs, that should not be a horrible
undertaking), and then work from there. Given the scope of what a
complete GCC rewrite would entail, almost* any other language choice
would be doomed from the start.

If I were writing a compiler from scratch (and that's something I've
done several times over the years), the technical merits of the
language are obviously a significant consideration, but the practical
realities of availability, tool chains and programmers loom just as
large. So while my first choice for implementing a compiler would
likely be something like Haskell, it just isn't usually an option in
the real world. Like it or not, the added abstractions possible in
C++ are quite handy for many of the manipulations needed in a
compiler, so C++ is likely the best option in most cases. At this
point the number of platforms you're likely to run a compiler on that
*don't* have a well supported C++ compiler is quite small, so the
greater availability of C is a pretty limited benefit.

Of course if you can limit your platforms enough, there are other
options to consider. For example, if you were targeting MS platforms
only, C# is pretty attractive.


*Objective C would have a similar high level of C compatibility as
C++, for example, but I think you'd be hard pressed to consider that
as sufficiently mainstream.

[Andrew Cooper]

On 22/08/2012 18:34, lovecreatesbeauty wrote:
> Hello! Wise people!
>
>
> Just read the shock news[1][2] that GCC is re-implementing in C++ and C will be discarded ( deprecated ? : )
>
> But still not very clear on it.
>
> . does it mean C++ is better than C?

C and C++ both have their place (and I indeed use each depending on the
problem needing to be solved)

The hidden question is "How much does the GCC source code look like C",
to which the answer is "not really".

The internal code has vast quantities of macros which appear to
implement OO design; so much so that the equivalent C++ code in places
is substantially cleaner and neater.

So the movement is more from "Basically C++ but implemented with the
preprocessor" to C++, which is rather less of a leap.

>
> . the re-implemention involves which one(s): C compiler, C++ compiler, and Java, Fortran ..?
>
> . what will the man who said "C++ is horrible language" and his related linux project do?

Continue to be the same because, while he is particularly vocal in his
opinion, he is correct when it comes to a kernel.

C++ is substantially easier than C for making sensible looking which
cripples performance. Two examples would be virtual functions inside a
tight loop (causing slower execution), or a liberal sprinkling of
templates (causing a swelling of code size). This is not saying that it
cant be done, but that it is making an already hard problem far harder.

~Andrew

[Kenneth Brody]

On 8/22/2012 3:45 PM, BartC wrote:
[...]

> It's no surprise that there might be better languages for implementing
> compilers with than C. Especially with much faster hardware now that allows
> more productive languages to be used.
>
> But I wouldn't have chosen C++..

Whitespace?

INTERCAL?

Or perhaps the oft-maligned Brainf**k?

--
Kenneth Brody

[Keith Thompson]

Before the transition, gcc consisted of thousands of lines of C.
Translating all that code to a language without very close compatibility
with C would have been a huge task.

As I understand it, much of gcc was already written in the common subset
of C and C++.

[Keith Thompson]

Andrew Cooper <am...@cam.ac.uk> writes:
> On 22/08/2012 18:34, lovecreatesbeauty wrote:

[...]

>> . what will the man who said "C++ is horrible language" and his
>> related linux project do?
>
> Continue to be the same because, while he is particularly vocal in his
> opinion, he is correct when it comes to a kernel.

I believe this refers to Linus Torvalds, primary author of the Linux
kernel.

[...]

[Alan Curry]

In article <lnobm2h...@nuthaus.mib.org>,

Keith Thompson <ks...@mib.org> wrote:
>Andrew Cooper <am...@cam.ac.uk> writes:
>> On 22/08/2012 18:34, lovecreatesbeauty wrote:
>[...]
>>> . what will the man who said "C++ is horrible language" and his
>>> related linux project do?
>>
>> Continue to be the same because, while he is particularly vocal in his
>> opinion, he is correct when it comes to a kernel.
>
>I believe this refers to Linus Torvalds, primary author of the Linux
>kernel.

I hope he's completely dissatisfied and enraged. The last time he got pissed
off at one of his development tools, he took a few weeks to build a
replacement and now we have git. Imagine the same thing happening to the
compiler.

--
Alan Curry

[Nobody]

On Wed, 22 Aug 2012 22:26:45 +0000, Alan Curry wrote:

>>I believe this refers to Linus Torvalds, primary author of the Linux
>>kernel.
>
> I hope he's completely dissatisfied and enraged. The last time he got
> pissed off at one of his development tools, he took a few weeks to build a
> replacement and now we have git. Imagine the same thing happening to the
> compiler.

His dissatisfaction with C++ relates to the language itself, not the
tools. As the changes shouldn't affect gcc's external behaviour, it
wouldn't matter if it was being re-written in Cobol. For Linus' purposes,
gcc (the C compiler) will be no less suitable and g++ no more suitable
when written in C++ than in C.

[James Kuyper]

His biggest complaints about C++ were about the maintainability of the
code. If his complaints are valid, the implementation using C++ will be
much buggier than the current one using C, in which case both gcc and
g++ will be less suitable when implemented using C++ than when
implemented using C. It's correspondingly important to know whether or
not his complaints are valid. I don't have sufficiently wide experience
to judge the issue.
--
James Kuyper

[Les Cargill]

There are classes of bugs that C++ can eliminate entirely. And there
are classes of bugs in C++ that are much less fun to debug. This being
said, so long as the bugs are reproducible, it's just money and time.

--
Les Cargill

[lovecreatesbeauty]

On Wednesday, August 22, 2012 8:40:28 PM UTC, William Ahern wrote:
>
> This just isn't the case. The collective decision to move to C++ was long
>
> and politely contentious (and not really news if you've been following
>
> things). A large number, perhaps even a majority, were happy sticking with
>
> C. But there was some number of contributors who strongly agitated to move
>
> to C++, and keeping those contributors happy was apparently enough
>
> justitication to make the move.
>
>
>
> One of the biggest arguments for sticking with C was that more people were
>
> proficient in C. However, major software vendors involved in the FOSS
>
> community, including Google, have come to favor C++ for myriad reasons, most
>
> not having anything to do with merit.
>

Will there be two sets of implemention of GCC, one in C and another in C++.

It's a change to switch back to C in case the latter one f_cked up.

[David Brown]

On 23/08/2012 00:13, Keith Thompson wrote:
> "BartC" <b...@freeuk.com> writes:
>> "Malcolm McLean" <malcolm...@btinternet.com> wrote in message
>> news:d65cee92-f2b1-4ec1...@googlegroups.com...
>>> בתאריך יום רביעי, 22 באוגוסט 2012 20:08:08 UTC+1, מאת Keith Thompson:
>>>> lovecreatesbeauty <lovecrea...@gmail.com> writes:
>>>>
>>>> I have no comment on whether this is a good idea, but it's not what
>>>> you're implying it is.
>>>>
>>> When any major program moves from C to another language it's
>>> something of a disappointment to regs of this newgroup. Particularly
>>> when it's the compiler in which a lot of C programs themselves are
>>> compiled. But it's an outlier. The general trend is that C++ use is
>>> down, C use is holding up.
>>
>> It's no surprise that there might be better languages for implementing
>> compilers with than C. Especially with much faster hardware now that
>> allows more productive languages to be used.
>>
>> But I wouldn't have chosen C++..
>
> Before the transition, gcc consisted of thousands of lines of C.
> Translating all that code to a language without very close compatibility
> with C would have been a huge task.
>
> As I understand it, much of gcc was already written in the common subset
> of C and C++.
>

Well, you almost have to go out of your way to write C code that is not
also valid C++ code. I gather there hasn't been much work involved in
getting gcc to compile and run correctly with g++ and all .c files
compiled as C++.

So contrary to some of the opinions in this thread, gcc is /not/ being
"re-written in C++". It is still mainly in C, compiled as C++. Future
changes, on the other hand, are more likely to be in non-C C++, at least
where it gives advantages.

There are also bits of gcc written in other languages. In particular,
plugins are often prototyped in other languages such as Python or Lisp.

[88888 Dihedral]

lovecreatesbeauty於 2012年8月23日星期四UTC+8下午3時15分39秒寫道：

C++ is good for those not interested in the hardware platform.

The auto-sizable vector container reminds me the array in basica.

It is also good for LISP users to get what they wanted and cried long time
ago.

[Mark Bluemel]

On 23/08/2012 08:15, lovecreatesbeauty wrote:

> Will there be two sets of implemention of GCC, one in C and another in C++.

Why don't you ask on one of the GCC mailing lists rather than a general
C forum?

[Chicken McNuggets]

I don't know. There are plenty of fast languages that are not C or C++.
Haskell strikes me as an interesting language that is both "fast enough"
and extremely expressive.

[Chicken McNuggets]

On 22/08/2012 21:56, Robert Wessel wrote:

>
> *Objective C would have a similar high level of C compatibility as
> C++, for example, but I think you'd be hard pressed to consider that
> as sufficiently mainstream.
>

I'm not so sure. Objective-C is growing in popularity all the time. It
has the advantage that any valid C program is a valid Objective-C
program and can also use C++ classes directly via Objective-C++. Sounds
like a win / win situation to me.

[Robert Wessel]

Outside the Apple world, the use of Objective-C relative to C++
appears to be miniscule, bordering on the non-existent.

[Chicken McNuggets]

According to the Tiobe language index for August 2012 it is the third
most popular language (ahead of C++).

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

[Vincenzo Mercuri]

Il 8/23/2012 3:49 PM, Chicken McNuggets ha scritto:
> On 23/08/2012 14:32, Robert Wessel wrote:

[..]

>> Outside the Apple world, the use of Objective-C relative to C++
>> appears to be miniscule, bordering on the non-existent.
>>
>
> According to the Tiobe language index for August 2012 it is the third
> most popular language (ahead of C++).
>
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

That doesn't prove that Objective-C is as popular outside the Apple world.
--
Vincenzo Mercuri

[fma...@gmail.com]

Given this data, I'd say that the Apple-world is more popular than C++

Ciao!

[Vincenzo Mercuri]

Not really an Apple to Apple comparison ;)

--
Vincenzo Mercuri

[Kenneth Brody]

On 8/23/2012 4:09 AM, David Brown wrote:
[...]

> Well, you almost have to go out of your way to write C code that is not also
> valid C++ code.

What about uncast returns from malloc()?

And I have been known, long ago, to use "new" (along with "old") as a
variable name.

[...]

--
Kenneth Brody

[Rui Maciel]

Chicken McNuggets wrote:

> According to the Tiobe language index for August 2012 it is the third
> most popular language (ahead of C++).
>
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

That index is meaningless. For example, it tries to account the popularity
of a given programming language by counting the number of videos on youtube
that pop out on a given search.

http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm


Meanwhile, a search on sourceforge for C++ returns 1632 results[1], while a
search on Objective C returns 66[2].


Rui Maciel

[1] http://sourceforge.net/directory/language:c%2B%2B/
[2] http://sourceforge.net/directory/language:objective-c/

[Rui Maciel]

fma...@gmail.com wrote:

> Given this data, I'd say that the Apple-world is more popular than C++

It may be more popular in youtube and in a set of random blogs, but that is
meaningless and it isn't exactly what a programming language is for.


Rui Maciel

[Kenny McCormack]

In article <k15pvn$fhj$2...@speranza.aioe.org>,

I'm curious exactly how you would answer the question (below) if you were
being perfectly honest and not trying to impress anyone on Usenet.

Q: What exactly do we mean when we say that language A is more "popular"
than language B?

--
Is God willing to prevent evil, but not able? Then he is not omnipotent.
Is he able, but not willing? Then he is malevolent.
Is he both able and willing? Then whence cometh evil?
Is he neither able nor willing? Then why call him God?
~ Epicurus

[Kenny McCormack]

In article <k15q2u$dhh$3...@news.xmission.com>,
Kenny McCormack <gaz...@shell.xmission.com> wrote:
...

>Q: What exactly do we mean when we say that language A is more "popular"
>than language B?

I suggest that the most common interpretation of this question is:

Q: What language should I study in school to maximize my chances of getting
a job?

--
Given Bush and his insanely expensive wars (*), that we will be paying for
for generations to come, the only possible response a sensible person need
ever give, when a GOPer/TeaBagger says anything about "deficits", is a
polite snicker.

(*) Obvious money transfers between the taxpayers and Bush's moneyed
interests. Someday, we'll actually figure out a way to have a war where the
money just gets moved around and nobody (on either side) gets injured or
killed. That will be an accomplishment of which we will be justly proud.

[Aaron W. Hsu]

pac...@kosh.dhis.org (Alan Curry) writes:

>I hope he's completely dissatisfied and enraged. The last time he got pissed
>off at one of his development tools, he took a few weeks to build a
>replacement and now we have git. Imagine the same thing happening to the
>compiler.

Of course, there are already a number of good C based compiler
offerings, depending on what you are looking for, so I don't think
that people who are religious about using C for their compiler have
to worry that much. PCC comes to mind, as well as OpenWatcom, which,
I think, is implemented in C.

--
Aaron W. Hsu | arc...@sacrideo.us | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.

[Melzzzzz]

Haskell fast? Well, it provides C strings and such but language
is inherently *slow*.
Java is much faster than Haskell for example...



--
drwxr-xr-x 2 bmaxa bmaxa 4096 Aug 22 11:59 .

[Melzzzzz]

What are advantages of Objective C over C++?


--
drwx------ 2 bmaxa bmaxa 4096 Aug 23 21:14 .

[Melzzzzz]

On Thu, 23 Aug 2012 14:49:38 +0100

Hm. Besides OOlite I don;t know any other application that uses
Objective C on Linux (or for that matter Windows).


--
drwx------ 2 bmaxa bmaxa 4096 Aug 23 21:15 .

[Melzzzzz]

What Objective C applications exists on other platforms except
apple?


--
drwx------ 2 bmaxa bmaxa 4096 Aug 23 21:21 .

[Malcolm McLean]

בתאריך יום חמישי, 23 באוגוסט 2012 18:42:54 UTC+1, מאת Kenny McCormack:
> In article <k15pvn$fhj$2...@speranza.aioe.org>,

>
> Q: What exactly do we mean when we say that language A is more "popular"
> than language B?
>
>

We don't mean anything exactly. There are several metrics which could could
use and defend. The number of programmers using the language, the number of
lines of code in existence, the number of programs written in the language, the
number of programmer hours spent with the language, the number of paid
programmer hours, the number of voluntary programmer hours (with few external
pressures to use other languages).
But most of these will give similar results.

[Anonymous]

Kenneth Brody <kenb...@spamcop.net> wrote:

> On 8/22/2012 3:45 PM, BartC wrote:
> [...]

> > It's no surprise that there might be better languages for implementing
> > compilers with than C. Especially with much faster hardware now that allows
> > more productive languages to be used.
> >
> > But I wouldn't have chosen C++..
>

> Whitespace?
>
> INTERCAL?
>
> Or perhaps the oft-maligned Brainf**k?

I know that was said in jest, but with a good optimizer and some careful GC,
brainf**k can outperfom even the best hand coded C.

[William Ahern]

Melzzzzz <m...@zzzzz.invalid> wrote:
> On Thu, 23 Aug 2012 10:43:21 +0100
> Chicken McNuggets <chi...@mcnuggets.com> wrote:

<snip>

> > I don't know. There are plenty of fast languages that are not C or
> > C++. Haskell strikes me as an interesting language that is both "fast
> > enough" and extremely expressive.

> Haskell fast? Well, it provides C strings and such but language
> is inherently *slow*.
> Java is much faster than Haskell for example...

Actually, Haskell competes quite well with Java on the Programming Language
Shootout.

http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all

GHC can compile either to native code, or to C.

[Melzzzzz]

Well, those are just small benchmarks tweaked to perfection.
I have tried Haskell some years ago and found it much more difficult
than C++ to master and write satisfying applications in time.
You have to be real guru to write satisfying Haskell code.
I mean idea that everything is constant is good in theory
but in practice you have to dig in "non safe" code and
to write against functional spirit in order to finish job,
and for that task Haskell is too complicated IMO.

--
drwx------ 2 bmaxa bmaxa 4096 Aug 23 22:33 .

[Robert Wessel]

On Thu, 23 Aug 2012 17:43:56 +0000 (UTC), gaz...@shell.xmission.com
(Kenny McCormack) wrote:

>In article <k15q2u$dhh$3...@news.xmission.com>,
>Kenny McCormack <gaz...@shell.xmission.com> wrote:
>...
>>Q: What exactly do we mean when we say that language A is more "popular"
>>than language B?
>
>I suggest that the most common interpretation of this question is:
>
>Q: What language should I study in school to maximize my chances of getting
>a job?

That's probably true, although somewhat difficult to measure. Other
useful answers might be the amount of work to be done (measured how?),
number of hours spent writing code, KLOCs being written, etc...

Tiobe has some other metric (something approximating a measure of the
chatter about the language on the Internet). How that relates to an
actual useful measure, I have no idea, but Tiobe's measure is
certainly not a direct measure of anything useful (unless maybe you
wanted to write a book or teach classes on a programming language).

In the case of Objective-C, approximately everyone and their idiot
brother is developing iOS apps. So there's lots of talk about the
relatively new platform. By contrast, C (and C++) is much better
understood, and I'd guess that the relative amount of chatter is lower
compared to the amount of actual work being done.

[David Brown]

Whereas real programmers work in C, but we don't sit around all day
talking about it...


More accurately, "real" programmers probably don't discuss their
programming languages in the sorts of places that Tiobe looks at, such
as facebook. If they looked at newsgroups or sites like Stackoverflow,
they might get different results.

[David Brown]

Well, if you like C++'s hideous template syntax, you'll just /love/
objective C's message passing syntax!

[Nick Keighley]

On Aug 23, 7:10 pm, Aaron W. Hsu <arcf...@sacrideo.us> wrote:
> pac...@kosh.dhis.org (Alan Curry) writes:
> >I hope he's completely dissatisfied and enraged. The last time he got pissed
> >off at one of his development tools, he took a few weeks to build a
> >replacement and now we have git. Imagine the same thing happening to the
> >compiler.
>
> Of course, there are already a number of good C based compiler
> offerings, depending on what you are looking for, so I don't think
> that people who are religious about using C for their compiler have
> to worry that much. PCC comes to mind, as well as OpenWatcom, which,
> I think, is implemented in C.

this whole conversation strikes me as bizzare. A kind of level
confusion. It reminds of one of my collegues who came out with "C++ is
upwards compatible with C because it is implemented in C" and couldn't
see what was wrong with that statement.

(I'll accpt that some people porting a compiler might care what it was
implemented in)

[Les Cargill]

Even Stackoverlfow et al have significant bias towards the newer
languages. Because, well, they're newer. We*/I have looked
hard at Objective C three times in the last twenty years or so, but
ended up not using it for the usual path dependent reasons.

*whoever that was at the time...

--
Les Cargill

[Johannes Bauer]

On 23.08.2012 22:17, Anonymous wrote:

>> Or perhaps the oft-maligned Brainf**k?
>
> I know that was said in jest, but with a good optimizer and some careful GC,
> brainf**k can outperfom even the best hand coded C.

That is not the question. Actually, this *never* is the question. If you
compare performances of different languages, you *will* need to take a
look at the abstraction level they provide. Merely comparing performance
alone is absolutely meaningless.

For example, obviously assembly language is at least as fast as *any*
compiled language (because they all are broken down into assembly). This
is not a reason to use assembly, however. In fact, most people will
sacrifice code optimality for abstration and use C (although this will
usually not yield ideal code).

Comparing *only* performance of languages with vast differences in the
abstraction they provide for the programmer is completly meaningless.

Best regards,
Joe

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht ï¿œffentlich!
Ah, der neueste und bis heute genialste Streich unsere groï¿œen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos ï¿œber Rï¿œdiger Thomas in dsa <hidbv3$om2$1...@speranza.aioe.org>

[jacob navia]

Le 24/08/12 15:09, Johannes Bauer a écrit :

> For example, obviously assembly language is at least as fast as*any*
> compiled language (because they all are broken down into assembly). This
> is not a reason to use assembly, however. In fact, most people will
> sacrifice code optimality for abstration and use C (although this will
> usually not yield ideal code).
>

> Comparing*only* performance of languages with vast differences in the

> abstraction they provide for the programmer is completly meaningless.

Precisely because of that I want to have a container library in C.

Surprisingly, most of the regulars in this group have worked against
this proposal

[Johannes Bauer]

On 24.08.2012 17:53, jacob navia wrote:

>> Comparing*only* performance of languages with vast differences in the
>> abstraction they provide for the programmer is completly meaningless.
>
> Precisely because of that I want to have a container library in C.
>
> Surprisingly, most of the regulars in this group have worked against
> this proposal

What do you mean by "have worked aginst" it? You are obviously free to
work on whatever you deem worthy of working on. Nobody is stopping you
and you've already invested a significant effort in the CCL.

The question I do have is: why? Why use C and implement most of the
standard STL containers instead of using C++? It seems like the wrong
tool for the job.

If I proposed a container library for assembly language, containing
thousands of macros making the language much easier and comfortable and
less error, you'd agree that that was not time well spend, wouldn't you?
That doesn't mean that such a thing would be useless, but it means that
there are tools better suited for the job and which are already
complete, well-understood and working/tested.

Best regards,
Johannes

[Kenneth Brody]

On 8/23/2012 1:43 PM, Kenny McCormack wrote:
> In article <k15q2u$dhh$3...@news.xmission.com>,
> Kenny McCormack <gaz...@shell.xmission.com> wrote:

> ....

>> Q: What exactly do we mean when we say that language A is more "popular"
>> than language B?
>
> I suggest that the most common interpretation of this question is:
>
> Q: What language should I study in school to maximize my chances of getting
> a job?

Q: If it's more likely that I can get a job with language X, but getting a
job with language Y pays more, which language should I study?

--
Kenneth Brody

[Kenneth Brody]

On 8/24/2012 5:15 AM, Nick Keighley wrote:
[...]

> this whole conversation strikes me as bizzare. A kind of level
> confusion. It reminds of one of my collegues who came out with "C++ is
> upwards compatible with C because it is implemented in C" and couldn't
> see what was wrong with that statement.

"Assembler must be upwards compatible with C, because 'as' is written in C."

"FORTRAN must be upwards compatible with C, because gnu FORTRAN is written
in C." (I think.)

Etc., etc., etc.

> (I'll accpt that some people porting a compiler might care what it was
> implemented in)

Agreed.

--
Kenneth Brody

[jacob navia]

Le 24/08/12 19:02, Johannes Bauer a ï¿œcrit :

> The question I do have is: why? Why use C and implement most of the
> standard STL containers instead of using C++? It seems like the wrong
> tool for the job.

Because I do not want C++!

The C++ guys are so completely convinced that their stuff is the best
discovery since sliced bread that they can't even IMAGINE that someone
doesn't WANT to use their pile of complexity.

This is a C group but it is full of people that think that C is just
obsolete and come here just to preach the advantages of their C++.

Why is C the wrong tool for the job?

My library is running at almost the same speed, has an easy to use
syntax and even more easy to use semantics. You do not get horrible
error messages because of some misplaced template bracket.

It is C.

You (and most people from C++) are unable to understand the advantages
of using a simple language without all the extra stuff of C++.

[jacob navia]

Le 24/08/12 19:02, Johannes Bauer a ï¿œcrit :

> If I proposed a container library for assembly language, containing
> thousands of macros making the language much easier and comfortable and
> less error, you'd agree that that was not time well spend, wouldn't you?

Why not?

What's wrong with doing that?

Why do you think that code reuse is bad?

Only C++ is right, the rest of the programming world is wrong. I see the
mentality behind your reasoning.

[Johannes Bauer]

On 24.08.2012 20:53, jacob navia wrote:

>> The question I do have is: why? Why use C and implement most of the
>> standard STL containers instead of using C++? It seems like the wrong
>> tool for the job.
>
> Because I do not want C++!

And nobody forced you to. I merely asked and you respond with such a rant.

> The C++ guys are so completely convinced that their stuff is the best
> discovery since sliced bread that they can't even IMAGINE that someone
> doesn't WANT to use their pile of complexity.

You are generalizing, using "The C++ guys" as stawmen. Anyone who thinks
that any language is the best since sliced bread is a moron. And anyone
who insist on using one PARTICULAR language, no matter what, is one too.

> This is a C group but it is full of people that think that C is just
> obsolete and come here just to preach the advantages of their C++.

That is not my opinion, actually. People in the group seem to like C
quite a lot. Why do you come to that conclusion?

> Why is C the wrong tool for the job?

For WHICH job? It always depends. For some things, C is *clearly* the
wrong tool. For other things it is the right tool. It always depends.

> My library is running at almost the same speed, has an easy to use
> syntax and even more easy to use semantics. You do not get horrible
> error messages because of some misplaced template bracket.

You're confusing the C++ language with the horrible error messages that
g++ spouts out when you do something wrong. Also, I agree that the C++
syntax is very complex and C is much easier to learn.

But that's not a valid argument. It's like saying a torque wrench is bad
because you can misuse it and it's more complicated than a standard
wrench. And every nut can be turned with a regular wrench anyways. Sure
it can. Nobody said it couldn't. Just for some uses, you wouldn't want to.

> It is C.
>
> You (and most people from C++) are unable to understand the advantages
> of using a simple language without all the extra stuff of C++.

You're wrong. I very clearly see the advantages and disadvantes of
C/C++. For some things, I use C. For others, I use C++. In contrast to
you, I make that decision based on the problem that I'm having, not
deciding up front.

[Johannes Bauer]

On 24.08.2012 21:08, jacob navia wrote:
> Le 24/08/12 19:02, Johannes Bauer a ï¿œcrit :
>> If I proposed a container library for assembly language, containing
>> thousands of macros making the language much easier and comfortable and
>> less error, you'd agree that that was not time well spend, wouldn't you?
>
> Why not?

Because there are tools already that do this, better than I could. There
are programming languages which have been around for DECADES which will
do a better job than any macro assembler I could ever build would. They
are tested better and used by way more people, leading to more robust code.

> What's wrong with doing that?

It will recreate something that exists already, only worse. That sounds
like a waste of time.

> Why do you think that code reuse is bad?

Where did I say that? Code reuse is great. Recreating something that
exists already is a horrible idea. So, in fact, I am advocating code
reuse: use the language that ALREAY does everything that you want, only
better tested and standardized instead of inventing your own stuff and
reinventing the wheel.

> Only C++ is right, the rest of the programming world is wrong. I see the
> mentality behind your reasoning.

I see why you think everyone in the group is against you. You're
generalizing, putting words in the mouth's of others and exhibiting
quite paranoid behavior. A very annoying habit, which I guess is the
reason why the regulars avoid you.

[Steven G. Kargl]

On Fri, 24 Aug 2012 13:58:46 -0400, Kenneth Brody wrote:

> On 8/24/2012 5:15 AM, Nick Keighley wrote:
> [...]
>> this whole conversation strikes me as bizzare. A kind of level
>> confusion. It reminds of one of my collegues who came out with "C++ is
>> upwards compatible with C because it is implemented in C" and couldn't
>> see what was wrong with that statement.
>
> "Assembler must be upwards compatible with C, because 'as' is written in C."
>
> "FORTRAN must be upwards compatible with C, because gnu FORTRAN is written
> in C." (I think.)

The name of the language is "Fortran". It's been Fortran since
the Fortran 1990 standard.

The GNU Fortran frontend is written in C. Some of the GNU
Fortran runtime is written in m4. The m4 files when processed
generates Fortran code. The Fortran code is then compiled by
GNU Fortran.

--
steve

[nroberts]

On Wednesday, August 22, 2012 7:42:46 PM UTC-7, James Kuyper wrote:

> [Linus's] biggest complaints about C++ were about the maintainability of the
>
> code. If his complaints are valid, ...

Nothing to worry about there. Carry on.

[Jorgen Grahn]

On Fri, 2012-08-24, David Brown wrote:
> On 23/08/2012 21:15, Melzzzzz wrote:

...

>> What are advantages of Objective C over C++?
>>
>
> Well, if you like C++'s hideous template syntax, you'll just /love/
> objective C's message passing syntax!

I don't know Objective C, but what's so hideous about the former?
Apart from the fact that (), [] and {} were used up so it had to
reuse <>?

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Jorgen Grahn]

On Wed, 2012-08-22, Malcolm McLean wrote:

> When any major program moves from C to another language it's something of a
> disappointment to regs of this newgroup. Particularly when it's the compiler
> in which a lot of C programs themselves are compiled.

> But it's an outlier. The general trend is that C++ use is down, C use is
> holding up.

Speaking as someone who really prefers C++ to C nowadays, and C to all
other languages for many uses:

If that is true, it should worry C programmers.

C++ really /is/ the "better C" in the sense that like C it
- works for low-level code
- works in environments with little runtime support
- is compatible with C libraries and interfaces.
but allows you to make your design more clearly reflected in the code.

There are no other important languages in that area. And the area /is/
important -- I've made my living in it in since '96, and things like
most Unix software are based on it.

So, even if you're happy with C, and see it "hold up", it should worry
you if the path forward is declining.

It's not as if other interesting things are happening in the C area.
And the C programmers I meet are generally unskilled. Not stupid or
unable to make things work -- just undereducated in topics like the C
language itself, debugging, and how to write large-scale maintainable
code.

[Johannes Bauer]

On 25.08.2012 11:06, Jorgen Grahn wrote:

> If that is true, it should worry C programmers.
>
> C++ really /is/ the "better C" in the sense that like C it
> - works for low-level code
> - works in environments with little runtime support

You clearly do *not* write low-level code.

Pre-initialized structures, which C provides, are for some architectures
I'm working in a *MUST*, since they determine the interrupt vector table
which gets transferred to C. C++ just does not offer this. Referring to
the Cortex-M3 and -M4 series here, for example (where the initial stack
pointer and the IVT are placed in the start of flash).

In fact I wrote a library to conveniently and efficiently address
low-level registers of a MCU using c++0x features, so access to
bitfields is truely typesafe (class enums!). This works nice and well,
but for other parts, C is still a must because C++ just doesn't cut it.

Regards,

[Nick Keighley]

On Aug 24, 8:33 pm, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote:
> On 24.08.2012 20:53, jacob navia wrote:

> >> The question I do have is: why? Why use C and implement most of the
> >> standard STL containers instead of using C++? It seems like the wrong
> >> tool for the job.
>
> > Because I do not want C++!
>
> And nobody forced you to. I merely asked and you respond with such a rant.

he appreciates the useful-ness of standard containers but doesn't want
the rest of the baggage that comes with C++. Idiomatic C++ doesn't
look a lot like C.

<snip>

> > My library is running at almost the same speed, has an easy to use
> > syntax and even more easy to use semantics. You do not get horrible
> > error messages because of some misplaced template bracket.
>
> You're confusing the C++ language with the horrible error messages that
> g++ spouts out when you do something wrong.

which compiler doesn't do this? VisualStudio isn't much better.

<snip>

[88888 Dihedral]

robert...@yahoo.com於 2012年8月23日星期四UTC+8下午9時32分02秒寫道：
> On Thu, 23 Aug 2012 10:49:35 +0100, Chicken McNuggets

>
> <chi...@mcnuggets.com> wrote:
>
>
>
> >On 22/08/2012 21:56, Robert Wessel wrote:
>
> >
>
> >>
>
> >> *Objective C would have a similar high level of C compatibility as
>
> >> C++, for example, but I think you'd be hard pressed to consider that
>
> >> as sufficiently mainstream.
>
> >>
>
> >
>
> >I'm not so sure. Objective-C is growing in popularity all the time. It
>
> >has the advantage that any valid C program is a valid Objective-C
>
> >program and can also use C++ classes directly via Objective-C++. Sounds
>
> >like a win / win situation to me.
>
>
>

Well, the IOS and ARM or BCM CPUS are not selling in the Wintel business
model.

The objective C can be pick up very fast by professional C / C++
programmers.

[Johannes Bauer]

On 25.08.2012 11:33, Nick Keighley wrote:

>>> Because I do not want C++!
>>
>> And nobody forced you to. I merely asked and you respond with such a rant.
>
> he appreciates the useful-ness of standard containers but doesn't want
> the rest of the baggage that comes with C++. Idiomatic C++ doesn't
> look a lot like C.

You are correct. However, it all depends on the usage. Nobody forces you
to use virtual methods, operator overloading, function polymorphy and
design patterns. They make the language look *very* different to C,
which is probably what you were referring to with "idiomatic C++".

However, one can also use C++ and just take advantage of containers,
leaving the rest. I would argue that this yields understandable syntax
that even a non-C++-programmer can understand easily.

Another thing to argue is that containerfied C doesn't look a lot like
idiomatic C either. Good examples for this are openssl (their use of
"STACK", etc) or the Linux kernel (their special implementation of
lists). Both are not intuitively understood by the programmer and for
both you'll have to read up how EXACTLY they work before being able to
use them.

>>> My library is running at almost the same speed, has an easy to use
>>> syntax and even more easy to use semantics. You do not get horrible
>>> error messages because of some misplaced template bracket.
>>
>> You're confusing the C++ language with the horrible error messages that
>> g++ spouts out when you do something wrong.
>
> which compiler doesn't do this? VisualStudio isn't much better.

CLang does a lot better than g++, actually. But I actually though the
VisualStudio error messages were also better (then again, this was
probably something like 5 years back and my memory might be fading).

Best regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?

> Zumindest nicht �ffentlich!
Ah, der neueste und bis heute genialste Streich unsere gro�en
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos �ber R�diger Thomas in dsa <hidbv3$om2$1...@speranza.aioe.org>

[Malcolm McLean]

בתאריך יום שבת, 25 באוגוסט 2012 10:06:48 UTC+1, מאת Jorgen Grahn:

> On Wed, 2012-08-22, Malcolm McLean wrote:
>
> If that is true, it should worry C programmers.
>
> C++ really /is/ the "better C" in the sense that like C it
>
>

> There are no other important languages in that area.
>

C++ is a superset of C (pedants, attack !!!). So if you write C rather than
C++ you've necessarily rejected C++. The only exception is when you're
developing for tiny embedded systems that don't come with a C++ compiler.

Why would you do that? Basically to make code more reusable, and to reduce
dependencies between source files. If my binary image library was in C++,
fr example, then a "binary image" would be an "object". Then the routines
would be member functions of the class. If you do a competent job then it does
mean that people can rewrite the image class to take packed images. But it
also means that someone look for, say, a distance transform can't just take
the code and drop in into his own program, without also pulling in an entire
binary image class that does the same thing as the one he already
has, but slightly differently.

[Malcolm McLean]

בתאריך יום שישי, 24 באוגוסט 2012 10:15:49 UTC+1, מאת Nick Keighley:

The first C++ compilers spat out C code, which was then fed to the C
compiler. Any language can be implemented in any other. The colleague
had probably heard a garbled version of the first statement, and wasn't
aware of the second.

[Rui Maciel]

Malcolm McLean wrote:

> The first C++ compilers spat out C code, which was then fed to the C
> compiler. Any language can be implemented in any other. The colleague
> had probably heard a garbled version of the first statement, and wasn't
> aware of the second.

If I'm not mistaken, that trick ceassed to work once exceptions were thrown
in the mix.


Rui Maciel

[Johannes Bauer]

On 25.08.2012 12:07, Malcolm McLean wrote:

>> C++ really /is/ the "better C" in the sense that like C it
>>

> C++ is a superset of C (pedants, attack !!!). So if you write C rather than
> C++ you've necessarily rejected C++. The only exception is when you're
> developing for tiny embedded systems that don't come with a C++ compiler.

This isn't mere pedanticism ("new" keyword, etc.), but the bare truth:
Some constructs which are necessary for embedded systems are just syntax
errors in C++, while they work perfectly in C.

Best regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?

> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1...@speranza.aioe.org>

[James Kuyper]

On 08/25/2012 06:22 AM, Johannes Bauer wrote:
> On 25.08.2012 12:07, Malcolm McLean wrote:
>
>>> C++ really /is/ the "better C" in the sense that like C it
>>>
>> C++ is a superset of C (pedants, attack !!!). So if you write C rather than
>> C++ you've necessarily rejected C++. The only exception is when you're
>> developing for tiny embedded systems that don't come with a C++ compiler.
>
> This isn't mere pedanticism ("new" keyword, etc.), but the bare truth:
> Some constructs which are necessary for embedded systems are just syntax
> errors in C++, while they work perfectly in C.

I can understand the necessity of using C on an embedded system if C++
is not available there. However, if a C++ compiler is available, I can't
imagine what these "necessary constructs" could be.

There are significant difference between C++ and C. I've posted example
code to this forum consisting of two modules which each can be compiled
in either C or C++. If both modules were compiled in C, or both were
compiled in C++, the resulting program was strictly conforming to all
versions of the corresponding language's standard, and returned
EXIT_FAILURE; if one was compiled in C, and the other in C++, the result
was strictly conforming to the C++ standard (the C standard doesn't
define how C++ code can be combined with C code, the C++ standard does),
and it returned EXIT_SUCCESS. There were six different differences
between the two languages that produced that result, and some of them
were very fundamental.

However, that was basically just a trick (and it took me a long time to
perfect it). As far as I know, everything that can be done using
portable C code can also be done by using (possibly different) C code
that also compiles as C++ code, with the same exact meaning in both
languages (exception: code like that which I described above, whose sole
purpose is to detect which language it was compiled in - by definition
such code must behave differently in order to behave correctly). Could
you give a counter-example?

If you're talking about something non-portable, is there anything
preventing a C++ compiler from providing support for a corresponding
non-portable construct?
--
James Kuyper

[Gareth Owen]

Johannes Bauer <dfnson...@gmx.de> writes:

> On 25.08.2012 12:07, Malcolm McLean wrote:
>
> This isn't mere pedanticism ("new" keyword, etc.), but the bare truth:
> Some constructs which are necessary for embedded systems are just syntax
> errors in C++, while they work perfectly in C.

Could you give an example or three?

[Johannes Bauer]

As I said in the previous postings, a construct like this is one of the
last reasons to have some files in C for MCU projects that I'm working
on. Omitting some deatils (like attribute specifiers which specify where
the IVT goes), but that's the gist:

struct ivtlayout {
int vec1;
int vec2;
int vec3;
};

struct ivtlayout ivt = {
.vec1 = 1234,
};

int main() {
return 0;
}


[~/tmp]: gcc -O2 -Wall -Wextra -std=c99 -pedantic x.c
[~/tmp]: g++ -O2 -Wall -Wextra -std=c++0x -pedantic x.c
x.c:8:2: Error: expected primary-expression before �.� token

Best regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?

> Zumindest nicht �ffentlich!
Ah, der neueste und bis heute genialste Streich unsere gro�en
Kosmologen: Die Geheim-Vorhersage.

[Johannes Bauer]

On 25.08.2012 15:35, James Kuyper wrote:

>> This isn't mere pedanticism ("new" keyword, etc.), but the bare truth:
>> Some constructs which are necessary for embedded systems are just syntax
>> errors in C++, while they work perfectly in C.
>
> I can understand the necessity of using C on an embedded system if C++
> is not available there. However, if a C++ compiler is available, I can't
> imagine what these "necessary constructs" could be.

Placing an interrupt vector table in ROM:

struct ivtlayout {
int vec1;
int vec2;
int vec3;
};

struct ivtlayout ivt = {
.vec1 = 1234,
};

int main() {
return 0;
}

> If you're talking about something non-portable, is there anything
> preventing a C++ compiler from providing support for a corresponding
> non-portable construct?

No, definitely not. Non-portable C++ could definitely provide this. I am
just really not a big fan of non-portable dialects. Actually, I really
don't know why this wasn't included in c++0x.

[Jens Gustedt]

Am 25.08.2012 15:35, schrieb James Kuyper:
> However, that was basically just a trick (and it took me a long time to
> perfect it). As far as I know, everything that can be done using
> portable C code can also be done by using (possibly different) C code
> that also compiles as C++ code, with the same exact meaning in both
> languages (exception: code like that which I described above, whose sole
> purpose is to detect which language it was compiled in - by definition
> such code must behave differently in order to behave correctly). Could
> you give a counter-example?

The intersection of C and C++ has
- no decent initializers, you'd need designated initializers on the C
side and constructors for C++
- no decent temporaries (compound literals for C and constructors for C++)
- no consistent way of passing dynamically sizes multi-dimensional
arrays to functions
- no type puning (union's are standardized differently between the
two)
- no consistent model for function inlining

not very attractive, at least for me

Jens

[Johannes Bauer]

On 25.08.2012 17:55, Jens Gustedt wrote:

> The intersection of C and C++ has
> - no decent initializers, you'd need designated initializers on the C
> side and constructors for C++
> - no decent temporaries (compound literals for C and constructors for C++)
> - no consistent way of passing dynamically sizes multi-dimensional
> arrays to functions
> - no type puning (union's are standardized differently between the
> two)
> - no consistent model for function inlining
>
> not very attractive, at least for me

I'm using C++ (and c++0x at that) for doing very, very low-level work,
down to 8 bit microcontrollers. And while most people seem to think that
this is impossible, quite the contrary is true: There is a huge benefit
in using it (if it is used correctly). For 8 bitters, for example, I do
not use fancy stuff (virtual methods, inheritance etc), nor parts of the
STL. I use heavily low-level language guarantees, such as strong typing
and especially strongly types class enums (gotta love those!).

To give an example on how MCU code looks using C and how it's usually
done (this is an example from an actual project of mine):

TCCR1A = _BV(COM1A1); /* Clear on Compare Match */
TCCR1B = _BV(CS10) | _BV(WGM13); /* 1 / 1 */
TCCR0B = _BV(CS02) | _BV(CS00);

where the _BV() macro is defined to be _BV(x) (1 << (x)). All the
symbols are defined by the standard library, the lvalues are volatile
registers and the rvalues are basically just bit definitions of the
hardware's datasheet.

This is just horrible. Notice how the settings of two different timers
are set, the first two lines refer to Timer 1 while the third refers to
timer 0. Both have a prescaler, or clock selection. Notice that the bits
in the standard library for this AVR processor are named CSnm, where n
is the timer (0, 1) and m is the bitvalue (0, 1, 2, 3). Obviously it is
*very* error-prone, because setting the wrong one in either register
leads to weird (and hard to debug results).

In C++, whith smart constructs, you can basically say

TCCR1().PRESCALER() = T1Presc::CKDIV_2;
TCCR0().PRESCALER() = T0Presc::CKDIV_16;

and it will boil down to the *exact* same code with no performance
penalty at all, only added typesafety. The compiler will barf if you try
to put the wrong type into a field. I find that quite awesome and this
is actually a reason for me to prefer C++ over C for this type of work.

[Les Cargill]

Johannes Bauer wrote:
> On 25.08.2012 11:06, Jorgen Grahn wrote:
>
>> If that is true, it should worry C programmers.
>>
>> C++ really /is/ the "better C" in the sense that like C it
>> - works for low-level code
>> - works in environments with little runtime support
>
> You clearly do *not* write low-level code.
>
> Pre-initialized structures, which C provides, are for some architectures
> I'm working in a *MUST*, since they determine the interrupt vector table
> which gets transferred to C. C++ just does not offer this. Referring to
> the Cortex-M3 and -M4 series here, for example (where the initial stack
> pointer and the IVT are placed in the start of flash).
>

I am fairly sure it is eminently possible to use pre-initialized structs
in C++.

> In fact I wrote a library to conveniently and efficiently address
> low-level registers of a MCU using c++0x features, so access to
> bitfields is truely typesafe (class enums!). This works nice and well,
> but for other parts, C is still a must because C++ just doesn't cut it.
>
> Regards,
> Johannes
>

--

Les Cargill

[Les Cargill]

This seems to work. I commented out the string
".vec1 = 1234", which isn't strictly necessary anyway
( but is a nice thing to have available ).

C:\c\usenet>cat prein.cpp

#include <stdio.h>

struct ivtlayout {
int vec1;
int vec2;
int vec3;
};

struct ivtlayout ivt = {

/*.vec1 =*/ 1234,
};

int main() {
printf("ivt.vec1=%d\n",ivt.vec1);
return 0;
}

C:\c\usenet>g++ prein.cpp

C:\c\usenet>a
ivt.vec1=1234

C:\c\usenet>

--
Les Cargill

[James Kuyper]

On 08/25/2012 11:28 AM, Johannes Bauer wrote:
> On 25.08.2012 15:35, James Kuyper wrote:
>
>>> This isn't mere pedanticism ("new" keyword, etc.), but the bare truth:
>>> Some constructs which are necessary for embedded systems are just syntax
>>> errors in C++, while they work perfectly in C.
>>
>> I can understand the necessity of using C on an embedded system if C++
>> is not available there. However, if a C++ compiler is available, I can't
>> imagine what these "necessary constructs" could be.
>
> Placing an interrupt vector table in ROM:
>
> struct ivtlayout {
> int vec1;
> int vec2;
> int vec3;
> };
>
> struct ivtlayout ivt = {
> .vec1 = 1234,
> };
>
> int main() {
> return 0;
> }
>
>> If you're talking about something non-portable, is there anything
>> preventing a C++ compiler from providing support for a corresponding
>> non-portable construct?
>
> No, definitely not. Non-portable C++ could definitely provide this. I am
> just really not a big fan of non-portable dialects. Actually, I really
> don't know why this wasn't included in c++0x.

Neither C nor C++ provides a portable way of telling the compiler to put
any particular object in ROM (though giving a const-qualified object
static storage duration certainly permits something to be placed in ROM
- and that's equally true in both languages).

If the above code is guaranteed to place anything in ROM (presumably
ivt, though that would be easier to understand if it were declared
const), that guarantee is provided by the C compiler, not the C
standard. I know of no reason why a C++ compiler couldn't make the same
guarantee for exactly the same code. If a C++ compiler were targeted to
the same platform and the same audience, I'd actually expect it to make
the same guarantee.
--
James Kuyper

[Keith Thompson]

Johannes Bauer <dfnson...@gmx.de> writes:
> On 25.08.2012 15:35, James Kuyper wrote:
>>> This isn't mere pedanticism ("new" keyword, etc.), but the bare truth:
>>> Some constructs which are necessary for embedded systems are just syntax
>>> errors in C++, while they work perfectly in C.
>>
>> I can understand the necessity of using C on an embedded system if C++
>> is not available there. However, if a C++ compiler is available, I can't
>> imagine what these "necessary constructs" could be.
>
> Placing an interrupt vector table in ROM:
>
> struct ivtlayout {
> int vec1;
> int vec2;
> int vec3;
> };
>
> struct ivtlayout ivt = {
> .vec1 = 1234,
> };
>
> int main() {
> return 0;
> }

In this particular case, you could just write:

struct ivtlayout ivt = { 1234 };

More generally, you just need to specify the member values in the order
in which they're defined.

Designated initializers are admittedly more convenient, especially when
you don't want to (or can't) make assumptions about member order.

>> If you're talking about something non-portable, is there anything
>> preventing a C++ compiler from providing support for a corresponding
>> non-portable construct?
>
> No, definitely not. Non-portable C++ could definitely provide this. I am
> just really not a big fan of non-portable dialects. Actually, I really
> don't know why this wasn't included in c++0x.

It's C++11 now. The 2011 ISO C++ standard did add a number
of features from C99, including long long, but it didn't add
designated initializers. I also don't know why they aren't in C++11
(I just checked the standard expecting to find them). VLAs and the
`restrict` keyword were also left out of C++11.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Johannes Bauer <dfnson...@gmx.de> writes:
[...]

> struct ivtlayout {
> int vec1;
> int vec2;
> int vec3;
> };
>
> struct ivtlayout ivt = {
> .vec1 = 1234,
> };
>
> int main() {
> return 0;
> }
>
>
> [~/tmp]: gcc -O2 -Wall -Wextra -std=c99 -pedantic x.c
> [~/tmp]: g++ -O2 -Wall -Wextra -std=c++0x -pedantic x.c
> x.c:8:2: Error: expected primary-expression before ».« token

At least newer versions of g++ (I have 4.7.0) give better error
messages:

c.cpp:7:24: warning: ISO C++ does not allow C99 designated initializers [-pedantic]
c.cpp:9:1: warning: missing initializer for member ‘ivtlayout::vec2’ [-Wmissing-field-initializers]
c.cpp:9:1: warning: missing initializer for member ‘ivtlayout::vec3’ [-Wmissing-field-initializers]

And "-std=c++11" is now an alias for "-std=c++0x" (or vice versa).

[Johannes Bauer]

On 25.08.2012 20:45, Les Cargill wrote:

>> Pre-initialized structures, which C provides, are for some architectures
>> I'm working in a *MUST*, since they determine the interrupt vector table
>> which gets transferred to C. C++ just does not offer this. Referring to
>> the Cortex-M3 and -M4 series here, for example (where the initial stack
>> pointer and the IVT are placed in the start of flash).
>
> I am fairly sure it is eminently possible to use pre-initialized structs
> in C++.

Please refer to this discussion a year back about exactly that issue
(the thread was called "C vs. C++: non-trivial designated initializers
not supported"):

https://groups.google.com/forum/?hl=en&fromgroups=#!topic/comp.lang.c++/HeWVpymftTg

Best regards,

[Johannes Bauer]

On 25.08.2012 21:00, James Kuyper wrote:
>> No, definitely not. Non-portable C++ could definitely provide this. I am
>> just really not a big fan of non-portable dialects. Actually, I really
>> don't know why this wasn't included in c++0x.
>
> Neither C nor C++ provides a portable way of telling the compiler to put
> any particular object in ROM (though giving a const-qualified object
> static storage duration certainly permits something to be placed in ROM
> - and that's equally true in both languages).

No, obviously not. I just need the language to be able to place a struct
somewhere, I'll handle the rest (actually, the linker will).

> If the above code is guaranteed to place anything in ROM (presumably
> ivt, though that would be easier to understand if it were declared
> const), that guarantee is provided by the C compiler, not the C
> standard. I know of no reason why a C++ compiler couldn't make the same
> guarantee for exactly the same code. If a C++ compiler were targeted to
> the same platform and the same audience, I'd actually expect it to make
> the same guarantee.

The guarantee I need is that I can initialize elements in arbitrary
order (using designated initializers). That's all. The rest is linker
magic. C does that, C++ does not.

[Les Cargill]

While that has been true for some toolchains, it's kind of not true any
more. There are .DATA , .TEXT and .BSS. The default is to put them into
RAM. If you write your own linker scripts, then you can
do what you like.
(yes, there's also the heap and the stack... )

For additional partitions, you have to use ... pragmas are other domain
dependent extensions.

> If the above code is guaranteed to place anything in ROM (presumably
> ivt, though that would be easier to understand if it were declared
> const), that guarantee is provided by the C compiler, not the C
> standard. I know of no reason why a C++ compiler couldn't make the same
> guarantee for exactly the same code. If a C++ compiler were targeted to
> the same platform and the same audience, I'd actually expect it to make
> the same guarantee.
>

If it works in 'C' the chances are excellent that it will work in C++.
The problem he had above was the construct ".vec1 = 1234," - the
".vec1 = " part is not recognized in C++. C++ forces you to declare
const memory layouts in order.

--
Les Cargill

[Keith Thompson]

Even so, the existence of a C++ implementation that generates C code
doesn't imply anything about upwards compatibility. A C program
that uses `new` as an identifier is still an invalid C++ program.

I think it's sufficient to say that the colleage was wrong (on multiple
levels).

[Johannes Bauer]

On 25.08.2012 21:09, Keith Thompson wrote:

> In this particular case, you could just write:
>
> struct ivtlayout ivt = { 1234 };
>
> More generally, you just need to specify the member values in the order
> in which they're defined.

*sigh* Obviously, yes. But that's not the point. The point is being able
to tell what vectors you want to use and not need to search through a
list of 98 vectors and hit the correct array position (which is, quite
frankly, incredibly inconvenient).

> Designated initializers are admittedly more convenient, especially when
> you don't want to (or can't) make assumptions about member order.

That is exactly the case here. There's a definition file in which all
almost 100 IRQ vectors are specified and you want to be able to say: "I
will use IRQs for DMA0 and for USART2". You don't want to look it up
somewhere and modify the 48th and 82th entry in a struct.

>>> If you're talking about something non-portable, is there anything
>>> preventing a C++ compiler from providing support for a corresponding
>>> non-portable construct?
>>
>> No, definitely not. Non-portable C++ could definitely provide this. I am
>> just really not a big fan of non-portable dialects. Actually, I really
>> don't know why this wasn't included in c++0x.
>
> It's C++11 now. The 2011 ISO C++ standard did add a number
> of features from C99, including long long, but it didn't add
> designated initializers. I also don't know why they aren't in C++11
> (I just checked the standard expecting to find them). VLAs and the
> `restrict` keyword were also left out of C++11.

Ah, yes, I still write 0x all the time. Maybe in the next revision
they'll be in.

Best regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?

> Zumindest nicht �ffentlich!
Ah, der neueste und bis heute genialste Streich unsere gro�en
Kosmologen: Die Geheim-Vorhersage.

[Johannes Bauer]

On 25.08.2012 20:50, Les Cargill wrote:

> This seems to work. I commented out the string
> ".vec1 = 1234", which isn't strictly necessary anyway
> ( but is a nice thing to have available ).

Yes, when you comment out the whole point of the example, it works.

[James Kuyper]

On 08/25/2012 11:55 AM, Jens Gustedt wrote:
> Am 25.08.2012 15:35, schrieb James Kuyper:
>> However, that was basically just a trick (and it took me a long time to
>> perfect it). As far as I know, everything that can be done using
>> portable C code can also be done by using (possibly different) C code
>> that also compiles as C++ code, with the same exact meaning in both
>> languages (exception: code like that which I described above, whose sole
>> purpose is to detect which language it was compiled in - by definition
>> such code must behave differently in order to behave correctly). Could
>> you give a counter-example?
>
> The intersection of C and C++ has
> - no decent initializers, you'd need designated initializers on the C
> side and constructors for C++

???
The claim was that use of C was a necessity, not just a convenience. C
doesn't have constructors, and designated initializers are only a
convenience feature that don't do anything that can't already be done
using ordinary initializers - they just make it more convenient.

> - no decent temporaries (compound literals for C and constructors for C++)

???
A compound literal doesn't do any thing that can't be done with an
explicitly declared and named temporary object. Again, it's just a
convenience feature.

> - no consistent way of passing dynamically sizes multi-dimensional
> arrays to functions

???
int func (double *array, rows, cols)
{
// to access column c of row r:
array[r*cols + c]

VLAs are also just a convenience feature - the don't do anything that
can't be done less conveniently by other methods.

It might just be jealousy on my part - I've never been paid to program
in an environment where I was permitted to use either designated
initializers or VLAs; I've regretted having to work within those
restrictions, but never had any trouble working around them, so the
claim that a lack of support for those features renders C++ unusable
strikes me as quite laughable.

> - no type puning (union's are standardized differently between the
> two)

Could you explain the relevant differences? There are things prohibited
in C++ unions that aren't even meaningful in C unions, but I'm not aware
of anything that C unions allow you to do that couldn't also be done in
C++. I'm willing to believe that I might have missed something, but you
need to be more specific.

> - no consistent model for function inlining

There are significant subtle differences between the two languages with
respect to inlining. However, the supposed "necessity" of programming in
C as a result of those differences would be much clearer with a
sufficiently specific example.
--
James Kuyper

[Johannes Bauer]

On 25.08.2012 21:23, Les Cargill wrote:
> While that has been true for some toolchains, it's kind of not true any
> more. There are .DATA , .TEXT and .BSS. The default is to put them into
> RAM. If you write your own linker scripts, then you can
> do what you like.
> (yes, there's also the heap and the stack... )

That is precisely what I'm doing. The example was just abbreviating the
whole thing. Actually I use some implementation defined construct to
place the const struct IVT into its own section. That section then gets
relocated to the correct place by linker magic.

> If it works in 'C' the chances are excellent that it will work in C++.
> The problem he had above was the construct ".vec1 = 1234," - the
> ".vec1 = " part is not recognized in C++. C++ forces you to declare
> const memory layouts in order.

Yes, and in this particular case it is incredibly annoying. Especially
when you have code that is portable across two devices (two interrupts,
same name, same setup, everything the same except their location in the
IVT). Since in my solution by calling them by name and including a
setup-file which specifies the CPU-specifics, it "just works". Entries
are at the correct location.

With C++ you'd have to maintain two different IVT files and have to look
that stuff up manually. And it are actually a *lot* of IRQs that these
devices offer. Pretty glad with the C solution for this one.

[James Kuyper]

On 08/25/2012 03:21 PM, Johannes Bauer wrote:
> On 25.08.2012 20:50, Les Cargill wrote:
>
>> This seems to work. I commented out the string
>> ".vec1 = 1234", which isn't strictly necessary anyway
>> ( but is a nice thing to have available ).
>
> Yes, when you comment out the whole point of the example, it works.

But the part that was commented out was pointless; if it was the point
of the example, the example had no point. Yes, I'm playing with words -
but it's also all literally true.
--
James Kuyper

[Johannes Bauer]

On 25.08.2012 21:23, James Kuyper wrote:

>> The intersection of C and C++ has
>> - no decent initializers, you'd need designated initializers on the C
>> side and constructors for C++
>
> ???
> The claim was that use of C was a necessity, not just a convenience. C
> doesn't have constructors, and designated initializers are only a
> convenience feature that don't do anything that can't already be done
> using ordinary initializers - they just make it more convenient.

By that twisted logic, every Turing complete logic has the same feature
set, since they're all Turing complete. Every syntacitical primitive is
just "convenience".

Give me a break here. That's ridiciulous. Designated initializers are
something missing from C++ and they're something that are *actually*
incredibly useful, as I can demonstrate. Obviously, you can still get it
done somehow, but this is not the point: The point is finding an
solution which minimizes effort. This is possible in C, but in this
instance it is not with C++.

[Johannes Bauer]

Alright, then, since you do understand what I'm getting at but are
unwilling to recoginze the point, here's a more complete example.
Imagine there are 3 hardware platforms (these are about 10-20 in
reality) each which have 10 IRQ vectors (these at least 100 in reality):

hw1.h:

struct ivtlayout {
int vec1;
int vec2;
int vec3;

int vec6;
int vec4;
int vec7;
int vec9;
int vec5;
int vec8;
int vec0;
};

hw2.h:
struct ivtlayout {
int vec4;
int vec2;
int vec5;
int vec8;
int vec1;
int vec3;
int vec9;
int vec0;
int vec6;
int vec7;
};

hw3.h:
struct ivtlayout {
int vec7;
int vec6;
int vec9;
int vec8;
int vec4;
int vec1;
int vec3;
int vec0;
int vec5;
int vec2;
};


Now you want to include for each version a IVT which specifies a value
for vector 8. C solution:

struct ivtlayout ivt = {
.vec8 = 1234,
};

I'll leave the C++ solution as an excersise to you. Hopefully you'll see
the point now.

Best regards,
Johannes


--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?

> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.

[James Kuyper]

On 08/25/2012 03:16 PM, Johannes Bauer wrote:
> On 25.08.2012 20:45, Les Cargill wrote:
>
>>> Pre-initialized structures, which C provides, are for some architectures
>>> I'm working in a *MUST*, since they determine the interrupt vector table
>>> which gets transferred to C. C++ just does not offer this. Referring to
>>> the Cortex-M3 and -M4 series here, for example (where the initial stack
>>> pointer and the IVT are placed in the start of flash).
>>
>> I am fairly sure it is eminently possible to use pre-initialized structs
>> in C++.
>
> Please refer to this discussion a year back about exactly that issue
> (the thread was called "C vs. C++: non-trivial designated initializers
> not supported"):
>
> https://groups.google.com/forum/?hl=en&fromgroups=#!topic/comp.lang.c++/HeWVpymftTg

The phrase "pre-initialized structs" appears to refer to structs that
are initialized at the point of definition, rather than being
initialized after being defined. Assuming that this is what you mean,
there's no problem with pre-initializing structs in C++. You can't use
designated initializers to do so, which is what that thread was about,
but you can use ordinary initializers. This is no different from C90.
--
James Kuyper

[Johannes Bauer]

On 25.08.2012 21:37, James Kuyper wrote:

>> Please refer to this discussion a year back about exactly that issue
>> (the thread was called "C vs. C++: non-trivial designated initializers
>> not supported"):
>>
>> https://groups.google.com/forum/?hl=en&fromgroups=#!topic/comp.lang.c++/HeWVpymftTg
>
> The phrase "pre-initialized structs" appears to refer to structs that
> are initialized at the point of definition, rather than being
> initialized after being defined. Assuming that this is what you mean,
> there's no problem with pre-initializing structs in C++. You can't use
> designated initializers to do so, which is what that thread was about,
> but you can use ordinary initializers. This is no different from C90.

Yes, it does. Which is also why C90 is out of the question (equally
stupid "solution" as the C++ one) and which is why I compiled my example
with -std=c99. Maintaing the mess (I kind of hint to the actual problem,
these are obviously just overly simplified examples) is just not
something that I want to do manually, and it is very error-prone. With
designated initializers there is a nice solution available in C99, but
not in C++11.

Best regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?

> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.

[James Kuyper]

On 08/25/2012 03:23 PM, Les Cargill wrote:
> James Kuyper wrote:
...

>> Neither C nor C++ provides a portable way of telling the compiler to put
>> any particular object in ROM (though giving a const-qualified object
>> static storage duration certainly permits something to be placed in ROM
>> - and that's equally true in both languages).
>>
>
> While that has been true for some toolchains, it's kind of not true any
> more. There are .DATA , .TEXT and .BSS. The default is to put them into
> RAM. If you write your own linker scripts, then you can
> do what you like.
> (yes, there's also the heap and the stack... )
>
> For additional partitions, you have to use ... pragmas are other domain
> dependent extensions.

You're probably right - for a particular set of platforms (probably a
very large and popular set of platforms), but it's not universally true.
You could probably identify that set better than I can - it would have
been completely inappropriate for me to worry about such details in any
program I've written since 1995.

...

> If it works in 'C' the chances are excellent that it will work in C++.
> The problem he had above was the construct ".vec1 = 1234," - the
> ".vec1 = " part is not recognized in C++. C++ forces you to declare
> const memory layouts in order.

It may be more convenient to be able to initialize them in arbitrary
order, but it's certainly not a necessity, as originally claimed.
--
James Kuyper

[Les Cargill]

Johannes Bauer wrote:
> On 25.08.2012 20:45, Les Cargill wrote:
>
>>> Pre-initialized structures, which C provides, are for some architectures
>>> I'm working in a *MUST*, since they determine the interrupt vector table
>>> which gets transferred to C. C++ just does not offer this. Referring to
>>> the Cortex-M3 and -M4 series here, for example (where the initial stack
>>> pointer and the IVT are placed in the start of flash).
>>
>> I am fairly sure it is eminently possible to use pre-initialized structs
>> in C++.
>
> Please refer to this discussion a year back about exactly that issue
> (the thread was called "C vs. C++: non-trivial designated initializers
> not supported"):
>
> https://groups.google.com/forum/?hl=en&fromgroups=#!topic/comp.lang.c++/HeWVpymftTg
>
> Best regards,
> Johannes
>

I stand by my statement. Indeed, I inlined some working code.
the problem continues to be that somebody is confused by
the lack of support for designated intializers. You can still have
fully initialized structs/classes; it is just that not all toolchains
support designated intializers.

--
Les Cargill

[Les Cargill]

Johannes Bauer wrote:
<snip>

> With C++ you'd have to maintain two different IVT files and have to look
> that stuff up manually. And it are actually a *lot* of IRQs that these
> devices offer. Pretty glad with the C solution for this one.
>

Sounds like 'C' is the better solution in this case.

> Best regards,
> Johannes
>
--
Les Cargill

[Johannes Bauer]

On 25.08.2012 22:02, Les Cargill wrote:
> Johannes Bauer wrote:
> <snip>
>> With C++ you'd have to maintain two different IVT files and have to look
>> that stuff up manually. And it are actually a *lot* of IRQs that these
>> devices offer. Pretty glad with the C solution for this one.
>>
> Sounds like 'C' is the better solution in this case.

Thank you ;-)

That is actually what I went for. Although it would have been more
consistent (most of the rest of the code, including the HW abstraction
library is C++), in this particular case, the solution using C was so
much more elegant, that it was implemented.

[Johannes Bauer]

On 25.08.2012 22:01, Les Cargill wrote:

> I stand by my statement. Indeed, I inlined some working code.
> the problem continues to be that somebody is confused by
> the lack of support for designated intializers. You can still have
> fully initialized structs/classes; it is just that not all toolchains
> support designated intializers.

Well, any conforming C99 *must* support designated initializers.

And, maybe I should've worded it wrong: Obviously, a solution is
possible in C++, but not an elegant one. In this particular case, the
C++ solution is so much worse that I went for C.

[Anonymous]

"Steven G. Kargl" <s...@REMOVEtroutmask.apl.washington.edu> wrote:

> On Fri, 24 Aug 2012 13:58:46 -0400, Kenneth Brody wrote:
>
> > On 8/24/2012 5:15 AM, Nick Keighley wrote:
> > [...]

> >> this whole conversation strikes me as bizzare. A kind of level
> >> confusion. It reminds of one of my collegues who came out with "C++ is
> >> upwards compatible with C because it is implemented in C" and couldn't
> >> see what was wrong with that statement.
> >

> > "Assembler must be upwards compatible with C, because 'as' is written in C."
> >
> > "FORTRAN must be upwards compatible with C, because gnu FORTRAN is written
> > in C." (I think.)
>
> The name of the language is "Fortran". It's been Fortran since
> the Fortran 1990 standard.

So what? FORTRAN is no less FORTRAN now then it was then. Perhaps he was
talking about gnu's shitty F77 compiler.

Just because people born after 1990 don't know an acronym from a proper name
doesn't change reality.

> The GNU Fortran frontend is written in C. Some of the GNU
> Fortran runtime is written in m4. The m4 files when processed
> generates Fortran code. The Fortran code is then compiled by
> GNU Fortran.

OMG no. You didn't just write "Some of the GNU Fortran runtime is written in
m4."

Oh yes you did. Just another reason not to use gnu's shitty toolchain. How
do you motherfuckers sleep at night?

Goodbye to gcc's grotesque bloat and "i was drinking that night" design,
goodbye to Stallmanesque Marxism, hello clang/LLVM!