What is the future of C++?

[GTO]

I do not believe that C# is the future of C++. I also do not believe that
adding two thousand new library functions to the standard library is the
future of C++. But what is the future of C++? Is it as good as a programming
language can get?

Like so many of you, I programmed speech recognizers, image recognition
systems, a portion of a chess program, lots of numeric code using STL, and
tons of other applications in C++, (even firmware for time critical
applications). Since 1997, I never missed even one feature in the language.
The poor implementation of C++ in various compilers however was certainly
outermost painful.

Anyway, is there a way to improve C++? - I think it's the perfect
programming language for our current computer architectures. I am even
tempted to believe that future "enhancements" can only negatively impact the
beauty of this language. No?

Gregor

[Jonathan Turkanis]

GTO wrote:

I do not believe that C# is the future of C++.
I don't think anyone does. Some people think that C++ is on its last legs, with
languages like C# as the languages of the future, or that C++/CLI is the future
of C++.
I also do not believe
that adding two thousand new library functions to the standard
library is the future of C++.
There will be lots of new library functions in the next version of the standard,
largely from C99. You don't have to use them if you don't want to.

New C++ libraries are mostly centered around new class templates.
But what is the future of C++? Is it as
good as a programming language can get?

Like so many of you, I programmed speech recognizers, image
recognition systems, a portion of a chess program, lots of numeric
code using STL, and tons of other applications in C++, (even firmware
for time critical applications). Since 1997, I never missed even one
feature in the language. The poor implementation of C++ in various
compilers however was certainly outermost painful.

Anyway, is there a way to improve C++? - I think it's the perfect
programming language for our current computer architectures. I am even
tempted to believe that future "enhancements" can only negatively
impact the beauty of this language. No?
It's certainly refreshing to hear this point of view in a message with the
current subject line. I was expecting someone compaining that C++ had fallen
behind the times and was doomed to extinction.

You shouldn't fear that C++ will be made worse, since the standards committee is
very sensitive to backward compatibility. If you don't like new feartures, you
can ignore them for the most part.

However, in addition to lots of additions to the standard library, there are
many exciting possibility for the next version of C++, including move semantics,
a module system and threading.
Gregor

Jonathan

[Dietmar Kuehl]

GTO wrote:

Anyway, is there a way to improve C++? - I think it's the perfect
programming language for our current computer architectures. I am even tempted to believe that future "enhancements" can only negatively impact the beauty of this language. No?

You might want to discuss this in comp.std.c++ where many of the C++
committee members hang out: this is the crowd which moves C++ forward
(and it is open, i.e. everybody can participate essentially by joining
a national standardization body).

I don't think that C++ is perfect, although I think it is the best
choice currently available. You said you were using templates but
apparently you weren't implementing them: in the context of templates
the most dire needs I have found arise but there are others not related
to templates, too. From my perspective there is a set of important
areas
which need fixing (and which aren't library issues at all):

- Concurrency needs to be integrated into the language. Much of this
will
be in form of a library but some essential stuff like an overhaul of
the C++ memory model has to be done in the core language.
- Templates and meta programming need fixing. There are various issues
like template typedefs, something like "typeof" (I the current
direction goes under the name of "decl_type"), possibly concept
support,
more structured type capability detection, and a whole bunch of other
stuff.
- Type Information, both at compile time (again for the use in
templates)
and at run time (i.e. something akin to reflection).
- Move semantics allowing non-POD objects to be moved efficiently
between
locations (e.g. when returning an object or when resizing a
'std::vector').

This is just which immediately pops to my head when thinking about
necessary changes to C++. Other may think of other stuff and consider
it
more important (e.g. optional garbage collection rates high for many
people). There is a host of proposals being made (have a look at the
"papers" section at <http://www.open-std.org/jtc1/sc22/wg21/> to get an
overview) and more halfbaked ideas being circulated amoung committee
members. The proposals and ideas range from more or less minor fixes to
rather major changes.

In any case, the C++ committee is well aware that some change is needed
to keep C++ attractive. For example, with multi-processors or
hyperthreaded
CPUs becoming common in the mainstream market (I'd guess that the
average
desktop computer in a decade will have more than just one CPU) support
for
multi-threading is essential. The next revision of the standard is
scheduled
to become available sometime in this decade - and it is more likely
that it
is 2009 than anything earlier...
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[GTO]

Regarding "move semantics", I thought that C++ already supports some sort of
moving of "expensive" objects (see copy constructor etc.). But to further
optimize C++, it might come handy. Or should we not just leave it up to
optimizing compilers to do this kind of work?

Regarding "threading", do you mean support for multithreading (a la JAVA)?
If yes, I would rather not see this added to C++ since support for
multithreaded concepts are details of the system's architecture and not the
language. But maybe you were referring to something else.

Gregor
"Jonathan Turkanis" <te******@kangaroologic.com> wrote in message
news:34*************@individual.net...

GTO wrote:

I do not believe that C# is the future of C++.

I don't think anyone does. Some people think that C++ is on its last legs,
with
languages like C# as the languages of the future, or that C++/CLI is the
future
of C++.

I also do not believe
that adding two thousand new library functions to the standard
library is the future of C++.

There will be lots of new library functions in the next version of the
standard,
largely from C99. You don't have to use them if you don't want to.

New C++ libraries are mostly centered around new class templates.

But what is the future of C++? Is it as
good as a programming language can get?

Like so many of you, I programmed speech recognizers, image
recognition systems, a portion of a chess program, lots of numeric
code using STL, and tons of other applications in C++, (even firmware
for time critical applications). Since 1997, I never missed even one
feature in the language. The poor implementation of C++ in various
compilers however was certainly outermost painful.

Anyway, is there a way to improve C++? - I think it's the perfect
programming language for our current computer architectures. I am even
tempted to believe that future "enhancements" can only negatively
impact the beauty of this language. No?

It's certainly refreshing to hear this point of view in a message with the
current subject line. I was expecting someone compaining that C++ had
fallen
behind the times and was doomed to extinction.

You shouldn't fear that C++ will be made worse, since the standards
committee is
very sensitive to backward compatibility. If you don't like new feartures,
you
can ignore them for the most part.

However, in addition to lots of additions to the standard library, there
are
many exciting possibility for the next version of C++, including move
semantics,
a module system and threading.

Gregor

Jonathan

[GTO]

> members. The proposals and ideas range from more or less minor fixes to

rather major changes.

I have read some of the "proposed" additions to C++, but I would like to see
minor fixes rather than major changes. For me JAVA has become a rather bad
example of how to move a language into the future. But you are right, the
standard committee might try everything possible to keep C++ "attractive".
Hyperthreaded CPUs or at least multiple CPUs are certainly in every box
until 2009. But what about FPGA's instead of CPU's? Would it not be easier
to have on-the-fly C++ compiler generate FPGA code rather than always run
everything on general purpose switches? In this case, the improvements would
be more in the compiler architecture rather than in the language.

Gregor

[Dietmar Kuehl]

GTO wrote:

Regarding "move semantics", I thought that C++ already supports some sort of moving of "expensive" objects (see copy constructor etc.). But to further optimize C++, it might come handy. Or should we not just leave it up to optimizing compilers to do this kind of work?
Moving objects is not just a matter of optimization: some objects
cannot
be copied at all (e.g. streams) but it would be desirable to move them,
e.g. when returning them from a function. Also, it is desirable to have
guarantees about certain things rather than hoping all compilers your
system runs on implement a certain non-trivial optimization.
Regarding "threading", do you mean support for multithreading (a la JAVA)? If yes, I would rather not see this added to C++ since support for
multithreaded concepts are details of the system's architecture and not the language. But maybe you were referring to something else.

Some portions of multi-threading go beyond a system's architecture and
it is, again, necessary to have certain guarantees. Notably, it is
necessary to have guarantees about ordering read and write operations
relative to access of potentially shared resources, independent of the
underlying multi-threading architecture. For example, the compiler
shall
be prohibited to move read access before the statement acquiring a lock
(you might want to have a look at
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1738.pdf> for
a more thorough coverage; I'd hope for a more detailed discussion but
I'm not aware of any).
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Dietmar Kuehl]

GTO wrote:

members. The proposals and ideas range from more or less minor fixes to rather major changes.

I have read some of the "proposed" additions to C++, but I would like

to see minor fixes rather than major changes. For me JAVA has become a rather bad example of how to move a language into the future. But you are right, the standard committee might try everything possible to keep C++ "attractive". Hyperthreaded CPUs or at least multiple CPUs are certainly in every box until 2009. But what about FPGA's instead of CPU's? Would it not be easier to have on-the-fly C++ compiler generate FPGA code rather than always run everything on general purpose switches? In this case, the improvements would be more in the compiler architecture rather than in the language.

I'm not sufficiently familiar with FPGAs but if these support some form
of multi-threading, some form of multi-threading aware memory model
would
still be necessary (and if they don't, I don't think they can solve the
whole problem) - in addition to improvements to the compiler back-end.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Ioannis Vranos]

GTO wrote:

I do not believe that C# is the future of C++.

What has C# to do with C++?

I also do not believe that
adding two thousand new library functions to the standard library is the
future of C++. But what is the future of C++? Is it as good as a programming
language can get?

The future of C++ is to be one of the best practical programming
languages out there.

Anyway, is there a way to improve C++? - I think it's the perfect
programming language for our current computer architectures. I am even
tempted to believe that future "enhancements" can only negatively impact the
beauty of this language. No?

C++ will hopefully keep expanding by adopting new mainstream paradigms
and improving the existing supported ones.
Some library extensions will surely take place. For example check the
upcoming TR1:

http://www.open-std.org/jtc1/sc22/wg...al_report.html


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[EventHelix.com]

Microsoft has proposed C++/CLI. Among other things, it supports
a built-in garbage collector. It even supports STL as STL.NET.

Deepa
--
http://www.EventHelix.com/EventStudio
EventStudio 2.5 - Automate sequence diagram generation

[Dietmar Kuehl]

EventHelix.com wrote:

Microsoft has proposed C++/CLI. Among other things, it supports
a built-in garbage collector. It even supports STL as STL.NET.

Nope, Microsoft has not proposed this as approach to C++. Nor
would C++/CLI stand any reasonable chance of becoming the
C++ standard!

C++/CLI is Microsoft's attempt to make something roughly
resembling C++ operational on a system which tries hard to
avoid integration of C++. Sure, you can run C++ on that
system but it doesn't integrate into the "managed" part of
it.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Ufit]

"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message news:1105081564.329048@athnrd02...

GTO wrote:

I do not believe that C# is the future of C++.

What has C# to do with C++?

/\
Exactly what I was thinking.
IMHO C# = VB with small changes.
Let me brighten the case up this way - I was developing custom fast databases
and tried VB.NET then C# and the code was SO big and slow. Still needed more speed.
So I looked in C++ applications and rewrote one program from VB to VC++.
I was amazed - code was smaller maybe 4times, program faster 10times and customer
happy as hell.) Just my app wasn't so fat in graphics as was C# one.
I totaly left VB\C# practicing and chose C++ - the best language out there.
Greets

Uf

[Randy Yates]

"Ufit" <ko**************@NOpoczta.fm> writes:

"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message news:1105081564.329048@athnrd02...

GTO wrote:

I do not believe that C# is the future of C++.

What has C# to do with C++?

/\
Exactly what I was thinking.
IMHO C# = VB with small changes.
Let me brighten the case up this way - I was developing custom fast databases
and tried VB.NET then C# and the code was SO big and slow. Still needed more speed.
So I looked in C++ applications and rewrote one program from VB to VC++.
I was amazed - code was smaller maybe 4times, program faster 10times and customer
happy as hell.) Just my app wasn't so fat in graphics as was C# one.
I totaly left VB\C# practicing and chose C++ - the best language out there.

I can't really speak to the issue since I've not used C#, but it sure SEEMS like
C# is a bad solution in search of a self-imposed problem. I've heard it said C#
is C++ with built-in overflow checking - is that true?

I agree with the general sentiment, though - we don't need another language that
essentially adds little value to C++ - let's stick with what we've got and improve
it and/or the libraries available for it.
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
ra*********@sonyericsson.com, 919-472-1124

[Dietmar Kuehl]

Randy Yates wrote:

I agree with the general sentiment, though - we don't need another language that essentially adds little value to C++ - let's stick with what we've got and improve it and/or the libraries available for it.

The key reason I see for an entirely new language (probably created
with C++'s
mindset) is that C++ has acquired that much legacy that it is hard to
create
a C++ processor. As a result, there are few good C++ tools which help
in various
development settings (reverse engineering of code for documentation,
code analysis
for correctness, IDE navigation, code completion, etc.) and those which
exist are
often quite imperfect (e.g. they fail utterly if heavy template stuff
is used).
This lack of tools, including correct and fast compilers, is the major
problem of
C++. I don't think that it can be rectified while retaining the usual
amount of
backward compatibility.

I think that there will be a workable C++0x which is compatible with
the current
C++ in that current C++ is valid C++0x. However, evolution beyond this
step will
need to get rid of many aspects of C++ and loads of C++'s complexities.
I don't
think that we can simplify the language sufficiently without breaking
compatiblity.
However, simplification in various aspects is already necessary.

Some trends are also hard to ignore: newer languages typically run on
some form
of virtual machine. They typically support garbage collection which can
even be
a speed advantage e.g. in multi-threaded environments. ... and, of
course,
multi-threading support will be essentially with multi-processor or
hyper-threading machines becoming mainstream. C++ will have to change
to
accomodate future technology.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Randy Yates]

"Dietmar Kuehl" <di***********@yahoo.com> writes:

Randy Yates wrote:

I agree with the general sentiment, though - we don't need another

language that essentially adds little value to C++ - let's stick with what we've > got and improve it and/or the libraries
available for it.

The key reason I see for an entirely new language (probably created
with C++'s mindset) is that C++ has acquired that much legacy that
it is hard to create a C++ processor. As a result, there are few
good C++ tools which help in various development settings (reverse
engineering of code for documentation, code analysis for
correctness, IDE navigation, code completion, etc.)

xemacs foots two of those bills. Going to another language does not
implicitly guarantee either of the other two.
and those which
exist are often quite imperfect (e.g. they fail utterly if heavy
template stuff is used). This lack of tools, including correct and
fast compilers,
Huh? What's wrong with g++? It's certainly fast enough for me. If
I cranked out a few dozen lines of code per minute I might start
to think that compile time would be a signficant overhead, but
I don't.
is the major problem of C++. I don't think that it
can be rectified while retaining the usual amount of backward
compatibility.
I don't really even see the problem, so I don't see what needs to
be rectified.
I think that there will be a workable C++0x which is compatible with
the current C++ in that current C++ is valid C++0x.
What's "C++0x"?
However, evolution beyond this step will need to get rid of many
aspects of C++ and loads of C++'s complexities.
Why? Which ones?
I don't think that we can simplify the language sufficiently without
breaking compatiblity. However, simplification in various aspects
is already necessary.
Why do we need to simplify the language?
Some trends are also hard to ignore: newer languages typically run
on some form of virtual machine. They typically support garbage
collection which can even be a speed advantage e.g. in
multi-threaded environments. ... and, of course, multi-threading
support will be essentially with multi-processor or hyper-threading
machines becoming mainstream. C++ will have to change to accomodate
future technology. -- <mailto:di***********@yahoo.com>
<http://www.dietmar-kuehl.de/> <http://www.contendix.com> - Software
Development & Consulting

I'll see you in the marketplace.
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
ra*********@sonyericsson.com, 919-472-1124

[Dietmar Kuehl]

Randy Yates wrote:

"Dietmar Kuehl" <di***********@yahoo.com> writes:

The key reason I see for an entirely new language (probably created
with C++'s mindset) is that C++ has acquired that much legacy that
it is hard to create a C++ processor. As a result, there are few
good C++ tools which help in various development settings (reverse
engineering of code for documentation, code analysis for
correctness, IDE navigation, code completion, etc.)
xemacs foots two of those bills.

These must be IDE navigation and code completion. Actually, I doubt
that (x)emacs can do a perfect job on those two things and an
imperfect one does not really help: if you rely on code completion
and it does not provide you with appropriate template instantiations
or suppresses them in other contexts, it is somewhat unhelpful at
best. Likewise I doubt that (x) emacs is capable of navigating to
the appropriate [partial] specialization of a template. It surely
provides some help but it does not go all the way.
Going to another language does not implicitly guarantee either of
the other two.
We are in perfect agreement on this. However, a new language gives
the opportunity to add considerations like potential tool support
to the language design guidelines.

and those which
exist are often quite imperfect (e.g. they fail utterly if heavy
template stuff is used). This lack of tools, including correct and
fast compilers,

Huh? What's wrong with g++? It's certainly fast enough for me.

First of all, g++ is wrong in some cases and it does not support
standard C++. If you disagree, try to use the 'export' keyword.
Considering g++ speed, I think it is reasonable but I would prefer
it to be faster: I tend to run testsuites often and most of my
projects have bigger testsuites which take considerable amounts of
time. Compilation speed of g++ compared to e.g. VC++ is not really
favourable although this shows that C++ can be compiled faster than
what g++ does (but then, with other flows). Essentially, there is
still only one standard conforming C++ implementation: EDG's
front-end and just one compiler (AFAIK) which actually ships it
with the whole feature set (Comeau). However, this compiler is not
exactly fast either. Of course, other compilers (C, Java, C#, etc.)
don't have that much to do (e.g. no templates) but they are much
faster for comparable amounts of code.
If
I cranked out a few dozen lines of code per minute I might start
to think that compile time would be a signficant overhead, but
I don't.
You might think differently if most of your code were in testsuits
which get recompiled with each run.

is the major problem of C++. I don't think that it
can be rectified while retaining the usual amount of backward
compatibility.

I don't really even see the problem, so I don't see what needs to
be rectified.

The template mechanism is one of C++'s most powerful features but
it inherently broken: just have a look at all those funny ADL
discussions on comp.lang.c++.moderated or comp.std.c++. Correct
template support is pretty hard to get it right and except for
EDG's front-end nobody has made it (and even EDG's front-end seems
to be imperfect in some corner-cases).

I think that there will be a workable C++0x which is compatible with the current C++ in that current C++ is valid C++0x.

What's "C++0x"?

The working title for the next C++ standard: the committee is
working on the next C++ revision and plans to finish it in this
decade. Most likely, the "x" will eventually be replaced by "9".

However, evolution beyond this step will need to get rid of many
aspects of C++ and loads of C++'s complexities.

Why? Which ones?

Why? Because it is hard to get remember all issues even for C++
experts. Which ones? Well, the core language specification (i.e.
C++ without its standard library) takes roughly 250 pages. I'd
consider this to be more than most people can remember and I
actually doubt that there is anybody who does know all the details
without refering back to this document in all situations. This is
clearly too complex.

But don't get me wrong: I surely want to retain C++'s power. I
just want to get rid of all those special rules you need to
remember. It actually starts with the declaration syntax: it is
not really obvious that

| std::vector<int> vec(std::istream_iterator(in),
| std::isteram_iterator());

declares a function rather than defining an object, is it?
Why do we need to simplify the language?
Because it is too complex for both humans and machines!
I'll see you in the marketplace.

I have no trouble with that: I think I'm quite good at writing
C++ and C++ is clearly my preferred language. However, I also
see C++'s limitations and disadvantages, many of which are not
really necessary - once we accept certain changes.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Ioannis Vranos]

Randy Yates wrote:

I can't really speak to the issue since I've not used C#, but it sure SEEMS like
C# is a bad solution in search of a self-imposed problem. I've heard it said C#
is C++ with built-in overflow checking - is that true?

I agree with the general sentiment, though - we don't need another language that
essentially adds little value to C++ - let's stick with what we've got and improve
it and/or the libraries available for it.

C#/CLI which is its exact name, is just syntax (as C++/CLI) with few
binding descriptions with CLI (which is a standard of its own).
It doesn't provide anything more. However C# programmers (as well as VB
..NET programmers), think that all CLI (and .NET) is C#. That is, they
think the whole CLI/.NET library is C# (and VB respectively)!
They say for example, "System::String of C#, or System::StringBuilder
are far better than C++'s string", missing the fact that myself also use
System::String and System::StringBuilder in my own applications.
Also with C++/CLI, C++ becomes the systems programming language of .NET
with far more abilities than C#.
To name a few, templates together with generics, deterministic
destruction (stack semantics/delete), etc.
For example in the upcoming revision of CLI (.NET 2.0), in C#/CLI,
C++/CLI, and the rest languages it is not directly supported to pin ref
objects in the managed heap directly.
However in C++ you can cast a ref handle to some other value handle,
then use that handle to pin the object and then with another
reinterpret_cast casting to an unsigned char * and print out its
contents. :-)


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Dietmar Kuehl wrote:

Some trends are also hard to ignore: newer languages typically run on
some form
of virtual machine. They typically support garbage collection which can
even be
a speed advantage e.g. in multi-threaded environments.

Check C++/CLI.

... and, of
course,
multi-threading support will be essentially with multi-processor or
hyper-threading machines becoming mainstream. C++ will have to change
to
accomodate future technology.

Check OpenMP (supported in VC++ 2005 along with others).


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Dietmar Kuehl wrote:

Nope, Microsoft has not proposed this as approach to C++. Nor
would C++/CLI stand any reasonable chance of becoming the
C++ standard!

C++/CLI is a standard of C++ extensions that helps programmers to take
*full advantage* of a CLI environment (actually it is the *systems
programming language* of CLI (and .NET).

C++/CLI is Microsoft's attempt to make something roughly
resembling C++ operational on a system which tries hard to
avoid integration of C++. Sure, you can run C++ on that
system but it doesn't integrate into the "managed" part of
it.

You are completely wrong. With C++/CLI you can write fully verifiable
..NET programs with more facilities and possibilities available than C#.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[seguso]

GTO wrote:

I do not believe that C# is the future of C++. I also do not believe that
adding two thousand new library functions to the standard library is the
future of C++. But what is the future of C++? Is it as good as a
programming language can get?
Maybe adding higher-order functions, lambdas and type inference would make
C++ at least a bit more readable and bearable. If you really want to shine,
you could also add transparent backtracking a-la Prolog. Also, adding the
possibility to program in a pure functional style would make it faster (due
to static garbage collection) and less error prone.
Anyway, is there a way to improve C++? - I think it's the perfect
programming language for our current computer architectures.

I suppose you don't know Mercury, Clean, Haskell, OCaml, Prolog. How many
languages do you know?

--
Best Regards,
Maurizio Colucci --- http://onefinger.sf.net
Please remove the uppercase letters "S,P,A,M":
se****************@tin.it

[Walter]

"GTO" <gr******@NOSPAMyahoo.com> wrote in message
news:tP****************@newssvr21.news.prodigy.com ...

I do not believe that C# is the future of C++. I also do not believe that
adding two thousand new library functions to the standard library is the
future of C++.
I agree.
But what is the future of C++? Is it as good as a programming
language can get?
Not at all. C++ has evolved over decades, with new features evolving to fit
new ideas in how to write programs. Each feature was carefully grafted over
existing features to maintain backwards compatibility. As such, it resembles
a farm house that started out as a cabin, but as each successive family
owned it they added new rooms and repurposed existing ones, resulting in a
lot of odd compromises and weirdities.

Many of us have programmed in C++ for so many years that we no longer even
see what those compromises and weirdities are, we can drive around them in
our sleep. But they're still there, they still make the language hard to
learn, and make programming in C++ unnecessarilly tedious and error-prone.
(One small example is when tag names are sometimes in a separate name space,
and sometimes not. There's no reason for that nonsense other than backwards
compatibility, no sane language designer would design a new language that
way.)

C++ stands to gain a lot from being refactored, a process by which one looks
at what works and what doesn't, and engineers a new language to make what
works work in a straightforward, seemless manner.
Like so many of you, I programmed speech recognizers, image recognition
systems, a portion of a chess program, lots of numeric code using STL, and
tons of other applications in C++, (even firmware for time critical
applications). Since 1997, I never missed even one feature in the language. The poor implementation of C++ in various compilers however was certainly
outermost painful.
The "poor implementation" is usually a consequence of the complexity,
inconsistencies and weirdities of the language. It's unlikely that C++ has
just had the bad luck of having crummy compiler writers attracted to it <g>.
Anyway, is there a way to improve C++? - I think it's the perfect
programming language for our current computer architectures. I am even
tempted to believe that future "enhancements" can only negatively impact the beauty of this language. No?

Check out the D programming language for an example of how one can have the
efficiency and power of C++ without the endless complexity.

-Walter
www.digitalmars.com/d/ the D Programming Language
"code of the nerds"

[Walter]

"Dietmar Kuehl" <di***********@yahoo.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

Some trends are also hard to ignore: newer languages typically run on
some form
of virtual machine.

What's the practical difference between a new language targetting a portable
VM and a new language that has portable semantics? I can't think of one.
What a VM actually does is put the back end of the compiler on the
customer's remote machine. The "write once, run everywhere" is just as
achievable with a language that has portable semantics and putting the whole
compiler on the customer's machine.

[Ufit]

"Walter" <wa****@digitalmars.nospamm.com> wrote in message news:J7********************@comcast.com...

> But what is the future of C++? Is it as good as a programming

language can get?

Not at all. C++ has evolved over decades, with new features evolving to fit
new ideas in how to write programs. Each feature was carefully grafted over
existing features to maintain backwards compatibility. As such, it resembles
a farm house that started out as a cabin, but as each successive family
owned it they added new rooms and repurposed existing ones, resulting in a
lot of odd compromises and weirdities.

That's what is all about - backward compatibility and fast development.
Do you think the same 'farm thing' would not have happened to C# ?
Programming is an art and dealing with very complex issues is a gift.
IMHO thats why not everyone can be a programmer.
Of course languages like VB/C# are great for other things but today
machines are still not so fast and programmers need some power backup tool.
Those weirdities can be avoided if you program an application properly
and that as I see doesn't happen very often. Anyway C++ should definitely
not be abandoned but carefuly improved.

Uf

[GTO]

> I suppose you don't know Mercury, Clean, Haskell, OCaml, Prolog. How many

languages do you know?

Enough, I suppose. But why does it matter how much languages I know? How
many of them I really master is essential.

C++ is excellent and I think I picked up some good arguments for improving
this language from this thread and some of the URLs provided. Thank you.

I hope things will evolve slowly and I hope the standard is not driven by
what one single company would like to "standardize". I started to use .NET
1.1 and got a glimpse into their next incarnation. I still don't like it.
Interesting enough, when working at Bell Labs, I was just using C since
BLASR, our speaker independent speech recognizer, was written in C. After
several lectures by Andrew Koenig, I embraced C++. (I even remember some
occasions when Bjarne Stroustrup found time to visit us in this class. But
it was quite a while ago, 1995/1996.) So, I consider myself an early
adaptor, someone with a flare for new great inventions. But C# and C++/CLI
just seems not to spark my interest. But again, I have nothing against
Microsoft's new technologies, as long as they do not drive the C++ standard.

Gregor

[Phil Staite]

GTO wrote:

I do not believe that C# is the future of C++. I also do not believe that
IMHO C# shares little more than part of it's name with C++. IMHO C# is
more "proprietary Java" than anything else. Granted, Java shares a fair
amount of syntax with C++.
adding two thousand new library functions to the standard library is the
future of C++. But what is the future of C++? Is it as good as a programming
language can get?

No, bulking up the standard library for the sake of bulking it up
wouldn't make sense.

Some oddball wild-hair ideas of what could be done/added to C++???

A modular standard. As in a baseline, maybe a full workstation/server
spec, a minimalist embedded spec (stripped down lib)... ???

Add a threading library. (eg. similar to Posix?)

A means of expressing parallelism.

Both of the above will be important as multi-CPU machines become more
common. Heck, even Intel has their HT Pentiums. (typing this on one
running Fedora Core 2 now).

Similarly, maybe formalize a networking library since just about every
widget seems to have an ethernet port on it now...

Forget a new standard, kick compiler vendors in their collective
backsides to catch up and be compliant with today's standard! ;-)

Define an abstract C++ virtual machine, maybe even a byte-code or
"portable C++" spec to compile C++ into bytecode that could run on a
JVM. (ie. beat the Java-ites at their own game by making C++ portable,
not just at the source level.)

Fill-in some nice-to-haves in STL, but don't get crazy...

Maybe introduce "compilable interfaces" or virtual headers. Similar to
how Ada lets you compile a package's interface and implementation
seperately.

Anything to help vendors with tool integration. (editors, compilers,
linkers, debuggers, profilers...)

Don't get carried away though - keep the lean/mean "C and then some"
attitude. Virtual function overhead and exception handling state
machines are about all the extra baggage I want to have carried around...

[Ioannis Vranos]

Phil Staite wrote:

IMHO C# shares little more than part of it's name with C++. IMHO C# is
more "proprietary Java" than anything else. Granted, Java shares a fair
amount of syntax with C++.

Actually from a glimpse that I took in some C# code it looks like to me
like Pascal+VB in an OO-only style.

I think Java syntax resembles more to C++ than C#, which I think has not
any resemblance.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Walter]

"Ufit" <ko**************@NOpoczta.fm> wrote in message
news:cr**********@news.onet.pl...

"Walter" <wa****@digitalmars.nospamm.com> wrote in message news:J7********************@comcast.com...

> But what is the future of C++? Is it as good as a programming
language can get?

Not at all. C++ has evolved over decades, with new features evolving to fit new ideas in how to write programs. Each feature was carefully grafted over existing features to maintain backwards compatibility. As such, it resembles a farm house that started out as a cabin, but as each successive family
owned it they added new rooms and repurposed existing ones, resulting in a lot of odd compromises and weirdities.

That's what is all about - backward compatibility and fast development.

Backward compatibility is an issue for maintaining or extending existing
apps. It isn't an issue when starting a new app. I don't suggest it would be
profitable to convert existing C++ apps to D. There is another area where
backward compatibility is an issue - not so much for being able to compile
the legacy code, but to lower the learning curve for writing new code. D is
close enough to C++ that experienced C++ developers will have little
difficulty transferring their knowledge and expertise.

Fast development is a big issue. I would venture that C++ is not known for
fast development, it is more known for efficient execution of the compiled
program.
Do you think the same 'farm thing' would not have happened to C# ?
It will eventually happen to C#, and any successful language. Languages that
aren't being extended and improved are dead languages.
Programming is an art and dealing with very complex issues is a gift.
IMHO thats why not everyone can be a programmer.
Of course. But anything the language can do to help mitigate the complexity
is good for productivity and reduced bugs. A language, however, has a
problem if it can only be mastered by gifted programmers.
Of course languages like VB/C# are great for other things but today
machines are still not so fast and programmers need some power backup tool. Those weirdities can be avoided if you program an application properly
and that as I see doesn't happen very often.
We've all learned to deal with the potholes in C++, and many of us are so
used to dealing with them we've even forgotten that they're there! That
doesn't mean they still aren't costing us, however. One D programmer wrote
me, cursing (!) that after programming in D for a while, he couldn't go back
to C++. The potholes were suddenly visible to him.
Anyway C++ should definitely not be abandoned but carefuly improved.

C++ will continue to be supported and improved as long as programmers are
using it. For those looking for alternatives that offer equivalent
efficiency and power, but are much easier to use, there's D.

[Ioannis Vranos]

Walter wrote:

C++ will continue to be supported and improved as long as programmers are
using it. For those looking for alternatives that offer equivalent
efficiency and power, but are much easier to use, there's D.

At WinFX era, will there be an implementation of D supporting WinFX (CLI)?
Also has D a standard library of its own?
Also the comparison table is not technically correct.
C# has no garbage collection by itself for example. All languages in
..NET (CLI) have the same facilities available (while C++ with C++/CLI
has more, like 100% verifiable binaries while using templates, along
with generics of course).
So what is true for C# should also be true for C++ (and VB .NET, J#
..NET, Delphi .NET etc).
Also from that table I conclude that D itself is more like a framework
(like Java?). So for example how will it work under WinFX where there is
another GC and probably other constructs (the CLI constructs).
Two garbage collectors together?


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Walter]

"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message
news:1105160854.530562@athnrd02...

Walter wrote:

C++ will continue to be supported and improved as long as programmers are using it. For those looking for alternatives that offer equivalent
efficiency and power, but are much easier to use, there's D. At WinFX era, will there be an implementation of D supporting WinFX (CLI)?

There are people working on a CLI version of D.
Also has D a standard library of its own?
Yes.
Also the comparison table is not technically correct.
C# has no garbage collection by itself for example. All languages in
.NET (CLI) have the same facilities available (while C++ with C++/CLI
has more, like 100% verifiable binaries while using templates, along
with generics of course).
C#'s semantics rely on the existence of garbage collection. Whether it is
supplied by .net or by some other method is immaterial, it needs one.
Standard C++ neither needs one nor offers one (C++/CLI is not Standard C++).
Also from that table I conclude that D itself is more like a framework
(like Java?). So for example how will it work under WinFX where there is
another GC and probably other constructs (the CLI constructs).
Two garbage collectors together?

The garbage collector for D is provided by the runtime library. If that
runtime library is .net, then .net will be providing that service for D
programs. There needn't be two collectors.

[Dietmar Kuehl]

Ioannis Vranos wrote:

Dietmar Kuehl wrote:

Some trends are also hard to ignore: newer languages typically run on
some form
of virtual machine. They typically support garbage collection which can
even be
a speed advantage e.g. in multi-threaded environments.
Check C++/CLI.

I have done so and posted in the past that I consider it a seriously
broken approach on all accounts, i.e. apart from technical objections
I have raised I also dislike the approach how it is created and the
attitude (at least some) people involved in C++/CLI specification react
to constructive criticism. However, Microsoft is obviously successful
with their marketing strategy and managed to find vocal proponents
outside their organization. Since none I could not verify any of their
claims e.g. about C++/CLI portability (e.g. that it is possible to compile
code with VC++.Net and run it on Mono) but have to support multiple
environments I'm not one of the proponents.
Check OpenMP (supported in VC++ 2005 along with others).

E.g. support by Intel's compiler for Linux is more interesting to me...
Anyway, I haven't read through the whole document but it does not seem
to address all issues. Personally, I think that something like the
memory model present in
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1738.pdf> is
necessary to address the future needs. I don't think that OpenMP does
address this issue (this paper are just the slides of a presentation
Andrei gave at the previous committee meeting in Redmond; I'm not aware
of any article which provides more details information but I hope that
someone follows up with a more details in a written document).
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Dietmar Kuehl]

Walter wrote:

"Dietmar Kuehl" <di***********@yahoo.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

Some trends are also hard to ignore: newer languages typically run on
some form
of virtual machine.
What's the practical difference between a new language targetting a
portable VM and a new language that has portable semantics? I can't think
of one.

Note my careful wording of "some form of virtual machine": this is something
which executes something without the need of user interaction for installing
the software. How this is handled, i.e. what kind of abstraction is met by
the executable code is not restricted by that.
What a VM actually does is put the back end of the compiler on the
customer's remote machine. The "write once, run everywhere" is just as
achievable with a language that has portable semantics and putting the
whole compiler on the customer's machine.

Yes. The compiler plus the needed execution environment would then make up
the virtual machine. Actually, it is that way with some popular virtual
machines like the JVM or the CLR, although the language they execute is
not directly what the programmer writes but a transformation thereof.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Dietmar Kuehl]

Ioannis Vranos wrote:

Dietmar Kuehl wrote:

Nope, Microsoft has not proposed this as approach to C++. Nor
would C++/CLI stand any reasonable chance of becoming the
C++ standard!
C++/CLI is a standard of C++ extensions that helps programmers to take
*full advantage* of a CLI environment (actually it is the *systems
programming language* of CLI (and .NET).

C++/CLI is a blunt attempt to lure developers into an environment which
is non-portable. In particular, writing C++ code which interacts smoothly
with managed code (which is, after all the stated goal of the abominations
added to C++), like function templates, effectively forces you to write
code which makes heavy use of the C++/CLI extensions (notably, you need to
use the notation for managed references and pointers in function
declarations). Fair enough, C++/CLI is the best language for the CLI but
it is not C++ and it is at best hard to write code which possibly
interacts with managed features while also being usable on non-C++/CLI
platforms (and, IMO, the people involved in the C++/CLI specification made
it deliberately that way).

C++/CLI is Microsoft's attempt to make something roughly
resembling C++ operational on a system which tries hard to
avoid integration of C++. Sure, you can run C++ on that
system but it doesn't integrate into the "managed" part of
it.

You are completely wrong. With C++/CLI you can write fully verifiable
.NET programs with more facilities and possibilities available than C#.

Obviously, we disagree strongly in our assessments of C++/CLI, as I don't
think I'm wrong (and, BTW, don't claim I'm essentially ignorant of C++/CLI:
I read the specification and tested quite a few things with their beta
version).
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Ioannis Vranos]

Dietmar Kuehl wrote:

I have done so and posted in the past that I consider it a seriously
broken approach on all accounts, i.e. apart from technical objections
I have raised I also dislike the approach how it is created and the
attitude (at least some) people involved in C++/CLI specification react
to constructive criticism. However, Microsoft is obviously successful
with their marketing strategy and managed to find vocal proponents
outside their organization. Since none I could not verify any of their
claims e.g. about C++/CLI portability (e.g. that it is possible to compile
code with VC++.Net and run it on Mono)

I have done it myself with VC++ 2005 Express Beta 1 and Mono 1

(but C++/CLI is really for the upcoming CLI revision so I had to place a
..NET dll together with the exe, in order to run it under Mono in GNU/Linux).
However strictly speaking, binary portability can really be ensured only
for Console applications using the CLI defined facilities (that is few
facilities like System::String, System::Console, etc).

This applies both for C++/CLI and C#/CLI.
However Mono (and I guess DotGNU too) provides the same APIs (dlls) for
other things too, Windows Forms, GDI+, ADO .NET etc so a pure managed
(C++, C#, VB) binary using these APIs in .NET, can also run unchanged
under Mono in any OS.
Mono also provides other APIs of its own, like GTK#.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Dietmar Kuehl wrote:

C++/CLI is a blunt attempt to lure developers into an environment which
is non-portable.

If you want to. For example I use std::string in my programs and will
not change that unless I want to achieve binary portability, and that if
there is not a C++ compiler in a target CLI environment.
It is up to you if you want to use managed facilities or unmanaged
facilities or both. C++ is the only language that is in fact two worlds
in one. The unmanaged and the managed.

So you can continue sticking with source code portability only.
In particular, writing C++ code which interacts smoothly
with managed code (which is, after all the stated goal of the abominations
added to C++), like function templates, effectively forces you to write
code which makes heavy use of the C++/CLI extensions (notably, you need to
use the notation for managed references and pointers in function
declarations). Fair enough, C++/CLI is the best language for the CLI but
it is not C++ and it is at best hard to write code which possibly
interacts with managed features while also being usable on non-C++/CLI
platforms (and, IMO, the people involved in the C++/CLI specification made
it deliberately that way).

Well, you can consider CLI as a portable VM system extension (that is
another pillar of portable source/binary VM code vs system dependent VM
code).
That is, think of it as another option.
You can continue writing ISO C++ code, and aim at source code
portability only.
ISO C++ compiles and works under a CLI VM, where a C++ compiler is
available.

C++/CLI is Microsoft's attempt to make something roughly
resembling C++ operational on a system which tries hard to
avoid integration of C++. Sure, you can run C++ on that
system but it doesn't integrate into the "managed" part of
it.

You are completely wrong. With C++/CLI you can write fully verifiable
.NET programs with more facilities and possibilities available than C#.

Obviously, we disagree strongly in our assessments of C++/CLI, as I don't
think I'm wrong (and, BTW, don't claim I'm essentially ignorant of C++/CLI:
I read the specification and tested quite a few things with their beta
version).

To produce completely verified managed binaries (and binary portable to
other CLI environments when you use only the CLI specified facilities,
or the target CLI VM provides the additional APIs that you are using),
you have to use /clr:safe.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[EventHelix.com]

CLI itself is a standard. Mono and other CLI implementations
are already available for Linux and other platforms.

It is quite possible the CLI and C++/CLI might become
a cross platform architecture, quite independent of Microsoft.

Deepa
--
http://www.EventHelix.com/EventStudio
EventStudio 2.5 - Automate sequence diagram generation

[Julie]

GTO wrote:

I do not believe that C# is the future of C++. I also do not believe that
adding two thousand new library functions to the standard library is the
future of C++. But what is the future of C++? Is it as good as a programming
language can get?

Like so many of you, I programmed speech recognizers, image recognition
systems, a portion of a chess program, lots of numeric code using STL, and
tons of other applications in C++, (even firmware for time critical
applications). Since 1997, I never missed even one feature in the language.
The poor implementation of C++ in various compilers however was certainly
outermost painful.

Anyway, is there a way to improve C++? - I think it's the perfect
programming language for our current computer architectures. I am even
tempted to believe that future "enhancements" can only negatively impact the
beauty of this language. No?

Gregor

(All) Programming languages are /solutions looking for problems/.

It's not how 'good' the language is, but if there is any system support for it.

So, your question, as posed, has no answer, and should be rephrased:

"What is the future of C++ support on platform X"?

[Alexander Terekhov]

Dietmar Kuehl wrote:
[...]

<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1738.pdf> is
necessary to address the future needs. I don't think that OpenMP does
address this issue (this paper are just the slides of a presentation
Andrei gave at the previous committee meeting in Redmond; I'm not aware
of any article which provides more details information but I hope that
someone follows up with a more details in a written document).

http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
http://groups.google.de/groups?selm=...2C8A7%40web.de
http://groups.google.de/groups?selm=...0EDB7%40web.de

regards,
alexander.