Chris Hills wrote:
>
> Darin Adler <darin@bentspoon.com> writes
> >
> >Steve Clamage <clamage@eng.sun.com> wrote:
> >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
> Please do so.... first find, or in this case write an 8051 C++ compiler.
> (that is a C++ compiler to target an 8051 the host platform is up to
> you.) AFAIK There are no *industrial*  8051 C++ compilers about.

Is there a conforming C compiler for that platform?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <Ss72IoAXjJO8EA5m@phaedsys.demon.co.uk>,
Chris Hills  <chris@phaedsys.org> wrote:
>Darin Adler <darin@bentspoon.com> writes
>>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
>Please do so.... first find, or in this case write an 8051 C++ compiler.
>(that is a C++ compiler to target an 8051 the host platform is up to
>you.) AFAIK There are no *industrial*  8051 C++ compilers about.

To the best of my knowledge, although there are C compilers available
for the 8051, there is no fully compliant C compiler available,
but instead, C subsets with non-standard extensions.  This is of
course understandable, when the 8051 architectural issues are considered.
Anyway, I think you're right that there is no 8051 C++ compiler.

>>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.
>It can do. Const is different to define. They take memory in a different
>way. This is important when you are using an ICE for debugging.

It depends upon the kind of const.  Note that in C, const tends
to mean readonly whereas in C++ is brings it further to a constant
in some cases.

>>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.
>OK. FIRST write the compiler to compiler C++ for an 8051 target. (any
>host) When you have done that I will tell you which features I will and
>will not be using.....

Comeau would be glad to consider such a port for a customer.
As to the features not being used, see above (even C programmers
have constraints and issues to deal with).

>When you have this C++ compiler I will need it to produce working
>programs.... so it has to be fast efficient and be able to compiler more
>than Hello world into the chip.

You can win the argument on something like exception handling,
but to imply there is nothing in C++ over C, or that there are
inherent inefficienies in C++ for everything over C, is misleading.
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> Date: Mon,  7 Jan 2002 21:40:04 GMT
> From: Chris Hills <chris@phaedsys.org>
> Newsgroups: comp.std.c, comp.std.c++
> Subject: Re: C9X vs C++
>
> Darin Adler <darin@bentspoon.com> writes
> >
> >Steve Clamage <clamage@eng.sun.com> wrote:
> >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,

For the record, I didn't write the article attributed to me.

--
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Greg Comeau <comeau@panix.com> writes
>In article <Ss72IoAXjJO8EA5m@phaedsys.demon.co.uk>,
>Chris Hills  <chris@phaedsys.org> wrote:
>>When you have this C++ compiler I will need it to produce working
>>programs.... so it has to be fast efficient and be able to compiler more
>>than Hello world into the chip.
>
>You can win the argument on something like exception handling,
>but to imply there is nothing in C++ over C, or that there are
>inherent inefficienies in C++ for everything over C, is misleading.

My argument was that you can not get C++ to run sensibly on an 8051.

However on other embedded targets I would not (and have not) hesitate to
use C++.  I have used C++ on SPARC and PPC though in the case of the PPC
we used C (in a C NOT C++ compiler)  for the device drivers.

Each has it's own set of advantages and disadvantages.   In some cases,
such as small micros C is much better suited than C++.  There are some
people who seem to want to turn C into C++. They can't see that the two
languages are different. and have different uses.

I just get very fed up with people telling me that it does not mater
what size the8051 is because the compiler runs on (usually) a PC....

Leave C alone. If you want the additional features in C++ then use C++.
If there is not a C++ compiler for your target there is probably a good
reason for this.

It is also the reason why there are many C compilers that are not c/C++
compilers.

Regards
         Chris
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <FmCTaKAw8zO8EA6o@phaedsys.demon.co.uk>,
Chris Hills  <chris@phaedsys.org> wrote:
>Greg Comeau <comeau@panix.com> writes
>>In article <Ss72IoAXjJO8EA5m@phaedsys.demon.co.uk>,
>>Chris Hills  <chris@phaedsys.org> wrote:
>>>When you have this C++ compiler I will need it to produce working
>>>programs.... so it has to be fast efficient and be able to compiler more
>>>than Hello world into the chip.
>>
>>You can win the argument on something like exception handling,
>>but to imply there is nothing in C++ over C, or that there are
>>inherent inefficienies in C++ for everything over C, is misleading.
>
>My argument was that you can not get C++ to run sensibly on an 8051.

And all I'm saying is that it's no picnic for C either.

>...
>I just get very fed up with people telling me that it does not mater
>what size the8051 is because the compiler runs on (usually) a PC....

For the record, and for clarification, I haven't said that.

>Leave C alone. If you want the additional features in C++ then use C++.

This is partly what everybody is saying.

>If there is not a C++ compiler for your target there is probably a good
>reason for this.

Sometimes, sometimes not.

>It is also the reason why there are many C compilers that are not c/C++
>compilers.

Sometimes.
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Chris Hills" <chris@phaedsys.org> wrote in message
news:FmCTaKAw8zO8EA6o@phaedsys.demon.co.uk...
>
> Leave C alone. If you want the additional features in C++ then use C++.
> If there is not a C++ compiler for your target there is probably a good
> reason for this.
>
> It is also the reason why there are many C compilers that are not c/C++
> compilers.

I'd put my money much more readily on "it's more difficult" than "it's less
effective/appropriate".

Ken


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Darin Adler <darin@bentspoon.com> writes
>
>Steve Clamage <clamage@eng.sun.com> wrote:
>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
Please do so.... first find, or in this case write an 8051 C++ compiler.
(that is a C++ compiler to target an 8051 the host platform is up to
you.) AFAIK There are no *industrial*  8051 C++ compilers about.

>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.
It can do. Const is different to define. They take memory in a different
way. This is important when you are using an ICE for debugging.

>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.
OK. FIRST write the compiler to compiler C++ for an 8051 target. (any
host) When you have done that I will tell you which features I will and
will not be using.....

As you realise the 128 bytes of DATA ram is not one block. Some can ONLY
be indirectly addressed some can only be directly addressed (because
they overlay the same space)  The IO is in predefined memory some of
which is bit addressable hardware.  I will need the bit addressing
capability.

The bottom 32  is the 4 register banks. (you can use them for data *if*
I am not using them for registers,. You will know at compile time.)

I may need to place some variables at fixed locations in external ram.
Some fixed data may need to be explicitly stored in CODE space.

The stack.... where will you put it? My compiler does the stack a little
differently (ie it is not used for parameter passing).  The usual size
for the user stack is about 20 bytes.

Note the DATA memory may or may not be internal... I will define that
later. Also the code space may or may not be internal. Also I may have
banked switching.....

>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.
You misunderstand. See above. I know what an 8051 compiler is. I use one
daily and have done so for many years. I have also used cross compilers
running  on MS-DOS, Windows, Lynx, Unix, CPM, GEM and others for a wide
variety of targets.

The embedded world understands that  for an  xyw compiler  the xyz
refers to the TARGET.  The host can be anything. Usually these days it
is x86 based though I have have 68K, SPARC, PPC and Z80 based hosts.

Desk top people seem to have a problem with this concept. an 8051
compiler *TARGETS* 8051.  Though I do know of one academic who wanted a
C interpreter hosted on an 8051....

When you have this C++ compiler I will need it to produce working
programs.... so it has to be fast efficient and be able to compiler more
than Hello world into the chip.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On 11 Oct 1999 21:07:32 GMT, Hyman Rosen <hymie@prolifics.com>
wrote:

>
>clamage@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?


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <t7670dbs8x.fsf@calumny.jyacc.com>, Hyman Rosen
<hymie@prolifics.com> writes
>
>clamage@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.

1)  dynamic_cast cannot be implemented as a C-style cast
2)  I think that where MI is involved static_cast does something that C-
style casts cannot.
3)  C-style casts concern rvalues, const_cast can deal with an lvalue
(it makes no sense to strip a const from an rvalue) though this better
be a reference (or pointer).

There is a common core of functionality, but each provides something the
other does not.




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


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <380245D7.814606D5@tribble.com>, David R Tribble
<david@tribble.com> writes
>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.

Nitpick: it has to have a declaration in scope, but that need not be a
prototype - it can be the definition.

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hyman Rosen wrote in message ...

>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.

This is only accurate in a historical sense.  The C++ committee looked at
things a C cast could do and gave those things names (and restricted
behaviors).

There are things the new-style casts can do (particulary dynamic_cast) that
the C-style cast can't.  In addition if a C-style cast is used in a
situation where both a static_cast and a reinterpret_cast would be
meaningful, the C-style cast is defined as behaving according to the
definition of the static_cast.  I don't believe the definition of
static_cast makes any reference to the C-style cast.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Michael Rubenstein wrote:
>
> On 11 Oct 1999 21:07:32 GMT, Hyman Rosen <hymie@prolifics.com>
> wrote:
>
> >
> >clamage@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.

That's not correct: While {static,const,reinterpret}_cast are
replacements for C-style casts, dynamic_cast is something
completely new.

>
> Citation please?  What cast can be done with a C-style cast that
> cannot be done with one of the other casts?

class Base {};
class Derived: private Base {};

Derived foo;
Base* bar = (Base*)&foo;

> How does one do a
> dynamic_cast using a C-style cast?

One doesn't. dynamic_cast is the only interface to the part
of RTTI required for dynamic_cast.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

alan_griffiths@my-deja.com wrote:
[Arguing that C++ takes more space than 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.)

Here's an idea: Don't use any virtual functions unless they
prevent you from having to write something equivalent in C.
Then there won't be any extra vtables, and the overhead will
be zero.

In C++ a major design goal was "don't pay for things you
don't use." For the most part, this goal was met. One
obvious exception is -- well, is exceptions. But C++
vendors know that some applications don't need this, so
they give us a way to turn the whole thing OFF. (When I
do this in Microsoft, I get jillions of warning messages
from library headers -- but everything works.)

--
Allan_W@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.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hyman Rosen <hymie@prolifics.com> writes:

>clamage@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.

I was speaking of the standard. It defines the four new-style
casts, and defines the C-style cast in terms of 3 of those 4 casts
(const_cast, static_cast, reinterpret_cast), plus three conversions
ignoring protection that are avalable only with the C-style cast.

The C-style cast cannot do everything.  A C-style cast does not
have the effect of a dynamic_cast when casting down or across a
hierarchy.

(Hmmm. Maybe this stuff is confusing after all.)

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
> 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.

Not a prototype, but a declaration.  Old-style () declarations are
still supported.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Michael Rubenstein <miker3@ix.netcom.com> writes:
> Citation please?  What cast can be done with a C-style cast that
> cannot be done with one of the other casts?

Casting to a private base class. The standard says so, in 5.4/7.

> How does one do a dynamic_cast using a C-style cast?

You don't, of course. I'm wrong about defining the new casts in terms
of the old casts.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Douglas A. Gwyn" <gwyn@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 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
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

clamage@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.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

maurice s. barnum wrote:
>
> Douglas A. Gwyn <gwyn@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
>: type, here 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).

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, david@tribble.com, http://www.david.tribble.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <eoKK3.24$IV3.2104@ptah.visi.com>,
  seebs@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

--
Allan_W@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.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

>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.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In comp.std.c Peter Seebach <seebs@plethora.net> wrote:
: True.  And the following patch will "fix" it:
:>    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-
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

efried@mindspring.com (Eric Friedman) writes:
> 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, david@tribble.com, http://www.david.tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> Peter Seebach <seebs@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).

-- David R. Tribble, david@tribble.com, http://www.david.tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7tipjo$47q$1@engnews1.eng.sun.com>, Steve Clamage
<clamage@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
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

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_.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37FE97E5.251F2A52@wn.net>, Andrew F. Vesper
<avesper@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
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Eric Friedman wrote:
>
> In article <37FC3350.C7B5F665@acm.org>, Pete Becker <petebecker@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?
>

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
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

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, david@tribble.com, http://www.david.tribble.com --




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In comp.std.c Peter Seebach <seebs@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...

[...]

: 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-
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <O99K3.3899$L85.284814@ptah.visi.com>, Peter Seebach
<seebs@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
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37F92C16.E6618705@tribble.com>, David R Tribble
<david@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: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <xJNJ3.3601$L85.252892@ptah.visi.com>,
  seebs@plethora.net (Peter Seebach) wrote:
> In article <7t813q$j0c$1@engnews1.eng.sun.com>,
> Steve Clamage <clamage@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.  :)

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.Kanze@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.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37F92C16.E6618705@tribble.com>,
  David R Tribble <david@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.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient=E9e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

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.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7tb2es$a7c$1@oravannahka.helsinki.fi>,
  Vesa A J Karvonen <vkarvone@cc.helsinki.fi> wrote:
> In comp.std.c++ alan_griffiths@my-deja.com wrote:
>
> > In article <HHnDCnAq1y93EA9k@phaedsys.demon.co.uk>,
> > 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.

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.griffiths@experian.com, +44 115 934 4517)
Senior Systems Consultant, Experian


Sent via Deja.com http://www.deja.com/
Before you buy.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7tasn0$ce7$1@engnews1.eng.sun.com>,
  clamage@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.Kanze@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.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Clive D.W. Feather" <clive@on-the-train.demon.co.uk> writes:

>In article <37F92C16.E6618705@tribble.com>, David R Tribble
><david@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.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7tc1tl$img@dfw-ixnews6.ix.netcom.com>,
Zalman Stern  <zalman@netcom16.netcom.com> wrote:
>In comp.std.c Peter Seebach <seebs@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 / seebs@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!
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

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.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In comp.std.c Konrad Schwarz <konrad_schwarz@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-


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37FB6AE4.154C0223@mcd.motDOTcom>, Konrad Schwarz
<konrad_schwarz@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


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37FC3350.C7B5F665@acm.org>, Pete Becker <petebecker@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?

Eric


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

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_schwarz@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


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Eric Friedman wrote:
>
> In article <37FC3350.C7B5F665@acm.org>, Pete Becker <petebecker@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.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

efried@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.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <ZBLK3.43$IV3.4726@ptah.visi.com>, seebs@plethora.net (Peter Seebach) writes:
|> In article <7tc1tl$img@dfw-ixnews6.ix.netcom.com>,
|> Zalman Stern  <zalman@netcom16.netcom.com> wrote:
|> >In comp.std.c Peter Seebach <seebs@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:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <ZBLK3.43$IV3.4726@ptah.visi.com>, Peter Seebach
<seebs@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
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7th3tf$fsr@dfw-ixnews4.ix.netcom.com>,
Zalman Stern  <zalman@netcom15.netcom.com> wrote:
>    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.

True.  And the following patch will "fix" it:
>    foo2 = (struct bar *)malloc(sizeof(struct foo));

:)

-s
--
Copyright 1999, All rights reserved.  Peter Seebach / seebs@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!
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

efried@mindspring.com (Eric Friedman) writes:

>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.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

efried@mindspring.com (Eric Friedman) writes:
> In article <37FC3350.C7B5F665@acm.org>, Pete Becker <petebecker@acm.org> wrote:
> >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?

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
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

The latest draft of my work-in-progress, "Incompatibilities Between
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, david@tribble.com, http://www.david.tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James.Kanze@dresdner-bank.com wrote:
> At least a conforming implementation in C++ can signal the errors.

So can a conforming C9x implementation.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"T.E.Dickey" <dickey@shell.clark.net> writes:

>In comp.std.c Steve Clamage <clamage@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 <fjh@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 fjh@128.250.37.3        |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

seebs@plethora.net (Peter Seebach) writes:

>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.

--
Fergus Henderson <fjh@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 fjh@128.250.37.3        |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37F930C0.4C51124E@tribble.com>,
David R Tribble  <david@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 / seebs@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!


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"T.E.Dickey" wrote:
>
> In comp.std.c Fergus Henderson <fjh@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?


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Zalman Stern wrote:
>
> In comp.std.c Peter Seebach <seebs@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...
>
What argument can be made for adding the cast?  AFAIU, void * was
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_schwarz@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
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <HHnDCnAq1y93EA9k@phaedsys.demon.co.uk>,
  Chris Hills <chris@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?

> 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.griffiths@experian.com, +44 115 934 4517)
Senior Systems Consultant, Experian


Sent via Deja.com http://www.deja.com/
Before you buy.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <b5pktAARg893EA9C@phaedsys.demon.co.uk>, Chris Hills
<chris@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


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <b5pktAARg893EA9C@phaedsys.demon.co.uk>, Chris Hills
<chris@phaedsys.demon.co.uk> writes
>It does not exist because it is not possible to write a C++ compiler for
>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
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Bjarne Stroustrup wrote:
> 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.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

seebs@plethora.net (Peter Seebach) writes:

>In article <7t813q$j0c$1@engnews1.eng.sun.com>,
>Steve Clamage <clamage@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.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Chris Hills <chris@phaedsys.demon.co.uk> writes:

>Steve Clamage <clamage@eng.sun.com> writes
>>
>>Chris Hills <chris@phaedsys.demon.co.uk> writes:
>>
>>>Peter Seebach <seebs@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.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

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, david@tribble.com, http://www.david.tribble.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Bjarne Stroustrup wrote:
>
> "Douglas A. Gwyn" <DAGwyn@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.
>
> Ah. Hmm. You couldn't be saying that
>
>         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.

-- David R. Tribble, david@tribble.com, http://www.david.tribble.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In comp.std.c++ alan_griffiths@my-deja.com wrote:

> In article <HHnDCnAq1y93EA9k@phaedsys.demon.co.uk>,
>   Chris Hills <chris@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
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7tarkt$bk8$1@engnews1.eng.sun.com>,
Steve Clamage <clamage@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 / seebs@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!
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Clive D.W. Feather" wrote:
>
> Bjarne Stroustrup <bs@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, david@tribble.com, http://www.david.tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Chris Hills <chris@phaedsys.demon.co.uk> writes:

>Peter Seebach <seebs@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.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7t813q$j0c$1@engnews1.eng.sun.com>,
Steve Clamage <clamage@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 / seebs@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!
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage <clamage@eng.sun.com> writes
>
>Chris Hills <chris@phaedsys.demon.co.uk> writes:
>
>>Peter Seebach <seebs@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 possibl=
e
>>to use C++.=20
>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.

>Since with minor syntactic exceptions, valid C is also valid C++
>and should generate identical object code,=20
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 th=
e
C compiler I use. Which is  why (despite it being =A31500) 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 onl=
y
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      /\/\/\/\/\/\/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage <clamage@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 <chris@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


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

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).


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37F4C728.2C3D0AD5@home.com>,
Douglas A. Gwyn <dagwyn@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


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7t34n5$p8r$1@engnews1.eng.sun.com>,
Robert Corbett <corbett@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 / seebs@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!


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Clive D.W. Feather" <clive@on-the-train.demon.co.uk> writes:

> In article <7singi$9id$1@oravannahka.helsinki.fi>, Vesa A J Karvonen
> <vkarvone@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




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6H9J3.3104$L85.211252@ptah.visi.com>, Peter Seebach
<seebs@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


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

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.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

seebs@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/


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Robert Corbett wrote:
>
> In article <37F4C728.2C3D0AD5@home.com>,
> Douglas A. Gwyn <dagwyn@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
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Douglas A. Gwyn" <dagwyn@home.com> writes:

>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.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6H9J3.3104$L85.211252@ptah.visi.com>,
Peter Seebach <seebs@plethora.net> wrote:
>
>In article <7t34n5$p8r$1@engnews1.eng.sun.com>,
>Robert Corbett <corbett@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?

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
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <FIwGro.JG0@research.att.com>, Bjarne Stroustrup
<bs@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: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Peter Seebach <seebs@plethora.net> writes
>
>In article <7t34n5$p8r$1@engnews1.eng.sun.com>,
>Robert Corbett <corbett@lupa.eng.sun.com> wrote:
>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.

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      /\/\/\/\/\/\/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7singi$9id$1@oravannahka.helsinki.fi>, Vesa A J Karvonen
<vkarvone@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.

"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: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Vesa A J Karvonen 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.

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.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7singi$9id$1@oravannahka.helsinki.fi>, Vesa A J Karvonen
<vkarvone@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.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christian Bau wrote:
>
> In article <7singi$9id$1@oravannahka.helsinki.fi>, Vesa A J Karvonen
> <vkarvone@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.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In comp.std.c++ Clive D.W. Feather <clive@on-the-train.demon.co.uk> wrote:
> In article <7s5fef$u3@library1.airnews.net>, Bill Wade
> <bill.wade@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; }

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
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37DEE109.CA9821D1@tribble.com>,
  David R Tribble <david@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.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7s5fef$u3@library1.airnews.net>, Bill Wade
<bill.wade@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: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37DEE109.CA9821D1@tribble.com>, David R Tribble
<david@tribble.com> writes
>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.

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Clive D.W. Feather" <clive@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


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Clive D.W. Feather wrote in message <4QGYM9K$Ur43EwS7@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.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7rr9sn$93k@library1.airnews.net>, Bill Wade
<bill.wade@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: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote in message <37DEE109.CA9821D1@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).





[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

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, david@tribble.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37DEE109.CA9821D1@tribble.com>, David R Tribble <david@tribble.com> writes:
>
>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
--
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

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





[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]