«

On 01/13/11 10:52 AM, sandeep wrote:
> Keith Thompson writes:
>
>> C++ is not strictly upward compatible with C anyway; this reuse of an
>> obscure keyword doesn't make the situation significantly worse.
>
> In my opinion, compatibility with C++ is one of C's greatest assets. I
> recommend the ISO C body to move towards these two goals viz-a-viz C++:
>
> 1. any program that is syntactically valid both in C and C++, should have
> the same semantics in both languages

VLAs already break this gaol.

> 2. as much syntactically valid C++ as possible, should also be valid C

Shouldn't that be the other way round?

--
Ian Collins

In message <igl7r6$33a$>, sandeep <>
writes

>In my opinion, compatibility with C++ is one of C's greatest assets.

It is one of it's biggest problems.

> I
>recommend the ISO C body to move towards these two goals viz-a-viz C++:

NEVER going to happen. I would vote against it every time. As it is
parts of C99 are being made optional in C1*. If you want C and C++
compatibility change C++ to be compatible with C. Lives depend on it.

>> I believe the C and C++ committees are already in close contact.
>
>I hope you are right.

They are in close contact.

> All my reading on this subject, gives the
>impression that standards bodies pride themselves on working in glorious
>isolation!

Not at all C and C++ are different languages designed for different
things. If you want more compatibility between C and C++ you will have
to move C++ to be compatible with C
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message <>, Ian Collins <ian-
> writes
>On 01/13/11 10:52 AM, sandeep wrote:
>> Keith Thompson writes:
>>
>>> C++ is not strictly upward compatible with C anyway; this reuse of an
>>> obscure keyword doesn't make the situation significantly worse.
>>
>> In my opinion, compatibility with C++ is one of C's greatest assets. I
>> recommend the ISO C body to move towards these two goals viz-a-viz C++:
>>
>> 1. any program that is syntactically valid both in C and C++, should have
>> the same semantics in both languages
>
>VLAs already break this gaol.
>
>> 2. as much syntactically valid C++ as possible, should also be valid C
>
>Shouldn't that be the other way round?

Yes. And that is the only practical option.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On 01/13/11 11:53 AM, Chris H wrote:
> In message<igl7r6$33a$>, sandeep<>
> writes
>
>> In my opinion, compatibility with C++ is one of C's greatest assets.
>
> It is one of it's biggest problems.

Shouldn't that be the other way round?



> Not at all C and C++ are different languages designed for different
> things. If you want more compatibility between C and C++ you will have
> to move C++ to be compatible with C

In some domains, where they overlap compatibility should be considered.
Threading is probably the most important of these.

--
Ian Collins

sandeep <> writes:
> Keith Thompson writes:
>> sandeep <> writes:
[...]
>> C++ is not strictly upward compatible with C anyway; this reuse of an
>> obscure keyword doesn't make the situation significantly worse.
>
> In my opinion, compatibility with C++ is one of C's greatest assets. I
> recommend the ISO C body to move towards these two goals viz-a-viz C++:

I'd say that compatibility with C is an asset of C++ (the reverse
of what you wrote). Whether it's one of its *greatest* assets is
an open question.

> 1. any program that is syntactically valid both in C and C++, should have
> the same semantics in both languages

That's mostly true now, and the exceptions are unlikely to go away.
For example, there are good reasons for character constants to be
of type int in C and of type char in C++.

> 2. as much syntactically valid C++ as possible, should also be valid C

The only way to fully achieve that goal would be to make C a clone
of C++. C will always be (nearly) a subset of C++; that's what
the "++" means. Moving C closer to C++ just for the sake of doing
so is not particularly useful. If C++ is what you want, you know
where to find it.

[...]

>>> ===
>>> A regular expression standard library component ===
>>>
>>> Recommendation: Many programs use regular expressions, so this would be
>>> a useful addition to C's standard library, again it should be done to
>>> maintain compatibility with C++.
>>
>> C/C++ compatibility generally means that C code is valid C++ code, not
>> the other way around. C++ has lots of stuff that C doesn't (classes,
>> exceptions, templates, etc.); this regular expression library would be
>> just one more such feature.
>>
>> It *might* be sufficiently useful to add to C, but C++ compatibility
>> isn't a strong reason to do so. And it might not be C-compatible
>> anyway, for example if it's defined in terms of C++ classes. (I haven't
>> looked at it.)
>
> Don't forget that C++ classes can be emulated in C using structs with a
> vtable of function-pointers for the methods.

And requiring that kind of machinery in a C standard regexp library
would be absurd.

http://www.open-std.org/JTC1/SC22/WG...2010/n3126.pdf is
the current draft of the upcoming C++ standard. Chapter 28 covers
the regular expression library. Take a look at it, and think about
implementing something equivalent in C. (For starters, there are
dozens of occurrences of the "template" keyword.)

[...]

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Ian Collins <ian-> writes:
> On 01/13/11 10:52 AM, sandeep wrote:
>> Keith Thompson writes:
>>> C++ is not strictly upward compatible with C anyway; this reuse of an
>>> obscure keyword doesn't make the situation significantly worse.
>>
>> In my opinion, compatibility with C++ is one of C's greatest assets. I
>> recommend the ISO C body to move towards these two goals viz-a-viz C++:
>>
>> 1. any program that is syntactically valid both in C and C++, should have
>> the same semantics in both languages
>
> VLAs already break this gaol.

Just curious, was that a typo or a deliberate pun?

("Gaol" is the UK English word for what US English calls "jail"; both
are pronounced the same way, modulo regional accent.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 01/13/11 01:02 PM, Keith Thompson wrote:
> Ian Collins<ian-> writes:
>> On 01/13/11 10:52 AM, sandeep wrote:
>>> Keith Thompson writes:
>>>> C++ is not strictly upward compatible with C anyway; this reuse of an
>>>> obscure keyword doesn't make the situation significantly worse.
>>>
>>> In my opinion, compatibility with C++ is one of C's greatest assets. I
>>> recommend the ISO C body to move towards these two goals viz-a-viz C++:
>>>
>>> 1. any program that is syntactically valid both in C and C++, should have
>>> the same semantics in both languages
>>
>> VLAs already break this gaol.
>
> Just curious, was that a typo or a deliberate pun?

The former, but I like the idea of the latter more!

--
Ian Collins

sandeep wrote:

> There are many other new things too, and I would advise all members
> of the ISO C panel to think carefully about how to integrate the new
> features of C++1x, into the next version of the ISO C standard.

You might want to subscribe to comp.std.c if you want to discuss
current and future C standards.

In message <>, Ian Collins <ian-
> writes
>On 01/13/11 11:53 AM, Chris H wrote:
>> In message<igl7r6$33a$>, sandeep<>
>> writes
>>
>>> In my opinion, compatibility with C++ is one of C's greatest assets.
>>
>> It is one of it's biggest problems.
>
>Shouldn't that be the other way round?
>
>
>
>> Not at all C and C++ are different languages designed for different
>> things. If you want more compatibility between C and C++ you will have
>> to move C++ to be compatible with C
>
>In some domains, where they overlap compatibility should be considered.
>Threading is probably the most important of these.

Only if C++ moves to C. C is still very widely used on 8 and 16 bit
MCU's (which still make up the majority of processors on the planet) in
self hosted embedded systems where safety and high reliability are
required.

As it is no one and bothered to fully implement the current C99 standard
in the 12 years since it's release and in fact for the next standard
they is a move to make parts of C99 optional.... so if anything ISO-C is
going to get smaller never mind adding to it.

If you want all these extra things by all means add them to C++ and use
C++ just don't mess about with C.

What happened in the 90's was C90 harmonised and Standardised the state
of the actual compilers in use. Tightened it up 90 to 95 but from 95
to 99 they added a lot of "cool" and "useful" things that the industry
did not want.

We don't want history to repeat itself.


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Le 13/01/11 11:05, Chris H a écrit :
>
> As it is no one and bothered to fully implement the current C99 standard
> in the 12 years since it's release


No compiler fully implements the 1998 C++ standard either. There are
several almost
perfect implementations of C99: Intel, gcc, IBM and others. Partial
implementations are very common. You want to destroy C99 and reduce
C to a language for 8 bit microcontrollers. There are people that
do not agree with you.

> and in fact for the next standard
> they is a move to make parts of C99 optional.... so if anything ISO-C is
> going to get smaller never mind adding to it.
>

That is just a wish from you.

> If you want all these extra things by all means add them to C++ and use
> C++ just don't mess about with C.
>

You do not own C. And if people want to program in C and want to
ìmprove the language its their right.

> What happened in the 90's was C90 harmonised and Standardised the state
> of the actual compilers in use. Tightened it up 90 to 95 but from 95
> to 99 they added a lot of "cool" and "useful" things that the industry
> did not want.
>

IBM, Intel, gcc, and many other compilers have implemented C99. In the
microcontroller world, many implementations exists and the last time
you brought two examples of compilers from the embedded world that did
not implement C99 I could prove you that they started implementing it.