Interview with Mr Stroustrup
sandeep
maintainer of C++, Mr B Stroustrup: http://www.codeguru.com/cpp/misc/
article.php/c18357/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm
In it he reveals that a new ISO standard for C++ will soon be available.
I believe this has many serious implications for ISO C. Here are some of
the main points.
===
I declared p without explicitly mentioning the type of p. Instead, I used
auto, which means "use the type of the initializer." So p is a
vector<pair<string,int>>::iterator. That saves a fair bit of typing and
removes the possibility of a few kinds of bugs. This is the oldest C++0x
feature; I implemented it in 1983, but was forced to take it out for C
compatibility reasons.
===
This is a major issue because auto is a keyword in C with a different
meaning! Recommendation: revise the semantics of auto in C to match C++.
So you could have:
auto fp = fopen("foo", "r"); /* fp will have type FILE*, not int */
Compilers will be able to provide switches like -traditional for legacy
code that uses auto in the old sense
===
Direct and type safe support for the traditional threads-and-locks style
of system-level concurrency. Together with a detailed memory model and
facilities for lock-free programming, this provides support for portable
and efficient concurrency.
===
Multithreading is the future - many-core processors are already becoming
the norm. Recommendation: C should follow the lead of C++ and standardize
multithreading in the same way.
===
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++.
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.
Marcin Grzegorczyk
> I have been reading a very interesting interview with the creator and
> maintainer of C++, Mr B Stroustrup: http://www.codeguru.com/cpp/misc/article.php/c18357/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm
>
> In it he reveals that a new ISO standard for C++ will soon be available.
> I believe this has many serious implications for ISO C. Here are some of
> the main points.
>
> ===
> I declared p without explicitly mentioning the type of p. Instead, I used
> auto, which means "use the type of the initializer." So p is a
> vector<pair<string,int>>::iterator. That saves a fair bit of typing and
> removes the possibility of a few kinds of bugs. This is the oldest C++0x
> feature; I implemented it in 1983, but was forced to take it out for C
> compatibility reasons.
> ===
>
> This is a major issue because auto is a keyword in C with a different
> meaning! Recommendation: revise the semantics of auto in C to match C++.
Could be a nice feature, but I very much doubt it'll happen in C1X. Are
there C compilers that already support this feature, BTW?
[...]
> ===
> Direct and type safe support for the traditional threads-and-locks style
> of system-level concurrency. Together with a detailed memory model and
> facilities for lock-free programming, this provides support for portable
> and efficient concurrency.
> ===
>
> Multithreading is the future - many-core processors are already becoming
> the norm. Recommendation: C should follow the lead of C++ and standardize
> multithreading in the same way.
I suggest you take a look at the latest C1X draft :-)
--
Marcin Grzegorczyk
Kenneth Brody
> I have been reading a very interesting interview with the creator and
> maintainer of C++, Mr B Stroustrup: http://www.codeguru.com/cpp/misc/
> article.php/c18357/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm
>
> In it he reveals that a new ISO standard for C++ will soon be available.
> I believe this has many serious implications for ISO C. Here are some of
> the main points.
>
> ===
> I declared p without explicitly mentioning the type of p. Instead, I used
> auto, which means "use the type of the initializer." So p is a
> vector<pair<string,int>>::iterator. That saves a fair bit of typing and
> removes the possibility of a few kinds of bugs. This is the oldest C++0x
> feature; I implemented it in 1983, but was forced to take it out for C
> compatibility reasons.
> ===
>
> This is a major issue because auto is a keyword in C with a different
> meaning! Recommendation: revise the semantics of auto in C to match C++.
> So you could have:
>
> auto fp = fopen("foo", "r"); /* fp will have type FILE*, not int */
>
> Compilers will be able to provide switches like -traditional for legacy
> code that uses auto in the old sense
This would require a tremendous amount of overhead AFAICT. You would, for
example, need to carry the type along with the value. And, you would have
to include runtime support for all operations on all types.
For example:
auto foo;
switch(bar)
{
case 1: foo = fopen("foo","r"); break;
case 2: foo = some_int_function(); break;
case 3: foo = some_float_function(); break;
}
foo++; /* What now? */
if ( bar == 3 )
printf("%f\n",foo); /* Promote float to double, _if_ a float. */
some_func(foo); /* How to typecheck the call? */
Or could you only assign it a value on the declaration?
auto foo = something_returning_type_X();
and the compiler would treat is as if it were:
type_X foo = something_returning_type_X();
and the type would still be a fixed type?
--
Kenneth Brody
Ian Collins
No.
> Or could you only assign it a value on the declaration?
Yes, auto is used as
auto x = expression;
The type has to be deduced at compile time, so there isn't any run time
overhead.
--
Ian Collins
Ben Pfaff
> On 1/11/2011 4:04 PM, sandeep wrote:
>> So you could have:
>>
>> auto fp = fopen("foo", "r"); /* fp will have type FILE*, not int */
>>
>> Compilers will be able to provide switches like -traditional for legacy
>> code that uses auto in the old sense
> [...]
>
> This would require a tremendous amount of overhead AFAICT. You would,
> for example, need to carry the type along with the value. And, you
> would have to include runtime support for all operations on all types.
>
> For example:
>
> auto foo;
>
> switch(bar)
> {
> case 1: foo = fopen("foo","r"); break;
> case 2: foo = some_int_function(); break;
> case 3: foo = some_float_function(); break;
> }
I think that this new 'auto' syntax is only allowed when the
variable declaration includes an initializer.
--
Ben Pfaff
http://benpfaff.org
Chris H
writes
>I have been reading a very interesting interview with the creator and
>maintainer of C++, Mr B Stroustrup:
He is not the maintainer. ISO WG21 is. This is made up or people from
many National Standards Bodies.
>In it he reveals that a new ISO standard for C++ will soon be available.
We know, everyone knows there is nothing to "reveal"
>I believe this has many serious implications for ISO C. Here are some of
>the main points.
Why? C and C++ are separate languages that went their separate ways
long before the first C standard.
>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++.
Why do we need compatibility between C and C++ they are separate
languages.
>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.
At the moment WG23 are looking at making some parts of C99 optional
never mind adding things.
What C++ does is up to WG21 it does not mean that WG14 has to follow it
at all.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Keith Thompson
> I have been reading a very interesting interview with the creator and
> maintainer of C++, Mr B Stroustrup: http://www.codeguru.com/cpp/misc/
> article.php/c18357/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm
>
> In it he reveals that a new ISO standard for C++ will soon be available.
> I believe this has many serious implications for ISO C. Here are some of
> the main points.
>
> ===
> I declared p without explicitly mentioning the type of p. Instead, I used
> auto, which means "use the type of the initializer." So p is a
> vector<pair<string,int>>::iterator. That saves a fair bit of typing and
> removes the possibility of a few kinds of bugs. This is the oldest C++0x
> feature; I implemented it in 1983, but was forced to take it out for C
> compatibility reasons.
> ===
>
> This is a major issue because auto is a keyword in C with a different
> meaning! Recommendation: revise the semantics of auto in C to match C++.
> So you could have:
>
> auto fp = fopen("foo", "r"); /* fp will have type FILE*, not int */
>
> Compilers will be able to provide switches like -traditional for legacy
> code that uses auto in the old sense
It's not that big a deal. The existing "auto" keyword in C is
never necessary, and is almost never used. The new C++ feature,
of being able to infer the type of a declared object from the type
of its initializer, might be nice to have, but it's not as useful
in C as it is in C++; usually in C you already know the type.
C++ is not strictly upward compatible with C anyway; this reuse of an
obscure keyword doesn't make the situation significantly worse.
> ===
> Direct and type safe support for the traditional threads-and-locks style
> of system-level concurrency. Together with a detailed memory model and
> facilities for lock-free programming, this provides support for portable
> and efficient concurrency.
> ===
>
> Multithreading is the future - many-core processors are already becoming
> the norm. Recommendation: C should follow the lead of C++ and standardize
> multithreading in the same way.
C201X already proposes to add threading. I don't know how similar
it is to C++ threading.
> ===
> 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.)
> 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.
I believe the C and C++ committees are already in close contact.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <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"
BartC
news:igigks$rp7$1...@speranza.aioe.org...
> I have been reading a very interesting interview with the creator and
> maintainer of C++, Mr B Stroustrup: http://www.codeguru.com/cpp/misc/
> article.php/c18357/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm
>
> In it he reveals that a new ISO standard for C++ will soon be available.
> I believe this has many serious implications for ISO C. Here are some of
> the main points.
>
> ===
> I declared p without explicitly mentioning the type of p. Instead, I used
> auto, which means "use the type of the initializer." So p is a
> vector<pair<string,int>>::iterator. That saves a fair bit of typing and
> removes the possibility of a few kinds of bugs. This is the oldest C++0x
> feature; I implemented it in 1983, but was forced to take it out for C
> compatibility reasons.
> ===
>
> This is a major issue because auto is a keyword in C with a different
> meaning! Recommendation: revise the semantics of auto in C to match C++.
> So you could have:
>
> auto fp = fopen("foo", "r"); /* fp will have type FILE*, not int */
>
> Compilers will be able to provide switches like -traditional for legacy
> code that uses auto in the old sense
Or we can just use a different keyword; 'auto' isn't exactly the most apt.
Is auto meant also for initialising from literals? Because I can't see it
working too well in code like this:
signed int a = 42;
unsigned int b = 42;
signed short c = 42;
unsigned short d = 42;
signed char e = 42;
unsigned char f = 42;
signed long long g = 42;
unsigned long long h = 42;
float x = 42.0
double y = 42.0
char *s = "abcdef";
char t[] = "abcdef";
If all the type-specs are replaced by 'auto' (or something better..), then
the literals, even with a few 'L' and 'LL' modifiers, would be hard-pressed
to represent exactly the type needed in each case.
And string literals have similar problems.
Would auto x[n]=y create an array of whatever type y is? In that case y
would be the wrong initialiser... So presumably names declared with auto
can't be formed into pointers, arrays and functions as can normal
declarations, at least not in the same declaration.
Even when initialising from an expression with a specific type, I can see
problems:
auto F = fopen(...) // from your example
If a variable G needed to match the type of F, how would that be done? Would
something like this be needed:
typeof(F) G; // ?
And if the type of G was hardcoded, then there would be problems when the
initialiser for F changed type.
--
Bartc
Ian Collins
The original proposal is here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf
--
Ian Collins
Jorgen Grahn
...
>>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++.
>
> Why do we need compatibility between C and C++ they are separate
> languages.
I think almost all C++ programmers and many C programmers want some
degree of compatibility, but what he's talking about is something
else.
If we started importing C++ features into C, I doubt these brand new
regex classes would be first in line -- before RAII, operator
overloading, the standard containers ...
You see where this is leading: if you want C++, use a C++ compiler.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
sandeep
Yes, but consistently using the auto keyword could be very helpful in
futureproofing code. For example, if the return type of fopen would
change in the future, then the code above could just be recompiled
without any changes and it would still work.
> 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
2. as much syntactically valid C++ as possible, should also be valid C
>> ===
>> Direct and type safe support for the traditional threads-and-locks
>> style of system-level concurrency. Together with a detailed memory
>> model and facilities for lock-free programming, this provides support
>> for portable and efficient concurrency.
>> ===
>>
>> Multithreading is the future - many-core processors are already
>> becoming the norm. Recommendation: C should follow the lead of C++ and
>> standardize multithreading in the same way.
>
> C201X already proposes to add threading. I don't know how similar it is
> to C++ threading.
This is a good proposal, hopefully it will agree in all respects with the
C++ proposal.
>> ===
>> 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.
>> 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.
>
> I believe the C and C++ committees are already in close contact.
I hope you are right. All my reading on this subject, gives the
impression that standards bodies pride themselves on working in glorious
isolation!
Ian Collins
> 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
Chris H
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 H
ne...@hotmail.com> writes
Yes. And that is the only practical option.
Ian Collins
> In message<igl7r6$33a$1...@speranza.aioe.org>, sandeep<nos...@nospam.com>
> 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
Keith Thompson
>> 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/WG21/docs/papers/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
> 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.)
Ian Collins
> Ian Collins<ian-...@hotmail.com> 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
Noob
> 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.
Chris H
ne...@hotmail.com> writes
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.
jacob navia
>
> 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.
Ian Collins
> In message<8p6q9s...@mid.individual.net>, Ian Collins<ian-
> ne...@hotmail.com> writes
>> On 01/13/11 11:53 AM, Chris H wrote:
>>
>>> 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.
That is why I said compatibility should be considered where C and C++
overlap.
> 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.
Sun did.
> If you want all these extra things by all means add them to C++ and use
> C++ just don't mess about with C.
Well if C is to have a future on all but the smallest single core
processors, threading should be considered, at least as an option.
> 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.
Just as we don't want C to be left behind. The C++ standard has adapted
to modern hardware by incorporating threading into the core language and
the C1x drafts do likewise.
--
Ian Collins
Chris H
<ja...@spamsink.net> writes
>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.
There are a lot of very good C90 implementations There are a few
partial implementations of C99. Most were C90+ now we are (over a
decade on ) starting to get C99- compilers.
> You want to destroy C99 and reduce
>C to a language for 8 bit microcontrollers. There are people that
>do not agree with you.
But the majority do agree. That is the majority who pay money and buy
compilers. Hence the industry has done what people want. C95
>
>> 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.
And it seems the ISO-C WG who are making things optional.
>> 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.
That was the argument use by those who took C95 and destroyed it by
making C99
>
>> 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.
Intel IBM and GC have partial implementations (like many others) who
have C90+ compilers.
>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.
Yes.... Over a DECADE after the C99 you can show that they are
*STARTING* to implement *SOME* of it. Meanwhile ISO-C WG is making parts
of C99 "optional" In the 2007 meeting of the ISO-C-WG in London it was
discussed dropping parts of C99 altogether. The compromise is to make
them "optional"
When C1* comes out people will move to that and C99 will be come the
standard that never was because even if you implement full C1* it will
not be a superset of C99.
The industry has voted with it's feet.
Chris H
ne...@hotmail.com> writes
>> If you want all these extra things by all means add them to C++ and use
>> C++ just don't mess about with C.
>
>Well if C is to have a future on all but the smallest single core
>processors, threading should be considered, at least as an option.
C is used on 8-128 bit systems and many of them have been multi core for
a decade. Also they have had multiple threads and multi tasking with and
without an RTOS.
>> 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.
>
>Just as we don't want C to be left behind. The C++ standard has adapted
>to modern hardware by incorporating threading into the core language
>and the C1x drafts do likewise.
Why? It is not needed for the majority and those that do need it seem to
have coped very well with multi threading and multiple cores for a long
while so far.
tm
> In message <igmj73$sa...@speranza.aioe.org>, jacob navia
> <ja...@spamsink.net> writes
>
> >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.
>
> There are a lot of very good C90 implementations There are a few
> partial implementations of C99. Most were C90+ now we are (over a
> decade on ) starting to get C99- compilers.
C99 just went in the wrong direction.
C is often used as "portable assembler". Many other
languages use C as base (to implement interpreters,
compilers and runtime libraries). Some compilers even
generate C instead of machine code. To support this
areas C could add features like:
- portable threading support.
- exception handling (with the possibility to switch it
off).
- possibility to check integer overflow, but keeping
the current behaviour, if desired. When overflow
checking is part of the language it is possible to
support it with no overhead when the hardware has
overflow trap).
- Move some Posix functions like reading directories
to the C standard.
- Support for closures (AFAIK gcc already supports them).
- Hints for the probability of conditions (gcc already
supports this feature). This way the programmer can
help to optimize a program.
Greetings Thomas Mertes
--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
jacob navia
> On 13 Jan., 11:29, Chris H<ch...@phaedsys.org> wrote:
>> In message<igmj73$sa...@speranza.aioe.org>, jacob navia
>> <ja...@spamsink.net> writes
>>
>>> 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.
>>
>> There are a lot of very good C90 implementations There are a few
>> partial implementations of C99. Most were C90+ now we are (over a
>> decade on ) starting to get C99- compilers.
>
> C99 just went in the wrong direction.
True
> C is often used as "portable assembler". Many other
> languages use C as base (to implement interpreters,
> compilers and runtime libraries). Some compilers even
> generate C instead of machine code. To support this
> areas C could add features like:
>
> - portable threading support.
lcc-win gives you access to threads provided by the OS. I am
doubtful if all the code written for pthreads or windows
threads will be rewritten to cater for yet another standard
> - exception handling (with the possibility to switch it
> off).
lcc-win provides you that. I have been proposing that
since 8 or more years to comp.std.c. No answer.
> - possibility to check integer overflow, but keeping
> the current behaviour, if desired. When overflow
> checking is part of the language it is possible to
> support it with no overhead when the hardware has
> overflow trap).
lcc-win implements that. I have been proposing that for eight years too.
No answer.
> - Move some Posix functions like reading directories
> to the C standard.
Yes, that would be a good idea.
> - Support for closures (AFAIK gcc already supports them).
Why you need that?
Can you give an example?
> - Hints for the probability of conditions (gcc already
> supports this feature). This way the programmer can
> help to optimize a program.
I do not think that a language standard can go so far in compiler
internals.
Ben Bacarisse
> Le 13/01/11 13:42, tm a écrit :
<snip>
>> - Support for closures (AFAIK gcc already supports them).
AFAIK Apple has a version of gcc that does this, but it's not in gcc
itself.
> Why you need that?
> Can you give an example?
You have one yourself. In the documentation for your container library,
you implement mapcar. Look at the huge amount of "machinery" you need
in C to do this (including a static object that will cause problems in a
threaded program). Re-write it using, say, Apple's blocks[1] and you
should see the advantage.
[1] http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/10
--
Ben.
Rui Maciel
>> If you want all these extra things by all means add them to C++ and use
>> C++ just don't mess about with C.
>
> Well if C is to have a future on all but the smallest single core
> processors, threading should be considered, at least as an option.
What's wrong with relying on standards for threads, such as pthreads?
There is no reason to push something into a particular standard when that
very same feature is already defined by another standard.
Rui Maciel
TonyMc
>> 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.)
"For a gaol can give you a goal"
-- "Mad Man Moon", from "Trick of the Tail" by Genesis
--
Tony
Walter Banks
Rui Maciel wrote:
> Ian Collins wrote:
>
> > Well if C is to have a future on all but the smallest single core
> > processors, threading should be considered, at least as an option.
>
> What's wrong with relying on standards for threads, such as pthreads?
> There is no reason to push something into a particular standard when that
> very same feature is already defined by another standard.
There is a good point here. Standards are supposed to incorporate
standard practice. Threads should reflect standard practice and
standards need a champion who understands the issues and has
the intellectual integrity to evaluate the implications of adopting
current practice.
The later is one of the reasons that standards take time. Papers
advocating technology and positions (and counter position papers
as well) need to be presented and debated by those in the field
who understand the implications. In general WG-14 has done
that quite well having a in depth debates. The diverse interests
and international nature of standards groups generally prevents
self interests from being able to dominate.
Regards,
w..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
Walter Banks
jacob navia wrote:
> > - exception handling (with the possibility to switch it
> > off).
>
> lcc-win provides you that. I have been proposing that
> since 8 or more years to comp.std.c. No answer.
Jacob you have often advocated good ideas. To your
credit most of your ideas are backed by practice
Standards groups work with material that is brought before
them in the form of papers and counter papers whose merits
are debated. Standards come out of those debates.
To have an impact on standards you need become involved
or find someone to advocate your ideas as part of the
standards group meetings.
John Bode
[snip]
> 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
>
Why? Should the same also hold for other related languages like, for
example, Pascal and Oberon?
C and C++ semantics diverged long enough ago that trying to line them
up again would break at least some legacy code on either side. What's
the payoff in making that change? How does it benefit anyone?
> 2. as much syntactically valid C++ as possible, should also be valid C
Again, why? They're two different languages. They happen to share a
lot of history, but in the end they have different goals and governing
philosophies. A well-written C program doesn't look or act very much
like a well-written C++ program, and for good reason.
Compatibility just for compatibility's sake doesn't make much sense.
Point to a solid *technical* reason why they should remain closely
compatible and we'll talk.
[snip]
tm
> Le 13/01/11 13:42, tm a crit :
> > C is often used as "portable assembler". Many other
> > languages use C as base (to implement interpreters,
> > compilers and runtime libraries). Some compilers even
> > generate C instead of machine code. To support this
> > areas C could add features like:
>
> > - portable threading support.
>
> > lcc-win gives you access to threads provided by the OS.
I want portable support for threads, not the threads
provided by the OS. I want that my threaded standard C
programs are portable. I don't care if it is pthreads or
something else. Probably it makes sense to take the
proposed C++ thread standard (when it is not template
or class based).
> I am
> doubtful if all the code written for pthreads or windows
> threads will be rewritten to cater for yet another standard
So am I. :-) The people can continue to use the OS
dependend threads. They are not standard C anyway, but
standard C threads allow future programs to be portable.
[snip]
> > - Support for closures (AFAIK gcc already supports them).
>
> Why you need that?
> Can you give an example?
We all use closures all the time without realizing.
Examples of closures are:
The conditions of a while loop
The statements in loop bodies
The statements that are conditionally executed in
an if statement.
Closures are expressions and they might be executed
once, many times or not at all. They differ from normal
function pointers, but they can be implemented with
function pointers.
There are several programming languages that compile
to C and which support closures. Closure support in C
would make the job of this compilers easier.
In case of Seed7 I have already implemented closure
support in the Seed7 compiler. So I do not really need it,
but it would simplify many things. Probably a C compiler
would have to do similar things that the Seed7 compiler,
therefore I describe the strategy here:
First it must be decided if a function with closure
parameter is called recursively. A non-recursive function
with closure parameters can be implemented with inlining.
Recursive functions cannot be implemented this way.
Implementing closures with function pointers works this
way. A function pointer together with an environment data
structure is used. A call of the closure parameter is
compiled to calling the function (via function pointer)
and giving this function a pointer to the environment
data as parameter.
The actual closure parameter must be analyzed to find
out which local variables (and parameters) it uses.
This local variables are the environment data of the
actual closure parameter.
This is just a general concept, the devil is in the
details.
> > - Hints for the probability of conditions (gcc already
> > supports this feature). This way the programmer can
> > help to optimize a program.
>
> I do not think that a language standard can go so far in compiler
> internals.
This is not compiler internals. It is like the register
keyword. Based on the gcc support I defined the macros
likely and unlikely. So a program can contain code like
if (unlikely((abc = malloc(sizeof(qwert))) == NULL)) {
/* out of memory */
...
} else {
/* okay */
...
The programmer has defenitely more knowledge about how
often an out of memory situation occurs. When a compiler
is not able to support this feature, it can just be ignored.
Richard
> On 13 Jan., 14:39, jacob navia <ja...@spamsink.net> wrote:
>> Le 13/01/11 13:42, tm a crit :
>> > C is often used as "portable assembler". Many other
>> > languages use C as base (to implement interpreters,
>> > compilers and runtime libraries). Some compilers even
>> > generate C instead of machine code. To support this
>> > areas C could add features like:
>>
>> > - portable threading support.
>>
>> > lcc-win gives you access to threads provided by the OS.
>
> I want portable support for threads, not the threads
> provided by the OS. I want that my threaded standard C
> programs are portable. I don't care if it is pthreads or
> something else. Probably it makes sense to take the
> proposed C++ thread standard (when it is not template
> or class based).
So I am guessing you dont give a shit about efficiency for example?
How many of your apps are ported to multiple architectures?
Tobias Blass
>1. any program that is syntactically valid both in C and C++, should have
>the same semantics in both languages
>
>2. as much syntactically valid C++ as possible, should also be valid C
Is not the extern "C" { } declaration exactly that? If you have valid C code in
a C++ program and want to have C semantics? It seems strange to me to make C a
clone of C++ just to save a line of code (plus the closing brace) for C++
programmers.
Seebs
> Why? It is not needed for the majority
And all the world's a VAX.
> and those that do need it seem to
> have coped very well with multi threading and multiple cores for a long
> while so far.
That's a major portability barrier, though, for code which wants to do that.
If the language had a decent spec for it, we wouldn't have that problem.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
Ben Bacarisse
> On Wed, 12 Jan 2011, sandeep wrote:
>>1. any program that is syntactically valid both in C and C++, should have
>>the same semantics in both languages
>>
>>2. as much syntactically valid C++ as possible, should also be valid C
>
> Is not the extern "C" { } declaration exactly that? If you have valid
> C code in a C++ program and want to have C semantics?
No, extern "C" just alters the details of the linage of external names.
It has no effect on the semantics of any code contained functions
defined within it.
<snip>
--
Ben.
Keith Thompson
> In message <igmj73$sa7$1...@speranza.aioe.org>, jacob navia
> <ja...@spamsink.net> writes
>>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.
>
> There are a lot of very good C90 implementations There are a few
> partial implementations of C99. Most were C90+ now we are (over a
> decade on ) starting to get C99- compilers.
My understanding is that there are several conforming C99
implementions. For example, Intel has claimed that their icc is
fully conforming, and I think the same claim has been made for
lcc-win; there are others (no gcc isn't one of them). (My use of
the word "claim" is not meant to cast doubt, merely to emphasize
that I haven't personally verified anything.)
I'm not disputing your main point that C99 adoption has been slow.
[...]
tm
You are guessing WRONG. I care about efficiency. You seem
to think something like pthreads=emulated=inefficient.
I am not a threading expert, but AFAIK Linux supports a
pthread interface for its native threads. I am NOT
interested in another emulated thread library (which
just runs on one processor). Instead I am interested in
a portable access to the real (native) threads of the OS.
There is also portabe access to the filesystem of the OS.
I see no reason why this cannot be done for threads?
> How many of your apps are ported to multiple architectures?
Seed7 runs under Linux, Bsd, various Unix variants, Mac OS
and Windows. The source code of Seed7 is written in C and
can be compiled with gcc, MS visual C and the Borland C
compiler. The Seed7 compiler generates C code which is
subsequently compiled to machine code. This way Seed7
programs can be as efficient as C programs (when advanced
Seed7 features like OO with multiple dispatch are not used).
The Seed7 runtime library contains many parts that
compensate for OS and compiler differences. Seed7
supports portable interfaces for many things. See:
http://seed7.sourceforge.net/faq.htm#portable
Ian Collins
> In message<8p820h...@mid.individual.net>, Ian Collins<ian-
> ne...@hotmail.com> writes
I see you have stopped asserting no one has a conforming C99
implementation. That's a start.
>> Well if C is to have a future on all but the smallest single core
>> processors, threading should be considered, at least as an option.
>
> C is used on 8-128 bit systems and many of them have been multi core for
> a decade. Also they have had multiple threads and multi tasking with and
> without an RTOS.
I know, I've used a fair few of them and I've also had to port between
almost as many threading implementations!
>>> 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.
>>
>> Just as we don't want C to be left behind. The C++ standard has adapted
>> to modern hardware by incorporating threading into the core language
>> and the C1x drafts do likewise.
>
> Why? It is not needed for the majority and those that do need it seem to
> have coped very well with multi threading and multiple cores for a long
> while so far.
Library support and core language support are two different beasts.
While they both support portability, some desirable features require
language support.
Do you object to the threading support in the C1x draft?
The C++ community has certainly embraced the support for threads in
C++0x as a long overdue feature for a modern programming language. I'm
really surprised people object to the additions to C.
--
Ian Collins
Keith Thompson
No. In C++, anything surrounded by extern "C" { } is callable from C,
but the code itself is still C++ code. For example, this:
extern "C" {
int class;
}
is a syntax error in C++ (and in C, because C doesn't have extern "C").
extern "C" is a mechanism for interfacing between *separately compiled*
C and C++ code.
For more information (which isn't really topical
in comp.lang.c), see section 32 of the "C++ FAQ" at
<http://www.parashift.com/c++-faq-lite/>.
Joshua Maurice
I believe that the new C standard for threading closely follows the
new C++ standard, and vice versa. They've been in close contact. I
base the rest of my reply on my knowledge from the C++ side.
The goal has been to provide a portable interface implementable on all
hardware which support threads, including supporting obscure stuff
like data dependency loads for the crazy DEC-Alpha. This is also while
not paying for what you not use - writing the data dependency load vs
a naked load won't hurt performance on an x86.
Obviously, those who use other thread interfaces such as pthreads can
and will be able to continue to do so, but future apps will be able to
use the standard C threads interface.
Joshua Maurice
Several reasons.
First, I think we'd all like an implemented and portable threading
interface so we don't have to roll our own abstraction layer. There's
a lot of subtle nuance in the several threading libraries which make
it non-trivial to wrap.
Second, threading really ought to be part of the programming language
standard as it directly affects and constrains the code generation of
the compiler. A library like a GUI doesn't impose any particular
noteworthy restrictions on the compiler, but threading is inextricably
tied to compilation, optimization, and code generation.
Third, from my knowledge of win32 threads, pthreads, and the barriers
of the linux kernel, I personally very much welcome this new standard
as it's much more formalized. There is such a lack of knowledge in the
community as to how threading actually works. I meet people every day
who think that volatile is still a portably useful threading
primitive. Trying to reason about how the compiler operate when
throwing inline assembly at it with pthreads is also quite difficult.
The new standard is much more complete, sane, and useful.
I've seen people using gcc inline assembly to do a read and write
barriers, and argue whether the "memory" clobber is used or not, and
whether volatile will make it work in the absence of the "memory"
clobber. With this new standard, you might even get better
optimization as opposed to gcc's current interface as the compiler
will be able to do something more fine grain than the correct "memory"
clobber, and it will still have the correct behavior unlike the case
of no "memory" clobber.
AFAIK, it has been standardized to be implementable on all hardware
such that "you don't pay for what you don't use". Specifically, if you
write your data dependent loads correctly in the C source, your code
will work on the DEC-alpha, and you won't suffer any performance
penalties where it's not needed such as the x86.
Alan Curry
Ian Collins <ian-...@hotmail.com> wrote:
>
>Just as we don't want C to be left behind. The C++ standard has adapted
>to modern hardware by incorporating threading into the core language and
>the C1x drafts do likewise.
If anything like pthreads gets added, and fork() doesn't, it'll be a tragedy.
One of the great benefits of modern hardware is protected memory. fork
gives you multiple threads of execution without throwing away that benefit.
To give up protected memory in the name of "adapting to modern hardware" is
ridiculous.
--
Alan Curry
Joshua Maurice
> If anything like pthreads gets added, and fork() doesn't, it'll be a tragedy.
>
> One of the great benefits of modern hardware is protected memory. fork
> gives you multiple threads of execution without throwing away that benefit.
> To give up protected memory in the name of "adapting to modern hardware" is
> ridiculous.
Well, I think that's more to do with that not all operating systems
natively support a Posix-like fork - eg: win32, whereas all current
threading models are sufficiency similar to allow standardization.
If we're talking about a much more generic process spawn equivalent,
then I agree that would be nice to have. It would be nice for the
reasons you state, and it would be nice even if I was programming only
on unix-like systems to avoid the bugs in Posix fork.
Finally, see my other posts else-thread for other reasons which apply
to threads but don't apply to processes. Threading is inextricably
tied to code generation, so it really ought to be in the same standard
document that constrains the rest of the code generation of the
compiler, whereas the existence of and the use of processes don't
really constrain the code generation of a compiler.
Ben Pfaff
> In article <8p820h...@mid.individual.net>,
> Ian Collins <ian-...@hotmail.com> wrote:
>>
>>Just as we don't want C to be left behind. The C++ standard has adapted
>>to modern hardware by incorporating threading into the core language and
>>the C1x drafts do likewise.
>
> If anything like pthreads gets added, and fork() doesn't, it'll be a tragedy.
Threads affect the language a lot more than fork() does. It's a
lot easier to add fork() as an afterthought than it is to add
threads.
--
Ben Pfaff
http://benpfaff.org
Thomas Richter
> In article <8p820h...@mid.individual.net>,
> Ian Collins <ian-...@hotmail.com> wrote:
>> Just as we don't want C to be left behind. The C++ standard has adapted
>> to modern hardware by incorporating threading into the core language and
>> the C1x drafts do likewise.
>
> If anything like pthreads gets added, and fork() doesn't, it'll be a tragedy.
>
> One of the great benefits of modern hardware is protected memory.
C as well as C++ also operates on hardware that *does not have*
protected memory, though offers threads. The fork() primitive requires a
lot of support from the operating system, and support some (if not even
the majority of the operating systems I know) do not offer.
Greetings,
Thomas
Tobias Blass
Of course it is easy to add fork() on some platforms, but I think including
threads to the standard but fork() not would make fork() look like some 2nd
class threading, so people would always use threading instead of several
processes. Of course there are some scenarios were threads are actually better
than processes ( e.g. scientific calculations), but in most of the cases
processes with separated address spaces lead to programs much easier to debug and to maintain. Wouldn't it be possible to add a clone(2)-like library function where you can specify how much you want to share with your child process. You had to find a way how to support separated data on platforms without separated process memory, but couldn't you just handle per process data like a variable with prefix? (So if the programmer says "I want to have 2 processes, one containing var1 and one containig var2" you could simulate it by dividing your programs memory and only refer to the memory used by the simulated process you're in)
I have no experience with writing compilers or operating systems, so the
approach may be quite naive, but I would be glad to hear some feedback where I'm
wrong
Ian Collins
>
>
> On Thu, 13 Jan 2011, Ben Pfaff wrote:
>
>> pac...@kosh.dhis.org (Alan Curry) writes:
>>
>>> In article<8p820h...@mid.individual.net>,
>>> Ian Collins<ian-...@hotmail.com> wrote:
>>>>
>>>> Just as we don't want C to be left behind. The C++ standard has adapted
>>>> to modern hardware by incorporating threading into the core language and
>>>> the C1x drafts do likewise.
>>>
>>> If anything like pthreads gets added, and fork() doesn't, it'll be a tragedy.
>>
>> Threads affect the language a lot more than fork() does. It's a
>> lot easier to add fork() as an afterthought than it is to add
>> threads.
>> --
>> Ben Pfaff
>> http://benpfaff.org
>>
> Of course it is easy to add fork() on some platforms, but I think including
> threads to the standard but fork() not would make fork() look like some 2nd
> class threading, so people would always use threading instead of several
> processes.
It's not a matter of 1st and 2nd class threading, it's a more matter of
code generation and optimisation, see Joshua Maurice's posts to this thread.
There's more to thread support than just creating threads.
--
Ian Collins
Alan Curry
In other words, threads with protected memory (i.e. fork) get along well
with the language, and threads without protected memory (i.e. pthread)
completely screw it up and force the programmer and the compiler to do
much more complicated things to compensate for the anything-goes shared
address space.
And this is an argument *for* non-protected-memory threads?
--
Alan Curry
Ian Collins
Threads exist, get over it.
Some applications suit threads, some suit processes. Because process
don't required core language support they can be added purely as a
library extension.
Isn't it better to have the compiler do the complicated things rather
than force every programmer to do them?
--
Ian Collins
tm
> jacob navia <ja...@spamsink.net> writes:
> > Le 13/01/11 13:42, tm a écrit :
> <snip>
> >> - Support for closures (AFAIK gcc already supports them).
>
> AFAIK Apple has a version of gcc that does this, but it's not in gcc
> itself.
Ok. BTW, the proposed C++ support for closures looks
also interesting.
James Kuyper
...
> 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++:
>
> the same semantics in both languages
This program contains two modules and one shared header. It's very
carefully designed to make many different points in a program that is as
small as possible. I make no claim that this represents good programming
practice:
shared.h:
=========
#ifndef SHARED_H
#define SHARED_H
extern char tag;
extern int enumer[2];
typedef void voidvoid(void);
int Cnmtyp(void);
int Cfunc(voidvoid*);
#endif
First module:
=============
#ifdef __cplusplus
extern "C" {
#endif
#include "shared.h"
char tag = 0;
static int hidden(voidvoid *pfunc)
{
(*pfunc)();
tag = sizeof 'C' == sizeof(int);
return Cnmtyp() && enumer[0] && enumer[1];
}
int Cfunc(voidvoid* pfunc)
{
struct tag
{
enum { enumer, other } in;
int integer;
} out;
out.integer = sizeof(tag) == 1 && sizeof(enumer) == sizeof out.in;
return hidden(pfunc) && out.integer;
}
#ifdef __cplusplus
}
#endif
Second module:
==============
#ifdef __cplusplus
extern "C" {
#endif
#include "shared.h"
int enumer[2] = {0, 1};
static void Cppname_Cpptype(void)
{
enumer[0] = sizeof 'C' == 1;
return;
}
#ifdef __cplusplus
}
#endif
int Cnmtyp(void)
{
struct tag
{
enum { enumer, other } in;
int integer;
} out;
out.integer = sizeof(enumer) == 2 * sizeof(int);
return out.integer && sizeof(tag) == sizeof out;
}
static voidvoid Cppname_Ctype;
static void Cppname_Ctype(void) {
Cppname_Cpptype();
}
int main(void) {
return Cfunc(&Cppname_Ctype) && tag;
}
Both modules contain syntactically valid code: according to C99, C++98,
and C++03, together they constitute strictly conforming C code, and
well-formed C++ code. The behavior of code containing __cplusplus is
technically undefined under C90, but for most (all?) fully conforming
C90 compilers, the behavior is exactly as if it were not a reserved
identifier, and not a pre-#defined macro. For any such C90 compiler, the
only code that would otherwise constitute a syntax error will be dropped
by the #if's.
You can compile both modules in C, or both in C++; the resulting
executables are guaranteed by the relevant standards to exit with a
failure status, for quite different reasons in each case. If you compile
the first module in C, and the second in C++, and the two compilers are
compatible, then the modules can be linked together; in that case, the
executable will exit with success status. Unfortunately, if you do it
the other way around, they cannot be linked.
Why does it matter which language is used for each module? Because three
of the comparison operators are guaranteed to have a different value,
depending upon whether the module is compiled as C or C++. The other two
comparisons will have the same value in both languages only in the
unlikely event that sizeof(int)==1. I'll leave it as an exercise for the
reader to figure out why these statements are true.
Please note that, while this code is VERY contrived, it depends upon
very deep principles of the two languages. For every single comparison
operator in the above code, guaranteeing that it would be true in both
languages would break a lot of code in one of the two languages.
So, if you want the semantics of this program to be the same in both
languages, what should they be?
Rui Maciel
> Several reasons.
>
> First, I think we'd all like an implemented and portable threading
> interface so we don't have to roll our own abstraction layer.
That's what a standard is for. The POSIX threads standard is pretty clear
on it's purpose: to implement a standard API to handle threads. If some
people keep ignoring a standard for over 15 years then what good will it
do if yet another standard is defined to deal with this very same issue?
> There's
> a lot of subtle nuance in the several threading libraries which make
> it non-trivial to wrap.
That's why we have for over a decade a standard for an API designed to
handle threads.
> Second, threading really ought to be part of the programming language
> standard as it directly affects and constrains the code generation of
> the compiler. A library like a GUI doesn't impose any particular
> noteworthy restrictions on the compiler, but threading is inextricably
> tied to compilation, optimization, and code generation.
I don't believe this to be any relevant. There is a standard that defines
an API to handle threads. I don't see any reason why the people dedicated
in developing a programming language would be forced to ignore an API when
they try to add support for a particular feature.
> Third, from my knowledge of win32 threads, pthreads, and the barriers
> of the linux kernel, I personally very much welcome this new standard
> as it's much more formalized.
What's wrong with pthreads? And what do you mean by "more formalized"?
> There is such a lack of knowledge in the
> community as to how threading actually works. I meet people every day
> who think that volatile is still a portably useful threading
> primitive. Trying to reason about how the compiler operate when
> throwing inline assembly at it with pthreads is also quite difficult.
> The new standard is much more complete, sane, and useful.
That's irrelevant. It has nothing to do with any API and everything to do
with the people in your anectodal example. A standard doesn't force any
knowledge on anyone remotely related to a subject, which means that
adopting a current standard or inventing a new one will have absolutely no
impact on this issue.
> I've seen people using gcc inline assembly to do a read and write
> barriers, and argue whether the "memory" clobber is used or not, and
> whether volatile will make it work in the absence of the "memory"
> clobber. With this new standard, you might even get better
> optimization as opposed to gcc's current interface as the compiler
> will be able to do something more fine grain than the correct "memory"
> clobber, and it will still have the correct behavior unlike the case
> of no "memory" clobber.
>
> AFAIK, it has been standardized to be implementable on all hardware
> such that "you don't pay for what you don't use". Specifically, if you
> write your data dependent loads correctly in the C source, your code
> will work on the DEC-alpha, and you won't suffer any performance
> penalties where it's not needed such as the x86.
That's irrelevant. The pthreads standard defines an API. The
implementaton details are left to the programming language and underlying
platforms. If there is a need to define any behavior of a given
programming language then this issue should be dealt by the people who
dedicate their time to manage that programming language. Yet, defining
behavior which has been previously left undefined does not force anyone to
design a new standard API from scratch while ignoring an established
standard designed for this very purpose.
Rui Maciel
Rui Maciel
> Library support and core language support are two different beasts.
> While they both support portability, some desirable features require
> language support.
It's quite possible to work on the definition of a programming language in
order to better support some features desired by some developers,
including those involved in developing libraries, without being forced to
bloat the standard by incorporating any definition on how exactly those
libraries should behave.
> Do you object to the threading support in the C1x draft?
The question which must be asked regarding pushing a definition of a
particular library into the C standard is "why?" and not "why not?". Any
addition to a programming language must be thoroughly justified, which has
not been the case.
> The C++ community has certainly embraced the support for threads in
> C++0x as a long overdue feature for a modern programming language. I'm
> really surprised people object to the additions to C.
Apples and oranges. There was no international standard that defined an
API to handle threads in C++. Adding to that, although it was possible to
handle threads with the pthreads library in a C++ program, there were
always a few issues plaguing it's use, which forced the programmer to jump
through a hand full of proverbial hoops just to make things work.
So, unequivocally the C++ programming language needed a dedicated standard
that defined a native C++ API for threads. Unfortunately the C++ people
failed to follow time-proven best practices on how to implement libraries
and simply made the mistake of bolting this new C++ threads standard onto
the definition of the C++ programming language.
Rui Maciel
Rui Maciel
> Well, I think that's more to do with that not all operating systems
> natively support a Posix-like fork - eg: win32, whereas all current
> threading models are sufficiency similar to allow standardization.
If I'm not mistaken, the reason behind Microsoft's failure to adopt
standard interfaces for basic features such as threading isn't due to any
technical issue that they failed to overcome.
Considering this, I don't believe that pushing a standard definition of a
particular API into the C standard will force Microsoft (and any other
company that shares their motivations) to offer a decent, standard API for
that particular feature.
<snip/>
> Finally, see my other posts else-thread for other reasons which apply
> to threads but don't apply to processes. Threading is inextricably
> tied to code generation, so it really ought to be in the same standard
> document that constrains the rest of the code generation of the
> compiler, whereas the existence of and the use of processes don't
> really constrain the code generation of a compiler.
If the C programming language needs any behavior to be defined in order to
be able to implement a particular library or a feature which is provided
by an underlying platform then it is clear that it is a good idea to
define whatever behavior needs to be defined. Yet, that doesn't force
anyone to push an entire definition of an API into the standard definition
of that particular programming language. Moreover, if we consider that
this API is designed to handle a feature which already benefits from an
API defined through a international standard for the past 15 years or so,
things become a bit more unjustifiable.
Rui Maciel
Joshua Maurice
As opposed to a piecemeal reply, let me make it short.
First, pthreads threads is a highly informal standard compared to the
proposed C++ semantics. There are several dark corners in pthreads
where the behavior is less than clear. It's badly specified. The new
proposed C++0x standard goes a lot better in clarifying corner cases
of what does and does not work. Please see:
http://www.hpl.hp.com/techreports/2008/HPL-2008-56.pdf
for a comprehensive review of the new threading standard. There's a
couple of places in the doc which describe the ambiguity of the
current pthreads standard, and at least one point where nearly all
POSIX pthreads implementations are glaringly not conforming to the
pthreads standard (see: "3. Making Trylock Efficient" in the above
link).
Second, it's not complete. It doesn't specify Linux kernel calls read,
write, and data dependent barriers, what C++0x calls
memory_order_consume,
memory_order_acquire,
memory_order_release,
memory_order_acq_rel,
It also lacks a way to say "No, I really know what I'm doing, and this
race condition is harmless" which C++0x calls
memory_order_relaxed,
And to make everyone's life easier, you can specify that the memory
operation participates in the global ordering, aka that it's
"sequentially consistent"
memory_order_seq_cst
Posix pthreads doesn't support any of that except memory_order_acq_rel
(or is it memory_order_seq_cst?), which sometimes results in people
going to the assembly for what the Linux kernel calls read, write, and
data dependency barriers. This leads to fun conversations between
experts on what exactly is going on, such as:
http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/fcef57c539a42ef5/be98b8ef87ff64a4
Does the volatile do anything? Obviously not portably, but will it
make your compiler + implementation on your hardware produce the
correct results? Do you need gcc's "memory" clobber or not for that
inline assembly? Frankly, this kind of stuff isn't documented
anywhere. You could spend days talking to the actual compiler writers
and consult your chipsets assembly docs, but even after that you
probably won't know for sure. I for one think this is an entirely
unsatisfactory state of affairs.
I suppose you could spruce up pthreads to do this, but it seems that
they have not. I /think/ that the C and C++ committees have been in
contact with the POSIX pthreads people. How do the pthreads people
feel about this standardization? Why haven't they updated POSIX
pthreads to fix the known issues and more formalize their model, and
add read, write, data dependent barriers? I wonder if the POSIX people
thought it would be better to put this stuff in the C and C++
standards.
Third, I want portable threading that everyone supports. It's
unfortunate that a certain OS decides to not support it out of the
box. However, does it make sense to talk about pthreads conformance
without the broader scope of POSIX conformance? Windows will never be
POSIX conformant, but it might supply a conforming pthreads interface.
Is the POSIX pthreads standard set up to allow Windows to claim
"pthreads" compliance without any other part of POSIX?
Fourth, as a minor point, I still think that it makes sense to put
something so critical and inherent to compiler code generation into
the language standard and not leave it to a separate standard. It
would be ridiculous if malloc and friends were in a different standard
than the C standard, or if typedef was in a different standard than
the C standard. The same is true of threading. It's so integral to the
language from a user point of view and implementer point of view that
it ought to be in the same standard. (I would argue that the same is
true of "shared objects" aka "shared libraries" aka "DLLs".)
Joshua Maurice
> > Well, I think that's more to do with that not all operating systems
> > natively support a Posix-like fork - eg: win32, whereas all current
> > threading models are sufficiency similar to allow standardization.
>
> If I'm not mistaken, the reason behind Microsoft's failure to adopt
> standard interfaces for basic features such as threading isn't due to any
> technical issue that they failed to overcome.
>
> Considering this, I don't believe that pushing a standard definition of a
> particular API into the C standard will force Microsoft (and any other
> company that shares their motivations) to offer a decent, standard API for
> that particular feature.
Slightly out of context. That was a rationale for why threads should
go in, but POSIX fork should not. "Sufficiently similar on all
platforms" is a necessary requirement for standardization in the C and
C++ standards, but it's not a sufficient one.
I do admit that this was a rather compelling argument. If it just
became another "C++ export" or supported everywhere but windows, then
I agree it would be rather silly to do. (Apart from fixing all of the
problems in POSIX pthreads and adding read, write, and data dependent
barriers, of course.)
However, Herb Sutter seems to be all for this new threading API, and
hopefully he'll bring Microsoft along. Also, googling has found this
one link from Microsoft
http://www.infoq.com/news/2010/12/visualc-angst
which gives some hope that they actually will implement it, as opposed
to POSIX pthreads. So, at worst, it's a game of politics, and if it
takes moving threading from one standard to another to ensure a
portable API usable everywhere, I'll play the politics.
> > Finally, see my other posts else-thread for other reasons which apply
> > to threads but don't apply to processes. Threading is inextricably
> > tied to code generation, so it really ought to be in the same standard
> > document that constrains the rest of the code generation of the
> > compiler, whereas the existence of and the use of processes don't
> > really constrain the code generation of a compiler.
>
> If the C programming language needs any behavior to be defined in order to
> be able to implement a particular library or a feature which is provided
> by an underlying platform then it is clear that it is a good idea to
> define whatever behavior needs to be defined. Yet, that doesn't force
> anyone to push an entire definition of an API into the standard definition
> of that particular programming language.
In the case of threading, there is no other way. In order to define
the necessary semantics of the C language, it's akin to just defining
the threading API. The same is true for POSIX pthreads. The
restrictions on a POSIX pthreads conforming implementation are made in
terms of the pthreads API and observable behavior.
> Moreover, if we consider that
> this API is designed to handle a feature which already benefits from an
> API defined through a international standard for the past 15 years or so,
> things become a bit more unjustifiable.
C++0x threads is much more than that. It's not just a refurbished
POSIX pthreads. We get what the Linux kernel calls read, write, and
data dependency barriers as well. We also get "sequentially
consistent" or "acquire and release" semantics, whichever POSIX
pthreads doesn't specify. (I forget which offhand.)
Also, again I ask: can you talk about POSIX pthreads compliance
without the context of a larger POSIX compliance? That is, can someone
claim "pthreads compliant" without any other POSIX compliance, or
would the POSIX people be unhappy and sue? A minor point, but an
interesting one in this game of politics.
Chris H
s.com>, tm <thomas...@gmx.at> writes
>On 13 Jan., 14:39, jacob navia <ja...@spamsink.net> wrote:
>> Le 13/01/11 13:42, tm a crit :
>> > C is often used as "portable assembler". Many other
>> > languages use C as base (to implement interpreters,
>> > compilers and runtime libraries). Some compilers even
>> > generate C instead of machine code. To support this
>> > areas C could add features like:
>>
>> > - portable threading support.
>>
>> > lcc-win gives you access to threads provided by the OS.
>
>I want portable support for threads, not the threads
>provided by the OS. I want that my threaded standard C
>programs are portable.
Portable from 8-128 bit MCUs?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Chris H
.com>, tm <thomas...@gmx.at> writes
>> How many of your apps are ported to multiple architectures?
>
>Seed7 runs under Linux, Bsd, various Unix variants, Mac OS
>and Windows.
What about VMS, MuCos, SAFERTOS, EmbOS, Sciopta, Integrity, ThreadX,
OSE, VXWorks, QNX, CMX, eCOS, OSEK, LynxOS, Nutrino, Nucleus, PikeOS
pSOS,Velocity and many others....
>The source code of Seed7 is written in C and
>can be compiled with gcc, MS visual C and the Borland C
>compiler.
IAR, Keil, ARM, Cosmic, Bytecraft, ImagCraft, Crossware, IBM, Intel,
SUN,
SO basically he ports to Windows and UNIX and uses one of three
compilers... That is NOT "portable"
Chris H
u...@mib.org> writes
>Chris H <ch...@phaedsys.org> writes:
>> In message <igmj73$sa7$1...@speranza.aioe.org>, jacob navia
>> <ja...@spamsink.net> writes
>>>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.
>>
>> There are a lot of very good C90 implementations There are a few
>> partial implementations of C99. Most were C90+ now we are (over a
>> decade on ) starting to get C99- compilers.
>
>My understanding is that there are several conforming C99
>implementions. For example, Intel has claimed that their icc is
>fully conforming, and I think the same claim has been made for
>lcc-win; there are others (no gcc isn't one of them). (My use of
>the word "claim" is not meant to cast doubt, merely to emphasize
>that I haven't personally verified anything.)
>
>I'm not disputing your main point that C99 adoption has been slow.
Thanks... So Intel, Lcc and It think Sun That is three compilers out of
dozens. I think you are probably looking at less than 3% take up of C99
as a full implementation which is my point.
C90 standardised what the industry did. Everyone went ISO-C90 compliant
very quickly.
C99 added a whole lot of "cool" and "nice" things that no one really
wanted or needed. At least not enough for anyone to spend any time and
money on them.
BartC
"Chris H" <ch...@phaedsys.org> wrote in message
news:xYvKg+Bb...@phaedsys.demon.co.uk...
> In message <0a317981-b91d-4078...@w2g2000yqb.googlegroups
> .com>, tm <thomas...@gmx.at> writes
>>> How many of your apps are ported to multiple architectures?
>>
>>Seed7 runs under Linux, Bsd, various Unix variants, Mac OS
>>and Windows.
>
> What about VMS, MuCos, SAFERTOS, EmbOS, Sciopta, Integrity, ThreadX,
> OSE, VXWorks, QNX, CMX, eCOS, OSEK, LynxOS, Nutrino, Nucleus, PikeOS
> pSOS,Velocity and many others....
>
>>The source code of Seed7 is written in C and
>>can be compiled with gcc, MS visual C and the Borland C
>>compiler.
>
> IAR, Keil, ARM, Cosmic, Bytecraft, ImagCraft, Crossware, IBM, Intel,
> SUN,
>
>
> SO basically he ports to Windows and UNIX
And MacOS.
> and uses one of three
> compilers... That is NOT "portable"
It's pretty good going. The restriction on compilers seems to be be to do
with having to provide specific makefiles for each.
What does it mean exactly to write a portable application in C? Surely you
can't expect someone (especially of free software) to test on dozens on
different compilers and dozens of different architectures? Who does?
Testing on a small number of different systems I'd have thought would at
least show it's not tied to one OS, one compiler, one architecture, a good
prerequisite for portability.
And are there any good examples of sizeable portable C apps, that do run on
*all* of those architectures and compilers you mentioned? (And if there are,
my bet is they would largely consist of a mess of conditional code,
conditional makefiles and conditional scripts.)
--
Bartc
tm
> In message <0a317981-b91d-4078-9456-8ed5b4e4a...@w2g2000yqb.googlegroups
> .com>, tm <thomas.mer...@gmx.at> writes
>
> >> How many of your apps are ported to multiple architectures?
>
> >Seed7 runs under Linux, Bsd, various Unix variants, Mac OS
> >and Windows.
>
> What about VMS, MuCos, SAFERTOS, EmbOS, Sciopta, Integrity, ThreadX,
> OSE, VXWorks, QNX, CMX, eCOS, OSEK, LynxOS, Nutrino, Nucleus, PikeOS
> pSOS,Velocity and many others....
How many programs are ported to all this operating systems?
Which programs are ported to this operating systems and do graphics,
use Unicode filenames, read directories, wait for milliseconds,
position the curser in a console window and read single characters
from a console window without echo?
This are things that go byond what standard C provides.
So you need operating system specific functions to do this things.
Seed7 provides driver libraries for all this things. A Seed7
program can do this things and the programmer does not need to
think about the OS used. Seed7 is not a language where you are
forced to use operating system functions for such simple tasks.
Seed7 tries to provide an OS independend platform.
You can help to port Seed7 to one of this operating systems by
writing the driver libraries.
jacob navia
> On 14 Jan., 21:02, Chris H<ch...@phaedsys.org> wrote:
>> In message<0a317981-b91d-4078-9456-8ed5b4e4a...@w2g2000yqb.googlegroups
>> .com>, tm<thomas.mer...@gmx.at> writes
>>
>>>> How many of your apps are ported to multiple architectures?
>>
>>> Seed7 runs under Linux, Bsd, various Unix variants, Mac OS
>>> and Windows.
>>
>> What about VMS, MuCos, SAFERTOS, EmbOS, Sciopta, Integrity, ThreadX,
>> OSE, VXWorks, QNX, CMX, eCOS, OSEK, LynxOS, Nutrino, Nucleus, PikeOS
>> pSOS,Velocity and many others....
>
> How many programs are ported to all this operating systems?
To VMS?
I -suppose none since it is quite dead. Digital went broke and was
bought by compaq. Then compaq was bought by hp. So VMS...
MucOs is an OS for avionics controllers. Yes, it supports real
time. I think the license is around 2.5K US$, so do not
expect a huge user community
Most of the others are the same.
Chris H
>> In message <0a317981-b91d-4078-9456-8ed5b4e4a...@w2g2000yqb.googlegroups
>> .com>, tm <thomas.mer...@gmx.at> writes
>>
>> >> How many of your apps are ported to multiple architectures?
>>
>> >Seed7 runs under Linux, Bsd, various Unix variants, Mac OS
>> >and Windows.
>>
>> What about VMS, MuCos, SAFERTOS, EmbOS, Sciopta, Integrity, ThreadX,
>> OSE, VXWorks, QNX, CMX, eCOS, OSEK, LynxOS, Nutrino, Nucleus, PikeOS
>> pSOS,Velocity and many others....
>
>How many programs are ported to all this operating systems?
Very little.
>Which programs are ported to this operating systems and do graphics,
>use Unicode filenames, read directories, wait for milliseconds,
>position the curser in a console window and read single characters
>from a console window without echo?
They all have their own systems for the above No one will use a new
system in ISO-C. It will be yet another non implimented part fo teh
standard.
>Seed7 provides driver libraries for all this things. A Seed7
>program can do this things and the programmer does not need to
>think about the OS used.
Inefficient. Most of those systems have the functionality already built
in. No point in duplicating it. All that does is take space, time and
power.
> Seed7 is not a language where you are
>forced to use operating system functions for such simple tasks.
>Seed7 tries to provide an OS independend platform.
So it will work on ALL the above OS? Otherwise it is not portable. So
far it is a specialised windows/Unix system.
>You can help to port Seed7 to one of this operating systems by
>writing the driver libraries.
Ok. Do you want do know my consultancy rates first?
Chris H
<b...@freeuk.com> writes
>
>
>"Chris H" <ch...@phaedsys.org> wrote in message news:xYvKg+BbvKMNFAY1@p
>haedsys.demon.co.uk...
>> In message <0a317981-b91d-4078...@w2g2000yqb.googlegroups
>> .com>, tm <thomas...@gmx.at> writes
>>>> How many of your apps are ported to multiple architectures?
>>>
>>>Seed7 runs under Linux, Bsd, various Unix variants, Mac OS
>>>and Windows.
>>
>> What about VMS, MuCos, SAFERTOS, EmbOS, Sciopta, Integrity, ThreadX,
>> OSE, VXWorks, QNX, CMX, eCOS, OSEK, LynxOS, Nutrino, Nucleus, PikeOS
>> pSOS,Velocity and many others....
>>
>>>The source code of Seed7 is written in C and
>>>can be compiled with gcc, MS visual C and the Borland C
>>>compiler.
>>
>> IAR, Keil, ARM, Cosmic, Bytecraft, ImagCraft, Crossware, IBM, Intel,
>> SUN,
>>
>>
>> SO basically he ports to Windows and UNIX
>
>And MacOS.
Which is essentially BSD Unix
>> and uses one of three
>> compilers... That is NOT "portable"
>
>It's pretty good going. The restriction on compilers seems to be be to
>do with having to provide specific makefiles for each.
No idea. Not used a make file in years. However that is nothing to do
with the code being portable.
>What does it mean exactly to write a portable application in C? Surely
>you can't expect someone (especially of free software)
The free part is irrelevant.
>to test on dozens on different compilers and dozens of different
>architectures? Who does?
Good point. Virtually no one. SO why is there al this crap about
portability. Particularly when most of these new features are going to
be of zero use on many MCU and OS.
This was C99's great failing. Things were added that were "cool" or
"neat" etc for a *FEW* people not the majority. Hence the near zero take
up of C99.
>Testing on a small number of different systems I'd have thought would
>at least show it's not tied to one OS, one compiler, one architecture,
>a good prerequisite for portability.
Not at all. It means it is portable across a SMALL subset. You should
not add things that are not 100% portable to all or at least the vast
majority of compilers (and OS) otherwise you get another C99.... a
standard that no one uses.
>And are there any good examples of sizeable portable C apps, that do
>run on *all* of those architectures and compilers you mentioned? (And
>if there are, my bet is they would largely consist of a mess of
>conditional code, conditional makefiles and conditional scripts.)
There are some libraries etc that do. Yes they use conditional code but
it is all Standard C. some of the things you want to add could not be
implemented in compilers for many targets.
Remember the x86 market makes up less than 5% of the MCU's out there.
IAR for example make compilers for 35 targets (not x86) of the about 60
compilers we can supply (8-64bit) non are x86 and most would not want
threading.
BTW none of the 60 odd compilers are C99. Despite the silly claims by
Jacob all they do is implement a few/some features that customers want.
IF the industrial world really wanted C99 all the commercial compilers
would have had conforming c99 compilers by December 2000. Ie eleven
years ago.
Nick Keighley
> Le 15/01/11 00:45, tm a crit :
>
> > On 14 Jan., 21:02, Chris H<ch...@phaedsys.org> wrote:
> >> In message<0a317981-b91d-4078-9456-8ed5b4e4a...@w2g2000yqb.googlegroups
> >> .com>, tm<thomas.mer...@gmx.at> writes
>
> >>>> How many of your apps are ported to multiple architectures?
>
> >>> Seed7 runs under Linux, Bsd, various Unix variants, Mac OS
> >>> and Windows.
>
> >> What about VMS, MuCos, SAFERTOS, EmbOS, Sciopta, Integrity, ThreadX,
> >> OSE, VXWorks, QNX, CMX, eCOS, OSEK, LynxOS, Nutrino, Nucleus, PikeOS
> >> pSOS,Velocity and many others....
>
> > How many programs are ported to all this operating systems?
>
> To VMS?
yes, including VMS struck me as a bit odd
> I -suppose none since it is quite dead. Digital went broke and was
> bought by compaq. Then compaq was bought by hp. So VMS...
there ar still VAX/VMS emulators out there.I know of an application
that runs it's compiler on such an emulator
tm
> In message <ea301f8b-265f-47f7-b3ff-338ef4c17...@15g2000vbz.googlegroups
> .com>, tm <thomas.mer...@gmx.at> writes
>
> >On 14 Jan., 21:02, Chris H <ch...@phaedsys.org> wrote:
> >> In message <0a317981-b91d-4078-9456-8ed5b4e4a...@w2g2000yqb.googlegroups
> >> .com>, tm <thomas.mer...@gmx.at> writes
>
> >> >> How many of your apps are ported to multiple architectures?
>
> >> >Seed7 runs under Linux, Bsd, various Unix variants, Mac OS
> >> >and Windows.
>
> >> What about VMS, MuCos, SAFERTOS, EmbOS, Sciopta, Integrity, ThreadX,
> >> OSE, VXWorks, QNX, CMX, eCOS, OSEK, LynxOS, Nutrino, Nucleus, PikeOS
> >> pSOS,Velocity and many others....
>
> >How many programs are ported to all this operating systems?
>
> Very little.
According to your definition this are the only portable
programs.
> >Which programs are ported to this operating systems and do graphics,
> >use Unicode filenames, read directories, wait for milliseconds,
> >position the curser in a console window and read single characters
> >from a console window without echo?
>
> They all have their own systems for the above
So portable programs need to use #ifdef or other forms
of conditional code to distinguish between this different
solutions.
> >Seed7 provides driver libraries for all this things. A Seed7
> >program can do this things and the programmer does not need to
> >think about the OS used.
>
> Inefficient.
In todays programs there are many areas were performance
is wasted. In case of Seed7 you get portable Seed7
programs at the cost of a function layer in the Seed7
runtime library.
> Most of those systems have the functionality already built
> in.
So you need to change your program when you move to a
different operating system. Do you consider this portable
programming? Porting a program without changing it is the
key point: It is NOT necessary to change a Seed7 program
when you move it from Windows to Linux or between other
operating systems supported by Seed7.
> > Seed7 is not a language where you are
> >forced to use operating system functions for such simple tasks.
> >Seed7 tries to provide an OS independend platform.
>
> So it will work on ALL the above OS?
No, but on the systems I mentioned already.
> Otherwise it is not portable.
With your definition almost nothing is portable.
For nontrivial programs there will ALWAYS be an OS or
compiler that does NOT support the particular program.
> So far it is a specialised windows/Unix system.
Windows, Mac OSX, Linux, Bsd and Unix combined
probably cover 99% of the PC, Workstation and
Minicomputer market. As others already pointed out VMS
is dying and even IBM is moving towards Unix/Linux.
> >You can help to port Seed7 to one of this operating systems by
> >writing the driver libraries.
>
> Ok. Do you want do know my consultancy rates first?
No. Sorry to say, but there are people I would prefer,
when I have to pay them. But I always appreciate when
programming for an opern source project is done for free.
Sherm Pendley
> On 15 Jan., 11:18, Chris H <ch...@phaedsys.org> wrote:
>> In message <ea301f8b-265f-47f7-b3ff-338ef4c17...@15g2000vbz.googlegroups
>> .com>, tm <thomas.mer...@gmx.at> writes
>>
>> >On 14 Jan., 21:02, Chris H <ch...@phaedsys.org> wrote:
>>
>> >How many programs are ported to all this operating systems?
>>
>> Very little.
>
> According to your definition this are the only portable
> programs.
I've never interpreted "portable" to mean that a program *has* been
ported to every possible OS, but rather that it *could* be.
After all, a portable radio is made no less portable by the fact that
I leave it on a shelf rather than carrying it around.
sherm--
--
Sherm Pendley
<http://camelbones.sourceforge.net>
Cocoa Developer
BartC
news:f1d9a3bc-efd4-4fb6...@w29g2000vba.googlegroups.com...
> On 15 Jan., 11:18, Chris H <ch...@phaedsys.org> wrote:
>> Most of those systems have the functionality already built
>> in.
>
> So you need to change your program when you move to a
> different operating system. Do you consider this portable
> programming? Porting a program without changing it is the
> key point: It is NOT necessary to change a Seed7 program
> when you move it from Windows to Linux or between other
> operating systems supported by Seed7.
There's the portability of Seed7, and the portability of the underlying C
code.
I would guess that Seed7 does 'portable' much better than C, where sometimes
a program has trouble working on the same architecture and the same machine
(or even with the same compiler, if exactly the right options and makefile
scripts are not used; I think these do form part of an application, even if
Chris H says they don't).
But then, there is only one source of Seed7; if other people created another
implementation, working from the same language spec, it would be interesting
to see whether the portability would still hold up.
>> So far it is a specialised windows/Unix system.
>
> Windows, Mac OSX, Linux, Bsd and Unix combined
> probably cover 99% of the PC, Workstation and
> Minicomputer market.
A few years ago when I was a proper programmer, 99% of *my* market was
Windows. Such hardware was available everywhere, it was cheap, and it was
popular. And most customers already had it. If they didn't, then many
customers would simply buy whatever we said they needed.
A few odd customers with Macs apparently got on well using a Windows
emulator. To the 1% (actually nearer 0.1%) who wanted Linux versions, we
just said no. (These days the figures would be different.)
So from that point of view, it's possible to simply not care about
portability. Someone (Chris H I think) said 95% of microprocessors in the
world are not x86. But so what?
If there is an advantage in porting an application from A to B, then it will
get ported. Writing it in the first place so that it will run on A, B, C,
all the way to system Z, means it will either never get finished, or it
would cost too much, or the quality would suffer.
--
Bartc
Keith Thompson
[...]
> This was C99's great failing. Things were added that were "cool" or
> "neat" etc for a *FEW* people not the majority. Hence the near zero take
> up of C99.
Then why is C201X, as least as of the current draft, keeping *all*
the features that C99 added, and making only a tiny fraction of
them optional?
The Foreword to the C99 standard lists 54 changes relative to the
C90 standard (if I've counted correctly). (A few were added by
C95, and a number of them are relatively minor.) The C201X drafts
we've seen so far propose to make only 3 of them optional (complex
types, VLAs, and <tgmath.h>); everything else is still mandatory.
That doubles the number of optional features; C99 already has
__STDC_IEC_559__, __STDC_IEC_559_COMPLEX__, and __STDC_ISO_10646__.
And of course most of the standard library has been optional for
freestanding implementations since C90.
It seems to me that the mandatory subset of C201X is much closer
to C99 than it is to C90. And of course the full C201X language,
with optional features enabled, is essentially a superset of C99.
Note that gcc, for example, already implements at least two of the
three newly optional features; if the gcc maintainers choose to
fully support C201X, they'll surely continue to support at least
those optional features. I suspect that most other almost-C99
compilers are in a similar position.
VLAs can be nice, but you can do the same thing with malloc() and
free(), with a little extra bookkeeping work (and the benefit of
being able to check for allocation failures, at least theoretically).
Complex types are useful for the relatively few programs that need
them, but they're really a niche feature. I haven't checked, but
I presume there are libraries that implement complex arithmitic in
C90, at the cost of losing a lot of syntactic sugar.
I'm frankly not sure I've ever seen the point of <tgmath.h>, other
than some minor syntactic convenience. If the machinery it uses
were available to user code, that might be a different matter,
but what's so hard about writing sinf() or sinl()? Perhaps I'm
missing something.
Meanwhile, all conforming C201X compilers will support long
long, <stdint.h>, mixed declarations and statement, // comments,
restricted pointers, compound literals, designated initializers,
inline functions, and dozens of other features that don't exist
in C90.
So what's the big deal? C201X, at least in the drafts we've
seen so far, is *not* going back to C90 and starting over.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <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"
lawrenc...@siemens.com
>
> I'm frankly not sure I've ever seen the point of <tgmath.h>, other
> than some minor syntactic convenience. If the machinery it uses
> were available to user code, that might be a different matter,
> but what's so hard about writing sinf() or sinl()? Perhaps I'm
> missing something.
If you decide you need more or less precision, changing the types of the
variables automatically changes the precision of the arithmetic
operators, but not the library functions (which are typically used
almost as often as the operators), so you have to search through all
your code and manually replace them. <tgmath.h> allows the library
functions to be as versatile as the operators.
And the C1X draft finally makes a similar mechanism available to user
code.
--
Larry Jones
Everything's gotta have rules, rules, rules! -- Calvin
Keith Thompson
> Keith Thompson <ks...@mib.org> wrote:
>>
>> I'm frankly not sure I've ever seen the point of <tgmath.h>, other
>> than some minor syntactic convenience. If the machinery it uses
>> were available to user code, that might be a different matter,
>> but what's so hard about writing sinf() or sinl()? Perhaps I'm
>> missing something.
>
> If you decide you need more or less precision, changing the types of the
> variables automatically changes the precision of the arithmetic
> operators, but not the library functions (which are typically used
> almost as often as the operators), so you have to search through all
> your code and manually replace them. <tgmath.h> allows the library
> functions to be as versatile as the operators.
Ok, that makes sense.
>
> And the C1X draft finally makes a similar mechanism available to user
> code.
Hmm. Then I wonder what's the benefit of making <tgmath.h> optional, if
the mechanism is mandatory.
Ian Collins
> Ian Collins wrote:
>
>> Library support and core language support are two different beasts.
>> While they both support portability, some desirable features require
>> language support.
>
> It's quite possible to work on the definition of a programming language in
> order to better support some features desired by some developers,
> including those involved in developing libraries, without being forced to
> bloat the standard by incorporating any definition on how exactly those
> libraries should behave.
>
>
>> Do you object to the threading support in the C1x draft?
>
> The question which must be asked regarding pushing a definition of a
> particular library into the C standard is "why?" and not "why not?". Any
> addition to a programming language must be thoroughly justified, which has
> not been the case.
You've completely missed my point, so I'll say it again:
While they both support portability, some desirable features require
language support.
I'm talking the core language, not the library.
(I really which the standard was in two parts, the core language and the
standard library, so one could be updated without the other!)
>> The C++ community has certainly embraced the support for threads in
>> C++0x as a long overdue feature for a modern programming language. I'm
>> really surprised people object to the additions to C.
>
> Apples and oranges. There was no international standard that defined an
> API to handle threads in C++.
Again, you miss the point.
--
Ian Collins
Joshua Maurice
> Ian Collins wrote:
> > The C++ community has certainly embraced the support for threads in
> > C++0x as a long overdue feature for a modern programming language. I'm
> > really surprised people object to the additions to C.
>
> Apples and oranges. There was no international standard that defined an
> API to handle threads in C++. Adding to that, although it was possible to
> handle threads with the pthreads library in a C++ program, there were
> always a few issues plaguing it's use, which forced the programmer to jump
> through a hand full of proverbial hoops just to make things work.
>
> So, unequivocally the C++ programming language needed a dedicated standard
> that defined a native C++ API for threads.
I don't think I'm understanding some of the nuance of your argument.
Do you really think that using pthreads in C++ code isn't practicable?
In my experience, it's almost trivial to do so - it's as easy in C++
as it is in C. To which hoops are you referring?
> Unfortunately the C++ people
> failed to follow time-proven best practices on how to implement libraries
> and simply made the mistake of bolting this new C++ threads standard onto
> the definition of the C++ programming language.
I want to emphasize what Ian has said else-thread that if the library
in question has serious restrictions on the language and on code
generation of a compiler, then that ought to be in the language
standard. It's not like we're proposing to throw process spawning,
GUI, or other "library" stuff into the language standard. Threading in
practice cannot be implemented as a library. It must have core
compiler/language support.
Sebastian
>
> I want to emphasize what Ian has said else-thread that if the library
> in question has serious restrictions on the language and on code
> generation of a compiler, then that ought to be in the language
> standard. It's not like we're proposing to throw process spawning,
> GUI, or other "library" stuff into the language standard. Threading in
> practice cannot be implemented as a library. It must have core
> compiler/language support.
...for what exactly? Can you be more specific? What "core language"
features do we need for "thread support"? What *is* "thread support"?
Are we talking threads, mutexes, locks, condition variables only or
does it include support for lock-free programming/atomics? If you
include the latter in "thread support" I would agree that it's
probably a better idea to implement atomics with some sort of core
language feature / "compiler magic" rather than a library-only
solution for the sake of implementability & performance.
Cheers!
SG
Marcin Grzegorczyk
> lawrenc...@siemens.com writes:
>>[on <tgmath.h>]
>> And the C1X draft finally makes a similar mechanism available to user
>> code.
>
> Hmm. Then I wonder what's the benefit of making <tgmath.h> optional, if
> the mechanism is mandatory.
AFAIK, MISRA wanted that because of potential undefined behaviour if
you, say, pass a pointer argument (N1256 7.22, footnote 273). But with
the generic selection construct in C1X, it's easy to write <tgmath.h> in
such way that this kind of mistake is a syntactic constraint violation,
so IMHO there is no benefit. In some sense, <tgmath.h> is optional
anyway -- for freestanding implementations.
I'll be surprised if __STDC_NO_TGMATH__ makes it into C1X.
--
Marcin Grzegorczyk
Niklas Holsti
> On 16 Jan., 09:35, Joshua Maurice wrote:
>> I want to emphasize what Ian has said else-thread that if the library
>> in question has serious restrictions on the language and on code
>> generation of a compiler, then that ought to be in the language
>> standard. It's not like we're proposing to throw process spawning,
>> GUI, or other "library" stuff into the language standard. Threading in
>> practice cannot be implemented as a library. It must have core
>> compiler/language support.
>
> ...for what exactly? Can you be more specific?
Hans-J. Boehm discussed the question in his 2004 paper "Threads Cannot
be Implemented as a Library",
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html.
The core of Boehm's position is perhaps shown in this quote:
"Library-based approaches to concurrency normally require a very
disciplined style of synchronization by multi-threaded programs.
Although we agree that this is appropriate for perhaps 98% of uses, we
argue that it eliminates some low-level programming techniques which, in
some cases, may be essential for obtaining any performance benefit from
multiple processors. In other cases, such low-level programming
techniques can be used to improve the performance of higher-level
library primitives, and thus provide pervasive performance improvements
for a large collection of applications. Thus, although these usage rules
are highly desirable guidelines, we argue that they are inappropriate as
absolute requirements in a world in which we need to rely on
multiprocessors for performance."
Boehm says that the problems he describes are being addressed in the
memory model being defined for the C++ standard. I don't of course know
if Joshua had the same issues in mind.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
Joshua Maurice
Technically, you can put threading in a separate standard. I'm not
arguing you can't. POSIX pthreads is an example proving that you can
have it in separate standards.
I think I was making two points there.
First, you need the compiler to understand threads in order to do non-
broken code generation. It's not even a matter of performance. You
need some guarantees from the compiler to use threads. A compiler, if
it doesn't know about threads, could generate code that is broken in a
threading situation. Obviously, you can write a compiler the quick
way, and get bad performance, or you can write it better and get
better code generation with threading.
Second, IMHO, threading is such a complicated and inherent part of a
threaded language that it ought to go in language the standard. The
entire abstract machine model changes. You need to change the
definition of sequence point. It just seems so much more tied to the
execution model than say.. a GUI library, or a math library.
Joshua Maurice
wrote:
> Sebastian wrote:
> > On 16 Jan., 09:35, Joshua Maurice wrote:
> >> I want to emphasize what Ian has said else-thread that if the library
> >> in question has serious restrictions on the language and on code
> >> generation of a compiler, then that ought to be in the language
> >> standard. It's not like we're proposing to throw process spawning,
> >> GUI, or other "library" stuff into the language standard. Threading in
> >> practice cannot be implemented as a library. It must have core
> >> compiler/language support.
>
> > ...for what exactly? Can you be more specific?
>
> Hans-J. Boehm discussed the question in his 2004 paper "Threads Cannot
>
> The core of Boehm's position is perhaps shown in this quote:
>
> "Library-based approaches to concurrency normally require a very
> disciplined style of synchronization by multi-threaded programs.
> Although we agree that this is appropriate for perhaps 98% of uses, we
> argue that it eliminates some low-level programming techniques which, in
> some cases, may be essential for obtaining any performance benefit from
> multiple processors. In other cases, such low-level programming
> techniques can be used to improve the performance of higher-level
> library primitives, and thus provide pervasive performance improvements
> for a large collection of applications. Thus, although these usage rules
> are highly desirable guidelines, we argue that they are inappropriate as
> absolute requirements in a world in which we need to rely on
> multiprocessors for performance."
>
> Boehm says that the problems he describes are being addressed in the
> memory model being defined for the C++ standard. I don't of course know
> if Joshua had the same issues in mind.
Yes. Thank you. I did have those issues in mind. Exactly that. Thanks
for linking to the paper which I'm sure can describe it better than I
offhand.
Chris H
u...@mib.org> writes
>Chris H <ch...@phaedsys.org> writes:
>[...]
>> This was C99's great failing. Things were added that were "cool" or
>> "neat" etc for a *FEW* people not the majority. Hence the near zero take
>> up of C99.
>[...]
>
>Then why is C201X, as least as of the current draft, keeping *all*
>the features that C99 added, and making only a tiny fraction of
>them optional?
Good Question... I would suggest it is to see if they can get the
optional idea to work. If it does they can make more optional in a TC
later.
>It seems to me that the mandatory subset of C201X is much closer
>to C99 than it is to C90. And of course the full C201X language,
>with optional features enabled, is essentially a superset of C99.
Yes. Probably.
>So what's the big deal? C201X, at least in the drafts we've
>seen so far, is *not* going back to C90 and starting over.
No. It won't and can't. Not Everything in C99 was bad. Most compilers
have implemented parts of C99.
Chris H
>
>Windows, Mac OSX, Linux, Bsd and Unix combined
>probably cover 99% of the PC, Workstation and
>Minicomputer market. As others already pointed out VMS
>is dying and even IBM is moving towards Unix/Linux.
Which is about 4% of the MCU market. PC's and Workstations make up a
VERY small part of computing. The average car has more computing power
than a PC. Never mind aircraft, ships, medicals etc etc
This is why there are over a dozen other OS and RTOS out there.
Your 99% market is less than 4% of the world market that uses c.
Incidentally each PC has several processors in it. (Keyboard, network
card, hard disks, CD drives, monitor, etc)
You are looking at a VERY small market overall. This is the market the
ISO -C standard has to look at. BTW the 8 bit MCU is still the most
widely used in the world.
>> >You can help to port Seed7 to one of this operating systems by
>> >writing the driver libraries.
>>
>> Ok. Do you want do know my consultancy rates first?
>
>No. Sorry to say, but there are people I would prefer,
>when I have to pay them. But I always appreciate when
>programming for an opern source project is done for free.
You may be able to afford to work for free but few people can these
days.
Chris H
<b...@freeuk.com> writes
>portability. Someone (Chris H I think) said 95% of microprocessors in the
>world are not x86. But so what?
The So what is that the ISO-C standard has to cater for the Global
market... or at least 95% of it :-)
>If there is an advantage in porting an application from A to B, then it will
>get ported. Writing it in the first place so that it will run on A, B, C,
>all the way to system Z, means it will either never get finished, or it
>would cost too much, or the quality would suffer.
Agreed and in the vast majority of the world C is rarely ported. Seed7
is only "portable" between a very small minority of Windows and Unix.
(But that is all it needs) However it is a very inefficient system.
In Embedded systems they are engineered to work with the minimum amount
of cost, hardware and power. You usually want it as small and as
efficient as possible. You don't just add more RAM as that will cost
(the chip, the CAD, the PCB manufacture, larger Power supply etc) Ok it
is only 5 USD but we are making 200,000 of them. So it has taken 1
million USD off the profit line.
Less efficient.... means more power and more heat and more weight all
important factors in many systems.
Uno
> I believe the C and C++ committees are already in close contact.
>
You'd think by now they may have golfed together or something. Do you
know everyone on both committees? In combinatorics, that would be
called a politician.
All of C's and half of C++'s?
--
Uno
Uno
> On 01/12/2011 04:52 PM, sandeep wrote:
> ...
>> 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
>
> This program contains two modules and one shared header. It's very
> carefully designed to make many different points in a program that is as
> small as possible. I make no claim that this represents good programming
> practice:
>
> shared.h:
> =========
> #ifndef SHARED_H
> #define SHARED_H
>
> extern char tag;
> extern int enumer[2];
>
> typedef void voidvoid(void);
>
> int Cnmtyp(void);
> int Cfunc(voidvoid*);
>
> #endif
>
> First module:
> =============
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> #include "shared.h"
>
> char tag = 0;
>
> static int hidden(voidvoid *pfunc)
> {
> (*pfunc)();
> tag = sizeof 'C' == sizeof(int);
> return Cnmtyp() && enumer[0] && enumer[1];
> }
>
> int Cfunc(voidvoid* pfunc)
> {
> struct tag
> {
> enum { enumer, other } in;
> int integer;
> } out;
>
> out.integer = sizeof(tag) == 1 && sizeof(enumer) == sizeof out.in;
>
> return hidden(pfunc) && out.integer;
> }
>
> #ifdef __cplusplus
> }
> #endif
>
> Second module:
> ==============
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> #include "shared.h"
>
> int enumer[2] = {0, 1};
>
> static void Cppname_Cpptype(void)
> {
> enumer[0] = sizeof 'C' == 1;
> return;
> }
>
> #ifdef __cplusplus
> }
> #endif
>
> int Cnmtyp(void)
> {
> struct tag
> {
> enum { enumer, other } in;
> int integer;
> } out;
>
> out.integer = sizeof(enumer) == 2 * sizeof(int);
>
> return out.integer && sizeof(tag) == sizeof out;
> }
>
> static voidvoid Cppname_Ctype;
>
> static void Cppname_Ctype(void) {
> Cppname_Cpptype();
> }
>
> int main(void) {
> return Cfunc(&Cppname_Ctype) && tag;
> }
>
> Both modules contain syntactically valid code: according to C99, C++98,
> and C++03, together they constitute strictly conforming C code, and
> well-formed C++ code. The behavior of code containing __cplusplus is
> technically undefined under C90, but for most (all?) fully conforming
> C90 compilers, the behavior is exactly as if it were not a reserved
> identifier, and not a pre-#defined macro. For any such C90 compiler, the
> only code that would otherwise constitute a syntax error will be dropped
> by the #if's.
>
> You can compile both modules in C, or both in C++; the resulting
> executables are guaranteed by the relevant standards to exit with a
> failure status, for quite different reasons in each case. If you compile
> the first module in C, and the second in C++, and the two compilers are
> compatible, then the modules can be linked together; in that case, the
> executable will exit with success status. Unfortunately, if you do it
> the other way around, they cannot be linked.
>
> Why does it matter which language is used for each module? Because three
> of the comparison operators are guaranteed to have a different value,
> depending upon whether the module is compiled as C or C++. The other two
> comparisons will have the same value in both languages only in the
> unlikely event that sizeof(int)==1. I'll leave it as an exercise for the
> reader to figure out why these statements are true.
>
> Please note that, while this code is VERY contrived, it depends upon
> very deep principles of the two languages. For every single comparison
> operator in the above code, guaranteeing that it would be true in both
> languages would break a lot of code in one of the two languages.
>
> So, if you want the semantics of this program to be the same in both
> languages, what should they be?
That's a very interesting read, james. I wish I had ubuntu so that I
could let the source and the respective compilers inform me, but I doubt
that you misrepresent the facts.
So we know that OP's above-stated intention MUST fail.
I came to C by way of microsoft and c++, and I think of the native
idioms being better in most situations, but you mind your p's and q's
when you're going to talk to the other in a standard way.
In this event, there is only what Jack Klein told me on my first
crosspost to comp.lang.c++:
extern 'C' {tja)
--
Uno
Chris H
writes
>On 1/11/2011 4:29 PM, Keith Thompson wrote:
>
>> I believe the C and C++ committees are already in close contact.
>>
>
>You'd think by now they may have golfed together or something. Do you
>know everyone on both committees? In combinatorics, that would be
>called a politician.
There are quite a few on both ISO panels but C and C++ are separate
languages and they tend to be used in different markets.
Joshua Maurice
I forget what I have read, or where I read it. I think that it was
James Kanze who said on comp.lang.c++ that they are in close contact,
though I honestly am not sure.
Also, that was pretty harsh there. Did I do something to offend you?
In which case, I'm sorry.
Rui Maciel
> I don't think I'm understanding some of the nuance of your argument.
> Do you really think that using pthreads in C++ code isn't practicable?
> In my experience, it's almost trivial to do so - it's as easy in C++
> as it is in C. To which hoops are you referring?
It depends on what you define as being practicable. Some may believe it
is practicable to be forced to use function wrappers in order to create a
thread but others, particularly C++ purists, may believe that constitutes
a set of hoops that they are forced to jump through just to get stuff to
work. This consequence of relying on pthreads to handle threading in C++
is so commonplace that it made it's way into some FAQs, such as:
http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.2
Therefore, it is only natural that a set of the C++ community invests some
time and effort to develop a threading API which is more C++-friendly,
which provides features such as the ability to freely use some C++ idioms
without being forced to resort to nasty hacks.
> I want to emphasize what Ian has said else-thread that if the library
> in question has serious restrictions on the language and on code
> generation of a compiler, then that ought to be in the language
> standard. It's not like we're proposing to throw process spawning,
> GUI, or other "library" stuff into the language standard. Threading in
> practice cannot be implemented as a library. It must have core
> compiler/language support.
Threading has been implemented up until now without anyone being forced to
impose any explicit behaviour on programming languages that didn't
explicitly supported threading, such as C and C++. That means that any
claim that "threading in practice cannot be implemented as a library" is
patently false.
Adding to this, and following Niklas Holsti's reference to Hans-J. Boehm's
report "Threads Cannot be Implemented as a Library"[1], it is claimed that
"library-based approaches to concurrency" are "appropriate for perhaps 98%
of uses", while some of the proposed changes are "currently only
appropriate for a small fraction of multi-threaded code". So, from that
report, the issue which is being discussed is essentially: is there any
technical justification to bloat the standard of a programming language
just to cover that 2% of uses where, according to some people, a library
approach may or may not be the most appropriate?
If this wasn't enough, once we read the cases presented to demonstrate the
2% where the "library-based approach to concurrency" may not be the most
appropriate, we understand that in essence those cases originate in a
failure on behalf of the programmer to acknowledge and respect the
principles defined in the pthreads standard. Other than that, the
proposed changes would only benefit a small fraction of corner cases, and
only in performance issues. This trade-off is at least very debatable.
So, considering all this, why do people push for such a fundamental change
to the language when this issue is essentially being posed as a solution
in search of a problem?
Rui Maciel
[1] http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html
Rui Maciel
> Technically, you can put threading in a separate standard. I'm not
> arguing you can't. POSIX pthreads is an example proving that you can
> have it in separate standards.
More importantly, the pthreads standard is an international standard which
is already in place. So in the end it isn't even a matter of having to
create a standard to handle that: it is only a matter of simply
acknowledging and following tried and true standards which have been in
place for the last 15 years or so.
> I think I was making two points there.
>
> First, you need the compiler to understand threads in order to do non-
> broken code generation. It's not even a matter of performance. You
> need some guarantees from the compiler to use threads.
Not necessarily. The issues which have been presented as the reasons to
impose support for threads on the C standard are essentially memory access
and performance. Up until now, what has been defined as issues regarding
memory access essentially refer to corner cases where principles defined
in the pthreads standard are neglected. In fact, a set of those corner
cases are presented although they never led to any failure. Other than
that, the performance issue is being presented as the perceived cost of
using mutex locks, which are based on measurements performed on systems
based on Pentium 4 processors.
> A compiler, if
> it doesn't know about threads, could generate code that is broken in a
> threading situation. Obviously, you can write a compiler the quick
> way, and get bad performance, or you can write it better and get
> better code generation with threading.
Again, the only cases where the so called "library approach to
concurrency" has been claimed to fail are cases where the principles
defined in the pthreads standard have been ignored. A new standard is not
a solution to a problem which is caused by ignoring current standards.
> Second, IMHO, threading is such a complicated and inherent part of a
> threaded language that it ought to go in language the standard.
I'm yet to see a single reason that justifices forcing threading into the
standard of the C programming language. Claiming that it is complicated
is also not a valid reason to do so.
> The
> entire abstract machine model changes. You need to change the
> definition of sequence point. It just seems so much more tied to the
> execution model than say.. a GUI library, or a math library.
If there was a campaign to force a GUI API into the C standard then things
would be a whole lot worse than they are.
Regarding threading in C, again, this push to force threading into the C
standard sounds like a solution in search of a problem.
Rui Maciel
Chris H
>
>> I believe the C and C++ committees are already in close contact.
>>
>
>You'd think by now they may have golfed together or something. Do you
>know everyone on both committees?
Actually a couple of people who are involved with both ISO-WG's have
posted to this very thread.......
Joshua Maurice
> Joshua Maurice wrote:
> > Technically, you can put threading in a separate standard. I'm not
> > arguing you can't. POSIX pthreads is an example proving that you can
> > have it in separate standards.
>
> More importantly, the pthreads standard is an international standard which
> is already in place. So in the end it isn't even a matter of having to
> create a standard to handle that: it is only a matter of simply
> acknowledging and following tried and true standards which have been in
> place for the last 15 years or so.
Which is quite informally specified, might I even say badly. It's
flawed in several subtle but important ways. However, as you said else-
post in a snipped section, I can agree that it does suffice for ~98%
of threading usage.
Still, I find it quite irritating having to convince people that "no,
you aren't guaranteed by any standard that volatile will do anything
useful", especially when they start invoking inline assembly like they
think they know something. I agree that POSIX pthreads suffices for
~98% of current usage, but for the very important other ~2%, it's the
wild west with people basically guessing and relying on undocumented
guarantees.
Also, why hasn't POSIX pthreads included read, write, and data
dependency barriers? Yes ~98% of the code doesn't need it, but the
other ~2% does, like the Linux kernel, and other high performance
threading code.
> > First, you need the compiler to understand threads in order to do non-
> > broken code generation. It's not even a matter of performance. You
> > need some guarantees from the compiler to use threads.
>
> Not necessarily. The issues which have been presented as the reasons to
> impose support for threads on the C standard are essentially memory access
> and performance. Up until now, what has been defined as issues regarding
> memory access essentially refer to corner cases where principles defined
> in the pthreads standard are neglected. In fact, a set of those corner
> cases are presented although they never led to any failure. Other than
> that, the performance issue is being presented as the perceived cost of
> using mutex locks, which are based on measurements performed on systems
> based on Pentium 4 processors.
As I think Hans Boehm has said, this isn't how it works in practice. A
compiler compiling threading code must be thread aware to some extent.
You won't get correct code generation from an optimizing compiler
otherwise, except by luck. In practice, all compilers implementing
pthreads are aware of what optimizations and transformations are
acceptable and which are not. Let me emphasize that choice of wording
- the compiler, linker, etc., implement POSIX pthreads, not a
library.
> > A compiler, if
> > it doesn't know about threads, could generate code that is broken in a
> > threading situation. Obviously, you can write a compiler the quick
> > way, and get bad performance, or you can write it better and get
> > better code generation with threading.
>
> Again, the only cases where the so called "library approach to
> concurrency" has been claimed to fail are cases where the principles
> defined in the pthreads standard have been ignored. A new standard is not
> a solution to a problem which is caused by ignoring current standards.
>
> > Second, IMHO, threading is such a complicated and inherent part of a
> > threaded language that it ought to go in language the standard.
>
> I'm yet to see a single reason that justifices forcing threading into the
> standard of the C programming language. Claiming that it is complicated
> is also not a valid reason to do so.
>
> > The
> > entire abstract machine model changes. You need to change the
> > definition of sequence point. It just seems so much more tied to the
> > execution model than say.. a GUI library, or a math library.
>
> If there was a campaign to force a GUI API into the C standard then things
> would be a whole lot worse than they are.
>
> Regarding threading in C, again, this push to force threading into the C
> standard sounds like a solution in search of a problem.
As you didn't reply specifically to what I felt was an important
point, let me repeat it. The C standard is made in terms of an
abstract machine which has but one thread of execution. The POSIX
pthread standard doesn't simply add on to another standard like a GUI
library might - it actually rewrites and takes precedence over parts
of the C standard. Threading changes the very nature of the abstract
machine from a single threaded one to a multi threaded one.
Judging from your other replies, I don't think that you'll find that a
compelling reason to put it in the C standard, but I do want to
clarify at least that I think this is a rather important distinction
which separates threading from nearly all other real life (third
party) libraries and third party standards.
Rui Maciel
> On Jan 17, 4:10 am, Rui Maciel <rui.mac...@gmail.com> wrote:
>> More importantly, the pthreads standard is an international standard
>> which is already in place. So in the end it isn't even a matter of
>> having to create a standard to handle that: it is only a matter of
>> simply acknowledging and following tried and true standards which have
>> been in place for the last 15 years or so.
>
> Which is quite informally specified, might I even say badly. It's
> flawed in several subtle but important ways. However, as you said else-
> post in a snipped section, I can agree that it does suffice for ~98%
> of threading usage.
>
> Still, I find it quite irritating having to convince people that "no,
> you aren't guaranteed by any standard that volatile will do anything
> useful", especially when they start invoking inline assembly like they
> think they know something. I agree that POSIX pthreads suffices for
> ~98% of current usage, but for the very important other ~2%, it's the
> wild west with people basically guessing and relying on undocumented
> guarantees.
>
> Also, why hasn't POSIX pthreads included read, write, and data
> dependency barriers? Yes ~98% of the code doesn't need it, but the
> other ~2% does, like the Linux kernel, and other high performance
> threading code.
Without delving into details about what the pthreads standard defines and
doesn't define, it is important to state that if what motivates this
campaign to force threads into the C standard is the idea that the current
pthreads standard fails to define behavior which is seen by some as being
important then it's clear that the problem would lie in the pthreads
standard and not in the C standard. Therefore, it would be far more
productive, and far less intrusive, to simply call for an update of the
pthreads standard. After all, it isn't possible to fix the perceived
shortcomings of an international standard by creating a new, parallel
international standard that covers the exact same subject. This issue is
even less justifiable if the proposed changes only cover corner cases
which are pretty much irrelevant.
> As I think Hans Boehm has said, this isn't how it works in practice. A
> compiler compiling threading code must be thread aware to some extent.
> You won't get correct code generation from an optimizing compiler
> otherwise, except by luck. In practice, all compilers implementing
> pthreads are aware of what optimizations and transformations are
> acceptable and which are not. Let me emphasize that choice of wording
> - the compiler, linker, etc., implement POSIX pthreads, not a
> library.
The case presented by Hans Boehm in his "Threads Cannot be Implemented as
a Library" technical report (which he then states that, yes, threads sure
can be implemented as a library at least for 98% of the cases) to justify
tweaking C compilers to generate thread-aware code essentially refers to,
if I'm not mistaken, essentially two issues: obscure race conditions
caused by a failure to employ mutexes and the expensive nature of mutexes.
The issue with race conditions was divided in two distinct issues: the
ability of some C compilers to rearrange/translate instructions, which may
cause race conditions in un-mutexed parts of the code which are subjected
to concurrent read/write operations (a no-no to begin with), and non-
atomic read/write accesses to memory which, again, the access isn't
managed by a mutex (another no-no).
So, from the issues being raised, it is clear that the problem doesn't lie
with pthreads, it lies in the inability to implement basic, fundamental
pthreads principles. After all, there is a very good reason why pthreads
has been successfully employed in the real world for over 15 years and
there is a good reason why the 2% of cases which are being used to justify
a overhaul of the C programming language either never happened (as it is
stated in the TR) or are simply based on the failure to correctly use
pthreads.
>> Regarding threading in C, again, this push to force threading into the
>> C standard sounds like a solution in search of a problem.
>
> As you didn't reply specifically to what I felt was an important
> point, let me repeat it. The C standard is made in terms of an
> abstract machine which has but one thread of execution. The POSIX
> pthread standard doesn't simply add on to another standard like a GUI
> library might - it actually rewrites and takes precedence over parts
> of the C standard. Threading changes the very nature of the abstract
> machine from a single threaded one to a multi threaded one.
>
> Judging from your other replies, I don't think that you'll find that a
> compelling reason to put it in the C standard, but I do want to
> clarify at least that I think this is a rather important distinction
> which separates threading from nearly all other real life (third
> party) libraries and third party standards.
The issue which must be discussed is the practical and real world
implications of forcing threading into the C standard. No one would deny
a change, even a profound one, which could undeniably improve the
language, even if it had it's drawback. Yet, in this case, even the
proponents of such a change only manage to point out as reasons to impose
such as fundamental change a couple of corner cases which, quite bluntly
(and based on the examples which were provided), are caused by a failure
to implement basic phtreads principles.
Knowing that, if we also take into account the complexity (or bloat,
whatever you may call it) that this change would impose on the
specification of the C programming language, essencially to bring nothing
relevant to the table, then one has to wonder where is the technical
justification to impose such a fundamental change.
Rui Maciel
tm
> In message <f1d9a3bc-efd4-4fb6-9e5b-dd665dc97...@w29g2000vba.googlegroup
> s.com>, tm <thomas.mer...@gmx.at> writes
>
> >On 15 Jan., 11:18, Chris H <ch...@phaedsys.org> wrote:
>
> >Windows, Mac OSX, Linux, Bsd and Unix combined
> >probably cover 99% of the PC, Workstation and
> >Minicomputer market. As others already pointed out VMS
> >is dying and even IBM is moving towards Unix/Linux.
[snip]
> Your 99% market is less than 4% of the world market that uses c.
Seed7 does not address the market that uses C.
OTOH I have information that some have experimented with
Seed7 for embedded stuff...
As I already said:
I use C as target language for compiled Seed7 programs.
As such I am interested in C features that are helpful
for machine generated C programs. I am not interested
in higher level features like VLAs, type inference, etc.
Instead I am interested in portable lower level features
that the current C standard cannot provide. The Seed7
compiler (and other compilers which generate C code) can
provide many features, but for some features support from
C is needed. One C feature that would be helpful is:
- possibility to check integer overflow, but keeping
the current behaviour, if desired. When overflow
checking is part of the C language it is possible to
support it with no overhead when the hardware has an
overflow trap).
It would be possible to improve the Seed7 to C compiler
such that integer overflow raises an exception. But the
code would probably not be very efficient. Therefore I
would prefer when it is possible to build upon a C
(standard) feature.
> >> >You can help to port Seed7 to one of this operating systems by
> >> >writing the driver libraries.
>
> >> Ok. Do you want do know my consultancy rates first?
>
> >No. Sorry to say, but there are people I would prefer,
> >when I have to pay them. But I always appreciate when
> >programming for an opern source project is done for free.
>
> You may be able to afford to work for free but few people can these
> days.
You seem to missunderstand. I work as freelancer and I
am paid for my work. And I really need the money because
I have a family with three childen. The development for
Seed7 is done in my free time. So I think: When I can
manage to write open source software for free most
computer professionals should be able to do so.
Chris H
>> days.
>
>You seem to missunderstand. I work as freelancer and I
>am paid for my work. And I really need the money because
>I have a family with three childen. The development for
>Seed7 is done in my free time.
That is your choice. I have other things to do with my free time.
> So I think: When I can
>manage to write open source software for free most
>computer professionals should be able to do so.
Why?
jacob navia
>
> Knowing that, if we also take into account the complexity (or bloat,
> whatever you may call it) that this change would impose on the
> specification of the C programming language, essencially to bring nothing
> relevant to the table, then one has to wonder where is the technical
> justification to impose such a fundamental change.
There is no technical justification.
Mcrosoft corp doesn't like pthreads. Period.
The standards committee then, will publish a new standard that could be
accepted by microsoft.
Standards are just politics+money, technical issues are not really
important.
Ian Collins
That's a very jaded view.
I haven't read the WG14 papers, but that does not appear to be the case
with WG21 (C++).
--
Ian Collins
Ian Collins
> In message<8piarb...@mid.individual.net>, Uno<merril...@q.com>
> writes
>> On 1/11/2011 4:29 PM, Keith Thompson wrote:
>>
>>> I believe the C and C++ committees are already in close contact.
>>>
>>
>> You'd think by now they may have golfed together or something. Do you
>> know everyone on both committees? In combinatorics, that would be
>> called a politician.
>
> There are quite a few on both ISO panels but C and C++ are separate
> languages and they tend to be used in different markets.
But they do overlap and maintaining compatibility where they do is
sensible. For example see:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3137.html
"C and C++ Liaison: Compatibility for Atomics"
--
Ian Collins
Rui Maciel
>> Standards are just politics+money, technical issues are not really
>> important.
>
> That's a very jaded view.
I don't know if that's the case with the new C standard. Nonetheless,
there is a fair share of standards out there who include absurdities which
were a product of political bickering. In the computing world, the sham
which was OOXML's standardization process along with all the corruption
that went with it is still fresh in many people's minds. In other areas,
such as CEN's Eurocode family of building codes, there are also a hand
full of such examples. For example, EN 1993-1 includes a couple of
versions of the same formula to evaluate the exact same type of structural
resistance that end up doing the exact same thing simply because, if I'm
not mistaken, the German and French representatives refused to adopt a
verification method other than the one they proposed. As a consequence,
EN 1993-1 essencially includes the same formula twice (minus som minor
details) due to nothing more than political bickering.
So, unfortunately this sort of stuff happens too frequently. And then we,
the ones who have an interest in following those standards, get to suffer
the result of those SNAFUs for years to follow.
Rui Maciel