C9X vs C++
David R Tribble
I'm writing a document that lists the incompatibilities between C++98
and C9X, and to help me finish it, I'd like suggestions and commentsfrom
interested parties. It's at http://david.tribble.com/text/cdiffs.htm .
One thing I'm missing is the URL for Stroustrup's Appendix from his
TC++PL 3rd ed, which lists the incompatibilities between C90 and C++.
Also, I'm not very knowledgeable about the sections dealing with
ISO/EIC 559, LIA-1, and <tgmath.h>, so perhaps someone could summarize
the problems these (will) cause for C++?
-- David R. Tribble, da...@tribble.com --
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Zeisel Helmut
>
>One thing I'm missing is the URL for Stroustrup's Appendix from his
>TC++PL 3rd ed, which lists the incompatibilities between C90 and C++.
>
http://www.research.att.com/~bs/3rd_compat.ps (or.pdf)
Helmut
--
---
Greg Brewer
I noticed 2 things.
First, you have
and_eq =
when I think you mean
and_eq &=
Second, another incompatibility is C++'s ability to pass values by
reference.
Ie void foo(float&f) {f++;}
Greg Brewer
Bill Wade
David R Tribble wrote in message <37DEE109...@tribble.com>...
>
>I'm writing a document that lists the incompatibilities between C++98
>and C9X, and to help me finish it, I'd like suggestions and commentsfrom
>interested parties. It's at http://david.tribble.com/text/cdiffs.htm .
Very nice.
At one point in the document you suggest a macro, dynamic_cast(t,e), to use
in both languages. I'd argue that in the rare cases where the macro does
the same thing in both languages, your static_cast() macro would also work
and would be preferred.
There is more to the one definition rule (ODR) than you've got in the
document, although I don't know if the differences matter for any existing
compilers.
ODR applies to struct definitions
struct a { long b; }; // In one file
struct a { long int b; }; // In another file
AFAICT this is legal C and illegal C++ (C++ standard 3.2p5 says "each
definition ... shall consist of the same sequence of tokens).
There are also ODR issues for extern inline functions. I believe C9X allows
an extern inline function to be inline in only some translation units that
use it. C++ requires it to be inline in all translation units that use it.
For another ODR example:
inline int foobar { return 0; } // In one file
inline int foobar { return 1-1; } // In another file
I believe this is legal C, but illegal C++ (but no diagnostic is required).
Clive D.W. Feather
In article <7rr9sn$9...@library1.airnews.net>, Bill Wade
<bill...@stoner.com> writes
>ODR applies to struct definitions
> struct a { long b; }; // In one file
> struct a { long int b; }; // In another file
>AFAICT this is legal C and illegal C++ (C++ standard 3.2p5 says "each
>definition ... shall consist of the same sequence of tokens).
Certainly it's legal C - the two spellings of the type are the same. You
can also do:
typedef signed long xx;
typedef xx yy;
struct a { yy b; };
in a third file and *that's* compatible.
>There are also ODR issues for extern inline functions. I believe C9X allows
>an extern inline function to be inline in only some translation units that
>use it.
Correct.
>For another ODR example:
> inline int foobar { return 0; } // In one file
> inline int foobar { return 1-1; } // In another file
>I believe this is legal C, but illegal C++ (but no diagnostic is required).
In C you can even write, in a third file:
inline int foobar { return 2; }
--
Clive D.W. Feather | Internet Expert | Work: <cl...@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd. | Home: <cl...@davros.org>
Fax: +44 20 8371 1037 | | Web: <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
Bill Wade
>> inline int foobar { return 0; } // In one file
>
>
> inline int foobar { return 2; }
But if you do this it is unspecified (in at least one of the files) what
value foobar() returns, making portable use of this "feature" problematic.
---
Bart van Tongeren
David R Tribble <da...@tribble.com> wrote:
>
> I'm writing a document that lists the incompatibilities between C++98
> and C9X, and to help me finish it, I'd like suggestions and
commentsfrom
> interested parties. It's at
http://david.tribble.com/text/cdiffs.htm .
>
The document proposes a solution for the incompatibility that would
exist if the old-style C casts were not supported by C++.
However, old-style casts are, unfortunately, _not_ deprecated in C++.
This means that the proposed macros are not strictly necessary,
although they do make a cast's purpose more explicit, and allow
better compile time checks if __cplusplus is defined.
--
-- reply address: bart.van.tongeren
[no spam please] @ quansis.demon.nl
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Clive D.W. Feather
In article <7s5fef$u...@library1.airnews.net>, Bill Wade
<bill...@stoner.com> writes
>>> inline int foobar { return 0; } // In one file
>>
>>In C you can even write, in a third file:
>>
>> inline int foobar { return 2; }
>
>But if you do this it is unspecified (in at least one of the files) what
>value foobar() returns, making portable use of this "feature" problematic.
Yes, it is unspecified whether this returns 0 or 2.
This isn't very useful in this simplistic example, but it may well be
that one translation unit can make simplifying assumptions that don't
apply to others. For example, the area of a triangle:
// Translation unit 1
extern double area (double x, double y, double z)
{
double s = (x + y + z) / 2;
return sqrt (s * (s - x) * (s - y) * (s - z));
}
// Translation unit 2
/*
* All triangles appearing in this translation unit are equilateral.
*/
inline double area (double x, double y, double z)
{ return x * x * 0.866025403784; }
--
Clive D.W. Feather | Internet Expert | Work: <cl...@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd. | Home: <cl...@davros.org>
Fax: +44 20 8371 1037 | | Web: <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
Clive D.W. Feather
>I'm writing a document that lists the incompatibilities between C++98
>and C9X, and to help me finish it, I'd like suggestions and commentsfrom
>interested parties. It's at http://david.tribble.com/text/cdiffs.htm .
You misunderstand _Bool. It is a 2 value integer type, not a type name
for some other underlying type.
Compound literals can have any type, not just structure type.
Designated initializers can be used with unions.
"All enumerated types, though, convert to values of type signed int when
they appear in expressions" is not true. The type behaves the same as
the (compatible) underlying integer type.
IEC 60559 is what used to be called IEEE floating-point.
LIA-1 is a standard for describing type systems in programming
languages, sort of.
Inline is being discussed in another thread right now.
The long long types are not 64 bit types.
Paul Jarc
"Clive D.W. Feather" <cl...@on-the-train.demon.co.uk> writes:
> "All enumerated types, though, convert to values of type signed int when
> they appear in expressions" is not true. The type behaves the same as
> the (compatible) underlying integer type.
Yes - he probably meant "all enumeration constants...". Converting a
type to an integer value would be a bit tougher, though useful.
paul
Fergus Henderson
>Clive D.W. Feather wrote in message <4QGYM9K$Ur43...@romana.davros.org>...
>>> inline int foobar { return 0; } // In one file
>>
>>In C you can even write, in a third file:
>>
>> inline int foobar { return 2; }
>
>But if you do this it is unspecified (in at least one of the files) what
>value foobar() returns, making portable use of this "feature" problematic.
One potentially common and mostly portable use of this feature is as follows:
/* foo.h */
#include <assert.h>
inline void foo(int x) {
assert(x >= 0);
...
}
/* bar.c */
#include "foo.h"
void bar(int x) {
foo(x);
...
}
/* baz.c */
#define NDEBUG
#include "foo.h"
void baz(int x) {
foo(x);
...
}
In C++, this program is ill-formed, but no diagnostic is required;
the behaviour is undefined and furthermore the implementation can
refuse to translate the program (even if the functions foo(), bar()
and baz() will never be called). Still, in practice it is portable,
because current C++ implementations do the same thing here that
they would do if "inline" were replaced with "static".
In C9X, if the argument to foo() is always >= 0, then
the program (or at least this part of it) is strictly conforming.
If the argument to foo() is < 0, then it is unspecified whether or not
you get an assertion failure. But as far as portability goes, that
is not such a big concern, because assertion failures could only
happen if the program is buggy anyway.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
---
Vesa A J Karvonen
> In article <7s5fef$u...@library1.airnews.net>, Bill Wade
> <bill...@stoner.com> writes
> >>
> >>In C you can even write, in a third file:
> >>
> >> inline int foobar { return 2; }
> >
> >But if you do this it is unspecified (in at least one of the files) what
> >value foobar() returns, making portable use of this "feature" problematic.
> Yes, it is unspecified whether this returns 0 or 2.
> This isn't very useful in this simplistic example, but it may well be
> that one translation unit can make simplifying assumptions that don't
> apply to others. For example, the area of a triangle:
> // Translation unit 1
> extern double area (double x, double y, double z)
> {
> double s = (x + y + z) / 2;
> return sqrt (s * (s - x) * (s - y) * (s - z));
> }
> // Translation unit 2
> /*
> * All triangles appearing in this translation unit are equilateral.
> */
> inline double area (double x, double y, double z)
> { return x * x * 0.866025403784; }
I honestly don't understand the motivation for allowing multiple
definitions of an inline function. It seems like a very silly idea,
because it violates the common sense that you should provide only one
definition of a thing. If you want polymorphism, use indirection.
If you want different semantics, you can always write another function:
inline double area_equilateral (double x, double y, double z)
{
assert(x > 0 && fabs(x-y) < epsilon && fabs(x-z) < epsilon);
return x * x * 0.866025403784;
}
In this case I would prefer to eliminate the unnecessary arguments
altogether:
inline double area_equilateral (double x)
{
assert(x > 0);
return x * x * 0.866025403784;
}
---
Vesa Karvonen
Christian Bau
<vkar...@cc.helsinki.fi> wrote:
> I honestly don't understand the motivation for allowing multiple
> definitions of an inline function. It seems like a very silly idea,
> because it violates the common sense that you should provide only one
> definition of a thing. If you want polymorphism, use indirection.
> If you want different semantics, you can always write another function.
I don't think you can achieve anything useful with multiple definitions of
inline functions. The problem is: What is a compiler supposed to do if a
programmer does something stupid like writing two different
implementations for the same inline function? A language standard can do
one of the following:
1. Make it illegal; compilers have to detect it.
2. Make it undefined behavior.
3. Make it defined, possibly unspecified behavior.
Detecting the situation is probably quite difficult, so it would be tough
on implementors if a standard demands that this is an error and has to be
detected.
James Kuyper
>
> In article <7singi$9id$1...@oravannahka.helsinki.fi>, Vesa A J Karvonen
> <vkar...@cc.helsinki.fi> wrote:
>
> > I honestly don't understand the motivation for allowing multiple
> > definitions of an inline function. It seems like a very silly idea,
> > because it violates the common sense that you should provide only one
> > definition of a thing. If you want polymorphism, use indirection.
> > If you want different semantics, you can always write another function.
>
> I don't think you can achieve anything useful with multiple definitions of
> inline functions. The problem is: What is a compiler supposed to do if a
> programmer does something stupid like writing two different
> implementations for the same inline function? A language standard can do
> one of the following:
>
> 1. Make it illegal; compilers have to detect it.
> 2. Make it undefined behavior.
> 3. Make it defined, possibly unspecified behavior.
4. Define precisely how to decide which version to use.
Clive D.W. Feather
>I honestly don't understand the motivation for allowing multiple
>definitions of an inline function. It seems like a very silly idea,
>because it violates the common sense that you should provide only one
>definition of a thing.
It fell out of a problem we had in defining "inline". An inline function
has two or more definitions anyway, so the problem is what restrictions
to put on those definitions. Requiring compatible types is easy, so we
did that. But what about the bodies ?
C++ says, roughly, that the tokenised bodies must be the same. There was
little or no support for following this approach, because it didn't seem
possible to handle all the questions of (for example) typedef names
appearing in the body without a major rewrite of C9X. So we decided to
allow the bodies to be different.
There was some sympathy for requiring the bodies to "have the same
effect", but this isn't a testable requirement. In the end we decided
that the best thing was to allow the bodies to be different and make it
unspecified which body was used in any given instance.
"inline" is supposed to be an optimisation technique. The commonest use
is to use it to say "this code is short enough or used often enough that
omitting the overhead of function calls is worth it". We found that the
same syntax and semantics also allows it to be used for "you can make
the following simplifying assumptions in this case".
--
Clive D.W. Feather | Internet Expert | Work: <cl...@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd. | Home: <cl...@davros.org>
Fax: +44 20 8371 1037 | | Web: <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
Douglas A. Gwyn
> I honestly don't understand the motivation for allowing multiple
> definitions of an inline function. It seems like a very silly idea,
> because it violates the common sense that you should provide only one
> definition of a thing.
What everybody seems to agree is desirable is to permit *benign*
redefinition, but not necessarily conflicting redefinition.
The former is useful for inline definitions in headers, etc.
Bjarne Stroustrup
"Clive D.W. Feather" <cl...@on-the-train.demon.co.uk> writes:
> In article <7singi$9id$1...@oravannahka.helsinki.fi>, Vesa A J Karvonen
> <vkar...@cc.helsinki.fi> writes
> >I honestly don't understand the motivation for allowing multiple
> >definitions of an inline function. It seems like a very silly idea,
> >because it violates the common sense that you should provide only one
> >definition of a thing.
>
> It fell out of a problem we had in defining "inline". An inline function
> has two or more definitions anyway, so the problem is what restrictions
> to put on those definitions. Requiring compatible types is easy, so we
> did that. But what about the bodies ?
>
> C++ says, roughly, that the tokenised bodies must be the same. There was
> little or no support for following this approach, because it didn't seem
> possible to handle all the questions of (for example) typedef names
> appearing in the body without a major rewrite of C9X. So we decided to
> allow the bodies to be different.
>
> There was some sympathy for requiring the bodies to "have the same
> effect", but this isn't a testable requirement. In the end we decided
> that the best thing was to allow the bodies to be different and make it
> unspecified which body was used in any given instance.
The C++ rule is a bit more strict than that. It says roughly that the
tokens has to be the same and that the meaning of those tokens have to be
the same. It is the same rule that apply to structs/classes.
The aim is to prohibit something like this:
// header.h:
struct S { int x; my_type y; };
inline S* get_n(size_t n) { return new S[n]; }
// file1.c:
typedef int my_type;
#include<header.h>
// file2.c:
struct my_type { int a, b; };
#include<header.h>
(I chose an example that is trivially transcribed into C).
The aim of the C and C++ rules are to approximate the ideal of a single
definition in a single place (if you don't believe me for C, check with
Dennis).
C9x departs from this ideal - apparently because the committee didn't
want to have a rule that couldn't be checked everywhere - and allows code
that is illegal C++. I consider this a gratuitous incompatibility that
doesn't buy the C community anything (except another incompatibility).
This kind of minor incompatibility is what I and the C++ committee have
worked hard to avoid.
It is actually not too hard to check these rules using a lint-like tool,
a compiler using a database, or RTTI. It just cannot be guarantees for
every compilation in a traditional C or C++ implementation
> "inline" is supposed to be an optimisation technique. The commonest use
> is to use it to say "this code is short enough or used often enough that
> omitting the overhead of function calls is worth it". We found that the
> same syntax and semantics also allows it to be used for "you can make
> the following simplifying assumptions in this case".
- Bjarne
Bjarne Stroustrup - http://www.research.att.com/~bs
Douglas A. Gwyn
Bjarne Stroustrup wrote:
> The aim of the C and C++ rules are to approximate the ideal of a single
> definition in a single place (if you don't believe me for C, check with
> Dennis).
Do you really think that C as invented by Dennis Ritchie contains
"inline"?
> This kind of minor incompatibility is what I and the C++ committee
> have worked hard to avoid.
It's *not* an incompatibility in practice. Strictly conforming
C9x code will have to make sure that the multiple definitions
have the same effect. The easiest and most obvious way to do
that is to use the *same* token sequence with the *same* types,
which means to write the code using the C++ rules, usually via
#include of a common "API" header (as in your example).
The C committee also worked hard to avoid significant
incompatibilities. In many cases where there was an overlap
with C++, we were unable to simply copy the words from the C++
(draft) standard into the C9x (draft) standard, for a variety
of structural reasons (to which Clive alluded).
Robert Corbett
In article <37F4C728...@home.com>,
Douglas A. Gwyn <dag...@home.com> wrote:
>
>Bjarne Stroustrup wrote:
>> The aim of the C and C++ rules are to approximate the ideal of a single
>> definition in a single place (if you don't believe me for C, check with
>> Dennis).
>
>Do you really think that C as invented by Dennis Ritchie contains
>"inline"?
Given all the other new stuff in the Plan 9 C compiler, it might.
Sincerely,
Bob Corbett
Peter Seebach
In article <7t34n5$p8r$1...@engnews1.eng.sun.com>,
Robert Corbett <cor...@lupa.eng.sun.com> wrote:
[re]
>>Do you really think that C as invented by Dennis Ritchie contains
>>"inline"?
>Given all the other new stuff in the Plan 9 C compiler, it might.
Doesn't that argue *against* the theory that dmr pays significant attention
to C++ compatability?
I hate to be seen as a heritic, but frankly, compatability hurts both
languages more than it helps either of them at this point. You don't need
to "convert" a project to C++; if you wrote it in C, the design will be sucky
for a C++ program anyway. On the other hand, if we could admit this and stop
putting effort into making things "compatible" when they really won't be
quite compatible enough anyway, any number of warts could get cleared up.
-s
--
Copyright 1999, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Francis Glassborow
In article <6H9J3.3104$L85.2...@ptah.visi.com>, Peter Seebach
<se...@plethora.net> writes
>I hate to be seen as a heritic, but frankly, compatability hurts both
>languages more than it helps either of them at this point. You don't need
>to "convert" a project to C++; if you wrote it in C, the design will be sucky
>for a C++ program anyway. On the other hand, if we could admit this and stop
>putting effort into making things "compatible" when they really won't be
>quite compatible enough anyway, any number of warts could get cleared up.
I agree, and have been heard murmuring along those lines for several
years. Actually the most dangerous situations are 'almost compatible'
because that makes the problem easy to miss.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Douglas A. Gwyn
Peter Seebach wrote:
> ... On the other hand, if we could admit this and stop putting
> effort into making things "compatible" when they really won't be
> quite compatible enough anyway, any number of warts could get
> cleared up.
Existing warts are hard to clear up, because people write code
that relies on them..
A reasonable goal, previously enunciated by Tom Plum among others,
is that there be a useful, large "common subset" of C and C++
which could be used to produce code that might find its way into
either environment.
But we know that C cannot be a strict subset of the larger language
C++, which started out with incompatibilities such as int foo();
that make it pretty annoying to be told by C++'s designer that we
are not paying enough attention to compatibility.
Stan Brown
se...@plethora.net (Peter Seebach) wrote in comp.std.c++:
>I hate to be seen as a heritic, but frankly, compatability hurts both
>languages more than it helps either of them at this point.
I think that's the key question. Reading /The Design and Evolution of
C++/ gave me a much better appreciation -- well, maybe "tolerance" is a
better word -- for the warts that are in C++ for C compatibility. I think
Stroustrup makes a convincing case that pretty much each of them was
necessary to gain acceptance for C++.
But now C++ is a language in its own right, and "as close to C as
possible, but no closer" is less important. I don't know whether the
compatibility effort has come to be a net liability (yet), or if it ever
will. I'd love to see some discussion on this point. Of course nothing
can be changed until the next standard, but maybe it's in order to talk
about some things that should be deprecated then.
--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
http://www.mindspring.com/~brahms/
Dennis Ritchie
>
> In article <37F4C728...@home.com>,
> Douglas A. Gwyn <dag...@home.com> wrote:
> >
> >Bjarne Stroustrup wrote:
> >> The aim of the C and C++ rules are to approximate the ideal of a single
> >> definition in a single place (if you don't believe me for C, check with
> >> Dennis).
I took Bjarne to mean structs and unions here.
> >Do you really think that C as invented by Dennis Ritchie contains
> >"inline"?
>
> Given all the other new stuff in the Plan 9 C compiler, it might.
Actually, it doesn't.
Dennis
---
Paul Eggert
>Bjarne Stroustrup wrote:
>> This kind of minor incompatibility is what I and the C++ committee
>> have worked hard to avoid.
>It's *not* an incompatibility in practice.
I tend to agree, but I don't see how
anybody can know this for certain right now,
as there's no existing practice for mixing C++ and C9x.
Had C9x and C++ adopted the same basic rule,
we wouldn't need to worry about this at all.
But as things stand, it remains a possible
(though I think unlikely) source of screwups.
Robert Corbett
Peter Seebach <se...@plethora.net> wrote:
>
>In article <7t34n5$p8r$1...@engnews1.eng.sun.com>,
>Robert Corbett <cor...@lupa.eng.sun.com> wrote:
>[re]
>>>"inline"?
>
>>Given all the other new stuff in the Plan 9 C compiler, it might.
>
>to C++ compatability?
No, it argues that C as invented by Dennis Ritchie might contain "inline."
I must not have been as clear as I thought I was.
Sincerely,
Bob Corbett
Clive D.W. Feather
<b...@research.att.com> writes
>The aim of the C and C++ rules are to approximate the ideal of a single
>definition in a single place (if you don't believe me for C, check with
>Dennis).
I don't believe you for C. inline is new in C9X; I was there, but
neither you nor Dennis were.
--
Clive D.W. Feather | Internet Expert | Work: <cl...@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd. | Home: <cl...@davros.org>
Fax: +44 20 8371 1037 | | Web: <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
Chris Hills
>
>In article <7t34n5$p8r$1...@engnews1.eng.sun.com>,
>Robert Corbett <cor...@lupa.eng.sun.com> wrote:
>Doesn't that argue *against* the theory that dmr pays significant attention
>to C++ compatability?
>
>to "convert" a project to C++; if you wrote it in C, the design will be sucky
>putting effort into making things "compatible" when they really won't be
>quite compatible enough anyway, any number of warts could get cleared up.
I agree totally. C and C++ are separate languages. They are now used
in different areas. Many places where C is used it would not be possible
to use C++.
In embedded engineering for example on 8 bit systems one is never
going to use C++ (I often only have 128 or 256 bytes of RAM and
64K of code space due to the hardware architecture!)
Given that the main use of C is going to be embedded (much of which is
safety critical) as in most other areas c++ has superseded it I would
look at making C safer and more compact that a contorted imitation of
C++.
Horses for courses don't turn a donkey in to an ass.
regards
Chris
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\/\ Chris Hills Staffs /\/\/\/\/\/
/\/\/\/\/\/\/\/\/\ England /\/\/\/\/\/\/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Steve Clamage
Chris Hills <ch...@phaedsys.demon.co.uk> writes:
>Peter Seebach <se...@plethora.net> writes
>>
>>I hate to be seen as a heritic, but frankly, compatability hurts both
>>languages more than it helps either of them at this point. ...
>I agree totally. C and C++ are separate languages. They are now used
>in different areas. Many places where C is used it would not be possible
>to use C++.
Do you mean that no C++ compiler exists for the target platform?
If so, you obviously can't use C++. If you mean something else,
you should be more specific.
Since with minor syntactic exceptions, valid C is also valid C++
and should generate identical object code, I wonder what else you
could mean. My experience in converting C programs to C++ has been
that the source and object code got smaller, and the code ran faster.
>In embedded engineering for example on 8 bit systems one is never
>going to use C++ (I often only have 128 or 256 bytes of RAM and
>64K of code space due to the hardware architecture!)
Many embedded-system developers, especially in Japan, write in C++.
I don't understand why having limited memory in the target system
would be a factor, assuming you are using cross-compilers anyway.
--
Steve Clamage, stephen...@sun.com
Peter Seebach
Steve Clamage <cla...@eng.sun.com> wrote:
>Since with minor syntactic exceptions, valid C is also valid C++
>and should generate identical object code, I wonder what else you
>could mean. My experience in converting C programs to C++ has been
>that the source and object code got smaller, and the code ran faster.
I'm not convinced that these "minor" syntactic exceptions are really so
minor.
Most importantly, you lose a lot of good idiom when trying to do that.
>Many embedded-system developers, especially in Japan, write in C++.
>I don't understand why having limited memory in the target system
>would be a factor, assuming you are using cross-compilers anyway.
Huh. I wonder why they cared so much about changes to C9X, if they
were gonna use C++. ;-)
Limited memory means that most of the C++ extra features are unavailable,
at which point, better to use a language where the operations you can
perform are as easy to read as possible. :)
-s
--
Copyright 1999, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
---
Chris Hills
>
>Chris Hills <ch...@phaedsys.demon.co.uk> writes:
>
>>Peter Seebach <se...@plethora.net> writes
>>>I hate to be seen as a heritic, but frankly, compatability hurts both
>>>languages more than it helps either of them at this point. ...
>>I agree totally. C and C++ are separate languages. They are now used
>>in different areas. Many places where C is used it would not be possible
>>to use C++.
>Do you mean that no C++ compiler exists for the target platform?
>If so, you obviously can't use C++. If you mean something else,
>you should be more specific.
the architecture.
>Since with minor syntactic exceptions, valid C is also valid C++
>and should generate identical object code,
Hardly... It depends on optimisations etc. I would be more than
surprised if both generated the same code.
>I wonder what else you
>could mean. My experience in converting C programs to C++ has been
>that the source and object code got smaller, and the code ran faster.
Only using the parts of C++ that are identical to C? Thus you are only
generating C. I doubt you could write a C++ compiler that would
generate smaller object code than the current C compiler I use. Actually
most (if not al) of the other C compilers for the target can not match the
C compiler I use. Which is why (despite it being £1500) I use it.
>>In embedded engineering for example on 8 bit systems one is never
>>going to use C++ (I often only have 128 or 256 bytes of RAM and
>>64K of code space due to the hardware architecture!)
>
>Many embedded-system developers, especially in Japan, write in C++.
I am sure they do. I have done in the UK and Europe. It depends on
your target. (mine wre a PowerPC, 486 and Sparc). Which 8 bit micro
were these Japanese programming then?
>I don't understand why having limited memory in the target system
>would be a factor, assuming you are using cross-compilers anyway.
OK try a "standard " 8051. 128 bytes of ram, 4K code space now
gets the same functionality in that with C++ as I can with C :-) The only
way you will do it is by cutting down your C++ compiler until it is a C
compiler. That or producing a C compiler with a few extra bits on. this
will be neither one thing nor the other.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\/\ Chris Hills Staffs /\/\/\/\/\/
/\/\/\/\/\/\/\/\/\ England /\/\/\/\/\/\/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Darin Adler
Steve Clamage <cla...@eng.sun.com> wrote:
>>I don't understand why having limited memory in the target system
>>would be a factor, assuming you are using cross-compilers anyway.
Chris Hills <ch...@phaedsys.demon.co.uk> wrote:
> OK try a "standard " 8051. 128 bytes of ram, 4K code space now
> gets the same functionality in that with C++ as I can with C :-) The only
> way you will do it is by cutting down your C++ compiler until it is a C
> compiler. That or producing a C compiler with a few extra bits on. this
> will be neither one thing nor the other.
I don't get your point, Chris.
If I write a simple C program (compatible with C++) for your 8051 and
compile it with a C++ compiler, it should be no larger and consume no more
resources that if I compiled the same program with a C compiler. In fact, it
would typically be byte-for-byte the same.
If I then modify the program to use C++ features, such as declaring
variables as they are used instead of the top of a block, using const
instead of #define, and using inline instead of #define, that shouldn't make
the code any larger than equivalent C code.
There are other C++ features that could make the program larger, but I
wouldn't necessarily use those if I had to fit it into 4K of code space and
128 bytes of RAM. If I did, it's got nothing to do with the compiler -- it's
my choice.
What does cutting down the C++ compiler have to do with it? The compiler
doesn't run on the 8051, because it's a cross compiler that runs on a
desktop computer.
-- Darin
alan_gr...@my-deja.com
In article <HHnDCnAq...@phaedsys.demon.co.uk>,
Chris Hills <ch...@phaedsys.demon.co.uk> wrote:
[snip]
>
> I agree totally. C and C++ are separate languages. They are now used
> in different areas. Many places where C is used it would not be
> possible to use C++.
makes it impossible.
> In embedded engineering for example on 8 bit systems one is never
> going to use C++ (I often only have 128 or 256 bytes of RAM and
> 64K of code space due to the hardware architecture!)
I'm speculating, but is the issue that some C++ features (e.g. exception
handling) have a fixed base overhead - so while they save code (source
and generated) on larger systems they cost on small ones?
> Given that the main use of C is going to be embedded (much of which is
> safety critical) as in most other areas c++ has superseded it I would
> look at making C safer and more compact that a contorted imitation of
> C++.
FWIW I think that continuing to constrain either of the languages to
"compatability" is of diminishing benefit.
--
Alan Griffiths (alan.gr...@experian.com, +44 115 934 4517)
Senior Systems Consultant, Experian
Sent via Deja.com http://www.deja.com/
Before you buy.
Francis Glassborow
In article <b5pktAAR...@phaedsys.demon.co.uk>, Chris Hills
<ch...@phaedsys.demon.co.uk> writes
>OK try a "standard " 8051. 128 bytes of ram, 4K code space now
>gets the same functionality in that with C++ as I can with C :-) The only
>way you will do it is by cutting down your C++ compiler until it is a C
>compiler. That or producing a C compiler with a few extra bits on. this
>will be neither one thing nor the other.
I assume that you are not trying to run a C compiler directly on the
target:) What the compiler must do is generate object code which is
eventually converted to machine code for the target. While I understand
that special purpose (usually non-conforming) compilers can do
exceptionally good optimisations of C code for low resource embedded
systems this is not inherent in the choice of language.
Of course you have no need for a new compiler if the existing one does
all you want. I suspect that C9X will offer little for such a system.
But, IMHO, this is not a language issue.
>
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Francis Glassborow
>the architecture.
Sorry Chris, but I simply do not believe that. CFront back-ended onto a
C compiler. If you can have a C compiler you can have a C++ cross-
compiler for the same architecture.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
Douglas A. Gwyn
> I just hope that the differences in formulation doesn't lead to
> differences in interpretation and use.
WG14 is, as I see it (not speaking officially here), committed
to maintain a high degree of compatibility between C and C++ in
the part that overlaps (or might some day overlap). So long as
we work together on resolving these issues, there shouldn't be
much problem in maintaining this property.
Steve Clamage
se...@plethora.net (Peter Seebach) writes:
>In article <7t813q$j0c$1...@engnews1.eng.sun.com>,
>Steve Clamage <cla...@eng.sun.com> wrote:
>>Since with minor syntactic exceptions, valid C is also valid C++
>>and should generate identical object code, I wonder what else you
>>could mean. My experience in converting C programs to C++ has been
>>that the source and object code got smaller, and the code ran faster.
>I'm not convinced that these "minor" syntactic exceptions are really so
>minor.
If you have existing K&R C code, getting it to compile as C++
is somewhat annoying and tedious.
If you write professional quality Standard C code -- by which I mean
you use standard headers, function prototypes, and declare everything
-- the differences are small. The main problems will be in C's
implicit conversion of void* to other pointer types, and that shows
up primarily in uses of malloc. A system such as you describe probably
is not using malloc.
If you are writing new code, it is not difficult to write it so that
it is valid in both C and C++. In fact, by making it valid C++,
you get the benefit of making your code safer in ways that the
C compiler does not enforce.
>Most importantly, you lose a lot of good idiom when trying to do that.
Can you provide an example? I don't know of any C idioms that
represent good programming practice that are invalid in C++.
The exception would be use of malloc, as noted above.
--
Steve Clamage, stephen...@sun.com
Steve Clamage
Chris Hills <ch...@phaedsys.demon.co.uk> writes:
>Steve Clamage <cla...@eng.sun.com> writes
>>
>>Chris Hills <ch...@phaedsys.demon.co.uk> writes:
>>
>>>Peter Seebach <se...@plethora.net> writes
>>>>I hate to be seen as a heritic, but frankly, compatability hurts both
>>>>languages more than it helps either of them at this point. ...
>>>I agree totally. C and C++ are separate languages. They are now used
>>>in different areas. Many places where C is used it would not be possible
>>>to use C++.
>>Do you mean that no C++ compiler exists for the target platform?
>Correct.
>>If so, you obviously can't use C++. If you mean something else,
>>you should be more specific.
>It does not exist because it is not possible to write a C++ compiler for
>the architecture.
So you are saying that compatibility between C and C++ hurts
both languages because no C++ compiler can exist for some of
your target platforms? I don't follow that logic.
>>Since with minor syntactic exceptions, valid C is also valid C++
>>and should generate identical object code,
>Hardly... It depends on optimisations etc. I would be more than
>surprised if both generated the same code.
Again, I don't see the logic. Given two C compilers, one might
generate worse code. By your logic, you therefore shouldn't use C.
Where one vendor provides both C and C++ compilers, it is common
for them to share optimizers and code generators. In such cases
is it common for them to generate identical -- or at least
equivalent -- code.
>>I wonder what else you
>>could mean. My experience in converting C programs to C++ has been
>>that the source and object code got smaller, and the code ran faster.
>Only using the parts of C++ that are identical to C?
No, by taking advantage of C++ high-level constructs that are
unavailable in C.
One example: We converted C string handling to a C++ string class
that derived from a block allocator. (The class was custom-written
for the application.) The source and object code shrank by 20%, and
performance improved by 15%. The C++ code of course could have been
simulated in C, but the result would have been impossible to
understand or maintain.
> I doubt you could write a C++ compiler that would
>generate smaller object code than the current C compiler I use. Actually
>most (if not al) of the other C compilers for the target can not match the
>C compiler I use. Which is why (despite it being =A31500) I use it.
You are changing the terms of discourse. That difference is not in
the C++ language, but the in that you have a compiler whose
performance you believe cannot be equaled or bettered.
>>I don't understand why having limited memory in the target system
>>would be a factor, assuming you are using cross-compilers anyway.
>OK try a "standard " 8051. 128 bytes of ram, 4K code space now
>gets the same functionality in that with C++ as I can with C :-) The only
>way you will do it is by cutting down your C++ compiler until it is a C
>compiler. That or producing a C compiler with a few extra bits on. this
>will be neither one thing nor the other.
Why would you need to cut down the C++ compiler? If some C++
language feature has run-time consequences you can't afford,
don't use it. But for each application requirement, you have to
code it somehow. My experience has been that C++ lets you get
runtime efficiency with safe and portable code in ways that are
not available in C.
T.E.Dickey
>>Most importantly, you lose a lot of good idiom when trying to do that.
> Can you provide an example? I don't know of any C idioms that
> represent good programming practice that are invalid in C++.
> The exception would be use of malloc, as noted above.
C++'s notion of the scope of const differs from C's (a nuisance when I
test-compile some programs with C++ that are written for ANSI C - so I
have to add an 'extern' to make them link).
--
Thomas E. Dickey
dic...@clark.net
http://www.clark.net/pub/dickey
David R Tribble
Peter Seebach wrote:
> I hate to be seen as a heretic, but frankly, compatability hurts both
> languages more than it helps either of them at this point. You don't
> need to "convert" a project to C++; if you wrote it in C, the design
> will be sucky for a C++ program anyway.
Not necessarily; you can use object-oriented programming techniques
in C, it just requires a little more discipline.
> On the other hand, if we could admit this and stop putting effort
> into making things "compatible" when they really won't be quite
> compatible enough anyway, any number of warts could get cleared up.
But there will be a desire to call C from C++ and visa versa, so
we (as language designers) would like to keep them compatible for
a while yet.
And there is the argument that people who learn C first shouldn't
be too terribly surprised by unnecessary incompatibilities when moving
to C++. More importantly, people (like me) who program in both C
and C++ don't relish the aggravation that comes from unnecessary
incompatibilities when switching between the two.
-- David R. Tribble, da...@tribble.com, http://www.david.tribble.com --
David R Tribble
Bjarne Stroustrup wrote:
>
> "Douglas A. Gwyn" <DAG...@null.net> writes:
>> ...
>> which started out with incompatibilities such as int foo();
>> that make it pretty annoying to be told by C++'s designer that we
>> are not paying enough attention to compatibility.
>
>
> int f();
>
> int g() { return f(3); }
>
> is good C?
>
> Could anyone in good concience ship a program containing such code?
Seems to me a awful lot of Unix code looks (and still looks) like
that.
> Is it on the list of deprecated features in ANSI C?
Yes. It was deprecated in C89, in fact (6.9.4).
> Is it still allowed in C9x?
Yes, and it's still marked as deprecated (6.11.4).
A little strange when you consider than implict int (which is of
the same order of badness) was not deprecated in C89 but is gone
completely in C9X.
Vesa A J Karvonen
> In article <HHnDCnAq...@phaedsys.demon.co.uk>,
> Chris Hills <ch...@phaedsys.demon.co.uk> wrote:
> [snip]
> >
> > I agree totally. C and C++ are separate languages. They are now used
> > in different areas. Many places where C is used it would not be
> > possible to use C++.
> ^^^^^^^^- This is a pretty strong assertion, can you elaborate on what
> makes it impossible.
> > In embedded engineering for example on 8 bit systems one is never
> > going to use C++ (I often only have 128 or 256 bytes of RAM and
> > 64K of code space due to the hardware architecture!)
> I'm speculating, but is the issue that some C++ features (e.g. exception
> handling) have a fixed base overhead - so while they save code (source
> and generated) on larger systems they cost on small ones?
[snip]
If the entire program is linked statically, then a smart linker can
strip off data and code that is never referenced. This can be done by
giving every statically allocated construct a section. If a section can
never be legally referenced by code, then the section can be removed. Of
course, in order for this to be really beneficial, the linker must
perform a true garbage collection pass, e.g. mark-and-sweep, on the
sections.
If a compiler is targeted at an embedded system, where space is already
very scarce, then I would certainly expect it to be able to do this even
for C. So, unless the compiler is poor quality, I don't see this as a
major advantage of C, because the linker can eliminate all the extra
stuff generated for RTTI and exception handling. Furthermore, many C++
compilers let you choose whether RTTI or exception handling support is
generated.
---
Vesa Karvonen
---
Peter Seebach
Steve Clamage <cla...@eng.sun.com> wrote:
>If you write professional quality Standard C code -- by which I mean
>you use standard headers, function prototypes, and declare everything
>-- the differences are small. The main problems will be in C's
>implicit conversion of void* to other pointer types, and that shows
>up primarily in uses of malloc. A system such as you describe probably
>is not using malloc.
Fair enough; I had been thinking of slightly larger systems, where you
want things like malloc.
>If you are writing new code, it is not difficult to write it so that
>it is valid in both C and C++. In fact, by making it valid C++,
>you get the benefit of making your code safer in ways that the
>C compiler does not enforce.
But you do this by throwing away "unsafe" idioms, such as an uncast malloc,
which are part of what makes C such a delightful language.
Writing code which isn't idiomatic produces greater maintenance costs.
>>Most importantly, you lose a lot of good idiom when trying to do that.
>Can you provide an example? I don't know of any C idioms that
>represent good programming practice that are invalid in C++.
>The exception would be use of malloc, as noted above.
Yes. Well, frankly, for any real code, I'm pretty much committed to using
malloc correctly, and that means none of my code is C++-compatible, and if
you're going to listen for the sound of violins at this point, you'll need
a pretty hefty amplifier. I have, so far, found *no* use for C compatability.
If you have a hypothetical piece of C code which is genuinely useful to C++
users, the *CORRECT* way to produce compatability is
#ifdef __cplusplus
extern "C" {
#endif
...
in the header. Trying to make sure it stays in the common subset is a waste
of resources.
Polyglots have been interesting IOCCC entries in the past, and make for
amusing reading. I don't think the "practical" application is a real one.
-s
--
Copyright 1999, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
David R Tribble
>
> Bjarne Stroustrup <b...@research.att.com> writes
>> The aim of the C and C++ rules are to approximate the ideal of a
>> single definition in a single place (if you don't believe me for C,
>> check with Dennis).
>
> I don't believe you for C. inline is new in C9X; I was there, but
> neither you nor Dennis were.
I took Bjarne's quote to mean something different. I didn't see it
as referring to 'inline' at all, but rather as talking about the ideal
of the one definition rule (ODR).
Ideally, both C and C++ strive for the ODR. Specifically applied
to 'inline' declarations, C took the easy approach and C++ took the
hard approach. Neither is perfect.
Consider that C allows two inline function definitions that operate
as if they are the same sequence of tokens, but don't have to be.
This makes it invalid to define inconsistent definitions of a
given inline function, but does not require the compiler to verify
this.
C++, on the other hand, mandates that all inline defintions of a
given function must be the exact same sequence of tokens.
Thus the following is valid (but unverifiable) C code, but invalid
C++ code:
// foo.c
inline int func(int i) { return i*2; }
// bar.c
typedef int i_type;
inline i_type func(i_type i) { return (i*2); }
But as Doug Gwyn points out, this is not very likely in practice,
so this kind of incompatibility should be considered minimal and
only accidentally produced.
-- David R. Tribble, da...@tribble.com, http://www.david.tribble.com --
Zalman Stern
: But you do this by throwing away "unsafe" idioms, such as an uncast malloc,
: which are part of what makes C such a delightful language.
Given that I've heard many a "C gray beard" claim that you should always
put the cast in anyway, I think this is debatable...
[...]
: If you have a hypothetical piece of C code which is genuinely useful to C++
: users, the *CORRECT* way to produce compatability is
: #ifdef __cplusplus
: extern "C" {
: #endif
: ...
: in the header. Trying to make sure it stays in the common subset is a waste
: of resources.
Which only works because C++ follows C89 closely and C++ implementations on
a given platform use the same conventions as "the" C compiler on that
platform. Things will not be so convenient in a post-C9X world if you use
new C9X features in your interfaces. (Which is not to say anything about
what C9X should or should not do. It is merely a statement of fact.)
: Polyglots have been interesting IOCCC entries in the past, and make for
: amusing reading. I don't think the "practical" application is a real one.
Lots of libraries will have to keep their interfaces at a C89 level to be
compatible with C++ use. Other people will go ahead and use any of a number
of techniques that exist for supporting a single library across many
languages. None of which are as simple as just writing a .h file I'm
afraid...
-Z-
Francis Glassborow
<se...@plethora.net> writes
>If you have a hypothetical piece of C code which is genuinely useful to C++
>users, the *CORRECT* way to produce compatability is
> #ifdef __cplusplus
> extern "C" {
> #endif
> ...
>in the header. Trying to make sure it stays in the common subset is a waste
>of resources.
However you better make sure the definition is compiled by a C compiler
because that extern "C" qualification only refers to linkage and calling
requirements. And the C compiler better be compatible with the C++ one
in so far as calling requirements are concerned.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Clive D.W. Feather
<da...@tribble.com> writes
>Consider that C allows two inline function definitions that operate
>as if they are the same sequence of tokens, but don't have to be.
>This makes it invalid to define inconsistent definitions of a
>given inline function, but does not require the compiler to verify
>this.
No, C explicitly allows two inline function definitions to have
different behaviours, let alone different token sequences.
--
Clive D.W. Feather | Internet Expert | Work: <cl...@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd. | Home: <cl...@davros.org>
Fax: +44 20 8371 1037 | | Web: <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
James...@dresdner-bank.com
se...@plethora.net (Peter Seebach) wrote:
> In article <7t813q$j0c$1...@engnews1.eng.sun.com>,
> Steve Clamage <cla...@eng.sun.com> wrote:
> >Since with minor syntactic exceptions, valid C is also valid C++
> >could mean. My experience in converting C programs to C++ has been
> >that the source and object code got smaller, and the code ran faster.
> I'm not convinced that these "minor" syntactic exceptions are really
> so minor.
> Most importantly, you lose a lot of good idiom when trying to do that.
> >Many embedded-system developers, especially in Japan, write in C++.
> >I don't understand why having limited memory in the target system
> >would be a factor, assuming you are using cross-compilers anyway.
> Huh. I wonder why they cared so much about changes to C9X, if they
> were gonna use C++. ;-)
> Limited memory means that most of the C++ extra features are
> unavailable, at which point, better to use a language where the
> operations you can perform are as easy to read as possible. :)
Many of the Japanese manufacturers are actually using a subset of C++,
called EC++. In turn, I could imagine for the smallest processors
(8051, for example), that only a subset of EC++ could be used (but that
some C++ features not in EC++, like templates, might be useful). Still,
having programmed C ten years, declaring struct's and a series of
functions manipulating them, then crossing my fingers that no one
accessed the struct fields other than by one of my functions, I'm not
about to forgo member functions and private data members if I can avoid
it. And I fail to see where these features would cause larger code or
data sets.
--
James Kanze mailto: James...@dresdner-bank.com
Conseils en informatique orientée objet/
Beratung in objekt orientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Sent via Deja.com http://www.deja.com/
Before you buy.
James...@dresdner-bank.com
David R Tribble <da...@tribble.com> wrote:
> Thus the following is valid (but unverifiable) C code, but invalid
> C++ code:
>
> // foo.c
>
> inline int func(int i) { return i*2; }
>
> // bar.c
>
> typedef int i_type;
>
> inline i_type func(i_type i) { return (i*2); }
> But as Doug Gwyn points out, this is not very likely in practice, so
> this kind of incompatibility should be considered minimal and only
> accidentally produced.
It's probably also worth pointing out that while this example is
undefined behavior in C++, with all of the C++ compilers I know, it will
in fact have the same results as in C.
I'm not sure that this is a good thing. If I understand the situation
in C, I think that the code would be legal even if, for example, the
second version multiplied i by 3. Legal, but with it undefined which
version of func was actually called. If this is the case, it is nothing
but a potential source of errors. At least a conforming implementation
in C++ can signal the errors.
Signaling them in this case is not as hard as it would seem. Generally
speaking, it would suffice if the compiler generated a 32 bit hashcode
for anything covered by the ODR, and put this in the object file. The
linker then verifies that all of the hashcodes are the same. IMHO, it
is a shame that C excludes this possibility.
Douglas A. Gwyn
> But you do this by throwing away "unsafe" idioms, such as an uncast malloc,
> which are part of what makes C such a delightful language.
While I have always explicitly cast malloc's value to the desired type,
there is a legitimate argument that this obscures a possible error,
when a prototype for malloc is not in scope.
alan_gr...@my-deja.com
In article <7tb2es$a7c$1...@oravannahka.helsinki.fi>,
Vesa A J Karvonen <vkar...@cc.helsinki.fi> wrote:
> In comp.std.c++ alan_gr...@my-deja.com wrote:
>
> > In article <HHnDCnAq...@phaedsys.demon.co.uk>,
> > handling) have a fixed base overhead - so while they save code (source
> > and generated) on larger systems they cost on small ones?
> [snip]
>
> If the entire program is linked statically, then a smart linker can
> strip off data and code that is never referenced. This can be done by
> giving every statically allocated construct a section. If a section can
> never be legally referenced by code, then the section can be removed. Of
> course, in order for this to be really beneficial, the linker must
> perform a true garbage collection pass, e.g. mark-and-sweep, on the
> sections.
OK (sticking to the EH example) given a significant degree of
implementation "magic" and if no exceptions are thrown then it is
theoretically possible to remove the RTL support for stack unwinding and
any data structures it uses.
> If a compiler is targeted at an embedded system, where space is already
> very scarce, then I would certainly expect it to be able to do this even
> for C. So, unless the compiler is poor quality, I don't see this as a
> major advantage of C,
Well there is more to eliminate. For instance a global flow analysis may
be required to determine which implementations of virtual functions are
redundant. (Most linkers - understandably - seem to attach everything
mentioned in a vtab.)
> because the linker can eliminate all the extra
> stuff generated for RTTI and exception handling. Furthermore, many C++
> compilers let you choose whether RTTI or exception handling support is
> generated.
:)
Pragmatically there may be no current C++ implementation that is
adequate for resource constrained environments. My original query was
"are they really impossible?" - you appear to believe not.
--
Alan Griffiths (alan.gr...@experian.com, +44 115 934 4517)
Senior Systems Consultant, Experian
Sent via Deja.com http://www.deja.com/
Before you buy.
James...@dresdner-bank.com
In article <7tasn0$ce7$1...@engnews1.eng.sun.com>,
cla...@eng.sun.com (Steve Clamage) wrote:
> Why would you need to cut down the C++ compiler? If some C++
> language feature has run-time consequences you can't afford,
> don't use it. But for each application requirement, you have to
> code it somehow. My experience has been that C++ lets you get
> runtime efficiency with safe and portable code in ways that are
> not available in C.
If the compiler supports exceptions, there will likely be significant
space overhead unless it is told explicitly that exceptions will not be
used.
The real problem is, I suspect, that most applications will not be able
to use very many, if any of the C++ features. Given this, it is likely
to be economically unviable to try and support these features, when
there is no demand for them. (This is, of course, part of the argument
behind EC++.) Thus, no C++ compiler is available, nor likely to become
available.
This is regrettable, because of all the C++ features, IMHO, the single
biggest win is member functions and private members. With only 128
bytes RAM and 4K ROM, intensive OO or generic programming is probably
not an issue. But having been there, I can assure you that even with
only 4K of program, encapsulation *is* an issue. And of course, member
functions and private members do not have any space overhead.
--
James Kanze mailto: James...@dresdner-bank.com
Conseils en informatique orientée objet/
Beratung in objekt orientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Steve Clamage
"Clive D.W. Feather" <cl...@on-the-train.demon.co.uk> writes:
>In article <37F92C16...@tribble.com>, David R Tribble
><da...@tribble.com> writes
>>Consider that C allows two inline function definitions that operate
>>as if they are the same sequence of tokens, but don't have to be.
>>This makes it invalid to define inconsistent definitions of a
>>given inline function, but does not require the compiler to verify
>>this.
>No, C explicitly allows two inline function definitions to have
>different behaviours, let alone different token sequences.
I've lost track of what is being objected to in this thread, and
I think two aspects of C++ might be getting mixed up.
Originally in C++, a non-member inline function had internal
linkage, like a static function. If the function was generated out
of line by the compiler, it was equivalent to a static function.
For various reasons, the C++ standard now says that "inline"
does not affect function linkage.
If you declare a C++ inline function static, it has the old
properies of inline functions in C++, and if I understand
correctly, the same as in C9X.
If you don't declare a C++ inline function static, it has external
linkage. The One-Definition Rule requires that all versions of an
external inline function be the same. The C++ standard says the
the token sequences must be the same, although that is an
over-specification.
--
Steve Clamage, stephen...@sun.com
David R Tribble
ISO C and ISO C++", revision 0.06, is available online at:
<http://david.tribble.com/text/cdiffs.htm> (61 KB).
I've incorporated only about half of the comments and suggestions I've
received to date; the rest will appear in another draft. Further
comments are welcome, either by email or postings to <news:comp.std.c>
or <news:comp.std.c++>. (I need a better section title than
"Changes to C9X versus C++".)
-- David R. Tribble, da...@tribble.com, http://www.david.tribble.com --
---
Doug Gwyn (ISTD/CNS) <gwyn>
> At least a conforming implementation in C++ can signal the errors.
So can a conforming C9x implementation.
Fergus Henderson
>In comp.std.c Steve Clamage <cla...@eng.sun.com> wrote:
>
>>>Most importantly, you lose a lot of good idiom when trying to do that.
>
>> Can you provide an example? I don't know of any C idioms that
>> represent good programming practice that are invalid in C++.
>> The exception would be use of malloc, as noted above.
>
>C++'s notion of the scope of const differs from C's (a nuisance when I
>test-compile some programs with C++ that are written for ANSI C - so I
>have to add an 'extern' to make them link).
That may well be a nuisance, but it's hardly the loss of a good idiom.
You can still use the same idiom, you just have to spell it differently.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
Fergus Henderson
>I have, so far, found *no* use for C compatability.
>
>If you have a hypothetical piece of C code which is genuinely useful to C++
>users, the *CORRECT* way to produce compatability is
> #ifdef __cplusplus
> extern "C" {
> #endif
> ...
>in the header. Trying to make sure it stays in the common subset is a waste
>of resources.
For that technique to work, the stuff in the header file, including any
macros and inline functions, still needs to be in the common subset.
Éamonn McManus
> Peter Seebach wrote:
> > But you do this by throwing away "unsafe" idioms, such as an uncast malloc,
> > which are part of what makes C such a delightful language.
> While I have always explicitly cast malloc's value to the desired type,
> there is a legitimate argument that this obscures a possible error,
> when a prototype for malloc is not in scope.
t.c:2: warning: implicit declaration of function `malloc'
,
Eamonn
Peter Seebach
In article <37F930C0...@tribble.com>,
David R Tribble <da...@tribble.com> wrote:
>Peter Seebach wrote:
>> I hate to be seen as a heretic, but frankly, compatability hurts both
>> languages more than it helps either of them at this point. You don't
>> need to "convert" a project to C++; if you wrote it in C, the design
>> will be sucky for a C++ program anyway.
>Not necessarily; you can use object-oriented programming techniques
>in C, it just requires a little more discipline.
Sure, but even then, so much of the implementation-level design will be
wrong...
>But there will be a desire to call C from C++ and visa versa, so
>we (as language designers) would like to keep them compatible for
>a while yet.
That's what 'extern "C"' is for.
People call C from Fortran and vice versa, too; anyone who wants to implicitly
declare all variables starting with 'i' through 'k' as plain int, raise your
hands. :)
>And there is the argument that people who learn C first shouldn't
>be too terribly surprised by unnecessary incompatibilities when moving
>to C++. More importantly, people (like me) who program in both C
>and C++ don't relish the aggravation that comes from unnecessary
>incompatibilities when switching between the two.
The problem, I think, lies in the question of what is "necessary". Is the \u
monstrosity a *necessary* "compatability"? We had technically better
solutions and ended up going against them because, while we agreed that they
solved important problems, they were not "compatible". So, the question is,
does the convenience of having the languages match on these points outweigh
the damage done?
I don't think it does, and I don't think it has for a long time. It's
probably too late to fix a lot of these things, but I think it's about time
to stop introducing more botches.
Should C++ add VLA's and compound literals? No. They have something better
*for C++*. It doesn't make sense to change C that way, so we do things
differently.
-s
--
Copyright 1999, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Jonathan de Boyne Pollard
T.E.Dickey wrote:
> In comp.std.c Steve Clamage <cla...@eng.sun.com> wrote:
> >>Most importantly, you lose a lot of good idiom when trying to
> >>do that.
>
> > Can you provide an example? I don't know of any C idioms that
> > represent good programming practice that are invalid in C++.
> > The exception would be use of malloc, as noted above.
>
You mean "linkage", not "scope", surely ?
T.E.Dickey
>>C++'s notion of the scope of const differs from C's (a nuisance when I
>>test-compile some programs with C++ that are written for ANSI C - so I
>>have to add an 'extern' to make them link).
> That may well be a nuisance, but it's hardly the loss of a good idiom.
> You can still use the same idiom, you just have to spell it differently.
yes (with an ifdef ;-)
T.E.Dickey
> T.E.Dickey wrote:
>> C++'s notion of the scope of const differs from C's [...]
> You mean "linkage", not "scope", surely ?
Yes (the technically correct term, though usage makes them near-synonyms --
some people object to my terminology, but usually not my spelling ;-)
James Kuyper
"T.E.Dickey" wrote:
>
> In comp.std.c Fergus Henderson <f...@cs.mu.oz.au> wrote:
> >>C++'s notion of the scope of const differs from C's (a nuisance when I
> >>test-compile some programs with C++ that are written for ANSI C - so I
> >>have to add an 'extern' to make them link).
>
> > That may well be a nuisance, but it's hardly the loss of a good idiom.
> > You can still use the same idiom, you just have to spell it differently.
>
> yes (with an ifdef ;-)
Why do you need an ifdef? What's wrong with making it explicitly
'extern' in both cases?
Juergen Heinzl
It depends on the compiler and warnings are to be gracefully ignored
by the developer ;-)
Ta',
Juergen
--
\ Real name : Jürgen Heinzl \ no flames /
\ EMail Private : jue...@monocerus.demon.co.uk \ send money instead /
Konrad Schwarz
>
> In comp.std.c Peter Seebach <se...@plethora.net> wrote:
> : But you do this by throwing away "unsafe" idioms, such as an uncast malloc,
> : which are part of what makes C such a delightful language.
>
> put the cast in anyway, I think this is debatable...
>
introduced
specifically as a pointer type that is compatible with any other pointer
type.
If (as in C++), void * loses this property, it would have sufficed to
stay
with char * (or caddr_t, a synonym).
In fact, I argue that using the cast is contraproductive. Consider:
void *a_malloc (size_t);
struct something *b_malloc (size_t);
struct something_else *const ap = (struct something_else *) b_malloc
(5);
/* error, programmer meant to use a_malloc() */
This error is not caught by the compiler, but would have been if the
cast
had been left out. Using a cast means that the compiler can no longer
help you.
> : If you have a hypothetical piece of C code which is genuinely useful to C++
> : users, the *CORRECT* way to produce compatability is
> : #ifdef __cplusplus
> : extern "C" {
> : #endif
> : ...
> : in the header. Trying to make sure it stays in the common subset is a waste
> : of resources.
>
> Which only works because C++ follows C89 closely and C++ implementations on
> a given platform use the same conventions as "the" C compiler on that
> platform. Things will not be so convenient in a post-C9X world if you use
> new C9X features in your interfaces. (Which is not to say anything about
> what C9X should or should not do. It is merely a statement of fact.)
No, actually C++ must now contain a C9X parser to parse code
(definitions, at least) contained within extern "C" { ... } statements.
Maybe the preprocessor
will have to change its behavior according to which language it is
working on.
Sounds like a lot of fun :-).
--
Konrad Schwarz konrad_...@mcdDOTmot.com
Motorola Computer Group
81829 M"unchen Schatzbogen 7 Tel: +49 89 92103 828
81809 M"unchen Postfach 820960 Fax: +49 89 92103 266
---
Nick Maclaren
In article <hcPK3.910$N64....@dfw-read.news.verio.net>,
T.E.Dickey <dic...@shell.clark.net> wrote:
>In comp.std.c Jonathan de Boyne Pollard <J.deBoyn...@tesco.net> wrote:
>
>> T.E.Dickey wrote:
>>> C++'s notion of the scope of const differs from C's [...]
>
>> You mean "linkage", not "scope", surely ?
>
>Yes (the technically correct term, though usage makes them near-synonyms --
>some people object to my terminology, but usually not my spelling ;-)
Did you mean to post this to comp.std.c?
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Peter Seebach
Zalman Stern <zal...@netcom16.netcom.com> wrote:
>In comp.std.c Peter Seebach <se...@plethora.net> wrote:
>: But you do this by throwing away "unsafe" idioms, such as an uncast malloc,
>: which are part of what makes C such a delightful language.
>Given that I've heard many a "C gray beard" claim that you should always
>put the cast in anyway, I think this is debatable...
Certainly! But the graybeards tend to date back to times before (void *).
Without (void *), a lot of casts are necessary. (void *) is there to let
you omit "trivial" casts; this allows better documentation, as it becomes
more clear when you really mean "reinterpret this".
>Which only works because C++ follows C89 closely and C++ implementations on
>a given platform use the same conventions as "the" C compiler on that
>platform. Things will not be so convenient in a post-C9X world if you use
>new C9X features in your interfaces. (Which is not to say anything about
>what C9X should or should not do. It is merely a statement of fact.)
In your interfaces, sure. But that's the same with issue with Fortran, too.
If you want code to be compatible with calls to or from a *separate language*,
you adapt your interfaces. You don't change the entire language and throw
out good features or designs just to make the calling code easier. You just
agree on what the common interface looks like, and how it's spelled.
I've seen lots of C that does
void foo(int s1len, char *s1);
for compatability with some Fortran compilers. Does this mean C *must*
integrate strings with a length attached to them in the language, to make it
easier to handle the calling conventions? No. You build common interfaces
and leave it at that.
-s
--
Copyright 1999, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
---
Pete Becker
>
>
> No, actually C++ must now contain a C9X parser to parse code
> (definitions, at least) contained within extern "C" { ... } statements.
No. extern "C" does not say to compile code as if it were C code. It
says to compile functions defined within the block using the C calling
convention (whatever that means) so they can be called from C code. It
is still C++ code.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
James Kuyper
>
> In comp.std.c Jonathan de Boyne Pollard <J.deBoyn...@tesco.net> wrote:
>
> > T.E.Dickey wrote:
> >> C++'s notion of the scope of const differs from C's [...]
>
> > You mean "linkage", not "scope", surely ?
>
> Yes (the technically correct term, though usage makes them near-synonyms --
> some people object to my terminology, but usually not my spelling ;-)
Scope and linkage are very different things. Usage that treats them as
near-synonyms is guaranteed to both reflect and cause misunderstandings.
Read up on them before commenting further.
Zalman Stern
In comp.std.c Konrad Schwarz <konrad_...@mcd.motdotcom> wrote:
: What argument can be made for adding the cast?
I'm not really sure since I don't do this. It is probably a combination of
compatibility with pre-C89 compilers and the fact that in certain places,
such as an argument to a varargs function, the cast is required. Note that
people who insist on such casts generally also cast NULL to the desired
type before using it.
Here's another example:
struct foo *foo1, *foo2;
foo1 = malloc(sizeof(struct foo));
foo2 = (struct foo *)malloc(sizeof(struct foo));
If one changes only the first line of code to say "struct bar *", the alloc
of foo2 will give a typecheck error where the alloc of foo1 will not.
Point being we can argue all day about which errors are more common etc. I
don't think there is a single answer other than that adding a way to do
typesafe allocator functions to the language is a good idea (albeit rather
anithetical to the C ideal).
[...]
: No, actually C++ must now contain a C9X parser to parse code
: (definitions, at least) contained within extern "C" { ... } statements.
: Maybe the preprocessor
: will have to change its behavior according to which language it is
: working on.
: Sounds like a lot of fun :-).
I expect you are joking, but that isn't at all what extern "C" means in C++
. The code inside such a block still must be valid C++ but with some extra
restrictions. (E.g. the malloc example above will require a cast if
compiled with a C++ compiler even if it is in an extern "C" block.)
The bottom line is this issue will likely cause hassle for anyone trying to
aggressively use C9X features in public interfaces. There are some
techniques that can be used to work around this. Perhaps a defacto-standard
header that checks preprocessor symbols to determine the compilation
environment and does things like "#define restrict" if necessary. (Handling
VLAs will be much more difficult...) Such things will be developed not only
for C++/C9X interoperability but for backward compatibility with C89.
-Z-
T.E.Dickey
> Did you mean to post this to comp.std.c?
I posted it to comp.std.c, as a followup to someone's cross-posting to both
groups (I noticed this week some problem with my ISP's list of moderators,
but haven't had the time to track it down since it's not on a local machine -
will do that on the weekend).
T.E.Dickey
> Why do you need an ifdef? What's wrong with making it explicitly
> 'extern' in both cases?
simply because the compilers I used did not provide the proper linkage.
(iirc, that was SGI's C compiler - or perhaps Sun's - so I get the impression
that you're saying one of those isn't ANSI)
T.E.Dickey
T.E.Dickey
> Why do you need an ifdef? What's wrong with making it explicitly
> 'extern' in both cases?
to summarize (from email):
I reexamined the configuration that led me to believe that C++ treated
extern specially with 'const', and see that the vendor's current compiler
on that platform behaves as Mr Kuyper indicates. The compiler that I was
referring to was released around the time that the C++ draft became final -
and though I found it very reliable in other respects, apparently this
detail was not.
(I still need the ifdef in case someone builds a program with the older
compiler, but it's not an issue here as far as I'm concerned ;-)
Francis Glassborow
In article <37FB6AE4...@mcd.motDOTcom>, Konrad Schwarz
<konrad_...@mcd.motDOTcom> writes
>No, actually C++ must now contain a C9X parser to parse code
>(definitions, at least) contained within extern "C" { ... } statements.
No. This is a fundamental misunderstanding of how extern "C" works in
C++. It has no effect on definitions, only on declarations (or the
declarative part of a definition). If that is not clear, within the
body of a function definition C++ _always_ rules if a C++ compiler is
doing the compiling.
>
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Eric Friedman
In article <37FC3350...@acm.org>, Pete Becker <peteb...@acm.org> wrote:
>Konrad Schwarz wrote:
>>
>>
>> No, actually C++ must now contain a C9X parser to parse code
>> (definitions, at least) contained within extern "C" { ... } statements.
>
>says to compile functions defined within the block using the C calling
>convention (whatever that means) so they can be called from C code. It
>is still C++ code.
>
Doesn't extern "C" just turn off name mangling?
Eric
T.E.Dickey
In comp.std.c Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
> Did you mean to post this to comp.std.c?
I posted it to comp.std.c, as a followup to someone's cross-posting to both
groups (I noticed this week some problem with my ISP's list of moderators,
but haven't had the time to track it down since it's not on a local machine -
will do that on the weekend).
--
Thomas E. Dickey
dic...@clark.net
http://www.clark.net/pub/dickey
Konrad Schwarz
Zalman Stern wrote:
> Here's another example:
>
> struct foo *foo1, *foo2;
>
> foo1 = malloc(sizeof(struct foo));
> foo2 = (struct foo *)malloc(sizeof(struct foo));
>
> If one changes only the first line of code to say "struct bar *", the alloc
> of foo2 will give a typecheck error where the alloc of foo1 will not.
This problem is easily avoided by using
foo1 = malloc (sizeof *foo1);
(but you probably already knew that).
> I expect you are joking, but that isn't at all what extern "C" means in C++
> . The code inside such a block still must be valid C++ but with some extra
> restrictions. (E.g. the malloc example above will require a cast if
> compiled with a C++ compiler even if it is in an extern "C" block.)
No, I didn't know that.
--
Konrad Schwarz konrad_...@mcdDOTmot.com
Motorola Computer Group
81829 M"unchen Schatzbogen 7 Tel: +49 89 92103 828
81809 M"unchen Postfach 820960 Fax: +49 89 92103 266
James Kuyper
Eric Friedman wrote:
>
> In article <37FC3350...@acm.org>, Pete Becker <peteb...@acm.org> wrote:
> >Konrad Schwarz wrote:
> >>
> >>
> >> No, actually C++ must now contain a C9X parser to parse code
> >> (definitions, at least) contained within extern "C" { ... } statements.
> >
> >No. extern "C" does not say to compile code as if it were C code. It
> >says to compile functions defined within the block using the C calling
> >convention (whatever that means) so they can be called from C code. It
> >is still C++ code.
> >
>
> Doesn't extern "C" just turn off name mangling?
What it does is implementation defined. 'extern "C"' on a function type
does whatever needs to be done to make the that function type's
interface (argument passing and return value) conventions compatible
with C. 'extern "C"' on a function name does whatever's needed to make
that name useable in C code to refer to that function. 'extern "C"' on
an object does whatever's needed to allow C code to refer to that
object.
Matt Austern
efr...@mindspring.com (Eric Friedman) writes:
> >> No, actually C++ must now contain a C9X parser to parse code
> >> (definitions, at least) contained within extern "C" { ... } statements.
> >
> >No. extern "C" does not say to compile code as if it were C code. It
> >says to compile functions defined within the block using the C calling
> >convention (whatever that means) so they can be called from C code. It
> >is still C++ code.
> >
>
> Doesn't extern "C" just turn off name mangling?
A C++ implementation might handle extern "C" that way, but the
standard says no such thing. The word "mangling" does not appear in
the index of the C++ standard.
According to the C++ standard (section 7.5), C linkage means that
- the implementation uses C linkage and calling convention, whatever
that might mean
- two functions with C linkage in different namespaces are taken to
be the same
- the compiler verifies that at most one function with a particular
name has C linkage.
Nick Maclaren
|> In article <7tc1tl$i...@dfw-ixnews6.ix.netcom.com>,
|> Zalman Stern <zal...@netcom16.netcom.com> wrote:
|> >In comp.std.c Peter Seebach <se...@plethora.net> wrote:
|> >: But you do this by throwing away "unsafe" idioms, such as an uncast malloc,
|> >: which are part of what makes C such a delightful language.
|>
|> >Given that I've heard many a "C gray beard" claim that you should always
|> >put the cast in anyway, I think this is debatable...
|>
|> Certainly! But the graybeards tend to date back to times before (void *).
|> Without (void *), a lot of casts are necessary. (void *) is there to let
|> you omit "trivial" casts; this allows better documentation, as it becomes
|> more clear when you really mean "reinterpret this".
You can put it a lot more strongly - pointer casts are positively
undesirable except when they are essential!
They mean "I don't give a damn what sort of pointer this was, but
treat it like THIS". There have been (correct) statements that
this is software engineering insanity, and proposals to add precise
casts (i.e. "I think it is THAT, but treat it like THIS"), but they
have never got anywhere. From what I hear about C++, there are
enough differences from C in the subtleties of pointer casting that
there are ways to get confused by them, too.
This is actually made worse by the fact that many important C
applications relied (and may still rely) on casting between function
and object pointers, and many compilers allow it to support those
applications. There are some utterly unspeakable applications that
use casting instead of unions, or even to permit a function to be
called with a different number of arguments from its definition.
The first language that I know of to demonstrate that this sort of
casting was a mistake was Algol 68, which may even have introduced
the concept (even though Algol 68 casts were checked for validity.)
Experience quickly showed that this was a fruitful source of errors
and explicit type conversions were a much better idea. But that is
a different ball game.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
---
Francis Glassborow
<se...@plethora.net> writes
>Certainly! But the graybeards tend to date back to times before (void *).
>Without (void *), a lot of casts are necessary. (void *) is there to let
>you omit "trivial" casts; this allows better documentation, as it becomes
>more clear when you really mean "reinterpret this".
The problem with void * is that it actually has two distinct uses for
which different rules for implicit conversions should apply.
1) It is a generic data pointer to which any other data pointer should
be convertible implicitly.
2) It is a pointer to generic storage that is suitably aligned for any
type from which there should be implicit conversions to all types.
Note that either of these alone combined with a need for explicit
conversion in the reverse direction works fine. It is the combination
that has a dreadful hole in it. C++ fixed the hole one way but failed
to note that it now needed a second incomplete type to allow clean (cast
free) programming for case 2)
Perhaps C++ (next version) could consider introducing a type std::any to
fill that gap, or even C and C++ introduce _any next time round.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Peter Seebach
> foo1 = malloc(sizeof(struct foo));
> foo2 = (struct foo *)malloc(sizeof(struct foo));
>If one changes only the first line of code to say "struct bar *", the alloc
>of foo2 will give a typecheck error where the alloc of foo1 will not.
True. And the following patch will "fix" it:
> foo2 = (struct bar *)malloc(sizeof(struct foo));
:)
-s
--
Copyright 1999, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Steve Clamage
>Doesn't extern "C" just turn off name mangling?
No.
When you declare "C" linkage for a function, you tell the C++
compiler to use the same calling conventions as the C compiler.
For example, the C and C++ compilers might pass parameters
in different orders, or differ in whether caller or callee
pops the stack.
C linkage ordinarily means turning off name mangling, but that is
not a requirement. For example, the C++ compiler might not
mangle names, or the C compiler might do the same mangling
as the C++ compiler. (Nothing in the C standard prohibits
mangling names -- it isn't needed, so compilers don't do it.)
--
Steve Clamage, stephen...@sun.com
Paul Jarc
> In article <37FC3350...@acm.org>, Pete Becker <peteb...@acm.org> wrote:
> >says to compile functions defined within the block using the C calling
> >convention (whatever that means) so they can be called from C code. It
> >is still C++ code.
>
That might be how it's implemented in many cases, but the purpose is
to specify that a function uses the C calling convention, so that it
can be called from C or C++, and can (but need not) be defined in C.
So extern "C" turns off whatever it is that's different between the
local C and C++ calling conventions. This typically includes name
mangling, but could also include, e.g., whether arguments are passed
in registers.
paul
Pete Becker
> >>
> >>
> >> No, actually C++ must now contain a C9X parser to parse code
> >> (definitions, at least) contained within extern "C" { ... } statements.
> >
> >says to compile functions defined within the block using the C calling
> >convention (whatever that means) so they can be called from C code. It
> >is still C++ code.
> >
>
> Doesn't extern "C" just turn off name mangling?
>
That is one of the things that it might do. Usually it switches from
C++-style name mangling to C-style name mangling, as well as possibly
changing the order of arguments and maybe some other things. Mostly
that's irrelevant: the compiler does what's needed to make the functions
callable from C. Details depend on the C compiler that's being targeted.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
Jonathan de Boyne Pollard
> David R Tribble <da...@tribble.com> wrote:
> > Thus the following is valid (but unverifiable) C code, but invalid
> > C++ code:
> >
> > // foo.c
> > inline int func(int i) { return i*2; }
> >
> > // bar.c
> > typedef int i_type;
> > inline i_type func(i_type i) { return (i*2); }
>
> [...] At least a conforming implementation in C++ can signal
> the errors.
>
> Signal[l]ing them in this case is not as hard as it would seem.
> Generally speaking, it would suffice if the compiler generated a
> 32 bit hashcode for anything covered by the ODR, and put this in
> the object file. The linker then verifies that all of the
> hashcodes are the same.
Another way that some C++ compilers solve this problem is to use linker
features that allow segments from in multiple object files to be overlaid on
top of one another. DOS, Win16, Win32, and OS/2 linkers support a combine
type of "common". Code that is generated by an extern inline function, for
example, is emitted into an object file segment with a "common" combine type
attached to it, and the linker combines all such code into a single instance
in the resulting executable. I'm glossing over the details here, but
effectively all of the copies are overlaid on top of one another at link time.
I don't know offhand whether or not those linkers are smart enough to analyse
the various segment contents to ensure that the data (i.e. the object code
bytes) being overlaid are the same in all cases, but it is certainly not
impossible for them to do so.
This is, of course, equivalent to your scheme, with the exception that "actual
generated object code" has been substituted for "32 bit hashcode".
Compilation, in this regard, is just another hashing function. (-:
David R Tribble
Konrad Schwarz wrote:
> No, actually C++ must now contain a C9X parser to parse code
> (definitions, at least) contained within extern "C" { ... }
> statements.
No, the tokens within an extern "C" block must constitute valid C++
declarations and definitions. C9X features that are not valid C++
syntax don't magically become valid simply because they are prefixed
with extern "C".
Consider:
// C++ code
extern "C" int foo(); // zero args
This is not compatible with:
// C code
extern int foo(); // zero or more args
> Maybe the preprocessor will have to change its behavior according to
> which language it is working on. Sounds like a lot of fun :-).
More likely, C/C++ compilers will simply extend their preprocessors
to handle the C9X preprocessor syntax, which is a proper superset
(except for '__cplusplus') of C90 and C++ preprocessor syntax.
-- David R. Tribble, da...@tribble.com, http://www.david.tribble.com --
Steve Clamage
>You can put it a lot more strongly - pointer casts are positively
>undesirable except when they are essential!
>They mean "I don't give a damn what sort of pointer this was, but
>treat it like THIS". There have been (correct) statements that
>this is software engineering insanity, and proposals to add precise
>casts (i.e. "I think it is THAT, but treat it like THIS"), but they
>have never got anywhere. From what I hear about C++, there are
>enough differences from C in the subtleties of pointer casting that
>there are ways to get confused by them, too.
C++ divides casts into four (somewhat overlapping) categories,
inspired by how casts are typically used:
1. removing const or volatile (const_cast)
2. performing a standard conversion or its inverse (static_cast)
3. navigation in a class hierarchy (static_cast or dynamic_cast)
4. type punning (reinterpret_cast)
The idea is that the spelling of the cast implies its reason for
being in the code.
The C++ type system is such that conversions that are always safe
can be accomplished without a cast, and any explicit cast implies
something unsafe in your code. When you port code, among the things
you need to check are casts. You can grep for any of these casts --
unlike a C-style cast which cannot be detected by simple scanning.
The C-style cast is retained for compatibility, and is defined
in terms of the other four casts. The casts that are valid in
standard C are valid in standard C++ and have the same meaning.
Programmers do seem to find the four new casts confusing, although
they are conceptually simple. It is true that there are subtleties
regarding their use. But, like so many things in C++, if you
get caught in the subtleties, you are probably writing dangerous
code and should find a better way to accomplish your purpose.
--
Steve Clamage, stephen...@sun.com
---
Zalman Stern
:> foo2 = (struct bar *)malloc(sizeof(struct foo));
Which is a local error easily seen to be wrong within a single line of
code. (Which is not the case with the error I described.) One can also roll
the idiom into a macro so the type is only mentioned once:
#define safe_malloc(type) (((type) *)malloc(sizeof(type)))
(Which probably fails to compile for certain types...)
As I said, we can argue about this all day long and very little is likely
to be decided.
-Z-
David R Tribble
> Doesn't extern "C" just turn off name mangling?
There's a little more too it than that; it also affects the function
calling conventions (parameter passing, etc.). This has a direct
impact on function pointers, in that extern C function pointers are
different critters than extern C++ function pointers.
extern "C"
{
typedef int (*Pcf)(int i); // ptr to C func
extern int cfunc(int a);
}
extern "C++"
{
typedef int (*Pcxxf)(int i); // ptr to C++ func
extern int cxxfunc(int a);
}
void calls(int i)
{
Pcf cf = &cfunc; // okay, ptr to C func
Pcxxf cxxf = &cxxfunc; // okay, ptr to C++ func
(*pcf)(i); // calls C func cfunc()
(*pcxxf)(i); // calls C++ func cxxfunc()
}
void bad(int i)
{
Pcf cf = &cxxfunc; // [A] ERROR
Pcxxf cxxf = &cfunc; // [B] ERROR
...
}
Most C++ compilers allow [A] and [B] without complaint, but they
aren't conforming, and the code is certainly not portable.
Other compilers (e.g., IBM OS/390 USS) will complain, and rightly so,
about incompatible function pointers. Some systems use different
function invocation methods for C and C++ functions. Hence the
need for the extern "C" specifier.
-- David R. Tribble, da...@tribble.com, http://www.david.tribble.com --
David R Tribble
>
> Peter Seebach <se...@plethora.net> writes
>> Certainly! But the graybeards tend to date back to times before
>> (void *). Without (void *), a lot of casts are necessary.
>> (void *) is there to let you omit "trivial" casts; this allows
>> better documentation, as it becomes more clear when you really mean
>> "reinterpret this".
>
> The problem with void * is that it actually has two distinct uses for
> which different rules for implicit conversions should apply.
>
> 1) It is a generic data pointer to which any other data pointer should
> be convertible implicitly.
>
> 2) It is a pointer to generic storage that is suitably aligned for any
> type from which there should be implicit conversions to all types.
>
> Note that either of these alone combined with a need for explicit
> conversion in the reverse direction works fine. It is the combination
> that has a dreadful hole in it. C++ fixed the hole one way but failed
> to note that it now needed a second incomplete type to allow clean
> (cast
> free) programming for case 2)
>
> Perhaps C++ (next version) could consider introducing a type std::any
> to fill that gap, or even C and C++ introduce _any next time round.
I suggested 'class std::object' a few weeks ago which had this same
ability. Rather than passing around aribitrary data as 'void*',
you could use 'std::object*'. Making this standard "any" type a
class has the added advantage of allowing it to have member functions
(unfortunately, we couldn't come up with any that were useful).
Francis Glassborow
<cla...@eng.sun.com> writes
>C linkage ordinarily means turning off name mangling, but that is
>not a requirement. For example, the C++ compiler might not
>mangle names, or the C compiler might do the same mangling
>as the C++ compiler. (Nothing in the C standard prohibits
>mangling names -- it isn't needed, so compilers don't do it.)
Actually TopSpeed C (which was the first MSDOS compiler certified as
conforming by BSI) did mangle names to produce type-safe linkage.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Andrew F. Vesper
Francis Glassborow wrote:
> The problem with void * is that it actually has two distinct uses for
> which different rules for implicit conversions should apply.
>
> 1) It is a generic data pointer to which any other data pointer should
> be convertible implicitly.
>
> 2) It is a pointer to generic storage that is suitably aligned for any
> type from which there should be implicit conversions to all types.
Nope. This is a quality of the pointer that malloc returns, not
anything related to 'void *'.
--
Andy V (OpenGL Alpha Geek)
"In order to make progress, one must leave the door to the unknown ajar."
Richard P. Feynman, quoted by Jagdish Mehra in _The Beat of a Different Drum_.
Francis Glassborow
<ave...@wn.net> writes
>> 2) It is a pointer to generic storage that is suitably aligned for any
>> type from which there should be implicit conversions to all types.
>
>Nope. This is a quality of the pointer that malloc returns, not
>anything related to 'void *'.
True, but that only emphasises why the allowing implicit conversions to
pointers of other types is such a poor idea.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
maurice s. barnum
: Peter Seebach wrote:
: > But you do this by throwing away "unsafe" idioms, such as an uncast malloc,
: > which are part of what makes C such a delightful language.
:
: While I have always explicitly cast malloc's value to the desired type,
: there is a legitimate argument that this obscures a possible error,
: when a prototype for malloc is not in scope.
Since this thread seems to be focused on code that is legal in both C
and C++, it should be noted that it isn't legal in C++ to call malloc
without a prototype in scope. This is fortunately one of the
differences between the languages that can be trivially detected
(unlike sizeof('a') variance, for example).
--xmsb
Hyman Rosen
cla...@eng.sun.com (Steve Clamage) writes:
> The C-style cast is retained for compatibility, and is defined
> in terms of the other four casts. The casts that are valid in
> standard C are valid in standard C++ and have the same meaning.
I think it's more correct to say that the other four casts are
defined in terms of the C-style cast, since the C-style cast
can do everything the other four can, while there are casts
that can be done only by the C-style cast.
David R Tribble
maurice s. barnum wrote:
>
> Douglas A. Gwyn <gw...@arl.mil> writes:
>: Peter Seebach wrote:
>: > But you do this by throwing away "unsafe" idioms, such as an
>: > uncast malloc, which are part of what makes C such a delightful
>: > language.
>:
>: While I have always explicitly cast malloc's value to the desired
>: error, when a prototype for malloc is not in scope.
>
> Since this thread seems to be focused on code that is legal in both C
> and C++, it should be noted that it isn't legal in C++ to call malloc
> without a prototype in scope. This is fortunately one of the
> differences between the languages that can be trivially detected
> (unlike sizeof('a') variance, for example).
Like C++, C9X requires a function to have a prototype in scope prior
to any use (e.g., invocation) of that function. IOW, implicit int
functions are no longer legit.
Thus an explicit cast of the return value of malloc() is needed even
less than it used to be. Combine that with the fact that void
pointers convert to any other pointer type without needing an
explicit cast, and we're left with no real good reason to use casts
on malloc() calls at all.
-- David R. Tribble, da...@tribble.com, http://www.david.tribble.com --
AllanW
In article <eoKK3.24$IV3....@ptah.visi.com>,
se...@plethora.net (Peter Seebach) wrote:
> >Not necessarily; you can use object-oriented programming
> techniques in C, it just requires a little more discipline.
/* Equivalent to Cust::FinishOrder() */
void Cust_FinishOrder(struct Cust c)
{
extern struct Printer p;
extern struct Database d;
Cust_CheckPreferred(&c);
Cust_CalculateTax(&c);
Cust_CalculateShipping(&c);
Cust_CalculateTotal(&c);
Cust_PrintOrder(&c,&p);
if (Console_AskIfOkay() == Object_Yes)
{
Cust_UpdateBalance();
Cust_SaveData(&d);
Cust_ResetCurrentOrder();
}
}
/* Yeech! */
> People call C from Fortran and vice versa, too; anyone who
> wants to implicitly declare all variables starting with 'i'
> through 'k' as plain int, raise your hands. :)
I think you mean 'I' through 'N' (Easy to remember: it's the
first two letters in 'INTEGER'). Of course, some versions of
FORTRAN let you change it to what you said by using this
statement (IIRC):
C Integers start with I through K
IMPLICIT I-K
--
All...@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Before you buy.
Michael Rubenstein
On 11 Oct 1999 21:07:32 GMT, Hyman Rosen <hy...@prolifics.com>
wrote:
>
>cla...@eng.sun.com (Steve Clamage) writes:
>> The C-style cast is retained for compatibility, and is defined
>> in terms of the other four casts. The casts that are valid in
>> standard C are valid in standard C++ and have the same meaning.
>
>I think it's more correct to say that the other four casts are
>defined in terms of the C-style cast, since the C-style cast
>can do everything the other four can, while there are casts
>that can be done only by the C-style cast.
Citation please? What cast can be done with a C-style cast that
cannot be done with one of the other casts? How does one do a
dynamic_cast using a C-style cast?