Could you please move this discussion about C and
related programming 
languages out of comp.arch.fpga. This thread has deviated considerably 
from the original posters request which was mostly on topic. Andy

Michael Wojcik wrote:
> Peter Flass wrote:
>> Michael Wojcik wrote:
>>> Peter Flass wrote:
>>>> Hey!  C's finally caught up to PL/I.  Only took them 50 years, and then
>>>> of course all the features are just tacked-on in true C fashion, instead
>>>> of thought-through.
>>> Well, that's rather insulting to the members of WG14, who spent a
>>> decade designing those features. Fortunately, they published the
>>> Rationale showing that, in fact, they were thought through.[1] And a
>>> great deal of documentation describing the process is available in the
>>> archives.[2]
>>>
>>> If you'd care to show why you think otherwise, perhaps there would be
>>> some grounds for debate.
>> "The flexible array must be last"?
> 
> Doing otherwise would break existing code. WG14's remit is to maintain
> upward compatibility.

Yes, as I said, they probably did the best they could with what they had 
to work with.

> 
>> "sizeof applied to the structure ignores the array but counts any
>> padding before it"?
> 
> I have no idea what you're quoting there. That phrase doesn't seem to
> be present in my copy of the standard.

Same reference as above, a bit farther down.  [whatever the link I was 
sent was, it got clipped somewhere]

> 
>> C is a collection of ad-hoc ideas.  WG14 may have put a great deal of
>> thought into how to extend it without breaking the existing mosh, but
>> that's my point, it's still a mosh.
> 
> If that was your point, then I have to say it was rather ill-expressed.
> 

Most of my points are ill-expressed.  I do the best I can with what I've 
got to work with, too.

[Followups restricted to a.f.c.]

Greg Menke wrote:
> Michael Wojcik <m...@newsguy.com> writes:
> 
>> Greg Menke wrote:
>>> Peter Flass <P...@Yahoo.com> writes:
>>>
>>>> C is a collection of ad-hoc ideas.  WG14 may have put a great deal of
>>>> thought into how to extend it without breaking the existing mosh, but
>>>> that's my point, it's still a mosh.
>>> iostream formatting operators, because we really need more operator
>>> overloading and no enhancements are too bizarre in service of making
>>> everything, (for particular values of everything), specialized?
>> How fortunate, then, that C does not have them.
> 
> You are quoting out of context.  

Nonsense. I quoted all of your message up to that point, and the
relevant part of Peter's.

> The original topic to which I followed up via the above quote was
> related to the sometimes "undesigned" appearance of C++.

Peter did not mention C++. My message, to which he was responding, did
not mention C++. I don't see a single reference to C++ in any of the
ancestor messages, until your own.

>  The particular
> quote above suggests C was already a collection of ad-hoc ideas, so that
> C++ is not a substantial departure from existing practice.

An odd thing to "suggest" in a conversation about C. Perhaps you
should have noted that you had decided to switch to a different topic.

[Followups restricted to a.f.c.]

Greg Menke wrote:
> Michael Wojcik <m...@newsguy.com> writes:
>> Greg Menke wrote:
>>> C++ does make for a nice "type-safe linking" C compiler.
>> Except that it's not a C implementation, and so is not a C compiler at
>> all.
>>
>> C and C++ are different languages.
> 
> Perhaps so, yet it is possible to compile C programs with a C++ 

Only some C programs. And then you are not compiling C programs with a
C++ implementation; you are compiling C++ programs that happen to be
written in the common subset of C and C++.

> and
> observe some benefits relating to better compile-time and link-time type
> checking.

There's nothing to prevent a conforming C implementation from making
similar checks, and some do. And any decent implementation, combined
with a modicum of discipline, makes this type checking unnecessary,
because the implementation's normal diagnostics will catch everything
C++-style name mangling would.

For better quality assurance, use real tools like Splint.

>  One can then disassemble the object modules created by C vs
> C++ compilers and observe the distinct similarity of with respect to the
> runtime structure.

Irrelevant. Many language implementations produce similar output.

> Which is why it "makes for a nice C compiler", not "is a better C
> compiler".

I'm well familiar with this argument - I've heard it since circa 1990,
if memory serves. I'm not convinced. Write C for C implementations,
and C++ for C++ implementations.

On Mar 9, 1:42=A0pm, Michael Wojcik
<mwoj...@newsguy.com> wrote:
> Greg Menke wrote:
>
> > C++ does make for a nice "type-safe linking" C compiler.
>
> Except that it's not a C implementation, and so is not a C compiler at
> all.
>
> C and C++ are different languages.
>

There is a subset/superset relationship between the two. Not unlike
the 8080 and Z-80, except IMO, the Z-80 is better than the 8080 and C
is better than C++.