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."
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.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
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.
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? ;-)
Try out fish, the friendly interactive shell.
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.
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.
Try out fish, the friendly interactive shell.
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
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.
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.
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.
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.
If you were blocking sigs, you wouldn't have to read this.
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.)
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.
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.
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.
Actually, it is free. GDC is the gnu version of the compiler, completely GPL.
No, he means it's whatever year it ends up actually being. 2005 was just an example, as was 06 which he also listed.
The enemies of Democracy are
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.
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).
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that