In article <37CFF015.E90E6E53@tribble.com>, David R Tribble
<david@tribble.com> writes
>> Then our C++ liaison came up with the \u notation that, he told us,
>> was already in C++, and a proposal that would make us compatible.
>>
>> Then things got hacked around at various times as we discovered
>> problems with integrating \u into C9X. So C UCNs aren't quite the
>> same as C++ UCNs.
>
>How do they differ?  Would a program be able to tell the difference,
>or rather, would a C9X program compiled as C++98 produce different
>results or fail to compile?

I'm afraid I don't know, just that the assertion was made. Does anyone
else here have more information ?

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

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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)  wrote on 25.08.99 in <7q14pk$9ao$1@engnews1.eng.sun.com>:

> kaih=7NRQYDQ1w-B@khms.westfalen.de (Kai Henningsen) writes:
>
> >gdosreis@korrigan.inria.fr (Gabriel Dos_Reis)  wrote on 21.08.99 in
> ><xajiu6a57n2.fsf@korrigan.inria.fr>:
>
> >> And that *is* the problem.
> >>
> >>  #include <inttypes.h>
> >>  void f(long) {}
> >>  void f(int32_t) {}
>
> >Allowing stuff like that is a significant part of what I don't like about
> >C++. (*Does* C++ allow this case? Why on earth?)
>
> What are you objecting to?  Typedefs?  Overloading in general?
> Details of overloading rules?

Overloading that differentiates by differently-sized integers. Which is
what would break with these typedefs. It's just not a significant-enough
difference.

> >> Introducing new typenames by typedef is evil WRT overloading and
> >> templates.  We already have such a problem  with std::size_t; I'm
> >> not convinced it would be much funnier to add more.
>
> >Then this is a clear case of severely broken language design. (On the part
> >of C++, that is.) IMarrogantO, typedef is a *far* more important feature
> >than overloading or templates.
>
> In what way is the language design broken? What should the design be?
>
> For example, if a typedef creates a new type, it would severely break
> C compatibility. It would also eliminate a useful feature of typedefs:
> the ability to abbreviate a complicated type name:
>  typedef basic_string<char> string;
>
> But if typedefs do not create a new type, then given
>  typedef int III;
>  III foo(III);
>  int foo(int);
> the two declarations of foo must refer to the same function, not an
> overloaded pair. (As in Gabriel's example.)
>
> Removing overloading from the language definition doesn't solve
> the problem, because you are not required to use function overloading.

So what else would break?

In any case, there is a good solution to the new types/old types question.
Modula-3 is an example of a language getting it right. (In fact, the M3
type system seems to be one of the best-thought-out I've seen. Language
designers could do worse than study M3.)

In this particular case, you get a new type if and only if you tell the
compiler that you want to get a new type, by means of "branding" the new
type (with a character string brand).

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)


[ 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 <K4tv3.2$kg.644@ptah.visi.com>, Peter Seebach
<seebs@plethora.net> writes
>> . \uXXXX characters (UCNs)
>> . Extended identifiers (a\uXXXX)
>
>ACK!  I was told those were specifically compatible with C++ stuff.  Ick.

This is a rather sad story. Once upon a time Frank Farance and I came up
(first independently, then we merged them) with a proposal for extended
character sets that I called "extended trigraphs". A UCN was entered as
??uXXXX or ??UXXXXXXXX. The translation was done at TP1, just like all
other trigraphs. The other changes to the Standard were orthogonal.

Then our C++ liaison came up with the \u notation that, he told us, was
already in C++, and a proposal that would make us compatible.

Then things got hacked around at various times as we discovered problems
with integrating \u into C9X. So C UCNs aren't quite the same as C++
UCNs.

If my memory doesn't fail me, we are now told that C++ has discovered
some of the same problems and there will be a TC to make their UCNs work
the same way as ours.

>> . Inline functions (not?)
>
>I think all valid C++ inline functions (modulo member functions) are valid
>C inline functions, but not vice versa.

That was the intention.

--
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" wrote:
[...]
> Then our C++ liaison came up with the \u notation that, he told us,
> was already in C++, and a proposal that would make us compatible.
>
> Then things got hacked around at various times as we discovered
> problems with integrating \u into C9X. So C UCNs aren't quite the
> same as C++ UCNs.

How do they differ?  Would a program be able to tell the difference,
or rather, would a C9X program compiled as C++98 produce different
results or fail to compile?

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

"Clive D.W. Feather" wrote:
> This is a rather sad story. Once upon a time Frank Farance and I came up
> (first independently, then we merged them) with a proposal for extended
> character sets that I called "extended trigraphs". A UCN was entered as
> ??uXXXX or ??UXXXXXXXX. The translation was done at TP1, just like all
> other trigraphs. The other changes to the Standard were orthogonal.

I still think that was technically a better approach.  If people wanted
to change the syntax to \u but keep the early-TP1 nature of the mapping,
that would be fine (except in some places where they would have to code
??/u).

> Then our C++ liaison came up with the \u notation that, he told us,
> was already in C++, and a proposal that would make us compatible.

More or less...

> Then things got hacked around at various times as we discovered
> problems with integrating \u into C9X. So C UCNs aren't quite the
> same as C++ UCNs.

What basically happened is that over about one year, the \u proposal
underwent much discussion and refinement, with a major goal being to
allow any of three different reasonable implementation methods (which
I hope were captured in the C9x Rationale).  But the C++ standard was
being rapidly completed while we were still figuring this out.

> If my memory doesn't fail me, we are now told that C++ has
> discovered some of the same problems and there will be a TC to make
> their UCNs work the same way as ours.

As I recall, people working both C and C++ agreed that this facility
should be functionally and syntactically identical in both standards,
and the C9x version had benefitted from additional iteration, so the
C++ standard should be adjusted accordingly.  There seems to be
general agreement on what UCN-using programs should look like, with
the discrepancies being in whether all the implementation models are
accommodated by the specifications.
---
[ 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              ]

Malcolm Purvis wrote:
>
> >>>>> "James" == James Kuyper <kuyper@wizard.net> writes:
>
> James> Valentin Bonnard wrote:
> >> I conclude that you volunteer to give the definition of __func__ in C++.
>
> James> Is there any problem with just using the C9X definition [...]:
>
> Is the namespace included?
>
> For nested classes, is the name of surrounding class included?

Good point. I'd favor including the namespace and the surrounding class.
Ouch: overloading! Should the name reflect the function signature?

> What is the relationship with type_info::name()?

I'm not sure there is any; a function name is an identifier, not a type.
Unlike a type, a function can't be a typedef for a different function,
so there's less incentive for making the string be
implementation-defined.
---
[ 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 <37C558B6.7923@wanadoo.fr>,
  Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
>
> James.Kanze@dresdner-bank.com wrote:
>
> > >  . 'complex' keyword (type vs. template)

> > They hardly had a choice, did they?  Without templates, they
> > couldn't define complex as in C++.

> Huh ?

> They couldn't define complex (at all) either.

?? They apparently did.

I find it rather hypocritical for people in the C++ community to
complain that the C committee defined complex in a way incompatible with
C++.  In this case, if anyone has grounds for complaint, it is the C
committee, because the C++ committee defined complex in a way they knew
C couldn't follow.  From a pratical point of view, there are, and were,
only two alternatives:

  - C++ defined a built-in type complex, which C adopted, or
  - C++ defined complex as a template, and the two languages go their
    own way.

Given the advantages of complex being a template, I quite concure with
the decision of the C++ committee, but we have to accept all the
consequences of that decision; we cannot blame the C committee for
ignoring us because we decided to go a way they cannot.  Quite the
contrary, I think they should be commended for having made as much
effort as they did to make their complex built-in type compatible, at
the code level, with our template type.

> > >  . Inline functions (not?)

> > The definition in the two languages is different.  But the
> > restrictions on their use in C is such that for the cases where they
> > are legal in C, no conforming program can tell the difference (I
> > think).

> I read unspecified as different from undefined. I see no requirements
> the public draft that the function shall be defined the same way in
> two TR. Perhaps it has changed.

If the code doesn't violate the C++ one definition rule, and it has
defined (not unspecified) behavior in C, then the two languages handle
it identical (or rather, close enough to identical that no conforming
program can tell).  If the code violates the C++ one definition rule, it
has undefined behavior in C++, and (probably) unspecified behavior in
C.  The only tricky point is the case where the code has unspecified
behavior in C (typically, for example, because it contains a local
static variable): in cases where the one definition rule is not
violated, I would expect it to have defined behavior in C++,
corresponding to one of the legal unspecified behaviors.  In practice, I
don't expect this to be a real problem; because such unspecified
behavior causes real program bugs in almost every case, I would expect
most C compilers to issue a warning in such cases, and all C programmers
to avoid the situation.

Obviously, if you are writing code which must compile with both
languages, you have to avoid the error conditions and unspecified
behavior in both languages.  In practice, this means adhering to the one
definition rule, and avoiding the unspecified behavior in C.  If there
is only one copy of the inline function, in a header file, the first is
almost free.  And the second is normal procedure anyway for compatible
code.  IMHO, this is really no different than something like not being
able to declare a variable named class or a function member if the code
is to be portable between the two languages.

> > >  . Variable-length arrays (VLAs)

> > A pure extension, but with possible problems when added to C++.

> Allowing it only on POD or C struct would cause no more
> problems than in C IMO.

With perhaps the added restriction that you cannot inherit from a class
which contains a VLA.  Which is a bothersome restriction: one frequent
technique for adhering to C API's is to derive from the C structure in
the C++ part.

> > >  . Type-generic std math functions (<tgmath.h>)

> > Again, without function overloading, what else could they do.  (As
> > close to C, but no closer, works in both directions.)

> As close to C++ but no closer ?

Globally, that seems to be the attitude they've taken.  And I personally
feel they've done a good job of it.  This doesn't mean I agree with
everything they've done.  Like Gabriel dos Reis, I very definitly don't
like the plethora of typedefs they've added.  But typedef is very
definitly a part of C++ -- you can't argue on the grounds of
compatibility.  And complaining that the C committee made an error
because they don't support some specific idiom of C++ seems to be taking
things a bit too far.

> > >  . '__func__' predefined identifier
> > >  . 'enum X { A, };' trailing comma

> > Two more pure extensions, trivially added to C++.

> I conclude that you volunteer to give the definition of
> __func__ in C++.

Why not simply implementation defined, as is typeid.name.  (I can see a
definite utility in standardizing typeid.name.  I can't particularly see
one in standardizing __func__.)

--
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/
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              ]

James Kuyper wrote:
> Is there any problem with just using the C9X definition:
>
> "The identifier _ _func_ _ shall be implicitly declared by the
> translator as if, immediately following the opening brace of each
> function definition, the declaration
>
>         static const char _ _func_ _[]="function-name";
>
> appeared, where function-name is the name of the lexically-enclosing
> function.

Yes.

What is the function name for a constructor or destructor?
How about an operator function?  A type conversion?

Then you get questions about what's desirable for, say, member
functions, or overloaded functions.

The C definition needs some elaboration to be meaningful, and it
may need more elaboration yet to be useful.

Of course, the usefulness of the construct isn't obvious to me
in the first place, so perhaps we could simply adopt simple rules
without loss of functionality :-)

-Mike Ball-
Sun MicroSystems.
---
[ 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 Ball wrote:
>
> James Kuyper wrote:
> > Is there any problem with just using the C9X definition:
> >
> > "The identifier _ _func_ _ shall be implicitly declared by the
> > translator as if, immediately following the opening brace of each
> > function definition, the declaration
> >
> >         static const char _ _func_ _[]="function-name";
> >
> > appeared, where function-name is the name of the lexically-enclosing
> > function.
>
> Yes.
>
> What is the function name for a constructor or destructor?
> How about an operator function?  A type conversion?
>
> Then you get questions about what's desirable for, say, member
> functions, or overloaded functions.
>
> The C definition needs some elaboration to be meaningful, and it
> may need more elaboration yet to be useful.
>
> Of course, the usefulness of the construct isn't obvious to me
> in the first place, so perhaps we could simply adopt simple rules
> without loss of functionality :-)

Mainly in debugging messages. In C9X, __func__ is required to be part of
the message printed by assert(). Most other uses of it would be similar.
---
[ 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:

> In article <37C558B6.7923@wanadoo.fr>,
>   Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
> >
> > James.Kanze@dresdner-bank.com wrote:
> >
> > > >  . 'complex' keyword (type vs. template)
>
> > > They hardly had a choice, did they?  Without templates, they
> > > couldn't define complex as in C++.
>
> > Huh ?
>
> > They couldn't define complex (at all) either.
>
> ?? They apparently did.

Absolutely. (That's my point.)

> In this case, if anyone has grounds for complaint, it is the C
> committee, because the C++ committee defined complex in a way they knew
> C couldn't follow.

How is

   float complex

easier to follow than

   complex<float>

?

> From a pratical point of view, there are, and were,
> only two alternatives:
>
>   - C++ defined a built-in type complex, which C adopted, or
>   - C++ defined complex as a template, and the two languages go their
>     own way.

Valentin Bonnard wrote:
>
> James.Kanze@dresdner-bank.com wrote:
...
> > In this case, if anyone has grounds for complaint, it is the C
> > committee, because the C++ committee defined complex in a way they knew
> > C couldn't follow.
>
> How is
>
>    float complex
>
> easier to follow than
>
>    complex<float>

Because adding a new type specifier was a fairly minor change to C. Much
of the complicated baggage of templates would have to be added to C,
before code using complex<float> could be supported with the same
meaning in both languages.

...
> From a pratical point of view, there are, and were, the following
> alternative:
>
> - define three typedef float_complex, etc has in EC++, in C and C++

That's not enough for compatibility between the languages. C9X's 'float
_Complex' works differently in subtle ways than C++'s 'complex<float>',
so that code using such a typedef would be difficult to write in such a
way that it would work exactly the same in both languages. The first is
a built-in scalar type, the second is a struct (and a templated one, at
that).


[ 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              ]

Valentin Bonnard wrote:
> > >  . '__func__' predefined identifier
> > >  . 'enum X { A, };' trailing comma
> >
> > Two more pure extensions, trivially added to C++.
>
> I conclude that you volunteer to give the definition of
> __func__ in C++.

Is there any problem with just using the C9X definition:

"The identifier _ _func_ _ shall be implicitly declared by the
translator as if, immediately following the opening brace of each
function definition, the declaration

 static const char _ _func_ _[]="function-name";

appeared, where function-name is the name of the lexically-enclosing
function.

This name is encoded as if the implicit declaration had been written in
the source character set and then translated into the execution
character set as indicated in translation
phase 5."
---
[ 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 <37C59832.F1063897@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> Valentin Bonnard wrote:
> > > >  . '__func__' predefined identifier
> > > >  . 'enum X { A, };' trailing comma
> > >
> > > Two more pure extensions, trivially added to C++.
> >
> > I conclude that you volunteer to give the definition of
> > __func__ in C++.
>
> Is there any problem with just using the C9X definition:
>
> "The identifier _ _func_ _ shall be implicitly declared by the
> translator as if, immediately following the opening brace of each
> function definition, the declaration
>
>  static const char _ _func_ _[]="function-name";
>
> appeared, where function-name is the name of the lexically-enclosing
> function.
>
> This name is encoded as if the implicit declaration had been written
> in the source character set and then translated into the execution
> character set as indicated in translation phase 5."

Yes.  The name if useless without some indication of which overloaded
function is meant.  (I rather think that this was Valentin's point.)  An
obvious start, supposing you wanted to standardize it, is that it should
contain the function signature in ASCII format; i.e. it must include the
parameter types.  And you'd also want the class name.  And any enclosing
namespace names.  Now think of what happens with functions with the same
signature, in two local classes of the same name in different scopes of
the same function.

IMHO: just say implementation defined, and leave it to the market.

--
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/
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 <K4tv3.2$kg.644@ptah.visi.com>,
  seebs@plethora.net (Peter Seebach) wrote:
>
> In article <37BC92E8.23F4B424@tribble.com>,
> David R Tribble  <david@tribble.com> wrote:
> > . \uXXXX characters (UCNs)
> > . Extended identifiers (a\uXXXX)
>
> ACK!  I was told those were specifically compatible with C++ stuff.
Ick.

It's compatible with the standard.  What most current compilers do is
also compatible:-).

> > . Inline functions (not?)

> I think all valid C++ inline functions (modulo member functions) are
valid
> C inline functions, but not vice versa.

I think vice versa.  There are different definitions of what happens in
the case of conflicting definitions; none are anything you would want in
a robust program, however.  (Undefined behavior in C++, unspecified in
C.)

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


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 <37BC92E8.23F4B424@tribble.com>,
  David R Tribble <david@tribble.com> wrote:

> Bjarne Stroustrup wrote:
> > It would be nice if someone would document the C0x/C++
> > incompatibilities.  It would be especially nice if that happened
> > before C0x was frozen, but I think that is already too late so that
> > some divergence is inevitable.

> Yes, there already are some incompatibilities:
>  . enum types
>  . 'foo()' vs. 'foo(void)'
>  . K&R-style (non-prototype) function declarations
>  . Dynamic const initializers

> C9X (C0X) adds a few more:
>  . \uXXXX characters (UCNs)
>  . Extended identifiers (a\uXXXX)

The exact wording may be different, but I can find no difference in
syntax or semantics between C++ and C9x for these two.

>  . Binary float literals

Looks like a pure extension, easily added to C++.

>  . 'bool' type (<stdbool.h>)

The definition is significantly different, but I suspect that for most,
if not all programs, a conditional include of stdbool.h is all that is
required.

>  . 'complex' keyword (type vs. template)

They hardly had a choice, did they?  Without templates, they couldn't
define complex as in C++.

>  . 'long long' type
>  . 'restrict' keyword

More pure extensions, which could be added to C++ without (too many)
problems.

>  . Inline functions (not?)

The definition in the two languages is different.  But the restrictions
on their use in C is such that for the cases where they are legal in C,
no conforming program can tell the difference (I think).

>  . Preprocessor '__VA_ARGS__'
>  . Empty preprocessor function macro args
>  . '_Pragma' preprocessing operator

More pure extensions.

>  . Variable-length arrays (VLAs)

A pure extension, but with possible problems when added to C++.

>  . Flexible array members (the struct hack)

A pure extension, which simply legalizes what all compilers (C or C++)
allow in other forms now.

>  . <inttypes.h> types

A pain, because as Gabriel dos Reis points out, typedef's are a pain
with function overloading.  But otherwise, no problem.

>  . Type-generic std math functions (<tgmath.h>)

Again, without function overloading, what else could they do.  (As close
to C, but no closer, works in both directions.)

>  . Designated initializers (for structs and arrays)

Pure extension, easily adopted to C++.

>  . compound literals

A pure (and very useful) extension.  Regretfully, they work very poorly
with STL iterators.  (IMHO, a design problem with the STL iterators,
more than anything else.)

>  . '__func__' predefined identifier
>  . 'enum X { A, };' trailing comma

Two more pure extensions, trivially added to C++.

>  . IEC 60559 arithmetic support

> I don't claim that this is a complete list, but it covers most of
> the incompatibilities.  A few of these are library issues, but most
> are language differences.

The real problem will probably be complex.  For the rest, I don't
anticipate any problems.

> Note that most of them are just the new
> additions to C9X (C0X).  I expect that many of them will be
> incorporated into C++ compilers by vendors who make C/C++ compilers,
> but these must be considered compiler-specific extensions to C++.

Some (complex, _Bool) can't be.

> Also bear in mind that we're still fighting inconsistencies in the
> implementations of C++, since the ISO C++ standard is still rather
> new; most existing compilers still adhere more to the ARM than to
> ISO.  (See <http://fusshuhn.ourfamily.com/cppincomp.html>.)
> Remember that it took C compiler vendors a few years to catch up
> to ISO C89.

--
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/
Share what you know. Learn what you don't.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

gdosreis@korrigan.inria.fr (Gabriel Dos_Reis)  wrote on 21.08.99 in <xajiu6a57n2.fsf@korrigan.inria.fr>:

> "Douglas A. Gwyn" <gwyn@arl.mil> writes:
>
> | Gabriel Dos_Reis wrote:
> | >> One can add typedefs fou7nd in <inttypes.h> may interact badly with
> | > C++ overloading.
> |
> | Since a typedef is just a synonym for an existing type,
> | how could that happen?
>
> And that *is* the problem.
>
>  #include <inttypes.h>
>
>  void f(long) {}
>
>  void f(int32_t) {}

Allowing stuff like that is a significant part of what I don't like about
C++. (*Does* C++ allow this case? Why on earth?)

> Introducing new typenames by typedef is evil WRT overloading and
> templates.  We already have such a problem  with std::size_t; I'm
> not convinced it would be much funnier to add more.

Then this is a clear case of severely broken language design. (On the part
of C++, that is.) IMarrogantO, typedef is a *far* more important feature
than overloading or templates.

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)
---
[ 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 wrote:
>
> seebs@plethora.net (Peter Seebach) writes:
>
> >In article <37BC92E8.23F4B424@tribble.com>,
> >David R Tribble  <david@tribble.com> wrote:
> >> . \uXXXX characters (UCNs)
> >> . Extended identifiers (a\uXXXX)
>
>> ACK!  I was told those were specifically compatible with C++ stuff.
>>  Ick.
>
> They are part of the C++ standard; see 2.2, 2.10, and Annex E.
> But not many (if any) C++ compilers support them yet.

Yes, my mistake.  I don't know which committee invented them first.

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

James.Kanze@dresdner-bank.com wrote:
....
> Looks like a pure extension, easily added to C++.
>
> >  . 'bool' type (<stdbool.h>)
>
> The definition is significantly different, but I suspect that for most,
> if not all programs, a conditional include of stdbool.h is all that is
> required.
>
> >  . 'complex' keyword (type vs. template)
>
> They hardly had a choice, did they?  Without templates, they couldn't
> define complex as in C++.

The relevant new C9X keywords are _Bool, and _Complex, and _Imaginary,
and are always available. 'bool', 'complex', and 'imaginary', are macros
in C9X, defined in <stdbool.h> and <complex.h>, respectively, and are
required to expand to the corresponding keywords. However, unlike most
of the other standard library macros, you are explicitly permitted to
undefine and redefine those macros.

Therefore, it should be perfectly feasible for a C++ implementation to
support the keywords as extensions, with essentially the C9X semantics.
What it can't do is support the corresponding C9X macros.
---
[ 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 James.Kanze@dresdner-bank.com wrote:
:>  . 'long long' type
:>  . 'restrict' keyword

: More pure extensions, which could be added to C++ without (too many)
: problems.

I think the long long overload issues are well known. I believe restrict
will also require work in C++ to define what it means when declared within
a class scope. In particular it would be useful to indicate that pointer
members of a class do not alias with each other or with the object they are
contained in (this). Though perhaps it will simply be outlawed in class
scope.

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

David R Tribble (david@tribble.com) wrote [about UCNs]:
>
> Yes, my mistake.  I don't know which committee invented them first.

C++.  There are a number of details that the C committee probably would
have done differently if it were just up to us (or at least would have
liked to discuss doing differently), but we felt obliged to go along
with what C++ had done since, by the time we got involved, it was too
late to change C++.

-Larry Jones

I'm so disappointed. -- Calvin

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

kaih=7NRQYDQ1w-B@khms.westfalen.de (Kai Henningsen) writes:

>gdosreis@korrigan.inria.fr (Gabriel Dos_Reis)  wrote on 21.08.99 in <xajiu6a57n2.fsf@korrigan.inria.fr>:

>> And that *is* the problem.
>>
>>  #include <inttypes.h>
>>  void f(long) {}
>>  void f(int32_t) {}

>Allowing stuff like that is a significant part of what I don't like about
>C++. (*Does* C++ allow this case? Why on earth?)

What are you objecting to?  Typedefs?  Overloading in general?
Details of overloading rules?

>> Introducing new typenames by typedef is evil WRT overloading and
>> templates.  We already have such a problem  with std::size_t; I'm
>> not convinced it would be much funnier to add more.

>Then this is a clear case of severely broken language design. (On the part
>of C++, that is.) IMarrogantO, typedef is a *far* more important feature
>than overloading or templates.

In what way is the language design broken? What should the design be?

For example, if a typedef creates a new type, it would severely break
C compatibility. It would also eliminate a useful feature of typedefs:
the ability to abbreviate a complicated type name:
 typedef basic_string<char> string;

But if typedefs do not create a new type, then given
 typedef int III;
 III foo(III);
 int foo(int);
the two declarations of foo must refer to the same function, not an
overloaded pair. (As in Gabriel's example.)

Removing overloading from the language definition doesn't solve
the problem, because you are not required to use function overloading.
It merely finesses the problem. Every time you eliminate a language
feature, you remove one set of problems, but restore the set of
problems the feature was intended to solve.  Overloading is subject
to mis-use and abuse, just like every other language feature. (Well,
overloading is probably more subject to abuse than most other
language features. C++ is a tool with sharp edges -- good for
cutting knots and thorns, but you do have to know how to use it.)

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

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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:

> >  . 'complex' keyword (type vs. template)
>
> They hardly had a choice, did they?  Without templates, they couldn't
> define complex as in C++.

Huh ?

They couldn't define complex (at all) either.

> >  . Inline functions (not?)
>
> The definition in the two languages is different.  But the restrictions
> on their use in C is such that for the cases where they are legal in C,
> no conforming program can tell the difference (I think).

I read unspecified as different from undefined. I see no requirements
the public draft that the function shall be defined the same way in
two TR. Perhaps it has changed.

> >  . Variable-length arrays (VLAs)
>
> A pure extension, but with possible problems when added to C++.

Allowing it only on POD or C struct would cause no more
problems than in C IMO.

> >  . Type-generic std math functions (<tgmath.h>)
>
> Again, without function overloading, what else could they do.  (As close
> to C, but no closer, works in both directions.)

As close to C++ but no closer ?

> >  . '__func__' predefined identifier
> >  . 'enum X { A, };' trailing comma
>
> Two more pure extensions, trivially added to C++.

I conclude that you volunteer to give the definition of
__func__ in C++.

--

Valentin Bonnard


[ 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              ]

Gabriel Dos_Reis wrote:
>> One can add typedefs fou7nd in <inttypes.h> may interact badly with
> C++ overloading.

Since a typedef is just a synonym for an existing type,
how could that happen?
---
[ 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 (bs@research.att.com) wrote:
>
> I don't know. The C committee has made many changes to C for C0x but
> a polite request from the C++ committee for a list of changes that
> afffected C/C++ compatibility was answered by "we don't know and we
> don't have the time or expertice to compile such a list." Clearly, C++
> compatibility is at most a very minor concern to the C0x committee.

Oh, dear, I'm afraid you've completely misinterpreted our response.  C++
compatiblity is *very* important to us, but we really don't have much
expertise in C++.  (I dare say the average member of the C++ committee
has a far wider and deeper of knowledge of C than the average C
committee member has of C++, for what I hope are fairly obvious reasons.
Many of us aren't even competent C++ programmers, let alone experts.)
We count on our C++ liaison and the few other members who are
knowledgable about C++ to keep us from doing anything stupid, but the
committee as a whole doesn't have enough C++ knowledge to know whether a
change affects C++ compatibility or not, and our few experts don't have
the time to do it all themselves.  In sort, it seemed to us that the C++
committee was in a much better position to answer than question than we
were, particularly since the C++ standard had already been published
when the question was asked whereas the C committee was still trying to
do ballot resolution on the FCD.

Where we knew there were issues, we tried to stay compatible with C++
(e.g., adding // comments) or, where that was not possible (e.g., adding
complex arithmetic support), we went to great lengths to try to make it
possible to write code that is equally valid in either language without
requiring a lot of extra effort on the part of the programmer or
resulting in ugly code.

-Larry Jones

It COULD'VE happened by accident! -- Calvin
---
[ 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              ]

Wil Evers wrote:
>
> Bjarne Stroustrup <bs@research.att.com> wrote
>
>> There are good practical reasons for following C in some of the new
>> areas of C/C++ incompatibility. However, I consider it unlikely
>> that C++ vendors or the C++ committee will follow C0x in every
>> detail.
>>
>> I think the C committee missed the best opportunity to decrease
>> C/C++ incompatibilities that we'll ever get and instead increased
>> the number of incompatibilities. It will not be easy to compensate.
>
> Knowing how much effort you spent into keeping C++ as close to C as
> it is now, I have to say your statement worries me.  The way things
> are now, a C++ compiler has little trouble compiling a properly
> written C program; I know of a company where the most of C
> programmers aren't even aware that C++ is used to compile their code.
>
> Will it get more difficult to do this?  If so, in which areas of the
> language do you expect trouble?

Bjarne Stroustrup wrote:
> It would be nice if someone would document the C0x/C++
> incompatibilities.  It would be especially nice if that happened
> before C0x was frozen, but I think that is already too late so that
> some divergence is inevitable.

Yes, there already are some incompatibilities:
 . enum types
 . 'foo()' vs. 'foo(void)'
 . K&R-style (non-prototype) function declarations
 . Dynamic const initializers

C9X (C0X) adds a few more:
 . \uXXXX characters (UCNs)
 . Extended identifiers (a\uXXXX)
 . Binary float literals
 . 'bool' type (<stdbool.h>)
 . 'complex' keyword (type vs. template)
 . 'long long' type
 . 'restrict' keyword
 . Inline functions (not?)
 . Preprocessor '__VA_ARGS__'
 . Empty preprocessor function macro args
 . '_Pragma' preprocessing operator
 . Variable-length arrays (VLAs)
 . Flexible array members (the struct hack)
 . <inttypes.h> types
 . Type-generic std math functions (<tgmath.h>)
 . Designated initializers (for structs and arrays)
 . compound literals
 . '__func__' predefined identifier
 . 'enum X { A, };' trailing comma
 . IEC 60559 arithmetic support

I don't claim that this is a complete list, but it covers most of
the incompatibilities.  A few of these are library issues, but most
are language differences.  Note that most of them are just the new
additions to C9X (C0X).  I expect that many of them will be
incorporated into C++ compilers by vendors who make C/C++ compilers,
but these must be considered compiler-specific extensions to C++.

Also bear in mind that we're still fighting inconsistencies in the
implementations of C++, since the ISO C++ standard is still rather
new; most existing compilers still adhere more to the ARM than to
ISO.  (See <http://fusshuhn.ourfamily.com/cppincomp.html>.)
Remember that it took C compiler vendors a few years to catch up
to ISO C89.

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

"Douglas A. Gwyn" <gwyn@arl.mil> writes:

| Gabriel Dos_Reis wrote:
| >> One can add typedefs fou7nd in <inttypes.h> may interact badly with
| > C++ overloading.
|
| Since a typedef is just a synonym for an existing type,
| how could that happen?

And that *is* the problem.

 #include <inttypes.h>

 void f(long) {}

 void f(int32_t) {}


On a plateform where 'long' is 64 bits and 'int32_t' is a synonym for
'int', that is ok.  Now I get problems on a 32 bits plateform that
defines 'int32_t' to be a synonym for 'long' (int and long are 32 bits).


Introducing new typenames by typedef is evil WRT overloading and
templates.  We already have such a problem  with std::size_t; I'm
not convinced it would be much funnier to add more.

 template<typename T> struct X {};

 #include <cstddef>

 template struct X<unsigned int>;

 template<> struct X<std::size_t> { /* special things */ };

What if std::size_t == 'unsigned int' ?


--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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 <37BC92E8.23F4B424@tribble.com>,
David R Tribble  <david@tribble.com> wrote:
> . \uXXXX characters (UCNs)
> . Extended identifiers (a\uXXXX)

ACK!  I was told those were specifically compatible with C++ stuff.  Ick.

> . Inline functions (not?)

I think all valid C++ inline functions (modulo member functions) are valid
C inline functions, but not vice versa.

>I don't claim that this is a complete list, but it covers most of
>the incompatibilities.  A few of these are library issues, but most
>are language differences.  Note that most of them are just the new
>additions to C9X (C0X).  I expect that many of them will be
>incorporated into C++ compilers by vendors who make C/C++ compilers,
>but these must be considered compiler-specific extensions to C++.

Yeah.  Note that many of them are "C ways of doing things" for things where
C++ added a feature.  The languages have different designs and goals.

Personally, I think mutual compatability between them is nearly as important
as making sure that French and German words that mean the same thing continue
to mean the same thing.  I think "superset-of-C" C++ was an interesting
transitional mode, but it's a *bad* way to write code.  If you want C++,
you know where to find it.  If you want C, you know where to find it.  Figure
out what you want, and use it.

I don't expect shell scripts to be valid LISP code, and I don't expect C
to be valid C++.

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

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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 <37BC92E8.23F4B424@tribble.com>,
>David R Tribble  <david@tribble.com> wrote:
>> . \uXXXX characters (UCNs)
>> . Extended identifiers (a\uXXXX)

>ACK!  I was told those were specifically compatible with C++ stuff.  Ick.

They are part of the C++ standard; see 2.2, 2.10, and Annex E.
But not many (if any) C++ compilers support them yet.

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

bs@research.att.com (Bjarne Stroustrup) writes:

[...]

|  > If so, in which areas of the language do you expect trouble?
|
| Examples are
|
|  the complex type and its associated operators
|  arrays declared with non-const dimension (especially as
|  function arguments)
|  long long (especially its interaction with the C++ oveloading)

One can add typedefs fou7nd in <inttypes.h> may interact badly with
C++ overloading.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr


[ 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              ]

"Wil Evers" <bouncer@dev.null> writes

 > Bjarne Stroustrup <bs@research.att.com> wrote in article
 > <FG3MGE.30B@research.att.com>...
 >
 > > There are good practical reasons for following C in some of the new areas
 > > of C/C++ incompatibility. However, I consider it unlikely that C++
 > vendors
 > > or the C++ committee will follow C0x in every detail.
 > >
 > > I think the C committee missed the best opportunity to decrease C/C++
 > > incompatibilities that we'll ever get and instead increased the number of
 > > incompatibilities. It will not be easy to compensate.
 >
 > Knowing how much effort you spent into keeping C++ as close to C as it is
 > now, I have to say your statement worries me.  The way things are now, a
 > C++ compiler has little trouble compiling a properly written C program; I
 > know of a company where the most of C programmers aren't even aware that
 > C++ is used to compile their code.

I think you should be worried. I am.


 > Will it get more difficult to do this?

I don't know. The C committee has made many changes to C for C0x but
a polite request from the C++ committee for a list of changes that
afffected C/C++ compatibility was answered by "we don't know and we
don't have the time or expertice to compile such a list." Clearly, C++
compatibility is at most a very minor concern to the C0x committee.

The response of the C++ committee - who has carefully documented every
C89/C++ incompatibility - was to request the committee's parent body
(SC22) to remove the requirement on the C++ committee to release it of
compatibility constraints (the C committee was never under reciprocal
formal constraints). I support the decision to reluctantly abandon
formal compatibility requirements. Having one-sided rules is impractical.
You can have improved compatibility only if both sides consider it
important. And only if both sides have people willing to work together
to do the work.

A large majority of the C++ committee consider C compatibility important
("as close to C as possible, but no closer"), but the C++ community cannot
blindly and unconditionally accept changes made to C without consideration
of their impact on C++.


 > If so, in which areas of the language do you expect trouble?

Examples are

 the complex type and its associated operators
 arrays declared with non-const dimension (especially as
 function arguments)
 long long (especially its interaction with the C++ oveloading)

I hope the practical problems will be minor, but since I don't have
a list of new incompatibilities, I cannot be sure. The integration
of all new C facilities will not be trivial.

It would be nice if someone would document the C0x/C++ incompatibilities.
It would be especially nice if that happened before C0x was frozen,
but I think that is already too late so that some divergence is inevitable.

 - Bjarne
Bjarne Stroustrup - http://www.research.att.com/~bs


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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 <bs@research.att.com> wrote in article
<FG3MGE.30B@research.att.com>...

> There are good practical reasons for following C in some of the new areas
> of C/C++ incompatibility. However, I consider it unlikely that C++
vendors
> or the C++ committee will follow C0x in every detail.
>
> I think the C committee missed the best opportunity to decrease C/C++
> incompatibilities that we'll ever get and instead increased the number of
> incompatibilities. It will not be easy to compensate.

Knowing how much effort you spent into keeping C++ as close to C as it is
now, I have to say your statement worries me.  The way things are now, a
C++ compiler has little trouble compiling a properly written C program; I
know of a company where the most of C programmers aren't even aware that
C++ is used to compile their code.

Will it get more difficult to do this?  If so, in which areas of the
language do you expect trouble?

- Wil

Wil Evers, DOOSYS IT Consultants, Maarssen, Holland
[Wil underscore Evers at doosys dot 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              ]

| > An even better solution is to keep these functions as they are,
| > and specify that the library should take care of multi-threaded
| > access (for instance, using thread-local storage).
|
| And incur overhead in the bargain.

If properly done, the overhead is non-existent.  I hate to give MS
software as a good example of anything, but this, they get right.  The
trick is that a small, fixed number of locations are set aside in each
thread structure to support the small number of "global" contexts that
are needed to make C, C++, and emulated Unix library functions thread
safe.  The cost to access these is equivalent to the cost to access a
single shared location.

Note, BTW, that even Unix implementations pretty much have to do
something like this to provide a thread-safe errno.

|         No, we should follow the lead
| of most Unixes and add replacement functions which are thread-safe
| (and incur zero additional overhead in multithread programs), e.g.,
| the localtime_r() function et al.

Granted, the Unix vendors faced a different problem:  They were working
with thread packages structured as libraries; often with compilers they
didn't control; and, in any case, organizationally it was apparently
difficult for them to coordinate the thread implementation, the
compiler, and the library implementations.  The "_r" functions follow
the long Unix tradition of "it's too hard for us to get right, so we'll
dump the problem on every programmer who uses our stuff."

That said, *many* (not all) of the "_r" functions are reasonable - the
functions they extend had interfaces that needed work.  It's unfortunate
that there's been little de facto (much less de jure) standardization of
these interfaces.  (Some of them also have their problems.  My favorite
"bug trap" is gethostbyname_r, which has a semantically output-only
argument HostentData which on at least two implementations I know of
must be initialized by the caller.  There's no validation of what you
pass in, so if you miss the little note in the documentation, you get
all kinds of wierd results, like SEGV's deep inside the name resolver.)

|        The Unix vendors obviously thought
| that this was an important enough issue to go to the trouble of
| adding these replacement functions, so I think ISO should consider
| them as well.

They thought these functions important enough to implement, but not
important enough to standardize.  The complete lack of consistency in
calling form shows up in the code I support:  It provides a common
interface on a bunch of different systems.  Outside of dynamic library
loading (and threads, because not everyone supports the Posix standard
yet - but at least they are heading rapidly in that direction, so I can
see the day when I'll have Posix and NT versions and nothing else) the
code that hides the differences between different "_r" (or no "_r")
implementations is the messiest and most system-dependent.

       -- Jerry
---
[ 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              ]

On 3 Aug 1999 14:46:37 -0400, David R Tribble <david@tribble.com>
wrote:

[...]
>1.  Replacing library functions that rely on static/global data
> between calls (e.g., strtok()).  My proposal suggested replacement
> (or simple "additional") functions, modeled after existing Unix
> implementations.  Making a function take an extra caller-supplied
> argument rather than relying on static/global data is a big step
> forwards to making that function thread-safe (reentrant).

An even better solution is to keep these functions as they are,
and specify that the library should take care of multi-threaded
access (for instance, using thread-local storage).

[...]
>2.  Addressing areas of the library that are inherently single-
>threaded in nature:
>  a.  malloc()/free() and the heap.

These functions belong to the previous category. Client code should
not care how malloc() (& friends) is implemented. It really should
make no difference if malloc() locks a global strucutre or maintains
per-thread structures (the faster approach).

>  b.  signals.
>  c.  exit(), atexit(), and abort().

Both these relate to the async-exceptions issue, which has raised a
somewhat heated discussion in the threads NG. I don't think we could
get a concensus here.

>  d.  floating-point controls.
>  e.  locales.
>
> Solutions for these issues should retain, as much as possible,
> backward compatibility with old source and binaries.  In particular,
> they should not entail drastic changes for programs or compilers
> that are not targeted for multithreaded environments.

I would go futher: They should entail no changes for programs that
are not multi-threaded.

[...]

---------------------------------------------
Ziv Caspi
zivca@netvision.net.il

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]

Ziv Caspi wrote:
>
> David R Tribble <david@tribble.com> wrote:
>
> [...]
>> 1.  Replacing library functions that rely on static/global data
>> between calls (e.g., strtok()).  My proposal suggested replacement
>> (or simple "additional") functions, modeled after existing Unix
>> implementations.  Making a function take an extra caller-supplied
>> argument rather than relying on static/global data is a big step
>> forwards to making that function thread-safe (reentrant).
>
> An even better solution is to keep these functions as they are,
> and specify that the library should take care of multi-threaded
> access (for instance, using thread-local storage).

And incur overhead in the bargain.  No, we should follow the lead
of most Unixes and add replacement functions which are thread-safe
(and incur zero additional overhead in multithread programs), e.g.,
the localtime_r() function et al.  The Unix vendors obviously thought
that this was an important enough issue to go to the trouble of
adding these replacement functions, so I think ISO should consider
them as well.

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

From: David R Tribble <david@tribble.com>

> "Douglas A. Gwyn" wrote:
>
> > > a)  A minimalist C++.  ...
> >
> > I'm frankly not concerned with C++.  For programming DSPs, embedded
> > controllers, etc., we generally use C rather than C++.

However, many others do not feel the need to restrict themselves to what C
offers in those areas. Embedded systems is an area of major concern to many
in the C++ community.


> My feeling is that the next C++ will follow the lead of whatever
> is done to C0X, if for no other reason that to keep a certain amount
> of compatibility between the two languages (notwithstanding enum,
> complex, and exceptions).

There are good practical reasons for following C in some of the new areas
of C/C++ incompatibility. However, I consider it unlikely that C++ vendors
or the C++ committee will follow C0x in every detail.

I think the C committee missed the best opportunity to decrease C/C++
incompatibilities that we'll ever get and instead increased the number of
incompatibilities. It will not be easy to compensate.

 - Bjarne
Bjarne Stroustrup - http://www.research.att.com/~bs





      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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" wrote:
>
> Robert O'Dowd wrote:
>> I would suggest these requirements as being tough to address in a
>> general language spec, particularly since C and C++ are both defined
>> in a way that assumes single thread of execution, a run time
>> environment (that, for example, captures and possibly uses the
>> return value for main), and plenty of other things.  There would
>> also, reasonably, be an expectation that a compliant programs
>> written today would mostly work correctly under any new standard.
>> And howls of anguish from people on (say) systems that do not
>> support multi-threading if the language specifically requires
>> multi-threading support.
>
> Sorry, but I don't find any of those arguments convincing.
> We could certainly make the C spec thread-safe, with no problem
> of backward compatibility.  I think more people who are in a position
> to have an informed opinion would prefer thread-safe to otherwise.
> *We wouldn't have to mandate multiple-thread support to do this.*

Indeed.  The following areas are suitable topics for discussion
about making the C library thread-safe:

1.  Replacing library functions that rely on static/global data
 between calls (e.g., strtok()).  My proposal suggested replacement
 (or simple "additional") functions, modeled after existing Unix
 implementations.  Making a function take an extra caller-supplied
 argument rather than relying on static/global data is a big step
 forwards to making that function thread-safe (reentrant).

 This kind of solution retains backward compatibility with old
 source and binaries.

2.  Addressing areas of the library that are inherently single-
threaded in nature:
  a.  malloc()/free() and the heap.
  b.  signals.
  c.  exit(), atexit(), and abort().
  d.  floating-point controls.
  e.  locales.

 Solutions for these issues should retain, as much as possible,
 backward compatibility with old source and binaries.  In particular,
 they should not entail drastic changes for programs or compilers
 that are not targeted for multithreaded environments.

> > a)  A minimalist C++.  ...
>
> I'm frankly not concerned with C++.  For programming DSPs, embedded
> controllers, etc., we generally use C rather than C++.

My feeling is that the next C++ will follow the lead of whatever
is done to C0X, if for no other reason that to keep a certain amount
of compatibility between the two languages (notwithstanding enum,
complex, and exceptions).

-- 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 <37A130F0.4D5AE1EC@nonexistant.com>, Robert O'Dowd
<nospam@nonexistant.com> writes
>Just my $0.02 anyway.  I'm sure there are many issues I, as a
>simple minded user of the language, have missed.


Like an entirely new set of standards committees:)  The one thing they
are all agreed upon (well almost all) is that they do not want subset
languages.


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


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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 O'Dowd wrote:
> I would suggest these requirements as being tough to address in a
> general language spec, particularly since C and C++ are both defined
> in a way that assumes single thread of execution, a run time
> environment (that, for example, captures and possibly uses the
> return value for main), and plenty of other things.  There would
> also, reasonably, be an expectation that a compliant programs
> written today would mostly work correctly under any new standard.
> And howls of anguish from people on (say) systems that do not
> support multi-threading if the language specifically requires
> multi-threading support.

Sorry, but I don't find any of those arguments convincing.
We could certainly make the C spec thread-safe, with no problem
of backward compatibility.  I think more people who are in a position
to have an informed opinion would prefer thread-safe to otherwise.
*We wouldn't have to mandate multiple-thread support to do this.*
And the C Standard already recognizes a "standalone" environments as
a subset of the "hosted" environment, without requirements for a
function named "main".  We also had presentations of low-level I/O
support proposals during C9x deliberations, although in the end we
decided we weren't ready to mandate them for conformance just yet.

> a)  A minimalist C++.  Assumes single thread of execution, basic
>       language features, and a cut down library (eg no dynamic
> memory, or language features that depend on it).

C++ without dynamic allocation is rather pointless.

> b) .. f)

I'm frankly not concerned with C++.  For programming DSPs, embedded
controllers, etc., we generally use C rather than C++.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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" wrote:
>
> Francis Glassborow wrote:
> > In article <379F9683.B90F8B28@tribble.com>, David R Tribble
> > <david@tribble.com> writes
> > > 5. Bring thread-safety up as a discussion item at the next ISO
> > >    C and C++ committee meetings.  (Which won't be for another
> > >    five years or so.)
> > Actually there is a meeting of both this October:) My memory is that
> > when we last considered thread safety the consensus was that
> > implementers should specify those parts of their libraries that were
> > thread safe.
>
> The official party line is that the C Standard assumes a single
> thread of execution, and says nothing when there are multiple threads.
> This is something I think we should address during the next few years,
> along with other topics that come up in various general C environments,
> especially embedded-system and other standalone applications.
> This is an area where C continues to dominate, despite not having much
> standardized support for important tasks such as direct I/O access,
> exception handling, parallelism, pipelined execution, etc.
>

I would suggest these requirements as being tough to address in a
general
language spec, particularly since C and C++ are both defined in a way
that
assumes single thread of execution, a run time environment (that, for
example, captures and possibly uses the return value for main), and
plenty of other things.  There would also, reasonably, be an expectation
that a compliant programs written today would mostly work correctly
under any
new standard.  And howls of anguish from people on (say) systems that do
not support multi-threading if the language specifically requires
multi-threading support.

Maybe, however, it would be possible to define things like

a)  A minimalist C++.  Assumes single thread of execution, basic
      language features, and a cut down library (eg no dynamic memory,
      or language features that depend on it).  Same philosophy
      as for the freestanding C/C++ libraries, but applied
      to the language spec.
b)  A full featured single threaded C++.  Basically includes everything
       that's in the standard today, plus reasonable enhancements
       [those would be open to debate].
c)  An embedded C++.  Sort of like the minimalist C++, with features
       adapted for embedded systems (small footprint, etc etc).
d)  A multi-threaded C++.  Includes support in the language or libraries
       for management of threads, mutexes (or similar), thread
       local storage.  Maybe three versions -- eg based on a-c
       but multi-threaded.
f)  A distributed C++ (eg incorporates something like a CORBA ORB).

My point is that it should be possible to identify core features
that are needed for different versions of the language (like the
above, but surely others).  The dialects would be related.
For example, minimalist C++ would be a defined subset of the
full-featured, a single threaded application would give the same
results whether compiled under multi-threaded or single-threaded C++
(apart from the sort that would be expected today if [say] we
use a MT library today to build a single threaded application).

This sort of thing would take away some of the headaches for
compiler vendors.  For example, a compiler vendor would not
need to worry about multi-thread support on an operating system
that doesn't support it.  All they would need to do is specify
compliance with one or more of the subsets.

Just my $0.02 anyway.  I'm sure there are many issues I, as a
simple minded user of the language, have missed.

R


-<Automagically included trailer>
Robert O'Dowd                       Ph    +61 (8) 8259 6546
MOD/DSTO                     Fax    +61 (8) 8259 5139
P.O. Box 1500                       Email:
robert.odowd@dsto.defence.gov.au
Salisbury, South Australia, 5108

Disclaimer: Opinions above are mine and may be worth what you paid for
them
---
[ 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              ]

Jerry Leichter wrote:
> | This is not thread safe, is it?
>
> It depends on the compiler.
...
>
> This is an area on which the Standard is (deliberately) silent.
> "Proper" implementation is undefined by the Standard, and ill-defined
> in practice.  (The same applies to dynamically loaded libraries - and
> especially to the interaction of threads with dynamically loaded
> libraries.)

The C++ standard makes no mention of, and seems to be written with no
concept at all of, thread-safety.  The C standard is the same.
True, it's a QoI issue, but there are functions in the standard
libraries that could be defined so as to be more easily implemented
as thread-safe code.  (Adding mutexes to force code to be thread-
safe is typically rather expensive and diffcult to get right.)

I proposed replacements for some of the standard C library functions
that rely on static data between multiple invocations (one of the
banes of thread-safe programming), based on existing Unix
implementations, but the ISO committee was not very enthusiastic
about them.  (See http://david.tribble.com/text/c9xthr.txt .)

Some lessons to be learned here are:

 1. Avoid using those standard functions that aren't thread-safe
    if you want your code to be thread-safe.

 2. Avoid the use of non-const static (global) data in your functions
    if you want them to be thread-safe.

 3. Avoid starting any threads until all of the static objects in
    your program have been instantiated.

 4. If your compiler doesn't produce thread-safe code, complain to
    the vendor.

 5. Bring thread-safety up as a discussion item at the next ISO
    C and C++ committee meetings.  (Which won't be for another
    five years or so.)

-- 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 <379F9683.B90F8B28@tribble.com>, David R Tribble
<david@tribble.com> writes
> 5. Bring thread-safety up as a discussion item at the next ISO
>    C and C++ committee meetings.  (Which won't be for another
>    five years or so.)

Actually there is a meeting of both this October:) My memory is that
when we last considered thread safety the consensus was that
implementers should specify those parts of their libraries that were
thread safe.



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:
> In article <379F9683.B90F8B28@tribble.com>, David R Tribble
> <david@tribble.com> writes
> > 5. Bring thread-safety up as a discussion item at the next ISO
> >    C and C++ committee meetings.  (Which won't be for another
> >    five years or so.)
> Actually there is a meeting of both this October:) My memory is that
> when we last considered thread safety the consensus was that
> implementers should specify those parts of their libraries that were
> thread safe.

The official party line is that the C Standard assumes a single
thread of execution, and says nothing when there are multiple threads.
This is something I think we should address during the next few years,
along with other topics that come up in various general C environments,
especially embedded-system and other standalone applications.
This is an area where C continues to dominate, despite not having much
standardized support for important tasks such as direct I/O access,
exception handling, parallelism, pipelined execution, etc.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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              ]