/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."
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?
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...
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.
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.
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 [nhplace.com] 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.
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.
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.
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.
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.
"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.
"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).
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".
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:)
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.
"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.
by Anonymous Coward
on Monday July 11 2005, @09:21AM (#13032602)
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?
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.
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
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 [gnustep.org]+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.
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?;-)
... 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!
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...
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.
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.
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!
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.
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.
> 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.
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.
by Anonymous Coward
on Monday July 11 2005, @10:29AM (#13033245)
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.
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 this [codeproject.com]article.
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.
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 [boost.org] and the Modern C++ Design [moderncppdesign.com] book.
For example, I've been using a combination of boost::function [boost.org] and boost::bind [boost.org] 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 [boost.org]).
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 [boost.org], 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!
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"
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.
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 [evansdata.com] 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.
"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 [www.gotw.ca] 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.
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.
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.
..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.
wait a moment... (Score:5, Funny)
Re:wait a moment... (Score:5, Funny)
Not when it's God talking.
Parent
Re:wait a moment... (Score:4, Insightful)
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...
Parent
Re:wait a moment... (Score:4, Funny)
I don't know... don't most people prefer to emphasize their accomplishments and hide their failures?
Parent
Blasphemy? (Score:5, Funny)
Now, what an academic is doing having a successful programming language with real-world applications is another question...
Parent
Dynamics in programming languages (Score:5, Insightful)
Re:Dynamics in programming languages (Score:5, Informative)
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.
Parent
"Design and Evolution" mis-titled (Score:5, Interesting)
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.
Parent
a 'few' rough edges (Score:4, Insightful)
Re:a 'few' rough edges (Score:5, Informative)
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.
Parent
Re:a 'few' rough edges (Score:4, Insightful)
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.
Parent
Re:a 'few' rough edges (Score:5, Insightful)
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 )
Parent
Re:a 'few' rough edges (Score:5, Interesting)
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.
Parent
Re:a 'few' rough edges (Score:4, Insightful)
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.
Parent
Re:a 'few' rough edges (Score:4, Interesting)
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).
Parent
Re:a 'few' rough edges (Score:5, Interesting)
So tell me, what really is wrong with C#?
Parent
I'm curious ... (Score:4, Funny)
Re:I'm curious ... (Score:5, Funny)
Parent
Re:I'm curious ... (Score:5, Funny)
Parent
Re:I'm curious ... (Score:5, Informative)
Parent
Is threading going to be abstraced out ? (Score:4, Insightful)
Dogma (Score:3, Interesting)
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 (Score:5, Funny)
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.
Parent
A better wheel (Score:5, Insightful)
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 (Score:3, Interesting)
Re:A better wheel (Score:5, Insightful)
Parent
Re:A better wheel (Score:5, Informative)
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 [gnustep.org]+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.
Parent
C++0x? (Score:3, Funny)
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? (Score:3, Informative)
Yeah about that standard library... (Score:5, Interesting)
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++
C++0x? D! (Score:4, Interesting)
I thought we were staying with C++ because of all the code that's already written in it...
Too little too late? (Score:3, Interesting)
What we need is "Smoothed out" people... (Score:5, Insightful)
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.
Expected release date (Score:3, Insightful)
Features I want... (Score:5, Interesting)
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... (Score:4, Informative)
exactly, and
std::for_each(content.begin(), content.end(),
std::bind1st(std::mem_fun(&PointVisitor::operator
is neither typable nor easy to read AT ALL! plus, it makes my head ache!
Parent
Re:Features I want... (Score:4, Interesting)
std::for_each(content.begin(), content.end(),
std::bind1st(std::mem_fun(&PointVisitor::operator
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.
Parent
Re:Features I want... (Score:5, Interesting)
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.
Parent
Re:Features I want... (Score:5, Interesting)
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.
Parent
Re:Features I want... (Score:5, Informative)
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 [open-std.org]
Parent
Re:Features I want... (Score:5, Informative)
For a full description of just how utterly brain damaged C++ member functions really are check this [codeproject.com]article.
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.
Parent
Watch out you don't get f'ed (Score:4, Funny)
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
A second wave for C++ (Score:5, Interesting)
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 [boost.org] and the Modern C++ Design [moderncppdesign.com] book.
For example, I've been using a combination of boost::function [boost.org] and boost::bind [boost.org] 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 [boost.org]).
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 [boost.org], 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,
Syntactic candy. (Score:5, Insightful)
- 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"
How about a module system? (Score:4, Insightful)
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.
Strostrup is in denial (Score:4, Insightful)
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 [evansdata.com] 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.
It's far too late (Score:4, Insightful)
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 [www.gotw.ca] 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:C++... always the ugly step-kid (Score:4, Informative)
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,
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.
Parent
Re:The future of C++... (Score:4, Insightful)
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.
Parent
Re:How about... (Score:4, Insightful)
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.
Parent