Slashdot Mirror
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."
That's 0x as in 05 as in 2005. So C++05 or C++06.
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.
Try out fish, the friendly interactive shell.
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.
Opinions on the Twiddler2 hand-held keyboard?
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.
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.
( )), v));
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!
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.
...! 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.
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.
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
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.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.