The Future of C++ ?

[Chris Thomasson]

C++ has one major flaw. #

How is C/C++ or Assembly Language flawed when they are used to create C#
Java?

Please enlighten me on how bad the language is that is used to implement you
favorite "Microsoft controlled super" high-level language?

 

[Chris Thomasson]

Of course it is. C++ beat all the other OO languages of its generation
because it supported all the company's existing C source. Read
Stroustrup's pages about the history of the language.

[...]


You don't think people use C/C++ for other reasons? What about the fact that
you can easily couple C/C++ with Assembly Language and create C#, Java,
custom lock-free VM, full blown garbage collection, virtually anything you
want!

Try to prototype new types of garbage collector designs in C# or Java,...
Ha!

 

[Steven T. Hatton]

How is C/C++ or Assembly Language flawed when they are used to create C#
Java?

Please enlighten me on how bad the language is that is used to implement
you favorite "Microsoft controlled super" high-level language?

Microsoft? Are they still in business? I haven't checked recently.

I believe you missed the entire meaning of my previous post. The one major
flaw in C++ is '#'. Other than that, it is an excellent language.

 

[Chris Thomasson]

Microsoft? Are they still in business? I haven't checked recently.

I believe you missed the entire meaning of my previous post. The one
major
flaw in C++ is '#'. Other than that, it is an excellent language.

Why is the preprocessor bad?

 

[Chris Thomasson]

Microsoft? Are they still in business? I haven't checked recently.

I believe you missed the entire meaning of my previous post. The one
major
flaw in C++ is '#'. Other than that, it is an excellent language.

Sorry, I thought you meant C#... You are referencing the preprocessor
correct?

 

[Steven T. Hatton]

Why is the preprocessor bad?

"Among the facilities, techniques, and ideas C++ inherited from C was the C
preprocessor, Cpp. I didn't like Cpp at all, and I still don't like it.
The character and file orientation of the preprocessor is fundamentally at
odds with a programming language designed around the notions of scopes,
types, and interfaces." Bjarne Stroustrup

 

[Chris Thomasson]

"Among the facilities, techniques, and ideas C++ inherited from C was the
C
preprocessor, Cpp. I didn't like Cpp at all, and I still don't like it.
The character and file orientation of the preprocessor is fundamentally at
odds with a programming language designed around the notions of scopes,
types, and interfaces." Bjarne Stroustrup

You can use the C preprocessor to generate C++ code:

http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/89382dc9a40439c7

I don't see anything wrong with the preprocessor.

 

[Kai-Uwe Bux]

Course in Java: [...]

And we can process concurrently...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Java memory model is so damn strict that it makes it impossible to
create any high-end synchronization algorithms. Period. But then, does
the average Java programmer even know this fact? I bet 99% do not.
Simple example of how learning Java first can, and will, burn you:

C++ teacher: Now we are going to learn about variable length arrays. C++
has
for instance the deque<> template, you see ...

Student: How does C++ actually implement that template?

C++ teacher: That is implementation defined according to the standard.
All I
can tell you for sure are the following guaranteed complexity bounds...

That teacher is crap. Give me a break. A good C++ teacher should make his
students create a vector class from scratch. Heck, the instructor can
teach his students how to implement a vector that meets the C++ Standard.
The instructor can teach the student how to create a memory allocator that
meets the C++ standard to plug into the standard vector the student will
be creating.

The classroom can define a namespace:

myclass_std

And the course would be about actually implementing Standard C++. Then the
students can implement Standard vector, and Standard queue, and use them
in further applications.


Any thoughts on this approach?

When you learned driving a car, did your instructor insist on assembling it
first from parts? Don't get me wrong, I think such a class would be fun and
a great way to learn quite a bit (been there, done that, learned a lot).
However that class would not be a language course. It would be a course in
data structures.

That C++ allows you to implement your own deque does not mean you should. It
does not even mean should know how to do it (there may be *other* reason
why you should know how to implement deque, but those are unrelated to C++
and are better taken care of by other classes in the curriculum).

In my opinion, a C++ course should focus on good programming idioms like
RAII, templated inheritance and policy classes, the use of standard
containers instead of pointers and arrays; the students should learn about
exception safety issues and how templates (user provided code) and
exceptions (when user provided code throws) aggravate the use of raw
pointers; the students need to explore the virtues and vices of being
virtual or of being private, protected, or public; and the list continues.
Those are issues a C++ needs to cover because these items are forced onto
the agenda by the language. A C++ course is neither a substitute for an
introduction to computer architecture nor a class on data structures and
algorithms.

Student: I hear the C++ Standard has a nice vector template?

Teacher: Well, yes it does. And you will learn exactly how to create a
Standard C++ vector template from scratch. This class will teach you how
to implement useful parts of the C++ Standard. The class uses the
namespace myclass_std for the minimalist Standard C++ template library you
will be creating.



Sound good to me, no?

As I said, sounds terrific for a class in data structures. But that is quite
different from teaching C++. The problems of implementing queues, maps,
sets, hash tables, and even something like vector are mostly unrelated to
the language (although it is true that templates help tremendously in
making such structures generic).


Best

Kai-Uwe Bux

 

[Earl Purple]

OK, so you just want them to be standard. That assumes that the proprietary
vendors would give up control of those things though. I can't imagine MS
giving up its cash cow by adhering to a standard GUI API.

That's like saying you can't have proprietary databases because they
have to support standard SQL.

 

[Silverclaw]

The real solution would be C++2, a new version of the C++ language

(not an extension of the current language). I should avoid the
numerous traps, pitfalls and wrong defaults of the current language.
C++2 could be compatible with (but not a superset of) current C and
C++ (through a compatibility mode). Of course, that's a futile
proposal. That kind of language evolution happens in Python, Ruby,
PHP, ... but not in C++.

An evolution of C++ is already en-route. Have you seen
http://www.digitalmars.com/d/ ?

 

[Earl Purple]

An evolution of C++ is already en-route. Have you seen
http://www.digitalmars.com/d/ ?

Yes, there is a big D discussion currently on comp.lang.c++.moderated.

D does not link with your existing C++ libraries. How it might be
useful is if there is a single D runtime library to make libraries
totally portable. They will need, in my opinion, a large number of
standard libraries relating to computing tools such as GUI, networking,
threads, databases, etc.

 

[VirtualDev]

If you had asked me 5 years ago about the future of C++, I would have
told you that its future was assured for many years to come. Recently,
I have been starting to wonder.

I have been teaching C++ at a local polytechnical school here in
Vancouver, Canada for approximately 8 years. Six years ago, at the
height (or should I say volume?) of the internet bubble, I had 80+
students per semester in my C++ course. Now I am fortunate to have 15
students per semester. What has changed? I believe that students are
no longer interested in learning C++. They would rather learn .NET
languages or Java (my colleages who teach these courses seem to be very
busy!). I believe it is because these other languages are easier to
learn and/or are perceived to be more relevant today.

I do believe that C++ is more difficult to learn than many of these
other languages. Despite my best efforts to make them exciting, I see
the eyes of my students start to glaze over when I start explaining
pointers. When I ask them to tokenize an english sentence (using the
strtok() function) and print the token in reverse order (they need to
declare an array of type char * and save the addresses of the tokens in
this array), I experience near panic from many of my students. But
these concepts need to be taught in a responsible C++ course. As was
pointed out to me recently, Microsoft still requires applicants to
demonstrate a very good knowledge of string manipulation using C-style
strings (none of these fancy string class objects!) when recruiting C++
programmers.

The ironic part is there is still a large demand for C++ developers
here in Vancouver. In fact, the company that I believe employs the
most developers here in Vancouver, employs almost entirely C++
programmers. This company, Electronic Arts (if you have not heard of
them, I guarantee that your kids have -- they create video games) is
only one of several gaming companies here in Vancouver that employ
primarily C++ programmers. Other companies like Kodak, MDSA, Nokia,
MDSI, etc. also employ large numbers of C++ programmers. Not
surprisingly, I have talked to several companies here in Vancouver who
are complaining that they are having difficulty finding C++ developers
and are looking at trying to recruit from abroad (eastern Europe
primarily).

I believe that many of these companies will be forced to migrate away
from C++ in the near future, simply because they will not be able to
find C++ programmers in the future. Soon the baby boomer C++
programmers will begin to retire, then the proverbial @@@@ will really
start to hit the fan!

Please tell me I am wrong, and paint me a view of the future which
includes C++.

I guess none here talked about the next standard of C++ the C++0x, that
one may be the solutions for all what is said about C++ complexity and
make it easy_to_learn and easy_to_program language.

In other hand, the C++, is the only language that gives the high rate
of flexibility between the high and the low level of programming.

for more about C++0x; http://www.artima.com/cppsource/cpp0x.html

Best Regards,
Adnane

 

[kwikius]

From: "kwikius" <[email protected]>
Newsgroups: comp.lang.c++
Subject: Re: The Future of C++ ?
Date: Tue, 28 Nov 2006 04:42:40 -0800

OK, so you just want them to be standard. That assumes that the proprietary
vendors would give up control of those things though. I can't imagine MS
giving up its cash cow by adhering to a standard GUI API.

All I can say is that Microsoft moves in mysterious ways their wonders
to perform.

I am intrigued as to why Microsoft released VC8.0 Express for free
though. I don't know why but speculating and first saying that VC8.0 is
a very capable C++ compiler with a lovely optimiser.

1) They want to introduce C++ coders to .Net.
2) They've given up on C++ and basically chucked VC8.0 like garbage as
their last C++ compiler.
3) gcc is free so they decided to compete on the same playing field.

Who knows... but (if if Microsoft are listening) I do hope there will
be a VC++9.0 though with Concepts:

http://www.generic-programming.org/languages/conceptcpp/

Beyond the limited horizons of 'implementation defined' C++ though, I
have a funny feeling that the idea of a virtual machine is the way of
the future. Ultimately this is the power of Java and the Microsoft .Net
languages. and its attractive to me and its a standard with cross
platform and cross language libraries... and and.... ;-)


regards
Andy Little

 

[Steven T. Hatton]

You can use the C preprocessor to generate C++ code:

http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/89382dc9a40439c7

I don't see anything wrong with the preprocessor.

I have seen Cpp used to effective ends. That is the nicest thing I can say
about it. For just one example of how it can bite you consider this
scenario: I spend 45 minutes agonizing over the names and signatures of
the member functions I want in the public interface of a class. I then
realize that I want DataModel to be an interface, and not an instantiable
class, so I rename it to DataModel_IF, delete the .cpp "implementation"
file and rename DataModel.h to DataModel_IF.h. Then I create a new header
file for the actual class DataModel and call it DataModel.h, and I also
create the corresponding DataModel.cpp. For some reason, none of my code
will compile even though everything looks correct. The errors aren't
making any sense in terms of the code I'm looking at. What's wrong?

 

[tetra]

Hey, that's great news. Less cheap labor competition makes me a more
expensive commodity. It also makes my life easier when I don't have to
deal with the bozos comming out of college these days. Let them write
horrible crap in C# or Java. I win either way...I can't loose, no way
is C++ going away any time soon, so this can only be good news.

I say make your course tougher. Weed out the idiots for us.

I agree!

 

[Mirek Fidler]

Other that that... When I get back from the meeting, we should include c.p.t
in this conversation.

Well, I have tried to follow links, but I am afraid I am missing the
necessary background...

Could you, for starters, give me a hint what means that
boost::shared_ptr does not have "strong guarantee"?

Does it mean that you cannot access (or write) single shared_ptr
instance from 2 threads?

Mirek

 

[Joe Seigh]

Chris Thomasson wrote:




Well, I have tried to follow links, but I am afraid I am missing the
necessary background...

Could you, for starters, give me a hint what means that
boost::shared_ptr does not have "strong guarantee"?

Does it mean that you cannot access (or write) single shared_ptr
instance from 2 threads?

Yes, concurrently or atomically, however you'd like to put it.
Similar to Java "pointer" guarantees.

 

[Frederick Gotham]

Steven T. Hatton:

"Among the facilities, techniques, and ideas C++ inherited from C was the C
preprocessor, Cpp. I didn't like Cpp at all, and I still don't like it.
The character and file orientation of the preprocessor is fundamentally at
odds with a programming language designed around the notions of scopes,
types, and interfaces." Bjarne Stroustrup

Did you see the macros I wrote recently in another thread:

POST_IN_TERMS_OF
OP_IN_TERMS_OF
NON_CONST_IN_TERMS_OF

These macros are very handy, and they cut down on programmer time and error.

 

[Frederick Gotham]

Steven T. Hatton:

The one major flaw in C++ is '#'.

Are you five years old? '#' doesn't mean "preprocessor", never has and never
will. It's nothing more than a symbol which has different names in different
languages and dialects -- I myself call it the hash symbol.

From now on, when I say that there's a problem with '~', you can take it to
mean the mid-Atlantic currents.

 

[Mirek Fidler]

Well, you can't use it as a 100% drop in replacement right now because the
interface is a little different. However, it does provides two smart
pointers:

Well, before going into details....

Have you found a way how to implement lock-free reference counting
usable e.g. for COW string? (with "weak" guarantee for string itself)?

If yes, what is the idea, if you are willing to share?

Mirek