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."
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.
You can't handle the truth.
... 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++.
.h header files. Call it the standard and let vendors code it out. Sweet!
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++
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...
Global symbol "$deity" requires explicit package name at line 2. - If only $scripture started "use strict;"
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.
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.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
I really wonder how they're gonna do that. I know some compilers have tried that in the past, with some export template thingy stuff. Templates where instantiated at link time. However, AFAIK, that never really worked.
Tristan
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!
If you say "here goes my karma" I will bite you!!!
if that were to happen i'd *so* be exhilerated!
not having a way to initialize a std::vector with some values has always been one minor annoyance for me when using the stl containers!
and about that "expert" thing: it is not by chance that c++ has become an expert-oriented language! there are SO many hidden traps and arcane details to get wrong that one can't just use c++ with intermediate skills and hope not to be punished! even the most simple mistakes can (and will) lead to segmentation faults and memory corruption!
i am not even saying that c++ is an evil language, but it sure as hell isn't newbie-friendly!
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.
... For Great Code!
The fact is, there's a huge C++ user and code base out there, and if they are going to stick with C++, there's exciting stuff coming.
I feel that C++ is having its second coming, primarily due to developments like the boost library and the Modern C++ Design book.
For example, I've been using a combination of boost::function and boost::bind to make powerful, flexible callbacks like nobody's business. Finally, there's a function "pointer" that can work with both freestanding functions, member functions and function objects, and finally there's an easy way to delay calling functions and use closures, respectively. (Also see boost::lambda).
Sure, almost all of this has been possible one way or the other (the flexible callback has been typically implemented via function ptr and void ptr argument, C-style), but it's very refreshing to actually have the code say what you mean: "I want to delay calling this function", or "this callback doesn't give a crap whether the function you're giving it is a member function or not".
Then there are smart pointers, which have easier-to-follow, clearer semantics, and can be used in STL containers and such. No more using easy-to-shoot-yourself-in-foot auto_ptr. It's been possible to write large chunks of code that have multiple "new" statements, but have no "delete" statements, all while maintaining exact control over the memory allocation.
Of course there's more... Maybe it's stuff that LISP/Scheme programmers have been using for ages, but the key difference is I can now apply tools in production commercial C++ code, during my everyday work. I no longer sit and say: "oh, crap, I could really use a closure here." I just do it.
A big problem is that the new features require greater understanding of the language and thus better training of the run-of-the-mill C++ developer. Many C++ developers I encounter do not have the sufficient understanding of these tools, and of the language. We should strive to educate our fellow developers,
I agree with you -- but if you read the article, you'll notice that Bjarne's point of view (and for that matter, the prevailing view in the community) is also consistent with yours. Basically, changes in the language are to be as minimal as possible. The changes that he proposes will not make life harder or more confusing. The "new C++" is going to be much the same as the old C++, but with a larger standard library.
The place where more substantial changes will occur (in fact have already occurred in TR1) is in the library. Libraries do change, that's a basic fact of life. The C++ standard library is still much simpler than other standard libraries.
So tell me, what really is wrong with C#?
We don't need a successor to C or C++, Delphi's use of Object Pascal provides all the functionality, speed, and a slick IDE, without the awkward pains of C flavored languages and without the hastles of interpreted or pseudo-compiled languages like Java or C#.
"22 astronauts were born in Ohio. What is it about your state that makes people want to flee the Earth?" Stephen Colbert
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.
"Honey, it's not working out; I think we should make our relationship open-source."
First off, Java only recently got templates and generics.
Secondly, C++ is a multi-paradigms language, you can OO or not OO, template or not template, h4x with the void pointers or not h4x with the void pointers. You and your problem choose, not someone else.
It also has operator overloading and you can control your resourse management options, rather than rely on Java's garbage collection which fails when you want to manage resourses other than memory (e.g. DB connections)
So Java and C# may have superseded C++ in many domains, but C++ is still king baby. Albeit a mean king.
I know that's a relatively intangible question to quantify but I did find a survey that lists different programming languages used in the workplace. Seems as if C++ definitely isn't dying just yet. I found another seemingly google-based article on the popularity of various programming languages. Sure Java and C# are up there with PHP thrown in as well, but C++ still has lots of current uses. Seeing I am hooked on Ruby in my workplace I am one of the few according to all of these figures :-)
The template closing thing is an obvious, minor change.
I'm not so sure about 'auto'. Just from the article, which admittedly is not supposed to be a list of features going into the new standard, I can't help but see problems. e.g.:
auto my_thing = [complex stl expression];
[some other complex expression](my_thing);
and getting some horrible STL error on the second expression because the type of the first expression wasn't what you expected and now you have to figure out what it actually was and how to force it to be what you thought it was going to be. In other words, it's the same nasty STL template debugging you have to do today, only with another level of hidden indirection in the type of a variable, which is at least something I don't really have to worry about today.
On the other hand, I do really like the idea of "concepts" where you specify what "concept" a template expects and the type you give can be verified to be the correct concept. As it stands right now, you don't know that a given type won't work in a given template until the compiler compiles a template function that requires a method your class doesn't support which may not even happen until after you've been using the template and class combination for a while. This sounds a bit like Java interfaces, but without the requirement that your class derive from the interface. You just have to provide what the concept expects.
This beats the hell out of the current situation where the "concept" a template requires is implied by its implementation. The implication that this might simplify template error messages would be icing on the cake.
The enemies of Democracy are
> forgive me if I take exception to some programmer hack calling himself a Scientist.
No, I won't forgive you, you pompous fuck. He didnt call himself a scientist, he said he had graduated with a degree in CS. That's what it's called and it has as much right to be called a science as rocket science, which is more obviously engineering than CS.
http://rareformnewmedia.com/
First, with ISO-quality standards, updates are made carefully and slowly to insure the least pain to all users relying on the standard. Backwards compatibility is usually the most important concern to the maintainers; there's no "willy nilly" changing going on. [Compare this to say Java, whose specs change much more quickly and perhaps more "willy" than C++]
There are many reasons to update standards periodically:
1. Most standards bodies (such as ISO) *require* that all standards be updated, or at least re-affirmed, on a periodic basis; usually once per decade. Otherwise they are considered abandonded and "revoked" from having its standard status. This helps weed out truely abandoned standards as well as insures that the standard is properly maintained and retains its usefulness.
2. As with most language standards, there are always many many small technical imperfections, or more commonly ambiguities, that need to be addressed or clarified. Most of these will never affect the "common" programmer, except perhaps those on the fringe (such as with embedded systems and so forth).
3. Practical experiences with a language often show shortcommings that, although may be technically minor, greatly detract from the language's usefulness in some cases. For instance when the C standard was last updated they made the numerical semantics much tighter (because they found out FORTRAN programmers could not adequately port programs to C without them). These changes would be hardly noticed by most programmers who don't do heavy and precise computation; but greatly welcomed by those who did.
4. Sometimes novel techniques or components are invented which prove to be very general solutions to widely-encountered problems, and which fit the "style" of the language very closely. Once these experimental components are deemed very mature and stable, adding them into the language proper can benifit all language users. For C++, many of these new extensions come out of the Boost project. But only the most mature and the most general-purpose extensions should be considered for standardization.
For a look at what's on the C++ issue lists, look at http://www.open-std.org/jtc1/sc22/wg21/
I prefer to think of that volume as "The Design Rationalization and Mutation of C++". An astounding amount of it is Stroustrup explaining why one feature or another would have been a good idea, but had to be shelved in favor of something simpler to implement, or requiring fewer keywords to change. It shows the extent to which C++'s design was political in addition to being technical (see Lambda the Ultimate Political Party for how this worked in the Lisp community).
It's a good, informative read, though not always a fun one - I still gnash my teeth every time I read about how they settled on termination semantics for exceptions.
To a Lisp hacker, XML is S-expressions in drag.
"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).
Opinions on the Twiddler2 hand-held keyboard?
May be Bjarne Stroustrup want to avoid "Argumentum ad verecundiam" (aka "Appeal to Authority").