Helmut Zeisel wrote:
> fjh@cs.mu.OZ.AU (Fergus Henderson) wrote in message
> news:<3f9cdc72$1@news.unimelb.edu.au>...
>> zei2003b@liwest.at (helmut zeisel) writes:
>>
>> >What are these good reasons to use inline differently in C and C++?
>>
>> C++'s "inline" feature requires more sophistication in the linker than C.
>> The C committee did not want to limit the uptake of the new C standard by
>> making the new standard much harder to implement than the 1989 C standard.
>> So they went for a design which did not require a sophisticated linker,
>> at the expense of requiring a little bit more work from the programmer.
>
> Sorry, I do not understand.
> Stroustrup in "Design and Evolution of C++", Chapter 2.5, "The Linkage
> Model" writes: "One of the critical influences on the development of
> C++ was the decision that separate compilation should be possible with
> traditional C linkers".

That was the original intent, but later changes seem to require
more sophisticated linkers.

>> In C99, you would write
>>
>>  // foo.h
>>  inline void foo() { ... }
>>
>>  // foo.c
>>  extern void foo();
>>
>> and the declaration in the .c file is needed to avoid link errors in cases
>> where the function can't be inlined (e.g. because its address is taken).
>
> Why? When a non-inlined version of the function is needed, it is the
> compiler who has to create the "instance" (with local/static linkage)
> of the inlined function, so I do not see how the linker should be
> involved in a nontraditional way.

A function must have a single address at run-time, so either the
compiler must avoid generating multiple non-inline instances
(aided by the programmer in C, but impractical in a C++
implementation) or the linker must resolve all references to the
function to a single instance (usual practice in C++
implementations).  I think most C linkers are capable of doing
the latter, but not all since it's not necessary for
implementation of standard C.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Helmut Zeisel wrote:

> >  // foo.h
> >  inline void foo() { ... }
> >
> >  // foo.c
> >  extern void foo();
> >
> > and the declaration in the .c file is needed to avoid link errors in cases
> > where the function can't be inlined (e.g. because its address is taken).
>
> Why? When a non-inlined version of the function is needed, it is the
> compiler who has to create the "instance" (with local/static linkage)
> of the inlined function, so I do not see how the linker should be
> involved in a nontraditional way.

In C++, if two different translation units are unable to
inline the same inline function, then the corresponding
object files will typically both contain copies of these
functions.  The linker has to then be smart enough to remove
one of these copies.

By contrast, in C, if two translation units are unable to
inline the function, neither of the object files will
contain the function.  The programmer is required to handle
this manually by explicitly creating an extern definition
of the inline function in a translation unit.  As there is
now guaranteed to be only one copy of this function, the
linker does not have to do anything inteligent to remove the
copies.

--
Richard Smith

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

""Dave"" <better_cs_now@yahoo.com> wrote in message
news:vpc3qu3c0divd4@news.supernews.com...
>
> Hello all,
>
> A very interesting point was raised over on comp.lang.c++.  One poster
> pointed out that C++ was designed for backward compatibility with C, but
> then C moved on (to C99)!  The point was then raised by another poster that
> it is apparently a matter of current debate in / between the two languages'
> standardization committees as to whether the two languages will be
> reconciled as part of the current C++0X effort.
>
> I am very curious about this, so I thought I'd throw this out to the
> standardization committee members who monitor this group to see what the
> current state of affairs is on this topic.
>
> Thanks! (And, while I'm at it, thanks for an awesome language!)
>


In general it's a stupid idea devoid of merit; the C group won't fix problems
with their language to bring it in line with C++, because there's no point --
if they wanted C++ they'd just use C++.

The only way any reconciliation can occur is if C++ breaks itself to match
what C allows.  The purpose of this is unclear.

C++ is a well-established language in its own right.  It no longer has any
need to depend on C for its market penetration.  The reverse is true.  C cruft
(including large numbers of people writing effectively C in C++) is hurting
the language.  Stupidities like

int* pInt, thisIsNotAPointer; // the whole declarator nonsense is a PITA.  *
should be a type constructor

and

vector<char> iMeantToDefaultInitializeButInsteadIDeclaredAFunction();

are there principally because of C and serve only to make the language more
annoying to use.

Why, for instance, should C++ gain clog?  C++ has overloading (well, C99 does
kinda too with its "generic" crud, but for some unfathomable (to me) reason it
doesn't use it here).  It doesn't need to call a complex logarithm function
clog, because it can -- and does -- just call it log.  There's no utility to
providing clog in C++ -- the only people who'd use clog are people writing C99
and, guess what?  They don't care about C++.  If they did, they wouldn't be
writing C99.

Any changes made to C++ that bring it closer to C99 should be done
coincidentally -- for example, some kind of indication that pointers don't
alias one would probably be useful.  Not because C99 added restrict, but
because the utility of such a thing seems fairly clear, and some problem
domains would benefit greatly from it.

What the WG should do is to say "nuts to C compatibility" and make breaking
changes in the language to make it a better language.  Breaking changes aren't
that big a deal -- compiler vendors will just provide dual-mode compilers,
like they do already, to pick between C89 and C99.  The issue can be easily
overcome.  They should be doing things like making int* a, b; declare two
pointers to int, not a pointer to int and an int; function declarations should
be changed so that, amongst other things, the most vexing parse no longer
occurs.  Clean up the C legacy cruft, but retain the important parts of C++ --
"don't pay for what you don't use" and reasonable support for different
programming paradigms.

--
Now Playing:  Tunnel Trance Force Vol.26 CD1 - Green Grass Mix (D I G I T A L
L Y - I M P O R T E D - European Trance, Techno, Hi-NRG... we can't define
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.jamesd.demon.co.uk/csc/faq.html                       ]

Helmut Zeisel wrote:
> eldiener@earthlink.net ("Edward Diener") wrote in message
> news:<vzHlb.14538$Uz6.8529@newsread1.news.atl.earthlink.net>...
>
>> I would very
>> much like to see C++ move on in the future and throw off many of the
>> C-like trappings in order to become a more regular, more orthogonal,
>> and easier to use language.
>
> Yes, but wouldn't C++ be "more regular and easier to use" when the
> meaning of C elements is the same in both C and C++?

No. Regularity and ease of use does not mean, IMHO, conformance to older
constructs and standards.

>
>> Continued support of a number of retrograde syntax elements,
>> which are part of C++'s C language roots, should be dropped and/or
>> transformed into modern idioms as C++ evolves into its own language.
>
> For example?

1) C style casts, ie. (sometype)someVariable or sometype(someVariable)
2) Use of void to declare a function with no arguments
3) Numerous C isms which are still around for backward compatibility but
which inhibit clearer parsing of language constructs.

When some syntax element which supports C has a much better C++ equivalent,
still exists for the sole purpose of supporting older C code, and no longer
fits well with more modern C++ constructs, I would like to see it deprecated
and then removed from the language. This will clear out space for better
parsing and understanding of the language, and allow clearer and better
designed language elements to be added in the future. By carrying around 30
years of C language syntax, C++ has been weighed down and can not make easy
language changes which would improve usage. Often someone will ask, why does
some feature still exist when we have better ways to do things now. The
patient explanation will be that it is done for backward compatibility for
C++'s C language roots. It is time to consider removing these backward
compatibility situations when better syntax exist, and clearing the language
of this debris so that it can grow in the future.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Helmut Zeisel" <zei2003b@liwest.at> wrote in message
news:b0d00898.0310230213.6af837d8@posting.google.com...
> eldiener@earthlink.net ("Edward Diener") wrote in message
news:<vzHlb.14538$Uz6.8529@newsread1.news.atl.earthlink.net>...
> Yes, but wouldn't C++ be "more regular and easier to use" when the
> meaning of C elements is the same in both C and C++?
No, it wouldn't.  The reason being that C is so horrible to use.  C++ inherits
a great deal of that horridness, and there's no longer any good reason to do
so.  A process of excision should begin.

> > Continued support of a number of retrograde syntax elements,
> > which are part of C++'s C language roots, should be dropped and/or
> > transformed into modern idioms as C++ evolves into its own language.
> For example?
int* thisIsAPointer, butThisIsNot;
std::vector<char> thisIsNotADefaultConstructedObject();
std::vector<char>
andThisIsNotRangeConstructed(istreambuf_iterator<char>(myFile),
istreambuf_iterator());
class forwardDeclared;
int squareBracketsArePostfix[]; int* butStarsArePrefix;
std::string thisLooksLikeAssignmentButIsReallyInitialization = "Hello";
int butIAnnoyinglyMustUseAssignmentForAggregateInitialization[] = {1, 2, 3};
const char* theseAre;
char const* theSame;

> As I understand, the "roadmap" for future evolution of C++ is to
> incorporate major changes in the library only; the core language is
> not supposed to change much in the future. Library additions usually
> do not interfere much with C compatibilty.
More's the pity.



--
Now Playing:  10-Freebase - Broken (D I G I T A L L Y - I M P O R T E D -
European Trance, Techno, Hi-NRG... we can't define 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.jamesd.demon.co.uk/csc/faq.html                       ]

pjp@dinkumware.com ("P.J. Plauger") wrote in message news:<X3plb.26766$Ee6.16442@nwrddc01.gnilink.net>...

> On the language side the problems are more diverse. Adding variable
> length arrays, for example, causes real problems.

What excatly are the problems? AFAIK, problems are only for types with
destructor, so a solution might be that C++ allows VLA for PODs only.
Am I missing something?

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://www.jamesd.demon.co.uk/csc/faq.html                       ]

pjp@dinkumware.com ("P.J. Plauger") wrote in message news:<sJXlb.58285$mp1.11139@nwrddc02.gnilink.net>...
> "Helmut Zeisel" <zei2003b@liwest.at> wrote in message
> > Are there good reasons that inline, bool, or clog are used differently
> > in both languages?
>
> inline, yes.
> bool, sorta yes but I don't think they're incompatible.
> clog, a botch, but luckily not as bad as it looks.

What do you mean by "yes"? That they are used differently, or that
there are good reasons to use them differently?

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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Helmut Zeisel" <zei2003b@liwest.at> wrote in message
news:b0d00898.0310240156.71be6efb@posting.google.com...

> pjp@dinkumware.com ("P.J. Plauger") wrote in message
news:<sJXlb.58285$mp1.11139@nwrddc02.gnilink.net>...
> > "Helmut Zeisel" <zei2003b@liwest.at> wrote in message
> > > Are there good reasons that inline, bool, or clog are used differently
> > > in both languages?
> >
> > inline, yes.
> > bool, sorta yes but I don't think they're incompatible.
> > clog, a botch, but luckily not as bad as it looks.
>
> What do you mean by "yes"? That they are used differently, or that
> there are good reasons to use them differently?

A little bit of both.

P.J. Plauger
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://www.jamesd.demon.co.uk/csc/faq.html                       ]

P.J. Plauger wrote:
> "Helmut Zeisel" <zei2003b@liwest.at> wrote in message
> news:b0d00898.0310240156.71be6efb@posting.google.com...
>
>
>>pjp@dinkumware.com ("P.J. Plauger") wrote in message
>
> news:<sJXlb.58285$mp1.11139@nwrddc02.gnilink.net>...
>
>>>"Helmut Zeisel" <zei2003b@liwest.at> wrote in message
>>>
>>>>Are there good reasons that inline, bool, or clog are used differently
>>>>in both languages?
>>>
>>>inline, yes.
>>>bool, sorta yes but I don't think they're incompatible.
>>>clog, a botch, but luckily not as bad as it looks.
>>
>>What do you mean by "yes"? That they are used differently, or that
>>there are good reasons to use them differently?
>
>
> A little bit of both.

What are these good reasons to use inline differently in C and C++?

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://www.jamesd.demon.co.uk/csc/faq.html                       ]

zei2003b@liwest.at (helmut zeisel) writes:

>What are these good reasons to use inline differently in C and C++?

C++'s "inline" feature requires more sophistication in the linker than C.
The C committee did not want to limit the uptake of the new C standard by
making the new standard much harder to implement than the 1989 C standard.
So they went for a design which did not require a sophisticated linker,
at the expense of requiring a little bit more work from the programmer.

In C99, you would write

 // foo.h
 inline void foo() { ... }

 // foo.c
 extern void foo();

and the declaration in the .c file is needed to avoid link errors in cases
where the function can't be inlined (e.g. because its address is taken).
In C++, there is no need for that declaration; it is enough to just
define the function in the header file.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

fjh@cs.mu.OZ.AU (Fergus Henderson) wrote in message news:<3f9cdc72$1@news.unimelb.edu.au>...
> zei2003b@liwest.at (helmut zeisel) writes:
>
> >What are these good reasons to use inline differently in C and C++?
>
> C++'s "inline" feature requires more sophistication in the linker than C.
> The C committee did not want to limit the uptake of the new C standard by
> making the new standard much harder to implement than the 1989 C standard.
> So they went for a design which did not require a sophisticated linker,
> at the expense of requiring a little bit more work from the programmer.

Sorry, I do not understand.
Stroustrup in "Design and Evolution of C++", Chapter 2.5, "The Linkage
Model" writes: "One of the critical influences on the development of
C++ was the decision that separate compilation should be possible with
traditional C linkers".

> In C99, you would write
>
>  // foo.h
>  inline void foo() { ... }
>
>  // foo.c
>  extern void foo();
>
> and the declaration in the .c file is needed to avoid link errors in cases
> where the function can't be inlined (e.g. because its address is taken).

Why? When a non-inlined version of the function is needed, it is the
compiler who has to create the "instance" (with local/static linkage)
of the inlined function, so I do not see how the linker should be
involved in a nontraditional way.

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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hello all,

A very interesting point was raised over on comp.lang.c++.  One poster
pointed out that C++ was designed for backward compatibility with C, but
then C moved on (to C99)!  The point was then raised by another poster that
it is apparently a matter of current debate in / between the two languages'
standardization committees as to whether the two languages will be
reconciled as part of the current C++0X effort.

I am very curious about this, so I thought I'd throw this out to the
standardization committee members who monitor this group to see what the
current state of affairs is on this topic.

Thanks! (And, while I'm at it, thanks for an awesome language!)

Best regards,
Dave


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

better_cs_now@yahoo.com ("Dave") wrote in message news:<vpc3qu3c0divd4@news.supernews.com>...
> Hello all,
>
> A very interesting point was raised over on comp.lang.c++.  One poster
> pointed out that C++ was designed for backward compatibility with C, but
> then C moved on (to C99)!  The point was then raised by another poster that
> it is apparently a matter of current debate in / between the two languages'
> standardization committees as to whether the two languages will be
> reconciled as part of the current C++0X effort.
>
> I am very curious about this, so I thought I'd throw this out to the
> standardization committee members who monitor this group to see what the
> current state of affairs is on this topic.

Work is ongoing. As far as the Standard Library is concerned, you
might want to see http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1503.txt.
The Standards Committee's Library Working Group (LWG) will discuss
this proposal next week in Kona, Hawaii. Since this proposal was
written at the specific request of the LWG, it will probably be well
received.

--Beman

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

""Dave"" <better_cs_now@yahoo.com> wrote in message news:vpc3qu3c0divd4@news.supernews.com...

> A very interesting point was raised over on comp.lang.c++.  One poster
> pointed out that C++ was designed for backward compatibility with C, but
> then C moved on (to C99)!  The point was then raised by another poster that
> it is apparently a matter of current debate in / between the two languages'
> standardization committees as to whether the two languages will be
> reconciled as part of the current C++0X effort.
>
> I am very curious about this, so I thought I'd throw this out to the
> standardization committee members who monitor this group to see what the
> current state of affairs is on this topic.

Dinkumware has long since reconciled the C++ and C99 *libraries*. We
have produced a proposal to add these reconciliations as part of the
(non-normative) library technical report (a.k.a. TR1) currently being
developed. By the end of the C++ standards meeting next week, we should
know more about whether this proposal is acceptable to the committee.

On the language side the problems are more diverse. Adding variable
length arrays, for example, causes real problems. Even adding
restrict raises serious issues with the overloading rules. I leave
it to others to speculate about the prospect of C++ adopting any C99
language changes.

P.J. Plauger
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://www.jamesd.demon.co.uk/csc/faq.html                       ]

better_cs_now@yahoo.com ("Dave") wrote in message news:<vpc3qu3c0divd4@news.supernews.com>...
> Hello all,
>
> A very interesting point was raised over on comp.lang.c++.  One poster
> pointed out that C++ was designed for backward compatibility with C, but
> then C moved on (to C99)!  The point was then raised by another poster that
> it is apparently a matter of current debate in / between the two languages'
> standardization committees as to whether the two languages will be
> reconciled as part of the current C++0X effort.
>
> I am very curious about this, so I thought I'd throw this out to the
> standardization committee members who monitor this group to see what the
> current state of affairs is on this topic.

The overall plan is for C++ and C99 to continue evolving in seperate
directions. Both committees have made it a priority (among many other,
conflicting, priorities) to minimize incompatibilities between the two
languages, unless there's a good reason.. However, incompatibilities
for which there are good reasons are already numerous, and you should
expect to see more in the future.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Dave" wrote:
> Hello all,
>
> A very interesting point was raised over on comp.lang.c++.  One poster
> pointed out that C++ was designed for backward compatibility with C,
> but then C moved on (to C99)!  The point was then raised by another
> poster that it is apparently a matter of current debate in / between
> the two languages' standardization committees as to whether the two
> languages will be reconciled as part of the current C++0X effort.
>
> I am very curious about this, so I thought I'd throw this out to the
> standardization committee members who monitor this group to see what
> the current state of affairs is on this topic.

I have nothing to do with the standardization committee but I would very
much like to see C++ move on in the future and throw off many of the C-like
trappings in order to become a more regular, more orthogonal, and easier to
use language. Continued support of a number of retrograde syntax elements,
which are part of C++'s C language roots, should be dropped and/or
transformed into modern idioms as C++ evolves into its own language.
Attempting to forever reconcile two different languages, despite the fact
that both have a common root, is a mistake. Computer languages, like human
languages, need to change for the better when a positive change is being
made, and C++ needs to consider its future as a dynamic language and not its
past as a fairly static procedural language. I hope the members of the C++
standards committee have the courage and foresight to move C++ into the
future in these regards.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net (James Kuyper) wrote in message news:<8b42afac.0310221040.6b78eb46@posting.google.com>...

> However, incompatibilities
> for which there are good reasons are already numerous,

Can you give please give some examples for "good reasons"?
Are there good reasons that inline, bool, or clog are used differently
in both languages?

> and you should
> expect to see more in the future.

These are bad news. If there are good reasons that incompatibilities
(i.e., C0x progams that are not valid C++0x programs) will increase,
reconciliation does not make sense.

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://www.jamesd.demon.co.uk/csc/faq.html                       ]

eldiener@earthlink.net ("Edward Diener") wrote in message news:<vzHlb.14538$Uz6.8529@newsread1.news.atl.earthlink.net>...

> I would very
> much like to see C++ move on in the future and throw off many of the C-like
> trappings in order to become a more regular, more orthogonal, and easier to
> use language.

Yes, but wouldn't C++ be "more regular and easier to use" when the
meaning of C elements is the same in both C and C++?

> Continued support of a number of retrograde syntax elements,
> which are part of C++'s C language roots, should be dropped and/or
> transformed into modern idioms as C++ evolves into its own language.

For example?

> Attempting to forever reconcile two different languages, despite the fact
> that both have a common root, is a mistake. Computer languages, like human
> languages, need to change for the better when a positive change is being
> made, and C++ needs to consider its future as a dynamic language and not its
> past as a fairly static procedural language.

As I understand, the "roadmap" for future evolution of C++ is to
incorporate major changes in the library only; the core language is
not supposed to change much in the future. Library additions usually
do not interfere much with C compatibilty.

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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Helmut Zeisel" <zei2003b@liwest.at> wrote in message
news:b0d00898.0310230057.58b1746@posting.google.com...

> kuyper@wizard.net (James Kuyper) wrote in message
news:<8b42afac.0310221040.6b78eb46@posting.google.com>...
>
> > However, incompatibilities
> > for which there are good reasons are already numerous,
>
> Can you give please give some examples for "good reasons"?
> Are there good reasons that inline, bool, or clog are used differently
> in both languages?

inline, yes.
bool, sorta yes but I don't think they're incompatible.
clog, a botch, but luckily not as bad as it looks.

P.J. Plauger
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://www.jamesd.demon.co.uk/csc/faq.html                       ]

zei2003b@liwest.at (Helmut Zeisel) writes:

| eldiener@earthlink.net ("Edward Diener") wrote in message news:<vzHlb.14538$Uz6.8529@newsread1.news.atl.earthlink.net>...
|
| > I would very
| > much like to see C++ move on in the future and throw off many of the C-like
| > trappings in order to become a more regular, more orthogonal, and easier to
| > use language.
|
| Yes, but wouldn't C++ be "more regular and easier to use" when the
| meaning of C elements is the same in both C and C++?

That would be true if the C "meanings of C elements" were regular and
easier to use.  For example, I doubt the validity of temporary objects
of class-type is easier to use in C++.  I would say the same for
variably modified types.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]