Stroustrup on the Future of C++

/ASCII writes "Bjarne Stroustrup, the father of C++, has written an essay [PDF] on the features of the upcoming C++0x standard. In his essay, he argues that new features should whenever possible go into the standard library and not into the language, but that the language needs to shave of a few rough corners to make it easier to use for novices."

Comments

wait a moment...

[Anonymous Coward]

[...] to make it easier to use for novices.

Doesn't this qualify as blasphemy?

Re:wait a moment...

[insert cool name]

Doesn't this qualify as blasphemy?

Not when it's God talking.

Re:wait a moment...

[ceeam]

I dunno - anybody knows where B.S. can swim?

Re:wait a moment...

[Mark of THE CITY]

Parent reminded me of the apocryphal objection to COBOL: "But Grace, darling, that will allow anyone to program" where the comparison is to assembly language.

Re:wait a moment...

[Kurt Granroth]

Not when it's God talking

Speaking of which, did anybody else notice the author description in that article?

"Bjarne Stroustrup is the College of Engineering Professor in Computer Science at Texas A&M University"

What!? Isn't that like saying the George Bush is a businessman from Texas? It's technically true, but completely misses the point on what matters.

This makes even less sense when you try to find the target audience. If the person reading the article already knows who Bjarne is (by which I mean every single C++ programmer), then I could see them omitting the entire "creator of C++" description because, well, they already know... but then why have a description at all?

If the person doesn't already know who this "Bjarne" is and they are reading the article, don't you think they'd want to know that he created the thing and therefore might have some relevant opinions on that matter?

Very odd...

Re:wait a moment...

[davecb]

If you look at the complexity that was
proposed before Grace Hopper joined the
project, you'll see why the relativey
simple COBOL was occasionally called
"the accountant's assembler"

perform a until done
add b to c giving d

Re:wait a moment...

[Anonymous Coward]

May be Bjarne Stroustrup want to avoid "Argumentum ad verecundiam" (aka "Appeal to Authority").

Re:wait a moment...

[Anonymous Coward]

"What!? Isn't that like saying the George Bush is a businessman from Texas? It's technically true, but completely misses the point on what matters."

I don't know... don't most people prefer to emphasize their accomplishments and hide their failures?

Re:wait a moment...

[LSD-25]

This makes even less sense when you try to find the target audience. If the person reading the article already knows who Bjarne is (by which I mean every single C++ programmer), then I could see them omitting the entire "creator of C++" description because, well, they already know... but then why have a description at all?

This essay was originally published in the C/C++ Users Journal, so most readers will know that he created C++. Also, some of those who know him might not know what he is doing now.

Re:wait a moment...

[Mark of THE CITY]

add b to c giving d

In CMS-2 (Navy high-level language for embedded apps, pre-Ada) that would be

SET D TO B + C

which looks like BASIC:

LET D = B + C

Dynamics in programming languages

[jurt1235]

It is interesting to see how an abstract language like a programming language evolves through time. I would think that in a language like C++ the more userfriendlyness should be in the libraries and not in the language, so I agree with the author on this point. Putting it in the libraries makes it better backwards compatible, and distributable.

Re:Dynamics in programming languages

[orthogonal]

It is interesting to see how an abstract language like a programming language evolves through time

If you find that interesting, you're going to love Stroustrup's The Design and Evolution of C++.

It's an almost novelistic discussion of how he made C in to C++, the various trade-offs required, and how he decided what changes to make or not make. For example, why the dot operator (".") can't be overloaded, but the parentheses can be, and why (contra Goslings Java) operator overloading is a good thing (short answer: it makes syntax match semantics).

If you ever want, or need, to develop a large-scale, flexible and general system of anything (and what's more general than C++, a programming language used by millions to write both Object Oriented and just "better C" code?), D&E is a wealth of experience, carefully and fully explained.

And, like a novel, it's for the most part a fun read. Grab a copy, and you'll not only understand C++ better, you'll understand why C++ is what it is, and how it got there from C.

Re:Dynamics in programming languages

[IWannaBeAnAC]

Interestingly, overloading the dot operator may well make it into the nex standard.

Re:Dynamics in programming languages

[dkf]

I agree mostly (losing associativity is worse, BTW) and I feel that C++ could have done the whole operator thing much better if they'd forced people to only ever do the job properly (perhaps by subclassing an abstract NumericValue class?)

As it is, what we have is a language that can be used to do really neat stuff, but which too often isn't used that way in practice. The language also makes it too easy to lose sight of where the expensive operations are, which is something that really matters for any language intended for even moderately low-level use.

(The other key problem with C++ as commonly implemented is that it is a PITA to deploy in a portable way. I'm not sure you'd call this a language fault though; it's perhaps more of a toolchain and binary-format problem.)

a 'few' rough edges

[leomekenkamp]

Shaving off a 'few' rough edges to make it more easy for newbies... It's that what Sun tried to do? (hint: java)

Re:a 'few' rough edges

[lbmouse]

... or MS tried to do? (hint: C#)

Re:a 'few' rough edges

[/ASCII]

If you would read the actual article, you would see that the edges Stroustroup talks about are little warts like :

• whitespace sensitvity in templates, i.e. vector> is a syntax error, since >> is a single token.
  
• Type declarating iterator variables can be a huge pain when using STL since the names are so long, i.e. the type 'vector >::const_iterator' is a bit of a mouthfull. Such variables can be guessed from the return type, so you could use a type 'auto' for this.
  

Java does not remove a few warts from C++, it forces you to use a Garbage collector, OO design, type introspection, etc, etc. Those are pretty fundamental changes.

Re:a 'few' rough edges

[leomekenkamp]

Yes, I know these are fundamental changes, that's why I put the word 'few' in between quotes.

Point of fact stays however: c++ has an enormous learning curve. Complexity in the language is imho comparable to Latin: you can almost recognise the author by lookin at the code. That complexity is far, far less in java.

Especially the gc makes life a lot easier for even seasoned programmers.

And by the way: you can be almost as un-OO in java as you can be in c++. Introspection in java is mostly used in 'frameworks', like for instance the serialization API; normally you almost never use it.

Re:a 'few' rough edges

[Da Fokka]

... or MS tried to do? (hint: C#)

So tell me, what really is wrong with C#?

Re:a 'few' rough edges

[GoldMace]

While Java made it easier in some ways like not needing to do pointer arithmetic, it also made it much more difficult in other ways for beginners. You have to learn all about complicated abstract concepts like object oriented programming just to make even a hello world program. Or a beginner's program that does simple math.

I know quite a number of beginning programmers that really don't get the whole object vs. class vs. method thing.

Re:a 'few' rough edges

[orthogonal]

Shaving off a 'few' rough edges to make it more easy for newbies... It's that what Sun tried to do? (hint: java)

Java's ok, but a few mistakes were made. Among the worst: over-reliance on the instanceof operator, and the need for something called a MethodNotSupported exception.

Now think about what MethodNotSupported means in the context of Barbara Liskov's Substitution Principle:

We've got a language that supports inheritance. Inheritance makes sense only insofar as Liskov's Principle is followed. Put simply, if class D inherits from class B, any "promises" that B made -- it's interface, both syntactically, in terms of public member names, and semantically, that the member functions really do do some particular thing -- any of those promises must also be kept by D, because we are saying, as Liskov tells us, that D is-a B.

If I hand you an instance of D, and you plug it in place of am instance of B, anything that the B instance does, the D instance must at least do. Otherwise, how can you safely and with confidence substitute a the D in where the B used to be?

But along comes Java, and the MethodNotSupported exception -- a method used by some of Java's core library, including, dismayingly enough, commonly used container classes. It's used so that a derived class can suddenly and at run-time throw it, telling you, "Whoops! Ha ha! Trickled you, I can't in fact really do what B promises! I claim I'm a B, but really, I'm not!"

Now imagine you had a component stereo, and you replaced your tuner with a "better" tuner with all the same jacks as the original. You'd plug it in and expect it to do the same work as the original tuner, just with better reception or fidelity or whatever. Now what if you plugged in the new tuner to the old connections, and suddenly its display read: "Sure, I have a two-plug RCA input, but it's not actually connected to anything, so you can plug in an RCA jack but no sound will come out". That's what having a method that throws MethodNotSupport is like: the jack -- or member function name -- is there, but the implementation is not.

D inherits ("extends") B, it says so right there on the label, but no sound comes out. With Liskov undermined, you don't really have an object oriented language at all. You don't really have true inheritance. What you have is a sham, a sham that can break down on you at run-time because an object is lying to you.

And the upshot is that you don't see enough real object oriented programming by client Java coders. If the core library can get it that wrong, why should clients of that library bother to adhere to a standard?

So you get lots of java code that does RTTI using instanceof and if( p instanceof Foo ) ... else if( p instanceof Bar ) ladders rather than calling p.virtualFunction(). Because coders won't take seriously OO that the language and its core libraries don't take seriously.

Re:a 'few' rough edges

[/ASCII]

Two important points here:

• There are lots of GCs for C++. They are not part of the language, they are implemented as libraries. Hopefully, a future version of the C++ standard will have a GC in the standard library. But never as a part of the language.
  
• The point about introspection in Java is that it _always_ costs you in performance and memory/disc use. Even if you're not using it.
  

Re:a 'few' rough edges

[Decaff]

Java does not remove a few warts from C++, it forces you to use a Garbage collector, OO design, type introspection, etc, etc. Those are pretty fundamental changes.

No it doesn't. How, when and if garbage collection is performed in Java is implementation dependent. There is nothing in Java that forces it's use.

You don't have to use OO design at all. You can start a source file with the 'class' keyword, then do things entirely procedurally.

As for introspection, that is a very specialised aspect of the language, and no-one is forced to use it at all.

Re:a 'few' rough edges

[Deadbolt]

So the language is responsible for the perversions that retarded coders put it through?

If you use instanceof more than once every, say, 10000 lines of code, I will fight you. That's no lie. It's a sop, and we, the loyal Java programmers of the world, know it's a sop. People who don't know what they're doing can turn it into a crutch. But those of us who DO know what we're doing know that using instanceof should be an automatic hint to rethink the design.

As for MethodNotSupportedException -- yes, it's kind of a hack. But the thing is, perfect designs don't translate to reality very well, and Java, for all its good points, isn't perfect. That exception lets you know when you're breaking an API contract -- though a List may have add() methods, if you want that List to be immutable, is it preferable to throw an exception from a mutator or remove the mutator from the subclass completely? Or should we just take add() out of the List interface? Point is, it's a hack, but it's a lot better than the alternatives. And what it DOES do very well is say, "Look, genius, you're saying two different things about this object. Figure out what you mean and then say it."

I could read stupid C++/D/C/Ruby/whatever code and then blame the language too, you know.

Re:a 'few' rough edges

[orthogonal]

"That exception lets you know when you're breaking an API contract -- though a List may have add() methods, if you want that List to be immutable, is it preferable to throw an exception from a mutator or remove the mutator from the subclass completely? Or should we just take add() out of the List interface?"

If those are the motivations, we should have an ImmutableList class without an add function, and derive the List with an add function from it (in C++, probably by private inheritance, that is, inheritance of implementation). Only the List class with the (working) add should publically inherit from the interface with an add function.

Problem solved.

"I could read stupid C++/D/C/Ruby/whatever code and then blame the language too, you know."

Sure, sure. Don't be touchy. I code Java too, in fact I'm Sun Certified.

What I'm saying is, you tell me you'd "fight" unnecessary uses of instanceof, and I believe you. I'm just trying to make your fight easier. The point is, if your core libraries don't take liberties, your fellow client coders will be less likely to -- or at least less likely to use the bad example ("but the core library does it, why can't I?") when a good java programmer, like you, points out the problem.

Re:a 'few' rough edges

[0xABADC0DA]

Java does not remove a few warts from C++, it forces you to use a Garbage collector, OO design, type introspection, etc, etc. Those are pretty fundamental changes.

What, like it can't do both? The problem with C++ is that is was built with focus purely on technology and seemingly without any effort to human factors at all. I mean come on, "::" to separate class from method name, pure virtual destructors, separate interface and implementation files, can't nest templates because >> is a token, references *and* pointers, no garbage collector (even optional)? If there had been any thought into human factors whoever came up with these would be burned at the stake.

Java does enforce using a GC, and encourages OO design, and makes C into a safe language (no pointer math and no invalid casts), but that is not why it has been so successful.

The #1 thing it does is make the code do what is says... you can look at Java code and see exactly what is going on with no ambiguity at all. You might not know what some method does, but you know when it's called; with operator overloading it is impossible to know what a C++ code is doing (ie, cin >> s, shift right or method call?).

The #2 thing Java does is have a large, consistent library. People can glance at pretty much any Java code and know a lot about the methods being called do since they are to the standard library.

The #3 thing it does is to remove all of the syntax crap of C++. The syntax in C is somewhat functional and makes some sense (except function pointers). It's clearly something people can stand, and Java adds nothing to this and even removes the -> vs . ambiguity.

Those are the reasons why Java is so successful, not because it forces OO, GC, safety, etc on the programmer. In fact in a lot of areas those are the things slowing its growth.

Re:a 'few' rough edges

[SerpentMage]

Yes it forces you to do all of the things that make you productive.

Now getting back to C++, you are not forced to do anything except write code like the following:

T & list::iterator::operator* () const
{
return current->data;
}

Yeah I suppose this is obvious, and simple! (NOT)

I completely gave up on C++ about six months ago. Before that I was half in and half out. Having read BS's article I have to say I am glad I gave up on C++.

I have talked to multiple people who regularly develop using Python, C#, Java, etc and they hate the fact you have so many little details in C++. If you look at my little C++ example look how many details a coder is supposed to take care of. It is insane!

Oddly enough, people still like C. I suppose it is a simple and effective language to get low level coding done.

Re:a 'few' rough edges

[Deadbolt]

Okay, I'll buy that. However, nothing prevents you from creating your own ImmutableList wrapper around a List instance and not exposing any mutators.

You could make an argument that the standard library should be designed that way, maybe with a root List interface and then a MutableList subinterface, but you could also make the argument that going that way doubles the number of classes in your collections API. Matter of taste, perhaps.

Just seems, though, like you're focusing on one thing that isn't perfect and using that as an indictment of the entire library. I remind you that Java does it about 80-85% right and 5-10% sorta right, which isn't bad for a real language.

Re:a 'few' rough edges

[slavemowgli]

Both Java and C++ are fundamentally object-oriented languages, so what, if I may ask, is wrong with forcing you to use OO design? The only reason I could come up with is that it's a violation of TIMTOWTDI, but it's not as if either Java or C++ are big on that, anyway.

I don't like C++ myself (it's a big, bloated, inflexible mess), but this seems rather silly. If your problems aren't nails (or if you don't want to treat them as such), then don't use a hammer as a tool, but don't complain about the fact that a hammer is, well, a hammer. :) There's plenty of other tools you can use instead.

Re:a 'few' rough edges

[Deadbolt]

T & list::iterator::operator* () const
{
return current->data;
}

*blink*

*-operator overload applied to a list::iterator object that returns a reference to type T and promises not to screw with *this...

*runs away screaming*

Re:a 'few' rough edges

[PWatson]

Now imagine you had a component stereo, and you replaced your tuner with a "better" tuner with all the same jacks as the original. You'd plug it in and expect it to do the same work as the original tuner, just with better reception or fidelity or whatever. Now what if you plugged in the new tuner to the old connections, and suddenly its display read: "Sure, I have a two-plug RCA input, but it's not actually connected to anything, so you can plug in an RCA jack but no sound will come out". That's what having a method that throws MethodNotSupport is like: the jack -- or member function name -- is there, but the implementation is not.

That sounds like my cable TV box... Although when I try to use its ethernet jack, I get a Com.Comcast.UserFriendlinessNotFoundException thrown at me.

Re:a 'few' rough edges

[m50d]

You can write c++ programs without once having to use the word "class". Try doing that in java. And if you try further to write non-OO stuff, you'll have all sorts of problems with static and non-static contexts - I know, I've tried it. Java really does force OO on you.

Re:a 'few' rough edges

[brett_sinclair]

Nice indignation here, with Liskov, component stereos and all.

But you've got it quite wrong, I'm afraid. And then I'm assuming that you mean java.lang.NoSuchMethodError, and not javax.mail.MethodNotSupportedException which is something else completely.

NoSuchMethodErrors only occur when you run code that wouldn't compile (such as when you remove a method, but forget to recompile users of that method).

And since you refuse to use the compiler, what's a poor runtime supposed to do when you call a non-existing method? Create one for you? Or install a new tuner?

Re:a 'few' rough edges

[Dewb]

If those are the motivations, we should have an ImmutableList class without an add function, and derive the List with an add function from it (in C++, probably by private inheritance, that is, inheritance of implementation). Only the List class with the (working) add should publically inherit from the interface with an add function.

Just in case anyone's curious, this is the way the NS* container classes in Objective C work. NSArray is immutable, but the derived class NSMutableArray has add/remove methods, etc.

I personally prefer supporting both in one interface using 'const' in C++, but this approach does make a bit of sense (once you get over the "Why doesn't NSArray have any mutator methods?! reaction.)

Re:a 'few' rough edges

[hgh]

I agree that major additions to the language like a garbage collector should be put in a library and not become part of the language to keep the flexibility that has been one of the major advantages of c++. At the same time, the standards committee has moved pretty slowly in adopting new features into the standard library. There's a pretty good community of people creating new public libraries for C++, such as boost, but few C++ programmers take any time to use libraries that are not part of the standard.

I think something like Perl's CPAN would be an excellent thing to have for C++, and many other languages. There's a lot of rich external libraries for C++ that just go unnoticed by too many programmers.

Re:a 'few' rough edges

[Xepo]

C++ is capable of much much more than just object-orientated programming. Look at all of the template craziness going on by Alexandrescu for generic programming. See the Boost Lambda library for some functional programming examples. Heck, even wikipedia says "C++ is designed to directly and comprehensively support multiple programming styles (procedural programming, data abstraction, object-oriented programming, and generic programming)" [Ref. And it does *all* of this without any sort of major performance detriment.

Re:a 'few' rough edges

[/ASCII]

My interpretation of Stroustrups article is that he agrees with you, the standard library should be much larger and develop faster. The biggest possible addition according to Stroustrup would be a standard widget set. I'm not convinced that one is coming, but if it does, it should be a pretty big help for platform independent GUI software. But a standardized GC, a few more containers, more templated algorithms, XML handling, networking and loads of other major additions would also be benificial.

Re:a 'few' rough edges

[Chris Burke]

The template closing thing is an obvious, minor change.

I'm not so sure about 'auto'. Just from the article, which admittedly is not supposed to be a list of features going into the new standard, I can't help but see problems. e.g.:

auto my_thing = [complex stl expression];

[some other complex expression](my_thing);

and getting some horrible STL error on the second expression because the type of the first expression wasn't what you expected and now you have to figure out what it actually was and how to force it to be what you thought it was going to be. In other words, it's the same nasty STL template debugging you have to do today, only with another level of hidden indirection in the type of a variable, which is at least something I don't really have to worry about today.

On the other hand, I do really like the idea of "concepts" where you specify what "concept" a template expects and the type you give can be verified to be the correct concept. As it stands right now, you don't know that a given type won't work in a given template until the compiler compiles a template function that requires a method your class doesn't support which may not even happen until after you've been using the template and class combination for a while. This sounds a bit like Java interfaces, but without the requirement that your class derive from the interface. You just have to provide what the concept expects.

This beats the hell out of the current situation where the "concept" a template requires is implied by its implementation. The implication that this might simplify template error messages would be icing on the cake.

Re:a 'few' rough edges

[dustman]

Nice indignation here, with Liskov, component stereos and all.

But you've got it quite wrong, I'm afraid.

Nice snobbery there. But you're a patronizing prick, I'm afraid.

The GP meant "UnsupportedOperationException", not "MethodNotSupportedException", which is an easy mistake to make.

NoSuchMethodErrors only occur when you run code that wouldn't compile (such as when you remove a method, but forget to recompile users of that method).

And since you refuse to use the compiler, what's a poor runtime supposed to do when you call a non-existing method? Create one for you? Or install a new tuner?

Did you even bother to read his post? It certainly looks like you have no idea what he was talking about.

There is a pretty obvious disconnect when he's talking about the standard library throwing these exceptions, and you're spouting off about what "NoSuchMethodError" means and then strawmanning your way into berating him for not using the compiler (wtf?)

Every aspect of his post was correct. The concept of a method which exists on an interface but is "unsupported" by implementations is somewhat bad design.

Re:a 'few' rough edges

[jallen02]

Not really.. if you know enough about the language to abuse it properly you can write amost purely procedural code. You will staill instantiate objects, but if everything you are doing is static and you don't use any instance varaibles you are basically using the absolute barest amount of OO possible to the point where youa re just arguing semantics claiming you are still doing OO.

Jeremy

Re:a 'few' rough edges

[Anonymous Coward]

If those are the motivations, we should have an ImmutableList class without an add function, and derive the List with an add function from it

Then you're saying that a List (which is mutable) is an ImmutableList. That's wrong. You could be passed an ImmutableList from other code and be surprised when it changes.

Better to name the superinterface List (which makes no statement about mutability or immutability) and have no mutable operations on it. The subinterface would be named MutableList and add the mutators.

Re:a 'few' rough edges

[Kenneth Stephen]

No it doesn't. How, when and if garbage collection is performed in Java is implementation dependent. There is nothing in Java that forces it's use.

Yes it does. Under C++, cleaning up of resources no longer used is the responsibility of the programmer. This is not the case with Java - so you are implicitly forced to use the garbage collector.

Re:a 'few' rough edges

[Anonymous Coward]

In the case of this List wrapper, you'd want an instance of it, not to derive from it.

It's really a whole in the ideology in the language, not the language itself. It tries to be "the OO language" and fails on a very important point.

That being said, in the real world, it's design by contract and you should never use a method without looking at it's contract (which in java is the javaDoc), which better say "This function will uncoditionally throw a UnssportedOperationException."

Re:a 'few' rough edges

[PsiPsiStar]

Now what if you plugged in the new tuner to the old connections, and suddenly its display read: "Sure, I have a two-plug RCA input, but it's not actually connected to anything, so you can plug in an RCA jack but no sound will come out". That's what having a method that throws MethodNotSupport is like: the jack -- or member function name -- is there, but the implementation is not.

Hi, I'm from the RIAA. We're fascinated by your proposal and we'd like your help in implementing this new functionality-crippling techno...oh, were you just speaking hypothetically?

Re:a 'few' rough edges

[tolkienfan]

Strange, I've never seen anyone code a ladder of instanceof tests.

Whoever coded it should be shot.

You can't blame Java itself. Anyway, Smalltalk has a similar NotImplemented exception.

Such decisions are often a trade off. Like the fact that the stl uses an informal idea of an interface. Look at the iterator. No type safety to ensure that an object really behaves as an interface. Java's interfaces (like Iterator) ensure that you have the necessary methods.

The other way to have "optional" methods would be to have an interface for each logical group of optional methods, but that doesn't recommend those methods to implementers.

The fact that a class has a (probably abstract) method to be overriden at least acts as a hint to the coder that the method should be implemented.

It certainly isn't standard practice to fill all mandated methods with "throw new MethodNotSupportedException(...)"

It also doesn't mean that the OOness of the language is totally broken.

In every OO language you can quite easily build flat procedural code. And you can avoid implementing methods by throwing exceptions.

Bad coding is the fault of the coder.

Re:a 'few' rough edges

[orthogonal]

"Okay, I'll buy that. However, nothing prevents you from creating your own ImmutableList wrapper around a List instance and not exposing any mutators."

Sure. No argument from me on that. Nothing prevents me from creating my own class that doesn't throw NoSuchMethod.

But the whole point of libraries, you'll agree, is to save the client programmer from having to roll his own, design his own, test his own, code his own -- and then make it interoperate with your code or his code.

And it's his code (not yours, not mine) where the problem sneaks in. (It's always his code, not mine. ;) )

Say I'm using Joe's Nifty Library O' Functions. Joe, being a good programmer, doesn't try to roll his own container code -- he knows that no one wants to read up on how his JoeArray or JoeInterator or JoeList are different from the standard, so Joe -- and he's right to do this -- uses standard Java core library classes.

So far so good. But to be good, Joe has to use java.util.List. That's actually an interface, so Joe uses List as his public contract and java.util.ArrayList as the actual implementing class. He uses it as a public member of Joe's Own Nifty Widget with Lots O' Features.

Now you use Joe's library in your code, and you routinely use Widget.getObserverList() like this: myWidget.getObserverList().add( myCallback ) and all is well.

But at some point Joe adds Lenny's Luscious Library to his own code, because it adds all sorts of new functionality to Joe's stuff. But Lenny's library requires that Jow use Lenny's List class. It also implements the java.util.List interface, so Joe -- rather than copy stuff back and forth between lists, just replaces the ArrayList with a LennyList. Joe's code still works, and he releases Joe's Library 2.0.

You upgrade to Joe 2.0, to take advantage of all the new functionality he's added -- in fact, your 2.0 release leverages and relies on lots of the new functionality in Joe's library, and there's no way you could roll your own version in time to meet your client's deadline. And the compiler never complains about your upgrade, because all the interfaces are right, no method calls are made to functions that don't exist.

But at runtime, your code fails. Because Lenny's List has an add function, but never implements beyond throwing an exception. Incredibly enough, Lenny's List is a special proxy listinstanceof too often, they'll just say "see, I told you, object oriented code and using exceptions just ain't reliable."

Of course, the problem is that in using NoSuchMethod, Java isn't actually being object oriented, but after the code throws, try explaining that to the converted C programmers doing java. (Again, not you, not anyone who has read this far -- but we all know and have worked with someone like this, no?)

Now of course, these sort of problems won't arise on small projects. But they'll inevitably arise when your JSP library is calling your Java App server's code which is calling, via RMI, your Distributed Business Object which is calling, via JSQL either an Oracle database (for your domestic operations) or a Sybase database (for the European subsidiary).

Re:a 'few' rough edges

[Woody77]

I've found that smart-pointers give me the ease of programming of a garbage collector (especially when paired with something like STLPort's allocator), but still gives me explicit control over the destruction of objects.

Java doesn't have a concept of a destructor that runs *NOW* (or not one that I'm aware of). And an object created on the stack can't do things in it's destructor like immediately freeing all references to non-memory resources that it's using (transactions, pipes, files, etc.)

You have to wait for the GC to do it's scan.

Re:a 'few' rough edges

[dustmite]

C# is not standard. Yes I know there is a standard specification, but it's not an "industry standard" in that it's not supported widely. E.g. can I simply compile my C# applications on OS X in Xcode, or on Linux, even if I have used cross-platform libraries like wxWidgets? As an ISV, choosing C# would mean a choice to deliberately limit the available platforms we could run our software on. This doesn't make sense at a time when libs like wxWidgets make it easy to develop decent cross-platform software - there is little advantage to deliberately unnecessarily limiting yourself like that. This makes C# useless for many applications regardless of whether or not it is a good language technically --- it just doesn't have critical mass.

But why doesn't it? Because C# just doesn't offer enough value over and above existing languages to attract significant numbers of new developers - it tries to solve problems that mostly had already been solved already elsewhere, and frankly there was really no point in introducing yet another new language at a time when there were already hundreds of decent languages in widespread use for all sorts of purposes. To make people want to use something new it has to be more than just "good". It has to offer something that really makes people want to switch, especially as there are retraining costs involved in switching to a different language.

Re:a 'few' rough edges

[gbjbaanb]

Absolutely, which is why it is popular - it isn't a "hold your hand and make it easy, but with overheads of all that helping", it is a "you know what you're doing, let me let you get on with it". Obviously, if you're not up to snuff as a programmer and you don't know what you're doing, then stick to Java, or VB or something simple.

I reckon if you're in that camp, you'll still make mistakes anyway.

(eg. I once worked with someone who was tasked with adding a new entry to something, and each entry was masked with a bitmask.. so we had #define A 1, #define B 2, #define C 4... and he quite rightly tagged a new one on the end.. #define D 5. A little knowledge of how computers work would have saved us some trouble there)

The thing with Java is that is isn't consistent (or elegant as people used to call it). Sure you have to use methods instead of syntactically-pleasing overloading.. but then Java does have primitive operators that are effectively overloaded (eg, add 2 integers together does not work the same as adding 2 floats, and way different than adding 2 strings). So really, its just being a bit stupid, and breaking the rules of encapsulation - an object should know how to add to itself, it doesn't need an explicit method 'add()' instead.
(and besides, what is the difference between add() and operator+() except how the programmer types it? If you need to know whether a variable is an object or a primitive, (ie. myInt1 + myInt2 is OK, whereas myComplex1 + myComplex2 is not) then perhaps hungarian notation would be good for you)

As for consistency in the library - how much of it is deprecated this week?

BTW, garbage collectors are optional in C++, do a google and you'll see hundreds of different bits of code that provide you with a GC. A GC that also allows for deterministic destruction too without the hack that is finalisation. (I remember when Java first came out, no finalisation.. people were quite rightly 'concerned', and a bodge had to be put in for Java 1.1. Its still there :( )

Surely separate interface and inplementation files are a good thing?! Isn't it good OO design practise to keep a definition away from the grubby internals. I mean, that's why you actually have interface types in Java that cannot contain code, or enjoy implemetation inheritance.

At the end of the day though, its not about my language is better than yours.. we can all come up with reasons why A is better than B, just like when I was at school and the spectrum owners and the C64 owners argued the same old arguments. Java is just different, fills a different need, and there should be plenty of programming to go round.

(BTW, my personal opinion is that you just use the best language for the job at hand, I used to write presentation tiers in VB, application and communication tiers in C++, and data tiers in SQL. Worked well, shame the current trend is to make all languages able to do everything... so perhaps C++'s ability as an all-purpose language has some envy value after all).

Re:a 'few' rough edges

[Trillan]

Java and C++ are different languages and have different uses. I'm not sure who you're trying to convince otherwise, or even why you're bothering.

Re:a 'few' rough edges

[nonsequitor]

C# has no comparison to C/C++ for one VERY important reason. C# is a managed language, sure you can hack at it to turn off the Garbage Collector and whatnot, but AFAIK there is no compiler in the pure sense of the word which creates straight machine code. (Thats leaving out the whole .NET nonsense too.)

Re:a 'few' rough edges

[leomekenkamp]

Wether or not the gc should be part of the language is almost a religious choice, so I will not argue on that point ;-).

I am afraid I do not get the part about introspection: the information on how object-data is represented in memory is only present once (every object has a 'pointer' to the virtual method table, class info, or what you would like to call it), so that has only a cost of O(1) in memory space (can one use O() wrt size? I forgot...). Performance-wise there is high cost: without multiple inheritance the compiler knows exactely at which offsets member variables can be found, so this has equivalent performance as in c++.

Or am I missing something here?

Re:a 'few' rough edges

[MassacrE]

E.g. can I simply compile my C# applications on OS X in Xcode, or on Linux, even if I have used cross-platform libraries like wxWidgets?

yes, although the 'in Xcode' part is still shaky.

Re:a 'few' rough edges

[Mingco]

(eg. I once worked with someone who was tasked with adding a new entry to something, and each entry was masked with a bitmask.. so we had #define A 1, #define B 2, #define C 4... and he quite rightly tagged a new one on the end.. #define D 5. A little knowledge of how computers work would have saved us some trouble there)

A little knowledge of programming style from the original programmer could have helped the newbie.

enum bitmask_for_foo
{
A = 1<<0,
B = 1<<1,
C = 1<<2,
};

Re:a 'few' rough edges

[huckleup]

Hey, I think that's kinda funny. Just because you don't agree with someone doesn't make them a troll. Maybe -.5 Flamebait, but not troll.

Personally I think C++ was a poor choice to standardize on. It was just in the right place at the right time with heavier promotion than the competition. I yell at it all the time and I blame it for my growing bald spot, even as I collect paychecks for battling the beast. I much prefer ObjC - actually ObjC++ because I like *some* of the C++ extensions beyond C, like to declare variables right at the places I need them, and in for() statements.

Re:a 'few' rough edges

[leomekenkamp]

:-)

I get the impression that you think that I think that c++ is not powerful. It might very well be, as you claim, the most powerful language on Earth. Java however works better for me in the work I do (business logic and that sort of stuff). It works better because I can concentrate more at the task to be solved. I do not have to worry about memory leaks or getting to know another non-standard library. Java enables me to write clean-looking solutions at a higher speed than in c++.

Does the resulting binary use more memory. Yup. Does it require a faster cpu? Yup, although the speed increases in 1.4 and 5 have been really noticable. However, that does not matter where I code. Shelling out 5000 euro more for a faster server with more memory is nothing compared to the time that would be put in development time if I were to code everything in c++.

Re:a 'few' rough edges

[leomekenkamp]

You are completely right: different languages with different uses. I was not trying to convince otherwise. I think that Sun (wether they knew in advance or not) came up with a more cross-platform language that looks a bit like c++, but leaves you less room to make mistakes. For most business logic it makes sense to use java, because of these reasons. Avg. speed of development is better with java. Avg size of executables and execution is better with c++. Take assembly, and the speed and size goes ever further down, at the cost of speed of development.

As you stated: different languages, different results and uses.

Re:a 'few' rough edges

[GoldMace]

My point was that for many beginning programmers, C++ was easier for them to learn because they don't have to learn the differences all at once, unlike in Java. In C++, they can write quite a lot of semi-useful programs just by typing everything within int main(){}, and then learn the rest later once they are comfortable with that.

Re:a 'few' rough edges

[Tim Browse]

Both Java and C++ are fundamentally object-oriented languages, so what, if I may ask, is wrong with forcing you to use OO design?

C++ supports object-oriented programming, but it is intended to be agnostic in terms of OO, procedural, generic programming, etc. It's up to the user how they use these features.

Tell Stepanov that C++ should only be used for OO, and see how far you get...

STL, at least for me, represents the only way programming is possible. It is, indeed, quite different from C++ programming as it was presented and still is presented in most textbooks.

But then, he is a bit of a zealot, so add salt as required:

STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people.

Re:a 'few' rough edges

[0xABADC0DA]

First of all, there is no MethodNotSupported... it's either NoSuchMethod (linking to different class version than compiled against) or UnsupportedOperation, mostly used in the Collections hierarchy.

In any case, for Collections the reasons why they didn't have separate type are clearly documented by Sun, and it makes sense. Basically, you get a massive class hierarchy of collections that are immutable, unmodifiable, synchronized, and modifiable. Not to mention collections that can be added to but not removed from and vice versa, or lists that are a fixed size (only support set/get).

The fact is that the Liskov Substitution Principle is a good guideline, but it's not a Law of good OO design. And if you think Java is bad, just consider value types. When you assign a subclass instance to a variable of a parent class, any extra state is lost. A simple assignment changes an object's type! That should pretty well destroy any regard you might have for C++ or Eiffel (or probably C# as well) if you think UnsupportedOperation is such a huge problem for java. Of course, it turns out to be fairly practical even though it is about the most anti-OO concept there is.

Re:a 'few' rough edges

[Trillan]

My apologies that I misunderstood your comment. :)

Re:a 'few' rough edges

[Cyberax]

I know, I write lots of Java code myself (server-side applications, mostly). Java and C# work fine for these types of software.

But fortunately, not all software is server-side :) There's a great demand for small memory footprint fast client applications.

Re:a 'few' rough edges

[leomekenkamp]

That's ok :-). About 80% of normal communication is non-verbal, so we humans tend to miss a lot on these kinds of discussions.

Re:a 'few' rough edges

[0xABADC0DA]

Surely separate interface and inplementation files are a good thing?! Isn't it good OO design practise to keep a definition away from the grubby internals. I mean, that's why you actually have interface types in Java that cannot contain code, or enjoy implemetation inheritance.

Way to miss the point, dude. Dot-h files are an anachronism. They don't provide anything useful except a kludge so other source files will compile against a type without re-compiling everything for each file. Java doesn't need dot-h files; the api is viewable in JavaDoc and other ways.

I once worked with someone who was tasked with adding a new entry to something, and each entry was masked with a bitmask.. so we had #define A 1, #define B 2, #define C 4... and he quite rightly tagged a new one on the end.. #define D 5. A little knowledge of how computers work would have saved us some trouble there

Nice, you defined a bitset in DECIMAL?! N00b. Quick, what's bit 22 in decimal? Define them (1<<bit) or in hex. But you choose C++ because you are such a competent programmer huh? More likely you choose it so you can blame things on co-workers or that "programming is hard"

and besides, what is the difference between add() and operator+() except how the programmer types it?

What does "i + j" do? In Java there are fewer possiblities than C even. In C++ you have no way to know without looking at the implementation of both types, and looking for global type conversions. So basically you have to know the entire codebase to be certain; the "magic" factor of scripting languages combined with the exactness required for C.

Re:a 'few' rough edges

[2short]

"I mean come on, "::" to separate class from method name, pure virtual destructors, separate interface and implementation files"

You mention these as if we are supposed to automatically know what you think is wrong with them. I'm not sure what you find objectionable about these, but from the rest of your criticisms, it's pretty clear you don't know much about C++.

"can't nest templates because >> is a token"

Of course you can nest templates. You just need a space between the ">" charachters. Bjarne is annoyed by this, because he's enough of a purist that he doesn't like having whitespace next to an operator be significant in this one case only. In principle, I agree, in practice, it's no big deal.

"references *and* pointers"
Which are different, and both useful. Which really goes to the philosphical difference between Java and C++. If there are two ways to do something, Java gives one (the one that's usually best); C++ gives you three. (The one that's usually best, the one that you might sometimes want instead, and the one that really shouldn't count because it's invariably a bad idea.)

"no garbage collector (even optional)?"
There are several libraries that provide garbage collectors, which are hence obviously optional. Programmers rarely opt for them. You can either take this as an argument for making them required, or against GC in general.

"cin >> s, shift right or method call?"
Method call. I guess I can see the theoretical problem there, but in practice, I've never run across a case where it was even close to being an issue. You'd have to be trying pretty hard to intentionally obfuscate your code for me to mistake it. (e.g. if 'cin' in your example isn't a stream.)

I think Java is successful because it makes things simpler for the programmer by reducing the available complexity. You only have to worry about learning one way to do it because there is only one way to do it. Frequently, that's an excellent trade-off. Java is quite expressive, so if you don't need the additional expressive ability of C++ there is certainly no need to deal with the complexity. (I'm not trying to insult any one here, but if someone has difficulty handling the complexity of C++, they may be more productive in Java. This is a genuinely useful feature of the language; for a businessperson thinking in terms of programmer pay scales, it may be huge.)

But I wouldn't fault C++ for it's complexity; it's design goal is to be as powerful as possible, within that, it should be as simple as possible. Many fault it's complexity, but I've yet to see anything simpler that retains all the power.

Re:a 'few' rough edges

[TheGavster]

I could deal with Java having a gc, provided that it also had a way to manually dispose of an object. Watching 100MB of scratch space that was in use for 1s sit around eating memory for the next hour is not my idea of a good time ...

Re:a 'few' rough edges

[Decaff]

Yes it does. Under C++, cleaning up of resources no longer used is the responsibility of the programmer. This is not the case with Java - so you are implicitly forced to use the garbage collector.

No you aren't. Garbage collection is assumed but is not required. An example of Java with no garbage collection is Card Java, a version of Java for embedded use.

Re:a 'few' rough edges

[Decaff]

The point about introspection in Java is that it _always_ costs you in performance and memory/disc use. Even if you're not using it.

Nonsense. There is no additional code or hooks placed in compiled Java to allow introspection, so there is no additional performance, memory or disc cost if you don't use it.

Re:a 'few' rough edges

[Bob Uhl]

But I wouldn't fault C++ for it's complexity; it's design goal is to be as powerful as possible, within that, it should be as simple as possible. Many fault it's complexity, but I've yet to see anything simpler that retains all the power.

Common Lisp, perhaps? Compiles to tight machine code; doesn't need templates; is object-oriented; possesses multi-methods (which C++ doesn't have); supports multiple inheritance; has a REPL; has full access to the entire language at read time, compile time and run time; it has macros which Don't Suck (and in fact are a valuable part of the language).

Re:a 'few' rough edges

[EvanED]

The problem with C++ is that is was built with focus purely on technology and seemingly without any effort to human factors at all

Actually, if you look into it I think you'll find that a lot of design decisions were made with the design of compilers in mind. Maybe not simple stuff like the >> as a token problem, but a lot more.

I mean come on, "::" to separate class from method name

What's wrong with that? It's probably because I used it first, but I prefer :: to Java's .

Besides, if you're trying to defend Java, would you like a list of about a dozen syntactic disadvantages of Java over C++? ...separate interface and implementation files...

First, I must say I still prefer the C++ approach to the Java/C# one file approach. Want to look up a function? It's easy... you don't have to wade through implementation crap you don't care about. Sure, if the programmer was nice in Java you'll have an interface you're looking at, but programmers are not always nice. (I realize this is significantly less of a problem with an IDE that will present you with a list of the members.)

Second, want a single implementation and interface file in C++? Great. Write one. C++ lets you.

Third, it's the easiest way to allow people to distribute binaries without source while still maintaining C++'s increased compile-time type safety over Java.

with operator overloading it is impossible to know what a C++ code is doing (ie, cin >> s, shift right or method call?).

No it isn't, not any more impossible than it is with Java. Is cin or s an object? Then you have a call to an overloaded operator. (Okay, C++ allowing automatic conversions muddles things somewhat, but I'd still kill someone to get operator overloading in Java. It cleans up a LOT more than it muddles.)

Re:a 'few' rough edges

[0xABADC0DA]

But I wouldn't fault C++ for it's complexity; it's design goal is to be as powerful as possible, within that, it should be as simple as possible. Many fault it's complexity, but I've yet to see anything simpler that retains all the power.

Are C++ backers intentionally trying to miss the point? The post was about human factors.

You really have no clue that "::" is a horrible choice of name separator, especially since "." was already used for that purpose? Or that requiring a space in nested templates because writing the BNF for the compiler would be too hard otherwise is a crappy excuse from a human interface POV? Or that requiring google searches for add-on hacks just to get basic functionality from over three decades ago is not 'power to the people'?

"cin >> s, shift right or method call?"
Method call. ...(e.g. if 'cin' in your example isn't a stream.)

Doesn't that just say it all? First you accuse me of being ignorant of C++ but then you assume "cin" must be an io stream because no competent developer would use that name otherwise. So you made an assumption, and based on data you think is wrong to begin with. You did that to mask the fact that in C++ simple statements like "a + b" require a lot of context to know what is really happening.

And this is what I'm talking about: human factors. Bjarne says that "a * b" for matrix multiply and "a <something besides .> b" for dot product is better because it looks like what it does, semantically (except for dot product...). But ultimately that is just saying the code for matrices should look quite pretty. Never mind that b is a string and is converted into a 1xN matrix using an automatic implicit conversion. Oops.

Of course you can nest templates. You just need a space between the ">" charachters. Bjarne is annoyed by this, because he's enough of a purist that he doesn't like having whitespace next to an operator be significant in this one case only. In principle, I agree, in practice, it's no big deal.

Enough of a purist?! You can nest templates like this: "outer<inner<type> >" but not like this: "outer<inner<type>>". That's not an annoyance, it's absolutely moronic from a human design POV. I mean I hate to harp on this since it is just one of many instances of the same poor design, but this what really irritates me about C++... there's just so much bullshit nonsense in it.

Re:a 'few' rough edges

[kscguru]

Are C++ backers intentionally trying to miss the point? The post was about human factors.

Nope - you are over-simplifying the language. Really. C++ is already as simple as possible without sacraficing power. By trying to portray it as simpler, you conveniently create straw-man arguments that just aren't true.

You really have no clue that "::" is a horrible choice of name separator, especially since "." was already used for that purpose?

"::" is necessary. In C++ there are many ways of naming a function, and three symbols. "->" means call through a vtable. "." means call through static dispatch. "::" names a specific version - a concept orthagonal to calling. (Ever tried calling a specific parent version of a function in Java? It's a lot harder than in C++, and I have a very good reason to do that two or three times a year). Don't assume C++ has Java's over-simplified version of OOP; C++ is much more powerful (albeit harder to use!)

Or that requiring a space in nested templates because writing the BNF for the compiler would be too hard otherwise is a crappy excuse from a human interface POV?

You expect a 1995-grade compiler back in 1985? Fine, while you're at it, can you complain about LPs, I'd like those to be standard again too... The point is, when C++ was born, that BNF was too hard to write outside of academia, and it took those extra ten years before computers and compilers that could handle it were available.

Or that requiring google searches for add-on hacks just to get basic functionality from over three decades ago is not 'power to the people'?

Your definition of "basic functionality", not mine. I'm quite happy writing code without cramping my style around garbage collectors. I'm not demanding you stop using GC, so I'd appreciate it if you stop demanding that I must use GC. I find GC moronic, I can manage memory perfectly well on my own thank you (I learned it very well while becoming a kernel programmer).

"cin >> s, shift right or method call?" Method call. ...(e.g. if 'cin' in your example isn't a stream.) Doesn't that just say it all? First you accuse me of being ignorant of C++ but then you assume "cin" must be an io stream because no competent developer would use that name otherwise.

He's exactly right. "cin" always means "character input stream", just like Java's "clone" always means "deep copy of an object" or C's "errno" always means "error number".

Bjarne says that "a * b" for matrix multiply and "a b" for dot product is better because it looks like what it does, semantically (except for dot product...). But ultimately that is just saying the code for matrices should look quite pretty. Never mind that b is a string and is converted into a 1xN matrix using an automatic implicit conversion. Oops.

Me, I blame the fool who thought a string should be a 1xN matrix and got slap-happy with automatic type conversions. Operator overloading is a way for a programmer to make semantic conventions that are blindingly obvious be reflected that way in the code; they are not a tool to hide programmer laziness. And unnecessary typecasts are a sign of poor design and laziness (a programmer problem), and not a problem with the underlying language.

C++ ain't a perfect language. But I like the power of C++. If you don't appreciate that power, fine ... but realize there are a lot of people out there who do, and your uninformed criticism doesn't dampen my love of C++ in the slightest.

Re:a 'few' rough edges

[kscguru]

So the language is responsible for the perversions that retarded coders put it through?

YES, when those retarded coders write the specs for the standard libraries (namely, the Java Class Libraries).

C'mon, that's the whole point, the standard library's specs are the language...

I could read stupid C++/D/C/Ruby/whatever code and then blame the language too, you know.

If they're part of the core libraries, sure!

Re:a 'few' rough edges

[Anonymous Brave Guy]

You could make an argument that the standard library should be designed that way, maybe with a root List interface and then a MutableList subinterface, but you could also make the argument that going that way doubles the number of classes in your collections API. Matter of taste, perhaps.

Or you could just use a language that supports the concepts of mutable and immutable data natively, like C++...

<ducks>

Re:a 'few' rough edges

[igi]

If those are the motivations, we should have an ImmutableList class without an add function, and derive the List with an add function from it (in C++, probably by private inheritance, that is, inheritance of implementation). Only the List class with the (working) add should publically inherit from the interface with an add function.

This is a bad solution. If List inherits from ImmutableList, this implies that List is an ImmutableList. Since that is not the case, this is obviously a bad design.

Also, your solution would be impossible to implement if you don't have control over the List class. For example, the List class could be a part of a component you can't modify, or even a part of your programming language.

Re:a 'few' rough edges

[James_Aguilar]

Er . . . there's no such thing as a MethodNotSupportedException exception. Actually, there's not even anything that matches the first two words, MethodNot.

Are you thinking about NoSuchMethodException? NSME is thrown when you're using reflection and you reflectively request a method by name that doesn't exist using something like Class.getMethod(String name). Or perhaps you meant to say CloneNotSupportedException, which is just a fancy way of saying, "Nope, you can't copy me."

Reflection is/was an artifact of not having generics (which is, by the way, the only reason why C++ doesn't need those kinds of RTTI keywords as well). Bagging in Java for not being OO is taking the Slashdot-flavor unsupported criticism a little bit too far.

Re:a 'few' rough edges

[Profound]

Newspeak is closely based on English but has a greatly reduced and simplified vocabulary and grammar. This suited the totalitarian regime of the Party, whose aim was to make subversive thought impossible.

Java is closely based on C++ but has a greatly reduced and simplified vocabulary and grammar. This suited Sun Microsystems, whose aim was to make "bad programming practice" impossible.

Winston stopped typing and looked up from his monitor to the giant telescreen where Sun had released the latest benchmarks. Java was faster than C++. Java had always BEEN faster than C++. He looked at his editor:

try {
if( (new Integer(2)).add( new Integer(2) )).equals( new Integer(5) ) ) {

He kept typing. His mind was clear. He was happy. He loved James Gosling.

Re:a 'few' rough edges

[n3k5]

Dear moderators: parent does not demonstrate/explain an over-reliance on instanceof operator, nor a harmful use of MethodNotSupportedException, thus parent post is utterly wrong and not '5, insightful'.

Writing OO programs is pretty much all Java is any good for, to the point that people will even make an OO design where it is counter-productive (e.g. a small programm that would be under 200 lines if done the procedural way). But OOP it does well, and even the minor flaw that was bickered about for 10 paragraphs doesn't exist in reality.

Of course you can always 'trick' a user of your API by overwriting some known method with another one that does nothing, crashes the machine or formats the harddisk. You don't need a MethodNotSupportedException for that. This exception is not meant to break something that worked in the superclass, and in the standard libs it's never used in that way; so if you do that, it's your fault alone. It's meant to be used when you implement an interface, or subclass an abstract class, that says about one of its methods, "this may be implemented, depending on wheter that makes sense at all." So, by implementing it maybe, all promises are perfectly kept and no one is tricked.

Maybe you don't understand why one would do that, instead of just defining a method only for those subclasses that really implement it. I can assure you that in about 99,99% of all cases, it's done the latter way anyway, but in some rare cases using MethodNotSupportedException does make some sense, and you can use it without any reflection code. If you need the instanceof operator to deal with it, that's not an indication of a flaw with this particular exception, but the flaw is your dumb design.

I'll give you an unrealistic (no one implements TV sets), but easy to grasp example: A subclass of AbstractTvSet will only support the setColourTemperature method if it is a colour TV. The idea is that your code will only try to call this method where it's known that you're dealing with a colour TV; if you call it for a monochrome one, you made a mistake; this should never have happened, hence there is an exception.

And finally, parent's claim that commonly used collections (Java lingo for 'container class') make use of this exception? Wrong.

Re:a 'few' rough edges

[2short]

I haven't used any Lisp in the last 10 years, so I'm not really qualified to comment on its simplicity/power vs. C++. When I did use Lisp those many moons ago, I thought it was neato, and very cool from a theoretical standpoint, but not something I'd want to do major development in; and that was before I even knew what major development was. Anyway, I don't really know squat about Lisp these days, except that its fans think its the greatest thing since sliced bread, yet still almost nobody uses it outside academia. But anyway, I'll bite, what's a multi-method and why would I want one?
Actually, I set out to write this post in a somewhat confrontational mood, so I went to your website to see if I could rag on you for being an academic. Sadly, not only are you apparently not an academic, you sound like an interesting guy, and to top it off, you're a fellow Boulder Cruzer. Now who am I going to be obnoxious to? Oh well, Happy Thursday.

Re:a 'few' rough edges

[2short]

kscguru pretty much wrote my reply to most of your points, so uh, what he said. But I can't help piling on a bit too.

"You really have no clue that '::' is a horrible choice of name separator"

No, I really had no clue about that. Here I had been thinking it was a perfectly fine choice, easy to type, readable, I don't know, how many things can you say about a choice of a couple charachters? it always seemed fine to me. Thanks for setting me straight with your blind assertion though. Um, you do realize "." is already used for something quite different?

C++ gives you all the power it can. This is more than enough power to let you do stupid things and create entirely impossible to understand code if you want. But I'm sure that even in Java a skilled programmer could write obfuscated hard to fathom code if they tried.

"you assume 'cin' must be an io stream because no competent developer would use that name otherwise"

Yes, that is exactly why I assume 'cin' must be an io stream: no competent developer would use that name otherwise. In fact, no incompetent developer would use that name otherwise. The only developer who would use that name otherwise is one bent on deception.

"Never mind that b is a string and is converted into a 1xN matrix using an automatic implicit conversion. Oops."

That's not an "oops". It's an "aha! gotcha!". C++ will indeed let you do what you want, even if what you want is to define intentionally deceptive conversions. It's not like someone accidentally made that conversion automatic; they wrote a whole extra function on top of what was needed for an explicit conversion whose sole purpose was making sure it would happen without specifying. They really wanted to make it work that way, and you want the language to forbid it? Even though forbiding that will forbid vast swaths of things that do make sense, and have teremendous expressive power in the hands of a skilled developer? Stay away from my language please.

"You can nest templates like this: 'outer<inner<type> >' but not like this: 'outer<inner<type>>'. That's not an annoyance, it's absolutely moronic from a human design POV"

I'd phrase that differently: From a design POV, it's absolutely moronic. In practice, it's not an annoyance. Seriously, I've devoted more thought to that in the course of this post than in my last decade of coding. Practicality-wise, it's a non-issue. Theory-wise, I'm glad they're fixing it.

Re:a 'few' rough edges

[gbjbaanb]

n00b? lol.

Funny you should look at that 1-line sample code as production code, not an example of the point I was making. If you prefer the letter of the text, not the spirit.. are you a lawyer?

As it happens, the macros were in hex (as always, but hey - decimal 4 is.. hex 4 anyway), and the colleague was defended by me (he was a programmer who had cross trained without the benefit of a computer science background so didn't understand bits and bytes, just like many Java programmers nowadays who are taught how to use Java, rather than how computers work)

what does "i+j" do? Depends on the object doesn't it. what does "i.add(j)" do? .. exactly the same, only doesn't help readability. Do you have to check the codebase for the .add() method, sure you do - and in Java, you have to check base classes, and interface implementations too! Not much difference there from C++ really.

As for a split .h/.cpp files - its good practise to separate design from implementation. ITs only these new languages that think they know better - and new programmers who think that 'cos Java does it one way, all other ways are obviously obsolete in the face the brave new world of cool new features, regardless of any validity.

Re:a 'few' rough edges

[/ASCII]

You are thinking about this in the wrong way. A compiler implementor can choose to add special compiler hooks to make sure performance critical library calls are handled directly by the compiler in the most efficient way possible. GCC does this with loads of C functions like string handling and memory copying functions.

Re:a 'few' rough edges

[dkf]

If you use instanceof more than once every, say, 10000 lines of code, I will fight you.

This all depends on whether you need to vary things by the type of the actual object along multiple axes simultaneously (and also on how large your class definitions are. ;-) OK, some languages support such things (Common Lisp with CLOS is one such example) but neither Java nor C++ do. Sometimes, the right thing to do is to refer the action to the other class and use the inheritance hierarchy to sort it all out, but not always.

One place where you do tend to need instanceof a lot is in basic equals() method implementations, since if things are of a different type, they're definitely not equal and yet you don't want to throw a type exception since you can correctly determine that they're different. It's when things are the same type that you have to do more work. If you're going to insist on avoiding instanceof because of some prissy rule on what you think OO is, you're going to have to do something even more gross instead, like catching all exceptions in code, or even comparing the serializations! Or are you just relying on the lame built-in object identity rules? (Oh well, at least they're controllable.)

Pragmatic programmers use instanceof where necessary (just like any other tool provided). Language fascists foolishly try to castigate them for this. But that's always been the way.

Re:a 'few' rough edges

[ckaminski]

Third, it's the easiest way to allow people to distribute binaries without source while still maintaining C++'s increased compile-time type safety over Java.
</quote>

Java .class files allow one to do this as well with compiled binaries, and throwing Javadocs in .JARs with your classes takes care of the documentation aspect of not having headers.

C++ doesn't *WIN* here, but I don't think it loses either. Different ways of accomplishing the same things I guess, but I do think Java's is simpler, and in some instances, better.

C++ programmer of 11 years, Java of 5.

Re:a 'few' rough edges

[Anonymous Brave Guy]

Now getting back to C++, you are not forced to do anything except write code like the following:

T & list::iterator::operator* () const
{
return current->data;
}

Yeah I suppose this is obvious, and simple! (NOT)

If you think that syntax is difficult, sure, maybe C++ isn't for you. To anyone who understands basic C++ ideas like references, scoping, const correctness and operator overloading, that's a pretty trivial function. C++ isn't really aimed at someone who isn't willing to learn these things, and that sort of person shouldn't be using C++.

If, however, you find the concepts involved difficult, maybe programming isn't for you. Any programmer who thinks using Java or Python or whatever means they don't have to understand ideas like indirection and iteration is pretty much a liability.

Re:a 'few' rough edges

[ckaminski]

ImmutableList should throw an "ImmutableListException" when an add() is performed, although indeed, add() should probably be private to help prevent this from ever happening explicitly.

Objects should throw domain appropriate exceptions or return appropriate error codes, as opposed to "virtual function not present exceptions".

Re:a 'few' rough edges

[ckaminski]

Sadly enough, C++ will let you shoot yourself in the foot and the knee and let you cast away constness... Eeep.

Re:a 'few' rough edges

[Bob Uhl]

I used to think exactly the same thing about Lisp--my college exposure to it was...less than ideal. It was presented as a theoretically interesting language with little practical use. It seems that a lot of folks had the same experience. While you can program in a functional fashion, Lisp also supports procedural, imperative, object-oriented and structured styles (and probably more). There's even an equivalent to goto:-)

Believe it or not, though, Common Lisp was designed for building extremely large systems. It has everything one would want for that, from low-level stuff like bit vectors and structs on up to packages and the like. The standard library--large for the late 80s/early 90s--could use some expansion, but that goes for C and C++ too:-)

A multi-method is very cool. Most object-oriented languages use a message passing paradigm: a method is a message which is sent to a particular object. obj.method(arg) is really a kind of syntactic sugar for method(obj, arg). Well, in C++, Java, Python or SmallTalk all you can do is specialise method() on its first argument--not on any of the rest (without using method overloading in languages which support it, of course). Lisp is different: methods don't belong to classes, but rather to a generic function, any or all of whose arguments may be specialised for a particular type.

So you can get exactly the same behaviour as a typical message-passing language (by specialising on the first argument), but you can can also do so on any of the other arguments (or not--so you can have catch-all methods too).

One of the nice side-effects of having methods owned by generic functions is that you don't need to worry about which class should own the overloaded method. If you decide to overload method(arg1, arg2, arg3) based on args 1 and 2, where should that definition live: in the class of arg1, in the class of arg2, or elsewhere? With Lisp you can put it anywhere. It's been awhile since I've played with C++ or Java; they may support some way to kinda get this (friend methods?), but it's still not as clean.

In fact, you can define a new method at runtime--and it will be compiled and run as well as one of the original methods.

You can also define special methods to run before, after or around the normal methods, and can specify funky ways in which to combine different methods--there's an awful lot of power available.

Man, can I write! Hope that you're not too bored by now.

Glad you liked my site. I'm certainly no academic! Maybe we can grab a beer sometime. Happy Thursday!

Re:a 'few' rough edges

[GamblerZG]

The fact that the language is aimed at elitists does not make an excuse for poor syntax.

Moreover, the syntax above is _nothing_ compared to stuff you encounter in real-life aps.

//what the hell is this?
float (*GetPtr1(const char opCode))(float, float)
{ //function body
} //or this?
template <class BASE, class ITEM, const IID *IFACE>
loEnumIface<BASE,ITEM,IFACE>::~loEnumIfac e<BASE,IT EM,IFACE>()
{
UL_TRACE((LOGID, "loEnumIface::~%p", this));
destroy_list();
}

Re:a 'few' rough edges

[2short]

Actually, in college, Lisp was presented to me as the ultimate language that would eventually take over the world :)
It seems to me that all the things you describe multi-methods doing are pretty directly achievable in C++. Functions can be specialized on any and all of their arguments, and can be members of particular classes or not. (You say "without using method overloading", but I'm not clear why one shouldn't).
But note that foo.bar(baz) is not just syntactic sugar for bar(foo,baz). If bar is a member of foo, it has special status; it can access private members of foo and other objects of its type; it does not just operate on foo, but is part of it. The "friend" keyword you mention allows methods that are not part of an object to access its private members, but that's a pretty rare case for tightly-coupled types. Definitely one of those things you should, as a rule, not do, but C++ will give you a way to do it, because sometimes it's best to bend the rules.
If Lisp methods aren't owned by particular classes, does it (or how does it ) provide a mechanism for enforcing abstraction barriers? The ability to present an interface, and prevent any aceess to implementation is certainly something I'd consider basic to large-scale development. I don't see how to do it without the "member" concept.

Re:a 'few' rough edges

[julesh]

There is no additional code or hooks placed in compiled Java to allow introspection, so there is no additional performance, memory or disc cost if you don't use it.

Actually, there is: along with each clss is stored a copy of its name, the name of its superclass, the names of the interfaces it implements, the names and types of all its member variables, the names and types of all its methods and details of the exceptions they throw.

In an average class, that takes up more space than the bytecode. A version of Java that didn't support introspection would probably be half the size, start about 20% faster, and use about 10% less memory.

Re:a 'few' rough edges

[julesh]

What has that got to do with GC implementations?

The general problem with GC when not part of the language itself is that you have two choices:

1. There must be some way of telling the collector exactly what is a pointer and what isn't (in a GC language, the language environment takes care of this for you).

2. Alternatively, the collector must assume that everything that might be a pointer is a pointer. This is not efficient; the collector will probably end up scanning more memory than it needs to and keeping objects that should be discarded.

How does something like GCC's intrinsic functions help with this problem?

Re:a 'few' rough edges

[Bob Uhl]

Well, when one defines a class in Lisp, one defines its members (called slots); each member can take a default value, and can have accessors defined (e.g. so that one can write (foo bar) instead of (slot-value bar 'foo) (you can define either a reader, a writer or an reader/writer). The idea is that if an accessor is defined then it's public; if not it's private. If you need to access the private slot, you can--but if you do, then be prepared!

Lisp takes the same approach with packages. foo:bar indicates the value of foo's exported bar; foo::baz indicates foo's baz, whether or not it was exported. Lisp lets one use encapsulation, but also lets one get around it if necessary. I forget now how doable that is in C++ or Java; Python, of course, pretty much doesn't do the encapsulation thing:-)

I thought that in C++ the owning class had to declare its friends and that any random class or function couldn't declare itself a friend--it's been years, though, so of course I could be wrong. The problem with this is that the owning class might be in a library and doesn't know anything about the code which uses it. Naturally, if I'm wrong and anything can declare itself a friend, then this doesn't matter.

Re:a 'few' rough edges

[Decaff]

Actually, there is: along with each clss is stored a copy of its name, the name of its superclass, the names of the interfaces it implements, the names and types of all its member variables, the names and types of all its methods and details of the exceptions they throw.

Those are nothing to do with the compiled code itself - they are present as part of the header of the file which contains the compiled code. This imposes no performance penalty.

In an average class, that takes up more space than the bytecode. A version of Java that didn't support introspection would probably be half the size, start about 20% faster, and use about 10% less memory.

Yes, but I was assuming that the original poster was talking about running speed (performance) rather than start speed. Also, there is going to be very little impact on memory, as this information is stored per-class, not per-instance.

Re:a 'few' rough edges

[julesh]

Yes, but I was assuming that the original poster was talking about running speed (performance) rather than start speed.

From the original post I replied to:

there is no additional performance, memory or disc cost

I'll admit the biggest cost here is in disc space, but it is a cost, and is part of the reason the JRE download is so f'ing huge. (I recently had to port a web system that used an applet to flash because the client felt the JRE download was too big to justify it...)

Also, there is going to be very little impact on memory, as this information is stored per-class, not per-instance.

Well, that's true, but there is a *lot* of that information. I've done some work on an experimental JVM, and I have a switch to tell it not to load the reflection information: if I use it, memory usage drops by about 2Mb for most applications.

Re:a 'few' rough edges

[2short]

"I thought that in C++ the owning class had to declare its friends and that any random class or function couldn't declare itself a friend"

Exactly.

"Lisp lets one use encapsulation, but also lets one get around it if necessary"

Ack! If you can get around it, it's not encapsulation. I write a class, and carefully expose a few member functions for others to use, sealing away the implementation. A couple years go by, during which a dozen other developers might have writen code that uses my class. Now I want to change part of the implementation. Can I do so without breaking any code? Note that I can't ask everyone who might have used my class because some of them have been fired for being the sorts that would unnecessarily ignore encapsulation if they could. This is not a hypothetical situation; I'm faced with this regularly.
In C++, I know that if the public members retain the same behavior, nothing using this class can break. (Unless it's a friend, but you almost never use friends, and as noted, you declare them in the class whose internals are being exposed, so you know about it) This is what I mean by large-scale development: I can work on one part of the code and have garauntees that I won't break anything in a code base containing code I know nothing about.
If developers decide to take the risk of relying on private stuff in a library I wrote, it sounds fine to say, well it's their problem if I change the library and their code breaks. But it's not fine, because they don't work here anymore, and I'm responsible for maintaining their code. And in my case, they outnumber me twenty to one! (Yes, I've been here too long; well, not really, only in the sense of being the most qualified to fight fires in far too much code)

Re:a 'few' rough edges

[Decaff]

From the original post I replied to:

"there is no additional performance, memory or disc cost"

I don't think we are talking about the same thing. I am not talking about the basic symbol information stored in class files. The post I replied to said:

"The point about introspection in Java is that it _always_ costs you in performance and memory/disc use. Even if you're not using it"

I understand introspection as "Studying a Javabean with reflection to discover its properties" (from the Java Glossary at mindprod.com).

My point was that the ability to use reflection does not require any extra information to be added to class files above what is already there, therefore the ability to use this facility does not cost you anything, either in terms of performance or size.

I suspect we are using terms like 'reflection information' differently. This terms implies information put into classes specifically for use by the java.lang.reflect.* API. If you look at the official class file specification the terms 'introspection' and 'reflection' are not even there. This information is present so that the ClassLoader can dynamically resolve classes and methods.

That is how I understand things.

Re:a 'few' rough edges

[Bob Uhl]

But the thing is, sometimes the implementer of the library doesn't expose his interface properly. The world's imperfect, and one can't really just use another library instead. If one needs that functionality, then one can't just simply say, 'oh well--I just can't do it.'

Lisp gives you the ability to make an end-run around the encapsulation, but it also makes it obvious (for classes: (slot-value object 'foo) rather than (foo object); for packages package::var rather than package:var)--and many compilers issue warnings. Also, since development is so fast, fixing code which did depend on internal knowledge is generally not a problem if it does come to that.

And since it's been used for some very large systems, I think that it works.

Really, C++ does the same, since members are just slots in a struct, and with a pointer to the struct one can pull anything out one wants *grin*

Re:a 'few' rough edges

[2short]

I find the argument in your first paragraph uncompelling. Fix the library, use a different one, or work around it in a maintainable way. If the implementer didn't expose the functionality you need, that library doesn't provide the functionality you need. It doesn't mean you just can't do anything; you do whatever you would if the library didn't provide the function at all. The fact that you know what private members do the thing you want implies you've got source, so you're hardly completely out of luck.

"Lisp gives you the ability to make an end-run around the encapsulation, but it also makes it obvious"

It's obvious in the calling code. It's not obvious if all I look at is the library code.

"Also, since development is so fast, fixing code which did depend on internal knowledge is generally not a problem if it does come to that."

There is no such thig as development that fast. I once accidentally broke backward compatibility in the public part of a library I wrote. The compatibility break was somewhat obscure, so it didn't cause problems imediately. But a couple years previously, someone had written some code using that behavior. A couple years after I made the change, a major clients server-based app goes down for an unrelated reason. The bug that brought them down was easy to find and the fix was simple: they needed the updated version of this one library; I recompiled; and now it's broken in a totally different way. Now I'm trying to find a subtle bug in a large amount of four year old code I've never seen before, while dozens of users are sitting on their hands. That sucked incredibly. In that case, I should have known I was causing a problem. Without working encapsulation, I couldn't know, and this would be happening constantly.

"And since it's been used for some very large systems, I think that it works."
Well, assuming you're defining "large" the same way I am (number of developers and amount of time in development) I can only assume that they enforced encapsulation externally to the language. i.e. they turned on the warning you mention, and didn't allow code that generated it. I'd just prefer the compiler do the enforcing, rather than the boss.

"Really, C++ does the same, since members are just slots in a struct, and with a pointer to the struct one can pull anything out one wants *grin*"

Well, that will only work for data members. I don't think you're going to be able to deduce the address of a member function, and it's obviously impossible if that member gets inlined, or for that matter, never generated. While it's probably a data member you want to get at, anyone who has the knowledge to do that probably has the wisdom not to.

I'm dealing with code written by maybe 30 people over 8 years. Many are not the sorts where I want to rely on their having been wise. Quite a bit of this code is in the category where if I have to do much of anything to it maintenance-wise, I'll probably need to rewrite it, but if I don't break it, I don't have to.

I don't know, people get by and get stuff done in coding environments I can't imagine working in. I'm sure Lisp is great for many people, and you're more than welcome to go with it. I'm just saying that for me to use a language, a lack of hard encapsulation is a deal-killer.

Re:a 'few' rough edges

[angel'o'sphere]

The point about introspection in Java is that it _always_ costs you in performance and memory/disc use. Even if you're not using it.


Please elaborate: how can a feature that is not used have costs?

Sorry, I'm glad if you can shed light io this, IMHO you are completely wrong.

More important: if you need such a feature and you WANT to use it, and it is not available and you implement it your self ....

a) how expensive would that be?
b) how much faster would your implementation be in relation to the standard language features?

angel'o'sphere

Re:a 'few' rough edges

[renehollan]

...lack of a turing-complete templating system? There was a real chance to develop a two-level language with better generics syntax than the C++ template monstrosity.

Re:a 'few' rough edges

[Da Fokka]

...lack of a turing-complete templating system?

Please forgive my ignorance, but how can a template system be Turing-complete?

Re:a 'few' rough edges

[renehollan]

You can write template metaprograms in it. In particular, you can, in theory, write *any* program in it, to be interpreted by the compiler. The output of such "programs" is, of course, normal text that the compiler compiles.

Look at "Modern C++ Design," by Andrei Alexandrescu for a greater discussion of the topic. It is fascinating.

Consider a simple example:

You need a table of sines and cosines to some degree of resolution for fast lookup. The compiler will not evaluate sin(some_constant) for you at compile time, but it can add, subtract, multiply, and divide constants at compile time. In the "old days", you'd write a separate program to compute the table and spit it out as a C/C++ variable initializer, and incude that in your "real" program. You could even compile, generate, include, and compile again in one big make. We all did this. Those of us in telecom did a lot of this to generate fast CRC "helper" tables (i.e. look up the next data byte in the table, shift the running CRC, and xor it with the table lookup; rinse, lather, repeat). With a Turing-complete template metalanguage, it's different.

You use the recursive capabilities of template definitions, with partial and full template specialization (i.e. T<int i, int j> is defined in terms of T<i, j-1>, with T<i, 0> specially defined, that is, partially specialised to end the recursion) to generate, at compile time, expressions of constants that, when computed by the compiler, will result in T&lti, series_steps> expanding to a constant expression that approximates sin(i/some_resolution).

Re:a 'few' rough edges

[renehollan]

Boy, that sounds like a slooow way to replace a lookup table. Programmatically it may be more elegant, but certainly not equivalent speed-wise, which is the real purpose of a lookup table.

You appear to miss the point. It may very well be slow, and probably is, but it is slow at compile time, and generates the fast table for you to use at run time.

In practice, I've written some knarly templates, and have not found the compile speed to be all that bad.

Re:a 'few' rough edges

[Da Fokka]

That's a pretty neat idea, first time I've heard of it. And you are right, you can't do that with C#. Still, C# has a lot of other features I really like.

Re:a 'few' rough edges

[renehollan]

Google for "template metaprogramming" for more information. It is cool stuff, but the syntax for it in C++ gets very ugly very fast.

It really appears as if template Turing-completeness in C++ was an accident. The syntax really does not lend itself well to it.

I'm curious ...

[The Mgt]

.. as to the pronunciation of 'C++0x'. Any suggestions ?

Re:I'm curious ...

[strongmace]

See Plus Plus Ox

...or you could just shorten it by taking out the plus plus and having C0x which is obviously pronounced cocks

Re:I'm curious ...

[sbb]

C++ heXtreme!

Re:I'm curious ...

[Trailer Park Boy]

That's 0x as in 05 as in 2005. So C++05 or C++06.

Re:I'm curious ...

[ceeam]

"Docs" (boring, I know).
Oh, here's another one: "cocks!" (slightly less boring).

Re:I'm curious ...

[rabidgoldfish]

chex ? (like the party mix)
cee hex ?
sechx ? (like butt sechs)

Re:I'm curious ...

[iabervon]

But C0x is an entirely different language (the development version of the successor to C99). If you want to make it easier to say, arrange it as C0x++, which is obviously pronounced "spam".

Re:I'm curious ...

[Jacked]

When I first saw it, I mentally pronounced it like "kooks".

Re:I'm curious ...

[Hepkat]

See plus plus oh not

Re:I'm curious ...

[Noah Adler]

(I hope this doesn't come off as arrogant, but there seems to be a lot of misunderstanding in the responses to this story.)

It's pronounced See Plus Plus, just like prior versions of the language. The name of the language is not changing-- this is simply a new version. It's like asking how to pronounce 'Linux 2.6.13' instead of whatever normal older Linux version you're used to.

Re:I'm curious ...

[Chris Burke]

Somebody throw that a +1, Funny because it was.

Re:I'm curious ...

[4of12]

That's 0x as in 05 as in 2005.

And, if things go like they usually do for standards committees,

x = 9
x = a
x = b

will extend the establishment right past 2010:)

Re:I'm curious ...

[Fredge]

Shouldn't this release just be called C+=2 ?

Re:I'm curious ...

[GoCoGi]

Even better: C=1

Re:I'm curious ...

[GoCoGi]

I meant C<<=1 of course. (slashdot html formatting)

Re:I'm curious ...

[Trejkaz]

It could go right past 2030 if they want to go to base 36...

Re:I'm curious ...

[sploxx]

Brilliant! Thank you.

Is threading going to be abstraced out ?

[Gopal.V]

Stuff that went into Boost should be in the standard library from now on... Also anyone who has had to use g++filt will agree with me that C++ STL error messages need to look less like the dog's breakfast :)

Re:Is threading going to be abstraced out ?

[yattaran]

Boost would be useful once they get rid of that annoying way to install it. No configure, make, make install ? Throw out the window for all I care. ;) STL errors with g++ are nothing compared to M$'s VC++. Last time I used it I easily got hundreds of lines of errors from the simplest error. Even when my code was correct I got errors.

Re:Is threading going to be abstraced out ?

[amightywind]

There are a lot of good ideas in boost. I use them in my work all the time. But there is also a lot of junk. I would be very selective about adding any of these classes to libstdc++.

Re:Is threading going to be abstraced out ?

[rmstar]

Last time I used it I easily got hundreds of lines of errors from the simplest error

I think this is more a fault of the language than a fault of the compiler. The syntax of C++ is one or two orders of magnitude too complex. You would need almost strong AI to produce sensible error messages.

This becomes particularilly "funny" when you try to teach C++ to full novices (FTR: I was following orders!). After a few days, the novices develop a tendency of not even looking at the error messages any more. The garble is pretty intimidating to them, and the compilers don't even get the line of the error right more than half of the time.

Re:Is threading going to be abstraced out ?

[jmccay]

Actually, some of the stuff is going into the library with TR1 (so technical release). C/C++ Users Journal has had a couple of articles on it in the last couple of months. I can't remember what the TR stands for at the moment, but all the stuff in it will reside in the std::tr1 namspace. They are anticipating on a TR2, TR3, etc because it is easier to get libraries passed than to actually change the language. If you read the background history on the Boost site, you will find out that Boost was created as a platform for future C++ libraries. If I remember correctly, tuples will be added with TR1. Possibly, variants will be too, but I am less sure on that one.

Re:Is threading going to be abstraced out ?

[jmccay]

Actually, what I was looking for (and had escaped my mind) was one of the following:

Library Extensions Technical Report 1

or

Library TR1

I knew TR stood for technical report. I have seen both of these refered to when introducing TR1 in articles--primarily in C/C++ Users Journal.
While I am mentioning it. You can download an older draft (January 2005) of TR1 here, and Scott Meyers has updated his page with information mapping items in TR1 to Effective C++ ( which is a must read for all C++ programmers).

Dogma

[roman_mir]

but that the language needs to shave of a few rough corners to make it easier to use for novices. - that is probably true. Analogy:

GLICK
Exactly! And that's what we're looking to do -
shake these people up a bit, get them motivated.
That's the whole point of the campaign. Mass
attendance is at an all-time low in this country.
And it's not like we're losing them to the
Protestants or Baptists - people aren't practicing
at any denomination these days. If we can sell
them some show - let 'em know the Catholic church
has some panache, we can win them back - even get
some new ones. Fill them pews, people - that's the
key. And cross-promoting - like with the cereal
tie-in grabs the little ones as well. Hook 'em
while they're young.
(sits at his desk, lights smoke)

RUFUS
Kind of like the tobacco industry?

GLICK
Oh - if only we had their numbers. But we are
aiming for the same demographic, even though mine
is the soul-saving biz. And if I have to play a
bit of the devil to bring them closer to the Lord,
then I'll wear the cloven hooves and carry the
pitch fork.


-
Today the battle is between Java and C++ and Java wins. Not because it's faster, because it is more convenient.

What C++ could use from Java? Why, an option to have garbage collection for starters. Just an option, not a requirement.

Re:Dogma

[bdcrazy]

There are garbage collectors for c++, however, you probably mean in the language or standard libraries right?

Re:Dogma

[gregRowe]

A garbage collector...like this one?

http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Re:Dogma

[Misroi]

C++ is just fine the way it is. If you want a language like java, go with c#.net

and you can also code c++.net, which has the option to use the .net framework and the .net garbage collector.

my personal opinion is c++ should stay exactly like it is. The more libraries the better. if you want some high level language, use c#.net. If you want a headache go with c++.net.

Re:Dogma

[orim]

Oh my sweet god. You want to put garbage collection in C++? That's about the only thing C++ has going for it: more control. With java, you still need to know what the language is doing with its memory, only there's not a damn thing you can do about it... you can only "hack", like have reusable objects. (when I heard this, I went: HUH?... talk about an ugly freaking hack...)

Yes, it gives you more to worry about in C++, memory leaks, and segment errors, but when coded properly, C++ is a thing of beauty.

Re:Dogma

[roman_mir]

here - a gc for C++, but I am talking about implementing this in native libraries.

C++ is a thing of beauty? There is nothing beautiful about it, like there is nothing beautiful about any computer language in itself. There are only beautiful implementations of ideas - compilers and other software.

"when coded properly" - sure.

Re:Dogma

[roman_mir]

Nope. I mean more people are taught Java and work with it than with C++. Java works well as the new Cobol but C++ does not work well as the new C.

Re:Dogma

[yattaran]

Today the battle is between Java and C++ and Java wins. Not because it's faster, because it is more convenient.

How is it more convenient ?
Java doesn't come installed on any OS I use.
Java doesn't fit into any OS or desktop I've used.
The GUI simply looks too different from the rest of the desktop.
It installs itself in the wierdest ways possible (configure, make, make install anyone??).
It even creates new directories under /usr/ that shouldn't be there.
Most java programs (that I've tested) even requires enourmous shell scripts to start the program.

I can't see how this can be convenient for anyone.

Re:Dogma

[roman_mir]

I mean as part of the compiler - built in option to not care about collecting your own garbage.

I mean that unlike Java, C++ compiled apps can have their own VM as part of the program added to them during compilation.

I don't mean that optional GC is the only thing that could benefit C++ to make it more attractive for novices. Standard libraries are already doing some of what Java does - string objects for example.

Re:Dogma

[roman_mir]

We are talking about developers here, not users. More convenient for developers.

Most of the applications in Java are server side, but projects like Eclipse (or what I created for Christie Digital - video software,) do well as is.

GUIs written in Java today can look like the rest of the platform, thanks to SWT. Eclipse project is partially Java partially compiled from C++, I believe that shows that Java is more convenient for developers to use, with C++ implementing as little as possible.

That is how for example I wrote video software (software that allows running multiple videos at the same time, do video capture, overlays, disturtions etc. - GUI is in Java, JNI to C++ layer and C drivers.)

Re:Dogma

[orthogonal]

"I sometimes find distributing an extra 30 MB [the .net run-time] a bit inconvenient."

Please download my new folding bicycle! Its lightweight aluminum frame means it's easily portable and rugged too! when not biking, fold it up and carry it under your arm like a briefcase! The perfect form of personal transportation!*

* Note: lightweight bicycle application is powered by a Soviet-era nuclear submarine, a separate download.

Re:Dogma

[roman_mir]

No, not like that one. A compiler option to ise GC or to use partial GC for example (sometimes you take care of memory, sometimes the GC built into your app by the compiler does. - easy to do, just always assume GC does all memory management but developer can clean memory by himself anytime.)

Re:Dogma

[roman_mir]

University of Toronto, where I used to go many years ago, now teaches courses in Java where it used to be C++ or Turing (OOT.) People still do study some C++ but it is not nearly as well understood by them as either C or Java. Strange, no? I am not saying the universities should create programers and not comp sci guys, I am saying C and Java get more exposure today and the fact that C++ is so much more weird than C or Java does not help the image.

I still write in C/C++/Java but I prefer Java now.

Re:Dogma

[CrazyTalk]

There is such an option - it's called managed C++ under .NET. Just use gcnew instead of new to allocate memory. OK, so I admit this isn't a universal standard, but it could be...

Re:Dogma

[gregRowe]

I don't understand. Libgc does all of that.

Re:Dogma

[roman_mir]

But it is not a standard. Besides implementing this on compiler level makes totally more sense for correctness and optimization.

Re:Dogma

[Deviant Q]

Today the battle is between Java and C++ and Java wins. Not because it's faster, because it is more convenient.

Actually, I'd urge anyone who thinks this is the case to consider C#. Yes, I know it's Microsoft, and yes, I know there's .NET involved, but...

I just love that language. It's a pleasure to code in; it fixes everything (IMO) that Java did wrong; it's very powerful and intuitive at the same time; the .NET framework class library is absolutely wonderful... I could go on and on. It's just awesome.

The only thing that pissed me off about it was the lack of templates, which (just like in Java) gives you some crazy boxing/unboxing issues like int i = (int)myArrayList[0];, but with templates ("generics") in 2.0 that's all fixed. It's beautiful.

Re:Dogma

[ckaminski]

Explain?

If you replace malloc()/free()/realloc() and new()/delete() how exactly can you get "MORE" correct and optimized with what are already "library" functions?

Methinks you are a troll.

The real problem is that different sharedlibs can indeed be linked to different memory allocators. Nothing in the C++ language will prevent you from called VirtualAlloc on Windows, or sbrk on Unix or whatever the syscall on your platform happens to be.

Re:Dogma

[ckaminski]

My biggest gripe is the lack of operator overloading. Other than that, I'm a happy java user, although C++ my first love...

Ick, humanizing languages. eep.

Re:Dogma

[roman_mir]

Setting up and running Eclipse is as easy as 1, 2, 3. A mix of Java/C++/C does the trick to make everything nice and easy for the user.

Re:Dogma

[julesh]

I mean as part of the compiler - built in option to not care about collecting your own garbage.

Well, what's wrong with having to use an external GC? It's not a lot extra work: a little time to download and install, then just include its header file, add its library file to the link command line, and use "new (GC) Object" instead of "new Object" where applicable. Not exactly rocket science.

Re:Dogma

[kbw]

C++ and Java are different tools for different jobs. If there is a battle, it's between Java and C#. It's just that C++ overlaps nearly every programming domain. No one tool is good enough; use what's required. Most environments support some level of interoperability with C, and so C++.

C++ is a system programming language that supports object oriented programming. It is general purpose. I see no reason to change it.

Please don't change C++, I mean look what happened to the latest C standard with its dynamic arrays etc. What a tragedy!

A couple of other points in response to previous posts.
1 - Well written C++ is a beautiful work of art. It is simply not true to suggest that beauty cannot exist in written code.

2 - A language level garbage collector has no place in a system programming language. If C++ can get away with library support for concurrency, it certainly can get away with library support for garbage collection. Why do you need garbage collection anyway? How do you manage the lifetime of your objects if you use a GC?

A better wheel

[Anonymous Coward]

Am I the only one who wonders why we need a successor to C or C++?

I've sat through the past 10 years and watched things like Java and D and Objective C come, but meanwhile most serious OS level and game development continues to be in C or C++. Doesn't this demonstrate that new language are merely a distraction to developers who haven't fully exploited the current set?

Re:A better wheel

[Radres]

Because sometimes you want to write something quickly without having to worry about managing memory, pointers, etc. If you're writing an application where every clock cycle counts, then yes, use C or C++, but in most cases you can get away with a little bit more CPU usage with the benefit of code maintainability. I suppose if you really had a section of code where minimal CPU usage was important, you could write that in C++ and import it into Java as a native interface library.

Re:A better wheel

[onnel]

No, it's more a signifier that different problems need different solutions. If all you have is a hammer, everything may look like a nail, but if you know c++, perl, php, java and a few others, your toolbox will contain an appropriate solution for a broad range of problems. I write my games in c++, my websites in php and my text parsing utilities in php. Java and python also serve their niches. Anyone who believes that a single language is the best solution to all of the broad range of problems faced by programmers is sorely mistaken. Onnel

Re:A better wheel

[roard]

Objective-C was created in 1983 by Brad Cox, then used on NeXT, so it's not exactly something that came in the last ten year ;-)

And actually drivers on the NeXT were written in Objective-C ;-)

Anyway, it's all a problem of using the right tool for the right job. Objective-C is excellent (particularly with AppKit + InterfaceBuilder on OSX, or with GNUstep+Gorm) for creating graphical applications.

If you need a very optimized code, you can do it in C, or C++... and still keep the rest of the app in Objective-C, as Objective-C is just a superset of C, and the Objective-C++ thingy let you mix C++ code an ObjC code in the same place...

But as they say, early optimisation is the root of all evils :-) which is why most of the time you're much better off with a high-level dynamic language than with a low level or static language. My opinion.

Re:A better wheel

[t_allardyce]

C/C++ will always be used in the most cutting edge power-hungry programs, which generally means games. C/C++ will also always be used to write libraries and drivers and low level things. However in the current market its far far more beneficial to be able to have rapid development and alteration as well as platform independence. For most programs it doesn't matter if they use lots of memory and CPU power because system resources are much cheaper than programmer hours.

Re:A better wheel

[Zerbs]

We don't need a successor to C or C++, Delphi's use of Object Pascal provides all the functionality, speed, and a slick IDE, without the awkward pains of C flavored languages and without the hastles of interpreted or pseudo-compiled languages like Java or C#.

Re:A better wheel

[squiggleslash]

FWIW, I find grouping C and C++ hard to stomach sometimes. C and C++ have as much in common as C and Objective C. I know C is the root of both languages, but they're not, generally, languages you'd use in the same way. They are unrelated except in origin. (ObException: I notice that Darwin's kernel contains a lot of C++ code. Surprising that. Of course, there's not much preventing it from containing Objective C code given the latter merely requires the static linking of two or three C functions, I think it's just that C++ is faster.)

So "most (...) development continues to be in C and C++" seems, to me, to be almost as strange as "most (...) development continues to be in FORTH and SmallTalk" (if that were true). You wouldn't talk about one successor to both languages, you'd talk about one successor to FORTH, and another to SmallTalk.

As far as C++ goes though, I think it has two competing successors, Java and C#, and I think the former is already eating C++'s lunch. While it's true a handful of application types are still using C++ (largely games), a quick look at the corporate world reveals where Java is being used (and where I suspect C# will find equal use.) C++ was beginning to take over from COBOL as enterprises migrated their old mainframe apps to Windows-type architectures, but that was pretty much shot down when Sun started to come up with credible versions of Java in the very late nineties.

Re:A better wheel

[styxlord]

Nah, the reason that games are written in C++ is because game programmers spend their "free" time playing games instead of learning new languages :)

Re:A better wheel

[squiggleslash]

Carbon's supported in Windows, funnily enough. Well, most of it. The Windows QuickTime environment supposedly contains most of Carbon. The story goes that Carbon was originally written as a compatibility layer to make it easier to port QT to Windows and then ported back to Mac OS/Mac OS X.

Re:A better wheel

[sinserve]

"Premature optimization is the root of all evil" - Hoare

That was Knuth, actually.

Re:A better wheel

[elflord]

Because sometimes you want to write something quickly without having to worry about managing memory, pointers, etc.

That doesn't in itself call for a "successor" to C++, that calls for a tool with fundamentally design goals. Such tools already exist, go right ahead and use them.

but in most cases you can get away with a little bit more CPU usage with the benefit of code maintainability.

"Most cases" is different for different people. But your example doesn't call for a "successor" to C++ anyway. Simpler languages, and safer languages already exist, but they're not really "successors" to C++.

Re:A better wheel

[clayasaurus]

Have you ever tried D? There is a better wheel.

http://www.digitalmars.com/d

Re:A better wheel

[m50d]

This *isn't* a successor. It's a little improvement. Not big changes, just a few things that should be touched up. A maintenance release, if you will. And it's a good idea. We've used it for long enough that we know a lot of the annoyances. Experienced programmers work around them, but it would be better to get rid of them.

I just hope it gets an implementation in my lifetime, given how I still can't find a C99 compiler. (Gcc breaks when you try and call functions with complex numbers)

Re:A better wheel

[daVinci1980]

No , it wasn't.

Re:A better wheel

[mdielmann]

I write my games in c++, my websites in php and my text parsing utilities in php. Java and python also serve their niches.

Heh, I read this and thought, "Hmm, looks like I shouldn't bother learning perl..."

Re:A better wheel

[gbjbaanb]

you're dead right. I always say that languages should be more specialised, not generalised.

So in my old job, front-ends were written in VB, communication and application tier was in C++, and the data tier was written in SQL. Everybody was an expert in their respective fields, everything was optimised for its particular task, and it worked wonderfully (lol, try writing SQL code in Java). And no politics in the dev teams either - everyone were masters of their own bit and all thought the guys writing the other tiers were relatively unimportant to the project :)

I'd do it the same way everytime now, maybe with java/c# for the presentation layer though.

Re:A better wheel

[renoX]

>meanwhile most serious OS level and game development continues to be in C or C++

And the developpers still don't manage to reduce the number of security flaws found in C or C++ programs..

I'd really like if D (or Eiffel, or Ada) would have success, but my hopes aren't great: not big enough "hype machine" pushing the language.

Re:A better wheel

[AuMatar]

Memory management and pointers are a strawman argument. As a C programmer, any idea how much time I spend on memory issues? Less than 1% of my development time, and less than 1% of my debugging time (meaning I'm not even counting meetings or design to fake my numbers). When you understand the language, keeping track of memory is just not that difficult. If you end up having problems figuring out where to use malloc and free, you have major architectural problems that will cause other errors to spring up.

The problem is that the current crop of CS students aren't being taught how to do this- they glaze over it in course work, and they don't have the advantages of older programmers who had to run on tight memory budgets. In this sense giving them crutches (gc) isn't realy helping them- its just ensuring they never reach the level of competence, and that lack of understanding does show in their designs and code.

Re:A better wheel

[Tim Browse]

Game programmers have free time? News to me! :)

Re:A better wheel

[hedge_death_shootout]

Is Object Pascal available for Amiga OS? If so, this combination could be the 'Killer App' of development environments!

*plus comments written in Esperanto for proper international support.

Re:A better wheel

[dechev]

"It is my firm belief that all successful languages are grown and not merely
designed from first principles",
D&E, BS

Re:A better wheel

[Hythlodaeus]

If you don't want to worry about memory and pointers in C++, use a good reference-counted smart pointer implementation. There are also full-blown garbage collectors out there, if that's really what you need. I have yet to hear of a useful feature of another language that couldn't be adapted to C++98.

Re:A better wheel

[oliverthered]

Ah, so it's you!!!

If more care had been taken with KDE then I could run it on my pocket PC and not need 1GB or ram and a 2Ghz+ processor.

Re:A better wheel

[omb]

No, the root of all evil it the UNCRITICAL
acceptance of (a) strong typeing, and bending
the language so that a compiler can, always,
and theoretically, detect mistakes at compile
time instead of warning and interpreting as
CPL, ancestor of BCPL, B, C, C++ tried to do,
but, of course warning and checking at run
time, and
(b) the fact that new developers are taught
that a single paradigm, procedural, functional
or OO is not only a GOOD_THING but the ONLY_WAY!

This leads to the pure Java mantra, "Perl is write
only", you can't write OO code in C and a lot
of more nonsense.

Re:A better wheel

[PurpleWizard]

I think you have a point. If the idea is to abstract more into the libraries. All that needs to be done is refine the libraries and also further test the libraries.

What about better tools for checking. Better ways of using it have come along through books like Effective C++ and more recent things like Modern C++ design.

The refinements can be written in the langugage itself. Until you run up against points where it is just broken which there may be my C++ is far short of expert let alone master.

A bit of a case of a know thine enemy type principle?

Re:A better wheel

[try_anything]

I know people prefer absolutes and questions with only one answer, but here's a question everyone has a different answer to:

If you told your customers that henceforth your products would run twice as slowly, but you would deliver new features twice as fast, what would they say?

Sure, there are developers out there who really need to program in C for some good reason, but there are even more developers clinging to C (and C++, the way most people use it) whose customers would be thrilled if they ditched C for a less demanding language.

By the way, the "twice as slow" part doesn't have to happen. My company has been using C++ to build systems that span the numerics, hardware, and application areas, and alternating hard and soft layers* has been a big win for us. It's awesome to fire up a REPL and use our software components to experiment, dissect some data, replicate a bug in isolation, or give a quick tour to a new developer. Since none of the "soft" code is critical to performance, there's no downside.

*http://c2.com/cgi/wiki?AlternateHardAndSoftLayers

Re:A better wheel

[Anonymous Brave Guy]

If you end up having problems figuring out where to use malloc and free, you have major architectural problems that will cause other errors to spring up.

Amen. And the memory management argument is even less relevant in C++, where resource management should generally be using at least simple RAII, and far more powerful schemes can be designed that still take advantage of deterministic destruction to ensure they're pretty much user-proof. Unlike certain other languages(TM) where memory is garbage collected -- sometimes -- and other resources are generally leaked like a sieve by programmers who haven't learned to do this stuff properly and think reading Learn A Language In 5 Seconds makes them good...

Re:A better wheel

[julesh]

Refcounts can't cope with cyclical structures without serious hacks. C++ garbage collectors are useful, but the fact that they can't tell pointers from binary data that happens to resemble a pointer is a serious problem for some applications.

Re:A better wheel

[julesh]

What about writing something quickly that I can just run outright on another machine?

You know, without having to install 30MB of toolkit/libraries/VM shit just to run the program./i.

Then you're looking for something with a smaller runtime, possibly which can build an encapsulation of runtime & program. Python is good for this.

Re:A better wheel

[ckaminski]

Rule #1 of C++: NEVER use auto_ptr. What idiot thought this was a good idea to throw into the language should be dragged out behind the barn and shot. With the entire magazine.

Other than ACE::Ref_Counted_Auto_Ptr and one I rolled my ownsome a LONG time ago which isn't all that great, I'm not sure I know of a GOOD refcounted smart pointer implementation. Got recommendations?

Re:A better wheel

[shiftless]

So a Dodge Viper or Cadillac Escalade is unneccesary because a Model T will get you from point A to point B?

C++0x?

[rerunn]

Perfect opportunity to come up with a decent name but nope, geekiness prevails and the best he can do is: C++0x

Re:C++0x?

[/ASCII]

Hmmm, the C standard are called C90 and C99. C++ follows this pattern as well with C++98, and the current C++0x, which on release will be renamed C++06 +- 1. Neat, consistent and predictable. Only6 you think it's geeky. Are you a marketer by any chance? ;-)

Names

[DNS-and-BIND]

Jeez, can they make these names any more obtuse? As if C++ wasn't confusing enough for people not in the know, C++0x? I mean, little in-jokes are fun, but put them in code comments, not in the title.

And I hate PDFs...if it had spiffy charts or images or something, it would be great...but it's just text! Opened it, saved as HTML and it was 78k.

Re:Names

[Anonymous Coward]

It's just the flipping standard's name. Currently, C++'s standard is... C++98. This is because it was standardized in 1998. C's current standard's name is C99 because it was most recently updated in 1999.

So it will still be C++. It's name will continue to be C++. But the standard will be switched from C++98 to C++0x (the 'x' means that the final standard isn't here yet... the final will probably be something like '6' or '7'... C++06... standardized in 2006... get it?) You will be able to have code that is C++98 compliant, and code that is C++0x compliant. I would prefer if they used the whole year name... C++1998, C++200x, etc.

Re:Names

[Xepo]

Actually, I was reading the standards page a while back about the developments of C++0x. Ends up that the x part of it might end up being a hexadecimal digit. =/ They were saying the standard would probably be published in 2009, barring any major hold-ups. And it's a standards committe, you know there's going to be hold-ups.

Re:Names

[Hythlodaeus]

0x refers to the fact that the new standard is intended to be finalized in 200x. The current standard is C++98, but the language itself continues to be just C++.

Yeah about that standard library...

[hey]

... its embarasing. Compare it to CPAN (perl) or Java. It can't do very much. I wish they could get some real functionality in there. Adding the Boost stuff is nice but. What some something like Java's SWT where you can write an entire GUI using the standard library. Now that would be an improvement for C++.

I would be very easy to do. Just "steal" the API spec's from Java. That's what C# did. Just recode the entire Java API into some C++ .h header files. Call it the standard and let vendors code it out. Sweet!

Re:Yeah about that standard library...

[CableModemSniper]

Yeah cause SWT is part of the java standard library. Perhaps you were thinking of AWT or Swing?

Re:Yeah about that standard library...

[RosenSama]

Don't Java and C#'s GUI stuff rely on an intervening VM so that write-once run-(mostly)anywhere can handle the GUI? How would this work for C++?

Re:Yeah about that standard library...

[Chosen Reject]

One of the reasons I hate Java so much is it's lousy gui. If I want a window, I want it to look native to my destop environment, not sticking out like a sore thumb.

Re:Yeah about that standard library...

[joshstaiger]

SWT acomplishes this. It uses native widgets where possible, and does so in an intelligent fashion.

Granted, this took much longer than it should have.

It's regrettable that Sun's marketing hype over Swing et all has poisoned people's impression of Java desktop GUIs, but with SWT we finally have a good framework...honest.

Try downloading Eclipse (written using SWT) to see for yourself.

Re:Yeah about that standard library...

[elflord]

Compare it to CPAN (perl) or Java. It can't do very much.

The aim of the standard library is not to "do as much as possible". The problem with canonizing a library in the standard, is that once it's there, you have a huge amount of code that depends on it, so you're stuck with it.

As for CPAN, last I checked, nothing in CPAN (or indeed perl!) was part of any formal standard in the same sense as the C++ library. CPAN is a collection of contributed libraries for Perl. There are also an enormous number of third party libraries for C++.

The bottom line is that putting a particular library in the standard gives it a sort of canonization/elevation that is probably not desirable as far as GUI libraries is concerned. I doubt it would be possible to get everyone to agree on a single true C++ GUI library, and neither should they.

Re:Yeah about that standard library...

[Cthefuture]

I have long thought the same thing. Most of Java's ease of use comes from the libraries. There is no reason why C++ could not have the same easy to use functionality in its standard libraries

Boost and STL are useful but too low level. We need a set of high level standard API's for C++. With the right design C++ could be nearly as quick easy to use as something like Perl (besides the need to compile).

Someone is working on porting SWT to C++. A great idea but it looks like a massive amount of work if you look at how much code is in SWT. Probably with some more help this project might get done quickly since it should be easy to divide up the work:

Style SWT in C++.

Re:Yeah about that standard library...

[NFLFan]

Speaking for myself, I find the STL a lot more useable than Java's standard library. Java's library is umm just too big for me and does not fit together that well. Countless times in Java have I picked/used a class that I later determined needed changed in favor of a similar class with more functionality. There also seems to be a lot more ughly method calls in Java- like obj1.fn(obj2.fn1().fn2().fn3()). And then there is the fact that the STL is faster and the retaining of types seem to allow for more.

Re:Yeah about that standard library...

[Rich0]

Of course, it doesn't help that Sun is out there screaming that SWT isn't Java, that it isn't in the standard libraries/JREs, and consequently requires separate installation.

I tried messing with an SWT-based hello-world in eclipse and was frustrated that nowhere is there a simple how-to on how to do it. I couldn't get the SWT libraries correctly linked in.

I think the absence of an SWT tutorial was due to IBM promoting SWT only as a tool for making eclipse plugins and not as a general toolkit for java apps - this was done to appease Sun, which of course was on the AWT or swing only bandwagon. Perhaps this has changed...

Re:Yeah about that standard library...

[m50d]

And have our programs look like ass everywhere? Seriously, GUI is an os-specific thing and belongs in OS-specific libraries.

Re:Yeah about that standard library...

[MobyDisk]

You are frustrated because you misunderstand the definition of a programming langauge. Programming languages don't provide APIs. Let me quote from the Wikipedia:

A programming language...is a standardized communication technique for expressing instructions to a computer. It is a set of syntactic and semantic rules...to precisely specify what data a computer will act upon, how these data will be stored/transmitted, and precisely what actions to take under various circumstances.

This definition does not include GUIs, graphics, or sound, or networking, or even file I/O. A language is used to describe allocating memory, and performing if/then/else logic, and describing data structures. Some examples of programming languages are: C, C++, Fortran, LISP, COBOL, TCL, Prolog, and shell scripts. Java is only a programming language if you remove the libraries.

What you are looking for is often called a platform. The Java platform ships with the Java language + a series of libraries that give you graphics and sound and networking.

If you treat C++ as a platform, you will be forever frustrated. If you are looking for a platform based on C++, I recommend C++ + POSIX + GTK. Most of the time I use C++ + Win32 as my platform. Try this, and you will be far less frustrated.

Oh, and just to make it clearer: If you want, you can use C++ + AWT or C++ + Swing if you want. The Java APIs are fully callable from C/C++. I don't recommend it because it defeats the purpose of using an low-level language like C++ if you then include a big virtual machine, but if you like the Java APIs, you can do it.

Re:Yeah about that standard library...

[Anonymous Brave Guy]

I tried messing with an SWT-based hello-world in eclipse and was frustrated that nowhere is there a simple how-to on how to do it. I couldn't get the SWT libraries correctly linked in.

This is the problem with languages that come with monolithic standard libraries. As long as what you want is in the library, and in the form you want it, you're fine. If it's not, or what's there isn't in a convenient or suitably adaptable form, you're in for a long day.

Compare and contrast with C++, where you bring in everything via separate libraries but pretty much everyone is familiar with how to do it, or Perl, where everyone knows you grab new packages off CPAN and usually has a one-liner tool available to do so.

Re:Yeah about that standard library...

[joshstaiger]

I tried messing with an SWT-based hello-world in eclipse and was frustrated that nowhere is there a simple how-to on how to do it.

You may want to check out the Getting Started with Eclipse and SWT page if you haven't already done so.

It contains some pretty good tutorials on the basics of SWT development.

--
http://joshstaiger.org/

Re:Yeah about that standard library...

[pdo400]

Personally, I find the code example you listed above quite pleasing. Would you rather have objects with tons of methods so you wouldn't have to chain the calls?

Re:Yeah about that standard library...

[stevejobsjr]

Recompiling... You know? The same way one GUI library can support multiple platforms in C++ now?

Re:Yeah about that standard library...

[AuMatar]

Exactly. The classic example of this is the C function gets(). Its a security risk. Everyone knows this. Everyone says never to use it. But we can't remove it, because much code depends on it.

Now if the IO code wasn't in a standard library, but instead people picked their favorite IO library among several developed by programmers, gets would have long since died. THere's be less code based one ach library, and a forced deprecation would have been easier. But since we put it in the standard, its there for all time.

Another example is zero terminated C strings. In many cases, a count followed by a string would make much more sense, and reduce strlen() to O(1). But all the standard library functions use 0 terminated. So we waste a lot of cycles doing string counts.

Standard libraries should be as small as possible (but no smaller). A basic IO abstraction is about all that should be in there. After that, let it all be in user libraries.

Re:Yeah about that standard library...

[EvanED]

I'll second (third? forth?) this opinion.

I'll be the first person blubbering about how using a Swing program is only slightly less painful than drinking a pan-galactic gargle blaster, how metal looks like someone took a dump on the screen, etc., but Eclipse is very nice to use.

If Sun were to drop Swing and pick up SWT I think they would see results very quickly.

I'm going to have to seriously consider Java and SWT as an option for any programs I do that I want to be cross platform, and to say that I find programming in Java less than pleasurable is about accurate.

Re:Yeah about that standard library...

[Trejkaz]

Not really. GUI is an OS-specific thing, but recompilation should be all that you need to make it look native on all platforms. You can blame this "looking like ass" (however things look like a donkey, I have no idea) on the developer of each platform's implementation, but you can't blame it on the idea.

Re:Yeah about that standard library...

[dmoon]

GCJ ( http://gcc.gnu.org/java/ ) has the c++ library which implments the java API. I hope they can make it an independent library so that the java programmers can switch to c++ easily.

Re:Yeah about that standard library...

[Mornelithe]

How do you make something that looks and works like a Windows application into something that looks and works like a Mac application (which has some distinctly different UI elements, like drawers and so on), with just a recompile?

Building a meta-toolkit front-end for several different, incompatible toolkits restricts you to supporting the lowest common denominator between them all, which probably means it will act poorly on them all. That was the problem with AWT. Swing tried to solve it by rolling its own GUI, which won't ever blend in as well as a native application.

Has SWT solved this? Will an SWT application work like a first-class Windows application on Windows, and a first-class cocoa application on Mac, and so on for Gnome and KDE? Will it automatically integrate wonderfully without any special work by the programmer?

Re:Yeah about that standard library...

[Trejkaz]

I personally hate SWT, so you've picked the wrong example. SWT is a particularly good example of where I am right: the GTK interface is written like crap, slow, and utterly useless. But I don't think it has to be. :-)

Re:Yeah about that standard library...

[vastabo]

The smart money says that your problem lies somewhere around -Djava.library.path="blahblahblah" arguments that you pass to the VM.

Be aware that the minor version number in the path isn't always right if you pasted it from the comments Eclipse puts at the beginning of your code ex:
org.eclipse.swt.win32_3.0.0 should be org.eclipse.swt.win32_3.0.2 (at least for me)

Also, sometimes Eclipse gets kinda bitchy about that path (even when it's right). Try (temporarily) copying the SWT library to someplace else with a simpler path (ex: / or C:\)

Re:Yeah about that standard library...

[Mornelithe]

Heh, okay, then. What is a good example?

Re:Yeah about that standard library...

[Trejkaz]

wxWidgets is somewhat better. Qt is better too, although I'll acknowledge that Qt/Mac looks shit... but again, that's also an implementation problem rather than a design problem.

Re:Yeah about that standard library...

[Mornelithe]

Qt is an autonomous toolkit, though. Qt is analogous to Swing or Cocoa. You can theme it to look like a Mac application, but it's not taking advantage of the native toolkit, so you won't get integration with the target system.

wxWidgets is more like SWT, in that it presents a uniform API that's implemented underneath by a native toolkit. So, you could make a Qt implementation of wxWidgets, and your wxWidgets app would look like a Qt app (that doesn't exist, although a GTK version does).

However, I'm skeptical that a wxWidgets application will fit in as well as anything written in the native toolkit itself. There's stuff in the Mac gui that isn't in GTK, and there's stuff that Qt/KDE can do that Gnome/GTK can't, and so on. I'm not sure I see how this can be reconciled by a library that has to provide a common interface to all of them.

The only thing I can come up with is some high level UI description language, where, for example, you say: "This is an accessory window for this other window," and the system automatically knows uses a drawer on OS X, and an extra top-level window on GTK or Qt, or something like that. But I'm not sure that's even feasible, and that really has nothing to do with the C++ standard library.

But, if I were proven wrong, I wouldn't be unhappy.

Re:Yeah about that standard library...

[Trejkaz]

That sounds more or less like the Swing approach. You tell it to do something in a certain way and it's supposed to be implemented per-platform to look and feel like the real thing. Problem is, Swing is drawn in Java-land so it will never look quite right until someone un-fucks that aspect of it.

You're on the right track there, though. A good cross-platform GUI API would abstract everything exactly like that... more than Swing. Much more.

But you know, for the majority of things, the developer wants a button with "Blah" written on it, and there's no big reason that it has to take different code on every platform.

It would probably be enough to have a common API for most stuff, and then platform-specific extensions for neat bits and pieces which don't exist elsewhere.

Re:Yeah about that standard library...

[ckaminski]

And this is EASIER than C++?

I also love how sometime around 1.3 they changed the rules so that jarfiles no longer obey CLASSPATH. Yeah, that bit me for the better part of two hours...

Re:Yeah about that standard library...

[ckaminski]

Um yeah, that's where this thing called Inheritance comes into play. If your toolkit is based on a model of Containers/Components, then all new components simply inherit from Component and do their magic differently. MFC manages it. Why a generic library couldn't as well, I cannot fathom.

Re:Yeah about that standard library...

[Mornelithe]

No, you're missing the point.

Suppose I have a widget toolkit X, that contains a widget foo, that every good X-based application uses.

I also have a widget toolkit Y, that has a widget bar, that's similarly included in all good Y-based applications.

X doesn't contain a direct analog to bar, and Y doesn't contain a direct analog to foo. In either case, you have to use a totally different widget, or combination of widgets in the opposite toolkit.

How do I make one meta-toolkit such that when I compile against a Y backend, it correctly uses bar in all the correct places, while against an X backend, it's done in some completely different way? And the same for foo. How is inheritance going to solve that?

How is inheritance and recompiling going to solve the difference between all sorts of different interface guidelines that differ from platform to platform?

Re:Yeah about that standard library...

[RosenSama]

1. The parent wanted support like Java/C# where there is no recompile 2. You mean putting GTK/Qt (or something) into the C++ standard?

Re:Yeah about that standard library...

[stevejobsjr]

1. The grandparent wanted to know how it would work ("How would this work for C++?"), and I explained that there'd be no VM and how a cross-platform library would work.

2. Yes. That's what this whole thread is about.

C++0x? D!

[pdbaby]

Why do we need this? D is a beautiful, well-appointed systems programming language. It's got a gcc front-end. It's got garbage-collection if you want, custom memory management if you want. It's got embedded assembly if you want. And it's fast

I thought we were staying with C++ because of all the code that's already written in it...

Re:C++0x? D!

[WalterBright]

Actually, it is free. GDC is the gnu version of the compiler, completely GPL.

Re:C++0x? D!

[WalterBright]

Since there's GDC, a gnu version of the library, there's no worries about what to do if Digital Mars goes bust. Anyone can continue on with the source, as they can right now.

Re:C++0x? D!

[jma05]

There are a LOT of things better in D than C++. D is far better language (not library) enhancement over C++ than Java/C#. Take a look at language comparison at http://www.digitalmars.com/d/index.html I do not use D however. I don't do much of systems programming and I fancy IDEs but language wise, D is perhaps the best imperative, native compiling language out there at the moment.

Re:C++0x? D!

[EvanED]

I thought we were staying with C++ because of all the code that's already written in it... ...then this story changes nothing. That's the nature of an addition to the language, they'll be very careful to not break any code. They might depricate a few features (I haven't yet read the article in question, but I've seen a few others in the past, and one feature that some are pushing to depricate are (type) expression and type(expression) style casts), etc., but if any of the changes break existing code, the broken code will be very rare and either poorly written or easy to fix.

Maintaining backwards compatability has been a hallmark of the development of C++ from the beginning, and is the reason for some of the more opaque syntax forms. (For instance, rather than add a new keyword (not even that major a change to existing code) for pure virtual functions, Strostrup came up with the foo() = 0; syntax.)

Re:C++0x? D!

[Hortensia Patel]

You might also have mentioned that the front-end for your DMD compiler (the reference implementation of the language) is also Free (GPL/Artistic).

It's also unusually comprehensible even to a compiler-illiterate like me. At least, compared to GCC source, of which even a brief glimpse ages you ten years.

Re:C++0x? D!

[PsychoBrat]

I've noticed this lately as well; considering that they haven't had the need to be as kind to superseded concepts quite as much as C++ did, there does seem to be a certain purity to the language.

However, do you know where Phobos is headed as far as 'native' (not linking back to C libraries) support for Windows GUI, or would this not be worthwhile/properly possible resulting in ugly wrappers that do little more than convert strings and whatnot?

Re:C++0x? D!

[julesh]

D is a beautiful, well-appointed systems programming language.

Yeah, right. Just looking at it now, as I've been meaning to for a while. Its memory management facilities just aren't up to C++'s. E.g., if you want to allocate an object on the stack, you have to declare that in its class, so all objects of the same class are stack allocated! And stack-allocated objects never have their destructors called.

Looking at the changelog, core runtime functions have been removed and replaced with equivalents with different interfaces recently.

Templated functions have a bizarre syntax: you have to name the function as well as the template.

The only things I've seen so far that I like is the garbage collector (although you can use a C++ one, it's not quite as efficient as a proper GC) and the fact that objects are passed to their constructors with the vtbl filled in (one of the most annoying things about C++: you can't call overridden virtual functions from a superclass constructor).

When it has matured, it might be an interesting language. At the current rate, I'd say it needs another 2 or 3 years.

C++... always the ugly step-kid

[MosesJones]

C was never a "nice" langauge, it was ugly, had massive problems around memory allocations, and the old unallocated pointer problems. It had unmangled names, so everything was in a global scope.

Then you had langauges like Smalltalk and Eiffel, elegant languages, simplicity, languages which gave control and power.

Then came C++, like C but improving on some things (name mangling), and adding the "power" of multiple inheritence. But worst it didn't solve the problems around memory allocation.

Languages like C# and Java have learnt from C++ and made it much easier to use (but not from Smalltalk see Ruby for evidence of that, and not Eiffel damn though it was good to develop it).

C++ was IMO a dreadful halfway house of a language that had most of the flaws of C and none of the advantages of Smalltalk/Eiffel.

Sometimes the best thing a creator of a language could do is declare it "dead" and get people to move away. Why do C++ if you can do Java/C#, why do Perl if you can do Ruby?

Re:C++... always the ugly step-kid

[jurt1235]

History of java according to IBM:
Java is based on Smalltalk!, not on C++

Can not help it, they tell this at the IBM java courses.

Re:C++... always the ugly step-kid

[DataPath]

Because C++ doesn't required a VM, a JIT compiler, or an interpreter?

Because with C++ you can compile to dozens more architectures than you can run C#/Java code on?

Because if you want garbage collection in C or C++, you can use one of the many libraries that allow you to do so?

You don't like multiple inheritance? Eiffel allows it. You got a problem with multiple inheritance? It solves a problem. And, depending on the implementation of that solution, it can be a very good one.

Oh yeah, and C++ predates Eiffel.

Re:C++... always the ugly step-kid

[jonastullus]

C was never a "nice" langauge, it was ugly, had massive problems around memory allocations, and the old unallocated pointer problems. It had unmangled names, so everything was in a global scope.

Then you had langauges like Smalltalk and Eiffel, elegant languages, simplicity, languages which gave control and power.

i won't dispute that many languages allow much better (data and functional) abstraction than C. but C - in its simplicity as a more readable and slightly more type-safe assembly - had its merits. in C there are no hidden mechanism and you are always right on the bare metal of the machine. so for what it was written for (operating systems, drivers and low-level software) C is actually a veritable and suitable language; far from more abstract languages in its power of abstraction and lacking any kind of real type-safety, BUT it had its applications!

c++ on the other hand takes the principles of C (medium/weak typing, ability to program close to the machine, lack of functional abstraction) and enhanced it by adding hidden mechanisms and arcane problems with values/references/pointers such as object slicing, double freeing, etc.

therefore c++ is neither the bare-metal-language that C was nor is it a real abstraction language like smalltalk, eiffel, lisp, haskell, ...! it is a PITA to learn C++, because every time you think you got it, something else creeps up on you and leads to one of those beloved "segmentation faults". c++'s merit is, that it allows a seemless transition from the bare-metal-programming of C to the more abstract realms of genericity (via templates *argh*) and OO. but the cost of this wide spectrum is the impossibility to comprehend c++ in its entirety or even understand enough of it in order not to be clubbed to death by wild pointers and memory corruption.

on its own, the necessity to think about copy-constructors and assignment-operators for EVERY class one writes is annoying. but together with virtual function calls not working in con/destructors, expressions of form

Class instance();

being interpreted as function declarations and by-default-implicit constructors can bring the aspiring beginner close to the edge sometimes.

Re:C++... always the ugly step-kid

[NDSalerno]

Here here! In the realm of native application development I have programmed in C++, Delphi, and Eiffel. Each language has its pros and cons. C++ is no doubt the most popular and most successful of the three. However, I have been most productive and had the most fun with Eiffel and Delphi. Some might be quick to say I am not experienced enough with C++ or that I haven't learned the idioms. I have programmed in C++ for many years. I have read all the books written by Stroustrup, Scott Myers, Herb Sutter, Andrei Alexandrescu, etc. I regularly read the newsgroups and paid attention to Sutter's Guru of the Week articles. With all that under my belt I still make mistakes. Why? In Eiffel and Delphi a statement of code can do one or two things. In C++ a statement of code can do several things, some of which incur side effects of their own. If you don't understand these behaviors then you write buggy code. Or, in other words, C++ is complex.

The hardcore crowd will tell you that ultimately you are better off going with C++ because of speed and power (implying that every other is a step above Visual BASIC). NONSENSE! Delphi is on par with C++. In certain situations C++ is more efficient than Delphi. In other situations Delphi is more efficient than C++. In the long run they are both the same. The only thing Delphi can't do is metaprogamming. Big deal. I can write my number crunching algorithm in C++ templates and wrap it in a library that Dephi can call. Problem solved. You know what C++ can't do elegantly? GUI development. It's tortuous. C++ Builder doesn't count because the language is modified and is not ANSI C++, which should really tell you that there is truth in the statement that C++ lacks some features. Qt has always been my favorite ANSI compliant GUI library. However, even Qt is a testament to the needed addition to C++. The meta-object compiler?? As if my compile times weren't long enough?

I have debated on the C++ newsgroups about accepting Borland's C++ extensions to the language, namely properties, closures, and reflection (advanced RTTI). I admit that boost does have a way to implement closures as template classes. They work and are efficient. My only dislike is that the syntax is too cumbersome. But I'll let that go. However, it has been argued and proven that properties CAN NOT be implemented as a class library without overhead. They simply must be a feature of the language. Combine that with better RTTI support (reflection capabilities) and you will have some powerful new tools to make elegant designs. And no, I am not advocating using RTTI for general development. Obviously if you have to test your base class pointer to discover the actual child type then your design is flawed. But that does not mean RTTI is as evil as goto statements. Properties and reflection is superior in the domain of GUI frameworks. GTK++, MFC, Qt, etc., should be proof enough that GUI libraries are too cumbersome without properties and reflection.

A lot of people ask for C++ to have some kind of GUI library but I do agree with Stroustrup's rationale for why that is not possible. There is no common denominator of design that would make sense for every platform and would appease everyone (whom has their own opinions on the design of a GUI framework, which are radically different). It is better for C++ to rely on third party libraries that deal with GUI development. That is fine for me. What I ask for is that we improve the language to allow better development for these third party GUI libraries.

Outside of GUI development, properties can be useful. The hardcore group, however, always argues against syntactic sugar because it is somehow pointless. This may be true for computer scientists. It is not true for software engineers. I always welcome any kind of help in reducing bugs. Syntactic sugar can actually help. To say it briefly, Delphi and Eiffel read like English. C++ reads like machine language. Guess which group of developers is going to have a higher defect rate?

Nicholas

Re:C++... always the ugly step-kid

[MrCopilot]

> To say it briefly, Delphi and Eiffel read like English. C++ reads like machine language. Guess which group of developers is going to have a higher defect rate?

Almost any language can read like english if done cleverly.

Actual Temp control code in working C++ application:

if(WaterTemp>SetTemp)
{
. setHeatON(FALSE);
}
else
{
. setHeatON(TRUE);
}

Oh yeah confusing. QT for gui, program reads like an instruction manual.

Re:C++... always the ugly step-kid

[Chris Burke]

c++'s merit is, that it allows a seemless transition from the bare-metal-programming of C to the more abstract realms of genericity (via templates *argh*) and OO

The beauty of templates (yes, it is a beauty, even if they do make you scream "argh" whenever you have to parse an error message) is that the source code you write is generic, but the object code produced by the compiler is not. This gives you the flexibility of generic programming with the speed of static typing. Templates can be really fast, as fast as code designed for a single type, a claim the other generic programming methods I know of (all of those which use base classes/virtual functions, including how generic programming was done in C) cannot make.

C++ really is a bare-metal language with syntactic sugar thrown on top to make OOP easier*. It is not a transition from C to higher level languages -- that transition is easy. It is designed instead to facilitate the use of higher-level concepts in a language that is still C-like. It is meant to occupy that middle ground, not provide transitions between the extremes.

I won't argue that it isn't full of arcane stuff that can give you headaches, though.

* Exceptions being the, uh, exception. But then again I don't like exceptions.

Re:C++... always the ugly step-kid

[NDSalerno]

Almost any language can read like english if done cleverly.

The key point here is "if done cleverly." I always strive to make my C++ as readable as possible. I agree that the average and novice programmer will be in good shape if they can code C++ cleverly. But that is the definition of novice, that you don't know any better until someone shows you or you figure it out with experience. If these people were able to do things cleverly in C++ then they would not be averages in the first place. They would be master level, which we are saying they are not.

I may not have written the sentence you quoted correctly. What I was trying to say is that there are programming languages that are designed such that you can't really write complex lines of code. That doesn't matter for the clever people but it sure matters a lot for novice developers. These languages tend to be wordy. They tend to need more statements of code to accomplish a task. Then there are languages that are designed such that you can write some code that did things you did not realize was going to happen. These languages tend to be terse. They tend to jam pack many operations in one high level statement. This is where people get in trouble with C++. The classic text book example is being given a line of code and asked how many temporaries will be involved and the lifetimes they have. Most people can't do it. Hell, I can't do it all the time. That's the complexity. Operator overloading is a notorious source of these hidden actions. The statement "a = b + c;" seems so innocent. Then, at runtime, the performance comes to a halt. What happened? What is truly going on in that statement? Then on some other project the statement "a = b + c;" seems to produce garbage values for a, if an exception hasn't been thrown already. Upon debugging we find that b and c are being added just fine. OK, what is going on with the return value? What is the return value? Is it by value, a reference, or a pointer to something? What is being referenced here? Are there treacherous temporaries afoot?

Now think of the kinds of statements that even the gurus trip over on! In a language like Object Pascal some of these issues are almost non-existent. That's always a plus, for the novice, the average, and even the gurus.

Nicholas

Re:C++... always the ugly step-kid

[MrCopilot]

Hmmm, Object Pascal http://pascal-central.com/compare.html

Thanks, I'll look into it. Can't believe that I haven't heard of it.

Re:C++... always the ugly step-kid

[Anonymous Brave Guy]

Almost any language can read like english if done cleverly.

Yes, although personally I'd say "be easily readable" rather than your "read like english", because English isn't always what you want due to inherent ambiguities and the like. In fact, I'd go as far as to say that one of the hallmarks of a good programmer is how readable his code is.

I've noticed an almost circular pattern here. Beginners write code that's pretty simple because they don't know any more, but that code sometimes doesn't perform well, or misses cases, or contains other subtle bugs. More experienced developers, with a wider range of language tools and programming techniques at their disposal, will use those extra techniques to plug the gaps and fix the bugs, but this creates lots of nasty special cases and "clever tricks" that are a maintenance and readability hazard. The really good programmer goes full circle, once again writing code that is very simple and easy to read. The difference from the beginner is that the expert will integrate most of the special cases cleanly into the design so they just don't arise in the first place. He will use extra language features or design techniques sparingly, and only when a simpler approach is inadequate. And above all, it will always be clear what tools and techniques are being used, and what the results should be.

Re:C++... always the ugly step-kid

[MrCopilot]

Beginners write code that's pretty simple because they don't know any more, but that code sometimes doesn't perform well, or misses cases, or contains other subtle bugs

This is the problem when they are taught more they must be held to some coding standard. Readability / Naming Convention Any standard helps. Most CS (intermediate skills) are giving homework and graded without regard to readability/maintainabilty. You end up with a lot of "I know I need another integer- I'll call it a." int a;

Great, now if (WaterTemp>a) WTF is 'a' again. Oh, 'a' is a temporary place for SetTemp. Then I should be able to read that. Somehow our industry survives this and teaches maintainabilty by making us try to maintain and then rewrite unmaintainable code by our predecessors.

We should strive for CLARITY and SIMPLICITY by design. No matter how complex the problem it can be solved by combinations of simple clear instructions, If they were thought out on the outset.

I love a good obfuscation challenge as much as the next guy, but only as a hobby. I don't wanna be paid to figure out why the hell there are so many GLOBAL Variables all starting with prefix temp (bad VB experience, sorry, First fire VB hack. Then replace VB software one piece at a time.) I was able to rescue 2 apps without ditching all the code but it took 3 times as long as rewriting any of the others.

Too little too late?

[leandrod]

I still remember the 'C++ Advisor' or something the like from Unix Magazine or a similar publication who wrote his last column giving up on the language because only a language lawyer could keep up on the accretions to it. I don't remember what the guy went for, but if one is into OO C derivatives you have C# with its integrated, extensible type system from the DBMS up to other languages. Or Java, if you don't want to be torpedoed by MS' 'IP'. C++ should have been fixed a long time ago, but then AT&T wouldn't have suffered from NIHS and we'd be all using ObjC and OpenStep.

Re:Too little too late?

[iggymanz]

it's very telling that Stroussap looks at much more well-designed languages and always says he can't see any advantage over C++. It's time to move on alright, much as I enjoy the challenge and fun of dealing with C/C++ code, it's the wrong solution for 80% of what it's commonly used for....let's leave it to kernel and graphics/GUI libraries, but for heavens sake let the rest die off.

hiding implementation of templates? how?

[KnightTristan]

I really wonder how they're gonna do that. I know some compilers have tried that in the past, with some export template thingy stuff. Templates where instantiated at link time. However, AFAIK, that never really worked.

Tristan

What we need is "Smoothed out" people...

[brockbr]

Every time a cost of entry is reduced and the expected prerequisites are thrown aside, the result is a truly less capable *person*, not a more capable tool.

Agreed - There are some things that need smoothing, but I for one am tired of dealing with people who lack a fundamental understanding of the *systems* as a whole. Examples of this are the folks coming out with CS degrees who aren't even capable of following a thought, let alone starting an actual career designing and developing software.

For them, a tool like Java offers an entry level that is acceptable given there current capabilities - A tool geared towards THAT user (and a fine one at that).

But C (and C++) can be leveraged by people who know the tool and *use* the tool for what it can do, even with it's high(er, intellectually) cost of entry.

Re:What we need is "Smoothed out" people...

[(void*)cheerio]

Amen!

Id's say it's like driving standard vs automatic. Standard is a pain in the ass if you don't know what you're doing. But if you invest in it, you can really control your car; you're in the loop.

Granted, it's nice that standard cars stall rather then have the engine rip the tranmission to pieces.

Re:What we need is "Smoothed out" people...

[midtoad]

you mean, given *their* current capabilities?

Expected release date

[thammoud]

2020. Good luck getting all the stuff in. Long live open standards.

Re:The future of C++...

[th0mas.sixbit.org]

... posts the AC as he thinks to himself, "VB roolz".

Features I want...

[BAILOPAN]

I program in C++ from dawn to dusk, and a few things really irk me about it:

1. Member function pointers. Implementation dependent and messy syntax that few people even know about. Their use is limited, and they don't support delegates like C#, making them ugly to work with.

2. The "virtual =0" syntax instead of something nice like "abstract" or "interface" is just weird. How can you set a prototype equal to 0? What's wrong with nice words?

3. Operator new and delete were designed by someone on crack. The only way to call a constructor is with placement new, whose syntax looks like: new (var) type(). Placement delete, however, doesn't call the destructor, which must be invoked manually. Furthermore, delete can't take parameters like new. What.

4. There is a "typeid" operator but no "typeof" operator. GCC has an extension for this, but it's not standard C++ I think.

I'm sure there are other language constructs that have annoyed me, and if you don't read my mind and fix them, Bjarne, I will kick you in the pants!

Re:Features I want...

[91degrees]

The "virtual =0" syntax instead of something nice like "abstract" or "interface" is just weird. How can you set a prototype equal to 0? What's wrong with nice words?

I'd like to see one of C#'s improvements here as well, where a reimplementation of a virtual method is explicitely stated. I've seen quite a few bugs caused by people changing the parameters of a base method without doing the same to inherited.

Re:Features I want...

[jonastullus]

1. Member function pointers. Implementation dependent and messy syntax that few people even know about. Their use is limited, and they don't support delegates like C#, making them ugly to work with.

exactly, and

std::for_each(content.begin(), content.end(),
std::bind1st(std::mem_fun(&PointVisitor::operator( )), v));

is neither typable nor easy to read AT ALL! plus, it makes my head ache!

Re:Features I want...

[drxenos]

No, there is no "typeof" but have you seen the proposed "typedecl" and the new uses for "auto"? Nice stuff. These are to be in the new standard. My main complaint is the need to use "typename" and "template" for disambiguating inside templates. Very confusing sometimes.

Re:Features I want...

[CrayzyJ]

> There is a "typeid" operator but no "typeof" operator.

According to "Effective C++" - Meyers, if you need to know the type of a class, you designed your classes wrong. Take advantage of abstract classes and coercion for this.

Re:Features I want...

[Anonymous Coward]

I don't know you bro, but care to elaborate on delete not calling destructor. That's kind of new thing to me after 10 years as C++ coder.

And the syntax of new and delete is awesome and I like it very much. I don't have time to chat and explain why I mean it is(and suits language well) but it is-trust me on this one. And that delete operator doesn't take arguments, man thats as easy to do the other way as - I mean plain easy.

and yes there is a proposal for typeof

Re:Features I want...

[Anonymous Coward]

Constructors that can return a value would be useful. Having to throw (& catch, & handle) an exception just to indicate a simple failure is a little bit too much when a simple int return type to identify an error condition could do.

Re:Features I want...

[happyfrogcow]

where oh where are the + moderation points on the parent?

good call, CrayzyJ

Re:Features I want...

[neil.pearce]

The "virtual =0" syntax instead of something nice like "abstract" or "interface" is just weird. How can you set a prototype equal to 0? What's wrong with nice words?

The man himself, in "The Design and Evolution of C++" states...

The curious =0 syntax was chosen over the obvious alternative of introducing a keyword "pure" or "abstract" because at the the I saw no chance of getting a new keyword accepted.
Had I suggested "pure", Release 2.0 would have shipped without abstract classes. Given a choice between a nicer syntax and abstract classes, I chose abstract classes. Rather than risking delay and incurring the certain fights over "pure", I used the traditional C and C++ convention of using 0 to represent "not there". The =0 syntax fits with my view that a function body is the initializer for a function and also with the (simplistic, but usually adequate) view of the set of virtual functions being implemented as a vector of function pointers. In fact, =0 is not best implemented by putting a 0 in the vtbl. My implementation places a pointer to a function called __pure_virtual_called in the vtbl; this function can then be defined to give a reasonable run-time error.

Re:Features I want...

[elflord]

1. Member function pointers. Implementation dependent and messy syntax that few people even know about.

I agree that these are a hassle. The adapters help, but don't completely solve the problem (IIRC tr1 improves the state of affairs with adapters)

2. The "virtual =0" syntax instead of something nice like "abstract" or "interface" is just weird.

Well, yeah, but I don't think this is a killer bug. btw, "interface" is a bad choice for a pure virtual anyway. After all, a non-virtual function is also part of the interface (and a private virtual function is not part of the interface for anyone besides the class author)

3. Operator new and delete were designed by someone on crack.

placement versions are seldom used by non-experts (in fact seldom used in general). delete doesn't and shouldn't take parameters. The destructor needs to be a nothrow operation, so it shouldn't do anything besides release resources. You take care of the stuff that needs parameters before you call the destructor -- there really is good reason to make these separate calls.

There is a "typeid" operator but no "typeof" operator.

This is on top of the list for new language additions, the main debate seems to be about how to do it, not whether it's a good idea (see "auto")

Re:Features I want...

[styxlord]

Did you read the article?

Don't tell us, tell Bjarne!

C++ language features
http://www.research.att.com/~bs/evol-issues.html

C++ standard library features
http://lafstern.org/matt/wishlist.html

Re:Features I want...

[Anonymous Coward]

1. Member function pointers. Implementation dependent and messy syntax that few people even know about. Their use is limited, and they don't support delegates like C#, making them ugly to work with.

False. Member function pointers are standardized and not implementation dependent. They do have a syntax that is unusual, however. It's unreasonable to expect C++ to support delegates "like C#" considering that C# was designed long after C++.

2. The "virtual =0" syntax instead of something nice like "abstract" or "interface" is just weird. How can you set a prototype equal to 0? What's wrong with nice words?

There is hesitation to introduce keywords, for fear of breaking backwards compatibility. If you program in C++ from dawn to dusk, the =0 notation should be perfectly normal to you, and not a problem in the slightest. They could have made it more descriptive, but it's certainly not a showstopper, and no C++ programmers I know even notice it anymore, as it is just a part of how things are done. Maybe it's a problem for newbies, but you're only a newbie for a short time.

3. Operator new and delete were designed by someone on crack. The only way to call a constructor is with placement new, whose syntax looks like: new (var) type(). Placement delete, however, doesn't call the destructor, which must be invoked manually. Furthermore, delete can't take parameters like new. What. You cannot call constructors, PERIOD. Placement new is not invoking a constructor, it's evaluating a "new expression" using an allocator function that returns the address it is given, and a SIDE EFFECT of that is the invocation of the constructor. It's simply impossible to directly call a constructor in C++.

As for "placement delete", I think you lack understanding. Users are not supposed to invoke placement delete, they are supposed to just invoke the destructor for objects created with placement new. Placement delete is only used to cleanup the memory when an exception causes the constructor to fail. And, as an obviously competant C++ programmer, you should know that if the constructor exits with an exception, the destructor is NOT invoked because the object wasn't constructed and therefore doesn't really exist. Operator new and delete are about MEMORY MANAGEMENT and not object lifetime issues. Constructor and destructors are about that. A "new expression" makes use of operator new and also invokes a constructor. You seem to have confused the "new expression" for operator new.

4. There is a "typeid" operator but no "typeof" operator. GCC has an extension for this, but it's not standard C++ I think.

You're correct, and you may find that we're trying to address this topic in C++0X. If you're interested, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers /2004/n1737.pdf

Re:Features I want...

[lothiel]

That would be terribly foolish. For one thing, RAII wouldn't work any longer. You can't force someone to check a plain return code, but they're forced to deal with an exception.

Re:Features I want...

[XNormal]

1. Member function pointers. Implementation dependent and messy syntax that few people even know about. Their use is limited, and they don't support delegates like C#, making them ugly to work with.

For a full description of just how utterly brain damaged C++ member functions really are check thisarticle.

Riddle: What's the size of a method pointer?

1. 4 bytes
2. 8 bytes
3. 12 bytes
4. 16 bytes
5. 20 bytes
6. all of the above

The correct answer is 6. It can be any of these sizes depending on the circumstances. And just imagine that with all of this mess method pointers STILL don't support something as elementary as delegates (bound method pointers) in a dependable and portable way.

Re:Features I want...

[NFLFan]

1. Member function pointers. Implementation dependent and messy syntax that few people even know about. Their use is limited, and they don't support delegates like C#, making them ugly to work with.

Okay, member functions pointers are implementation dependent but the syntax is not- lets not murky the waters. 2. The "virtual =0" syntax instead of something nice like "abstract" or "interface" is just weird. How can you set a prototype equal to 0? What's wrong with nice words? Oh well, deal with it. I certainly would not want the notion of interfaces that Java has and have to concern myself with using implents or extends to inherit a class, yuck.

3. Operator new and delete were designed by someone on crack. The only way to call a constructor is with placement new, whose syntax looks like: new (var) type(). Placement delete, however, doesn't call the destructor, which must be invoked manually. Furthermore, delete can't take parameters like new. What.

You have me scratching my head here. I call constructors all the time without using new. Whenever I call delete the objects destructor gets invoked too! I don't understand your need for passing parameters to delete, but you can to destructors and don't forget classes hold state!

4. There is a "typeid" operator but no "typeof" operator. GCC has an extension for this, but it's not standard C++ I think.

Okay, so there is no typeof. You can get a lot of its functionality out of sizeof though! See Modern C++ Design pages 34-37 for details. I believe there is also a good chance of it getting added, that is why they make admend standards afterall.

Re:Features I want...

[nautae]

Speaking of stuff that'd be nice, it'd sure be convenient to have anonymous functions and anonymous classes. Boosts lambda library is really cool, but it shouldn't be needed !

Re:Features I want...

[saurik]

> It would be nice if the compiler could arrange so that the matching operator delete was called automatically...

But if it did that, then it would have to store something extra in the memory region you requested. Which would change the usage and performance of the memory region you are working with. This is something that should be in the hands of the library designer, which is more than doable.

Example: in my C++ library (Menes) all calls to new are choke-pointed through a single system that tags the memory region with a reference to the allocator in charge of the allocation. When delete is called I can then deallocate it using the specific allocator that caused the allocation. Without also standardizing the concept of allocation objects and just ensuring the same allocation function is called, you'd just be wasting another few bytes in my objects (things which were important enough to be allocated a certain way that I spent the time to write this massive allocation system) and I'd _still_ have to add a reference to the specific allocator object to the block of memory somewhere.

Re:Features I want...

[wxprojects]

> False. Member function pointers are
> standardized and not implementation dependent.
> They do have a syntax that is unusual, however.
> It's unreasonable to expect C++ to support
> delegates "like C#" considering that C# was
> designed long after C++.

Um, I think parent was referring to the fact that the size of mfps are implementation-dependant -
http://www.codeproject.com/cpp/FastDelegate.asp

> If you program in C++ from dawn to dusk, the =0 notation should be perfectly normal to you, and not a problem in the slightest

Yes its a problem - the creator himself even aknowledged himself that it was basically a hack because a keyword wouldn't be accepted. Just get it over with and use abstract already :).

> You cannot call constructors, PERIOD. Placement
> new is not invoking a constructor, it's
> evaluating a "new expression" using an
> allocator function that returns the address it
> is given, and a SIDE EFFECT of that is the
> invocation of the constructor. It's simply
> impossible to directly call a constructor in
> C++.

Wow, that's some real nitpicking there :\. As long as you remember to call the destructor beforehand or call it on an uninitialized object it is the functional equivelent of calling the constructor of an object.

> Placement delete is only used to cleanup the
> memory when an exception causes the constructor
> to fail

Yes, but I think what parent meant was that it makes logical sense to match every new with a delete, which in the case of placement new is generally not the case.

> And, as an obviously competant C++ programmer,
> you should know that if the constructor exits
> with an exception, the destructor is NOT
> invoked because the object wasn't constructed
> and therefore doesn't really exist.

One of the complicated things about c++ that routinely trips up even experts in practice.

> You're correct, and you may find that we're
> trying to address this topic in C++0X. If
> you're interested, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers /2004/n1737.pdf

Good luck. Personally, I think the embedded c++ standard was the best comprimise between c and c++.

One more thing - please remember that that standard will have big consequences for compilers to come - for wxWidgets I still have to deal with old, arguably broken, compilers. Please don't rush it and make sure it gets right this time :).

Re:Features I want...

[joss]

Great, please give me an example of how would you use this return type ?

Foo f1(3);
Foo *f;
f = new Foo(2);

Maybe a little more thought needs to go into your language suggestions.

Re:Features I want...

[oscarmv]

Most compilers will optimize off a dynamic_cast if it's known at compile time that it's going to work.

For whatever that is worth.

Re:Features I want...

[XNormal]

For a full description of just how utterly brain damaged C++ member functions really are

That should have been member function pointers, of course.

Re:Features I want...

[WWE-TicK]

No, he said that at the time he didn't think a new keyword would've been accepted.

Re:Features I want...

[Spy der Mann]

exactly, and

std::for_each(content.begin(), content.end(),
std::bind1st(std::mem_fun(&PointVisitor::operator( )), v));

This is one of the reasons i love PHP so much:

foreach($array as $item)
{
}

I never use any for_each crap in C++. I just make sure all my arrays begin at index 0. Sure, it's risky at times, but definitely much more elegant than the half-baked C++ iterators.

Re:Features I want...

[alyosha1]

You can do this in a considerably nicer fashion using the boost::bind and boost::function libraries, so for example

std::bind2nd(std::ptr_fun(f), 5)

becomes

bind(f, 5, _1)

That said, Python and especially Haskell still have much nicer syntax for binding functions.

Compare
std::bind1st(std::plus<int>(),1);

in c++

with
(+1)

in Haskell!

Re:Features I want...

[Anonymous Coward]

Um, I think parent was referring to the fact that the size of mfps are implementation-dependant -
http://www.codeproject.com/cpp/FastDelegate.asp

If the parent was referring to that, then why limit the complaint to only pointers to members? The size of pointers is implementation dependent for of ALL types of pointers (and integers and longs, and classes, and struct, and unions, and...)

Yes its a problem - the creator himself even aknowledged himself that it was basically a hack because a keyword wouldn't be accepted. Just get it over with and use abstract already :).

Seriously, if you feel strongly enough about it, now is the time to write a proposal.

> You cannot call constructors, PERIOD. Placement
> new is not invoking a constructor, it's
> evaluating a "new expression" using an
> allocator function that returns the address it
> is given, and a SIDE EFFECT of that is the
> invocation of the constructor. It's simply
> impossible to directly call a constructor in
> C++.

Wow, that's some real nitpicking there :\. As long as you remember to call the destructor beforehand or call it on an uninitialized object it is the functional equivelent of calling the constructor of an object.

It may be nitpicking, but it's still an important distinction to make. You cannot call constructors, and that has visible consequences, such as 1) you cannot take the address of a constructor 2) constructors can only be called once per object 3) the object "lives" only after the constructor exits successfully, 4) during construction the dynamic type of the object is the same as the static type of the object, but later, they may change, 5) you therefore cannot call pure virtual functions from a constructor.

These contribute to making a constructor "special."

...
Yes, but I think what parent meant was that it makes logical sense to match every new with a delete, which in the case of placement new is generally not the case.

It generally IS the case. I'd argue that placement new is the exception, and one for expert programmers who know the intracacies.

> if the constructor exits
> with an exception, the destructor is NOT
> invoked because the object wasn't constructed
> and therefore doesn't really exist.

One of the complicated things about c++ that routinely trips up even experts in practice.

Why is it compilcated? If you flip it around, it's much harder to justify. Suppose that the destructor would be called no matter how little of the constructor had actually executed. How do you write a destructor that correctly operates? It may be dealing with uninitialized member data that it cannot touch, and has no way of knowing quite how much of the initialization actually needs to be cleaned up. It can't even keep track of state in a variable while executing the constructor, because the state could be uninitialized if the failure occurred even earlier. (That would require compiler support to implement reliably, and would have terrible runtime performance penalties.)

Good luck. Personally, I think the embedded c++ standard was the best comprimise between c and c++.

Well to each his own. I've no more influence over the outcome than my ability to influence voting members. I don't know how much, if any, I have influenced anything yet. :)

One more thing - please remember that that standard will have big consequences for compilers to come - for wxWidgets I still have to deal with old, arguably broken, compilers. Please don't rush it and make sure it gets right this time :).

Well, old broken compilers

Re:Features I want...

[Omnifarious]

First, I don't think it matters if the size of a method pointer is random. What's the size of a structure containing a char and an int? It could be a wide range of values, and it's implementation dependent.

The boost library gives you delegates that work just fine.

Yes, the syntax and semantics are horribly ugly. But, they are well defined, and aren't implementation dependent. Now the exact size of the pointer is implementation dependent, but you shouldn't be caring what the size is anyway.

Re:Features I want...

[maxwell demon]

Ok, then tell me the correct design for this:

template<class Float> class Vector
{
// math vector using arbitrary float type
}

template<class Float1, class Float2>
Vector<typeof(Float1() + Float2())> operator+(Vector<Float1> const& a,
Vector<Float2> const& b)
{
// ...
}

// ...

int main()
{
Vector<double> v;
Vector<MyHighPrecisionUserDefinedFloat> w;
// ...
Vector<MyHighPrecisionUserDefinedFloat> x = v + w;
// there's an operator+ for double+MyHighPrecisionUserDefinedFloat
// returning MyHighPrecisionUserDefinedFloat
// ...
}

Yes, there's the possibility to do type traits, but that doesn't scale (even with only built-in types you have char, signed char, unsigned char, short, unsigned short, int, unsigned int, long, unsigned long, float, double and long double, that makes 12 entries for one argument; given that + has two of them and any two of them can be added, you'd actually need 144 traits specializations to cover all built-in types. And for the first user-defined type, you'll likely add 25 more: 12 with built-in as first operand and user-defined as second, 12 the other way round, and one for sum of two user-defined). And all of that just to state something which the compiler already knows anyway.

Re:Features I want...

[Chris Burke]

He's talking about "placement" delete which does not call the destructor, but he's still on crack because the whole point of placement new/delete is to separate the allocation/deallocation of memory for an object with the construction/destruction of the object. If you want to both deallocate the memory and call the destructor, you use normal delete. Placement new is similarly used only in cases when you want to separate memory allocation from constructing the object, like in pool classes.

Re:Features I want...

[NFLFan]

You have me scratching my head here. I call constructors all the time without using new. Whenever I call delete the objects destructor gets invoked too! I don't understand your need for passing parameters to delete, but you can to destructors and don't forget classes hold state!

Ugh, just realized that you were talking about placement. Still, something does not sound right. Anyhow, placement should almost never be used and one should spend more time justifying its use than on implementation details.

Re:Features I want...

[BAILOPAN]

No, we were implementing virtual function hooking through a delegate implementation.

You can read about it ("SourceHook") on the developer's blog: click here

Re:Features I want...

[BAILOPAN]

Indeed, you are correct, my understanding of placement delete was not quite right :) thanks for clearing that up. By "implementation dependent", I meant the binary ABI behind it. You can't cast a member function pointr to a void pointer, you must double cast it to a pointer to a pointer and then back to get at its memory. I imagine this is because every compiler implements it differently.

Re:Features I want...

[EvanED]

No, in sum, the argument went "I didn't want to piss off anyone in my user base that was using pure or abstract as an identifier somewhere, so I chose a syntax that, while a bit obscure, didn't break existing code."

If you'd investigate and read D&E instead of making sarcastic remarks, you'd learn that not breaking existing code -- C code, even, let alone existing C++ code -- was one of the primary goals.

Re:Features I want...

[EvanED]

It wasn't a matter of choosing the keywoard that was a problem; I'm sure that he would have thought that either pure or abstract would have been splendid.

It's just that if he chose a keyword, it would either have to be one that was already in use (in which case you get just as akward a syntax) or something that, probably, someone was using as an identifier somewhere.

You add a keyword to a language and bam, suddenly you break code. Not breaking code unless absolutely necessary was a primary goal of Stroustrup when he was writing C++, so he went with an obscure syntax that didn't break code rather than a nicer syntax that did.

There's another part of D&E where he says pretty much that about keywords in general.

(If you want another example of when this happened, I think the crazy syntax for differentiating between the prefix and postfix increment and decrement operators came about very similarily.)

Re:Features I want...

[EvanED]

Riddle: What's the size of a method pointer?

Riddle: What's the lowest number you can be guranteed of an int holding? char? What's the guranteed range of a char?

If you answered negative 2 billion something, you're wrong.

If you answered -32768, you're wrong. While I am unaware of any implementation that doesn't allow you to have an int of -32768, it's not guranteed. The range of an int is only guranteed to be at least -32767 to 32767.

Range of a signed char is -127 to 127.

And the guranteed range of a char is 0 to 127.

Yet these ranges are usually changed.

What's the size of an int? Might be 2 bytes. Might be 4 bytes. If you have a 64 bit machine, it could probably legally be 8 bytes. Is this a problem?

In fact, what's the size of a normal pointer? You don't know!

Of all the things you could complain about member pointers, it being an unpredictable size is NOT one of them.

Re:Features I want...

[SamNmaX]

> There is a "typeid" operator but no "typeof" operator.

According to "Effective C++" - Meyers, if you need to know the type of a class, you designed your classes wrong. Take advantage of abstract classes and coercion for this.

Well, there are some issues with this. For example, when dealting with STL, I believe they avoid abstract classes in order to avoid virtual function overhead as well as normal function overhead by having inlinable code. Some sort of 'auto' or 'typeof' operator would be an excellent addition to the language, as it would support a style of code many use and that they explicitly encourage via the STL. That said, there are cases like this where abstract classes would be appropriate, and should be considered as an option, whether or not 'auto' or 'typeof' come into existence.

Re:Features I want...

[Anonymous Brave Guy]

According to "Effective C++" - Meyers, if you need to know the type of a class, you designed your classes wrong.

Or, alternatively, Scott is wrong on this one.

There is a reason to have dynamic_cast in the language. Consider, for example, a class hierarchy with three levels, where some virtual functions are introduced in the middle level, but all you have is a reference to the top level base class. If you have an algorithm that deals with this class hierarchy, and wants to call one of the mid-level virtual functions if the object it's got is of a suitable type, then the only way to get there safely, in general, is via a dynamic cast.

Anything else either requires polluting the topmost base class's interface, or some part of the system to have deeper knowledge of the types involved. (Try it.) The deeper knowledge may theoretically always be available, somewhere, and possibly at the expense of hideous code duplication, but in practice it's often cleaner and more maintainable to go with the dynamic cast.

Re:Features I want...

[James_Aguilar]

That's why you break it down over multiple lines. Don't worry, it doesn't take up any more space on the stack than it would otherwise . . . and you can read it . . .

Re:Features I want...

[ivec]

About how these problems are being addressed, or why they may remain as is:

1. [Member function pointers & lack of delegates]
Derived from boost::function http://www.boost.org/doc/html/function.html, function objects are being added to the standard library. They will support callbacks in a way that is comparable to what is found in C# (and in compiler-specific extensions such as Borland's).
It was always intended to have this as a standard library.

2. "virtual =0" syntax - what's wrong with nice words
C and C++ have always made trade-offs to avoid introducing additional keywords that could break backwards-compatibility.
Personally, I'm not bothered much by this syntactic detail. "#define abstract =0" if you wish. But it would be nice to have explicit overrides vs new function, as supported in other languages and vendor-specific extensions (e.g. Microsoft's C++/CLI).

3. new & delete, delete doesn't take a parameter
If you want both new and delete to take a parameter, what you are looking for is a container that stores your elements.
Low-level usage of new & delete overload is an advanced technique, that only experts should have to use. If it appears clunky to you, don't use it. I understand its logic.

4. typeof operator
This is an extension that is expected to be part of the next C++ standard, and that an increasing number of compilers are supporting. [plus there are today some (ugly) library hacks to provide that functionality in standard C++98]

Re:Features I want...

[julesh]

class Delegate { public: virtual void operator() = 0; }
class T { public: virtual void f() { ... } };

class T_f_Delegate : public Delegate {
private:
T * target;
public:
T_f_Delegate(T * t) { target = t; }
virtual void operator() { return target->f(); }
};

T t_instance;
...
T_f_Delegate delegate (t_instance);
...

Not the easiest setup in the world, but it can be improved substantially by using a few templates.

Re:Features I want...

[julesh]

How about taking a paremeter that's a reference to an int and storing an error code in there.

Although throw & catch probably generates better code when its compiled, so I've no idea why you'd want to do it that way.

Re:Features I want...

[Anonymous Brave Guy]

Having to throw (& catch, & handle) an exception just to indicate a simple failure is a little bit too much when a simple int return type to identify an error condition could do.

That wouldn't do at all. Throwing an exception to indicate construction failure means a failed construction usually doesn't leave the name that would have referred to the constructed object in scope, which means you can't try to use it accidentally. Dumping this effective idiom for naive return codes would be like introducing a finally keyword but dumping RAII: it's a step in the wrong direction.

Blasphemy?

[smittyoneeach]

In no way. If you read the B.S. writings (and I recommend he favor the world with a middle initial) he is always concerned with teachability of a feature, which is pretty understandable when you consider he's an academic.
Now, what an academic is doing having a successful programming language with real-world applications is another question...

Re:Blasphemy?

[KonradScorciapino]

...
he is always concerned with teachability of a feature, which is pretty understandable when you consider he's an academic.
...

haha
hahahaha
hahahuahahahahahahahah

No wonder you got modded +5 Funny

Re:standards are nice

[drstock]

"Standards are nice, everybody should have their own" That quote always cracks me up.

Watch out you don't get f'ed

[MarkusQ]

the language needs to shave of a few rough corners

Yo nee t b carefu whe cuttin corner; i yo cu to fa yo ca reall "f" yoursel ove goo!

--MarkusQ

Re:C++'s achilles heel

[jurt1235]

I mainly use Java, just commenting on languages evolving. Looking at Java, I think Java is one of the most clear examples in it. Sun reacts to input of users of the language, and to its competition (.NET) by updating the language and the VM to be able to stay competitive.

The library problems of C++ are well known to me too (port application from one linux box to the next, and welcome incompatibilities and the hours of solving it, last problem though was with IBM Java: It started, but just not completely, library problem!)

If you're confused too...

[Henry V .009]

I read the article and was confused by some of the code examples.

The '=' have been replaced by '-' signs. (In Acrobat 7 on Windows anyway.) The code makes a heck of a lot more sense once you realize this.

Re:If you're confused too...

[Anonymous Coward]

Actually, they're still '=' signs. Zoom in and you can see. Apparently the typeface he chose has very narrow '=' signs!

Re:If you're confused too...

[zonx lebaam]

A glimpse at the true power of operator overloading!

Time to reitre C++??

[Anonymous Coward]

I'm a first year programming student at an Ivy League school and I've
just finished my Visual Basic classes. This term I'll be moving onto
C++. However I've noticed some issues with C++ that I'd like to
discuss with the rest of the programming community. Please do not
think of me as being technically ignorant. In addition to VB, I am
very skilled at HTML programming, one of the most challenging
languages out there!

C++ is based on a concept known as Object Oriented Programming. In
this style of programming (also known as OOPS in the coding community)
a programmer builds "objects" or "glasses" out of his code, and then
manipulates these "glasses". Since I'm assuming that you, dear reader,
are as skilled at programming as I am, I'll skip further explanation
of these "glasses".

Please allow me to make a brief aside here and discuss the origins C++
for a moment. My research shows that this language is one of the
oldest languages in existence, pre-dating even assembly! It was
created in the early 70s when AT&T began looking for a new language to
write BSD, its Unix Operation System (later on, other companies would
"borrow" the BSD source code to build both Solaris and Linux!)
Interestingly, the name C++ is a pun by the creator of the language.
When the first beta was released, it was remarked that the language
would be graded as a C+, because of how hideously complex and unwieldy
it was. The extra plus was tacked on during a later release when some
of these issues were fixed. The language would still be graded a C,
but it was the highest C possible! Truly a clever name for this
language.

Back to the topic on hand, I feel that C++ - despite its flaws - has
been a very valuable tool to the world of computers. Unfortunately
it's starting to show its age, and I feel that it should be
retired, as COBOL, ADA and Smalltalk seem to have been. Recently I've
become acquainted with another language that's quite recently been
developed. Its one that promises to greatly simplify programming. This
new language is called C.

Although syntactically borrowing a great deal from its predecessor
C++, C greatly simplifies things (thus its name, which hints at its
simpler nature by striping off the clunky double-pluses.) Its biggest
strength is that it abandons an OOPS-style of programming. No more
awkward "objects" or "glasses". Instead C uses what are called
structs. Vaguely similar to a C++ "glass", a struct does away with
anachronisms like inheritance, namespaces and the whole
private/public/protected/friend access issues of its variables and
routines. By freeing the programmer from the requirement to juggle all
these issues, the coder can focus on implementing his algorithm and
rapidly developing his application.

While C lacks the speed and robustness of C++, I think these are petty
issues. Given the speed of modern computers, the relative sluggishness
of C shouldn't be an issue. Robustness and stability will occur as C
becomes more pervasive amongst the programming community and it
becomes more fine-tuned. Eventually C should have stability rivaling
that of C++.

I'm hoping to see C adopted as the de facto standard of programming.
Based on what I've learned of this language, the future seems very
bright indeed for C! Eventually, many years from now, perhaps we'll
even see an operating system coded in this language.

Thank you for your time. Your feedback is greatly appreciated.

Re:Time to reitre C++??

[Anonymous Coward]

Huh? Everybody knows that C++ and lisp were both based on Java which was invented by Microsoft. I admit that C is an exciting language however Java runs in a VM that maintains speed advantages over C by using advanced optimization technologies like 'JIG' and 'JNI'. The greatest thing about javascript is that it works in your Internet Explorer. Absolute fucking genius, why do these computer gurus keep reinventing the wheel when the square one we have works fine.

Re:Time to reitre C++??

[peterpi]

Well I found that incredibly funny, even if the mods didn't. Bravo!

Shave OFF a few rough corners

[lbmouse]

...change the name from C++ to Coo

*yeah* initializing std::vectors

[jonastullus]

if that were to happen i'd *so* be exhilerated!

not having a way to initialize a std::vector with some values has always been one minor annoyance for me when using the stl containers!

and about that "expert" thing: it is not by chance that c++ has become an expert-oriented language! there are SO many hidden traps and arcane details to get wrong that one can't just use c++ with intermediate skills and hope not to be punished! even the most simple mistakes can (and will) lead to segmentation faults and memory corruption!
i am not even saying that c++ is an evil language, but it sure as hell isn't newbie-friendly!

Re:*yeah* initializing std::vectors

[neil.pearce]

not having a way to initialize a std::vector with some values...

Just copy them into a back_insert_iterator...

#include <iostream>
#include <vector>
#include <iterator>
#include <algorithm>

int main() {

typedef std::vector<int> IntVector;
IntVector intVector;

const int values[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };

std::copy(values,
values + sizeof(values) / sizeof(int),
std::back_insert_iterator<IntVector>(intVector));

std::copy(intVector.begin(),
intVector.end(),
std::ostream_iterator<int>(std::cout, "\n"));
}

Re:*yeah* initializing std::vectors

[Zathrus]

I'm not quite sure what you're looking for here -- a new vector has size 0 so it doesn't have any "values" to initialize (it does have memory reserved for values, but that's different).

If you use the resize() function to explicitly give it a size then the optional second parameter allows you to initialize all the new values to a set value. That's standard, portable, and it works -- even on VC++ 6.0.

Re:*yeah* initializing std::vectors

[jonastullus]

thx.

i am/was quite aware that you COULD somehow get values into a vector. but i resent the necessity of the 4-6 lines of code of yours.

wouldn't it be great to simply write:

std::vector vec = {1,2,3,4};

no matter whether it was pure syntactic sugar or however implemented, but this would elevate std::vectors to a built-in-status that they simply don't have today!

Re:*yeah* initializing std::vectors

[Uksi]

Aside from the std::vector(n, initialValue) constructor, which fills the vector with n copies of the initialValue, you can use the boost::assign library. From the doc: "The purpose of this library is to make it easy to fill containers with data..."

• A comma-separated list:

  vector<int> v;
  v += 1,2,3,4,5,6,7,8,9;

• A parenthesis-separated list:

  map<string,int> m;
  insert( m )( "Bar", 1 )( "Foo", 2 );

• Repeats:

  vector<int> v;
  v += 1,2,3,repeat(10,4),5,6,7,8,9;
  // v = [1,2,3,4,4,4,4,4,4,4,4,4,4,5,6,7,8,9]

..etc

Re:*yeah* initializing std::vectors

[jonastullus]

a new vector has size 0 so it doesn't have any "values" to initialize

exactly!
and as BS wrote in TFA, it would be quite nice to initialize vectors with more than 0 members; like so:

std::vector vec = {1,2,3};

this would be especially handy if the values between the braces above are not all the same (in which case one could use vector constructors default value)!

Re:*yeah* initializing std::vectors

[HuguesT]

Ok, but then all sorts of problems creep up. All of a sudden you'd like to be able to do that with lists, maps, etc. Where do you stop ?

Then there is too much coupling between the language and the library. You wouldn't be able to change the STL that comes with your compiler with Fair Dinkum's for example.

C++ is strong partly because your language components can come from various sources.

Re:*yeah* initializing std::vectors

[sqlrob]

Not if that's declared in the standard to call a particular constructor involving iterators and counts. It would be applicable for all containers. Maps would just be collections of the pairs.

Re:*yeah* initializing std::vectors

[NFLFan]

Well buddy, there are ways to initialize vectors! To initialize a vector<int> of size 100 to the number 9 you would do "vector<int>(100, 9)" but beware if you expand the vector afterwards the new elements are not initialized to your desired value. The vector function resize does take an optional second argument to initial new elemetns, otherwise it falls back to the default constructor. If you want to initialize the vector later, perhaps because you do not know the size until later, use assign such as "vector<int> v; ...; v.assign(100, 9);"

Re:*yeah* initializing std::vectors

[maxwell demon]

I never liked the comma-separated list method. The problem is that it doesn't work like it seems to work. Anyone "unsuspecting" who sees

v += 1, 2, 3, 4, 5, 6, 7, 8, 9

immediatly thinks

v += (1, 2, 3, 4, 5, 6, 7, 8, 9)

i.e. the list of those numbers is added to v. But don't try to type the second line! It will compile quite fine. But it will not do what you want, but rather only append 9 to the vector. However the "intuitiveness" of the method completely relies on that wrong intuition. The true mechanism at work isn't quite intuitive.

BTW, I consider using operator+= for this purpose a bad idea, too.

Re:*yeah* initializing std::vectors

[HuguesT]

As it turns out I learned in this post that Boost is able to pretty much do what was wanted through overloading of the comma operator, but what was suggested in the GP was to make vectors first-class types. That does prevent anybody from supplying their own vectors, short of also supplying the compiler.

Re:*yeah* initializing std::vectors

[sqlrob]

Again, no it doesn't, if the standard defines it a certain way.

e.g. std::vector<int> x = { 1,2,3 };
is defined to mean
int xtmp[] = { 1,2,3};
std::vector<int> x(xtmp,xtmp + sizeof(xtmp)/sizeof(xtmp[0]));

The original line would just be syntactic sugar for the next ones. Allow that definition for any constructor assignment to a const array. That wouldn't even limit to the STL classes, you could use it in your own code.

Obligatory

[Arthur B.]

http://linux.wku.edu/~lamonml/software/cpptruth.ht ml So what is C++0x going to obfuscate now ? *ducks*

Why do C++ if you can do Java/C#

[exp(pi*sqrt(163))]

Because C++ still has the performance edge and in some applications (games, other types of interactive 3D app, medical image processing, monte carlo sims of financial derivatives...) performance matters, C++ can bring a tolerable mix of abstraction and performance.

BTW Some people don't see memory allocation as a 'problem'. For many applications you want complete control over memory allocation and you don't want garbage collections and random moments, expecially for applications with a real-time component.

What I don't understand is this: if you're going to sacrifice performance then the world is your oyster. Why do you have to use some lame C++ clone like Java or C#? Why not try ocaml (whose performance isn't bad at all anyway), or Haskell (where you can make your code as elegant as a Haiku), or some other powerful language. C# and Java solve only one problem in C++ but otherwise open up few new options. Functional programming languages rethink the entirety of programming and make countless new techniques available.

Re:Why do C++ if you can do Java/C#

[Dun Malg]

This is of course why the folks at Boeing are using Java as the "pilot" on the next generation of autonomous Real Time spyplanes. Maybe in fact Java isn't actually that slow?

One could write a pilot AI in interpretted basic that would still be faster than a human. We allow humans to fly planes. Therefore solving the problem does not require high execution speed. Java may, in fact, be as fast as you say, but your example is proof of nothing.

Re:Why do C++ if you can do Java/C#

[exp(pi*sqrt(163))]

This is a bit of a crazy way to make a comparison. Boeing's customers almost certainly have the luxury of being able to spend as much money as they like on making up for shortcomings in the software by throwing more hardware at the problem. If, on the other hand, you're writing for games consoles, or embedded systems, or home PCs, you might not have that luxury.

Jave is slower than C++. It's not open for debate.

Re:Why do C++ if you can do Java/C#

[m50d]

My thoughts exactly. I have yet to see a java program that wouldn't be better done in C++ (for speed) or python (for ease of coding).

Re:Why do C++ if you can do Java/C#

[19thNervousBreakdown]

Real-time does not mean fast. It means that operation X will take exactly Y time, every time.

Re:Why do C++ if you can do Java/C#

[Cutting_Crew]

i think when you talk about games, 3D applications, virtual environments, GUI's etc etc, C++ shines. i think as embedded systems, custom built environments start to grow then C++ might gain some of its popularity back...of course i am sure to some extent C# is gaining more ground...but C++ is not biased on a certain platform. AS Linux flavors emerge and become more popular a language will need to be 'cross-platform' if you will.

can you imagine doing Java with OpenGL? i am not talking about drawing a 3D cube or rotating spheres. maybe you have but i cant imagine that, especially when there isnt much support/help out there for it and when dealing with real time interactive applications, virtual environments etc etc as mentioned above Java fails miserably

i agree with some on here though. i have NEVER needed or honestly wanted to use the keyword 'friend'. to most noobs (friend != ur_friend). also i remember in my data structures class in college doing an assignment related to overloading streams. i guess i can see where you would want to overload this but for me in the past and now it has never been worth the hassle or the work. just easier to use the headers that come with the compiler.

as already noted, templates are a mess, confusing and IMO too prone for errors, such as it seems there is no one or two ways of doing something with templates but unlimted instead. conclusion: c++ is powerful, even though not the most noobish language out there, fast for most people, well documented, online community support, cross-platform and overall provides a good standard.

Re:Why do C++ if you can do Java/C#

[exp(pi*sqrt(163))]

Not even 'exactly', just approximately would do for many applications. But in a language with GC an operation that should take 100us might end up taking a full 1s because garbage collection is triggered. Whether you're manipulating 3D objects in a modeling package or waiting for an input device, an occasional delay of even a fraction of a second is not acceptable. For some reason I find most of my career involved with these types of applications.

But I do Haskell at the weekends when performance doesn't matter :-)

Re:Why do C++ if you can do Java/C#

[exp(pi*sqrt(163))]

there is no one or two ways of doing something with templates but unlimted instead

Rejecting something because it gives you a choice is a bad idea. Do what I and many other do. Carve out a subset of C++ that satisfies your needs. Like you, I don't use friends. I also won't use multiple inheritance. I don't reject templates because they allow both abstraction and performance. I'm strict about what operator overloading I'll do (eg. I'll override operator+() if the operation really corresponds to + in a ring or field in the mathematical sense). But I won't reject anything simply because it gives me a choice.

Re:Why do C++ if you can do Java/C#

[EvanED]

i have NEVER needed or honestly wanted to use the keyword 'friend'

I have. In fact, just a couple weeks ago I expressed my angst at a coworker that Java didn't have friend. Know why? JUnit tests.

There are essentially three ways to structure JUnit tests:
1. Entirely separate from the code that's being tested. This is how we have our project set up. Part of our directory structure is:

/src
|--- /src/java
| |--- /src/java/com ...
| (.java files go here)
|--- /src/test/ ...
(JUnit tests go here)

2. JUnit tests in the same package as what they are testing

3. JUnit tests in the same class they are testing

I would very strongly argue that those options are listed it order of decreasing desirability from a design perspective. Unit tests shouldn't ship with the final project and are logically different, so they should be separated.

However, moving down the list brings benefits: you can test more. With option 1, you can only test public methods. With option 2, you can test public and protected methods. With option 3, you can test all methods.

If Java had friend methods, it would be possible to say that everything in the JUnit tests is a friend. Now voila, they can access (and thus test) private members while you still keep them separate.

Granted, it's not a perfect solution, as you still need the friend statements, but it's still better than anything else I see.

BTW, if anyone knows a better way to do this, let me know. We're all pretty new (all interns working very much on our own amongst people who tell us we're the resident Java experts) at this.

Re:Why do C++ if you can do Java/C#

[MosesJones]

If, on the other hand, you're writing for games consoles, or embedded systems, or home PCs, you might not have that luxury

Umm you mean like Boeing... they used the Real-Time Specification for Java, on an embedded device.

You do know that Boeing make more than jumbos don't you?

Jave is slower than C++. It's not open for debate.

Ah but then I have only the benefit of experience rather than of narrow minded certainty.

One thing that could be added...

[ratta]

is the possibility for allowing templates depending on a class type T to list/access the class members in some way, in order to be able to define a

template serialize(const T& t);

that prints the members of the class recursively.

Re:One thing that could be added...

[KatieL]

Actually this one is perfectly possible using existing C++ and some template jiggery-pokery.

I've used it for recursive serialisation in the past.

Now, a "build by name" that doesn't need a seperate "registration" scheme to log class names in and out of would be nice.

Re:C++ Viability

[superpulpsicle]

Alot of these professors started their career roots with C and old school languages from th 80s. They see no need to change. Why go to C# and have some kid in the classroom smarter than you?

There is still alot of schools out there with a strong focus in C++. The programs figured if you can learn C/C++, you can learn the rest. The reality is not so true. I have seen plenty of graduated kids really struggling to learn a non-Object oriented language.

Language should not be modifies only for novices..

[ratta]

"template typedef" is for instance something very important (and that will very like be added). Templates are a compile-time functional language, and i think that making this functional language more powerful and easer to use could be a big win.

A second wave for C++

[Uksi]

I won't argue the relative merits of C++ to other languages. For many organizations, switching from C++ (regardless of whether it would make things easier) is often not an option, and not considered as an option. I will also not argue whether that is bad.

The fact is, there's a huge C++ user and code base out there, and if they are going to stick with C++, there's exciting stuff coming.

I feel that C++ is having its second coming, primarily due to developments like the boost library and the Modern C++ Design book.

For example, I've been using a combination of boost::function and boost::bind to make powerful, flexible callbacks like nobody's business. Finally, there's a function "pointer" that can work with both freestanding functions, member functions and function objects, and finally there's an easy way to delay calling functions and use closures, respectively. (Also see boost::lambda).

Sure, almost all of this has been possible one way or the other (the flexible callback has been typically implemented via function ptr and void ptr argument, C-style), but it's very refreshing to actually have the code say what you mean: "I want to delay calling this function", or "this callback doesn't give a crap whether the function you're giving it is a member function or not".

Then there are smart pointers, which have easier-to-follow, clearer semantics, and can be used in STL containers and such. No more using easy-to-shoot-yourself-in-foot auto_ptr. It's been possible to write large chunks of code that have multiple "new" statements, but have no "delete" statements, all while maintaining exact control over the memory allocation.

Of course there's more... Maybe it's stuff that LISP/Scheme programmers have been using for ages, but the key difference is I can now apply tools in production commercial C++ code, during my everyday work. I no longer sit and say: "oh, crap, I could really use a closure here." I just do it.

A big problem is that the new features require greater understanding of the language and thus better training of the run-of-the-mill C++ developer. Many C++ developers I encounter do not have the sufficient understanding of these tools, and of the language. We should strive to educate our fellow developers, ... For Great Code!

Re:A second wave for C++

[Omnifarious]

I actually really like auto_ptr. I think it should be a rule that containers use default constructor + 'swap' when they need to move an object in memory instead of the typical copy constructor or default constructor followed by assignment operator. That would let auto_ptr work just fine with them, and make them more resilient in the face of exceptions.

Re:A second wave for C++

[ckaminski]

Are you NUTS?

Try this for example (pseudo):

vector< auto_ptr<classB> > vec;
vec[0] = bPtr;
vec[0].operator();
doSomething( vec[0] );

function dosomething( auto_ptr<classB> bPtr ) {
bPtr->operator();
}

Tell me what happens.

If you don't pass auto_ptrs by reference, you get your ass handed to you. Violently. Frankly, that's an implementation detail I'd rather not care to deal with. Smart refcounted Auto_Ptrs aren't much better, but I know I don't have to treat references differently.

Re:A second wave for C++

[Omnifarious]

If you don't pass them by reference, you get what you deserve. They are not general purpose smart pointers.

I don't like the reference counted smart pointers because I think they're more expensive than what they're worth most of the time, and I think they encourage sloppy programming. If I want to program sloppily, I'll use a forgiving scripting language like Python.

But, if the vector class were re-done to not use the assignment operator or copy constructor for the contained objects, it could work just great with auto_ptr if you exercised a reasonable amount of care.

Maybe, instead, it would just be better to add a template parameter that allowed you to specify that the vector owned the pointers it contained. But I think my solution is a bit more elegant.

Re:A second wave for C++

[ckaminski]

I don't see how I should expect that to "get what I deserve", especially if I pass to a const object. Granted, it only bit me for the better part of half an hour in some really sloppy stream-of-consciousness first run bullshit code, but it soured me... As a side effect, it's a fairly insidious one, I'd say.

And I don't see how I'd want to exercise "care" using my containers. Either they store first-class objects the same, or they don't. Why make the containers more complex to support one broken object?

I'll agree that refcounted pointers are expensive, but I'm not sure I'll agree they encourage sloppy programming. In fact, in some event driven domains (webservers, etc.) I'd propose they provide a simple solution to complex housekeeping tasks. But why don't we just agree to disagree.

You can specify all the parameters you want, but if auto_ptr is coded thusly:

auto_ptr<T>( auto_ptr<T>& rhs ) {
this.ptr_value = rhs.ptr_value;
rhs.ptr_value = null;
}
~auto_ptr() {
delete this.ptr_value;
}

You're going to add a LOT of complexity to your containers to fix an agreeably useful, but semantically badly designed object. While I do still use auto_ptrs, it's only as closure protection since the C++ standard has seen fit to do without a finally() exception block. I no longer pass auto_ptrs as arguments. I'd normally write some closure<T> template, but would much rather use something that someone is familiar with, than have to figure out what my closure template does.

Fundamentally, I think it comes down to the fact that pointers are dangerous idioms, and the walls we build around them are bound to be frail and full of holes, because they are so flexible and powerful. I'm not sure if language support for refcounted pointers would help fix the problem. I'm not sure I even want to contemplate it. It would certainly involve a tradeoff in speed and size.

Re:A second wave for C++

[Omnifarious]

Reasonable amount of care meaning that you don't copy the auto_ptr out into another auto_ptr.

I actually like the default-constructor + swap idiom a little more than assignment or copy-construction, though they seem more obvious. I think it can be more efficient, and I think it matches the semantic intent a little better. I think it makes containers more complex to code only in that the standard conventions aren't used in favor of something a little odd. I don't think it adds any extra code paths or exceptional cases. In fact, I think it reduces them.

Here is what I mean by default construction + swap...

T x(y);

becomes...

T x; x.swap(y);

and...

T x; x = y;

becomes...

T x; x.swap(y);

Containers don't really have to make copies of objects. They just need to move them around. The swap idiom is fine for this purpose. If cotnainers changed to use it instead of assignment or the copy constructor, they would work fine with auto_ptr.

Re:Why new languages: Why?

[elflord]

I don't understand why languages that take someone like me hours and minutes to learn fully have to be changed will-nilly every ten to twenty years.

I agree with you -- but if you read the article, you'll notice that Bjarne's point of view (and for that matter, the prevailing view in the community) is also consistent with yours. Basically, changes in the language are to be as minimal as possible. The changes that he proposes will not make life harder or more confusing. The "new C++" is going to be much the same as the old C++, but with a larger standard library.

The place where more substantial changes will occur (in fact have already occurred in TR1) is in the library. Libraries do change, that's a basic fact of life. The C++ standard library is still much simpler than other standard libraries.

Re:C++ Viability

[BarryNorton]

Alot of these professors started their career roots with C and old school languages from th 80s

From the 80s? It's a shame these 'schools' aren't teaching languages with features worked on since the 1970s so students could realise that imperative is very often not a sensible choice, and that the type system can be an ally not something to fight against or abandon...

Member function pointers

[chrizel]

What would be great if C++ gets member function pointers to make things like:
button.onClick = myObject.handleClick;

(Delphi has this sort of event handling)

At the moment you have to play with ugly templates (see gtkmm/sigc++) or you have to make language extensions like Qt does with Signal/Slots.

If C++ would have easy member function pointers (without scary syntax) it would be possible to make nice GUI toolkits in it. The Qt-way is good but not standard... MFCs and wxWidgets way of event handling are ugly C macro dispatch tables, afaik...

Easy member function pointers -> please put it in! :-)

Re:Member function pointers

[jeff_schiller]

You can get this functionality looking very close to what you have written. Look up Boost.function and Boost.bind.

Re:Member function pointers

[wxprojects]

> If C++ would have easy member function pointers
> (without scary syntax) it would be possible to
> make nice GUI toolkits in it. The Qt-way is
> good but not standard... MFCs and wxWidgets way
> of event handling are ugly C macro dispatch
> tables, afaik...

*sigh* wxWidgets has had a way to dynamically connect events for a while now - example

mywindow->Connect(mywindow->GetId(), wxEVT_PAINT, wxPaintEventHandler(MyWindow::OnPaint));

Re:Member function pointers

[dmh20002]

It may not be exactly what you want, but C++ has pointers to member functions already.

class X {
public:
virtual int member(int x) {
return x;
}
};

int main(int argc, char* argv[])
{
X x;
int a;
int (X::*p)(int) = &X::member;

a = (x.*p)(0);
}

the missing thing is that the pointer-to-member doesn't bind to a specific object. you need to have an object reference also, so you would need to store the pointer to member and also a pointer to the object you wanted to access.

Syntactic candy.

[mcc]

This is mere unnecessary conveniences. What exactly are they giving us here? Well, if I'm reading this right, "C++0x"* will give us:

• Some cases where you can type ; where previously {} was necessary, saving as many as two keystrokes.
• The lexer ambiguity where a<b<c>> and a<b<c> > meant entirely different things is fixed, saving as many as one keystroke.
• EVEN MORE "free" constructors which may or may not work quite the way you wanted them to in practice.
• More "fancy cast" operators, which sounds nice until you remember that if there's ever a time you find yourself using the C++ "fancy cast" operators, then there is a damn good chance that it's because you're doing something unwise enough it really would be a better idea to refactor the code to make the "fancy cast" unnecessary.

...in the meantime the fundamental issues with C++ remain not only unresolved, but unaddressed. The template system is still not a generics system, but an ugly cut & paste macro system which can incidentally be used for generics, with some caveats. The class system is still fundamentally brittle and unfriendly to simple things such as upgrading a DLL or determining at runtime if two objects are of the same type. The syntax is still a forest of features whose features interact in ways so crazy and unpredictable it approaches Perl in its chaos; references are still gimped; the distinctions in behavior and use between static and dynamic objects remain awkward and newbie-unfriendly. The features that people obviously desire to have in the language as demonstrated by their tendency to hack them in with third-party libraries (like BOOST) are-- they tell us-- a good thing, and they tell us we should continue to hack them in with libraries (like BOOST). That's nice. You know, that would be a lot easier though if we had a macro system** capable of anything smarter than blind code cut and paste-- or at least a macro system** fundamentally designed to be used for anything at all other than generics.

Meanwhile, it appears if I'm reading this right that the most important differences in C++0x will be changes to the standard library. Great. The STL was defined how many years ago, and it's only just in the last few years that compliant implementations have become commonplace? How many decades will it be before the "C++0x" library changes have become common in a cross-platform compatible way?

C++ is an extremely useful language, and making an update to C++ which changes as little as possible so as to follow some kind of "if it aint broken don't fix it" principle is an idea which makes a whole lot of sense. However it seems likely to me from reading this that C++0x will offer so little significant difference from C++ as to make itself simply redundant.

* ("C++0x". Were they specifically trying to come up with a name less convenient than "C#"? Ah well, I guess we can call it "COX" or "cocks" for short.)
** "Template system"

Re:Syntactic candy.

[fdicostanzo]

I don't know if you intentionally missed it, but I have been wanting that 'auto' syntax for years now. That would save me from a bunch of headache.

Re:Syntactic candy.

[mcc]

I'd kinda skimmed past that, it seems. That does look pretty useful, even if only to metaprogrammers.

Re:Syntactic candy.

[NFLFan]

# Some cases where you can type ; where previously {} was necessary, saving as many as two keystrokes. # The lexer ambiguity where a> and a > meant entirely different things is fixed, saving as many as one keystroke.

I don't think it is about saving one from typing but preventing errors. An expierenced C++-er knows to avoid >> with templates but does a beginner? The error messages can be less than great with templates- so avoiding one is all the better. The error message that g++ now seems to give is helpful but so annoying saying something like "you used >> where you wanted > > ... [c++ template garble]."

EVEN MORE "free" constructors which may or may not work quite the way you wanted them to in practice.

That sounds like a very ignorant argument. I used this constructor but it does not do what I want it to, is it wrong?

More "fancy cast" operators, which sounds nice until you remember that if there's ever a time you find yourself using the C++ "fancy cast" operators, then there is a damn good chance that it's because you're doing something unwise enough it really would be a better idea to refactor the code to make the "fancy cast" unnecessary.

I assume the current fancy C++ cast operators you are talking about are static_cast and dynamic_cast. With the lack of multi-methods and it being an error to downcast an object c-style I think the need for static_cast and dynamic_cast are clear. The only good clue to maybe needing to refactor an hierarchy is when it is unsafe to use static_cast in place of dynamic_cast (when you know the type), times when you have virtual base classes and other goofy instances.

Re:Syntactic candy.

[cbciv]

The lexer ambiguity where a<b<c>> and a<b<c> > meant entirely different things is fixed, saving as many as one keystroke.

Nice strawman. The real reason is to prevent newbies from having to figure out why "a<b<c>>" gives them a weird error message when logically it should do exactly what it says. The parser should make my life easier by allowing me to write code logically and not requiring me to work around its stupid limitations.

Re:Syntactic candy.

[AuMatar]

A nice time saver even for pros. I know that bug exists, but I still type it wrong occasionally, then waste time trying to compile it.

Re:Syntactic candy.

[EvanED]

The template system is still not a generics system, but an ugly cut & paste macro system which can incidentally be used for generics, with some caveats. ...and which is a couple of orders of magnitude more powerful than a simple generics system.

"C++0x". Were they specifically trying to come up with a name less convenient than "C#"? Ah well, I guess we can call it "COX" or "cocks" for short.

No, they're following a couple (at least) decade old convention. Standards are described by the standard name followed by the year.

C87 is the C language as standardized in 1987. (Or whatever year it was.) C99 is the C language as standardized in 1999. The full name of the current C++ standard is C++97, because it was standardized in 1997. C++0x refers to the next version of the C++ standard. Only it doesn't have a full name, like C++08, because we have yet to invent a device that will see into the future to find out when the standardization actually occurs. Thus we need a placeholder.

Re:Syntactic candy.

[Anonymous Brave Guy]

You're missing a lot of background here. The article is more about some of the design principles they're adopting (e.g., focus on extending the library, while keeping the language as unchanged as possible) than about enumerating all the new features under consideration. If you want the latter, much of the discussion is public; just search the standards committee's web pages.

Re:Syntactic candy.

[SamNmaX]

While I agree C++0x doesn't address many issues and can see where you are coming from with most of your comments, I think you are making many invalid assumptions.

The lexer ambiguity where a<b<c>> and a<b<c> > meant entirely different things is fixed, saving as many as one keystroke.

This is not about saving keystrokes, but about making the language more understandable. This has always been a silly issue with the language that nearly everyone trips up with at some point. If <> are going to be used as brackets, they should act like brackets, and not require spaces between them.

The class system is still fundamentally brittle and unfriendly to simple things such as upgrading a DLL or determining at runtime if two objects are of the same type.

DLL issues is really separate from the language. The language does support comparison of types of objects through RTTI, though it's almost a rule that if you need this you probably aren't using the language as intended.

References are still gimped

I assume you mean references aren't like references in Java, where they can be reassigned. There's not much reason why pointers can't be used instead, nor smart pointers.

the distinctions in behavior and use between static and dynamic objects remain awkward and newbie-unfriendly

By 'static' objects, I assume you mean objects that objects that are automatically created and destroyed on the stack. I agree it's a stumbling block for newbies, but any change in this would be a very fundamental change in the language. Java's 'solution' to this is to just have dynamic objects combined with garbage collection. For C++, creating stack objects means you know *exactly* when the object will be destroyed, with no need for garbage collection or manual call of 'delete'. As well, you can use this as an idiom for features like locking some sort of resource with a 'lock' object, which automatically unlocks when the object is pushed off the stack.

The features that people obviously desire to have in the language as demonstrated by their tendency to hack them in with third-party libraries (like BOOST) are-- they tell us-- a good thing, and they tell us we should continue to hack them in with libraries (like BOOST). That's nice. You know, that would be a lot easier though if we had a macro system** capable of anything smarter than blind code cut and paste-- or at least a macro system** fundamentally designed to be used for anything at all other than generics.

I don't know if a macro system is appropriate. Ideally the spots where BOOST has to copy/paste could be dealt with in a smarter way.

Meanwhile, it appears if I'm reading this right that the most important differences in C++0x will be changes to the standard library. Great. The STL was defined how many years ago, and it's only just in the last few years that compliant implementations have become commonplace? How many decades will it be before the "C++0x" library changes have become common in a cross-platform compatible way?

Well, if you think changing the STL is hard, changing the language itself is generally a lot harder. Ideally, you could have (essentially) one implementation of STL that, without any hacks, just works on all systems. The reason this doesn't happen is because of issues with the language, most notably issues with implementing templates.

I definately think though, that if a useful feature can be cleanly implemented in the standard library instead of the language, that's the way to go. If it can't, then as Bjarne discusses in his article, it's best not to just add that feature to the language, but look and see if some general mechanism can be added to the language that would not just benefit that one feature but possibly many other features people could add later.

* ("C++0x". Were they specifically trying to come up with a name less convenient than "C#"? Ah well, I guess we can call it "COX" or "cocks" for short.)

It's C++05 or C++06... depending on the year the standard comes out.

Re:Syntactic candy.

[ivec]

Well, if I'm reading this right, "C++0x"* will give us:
I don't think you've read this right, if at all.

C++ is bringing us much more than the tiny details you are focussing on. For a picture of what's going one, check the many proposals that are currently being reviewed:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers /

Templates in C++ are much more than a macro system, which already existed in C. What exactly are you looking for that is not supported in C++ templates? Maybe introspection, or the definition of constraints on the template parameters? Well, there are proposals for adding both of these features to C++0x.

Boost has been a powerful tool for studying the design and implementation of new features as library extensions. Many have matured, and now that the community has gained experience with them, they are being integrated to the standard language. Just because of this higher level of maturity, I expect to see them properly implemented much faster than the original STL.
Many features offered in Boost work nicely as is, and are being integrated in the standard library (e.g. function objects/delegates, ref-counting smart pointers, tuples, regular expressions, threading).
Others were proven to require language changes, which are being proposed for integration in the core language: typeof, closures, etc.

Finally, "C++0x" is not the name of a new language. It is a reference to the next standard, expected sometime before 2010 (therefore 200x), which will become The C++. There is just no marketing guy giving this a fancy name to sell it as the next big thing.

Re:Syntactic candy.

[julesh]

No, they're following a couple (at least) decade old convention. Standards are described by the standard name followed by the year.

Algol 58 is the earliest example I know of. AFAICT the first non-Algol language to use the convention was FORTRAN 66; then lots of others started doing it.

How about a module system?

[putko]

More powerful languages like ML, CAML and some Schemes have a module system. This allows the programmer to control the meaning of identifiers (e.g. what function they mean). E.g. what gets imported (and with what name), what gets exported.

Often there is a separate notation for the modules -- it says what files contain the things, what's exported/imported etc.

That's very useful for encapsulation.

C++'s namespaces are a crappy attempt to get the benefits of a module system -- that's likely where he got the idea from.

Hygienic macros would be a good step too.

Re:How about a module system?

[devphil]

Go read the papers at the C++ ISO Standard homepage. Module systems have been proposed well before /. got around to bitching and whining, and many of the ideas in your post were taken into account. Something is already in the works.

Re:How about a module system?

[Xepo]

You can really accomplish this with namespaces as they are currently.

The using keyword isn't only used in using namespace std;. You can also say things like: using std::vector;. You can also make aliases to namespaces: namespace sp=boost::spirit; Separate things correctly with namespaces, and know how to use using and you'll already have this functionality.

Re:How about a module system?

[putko]

But you can't use only some things from a namespace, and give them new names in the new namespace, can you?

Or how about making a namespace that is a union of subsets of other namespaces?

Or a namespace that takes some other namespaces (like a function takes arguments) and gives you a new namespace?

Its because of these missing features that I call C++ namespaces (as I last got to use them) "crappy" versions of the real thing. I'm guessing, based on your blithe answer, that you haven't experienced the true power of a module system.

Re:How about a module system?

[Xepo]

My question for you is why would you ever need to rename things out of one namespace? C++'s typedefs should fulfill any sort of renaming need you may have. If you're getting name conflicts...well, Stroustrup says you shouldn't use the "using namespace" statement anyway, but should either completely specify the namespace (or a renamed namespace as it may be), or only import specific items from the namespace.

And if you fail to see how you can make a union of namespaces from my previous post, then you're simply not thinking at all:
namespace unionwow {
using namespace soandso;
using soandsoandso::object;
}

Whoa! I've got a union of the full soandso namespace and an object from soandsoandso.

I also fail to see how function-like namespaces would be desireable. Best I can think of is for things currently accomplished with templates, like parameterizing a vector module on an int datatype.

You're right, I don't have too much experience with any language that has function-like namespaces, and hence I fail to see their use. Care to explain?

Re:How about a module system?

[putko]

Here's an explanation. Here's a manual. Here is a writeup.

I encourage you to look at any of those and then this C++ proposal (from the ISO people).

http://www.open-std.org/jtc1/sc22/wg21/docs/papers /2004/n1736.pdf

Let me know what you think.

Re:How about a module system?

[julesh]

Stroustrup says you shouldn't use the "using namespace" statement anyway

Are you sure? Here's an example from his web site's technical FAQ:


#include<vector>
#include<string>
#include<ios tream>
#include<algorithm>
using namespace std;

int main() // small program messing around with strings
{ ....

Re:How about a module system?

[Xepo]

My bad, it was here that I saw it: http://www.parashift.com/c++-faq-lite/coding-stand ards.html#faq-27.5

Best quote in the article!

[Mirk]

From TFA:

So, why don't we just accept all reasonable suggestions to make everybody happy? There are too many suggestions to analyze and adequately specify. If we accepted all suggestions there would be six or seven ways of doing anything in C++, rather than just two or three.

Re:C++ Viability

[stanmann]

In CS, you should have learned programming, not a language. You should have been exposed to at least 6 different languages as well as compiler concepts and OS design. If you were not, then you have a Programming degree, not a CS degree, regardless what your diploma says.

And "standard" libraries....

[genneth]

... aren't that standard. Look at the effort that it takes to get Java ported to somewhere. Kaffe is/has been ready for years. Classpath (your standard library) is only getting useful (it compiles Eclipse!) And how many "deprecated" components are there in Java? C++ has plenty of people working on less-than-set-in-stone projects, but those shouldn't be considered standard. Use gktmm by all means. Use Qt. Use ACE. None of them can be considered standard, but you can use them today and Get Shit Done (TM). Hell, even Boost isn't standard. The day anything turns standard in C++ is the day that niche is basically done (on the scale short of introsort pushing out quicksort). GUI programming is by no means a done deal yet; the Adobe people are working up some very interesting tools; Mozart is investigating along similar lines; there's also a smaller personal project that uses embedded DSL in C++ (Boost.Spirit style). Until the One-True-Abstraction blows everything else away, you get the choice of making your own bed and lying in it.

Re:Waiting for C++ 2007 lite ANSI standard

[SIGALRM]

C++ is losing market share

Probably not the right terminology: C++ is not a company, and coders are not a "market" per-se.

The advance of Java and C# prove that large parts of OO functionality found C++ are not necessary.

Managed code and VM's dictate a completely different set of rules (and yes, I do understand managed C++ exists), and thus cannot be compared one-to-one. That said, I never use multiple-inheritance in C++, implement interfaces. Java and .Net did not "show" me that, experience did.

- C++ lite - essentially what C# is today

Again I disagree. Formulas such as "((C# == C++)--)--;" look cool but oversimplify, and fail to see the richness of both environments.

Re:Deja vu

[(void*)cheerio]

First off, Java only recently got templates and generics.

Secondly, C++ is a multi-paradigms language, you can OO or not OO, template or not template, h4x with the void pointers or not h4x with the void pointers. You and your problem choose, not someone else.

It also has operator overloading and you can control your resourse management options, rather than rely on Java's garbage collection which fails when you want to manage resourses other than memory (e.g. DB connections)

So Java and C# may have superseded C++ in many domains, but C++ is still king baby. Albeit a mean king.

Yes, Sun tried that

[Rogerborg]

And then Microsoft did it right, with C#. Really. It's like C++ version 3, i.e. the one that finally works the way it's supposed to.

Re:Waiting for C++ 2007 lite ANSI standard

[grahamlee]

I think the OP would have got on better with "mindshare" than market share...but that's just an aside. I agree that C++ and C#/Java/Objective-C object models cannot be considered supersets or subsets of each other, and think that a language which was "C++ but with C# inheritance" would not be a useful language. At least it wouldn't be a language offering anything significant that others already don't - it would be like Objective-C with static compile-time method lookups. I've never particularly got on with multiple inheritance (I'm an ObjC protocol/Java interface man) but it has its uses to a lot of people - I think it seems like a first go at aspects. Get rid of it and whatever you end up with may be of use to someone, but C++ it isn't. My particular issue with C++ is that which BS seems to be warning against - unlike him I already think there's far too much in the C++ language that should properly have gone into the standard library. For me, OO languages should be like Ruby or ObjC - give me a way to manipulate objects, then give me a bucketload of objects. On the other hand, it's possible to go too far in the opposite direction and end up with a designed-by-committee API like Java which bloats with every new release, because someone somewhere didn't like a particular package and decided it needed a complete reimplementation (but we can't deprecate the existing one for another release or so).

Re:I don't think so

[elflord]

C# is much more than a "Windows programming language". There is a vast amount of C# code available on Mac and Linux, and C# is a standard, not just a MS language. Mono, heard of it?

Yes, I have heard of Mono, which last I checked does not include major parts of the core C# libraries. How many major linux applications are written in C# ? I agree that it's a standard. But it is originally designed, and implemented, as a Windows programming language. For example, it is designed to run on an operating system that has a number of features including support for graphical user interfaces and multithreading. It is not a general purpose programming language in the same sense that C++ is.

Nothing is wrong with C#

[Rogerborg]

C# is what C++ always wanted to be. It was written by people who had learned from the mistakes of C++ and Java. It's not perfect, but it's better than either of the others for the majority of desktop and server applications. Anyone who tells you otherwise is a Microsoft hater, or isn't working in that problem realm.

You might also want to have a look at the D programming language, which is a ruthlessly pragmatic alternative.

Re:Nothing is wrong with C#

[Compenguin]

I read about D a while back and i like most of it's changes/features but without a major backer I don't see it going anywhere.

Re:I don't think so

[xtremee]

C# can be compiled without any problems in almost all platforms

Re:The future of C++...

[Nasarius]

... is extinction. Just stating a fact here.

Obviously. The same goes for any language. But what do you propose to replace it? The vast majority of "modern" languages are not compiled to machine code. For the moment, C++ is a good balance between the efficiency of C and the user-friendliness of higher-level languages. It fills a niche (resource-gobbling 3D games, operating systems, compatibility with C/C++ libraries, etc) that no other language does.

Re:How about...

[CptNerd]

..we wait for people to actually understand amd implement the current C++ standard?

Unfortunately, because the spec is so convoluted, you can implement some aspects in completely incompatible ways, and still be "implementing the standard."

I've been in the profession for over 20 years, and I've seen the same thing happen to certain "standards". Something new and innovative will come along, and within a decade, features will be added that will make it unusable, and foster the demand for "something like X but easier/simpler/faster/cleaner". Most of the feature creep is driven by large corporate interests and the demands of their programming staffs to add features that they claim they can't develop without.

Not many people remember X Window 10R4, but the entire Xlib documentation took up a half-inch thick stack of single-sided pages, and described a basic networked window system that was useful enough to develop distributed systems with. The protocol was easy to implement, straightforward, and clean. But that wasn't good enough for the wonks at Apollo, DEC, HP, Sun, AT&T, and the researchers at MIT. So, once everyone added their "must have" requirements to X Window (we have to have font servers or we can't write good systems!) you ended up with a monstrosity of an Xlib spec that took up a thousand or so pages of documentation, added thousands of new points of failure, and spawned an entire bookshelf from O'Reilly just to try to explain how to use X.

I saw the same thing happen to C++. In the early days it was what it set out to be, a simple, easy to implement extension to C that let you do basic object oriented programming. Sure, it wasn't Smalltalk or Scheme, but it was good enough for 90% of the tasks that really needed simple lightweight objects. But, certain vested software interests demanded that the spec be extended to include things like templates and virtual this and that, all designed to save some corporate programming group some design time, at the expense of creating a spec that required Talmudic scholars to interpret.

I've been on the outside of Java, watching it since it was first described, and I've seen the changes and additions to the language spec over the years. The same thing is happening to Java that I saw happen to X and C++, and I predict that in 10 years or so someone will come out with a language "that does what Java does without all the overhead". I knew Java was doomed to follow the C++/X path when they announced namespace support in the language. Sorry, Javaheads, but that was the tipping point, and you're all on that long slide into obfuscation and bloat that many derided C++ for.

I know many who actually read this post won't believe it, will argue that "Java is different" somehow, but mark my words, Java will bloat into uselessness within 10 years, just like C++ did.

Two important additions

[ardor]

1. signals & slots. These *must* be introduced. Event handling is a breeze with them.

2. make it mandatory for allocations to be deallocated in the heap they were allocated, that is, for example if you allocate memory with new or malloc() in a DLL, and you deallocate it with delete or free(), then the deallocation must be done in the DLL. This could be done with some tables storing the heap for each allocation. This is *very* important if you work with several DLLs in your project, since if you deallocate something that was allocated in a different module, the system crashes because you try to deallocate in the wrong heap. Especially STL containers cause a lot of trouble with DLLs.
Well, this can be solved by overloading the new & delete operators; also, choosing "multithreaded DLL" as CRT in VisualC is a solution, since then all "multithreded DLL"-Modules share the same heap. Nevertheless, this is something that should be dealt with in the language.

Re:Two important additions

[JustNiz]

>>> Nevertheless, this is something that should be dealt with in the language.

*Sigh* yet another Windows user who thinks every OS=Microsoft.

A langauge should not implement OS-specific features. Don't blame Stroustrup for Microsoft's godawful API and crappy memory-management design. None of your issues are problems in Linux, for example.

Re:Two important additions

[AuMatar]

On number 2- first off, not all platforms have dlls. Most don't (or any equivalent).

Secondly, this isn't possible. An app doesn't know if its in a dll or the main app code. It doesn't know if memory being passed to free was allocated in one or the other. There is no way to know this- a pointer doesn't hold any memory of its origins, unless you write an allocator that knows it.

Solutions:

1)Design your apps better so they do this.

2)Overlaod new and delete so they call a custom allocator, make the custom allocator/deallocator do this. You'll have to add some logic to tell if you're in a DLL or not- set a global variable the allocator can read at the top and exit of every function. ANd it won't work on 3rd party apps that don't follow that spec.

MOD PARENT UP

[orfanotna]

-1 Troll??

Come on, that post should have been modded +100,000 Funny. Man, that just made my day.

What large projects has Stroustrup worked on?

[Rogerborg]

Another unmarried marriage guidance councillor.

Template madness

[Anonymous Brave Guy]

Stuff that went into Boost should be in the standard library from now on...

Oh God, please, no!

C++ desperately needs some basic functionality in its standard library: concurrency, GUI, maybe things like sockets. (Alas, by the standards committee's own admission, some of these -- particularly the GUI one -- are unlikely to happen.)

What C++ doesn't need is for its relatively simple but useful standard library to be overwhelmed by every template freak and his brother's pet ideas, which is very much the direction a lot of the "in crowd" and a lot of Boost contributors are tending towards at present.

By all means, let library designers use whatever language features are useful in whatever ingenious ways they can, but please let the interface for anything that actually gets into the standard library be simple and effective, not infinitely customisable but massively over-complex. That means some parts of Boost would be excellent additions, but others certainly would not.

Re:Template madness

[AuMatar]

I'd disagree these are good ideas for a library. The idea of a standard library s that it should indeed be standard- no matter what OS, it should work with full functionality. The problem here is that they don't.

Concurrency- different OSes have different concurrency primitives (sometimes *very* different, look at real time OSes vs Unix vs Windows semaphore APIs). Some have very complicated APIs but end up with high functionality (deadlock prevention) as a result.

Sockets- They could standardize on the BSD socket API. The problem there is twofold. 1- different OSes implement it differently. For example, WIndows cannot select on a TCP and UDP socket simultaneously. Also in WIndows, a read with MSG_PEEK in the flags will always read the same length, even if new data becomes available. Unix has neither of there (mis)features.

Secondly, the BSD socket API is not user friendly. Wierd structs to fill out, multiple steps to do simple things like listen on a port. It makes it very flexible, but it makes the common case hard. As a standard library, it can't afford to lose flexibility. But making that choice will just garuntee that coders use libraries on top of that layer, just as they always have.

GUI- GUIs do not work in any way the same between platforms. Many, many platforms do not have a GUI at all (embedded). Its impossible to get identical behavior on all platforms. This makes a *bad* candidate for a standard library.

Personally, I'm not a fan of big standard libraries. For one, they inhibit innovation. Once a standard library exists, there's little reason in most programmers minds to improve on it, so new interfaces don't get tried. Look at how long Java limped under AWT because it was standard.

Secondly, a large standard library just makes it difficult to stay consistant and to implement the standard. This is part of why open source Java implementations have so much trouble.

I'm much more a fan of Boost and CPAN style library collections. Let the users innovate and share. The cream will rise to the top, and a good website or two will make it easy to find them.

What is C++'s popularity?

[gregarican]

I know that's a relatively intangible question to quantify but I did find a survey that lists different programming languages used in the workplace. Seems as if C++ definitely isn't dying just yet. I found another seemingly google-based article on the popularity of various programming languages. Sure Java and C# are up there with PHP thrown in as well, but C++ still has lots of current uses. Seeing I am hooked on Ruby in my workplace I am one of the few according to all of these figures :-)

Re:What is C++'s popularity?

[curtoid]

Well, first off C/C++ is the language in which the OS is written. And secondly, it's fast, which is the reason for #1. I am a die-hard C/C++ programmer and write such things as drivers and image processing code, which need every ounce of speed they can get. I use C++ over C because it is Object-Oriented and, therefore, complete code modules can be reused without difficulty.

I never cared much about the "virtual machine" languages (VB, JAVA, etc.) because that machine is pathetic when compared to the host due to the overhead of the anti "code slop" and technology guarding (i.e. lock-in) features.

int stroustrup(char *a, const char *b, int n)

[dtfinch]

For a moment there I thought I was looking at a new function name. No offense intended.

What time is it?

[TimePressured]

Interesting article, no attempt to learn from the mistakes other languages have made. No observation that India/ China/ Pakistan are the new markets. No acknowledgment that the programming IT market is shrinking. C++ was previously just lucky as its previous early adopters were not primarily professionals but were more importantly enthusiastic. As India grows a crop of new low paid professionals just how long will C++ stand up in a world with substantially better language / framework and practical alternatives? 20 x 20 hindsight show that "No substitute exists for being in the right place at the right time" Stroustrup forgets the time,

Re:What time is it?

[Anonymous Brave Guy]

Stroustrup created a language that has lasted some 20 years already, with an estimated user base of 3 million people, popularising numerous programming concepts previously reserved for academic or obscure programming languages, and you are going to lecture him about timing? That's really very, very funny.

Re:What time is it?

[TimePressured]

Don't get me wrong, I think current version has indeed been embraced. I wonder though, how many programming languages were created consumed and still used today not out of capitalism, but out of anguish and pain points with the current version of C++ and the library.

And to his credit, Stroustrup is looking at the exact same thing. He's examining pain points and factoring a life time of personal knowledge into it. Also, he's not doing it in a vacuum. I guess the question what time is it? should really goto the communities who have large investments in code.

God I hope they stand up be brave grow some balls and tell him what they believe.
It was my impression that most of his feedback is not from companies or awareness groups but from frustrated individuals.
Not everyone who thinks they are a programmer is a programmer.

Re:Isn't It Time for the Software Industry to Stop

[turingcomplete]

What kind of twisted logic caused you to work in C++ for 16 years? Pure stubborness or lack of carreer mobility? The WISH LIST of the UPCOMING C++ standard includes absolutely basic things like - Threads - GUI Support (not real GUI support mind you, just things like call backs that make this easier) - Database support When Java, which you so offhandedly distain, had things java.lang.Thread, Swing, and JDBC since Java2.

Strostrup is in denial

[Animats]

C++ is in deep trouble, and Strostrup is in denial about it.

C++ is the only major language with extensive abstraction but without memory safety. All other major languages are either memory-safe or don't hide the underlying machinery. (Java, C#, VB, Perl, Python, etc. all have automatic memory management. Some use garbage collection; some use reference counts. C is unsafe, but hides nothing.) This fact is responsible for millions of program crashes every day. Most security holes in C++ code come from this problem. Java and C# were invented primarily to eliminate the safety problems of C++. The open source community has generally stayed with C, where at least you can see by examination what's going on. C++ is losing market share to Java.

And Strostrup denies this is a problem.

This has happened before. Last time, it was Wirth. Wirth designed Pascal, Modula, and Modula II, but refused to admit that each had serious problems. He fought external compilation in Pascal. He fought extensions to the language. He even fought compile-time arithmetic. In the end, he took Pascal from a major language to a historical footnote.

Serious systems programming was once done in Pascal, but not in Wirth's version of it. The original Macintosh and Lisa software was written in nonstandard versions of Pascal. And much of the DOS era was built on Turbo Pascal. But proliferating nonstandard versions of Pascal caused another set of problems.

C++ has been in decline for years. "Evans Data has found that the percentage of developers using C++ has steadily declined over the last six years--from 76 percent in the spring 1998 to 46 percent in fall 2004." Strostrup also denies that.

The C++ committee has been taken over by template fanatics. Most of the committee's effort revolves around obscure template features that few will use, and which no responsible programming manager would allow on a mission-critical project. There's very little interest in language safety, and a vocal minority that insists language safety is undesirable or impossible.

All is not well in the C++ world. Claming otherwise is irresponsible.

Re:Strostrup is in denial

[I judge you]

C++ is the only major language with extensive abstraction but without memory safety

And for that, I thank C++.

C++ has been in decline for years

Who cares? It's not dying. It's more an effect of the mass over-hyping of C++ in the 90's. When the crowd moved onto Java, the C++ scene gained...

vocal minority that insists language safety is undesirable

The tradeoffs involved make it undesirable. It's a fundamental architectual choice of the langauge, with undeniable performance implications. If you want safety above performance, go use another language.

I juge you: ass

Re:Strostrup is in denial

[EnglishTim]

I think you're missing the point.

There's still a need for a C++-like language - one without automatic garbage collection, raw memory access and the like. Sure, there's lots of other cool languages about now (C#, Java, Python) that are much better for many purposes, but there still is a need for C++, especially as there is still so much legacy code written in it.

Yes, lots of people will be moving from C++ to one of these more modern languages. This is a good thing, but there's no reason why C++ shouldn't evolve while still maintaining its C++-ness.

Just because C++ use is declining isn't a bad thing, and I don't see any sign that Stroustrup is denying its decline. I'd be interested to hear what kind of changes you think he could realistically make to the language to reverse the decline - it seems to me that you'd like something more like Java or C# - in which case why not just stick with Java or C#?

Re:Strostrup is in denial

[Anonymous Coward]

Automatic memory management, as in reference counted smart pointers, are in boost right now, and will be in the standard. The 'obscure template features' are actually used to create these things. There is lots of interest in language safety, and templates are used to create the means for this.

The main problem with C++ is that everybody thinks it's C and the 'class' keyword. templates and the STL seem too scary and too bloated. Well, they are not. Learn them. *Test* if they are bloat. Find out they are not. AFter that, learn C++ as it is meant to be. I know what I am saying here, as I had to do this myself.

Re:Strostrup is in denial

[Animats]

Automatic memory management, as in reference counted smart pointers, are in boost right now, and will be in the standard.

They've been in Boost for years. But you can't really do reference counted smart pointers safely in C++ without language changes. It's been tried many times. The basic issue revolves around the need to extract a raw pointer from a smart pointer to get anything done. The auto_ptr mess illustrates the problems. The auto_ptr spec has been changed three times, and it still isn't satisfactory. Various solutions have been proposed, but they either require language changes or don't work reliably.

Many of the safety problems in C++ could be fixed without performance penalties. But safety is a low priority of the C++ committee, and this is with Strostrup's consent. That's the problem. Every day, millions of people suffer from the unreliable software that results.

Re:Strostrup is in denial

[Doctor Faustus]

C++ is the only major language with extensive abstraction but without memory safety.

That would be because C and C++ are the only major systems programming languages. I honestly don't much like C++, but complaining it behaves like a systems language is missing the point of it.

C++ is losing market share to Java...And Strostrup denies this is a problem.
So do I. There *should* be a lot more programs written in Java, because most tasks don't require a systems language.

The problem with nice words...

[devphil]

...is that they're already in use.

Remember that, when the language syntax was designed, the idea was that every conforming C program would also be a conforming "C With Classes" program. Identifiers like "abstract" and "interface" were already in use as user variables, types, functions, etc.

I think you would be pretty pissed off if the next revision of your dawn-to-disk programming language suddenly made "foo" or "i" a reserved keyword. :-)

Time has passed and the two languages no longer fit together like that. Hell, they barely resemble each other anymore. But even ignoring C, now there are valid C++ programs which use "abstract" and "interface" as identifiers, so the problem remains.

Re:The problem with nice words...

[Deadbolt]

Remember that, when the language syntax was designed, the idea was that every conforming C program would also be a conforming "C With Classes" program. Identifiers like "abstract" and "interface" were already in use as user variables, types, functions, etc.

And we've been paying for that decision for 20 years.

Sometimes backward compatibility isn't worth the trouble. Is it worth being able to (almost) run a C program through a C++ compiler at the expense of giving keywords three or four distinct meanings?

Re:C++ Viability

[joss]

> forgive me if I take exception to some programmer hack calling himself a Scientist.

No, I won't forgive you, you pompous fuck. He didnt call himself a scientist, he said he had graduated with a degree in CS. That's what it's called and it has as much right to be called a science as rocket science, which is more obviously engineering than CS.

Why standards are updated

[dmeranda]

First, with ISO-quality standards, updates are made carefully and slowly to insure the least pain to all users relying on the standard. Backwards compatibility is usually the most important concern to the maintainers; there's no "willy nilly" changing going on. [Compare this to say Java, whose specs change much more quickly and perhaps more "willy" than C++]

There are many reasons to update standards periodically:

1. Most standards bodies (such as ISO) *require* that all standards be updated, or at least re-affirmed, on a periodic basis; usually once per decade. Otherwise they are considered abandonded and "revoked" from having its standard status. This helps weed out truely abandoned standards as well as insures that the standard is properly maintained and retains its usefulness.

2. As with most language standards, there are always many many small technical imperfections, or more commonly ambiguities, that need to be addressed or clarified. Most of these will never affect the "common" programmer, except perhaps those on the fringe (such as with embedded systems and so forth).

3. Practical experiences with a language often show shortcommings that, although may be technically minor, greatly detract from the language's usefulness in some cases. For instance when the C standard was last updated they made the numerical semantics much tighter (because they found out FORTRAN programmers could not adequately port programs to C without them). These changes would be hardly noticed by most programmers who don't do heavy and precise computation; but greatly welcomed by those who did.

4. Sometimes novel techniques or components are invented which prove to be very general solutions to widely-encountered problems, and which fit the "style" of the language very closely. Once these experimental components are deemed very mature and stable, adding them into the language proper can benifit all language users. For C++, many of these new extensions come out of the Boost project. But only the most mature and the most general-purpose extensions should be considered for standardization.

For a look at what's on the C++ issue lists, look at http://www.open-std.org/jtc1/sc22/wg21/

"Design and Evolution" mis-titled

[alispguru]

I prefer to think of that volume as "The Design Rationalization and Mutation of C++". An astounding amount of it is Stroustrup explaining why one feature or another would have been a good idea, but had to be shelved in favor of something simpler to implement, or requiring fewer keywords to change. It shows the extent to which C++'s design was political in addition to being technical (see Lambda the Ultimate Political Party for how this worked in the Lisp community).

It's a good, informative read, though not always a fun one - I still gnash my teeth every time I read about how they settled on termination semantics for exceptions.

Re:"Design and Evolution" mis-titled

[Gobelet]

"The Design Rationalization and Mutation of C++"

Actually he thought about it, but the title with the font they just bought wouldn't fit the cover.

Re:"Design and Evolution" mis-titled

[ckaminski]

No finally() clause, that gets me every time. I understand that C++ wants to foster stack-based object creation vs. heap allocation, but dammit, a finally clause would have eliminated SO much redundancy in my code over the years...

Re:"Design and Evolution" mis-titled

[alexo]

> a finally clause would have eliminated SO much redundancy in my code over the years...

Ever hear about destructors?

Re:"Design and Evolution" mis-titled

[ckaminski]

Ya, I understand the point Stroustroup was trying to make by excluding finally(). But that lack of logic leads to bastardizations like auto_ptr<>. If every dynamically allocated array or variable I create I either have to throw into a vector or an auto_ptr, when after each catch() clause is done, just before the stack frame is popd, you jmp over to this little finally clause...

I'm all for destructor based cleanup, I understand and love the concept (hence my love for exceptions), but come on. Resorting to templates to ensure protection from memory leaks? Today, I'd argue that finally isn't necessary since most C++ compilers have decent template support. 8 years ago, that wasn't so true.

Obviously I'm not the only person who thinks it's an oversight, when people are building closure templates and smart_ptrs to make up for a fundamental deficiency in the language.

I mean, this is great:

int a() {
try {
b bptr = new b();

} catch (Exception) {
report_error();
}
return(0);
}

Easily fixed by:

int b() {
try {
auto_ptr<b> bPtr(new b);
} catch (Exception) {
}
return(0);
}

I guess I don't have a point. 10 years ago, maybe I would. Today I don't... if only auto_ptr wasn't so brain-dead...

Re:"Design and Evolution" mis-titled

[angel'o'sphere]

You are completely right and Bjarne is unfortunately completely wrong. Especially when you see comments like "Bjarne is looking from the point of teachability at new features".

IMHO, C++ should be frozen and a new C++ like language should be created. All the "stange" stuff from C++ should be removed, and all the good ideas from C# and Java should be introduced!

Basically I want a Jave + true templates + multiple inheritance.
Or a safer/better C++ :D

If you can add some meta level programming capabilities and especially closures and probably the option to define my own keywords (as methods of meta classes e.g.) I would imediatly switch back from Java to C++

E.G. the VM should be a class which has a method for every bytecode .... and I can meta programm the VM by overwriting that class and their "byte codes" and registering "my VM" as execution engine below the actual VM. Of course, you would not do that by overwriting the VMs methods but by specializing the template method implementing that VM/bytecode ....

Bjarne biggest personal flaw is the same as the personal flaws of other great language designers:

a) when they crafted the language they made descissions based on certain forces, at that time the descission was probably right! Read "The Design and Evolution of C++", a lot of the "bullshit" you have now in C++ are completely logical descissions and made really a lot of sense at that time!

b) he still "feels the need" to defend those old descissions, instead of abandoning them and reconsider everyting in the new light of current research results and improved operation systems and processors.

c) Bjarne is a smart guy, and he has all right to be proud on his achievements! However, I wished he would get the idea that times has changed. A VM is not that bad, slightly modified behaviour in "synthesizing" by the compiler, probably template based (or meta programming based) incorporation of a GC would be ok now, especially more keywords would be good!

A language without true reflection and introspection, what a complete silly idea that is in our days ....

Back to my first point, as I was answering to a pretty good post ...

Consider you are a Java programmer and a you know the term finalization or finally ... if you "grep" the documentation of C++, do you think that auto_ptr shows up during grep as "C++" aequivalent to Java finally?

I dont think so ... C++ is a language that coined so hard its own jargon (like PERL) that the language is per definition '"non teachable".

"member function", what an idioticy must have driven Bjarne to call a "method or message or operation" a member function?

"Static" members, all Java programmers (when learning the language" look at me with big open eyes: static? What the heck means static? Why the heck did he call it "static", what a complete strange idea .... (Yes, I know, he really badly feared to introduce new keywords which might make his "better C" incompatible with existing C programms .... but its a unbelieveable that you need a "history course in computer languages" to be actually able to learn a modern our day language like Java or C#)

You can only learn C++ properly under a few circumstances:

a) you know how to code assembler
b) you knew how to code assembler and now code in C, as "portable assembler"
c) you have got a very RECENT very MODERN introduction into "how to teach C++ and the standard library"
d) you coded several 100.000 lines of C++ and learned from your own mistakes or from the very good articles in C++ Report or read the few good books about C++

For me C++ is "a dead language" and I encourage everyone learning programming right now to try OCaml, Java *and* Python.

Regards,
angel'o'sphere

P.S. I started programming C++ in 1989 and I coded about 1 million lines of C++ code myself

Re:"Design and Evolution" mis-titled

[ckaminski]

Not to disparage your comments, in hindsight we go WTF were they thinking.

But you HAVE to remember that the earliest C++ compilers were nothing more than preprocessors to the then extant C compilers, so C++ couldn't be radically different from it's predecessor. C++ wouldn't be so bad if it had truly been a new language, instead of C with OOP.

Re:"Design and Evolution" mis-titled

[angel'o'sphere]

Indeed!

And thats why I argue for a new C++ liek languge dropping the old stuff in favour for new concepts ...

angel'o'sphere

the D Programming Language

[WalterBright]

D is a refactoring of C++ to make it easier, more powerful, and more robust to use. -Walter

Re:The father of C++?

[not-my-real-name]

In this case, everyone knows who the father is. It's the mother that is unknown.

If only...

[JustNiz]

I haven't RTFA but I just hope that Stroustrup has come to his senses and got rid of the 'friend' keyword.

I've never seen 'friend' used other than as a bodge to hide the fact that the original design was botched.

After many years of software development, I've never found any use of 'friend' where the rest of the code isn't really hacky too, or any good developer that would consider using it.

Re:If only...

[MeerCat]

I've never seen 'friend' used other than as a bodge to hide the fact that the original design was botched.

I suggest you read Jiri's Soukup's book "Taming C++" for a very good use of friend - and the only decent use of patterns that I've every seen (spoiler: he has classes that implement a pattern by name but contain no data, and these are friends of the classes that comprise the pattern but in turn these classes are independent of each other and are mostly structs but with all private data memebers. This keeps the pattern explicitly in the code [patterns usually exist in the design docs but mysteriously evaporate away by the time the code gets written] and decouples the data classes from each other to make proper unit testing and re-use possible).

Don't knock something just 'cos you don't use it -I think exceptions are an abomination and an easy excuse for every weak programmer around, but I wouldn't deny their use to other projects.

Re:If only...

[Anonymous Brave Guy]

Don't knock something just 'cos you don't use it -I think exceptions are an abomination and an easy excuse for every weak programmer around, but I wouldn't deny their use to other projects.

Funnily enough, I was about to reply to the GP with exactly that example when I read to the end of your post. Exceptions are frequently used very poorly from a design perspective, and in C++ from an exception-safety perspective as well. That just means that most programmers suck, which we already knew. Nevertheless, exceptions used well by good designers and programmers can keep code much cleaner and more maintainable than it otherwise would be, and the safety comes almost without a second thought. Like any craftsman, a programmer has to know how to use his tools, or he's just another muppet with a bit of machinery in his hand.

Balance between ease of use and features

[Mingco]

The perfect balance of ease of use and richness of features for C++ is defined thusly:

If any novice is able to pick up Bjarne Stroustrups' The C++ Language and beat him within an inch of his life... but no more, then the book is perfectly balanced between ease of use and richness of features.

As it currently stands, I believe that every second or third novice would easily be able to beat Bjarne to a messy, bloody pulp almost as ugly as the code his language engenders.

packed decimal

[cdn-programmer]

So do we get a packed decimal datatype yet? WHat of Zoned decimal?

Re:Waiting for C++ 2007 lite ANSI standard

[Charles W Griswold]

Eh. Everyone should just switch to an interpreted, procedural language with objected-orientedness tacked on to the side, and which keeps promising to come out with a new, slick standard with more integrated OO features and which will break about 3/4 of the existing programs but which (so far) has completely failed to do so which means that existing programs are (so far) safe like, oh say, Perl.

[big, toothy grin]

Re:How about...

[CptNerd]

"...their "AOP" and other such stuff..."

And other TLAs. There should be a moratorium on any more acronyms being added to Java. No language should have more than two or three TLA or FLAs, at the most. When you have acronyms that are as long as the language you're acronyming, that's too much!

I mean, I've seen MILSPECs with fewer T/FLAs than Java has spawned! Hell, even the MILSPEC computer language doesn't have that many!

Member function pointers

[CreateWindowEx]

My big beef with C++ member function pointers is that there isn't a good way to pass a pointer to a member function of class A to someone who hasn't "heard" of class A without ugly workarounds.

I feel like the C++ member function pointers are nearly useless in their current form. If the language supported the concept of a bound member function pointer, it would enable a lot of the nice things you can do in ObjC, and fairly efficiently.

if you have something like:

struct Foo {
virtual void Bar(int);
};
Foo *my_foo;

and want to pass my_foo->Bar(), the compiler should be able to output pretty much the same code as when it would actually generate a member function call, e.g., adjust the "this" pointer if neccesary, lookup the actual function address in the vtab, and then just store those two pointers. Actually calling through this "fat pointer" might even be faster than a regular virtual function call--just put the "this" part of the pointer into the appropriate register and then jump-to-subroutine-register on the function pointer (you could even load the "this" pointer in the branch delay slot on MIPS architectures). This would be incredibly useful, the main problem is coming up with a nice syntax that fits into the rest of the language. How about this one:

void (.* member_fn_ptr)(int) = &my_foo->Bar;
(*member_fn_ptr)(17);

This has always seemed to me like such an obvious, useful, and unobtrusive extension to the language, that I'm curious if there is some good reason why this hasn't been considered--e.g., is there some nasty case where this would be hard or impossible to implement, or is considered to violate some aesthetic principle of the language, or are what seem to me to be ugly workarounds considered acceptable by most people (and thus extending the language to support it would be "redundant")?

Out of the loop for a while...

[krick-zero]

I've been developing in Java exclusively for the last 4 years and haven't been following C/C++ at all.
Can anyone tell me what the following quote is talking about regarding enumerations?...

"Also, some 'random extensions' will slip through the net and become 'odd and isolated' features in the language (much as enumerations are in C and C++)."

Re:Out of the loop for a while...

[Mingco]

By the way, if you have not looked seriously at C++ for a while, have another look. There are some excellent "new" goodies!

You forgot to "delete" goodies at the end of your post, thus enabling hackers to install spyware on my machine through your negligent memory management!

Thanks alot!

Re:How is that 5?

[Chris Burke]

No, he means it's whatever year it ends up actually being. 2005 was just an example, as was 06 which he also listed.

Needed...C0x Inhibitors

[SidAzad]

More Libs? What about ACE and RogueWave and the so many C++ Libraries out ther for multithreading, logging etc. How about a Jave like 'interfac' keyword as a part of the language?

You're seeming to forget something.

[Spy der Mann]

High level languages are built on top of other languages. After all, in which language are .NET or Java compilers written?

The good characteristic of C++ is that it's low level. It's the lowest-level language that is independent of hardware, except for plain C.

For this reason, C++ won't disappear. It will just evolve.

Of course, If C++ ends up being a compiler-only language (which is very probable), oh well. What can we do about it?

Re:You're seeming to forget something.

[Nasarius]

High level languages are built on top of other languages.

Maybe that's your definition. It's not the common one. C++ is high-level compared to C, as it allows for much greater abstraction.

For this reason, C++ won't disappear. It will just evolve.

I agree. C and Fortran will very likely stick around too, as they fill certain needs. Personally, I'm mildly surprised that there hasn't been more work on languages that compile to machine code. At the very least, it's an interesting project for CS students, and I don't think C++ is the pinnacle of what can be done in a compiled language. I believe GCJ can compile Java to machine code, but the mandatory garbage collector probably cripples it.

Re:You're seeming to forget something.

[Mornelithe]

Haskell is written in Haskell; Lisp is written in Lisp; ML is written in ML; Et cetera.

Those are all better languages for writing compilers than C++, as well as being higher level languages (in fact, they're all higher level than C++). C++ is not a great language for compiler writing.

Oh, and incidentally, the Java compiler from Sun is written in Java, but I imagine you meant the virtual machine (which is probably written in C). :)

Re:You're seeming to forget something.

[ClosedSource]

"Those are all better languages for writing compilers than C++, as well as being higher level languages (in fact, they're all higher level than C++). C++ is not a great language for compiler writing."

It depends on what "better" means. If execution time is not a factor choose whichever language makes the implementation job easier. In the real world compiler efficiency has a value > 0, so a trade-off must be made between easy and efficient.

Re:You're seeming to forget something.

[Mornelithe]

What makes you think these languages will be significantly slower than C++? There are benchmarks out there that put Ocaml code on equal or better footing than C++. And people have been working on optimizing compilers for Lisp for a very long time.

Any gap will likely shrink in the future, too, as more work gets put into optimizing compilers for the more modern functional languages. By contrast, it seems unlikely that C++ will catch up as far as the simplicity factor is concerned, so saying that C++ will always be around for compilers seems inaccurate to me.

Re:You're seeming to forget something.

[Mornelithe]

All optimizations that can apply to higher level programming languages can apply to C++ too.

Can it? There are no techniques that optimize things in functional languages that C++ doesn't even deal with (lazy evaluation and garbage collection for example)? In addition, since, as you say, much more money and time has been put into optimizing C++, there may be optimizations that are in C++ that haven't been worked on for functional languages yet.

As for lisp/scheme they are a different paradigm... functional programming is inherently incomparable to a procedural language like C++.

You can write imperative code in scheme and lisp. They both have assignment, loops, and the ability to sequentially execute expressions.

I'm not sure what that was in relation to, though. All the languages I mentioned are primarily functional (although many people would argue that Common Lisp is a multi-paradigm language, like C++). Only Haskell is purely functional (since you can't do any imperative programming).

Re:You're seeming to forget something.

[ClosedSource]

I'd have to see the benchmarks. I'm not saying that C++ is the fastest language available, but I really don't think there's much debate that it's one of the fastest.

People have been talking for years about languages with virtual machines having the potential to outperform traditional languages, but so far, it's just been talk. For example, after 10 years of intensive Java development, C++ still outperforms it.

It's far too late

[pammon]

"If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?" -Tom Cargill

The largest problem with C++ is its complexity. It is not just too complicated, it is *unmanageably complicated.* Some of the symptoms are:

• The STL has inexplicable omissions. For example, there's no portable way to seed the built-in PRNG in the random_shuffle algorithm, rendering it useless.
• Guruhood isn't good enough. Consider the seemingly simple task of creating a stack that works correctly with exceptions. It's extraordinarily difficult even for a guru.
• Language features interact in nonintuitive ways, producing a combinatorial explosion. For example, if you overload a function in a class, you don't have to use the scope resolution operator, and if you override a function, you don't have to use it either - but if you do both, you DO have to use the scope resolution operator or else you get a compile error!

Insofar as the new C++ standard adds stuff, instead of simplifying, this will only get worse. Since it's unreasonable to expect a new standard to remove features, the problem is unfixable. The result will be that programmers carve out their separate comfort zones, compiler vendors will not implement all features, and the monolithic C++ language will fragment into a Venn diagram of sublanguages. More so than today.

Re:It's far too late

[Mornelithe]

A few weeks back, I recall reading a thread on comp.lang.functional that had lots of argument about C++ (I think the thread is disguised by being called "Generic Programming and Functional Languages," if you care to look it up, though I could be wrong about it being that one; the C++ debate is buried several levels down in the thread). Naturally, the functional guys don't like C++ too much for many different reasons. However, there was an actual C++ language designer (I guess he's on the committee or something) there debating with them, so it turned into a nice flamewar. :)

In short, the C++ guy argued that it was a pretty good language given all the constraints Bjarne had, including C compatibility and so on. Of course, the functional guys argued that no matter what the circumstances, that didn't make C++ an actual good language (and I agree). The history might explain why C++ is bad, but that's not an acceptable reason to use a bad language.

Now, the C++ guy seemed enamored with the idea that he could eventually "fix" C++ into a good language. However, one constraint he had was that it had to be compatible with C++ as it exists now. In other words, you're unlikely to ever see features removed from C++ to make it better; the only option is adding to it.

The people on the newsgroup argued (and I quite agree with them), that no matter how much you add to C++, it's not going to become "good." In fact, as you mentioned, one of its problems is that it has too much stuff already. Anything that "fixes" C++ isn't going to be C++ anymore, because it's going to have to get rid of a lot of stuff that's there. And at that point, why not model your new language off of one of the ones that is already far better than C++?

In short, I agree. :)

The article looks like a promotional prop...

[iskander]

and Bjarne sounds as if he were rehearsing his pitch on the eve of a product launch. As if C++ needed to be re-launched! I wonder whether he does this because he fears people's reaction to the new standard. In any case, it seems he hopes to preempt a good deal of criticism by manipulating our view of the standard's gestation ahead of the release. We've seen this kind of thing before, haven't we?

Technique Before the launch, persuade clients to believe that the product's development was/is governed by core values they already hold. Result After the launch, clients are less likely to look at the product critically and dispassionately because they are already satisfied that it respects their core values.

But maybe that's what a language creator ends up having to do if he wants changes to be widely accepted and (more importantly) adopted so that the language does not become stale. Yes, "the end justifies the means" and all that jazz. That might account for the delay in the delivery of Perl 6 and the endless series of Exegeses and Apocalypses and Ecclesiastes and whatnot.

What I don't fully understand, then, is why Bjarne spoils an otherwise excellent pamphlet by indulging in the pointless denunciation of enumerations as an "odd and isolated feature" born of or comparable to (it's not clear from the phrasing) a "random extension" that was included in the standard due to operational deficiencies in the standards process. Is this flamebait, tossed our way to draw attention to his article and to the standards process? Certainly, he isn't trying to discredit the process by acknowledging the inevitability of incorporating "random extensions" that would later become "odd and isolated" features, is he?

Agreed, but you need to broaden your field

[alispguru]

... but if you know c++, perl, php, java and a few others, your toolbox will contain an appropriate solution for a broad range of problems.

The list of languages above is a good start, but is actually pretty narrow - they're all mostly imperative and Algol-like. For real breadth, you should break out into one or more of:

Common Lisp, Scheme

Haskell, ML, ocaml

Smalltalk, ruby

Prolog

Re:Agreed, but you need to broaden your field

[pilkul]

He was talking about real programming languages to solve real problems, you listed obscure research languages with no practical use whatsoever (with the exception of Ruby). A more important addition to his list would be SQL, for relational, data-oriented programming.

I too was once a Lisp fan but I stopped advocating it for serious programming a long time ago. The reason the languages you listed are bad has more to do with the absence of good standard and third-party libraries and development tools as well as absence of target use (e.g. PHP = web programming, C++ = systems/speed programming, but Haskell = ???) than any issues with language semantics, which is not very important in real life.

Re:Agreed, but you need to broaden your field

[alispguru]

...issues with language semantics, which is not very important in real life.

Erlang fans would disagree with you. Ericsson uses it a lot to implement their internal telecom switch control programs. Its pure functional semantics allows it to run tens of thousands of threads without requiring locking - equivalent Java or C++ would collapse under that kind of concurrency load.

Agreed on SQL.

Multiple return values

[AuMatar]

THe one thing I've wanted forever is for it to allow multipel returns from one function. The idea of a function returning one variable comes from math. It doesn't really port well to CS. In CS, its frequently useful to get 2,3, or more pieces of data back. This forces us to one of several hacks- either return a class with all the fields, use input/output variables, or for error returns use an exception.

Something similar to the following is what I envision:

int,int foo();
int a,b;

a,b=foo();

Foo would *always* return 2 variables, and the type would always be known, so we don't lose type safety. But we would gain the ability to read 2 pieces of data.

Re:Multiple return values

[renej_frog]

using boost::tuple you can do: boost::tuple foo(); int a, b; boost::tie(a, b) = foo(); pretty close huh? renej

Re:Multiple return values

[AuMatar]

Yes, but why kludge a solution in, when it would be much more elegant (and likely less buggy) as a language feature? And using a map (or a tuple as the other poster suggested) requires allocating and initializing variables, and deallocating and deinitializing them on end of use. A lot of overhead (especially on a map/list, less on a tuple). I'd prefer to see it built in and go with a very low overhead solution, probably just writing them to the stack (or registers) and then reading them out rather than involving objects at all.

Re:Multiple return values

[djs55]

I totally agree with the need to return more interesting values from functions. In O'Caml I just write

let a, b = foo ()

as you suggest.

However, one minor niggle:
The idea of a function returning one item comes from math. However in math these items can be anything; a single int (member of Z), a pair of ints (member of Z x Z), a huge complicated structure describing the state of an interpreter or whatever. Maths doesn't restrict functions to only return one single integer, or float or whatever. It just so happens that many common functions are defined that way, it's not true of functions in general. So the restriction comes from C/C++ and not math.

Re:Multiple return values

[EvanED]

...when it would be much more elegant (and likely less buggy) as a language feature?

Changing the language is more difficult than adding a library because the compiler must be modified, which is a daunting task.

The trick is to find a way to do it safely without any (or with very little) extra overhead. I'm trying to come up with an idea, but I don't have anything yet. If I think of something, I'll reply again. However, I'm reasonably confidant that there's a way to do it with no extra overhead (at least with any moderately decent optimizing compiler), I can feel it, I just don't know how yet.

Re:Multiple return values

[AuMatar]

True. But they are updating the language, so this would be a cool feature to put in at the same time :) It would also probably have better semantics that way.

Re:Multiple return values

[julesh]

And using a map (or a tuple as the other poster suggested) requires allocating and initializing variables, and deallocating and deinitializing them on end of use. A lot of overhead (especially on a map/list, less on a tuple). I'd prefer to see it built in and go with a very low overhead solution, probably just writing them to the stack (or registers) and then reading them out rather than involving objects at all.

When you return a statically allocated tuple, it is stored on the stack. No allocation overhead, no nothing. Tuple constructor call gets inlined. It's as efficient as you could hope for, as long as the compiler's got a good optimizer.

Re:Multiple return values

[EvanED]

On the other hand, if they put every cool feature in the language, it'd be huge. There has to be a very compelling reason for a language change, simply because of the burden it places on compiler writers. Just because they are making a revision to the standard doesn't mean that the language will face huge changes; by contrast, probably the changes will be relatively small.

This is a lot simpler than what might arise in practice, but the following code when compiled with gcc and -O2 on Solaris seems to produce about as optimal code as I think you could hope for in a high-level language in which the call to foo wasn't inlined:

struct Pair
{
public:
int a_, b_;
Pair(int a, int b) : a_(a), b_(b) {}
};

struct Tie
{
public:
int& a_;
int& b_;

Tie(int& a, int& b) : a_(a), b_(b) {}

void operator = (const Pair& rhs)
{
a_ = rhs.a_;
b_ = rhs.b_;
}

};

Pair foo()
{
int a = 0, b=3;
return Pair(a,b);
}

int main()
{
int x, y;
Tie(x,y) = foo();
std::cout << x << " " << y;
}

Keep in mind that everything above foo() would sit in a header file somewhere, so you wouldn't have to worry about it.

Granted, the syntax could possibly be made nicer, perhaps by doing something like using a notation for a pair, but you have to ask if the increased "prettyness" of the source really justifies that.

I'm not so much trying to say that the addition is a bad idea, or not cool, or wouldn't lead to better code; I'm just trying to show why there's little chance it would happen.

I see wxWidgets as a standard library

[Nicolay77]

I write this as it is my personal experience:

I first learned Java and then C++.

Shortly after learning C++ I learned wxWidgets (it was named wxWindows then). To make a long history short, I only missed serialization from Java, almost everything else felt better in C++/wx than in Java, especially GUI stuff.

And one of the reasons for it is that wx doesn't use C++ templates at all. No bloated code. It's even simpler to use than Java.

Well the other thing that I miss from Java is JDBC. wxODBC is just ugly (looks like MFC code).

Re:I see wxWidgets as a standard library

[ckaminski]

Try OTL. It's Streams based ODBC/OCI.

wxWidgets

[Nicolay77]

I said it once... and say it again.

Why copy a bad API when there are better alternatives?

wxWidgets is to C++ like gas is to cars.

Re:wxWidgets

[EvanED]

You're saying "Why copy a bad API" and suggesting one that is quite similar to MFC?!

If wxWidgets is like gas, then it's a high-sulfur diesel.

Re:wxWidgets

[Tim Browse]

I keep looking at wxWidgets every now and again, but I can never shake off the feeling that I will just be annoyed by it.

This is quite possibly because I've been writing my own abstracted GUI library over the past few years - as both a learning exercise and to produce a useful library, so I admit that I'm biased.

To take an example - for UI/GDI stuff, MFC is just a very thin wrapper over most Win32 objects/calls. It basically takes care of object destruction and has a few (crap) convenience functions, but that's it.

One of my pet hates is that the standard listbox control works differently to the 'new' listview control (introduced in Win95). Again, in MFC, the APIs are different. Another pet hate is that to clear a listbox of all items, clear a listview of all items, or clear a combobox list of all items is like 3 different calls, ClearContents(), DeleteAll(), or whatever.

In my own GUI library, you instantiate the same listbox class and attach it to the control in a dialog, and it automagically handles the rest. You use the same API to manage the two types of list control - this is as it should be, imho.

When I checked wxWindows a while back, it failed to even manage this for unifying the API of two basically similar objects. They just copied the Win32 function names. This kind of thing doesn't inspire confidence that the higher level stuff isn't of a similar quality.

Another pain about list controls in Windows is that for one of them (forget which - I have a library to do all this shit for me now), it's non-trivial to find which is the selected item in the list (or some similar operation that should be easy). By non-trivial, I mean it's more than one function call. Again, my library abstracts away stuff like that, but I checked wxWindows and it was still just copying the Win32 interface, even for something as obviously broken as that. I think there was even a note in the comments as to how dumb this was.

I guess my point is: if the list control class in a GUI library isn't even nice to use, I don't want to know about the rest of it.

Re:wxWidgets

[wxprojects]

> Another pain about list controls in Windows is
> that for one of them (forget which - I have a
> library to do all this shit for me now), it's
> non-trivial to find which is the selected item
> in the list (or some similar operation that
> should be easy). By non-trivial, I mean it's
> more than one function call. Again, my library
> abstracts away stuff like that, but I checked
> wxWindows and it was still just copying the
> Win32 interface, even for something as
> obviously broken as that. I think there was
> even a note in the comments as to how dumb this
> was.

I'm not sure what you're problem is - you can do pretty much anything you mentioned in one function call in wxWidgets - in this case wxListView::GetFirstSelected

Re:The future of C++...

[Mornelithe]

The vast majority of "modern" languages are not compiled to machine code.

No, the vast majority of modern mainstream languages aren't compiled to machine code. Haskell, ML, Ocaml, Lisp, Mercury, etc. all compile to machine code.

For the moment, C++ is a good balance between the efficiency of C and the user-friendliness of higher-level languages.

That may be true if you equate "higher-level languages" with "Java, C#, Perl and Python," but that's not even close to the full spectrum.

It fills a niche (resource-gobbling 3D games, operating systems, compatibility with C/C++ libraries, etc) that no other language does.

Almost any language can interface with C libraries, because they're the de facto standard.

Do you know of C++ being used in the kernels of any mainstream operating systems (or even many non-mainstream ones)? C is still king here, as far as I know, because when people write operating systems, they want to be as close to the metal as possible, and don't want all the abstraction that C++ provides.

Please explain why you couldn't write 3D games in, say, Ocaml.

But you won't have to distribute the runtime

[Urusai]

...because Microsoft will put it everywhere for you! Think DirectX...OK, bad example.

S++

[s0n]

As C++ programmer I always wanted to have a language that supported symbolism. I understand why Bjarne wants to call it C++0x but without some AI it whould be hard todo, if you get the point. Putting todo in a library is indeed the catch. To reuse or not to reuse... S++ ?

Three words for you:

[Marc2k]

ngen dot exe

All .NET code is interpreted by the Common Language Runtime Just-in-time compiler, and ngen can compile all necessary code to native binary. AFAIK, you'll still need the CLR on-site, since it doesn't package system libraries...yeah, it can be done.

Re:Three words for you:

[nonsequitor]

My experience with C# involved managed wrappers for Native code, Marshalling sucks by the way, and working with Visual Studio .NET trying to make C# play nice with Native C and C++ code with interprocess communication running involved weeks of headache. Also, do you have to write code as if there was no garbage collector or will those 3 magic words automagically decide when to delete objects?

The point I'm trying to make is that even though there are various hacks, maybe kludge is a better word, to get it working, unless you have complete control of all the libraries you compile against, including licensed code, its not feasible in most real world scenarios. Every time I've seen C# used for a task that C++ is better suited for, it takes weeks to sort out all the related issues, which never seem to stop going away over the lifetime of the product. Which is why IMHO there will always be a place for C++.

Does C++ has a big future?

[carmello]

More and more application will be writen in Java, on sourceforge the number of Java projects is just behind C++, just a few hundred. There are a lot of Java enabled cell phones, the game market for Java is currently not realy big but is growing and will grow more in the future when more tools come availible for Java game development.

There are a lot of other areas were Java shows up, realtime software, at NASA for ground-site control but in the future (2009) also on the mars rover. Or the unmanned aircraft (scaneagle) of boeing, parking tickets systems, in the Formula One, the Automotive Industry and healthcare.

It is just getting hard to find an industry (that uses software) where Java is not in.

There is still lot of code written in C++ but I think it will be hard to stay popular and most used computer language, but we will see that within the next 5 to ten years.

Re:Does C++ has a big future?

[Anonymous Brave Guy]

More and more application will be writen in Java

So I've been told, for much of the last decade in fact. And yet Java hasn't somehow wiped out C++. Nor did VB, and nor will C#. As I've noted before, there are many ways you could make a language very much better than C++ if you're starting from a clean slate with 20 extra years of experience from C++ and other languages to build on. I'm really quite surprised that no-one has yet developed a killer application development language taking the stronger aspects of C++ and other languages, and reduced all of the above to nothing more than legacy support jobs.

But so far, they haven't. In fact, depending on who you talk to, Java is now on a serious downhill slide; even universities are starting to see that it's not all it's cracked up to be and switching back to teaching C or C++ as their primary example language for CS courses. C++ has stood up to the marketing machines of Sun and Microsoft, and competed on merit, and it's still around. I'd say that's a pretty good indicator about its future.

Re:Does C++ has a big future?

[Anonymous Brave Guy]

I'm not sure who you're talking to, but everywhere I go, I see Java on the up and up.

I'm talking to people who work on scientific applications, instrument control applications, games, and system software, for a start. Every one of those is a huge development area, perhaps not quite as big as "business apps" (i.e., databases), but certainly on a comparable scale. Java's chance of penetrating any of these areas significantly is approximately not very much at all. It just isn't cut out for the performance and/or low-level control that is routinely used in this sort of application.

By all means, let Java's use for developing business apps grow; that is where it seems to work well, and a domain probably better suited to Java than to C++. Similarly, for undemanding (in performance and control terms) desktop apps, or the equivalents on mobile phones and such, Java should be right at home. Perhaps the same is true of some embedded systems as well, though I suspect many of those will run into similar limitations to the external instrument control world and decide to stick with C or C++ anyway. But really, this is a different world to the one in which C and C++ live. They were only king of the other spaces by proxy before, because no-one else stepped up and said they'd do it.

d++

[grikdog]

Any "rough corners" shaved off had better leave a syntax that resembles the subset most people bother to learn. It's always fun to watch obvious code change from plain and sincere to incomprehensible because some genius decided to wrap the grammar in an "obviously useful" abstraction layer. Whenever this happens, I thank gad (aka Bill Goats) for giant corporations who think of customers before lighting up in their ivory towers.

C++ sucks.

[master_p]

I used to think C++ was the best general purpose programming language, until I met LISP. At first, I had difficulties understanding it, but after playing with LISP, I realized how much more powerful than C++ is.

I suggest everyone to read the material at lambda-the-ultimate. You will be surprised on how little you know on programming languages...it was a real eye opener for me.

Re:Just use perl

[MeerCat]

This must be a troll.

Yeah it must.

Perl has an atrocious OO implementation.

Perl has multiple OO options ranging from "none whatsover" to "just a bit" to a whole lot more... which one were you talking about, or were you confusing a wealth of options with a single narrow minded single purpose.

No one is gonna code something in an interpreted language for what they would use a compiled language for.

No one ? Well as a pracitcing C++ person since 1990, I tend to use perl... sometimes... when it's appropriate (which is rather often, thank you).
Bang goes that argument.

You're full of it!

Hmmmm ... cough ...

Note I don't tell you what you will and won't do, please return the favour and don't try and tell the world what I will or won't do.

What a crock of shit

[Trejkaz]

Java doesn't force you to use OO design and type introspection any more than C forces you to use a procedural design.

Re:Just use perl

[AuMatar]

Well, some of us like maintaining our apps.

Besides, people complain about loser programmers with C++, wait til we give them perl and allow them to override $[.

Whoa!

[James A. D. Joyce]

C++ has real-world applications now?

Re:Whoa!

[James_Aguilar]

Anything that is worth doing is done better in C++. =)

Re:The future of C++...

[Nasarius]

Haskell, ML, Ocaml, Lisp

I apologize. I should have said "invented recently" rather than "modern".

Please explain why you couldn't write 3D games in, say, Ocaml.

Functional languages are neat, but most programmers are more comfortable designing a large system in an imperative, object-oriented language. Functional idioms can be rather unintuitive, even to those with decent CS educations.

Re:The future of C++...

[Mornelithe]

Functional languages are neat, but most programmers are more comfortable designing a large system in an imperative, object-oriented language. Functional idioms can be rather unintuitive, even to those with decent CS educations.

Perhaps, but I think that's largely a problem of education rather than some intrinsic difficulty that functional languages possess. Most programmers are trained to use imperative, object-oriented languages from the get go, so switching to functional languages is a significant shift from everything they've learned before. However, I don't see why functional programming would be significantly more difficult if people learned it from the start.

In essence, such an argument reduces to something like, "everyone knows C++ now, so it's easier to keep using C++ like languages, so everyone will continue to know C++, ...." I don't find that sort of argument a compelling reason why people should continue using C++.

Ocaml does have an object system, and you can write imperative code in it, so you could likely even write code that's rather similar to C++ in it, too, although that would not be the best way to solve most problems with it.

But standardised *frameworks* are useful

[Anonymous Brave Guy]

Thank you for a thoughtful reply.

To an extent, I agree with your position: I don't favour all-encompassing libraries a la Java, and I do prefer somewhat centralised but community-driven framework's like Perl's CPAN or TeX's CTAN.

However, I think a certain amount of pragmatism is useful. To pick on the GUI library as an example, it's certainly true that many C++ programmers write GUI code, though many more do not. If you do, then whether you're using MFC or wxWidgets or Qt or Yet Another Clone Windowing Library, the basic concepts are very much the same.

In light of this, I believe that a standard library should provide a simplified framework of basic functionality in this sort of case, upon which more powerful non-standard extensions can build if they wish. There will always be platform-specific libraries, not least because not all platforms have the same capabilities, but the needless duplication of effort between all of the libraries I mentioned just above is an impediment to portability without benefit. Why not commoditise the common ground, and leave the specialist library guys to focus on the more powerful stuff in their respective fields, without that unnecessary duplication of effort, and without creating artificial barriers to portability?

For bonus points, this also provides useful basic features for the many applications that only use a simple GUI anyway. In addition, you reduce the learning curve for both the langauge and any libraries building on the standard framework, and make it easier to teach the language to beginners.

You can make much the same argument for many other fields, where a very large number of programmers do essentially the same basic thing, with different bells and whistles on top. C++ excels in providing tools for flexible, extensible, customisable code in libraries: classes, templates, overloading, RTTI, exceptions, and more. Of all the mainstream programming languages in use today, I think C++ is perhaps the most suitable to this framework-based approach. Over a million programmers are going to wind up using MFC or Qt or wxWidgets or whatever anyway, so it seems overly pedantic to restrict the scope of a standard library because a GUI component couldn't be used everywhere. After all, taken to the logical conclusion on that basis, you're not allowed any sort of file access, either, but I can't imagine any language hitting 3 million users if you had to download additional libraries just to open a file!

Man pages for C++

[heroine]

It's about time there were man pages for C++ the way there are for C.

Re:Dump C++, this would be a lot better...

[BCooley]

Well, C++ does import C and C++ header files, but I don't think it addresses any other of these issues. Can I: o Change the binary representation of a string literal to something other than string-z? o Create a Container class which is implemented as a list, an array, or merely a sequence of statements depending on how it's actually used? o Control the way exceptions, inheritance, object construction/deletion, or memory management is implemented. o Completely ignore the differences between functionally identical data types with different implementations? o Write a memory management library that would automatically generate the propert "delete" statements for every "new" in a single threaded application. o Write "printf" like function which would check the syntax of its own format parameters at compile time. I don't think C++ can do any of this at the present. I really want a language which will allow me as a library designer to use the best implementation strategy for what the user is trying to do. That requires that I be able to analyze the user's code and even its runtime characteristics, and generate the most efficient implementation of any class with the least overhead. This requires that classes and methods be abstractions, not actual concrete representations as in C++/C#/or Java, that can be replaced by a variety of different concrete implementations at compile time.

Language Wars

[NullProg]

I'm no C++ guru (I know enough to make mistakes), but I do know that the language gives as much or as little control as the programmer desires. Just like C and assembler.

After reading the posts in this thread, I can only derive that the most of the Python/Java/Perl/C#/PHP/Ruby crowd have no idea how thier interpreter of choice is built. All are built using C/C++ or a combination of both.

It's really disturbing that most of these programmers have no idea on how thier interpreter of choice interacts with the processor or the OS its running on.

It's downright stupid that most of the interpretive programmers blame the security issues on C/C++ and not the program vendor for shoddy code.

No flamewar intended. Food for thought.
Enjoy.

C++ doesn't suck

[Anonymous Brave Guy]

Congratulations, you've taken another step in the journey of learning to program. However, your conclusion is a little premature.

Some of us took that step a long time ago, lured in by the power and flexibility of functional programming languages, and the elegant simplicity of LISP in particular. And many of us came back, giving a polite nod to those languages, understanding some programming concepts a little more deeply than we used to, even wishing we could bring some of the neater stuff with us, and yet still returning to tools like C++ or Perl or Java for our serious work.

Why did we do this? The theoretical power of functional languages is undeniable, and for sure many of the current mainstream languages could learn more than a trick or two from them, but they tend to sacrifice practicality for purity. Lazy evaluation and side effects make ill bed-fellows, for example. In my universe, we frequently use side effects for I/O, and we do not consider monad-based techniques, however clever and theoretically pure, to be an adequate substitute when we're writing more than toy examples. Similarly, while LISP macros are awesomely powerful, for most jobs some well-thought-out and standardised syntactic sugar will offer more benefit.

It's perfectly possible to gain many of the advantages of functional languages in more mainstream alternatives, simply by adapting your programming practices: write in a more declarative style with liberal use of const, for example. However, at least in C++, you have a choice. In a strict functional language, you don't, and that's a deal-breaker for most programming jobs.

Re:C++ doesn't suck

[master_p]

I don't disagree with what you are saying, but LISP is not only a functional language, as C++ is not only an object-oriented language. In fact, I got the most out of LISP due to 3 things: a) it's uniform syntax (which after a while makes you super-productive), b) it's imperative features, c) its macros.

The STL is OK, but not all that

[Anonymous Brave Guy]

The STL is real. It works. It rocks. Compilers get better at making it incredibly fast all the time.

OK, I'm a bit of a C++ fan (I like practical tools), but let's keep this in perspective.

The containers/iterators/algorithms parts of the C++ standard library are real.

They mostly work, aside from the glaring omissions (hash tables? circular lists?) and design blunders (vector<bool>? basic_string?).

They don't really rock. The containers are handicapped by the absence of corresponding literals, which even the practical monstrosity that is Perl can do. Many of the algorithms are crippled by the lack of first-order functions and the like, and look like a strange attempt at humour to anyone familiar with functional programming languages. Numerous articles have been written by clever people about how to get these C++ features to almost do something using a page of code that other languages can do in one line described in the first chapter of the book.

And the performance is OK, but since compilers still have to accept underlying aliasing concerns and the like, it's still somewhat held back compared to a more robust type system that didn't allow for things like pointer arithmetic.

C++ tutorials/references?

[Sarcastic Assassin]

I know this is a bit off-topic, but I have always wanted to learn C++. I already know a tiny bit (real basic stuff, like "cin/cout", function declaring, and I've just scratched the surface of classes). Does anyone have any good C++ book tutorials/references?

Re:C++ tutorials/references?

[Anonymous Brave Guy]

You could try Eckel's Thinking in C++, which is available for free in electronic format via his web site.

I've never seen any good C++ code

[slickwillie]

It's either Plain Old C, or so full of hacks and obfuscation that it was unreadable (or at least unfollowable). I mean, when you see 'friend' everywhere, that can't be a good sign.

But wait, there's more

[slickwillie]

I learned C++ when the first affordable compilers became available for the PC, about 15 years ago. I even wrote a multitasking kernel using C++. Then I didn't use it for a long time. When I returned, it seemed Java had been developed and B.S. apparently revamped C++ to look more like Java.

Re:But wait, there's more

[Anonymous Brave Guy]

When I returned, it seemed Java had been developed and B.S. apparently revamped C++ to look more like Java.

OK, now I know you're trolling. True, one of C++ and Java has been changing, in very significant ways, to look more like the other, but you've got them the wrong way around. "We don't need templates!" cried the Java evangelists, yet now Java 1.5 introduces generics. Ditto for enumerations, and much more. C++ got these things at least somewhat right the first time, and Java (and C#/.Net) are only just catching up. We ought to be 20 years further on by now, with C++'s efforts consigned to the history books as a stepping stone to something much better, yet they're only just now being half-heartedly emulated!

As for your original comment that you've never seen any good C++ code, well, if you think using friend is a common thing then you obviously haven't seen very much C++ code at all. The language has changed a lot in the past 15 years, and you still seem to view it as it was then, ignoring all the developments in both language features and effective usage idioms that have come about since.

Re:C++'s achilles heel

[andalay]

Obviously you havent read anything about C++.

The mantra is "Don't pay for what you don't use" If you dont use virtual functions, you shouldnt pay for a pointer to a vtable. Simple.

Real world applications

[pavonic]

C++ is died? Hmmm..., have you ever asked yourself which language Adobe, Microsoft, Macromedia, Mozilla, KDE, Opera (and many others) use to develop their flagship applications?

Re:Garbage

[nagora]

How odd. A straight-forward question marked as a troll and flamebait!

Someone told me that some C++ compilers or extensions added garbage collection, I was wondering if it had ever been added to the language definition.

Apparently, the C++ programmers here think that's a rude question, so I suppose the answer is "no".

TWW

Re: Intelligent Discussion

[some guy I know]

If you read the rest oof the thread, you'll see that almost the whole thing is full of deep, intelligent and well-reasoned arguments on both sides of the GC in a language issue and so on.

But you're missing the deepest, most intelligent, and mostest well-reasoned argument of all: whether it's pronounced "STROO-strup" or "STROW-strup".

(Yes, I know, that's not a particularly funny joke, but at least it's not Bjarne-yard humor.)

Re:What we need is "Smoothed out" people. (WAY OT)

[ckaminski]

I do believe that it is impossible for recently designed automatic transmissions to be ripped to pieces by an engine. I've placed my car in drive to park on occasion (accidently) and it still works. The fact that there is no direct connect to the engine, and that the transmission works under hydrostatic pressure insulates it from a similar fate on a manual transmission of say, going from 5th gear to reverse (assuming the lockout broke).

And just about every recent automatic will cut off the engine once it red-lines. My plymouth voyager did, and my Mercury Sable do.

Re:C++ Viability

[julesh]

I know most game programming is still done in c++, but if the universities have moved on, the industry won't be far behind.

I think the universities have jumped the gun on this one. Yes, they've just about all moved to a java-centric syllabus. Mine only teaches Java and a functional language now -- not sure which one -- I was in the last year that was taught Pascal, C, Miranda, a bastardised version of Pascal with concurrent programming structures hacked in and C++: it's just Java and a functional language these days. I can understand why, too -- that was a lot of languages to teach people over 3 years. But, I learned important things:

* I learned how to learn languages quickly
* I learned a wide variety of different language styles
* I learned to use the best tool for the job (witness my final year project, which included a programming language interpreter written in C/flex/bison, with a GUI written in Java)
* I learned that low level programming is hard, but that when you work it out it is manageable

Current students are coming out with CS degrees and no idea how explicitly managed memory should work. That's just wrong: memory management is an important CS subject, if only because *somebody* has to write the memory managers.

Re:C++ Viability

[julesh]

It's getting hard to get that kind of degree today. I'd argue that language exposure isn't what makes CS CS though: it's learning the mathematical underpinnings that separates CS from Software Engineering courses. Complexity analysis, discrete maths, logic, semantics -- these are the courses that distinguish CS from other subjects.

Why would D need to "go anywhere"?

[Rogerborg]

It's complete enough to use for major projects right now. What more do you want?

Re:The future of C++...

[sploxx]

The functional style simply does not fit every problem. If you want to print text onto the screen, the most obvious way is to do a

print 'device' 'text'

and not a

print 'world' 'text' : returns 'new-world-where-the-screen-has-the-next-line-of-t ext-printed-onto-it'

After all, computers are executing code and somewhere you do have to start, your haskell
session starts by imperatively invoking your haskell interpreter/compiler/program!

Re:My point IS.......

[crucini]

I understand most of your wishlist. But how do you survive without copy constructors? Do we always default to bitcopy? What if there are pointers in the object?

Re:Waiting for C++ 2007 lite ANSI standard

[crucini]

My particular issue with C++ is that which BS seems to be warning against -
unlike him I already think there's far too much in the C++ language that
should properly have gone into the standard library.

For example?