Francis Glassborow wrote:
[...]
> Sorry, but I do not. A compatible common core is fine but even that is
> extremely hard to achieve. Just take the small issue of conversion from
> void* is C++ going to allow automatic conversions from void* to T*, I
> sure hope not. OTOH how can C change the other way when it will break
> many millions of lines of C source code?

Easy. I think that NEW [consolidated] >>POSIX.1++<< should simply provide
something like 'Deprecated-C' ['Old-Really-BAD-C' would be OK as well]
*scoping* with an 'Old C' appendix [everything deprecated right from the
beginning] to facilitate coexistence [for the next 10-20 years only, I hope]
and *encourage migration* to a 'better C' subset/core of the future POSIX.1++
language and corresponding OS 'better than java' bindings. The pure C++ core
should probably be defined OPTIONAL just like almost all of 'OS' C [current]
and C++ [future] bindings [e.g. threads and signals in general, AIO, MS-IOCP-
like *effective*/system-controlled (w.r.t. concurrency level, I/O utilization,
whatever) thread-pooling, etc.].

regards,
alexander.

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

"Nate Hayes" <nhayes@sunfishstudio.com> wrote in message
news:uih2roebnea3eb@corp.supernews.com...

> I wonder if the focus of the C++ committe shouldn't just simply be: to
> simplify C++ (if possible) and remove many of the warts and quirks, e.g.,
> streamline the language while still preserving its best qualities.

That would be so nice, wouldn't it?

However, I'm afraid it's completely unrealistic. Doing that would break many
millions of lines of C++ code, and it's my impression that breaking
backwards-compatibility is a non-starter for customers of many of the
vendors who form a large constituency on the committee.

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

David Abrahams wrote:

> "Nate Hayes" <nhayes@sunfishstudio.com> wrote in message
> news:uih2roebnea3eb@corp.supernews.com...
>
>
>>I wonder if the focus of the C++ committe shouldn't just simply be: to
>>simplify C++ (if possible) and remove many of the warts and quirks, e.g.,
>>streamline the language while still preserving its best qualities.
>>
>
> That would be so nice, wouldn't it?
>
> However, I'm afraid it's completely unrealistic. Doing that would break many
> millions of lines of C++ code,


   That sweeping statement is overly broad.  I recommend changing
"would" to "might".  Carefully-crafted proposals (with accompanying
demonstrative implementation, say, in GNU C++ or eventually OpenWatcom)
could conceivably introduce new syntax which would not eliminate (nor
deprecate) old syntax and thus would improve newly-written C++ without
breaking any of the existing source code.

   There may very well be other reasons why to not enact such a strategy
(e.g., compiler vendors who do not want an even-more-complex grammar to
parse; a governing policy to add only libraries in C++0x, not go on an
expansive syntax evolution in the core language; a governing policy to
"merge" C and C++ into strict subset/superset relationship), but
condemning every conceivable wart-elimination proposal, every
conceivable quirk-reduction proposal, and every conceivable streamlining
proposal to 100%-certainly-without-exception "break many millions of
lines of C++ code" is incorrect.

   However, I do agree in spirit that many (carelessly-crafted)
proposals (proffered extemporaneously in a newsgroup) would in fact
"break many millions of lines of C++ code" and that "breaking
backwards-compatibility is a non-starter".  I do agree with the overall
message communicated by multiple members of WG21: put your time & money
where your mouth is by building out a working version of one's proposal
to force the originators of the proposal to work out all of the messy
details themselves, permitting the final product to be judged as a
whole, merits, demerits, cascading effects, and all.

   But this write-a-full-blown-demonstration strategy also has its
risks---bilaterally no less.  Obviously one risk is that WG21 would
reject the proposal even after seeing the demonstration implementation.
  But another risk is that despite rejection by WG21, the fully-blown
high-quality demonstration in an open source GNU C++ would be merged
into the GNU C++ mainline.  Conceivably open source projects such as GNU
C++ which port to a vast multitude of platforms need not remain limited
to a standard promulgated conventionally.  To some degree a
noncommercial open source community which supports a vast multitude of
platforms can act as its own de facto standards body.  Such an open
source community of like-minded inventors could pursue a superset of the
conventionally-promulgated standard.  Such a superset could become quite
popular due to its availability for free on a vast multitude of
platforms.  An open source compiler which ports to a vast multitude of
platforms could take on a mind of its own, conveying (one community's)
current thinking about on-going language evolution.  Even if the GNU C++
mainline did not admit this evolutionary work into its mainline, some
rogue fork of GNU C++ (or eventually OpenWatcom) could start having a
mind of its own, acting as its own de facto standards body of a
post-C++/evolved-C++ language.  One microscopic example of this
mind-of-its-own potential appears to be the reported premature inclusion
of C99's restricted keyword into GNU C++.  (I have not actually used the
restricted keyword in the latest releases of GNU C++ myself, but have
read that the restricted keyword is successfully parsed in C++ code.)

> and it's my impression that breaking
> backwards-compatibility is a non-starter for customers of many of the
> vendors who form a large constituency on the committee.

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

"Daniel Miller" <daniel.miller@tellabs.com> wrote in message
news:3D29EC89.2080003@tellabs.com...
> David Abrahams wrote:
>
> > "Nate Hayes" <nhayes@sunfishstudio.com> wrote in message
> > news:uih2roebnea3eb@corp.supernews.com...
> >
> >
> >>I wonder if the focus of the C++ committe shouldn't just simply be: to
> >>simplify C++ (if possible) and remove many of the warts and quirks,
e.g.,
> >>streamline the language while still preserving its best qualities.
> >>
> >
> > That would be so nice, wouldn't it?
> >
> > However, I'm afraid it's completely unrealistic. Doing that would break
many
> > millions of lines of C++ code,
>
>
>    That sweeping statement is overly broad.  I recommend changing
> "would" to "might".

Happy to, except that...

> Carefully-crafted proposals (with accompanying
> demonstrative implementation, say, in GNU C++ or eventually OpenWatcom)
> could conceivably introduce new syntax which would not eliminate (nor
> deprecate) old syntax and thus would improve newly-written C++ without
> breaking any of the existing source code.

...the OP was talking about *removing* warts and quirks. Generally speaking,
if there's a wart, someone is relying on it. You can't take these things out
without breaking that person's code.

>    There may very well be other reasons why to not enact such a strategy
> (e.g., compiler vendors who do not want an even-more-complex grammar to
> parse; a governing policy to add only libraries in C++0x, not go on an
> expansive syntax evolution in the core language; a governing policy to
> "merge" C and C++ into strict subset/superset relationship), but
> condemning every conceivable wart-elimination proposal, every
> conceivable quirk-reduction proposal, and every conceivable streamlining
> proposal to 100%-certainly-without-exception "break many millions of
> lines of C++ code" is incorrect.

You're probably right. However, from my standpoint the prospects for
cleaning up the really treacherous stuff still look rather bleak. Take for
example the way dependent and non-dependent name lookup works in templates.
Who explicitly qualifies all function calls which might otherwise mistakenly
invoke argument-dependent lookup from within a template? Who never
forgets?Who takes pains to ensure that all overloads that should participate
in overload resolution in a qualified call from a template are visible at
the point of the template's *definition*? These are the sort of problems
which bite library writers after their code is delivered, and which
compilers can do little to help us detect. Fixing the problems require major
changes to the language semantics -- just the sort of change which causes
some code to stop compiling, or worse, to silently change its meaning.

>    However, I do agree in spirit that many (carelessly-crafted)
> proposals (proffered extemporaneously in a newsgroup) would in fact
> "break many millions of lines of C++ code" and that "breaking
> backwards-compatibility is a non-starter".  I do agree with the overall
> message communicated by multiple members of WG21: put your time & money
> where your mouth is by building out a working version of one's proposal
> to force the originators of the proposal to work out all of the messy
> details themselves, permitting the final product to be judged as a
> whole, merits, demerits, cascading effects, and all.

I wasn't talking about careless proposals. Sometimes if you want to fix
something, you have to break code, carefully or otherwise. I'm afraid that
it won't be politically possible to break enough code to fix any real
problems.

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

Nate Hayes wrote:

> I know several hard-core C programmers. They use C for algorithm development
> that usually runs in embedded systems. While this is not my area of
> interest, I see the elegance of using "plain old C" for this kind of work,
> and I respect the argument of people who claim that C has a right to exist
> on its own terms.

So many people fail to recognize the difference between C and C++.  C
was developed as a substitute for assembly and to be used for embedded
and small system programming. C++ was developed as an evolution to
successfully and safely handle large amounts of data.  The two are
intended to handle completely different problems.

A great deal of misgiving arises when someone designs and programs a
small system with C++ and is stunned at the difference in size with
comparable C code.  This ususally gives rise to C++ bashing.

I would suggest that if merging of the two languages is a goal -- indeed
some people presume compatibility is a given (to their surprise) -- that
the issue of code size expectation be addressed.

For what it's worth,

Jeff Klopotic

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

JMK wrote:
>
> Nate Hayes wrote:
>
>
>>I know several hard-core C programmers. They use C for algorithm development
>>that usually runs in embedded systems. While this is not my area of
>>interest, I see the elegance of using "plain old C" for this kind of work,
>>and I respect the argument of people who claim that C has a right to exist
>>on its own terms.
>
>
> So many people fail to recognize the difference between C and C++.  C
> was developed as a substitute for assembly and to be used for embedded
> and small system programming. C++ was developed as an evolution to
> successfully and safely handle large amounts of data.  The two are
> intended to handle completely different problems.
>
> A great deal of misgiving arises when someone designs and programs a
> small system with C++ and is stunned at the difference in size with
> comparable C code.

As is fair; there's no reason to accept it, unless their
C++ is bad.

> This ususally gives rise to C++ bashing.

When it should lead to (a) complaining to the vendor of
their compiler that its code generation is bad, or (b)
educating the programmer about how to make efficient use
of C++.

>
> I would suggest that if merging of the two languages is a goal -- indeed
> some people presume compatibility is a given (to their surprise) -- that
> the issue of code size expectation be addressed.

Luckily the issue of code size has been carefully
address all the way through C++'s development, and
care has been taken to ensure that C code, when compiled
with a C++ compiler, has no reason to be larger than when
it is compiled with a C compiler.  C++ adds no essential
overhead to features already present in C.

Now that C++ has a stable standard, C++ compiler vendors
are likely to be able to wind down their work on just
getting a working, "sufficiently standard" C++ compiler
and deal with issues of code generation including code
size.  Similarly C++ library vendors are likely in the
coming years to spend less time producing conforming
libraries, as that work is mostly done, and more time
increasing the performance and friendliness of their
libraries.  C++ is largely a world where performance
still matters.

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

> Much more fundamental: assuming that the objective is desirable (I
> remain unconvinced) how do you persuade the pure C programmer that
> changes should be made to C to make it compatible with C++ (because you
> know it will not be the other way round :-)

Indeed!

That remains a tough question. Stroustroup I think makes some good arguments
about the coherence of the C/C++ community. However, I don't know that its
really compelling for the types of C programmers that you mention.

Perhaps the most persuasive argument for the C community is the idea of
better compilers and tools, e.g. if C and C++ are merged into compatible
subsets, this allows compiler implementors to focus more on supporting the
language than supporting portability issues. I really liked Stroustroup's
Venn diagram of the "nightmare scenario". The thought of that reality does
indeed send shivers down *my* spine, as well.

Francis, can you elaborate on some reasons why you remain unconvinced that
compatibility is a desireable objective? I'd like to hear more about that
point of view.

Sincerley,

Nate Hayes



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

In article <uibv10ma34974f@corp.supernews.com>, Nate Hayes
<nhayes@sunfishstudio.com> writes
>Francis, can you elaborate on some reasons why you remain unconvinced that
>compatibility is a desireable objective? I'd like to hear more about that
>point of view.

When you have sat on both sides of the fence as I have (while
representing the UK at  ISO meetings) you come to realise that there
really are some pretty fundamental differences in design philosophy
between the two languages. I really do not want to argue the case here
because such argument too often rapidly deteriorates into strongly
expressed opinions.

However you mentioned in the part I snipped that having C++ as a
superset of C leads to better compilation tools. I would strongly argue
the contrary. If all I need is C, then paying the development costs for
a complete C++ implementation makes little sense. In addition there is
much more complexity in a C++ compiler with the consequential room for
bugs.

IMHO in supporting a wider range of paradigms C++ becomes less
appropriate where I only want small scale procedural programming. When I
also need special extensions (e.g. for 8051 programming) these are much
more likely to be commercially viable in an extended C compiler rather
than a C++ one.

If C++ can really provide all that procedural programmers working on
small specialised embedded systems then C will quietly die. Trying to
straight-jacket either language with the requirements of the other is,
IMHO, a serious mistake. While I have a deep respect for Bjarne I think
he is mistaken in his views with regard to C and C++. Remember that it
was his original choice to keep C++ close to (but not exactly a superset
of) C. There were excellent political reasons for doing that. However
the C programming community never asked for compatibility and I do not
think that the C++ community is justified in demanding that C stay close
to C++.

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

> If C++ can really provide all that procedural programmers working on
> small specialised embedded systems then C will quietly die. Trying to
> straight-jacket either language with the requirements of the other is,
> IMHO, a serious mistake. While I have a deep respect for Bjarne I think
> he is mistaken in his views with regard to C and C++. Remember that it
> was his original choice to keep C++ close to (but not exactly a superset
> of) C. There were excellent political reasons for doing that. However
> the C programming community never asked for compatibility and I do not
> think that the C++ community is justified in demanding that C stay close
> to C++.

I think I'm starting to see how complicated this issue really is.

I can also understand why you could suggest compatibility is not a
desireable goal. If one takes that position, then, what should the "vision"
of the next C++ standard look like? In other words, if compatibility is not
a priority, what are the issues that you see as being important?

Bjarne has outlined his vision and reasons. I think I understand the reasons
that you make in counter-point, but I'm unclear as to what your vision of
the future of the C++ language should then be. For example, does it include
deprecating existing quirks in the language that are due to historical
compatibility issues with C?

Sincerely,

Nate Hayes





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

In article <uicagvqopdv60f@corp.supernews.com>, Nate Hayes
<nhayes@sunfishstudio.com> writes
>Bjarne has outlined his vision and reasons. I think I understand the reasons
>that you make in counter-point, but I'm unclear as to what your vision of
>the future of the C++ language should then be. For example, does it include
>deprecating existing quirks in the language that are due to historical
>compatibility issues with C?

As for the next C++ standard, I am very close to Bjarne's vision and am
very happy to work with him. I even work quite hard at persuading all
concerned to avoid gratuitous incompatibilities and trying to ensure
that it is possible to write code in a form that compiles both as c and
C++ (quite important for some aspects of library development). Making
C++ more teachable by removing warts, adding support for library
development etc. is definitely on my agenda.

I just think we should keep it clear in our minds that compatibility
with C89/90 was a design requirement for C++, while compatibility with
C++ was never a design requirement for C99, though we did try to avoid
causing problems. It is worth noting that there are very few people who
understand the whole of the C++ core while there are many who understand
the C core (i.e. sans library specs.)  This means that it is relatively
easy for C++ designers to consider C compatibility and extremely hard
for C to consider C++ compatibility.


There is also another aspect of this in that those who want facilities
to support their hardware requirements (such as saturated and fixed
point arithmetic types for DSPs) will seek these in C because there is
less baggage to understand. If you are going to add such support in a
language core (rather than through pure library additions) C is
definitely a better place to try it.  Then the problem is that C++ would
not do it that way (consider how complex number support is implemented
in C and C++)



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

>In article <ui9vd76i0i157b@corp.supernews.com>, Nate Hayes
><nhayes@sunfishstudio.com> writes
>>So the problem seems to then be: how do you "remove" incompatibility between
>>C and C++, or, even, how do you merge these two languages into formal
>>subsets of one common language? That seems like it could potentially break
>>as much existing code as just starting over from scratch. I guess I'm
>>anxious to see what ideas people might have to accomplish this.

See Bjarne's third article in the September CUJ. He will go through several
specific cases and suggest several alternatives for each.

On Fri,  5 Jul 2002 18:03:59 GMT, Francis Glassborow
<francis.glassborow@ntlworld.com> wrote:
>Much more fundamental: assuming that the objective is desirable (I
>remain unconvinced)

Personally, I'm convinced it's desirable, for the reasons Bjarne gives in
his August CUJ article.

>                    how do you persuade the pure C programmer that
>changes should be made to C to make it compatible with C++ (because you
>know it will not be the other way round :-)

Now, now, don't be dismissive. :-) It's not safe to write it off that
quickly -- not least because, in the first three or four examples Bjarne
will give in September, he recommends that C++ change, not C. He includes
one case where, if there were no prior history, the clear choice would
probably be to use the C++ syntax for its elegance, but for backward
compatibility in both languages Bjarne volunteers that it would be best for
C++ to change...

In particular, Bjarne notes in that forthcoming article that there are quite
a few changes to C++ that he would strongly oppose as separate changes on
their individual merits because they arguably compromise C++ in some way,
but that he would happily support as part of a package for C compatibility
(if the C and C++ committees were to agree to work toward full/better
compatibility and both were willing to give and take). I agree with him, so
that's at least two of us so far... what about you, Francis? You're on both
WG14 and WG21. :-)

Some would go so far as to say that C/C++ compatibility is the most
important issue facing both languages' committees at this point.

Herb

---
Herb Sutter (www.gotw.ca)

Secretary, ISO WG21/ANSI J16 (C++) standards committee   (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal                 (www.gotw.ca/cuj)
C++ community program manager, Microsoft           (www.gotw.ca/microsoft)

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

Francis Glassborow wrote:

> It is worth noting that there are very few people who
> understand the whole of the C++ core while there are many who understand
> the C core (i.e. sans library specs.)


    I see this as a problem with the basic design of the
language.  It's just too big.


 John Nagle
     Animats

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

In article <fccfiuoq5qbf31oc3t315pra9f73rdsbc9@4ax.com>, Herb Sutter
<hsutter@gotw.ca> writes
>In particular, Bjarne notes in that forthcoming article that there are quite
>a few changes to C++ that he would strongly oppose as separate changes on
>their individual merits because they arguably compromise C++ in some way,
>but that he would happily support as part of a package for C compatibility
>(if the C and C++ committees were to agree to work toward full/better
>compatibility and both were willing to give and take). I agree with him, so
>that's at least two of us so far... what about you, Francis? You're on both
>WG14 and WG21. :-)

Sorry, but I do not. A compatible common core is fine but even that is
extremely hard to achieve. Just take the small issue of conversion from
void* is C++ going to allow automatic conversions from void* to T*, I
sure hope not. OTOH how can C change the other way when it will break
many millions of lines of C source code?

Yes, I do serve on both WG14 and WG21 which is exactly why I understand
that the design objectives of the languages are different.

IMO most programmers who claim to work in C/C++ (whatever that might be)
actually mean they use C++ and sometimes write in a procedural style.
Sometimes they would like to use libraries written for C, but how is
this different from those working in numerics who would sometimes like
to use libraries written in Fortran?

I think the design of C++ has been compromised enough by C compatibility
issues. I really think we have already gone too far down the road of
compromise and it is time to unshackle the languages. Where either makes
changes that impact on the common core (well almost) provided by C89
then both have issues with legacy code (their own as well as the others)
and these should be looked at very carefully by both sides.

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

> Yes, I do serve on both WG14 and WG21 which is exactly why I understand
> that the design objectives of the languages are different.

Francis, please forgive my ignorance. I'm assuming that WG14 and WG21
represent the C and C++ committies, right? In other words, you're currently
involved in the defining both C0x and C++0x?

> I think the design of C++ has been compromised enough by C compatibility
> issues. I really think we have already gone too far down the road of
> compromise and it is time to unshackle the languages. Where either makes
> changes that impact on the common core (well almost) provided by C89
> then both have issues with legacy code (their own as well as the others)
> and these should be looked at very carefully by both sides.

I guess this is the gut feeling I've had for a while, and it is the feeling
that motivated me to start this thread by suggesting a new language that
wasn't burdened by the warts and quirks of C++. I just haven't heard it
expressed so succinctly before.

I am a computer scientist, and I have very good analytical skills and can
understand things that can be explained logically, like the history of some
of C++'s more undesireable quirks and blemishes. But I also come from a
strong visual arts background and so programming to me is also a form of art
that has certain intangible and aesthetic qualities. The pragmatic side of
me understands Bjarne's arguments and can agree with them. The artistic side
of me, though, can't stand some of the quirky, ugly tidbits scattered
throughout C++, and this part of me just wants to see C++ become a truly
simple and elegant language (more so than it is already), regardless of the
costs!

Of course, I have to temper those kinds of intangible and pssionate feelings
with good common sense, and I'm still not sure at this point what the most
reasonable solution is. But this does seem to be a very important issue that
is going to change the way I (and others) program in the future. Hopefully,
the change, whatever it is, will be for the better and not the worse.

Nate



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

> IMO most programmers who claim to work in C/C++ (whatever that might be)
> actually mean they use C++ and sometimes write in a procedural style.

I just had another thought regarding this. I have been programming C++ for
about 10 years. I remember when I first started, and my usage of C++ was
basically as "a better C", e.g., my use of language features such as virtual
methods, inheritance, encapsulation, exception handling, etc. were
extreemely limited. My programming style at this time could best be
described as "procedural programming using classes".

Of course, over the years I grew more sophisticated both in my usage of the
language and also in my understanding of its true power. I learned how to
use design patterns and features of the language to actually solve very
difficult programming tasks and obstacles. As this change occurred, my
programming became less and less procedural. My code became more and more
losely coupled and defined by interfaces.

Now I work on industrial-strength programming applications that push the
language features to thier full potential, and even to thier limit
sometimes. I make the language work for me, instead of the way it was in the
beginning, when it was the other way around. I can use the features of the
language to design class libraries and hierarchies that contain hundreds,
even thousands of classes, while still remaining extensible, upgradeable,
and maintainable.

When I see my embedded C program coworkers and the code they write and work
on, its just a foreign world to me. It is a world that is soo small and self
contained. The parameters are so well known and so well defined. They spend
weeks tweaking algorithms to shave milliseconds off thier computational
time.

I guess because of working in this kind of evironment for so long, I have
developed the impression that C++ and C really are fundamentally different
languages developed specifically for different kinds of programming tasks.
When I look at the types of programming I've done over the past 5 years, I
don't see how C compatibility has helped me, because as I learn how to use
C++ to its full potential, the natural tendency is to use the C++-only
features of the language and so all C-compatible idioms are lost and not
used.

Of course, the punchline to this story is that we do actually have to
integrate the code written by the embedded C programmers into our system. So
we generally include all thier header files into a single namespace and
compile it as a static link lib. So this is the one way that C/C++
compatibility has made my life easier, I guess. But as long as there is a
way to create an interface file between the two languages, the rest could be
completely different, as far as I'm concerned, and it wouldn't affect any of
the code or systems that I've worked on or developed over the last several
years.

I realize this is probably not the case for everyone, though. But my only
point was that as a programmer continues to adopt the paradigm and power of
true object-oriented programming, it seems that using C idioms is less and
less beneficial. It seems that the only useful level of compatibility is to
allow an interface file to be defined that can allow a C++ program to make
function calls into a compiled C library. It doesn't seem that anything else
about the languages really would need to be similar for a scenario like
this.

Nate



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

> (if the C and C++ committees were to agree to work toward full/better
> compatibility and both were willing to give and take).

Herb, it's clear to me why C++ users would be worried about compatibility
with C, but what motivation do you think the C users will have to give in a
situation of give and take? In other words, I'm just thinking that because C
is a subset of C++, the C community doesn't really care about the superset,
or that they would want to invest the time and expertise in trying to remain
compatible with C++. Of course, I really don't know that this is true, it's
just an impression I have. If you don't think this is true, I'd like to
understand why.

> Some would go so far as to say that C/C++ compatibility is the most
> important issue facing both languages' committees at this point.

I wonder if the focus of the C++ committe shouldn't just simply be: to
simplify C++ (if possible) and remove many of the warts and quirks, e.g.,
streamline the language while still preserving its best qualities.

If it happens to be that compatibility is something we can get out of that
process, then I could see that as a terrific benefit. But I guess I still
question and/or am unclear about why compatibility with C should be the
highest priority, especially if both C++ and C are making changes that break
compatibility with C89 anyways. Can you give other examples of why you think
this is such a desireable goal?

Nate


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

mackrune wrote:
>
>
> Do you know if VLAs are ever going to be in the C++ standard? Are there any
> plans for this?
>

There are no present plans one way or the other. Haven't gotten to it
yet.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

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

On Tue,  2 Jul 2002 15:44:34 GMT, "Nate Hayes" <nhayes@sunfishstudio.com>
>I sometimes wonder, though, if its a good idea to try and improve the
>language while at the same time remaining compatible with ANSI C.

>C99 adds many new features that break compatibility with the current C++
>standard. Many of these new C99 features may also be difficult to add to
>C++. It seems that C99 and C++ are drifting apart, and I wonder about how
>practical and prudent it really is to continue trying to keep these two
>languages married together.

>I wonder sometimes if it isn't time for the C++ community to make a clean
>break. Is it time for us to control our own destiny and define a language

Be sure to read Bjarne Stroustrup's trio of articles on exactly this
question that (will) appear in the July, August, and September issues of
C/C++ Users Journal. The July issue is already available, and the others are
coming. And I believe other authors will be writing followup feature
articles in other issues later this year to weigh in with their own takes.

>Instead of a new version of C++ (C++0x), perhaps its worth considering the
>merits of a new language. This new language would be based on ANSI C++, but
>would be slightly different in the sense that it would be free and clean of
>the quirks and limitations caused by ANSI C compatibility. It would be the
>"pure C++" that you and I (and probably Stroustroup) have always dreamed
>about but were never able to have: Imagine not just a "better C", but
>instead a "pure C++".
>
>It would be a dream come true.

It would also be greatly incompatible with C++, for the C legacy is (for
better or worse) inextricably entwined with C++ syntax. To make a clean
break with C roots, you'd almost certainly break every C++ program that
exists today just by "fixing" the C declaration syntax, for example. Never
mind #include vs. a module system, the C stdlib, and other severe breaking
changes.

There's no reason not to pursue a new language. That idea always has merit.
But I'm just pointing out that, even if you try to make it like C++, trying
to jettison the C baggage will immediately diverge it so far from C++ syntax
that Java and C# will start looking like C++'s identical twins in
comparison. (Remember that certain other languages began exactly as you
suggest, and ended up keeping the worst of the C legacy anyway, such as the
declaration syntax.)

Herb

---
Herb Sutter (www.gotw.ca)

Secretary, ISO WG21/ANSI J16 (C++) standards committee   (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal                 (www.gotw.ca/cuj)
C++ community program manager, Microsoft           (www.gotw.ca/microsoft)

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

"Nate Hayes" <nhayes@sunfishstudio.com> wrote
> I love C++. I've been programming C++ for over 10 years.
>
> I sometimes wonder, though, if its a good idea to try and improve the
> language while at the same time remaining compatible with ANSI C. But I
> realize if this isn't the case, we're into the realm of a whole new
> language.

When C++ was first created, compatibility with C was one of the major
design concerns.

Today, one of the major design concerns is compatibility with C++98.
You might argue that we should do something about
    Class2 a(3,5); // Creates an instance of Class2
    Class1 b(2);   // Creates an instance of Class1
    Class0 c();    // Declares a function!
...but if we change the language rules to fix this "problem," we also
break millions (billions?) of lines of code!

In addition, a less important (but not insignificant) goal of C++ has
been, "no GRATUITIOUS incompatibility with C" (emphasis mine). To say
this another way -- the next C++ might not intentionally support every
new C99 feature, but it's not intentionally going to create new
identifiers or syntax rules specifically intended to break C code,
either. That's as it should be. After all, C and C++ *do* have a lot
in common right now. You wouldn't try to distribute a single "header"
file that works with both BASIC and FORTRAN, or COBOL and APL, but it's
very common for a single header file (especially for third-party
libraries) to work with both C and C++. Supporting this shouldn't be the
highest priority, but we shouldn't intentionally try to block it either.

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

On Wed, 3 Jul 2002 21:58:39 GMT
Herb Sutter <hsutter@gotw.ca> wrote:

> It would also be greatly incompatible with C++, for the C legacy is (for
> better or worse) inextricably entwined with C++ syntax. To make a clean
> break with C roots, you'd almost certainly break every C++ program that
> exists today just by "fixing" the C declaration syntax, for example.
Never

So introduce a new declaration declaration syntax in parallel with the old
one, such as the one described by Stroustrup in the D&E (p.46).

(There are potential issues with the new declaration syntax conflicting
with goto labels, but there are almost certainly ways around this).

- Julian

--
http://www.op59.net

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

> Be sure to read Bjarne Stroustrup's trio of articles on exactly this
> question that (will) appear in the July, August, and September issues of
> C/C++ Users Journal. The July issue is already available, and the others
are
> coming. And I believe other authors will be writing followup feature
> articles in other issues later this year to weigh in with their own takes.

As usual, Stroustrup has a very cogent and lucid perspective on this whole
issue. So much so that I find myself convinced -- if not even emotionally
comforted -- that his vision of a strictly compatible C as a subset of C++
is really an ideal solution. He does admit, though, that this vision will
require removing incompatibilities and that:

"we are now at a stage in the development of C and C++ where the
long-standing semi-official C++ policy of "as close to C as possible, but no
closer" could become a policy of full compatibility"

Formalizing the semi-official compatibility policy to strict compatiblity
seems attractive to me. Perhaps even to the point where the core C and C++
languages are simply "Section 1" and "Section 2" of the same standard or
language.

But this goal, while visionary and altruistic, also seems rather lofty and
frought with peril: how do you "remove" incompatibilites from an existing
stanadard? That part I don't clearly understand, and would hope to see
elaborated upon.

I know several hard-core C programmers. They use C for algorithm development
that usually runs in embedded systems. While this is not my area of
interest, I see the elegance of using "plain old C" for this kind of work,
and I respect the argument of people who claim that C has a right to exist
on its own terms.

So the problem seems to then be: how do you "remove" incompatibility between
C and C++, or, even, how do you merge these two languages into formal
subsets of one common language? That seems like it could potentially break
as much existing code as just starting over from scratch. I guess I'm
anxious to see what ideas people might have to accomplish this.

Sincerely,

Nate



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

In article <ui9vd76i0i157b@corp.supernews.com>, Nate Hayes
<nhayes@sunfishstudio.com> writes
>So the problem seems to then be: how do you "remove" incompatibility between
>C and C++, or, even, how do you merge these two languages into formal
>subsets of one common language? That seems like it could potentially break
>as much existing code as just starting over from scratch. I guess I'm
>anxious to see what ideas people might have to accomplish this.

Much more fundamental: assuming that the objective is desirable (I
remain unconvinced) how do you persuade the pure C programmer that
changes should be made to C to make it compatible with C++ (because you
know it will not be the other way round :-)


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

I love C++. I've been programming C++ for over 10 years.

I sometimes wonder, though, if its a good idea to try and improve the
language while at the same time remaining compatible with ANSI C. But I
realize if this isn't the case, we're into the realm of a whole new
language.

But would that really be a bad thing? I mean, C++ is now a standard, and it
will forever provide an object-oriented platform that provides compatibility
with older C programs. The current C++ standard will always be there for
legacy systems built around C and C++. But what about new software systems
being designed now and in the future? What about new systems that don't
require legacy compatibility? Should they be required to bear the burden of
the past when they have nothing to gain by such legacy compatibility?

C99 adds many new features that break compatibility with the current C++
standard. Many of these new C99 features may also be difficult to add to
C++. It seems that C99 and C++ are drifting apart, and I wonder about how
practical and prudent it really is to continue trying to keep these two
languages married together. Is there really going to be any real value in
continuing to pursue that goal? Will the C++ language just become more and
more convoluted and complicated? Is C++ as a "compromised" language the most
that it will ever have hopes of aspiring to?

And even if C++ doesn't continue to support the evolving C standards, should
future software developments forever then be forced to bear the burden of
the past?

I wonder sometimes if it isn't time for the C++ community to make a clean
break. Is it time for us to control our own destiny and define a language
that works the way we want it to? Without having to compromise for legacy
issues and compatibility with other languages that are drifting further and
further away from our language?

Instead of a new version of C++ (C++0x), perhaps its worth considering the
merits of a new language. This new language would be based on ANSI C++, but
would be slightly different in the sense that it would be free and clean of
the quirks and limitations caused by ANSI C compatibility. It would be the
"pure C++" that you and I (and probably Stroustroup) have always dreamed
about but were never able to have: Imagine not just a "better C", but
instead a "pure C++".

It would be a dream come true.

Sincerely,

Nate Hayes



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

Nate Hayes wrote:
>
> C99 adds many new features that break compatibility with the current C++
> standard. Many of these new C99 features may also be difficult to add to
> C++.

Very few of them are difficult to add to C++.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

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

Nate Hayes wrote:
> Instead of a new version of C++ (C++0x), perhaps its worth considering the
> merits of a new language. It would be a dream come true.

Only if you make it so. As usual, you cannot wish such a language
into existence. If you want it to be, get to work desigining it,
and perhaps grab a copy of gcc and modify it to compile your new
version. Then you will have something concrete for people to
evaluate. AFtyer all, that's what Stroustrup did.

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

On Tue, 2 Jul 2002 20:00:09 UTC, Hyman Rosen <hyrosen@mail.com> wrote:

> Nate Hayes wrote:
> > Instead of a new version of C++ (C++0x), perhaps its worth considering the
> > merits of a new language. It would be a dream come true.
>
> Only if you make it so. As usual, you cannot wish such a language
> into existence. If you want it to be, get to work desigining it,
> and perhaps grab a copy of gcc and modify it to compile your new
> version. Then you will have something concrete for people to
> evaluate. AFtyer all, that's what Stroustrup did.
>
A new language would only likely succeed if it also came with a
working translator from C++ to itself on at least three platforms.

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


--
Remove zamboni to reply.
All the above is hearsay and the not quaranteed.

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

Pete Becker wrote:
|| Nate Hayes wrote:
|||
||| C99 adds many new features that break compatibility with the
||| current C++ standard. Many of these new C99 features may also be
||| difficult to add to C++.
||
|| Very few of them are difficult to add to C++.
||

Do you know if VLAs are ever going to be in the C++ standard? Are there any
plans for this?

mackrune


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