Slashdot Mirror
An Interview With C++ Creator Bjarne Stroustrup
DevTool writes "Bjarne Stroustrup talks about the imminent C++0x standard and the forthcoming features it brings, the difficulties of standardizing programming languages in general, the calculated risks that the standards committee can afford to take with new features, and even his own New Year's resolutions."
Only two usages of "trivial" in that article? Needs to be fluffed up a bit.
Of course by this point it really should be called the imminent C++1x standard.
"I don't care about the Constitution!" --Bill O'Reilly, November 17, 2009
I want some efficient use of multiprocessor systems. When can expect to see this implemented in G++ or similar?
I never realized that the standard for C++ hadn't been updated in 13 years... Seems like a long time for a language that popular. Then again, if the standard doesn't change, old code should be supported for a longer period of time. Any thoughts on if this is a benefit?
The Copper Tribe - Office Software Solutions
which idiot would embed tabs in the code examples? typical kalev fail.
They should have added nullptr 20 years ago. It's always amusing to read about C++'s design for type safety when we've been forced to sling around magic '0' literals all this time because someone got their panties in a bunch over automatic casting of void*.
I am becoming gerund, destroyer of verbs.
There's still a market for low level C programmers, and for Java, C#, Perl, Python, VB, and just about everything else, but who uses C++ these days? Games developers, a few corporate app maintainers and... uh... hang on...
Note carefully: I love C++, with all its fragmentation, bloat, gotchas and non-standard-standard-libraries, but really, it's a niche language now, kept alive by beardy wierdies and a few caffeine soaked kids who'll burn out and end up writing SQL for banks in a couple of years. Interesting, but hardly news that matters.
If you were blocking sigs, you wouldn't have to read this.
Sadly, designers do not have much interest in 'fixing' things when they can design new stuff AND increase the number of places their design can be used. That is the problem with C++... the people steering it want a language to solve all problems, and increasingly it becomes worse at solving any,.. or at minimal the increasing number of solutions to any given problem embedded in C++ makes understanding it more and more difficult.
I think they could use a graphic designer for "The number one developer site!".
It seems to me that most tasks that seem good for C++ would be better handled using a mix of an easier-to-program language (Ruby, Python, heck even lisp or smalltalk or anything else) with C extensions.
IMHO C++ seems not very good at very low-level programming; since with C++ it's not always obvious what a compiler might want to do with '+' thanks to operator overloading and rather convoluted implicit casting rules. In C you're using a pretty good tool for low-level programmings (especially with a dialect where you can sneak in a few assembly calls where you need to). In Ruby you're using a reasonably nice and efficient to develop in OO language. With the incredible ease of writing C extensions for Ruby, it's easy to use the best tool for each part of the job you're doing. The only compelling reason to use C++ I can think of is if some political policy forces you to use a single language for an entire project; and then I guess C++ not quite as clunky as java or c#.
( though I'm kinda repeating myself - a longer rant I made on slashdot about the pains of C++ years ago is here http://slashdot.org/comments.pl?sid=100202&cid=8540772 . An even more condemning annoyance about C++ is that thanks to so many convoluted tricks in the language, most people who claim C++ knowledge don't actually know it, as evidenced by the comments in that old thread )
Stop trying to add more redundant features to C++... it is already getting progressively harder for C++ programmers to read each other's code and teach newbies what something means.
All this does is result in yet more more syntactic sugar to teach people in order to accomplish the same tasks they can already do with the older standards, and yet another round of relearning so you can tell what someone who learned a 'neat new trick' is doing. And of course you STILL need to teach the old methods to newbies so they can understand C++ code that they have to maintain.
Seriously.. this really does not help.
C plüzs plüsz ...
Read radical news here
I always preferred this interview with Bjarne Stroustrup.
(Yes, I know it's not real, but...)
See-plus-plus-zero-ex doesn't really roll off the tongue. How about something a bit easier? Super-C, C-flat, Cmega+ or something lame that people can actually say.
(Here's your queue to explain to me what the proper pronunciation is. AND the reason for picking such a weird name)
http://harmful.cat-v.org/software/c++/I_did_it_for_you_all
Early C++ introduced void* and it was good. C adopted it.
Then C++ took away the automatic casting, I guess about the time C++ was first standardized. OK, now what is the point? The value of void* is gone. Now we write code with nasty casts. We can even hide the nasty casts in macros. Oh joy.
C remains fairly sane. There haven't been any serious fuckups since the trigraph disaster which no compiler enables by default. C99 is damn nice in fact.
...if some political policy forces you to use a single language for an entire project...
Oh God!
I have never seen a software project that used "the right tool for the job" - different languages for different for different parts of the system - that wasn't: overly complex, buggy as all hell, and a complete bitch to debug and to understand.
Here you are, debugging the C++ code and all of a sudden, it makes a call to an interpreted language module (kicking off the interpreter in the process) and you can't step in and follow WTF is going on. You're back to printing out to console or a file to see what's going on. Of course, the first several times in doing that isn't enough so you're constantly adding more "print" statements.
I once had a system that had a Java Swing UI, a C++ module that did something, that called a Perl module because, according to the original developer Perl is the only language for processing text, which then went back up the chain to the Java UI which then made JDBC calls into Oracle (with its own SQL code) and then back. It was buggy, ugly, slow as fucking hell, and the end user eventually scrapped everything (and canned everyone in the process) and bought something off the shelf.
tl;dr: Writing a system in one language is perfectly acceptable and this "right too for the job" only applies to trades people. Languages are just syntax and they all end up as ones and zeros in the end.
Interviewer: Well, it's been a few years since you changed the
world of software design, how does it feel, looking back?
Stroustrup: Actually, I was thinking about those days, just before
you arrived. Do you remember? Everyone was writing 'C'
and, the trouble was, they were pretty damn good at it.
Universities got pretty good at teaching it, too. They were
turning out competent - I stress the word 'competent' -
graduates at a phenomenal rate. That's what caused the
problem.
Interviewer: Problem?
Stroustrup: Yes, problem. Remember when everyone wrote Cobol?
Interviewer: Of course, I did too
Stroustrup: Well, in the beginning, these guys were like demi-gods.
Their salaries were high, and they were treated like
royalty.
Interviewer: Those were the days, eh?
Stroustrup: Right. So what happened? IBM got sick of it, and
invested millions in training programmers, till they were a
dime a dozen.
Interviewer: That's why I got out. Salaries dropped within a year,
to the point where being a journalist actually paid better.
Stroustrup: Exactly. Well, the same happened with 'C' programmers.
Interviewer: I see, but what's the point?
Stroustrup: Well, one day, when I was sitting in my office, I
thought of this little scheme, which would redress the
balance a little. I thought 'I wonder what would happen, if
there were a language so complicated, so difficult to learn,
that nobody would ever be able to swamp the market with
programmers? Actually, I got some of the ideas from X10,
you know, X windows. That was such a bitch of a graphics
system, that it only just ran on those Sun 3/60 things.
They had all the ingredients for what I wanted. A really
ridiculously complex syntax, obscure functions, and
pseudo-OO structure. Even now, nobody writes raw X-windows
code. Motif is the only way to go if you want to retain
your sanity.
Interviewer: You're kidding...?
Stroustrup: Not a bit of it. In fact, there was another problem.
Unix was written in 'C', which meant that any 'C' programmer
could very easily become a systems programmer. Remember
what a mainframe systems programmer used to earn?
Interviewer: You bet I do, that's what I used to do.
Stroustrup: OK, so this new language had to divorce itself from
Unix, by hiding all the system calls that bound the two
together so nicely. This would enable guys who only knew
about DOS to earn a decent living too.
Interviewer: I don't believe you said that...
Stroustrup: Well, it's been long enough, now, and I believe most
people have figured out for themselves that C++ is a waste
of time but, I must say, it's taken them a lot longer than I
thought it would.
Interviewer: So how exactly did you do it?
Stroustrup: It was only supposed to be a joke, I never thought
people would take the book seriously. Anyone with half a
brain can see that object-oriented programming is
counter-intuitive, illogical and inefficient.
Interviewer: What?
Stroustrup: And as for 're-useable code' - when did you ever hear
of a company re-using its code?
Interviewer: Well, never, actually, but...
Stroustrup: There you are then. Mind you, a few tried, in the
early days. There was this Oregon company - Mentor
Graphics, I think they were called - really caught a cold
trying to rewrite everything in C++ in about '90 or '91. I
felt sorry for them really, but I thought people would learn
from their mistakes.
Interviewer: Obviously, they didn't?
Stroustrup: Not in the slightest. Trouble is, most companies
hush-up all their major blunders, and explaining a $30
million loss to the shareholders would have been difficult.
Give them their due, though, they made it work in the end.
Interviewer: They did? Well, there you are then, it proves O-O
works.
Stroustrup: Well, almost. The executable was so huge, it took
five minutes to load, on an HP works
And, we all know that power corrupts. So, when Joe Shortcut figures out that he can overload the '=' operator to slice his ham sandwich, you invariably end up with illogical, non-intuitively behaving code. Plus, the language in an effort to be ultimately configurable, doesn't take care of some menial, repetitive tasks. That opens the door for insanely dangerous, obscure bugs like object slicing. I wish that the standards community would have just drawn a line in the sand and said "OK, here's the cleaned up, modern version that we made practical at the expense of esoteric powers."
That being said, I have total respect for what Stroustrup accomplished in context.
I swear to God...I swear to God! That is NOT how you treat your human!
The biggest beef I have with C++ is linking.
Linking to a library that was compiled in a different C++ compiler (or even a different version of the compiler you have) is somewhere between painful and downright impossible; this is because function name mangling was never standardized and the core libraries are often incompatible.
Couldn't they standardize this in C++? It would make life so much nicer for those who deal in binaries.
There's no -1 for "I don't get it."
My experience with C++ developers in the late 90's was that 99% of them knew only a tiny, tiny percentage of the language.
My experience is that 99% of people muddle through life with a combination of hubris and clandestine effort.
A similar proportion express that their knowledge and talent is well above average and insist that almost every challenge is trivial.
This group is overrepresented on Slashdot.
It's a long time before anyone starts to use nullptr. NULL is still shorter to type and too entrenched in the documentation. What I do not understand is why tey kept NULL there.
Is there any reason not to break backward compatibility? If there is any of that in some legacy code you can split your codebase in two and compile with different versions. Other languages break legacy code at every version and still manage to stay around. I think this is because every code big enough that you cannot rewrite is probably modular. I am usually against patching instead of fixing, especially on something that should be used by everyone. Of course I never designed a language, so maybe I am wrong...
According to Wikipedia, "C++0x" is pronounced "see plus plus oh ex". After three rounds of macro preprocessing, four expansions of template substitutions, and reversing five levels of dynamic cast operator overloads, the name is eventually compiled to something readable: C plus plus? Oh, my ex-programming language!.
Sigh. Why do we still have to go through this? That is the designation to distinguish when you are talking about the new standard. That is NOT its name. The language is still just C++. ALL ISO language standards committees do this. When the new standard comes out, the language will be called C++. You write things like C++03 and C++0x or C90 and C99 to distinguish between them.
Because it's still just C++. C++0x is just one particular version, like C++98 or C++03. Java 1.6.23 doesn't exactly roll off the tongue either.
C++-oh-X is as easy to say as any of your suggestions, and the word is "cue" you weak-minded trumpster.
Cocks?
Does anyone actually use any of the features of C++?
Yes. So far I've used:
And that's just in my own code, not counting features that libraries use (rvalue references, for example). I'd use a lot more if they were implemented in g++.
The next C++ standard is going to be a huge improvement in usability, especially for writing generic code.
Actually it is my cue to inform you that you used the wrong word that sounds like the letter 'Q'.
thats all
It's a long time before anyone starts to use nullptr.
If you ever ran Visual Studio 2010, you have used a product that uses nullptr in some parts of its source.
(while we're at it, it also has C++0x lambdas)
It's a long time before anyone starts to use nullptr. NULL is still shorter to type and too entrenched in the documentation.
In which documentation? "The C++ Programming language" mentions it twice, and says it's a C thing which you should avoid -- just use 0. Which is what I do.
Of course you can still *call* it "the NULL pointer" when you talk about it.
Which in turn will be mispronounced to Chalk, which is a kinda workable language name.
It Makes me suspect that the erase feature is fast and dirty.
well lets be fair: C++ is a flexible and powerful, it was designed to be. If you have a developer that isn't very good, they will produce code that is a unorganized mess. In the hands of a skilled dev, there is nothing wrong with C++. They can produce some very elegantly designed data structures. But this is true of any language.
You are in essence condemning fire because it can cause burns.
HA! I just wasted some of your bandwidth with a frivolous sig!
"The C++ Programming language" mentions it twice, and says it's a C thing which you should avoid -- just use 0. Which is what I do.
And then you have to do all sorts of workarounds for it when you have overloaded functions where it thinks you are passing it to the one that takes an integer instead of the one assuming a pointer.
It is ugly as hell but it is readable... why more sites do not have a printer friendly page is beyond me (or I missed the link)!
Oh yeah, be prepared to scroll down a lot to get to the meat.
Page 1/3:
http://webcache.googleusercontent.com/search?q=cache:http://www.codeguru.com/cpp/misc/article.php/c18357/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm&hl=en&client=firefox-a&hs=5K7&rls=org.mozilla:en-US:official&strip=1
Page 2/3:
http://webcache.googleusercontent.com/search?q=cache:http://www.codeguru.com/cpp/misc/article.php/c18357__2/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm&hl=en&client=firefox-a&hs=kN7&rls=org.mozilla:en-US:official&strip=1
Page 3/3:
http://webcache.googleusercontent.com/search?q=cache:http://www.codeguru.com/cpp/misc/article.php/c18357__3/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm&hl=en&client=firefox-a&hs=kN7&rls=org.mozilla:en-US:official&strip=1
Now since I have posted a comment like a good /.er I can go RTFA.
A few years ago, I was invited to a musical performance. It was performed by a lady I knew who was completing her PhD in musical performance. She was hoping to round up people to attend the performance. I, along with about 4-5 others went as a group, and in a hall that can hold about 350, there were 20 or so in total. There were three people at the front -her teachers- grading her performance. The pieces were quite.... longhair. One was immensely atonal. It seemed to be a mere exercise in accurately hitting notes at one end of the piano keyboard, then at the other end, and then back and fourth a few dozen times. It did not sound like music in any traditional sense of the word. Why am I talking about this when the Slashdot piece is about C++? C++ is a good academic exercise. It provides nothing else. C, is a great, all purpose, fully functional, Turing complete language (full stop). It didn't need anything major added to it. It was and is fine. A few cleanups here and there, a few cases where things could be done a bit better, but its expressive, logical and elegant. So then we have C++. Elegance is gone. Out the window. We traded clarity, for obscurity. And what did we trade it for? What? Well now thats the big question, isn't it? What exactly did we get? Overblown? Overhyped? What real good functionality do we get, that we did not have before? Is there anything useful in C++ that did not exist in C? NO, thats the whole point. We were fine with C. C is complete. Its a bit like the movie Highlander. It was fine on its own, but then Highlander 2 comes along. OH MY THE DISAPPOINTMENT! What a failed exercise! What a waste of time and effort! I've heard people making arguments for C++ for a long time. They fail. Elegance, simplicity, beauty were replaced by something matching Cobol in verbosity, and binary in readability. Oh, we are told, you just need to examine a few thousand classes to understand... and thats where it fails in elegance. Like its object oriented, overloaded, overblown brethren, it hypes it virtues, fails on those, and ruins what was elegant. This truly isn't anything about zeal, this is the practicality of the language itself. Its an academic exercise, best left in academia. It provides nothing useful that hasn't been done better elsewhere.
WHEN are you going to implement dynamic memory allocation tracking?
Memory leaks are one of the major headaches in C++. That's the main reason people use C# over C++. Mix that in with exceptions and I doubt any application beyond the most trivial won't memory leak.
What is this? "My First HTML Page" class at some high school?
I wonder if they'll *finally* get rid of those cumbersome backwards things called header files.
Why OpalCalc is the best Windows calc
You don't have to learn the whole language to get advantage from it.
Procedural programming style with C++ is just as easy as with C and you get the benefit that if you want to use something neat like stl::string you can.
I feel most sorry for the people who are stuck with using pure C. Usually either by choice (maybe the 0.0001% speed boost matters?) or by lack of C++ runtime libraries (kernel level programming). If you can take the day or two it takes to learn C you now know enough to create meaningful programs in C++. There's nothing wrong with C-style programming in a C++ environment. If anything the overuse of classes and objects by end-users is a problem with C++, the language itself is fine.
NULL is defined to be integer 0 in C++, so you have to do these workarounds when you use NULL, as well; indeed, one of the advantages of using 0 is that it serves as a bit of a reminder that you need to keep these workarounds in mind.
Each to their own I suppose. It has been useful to me, for writing plenty of software across multiple platforms. Just because you have a love of C doesn't mean everything else is dreadful. You don't have to use it, nor do you have to whinge.
Many people I know think that Jazz music sounds dreadful, but that doesn't make it bad. They don't have to listen to it, and it would be better if they don't whinge about it.
If you miss the interplay of the backing section with the lead lines and the swapping of lead lines and interplay in Jazz, I suppose it would be lost on you. But that's not a problem. No need to whinge about it.
So you don't value the fact that there's now a well-defined memory model for multithreading, as well as a standard interface to it so you can do cross-platform multithreaded code without #ifdef or relying on third-party code?
And you don't value that they removed the restriction that you couldn't use local classes as template parameters?
And you don't value the fact that returning standard library classes by value will now be much more efficient, thanks to move semantics?
And you don't value that regular expressions are now supported in the standard library?
The Tao of math: The numbers you can count are not the real numbers.
imminent
C++0x
Did anybody else laugh out loud seeing those two words next to each other?
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
If [operator +] does something unexpected, chances are you [...] are using a terrible library
Terrible libraries are a fact of life. In many cases, you don't have the clout to change the specification of your program to use different libraries. So we need a language that doesn't encourage the creation of terrible libraries.
I'm the type to make it easier, or switch to a language where it is easier.
Until you end up on a platform that only runs one language. For example, Xbox 360 XNA and Windows Phone 7 run only C# (or other languages isomorphic to C#), and BlackBerry runs only Java. For a few months, while Apple and Adobe were feuding over AIR, iPhone and iPod touch ran only Objective-C and C++ in apps and JavaScript in web pages.
Well, variable declared at the top of the function are the least evil c-ism.
Furthermore, this requirement hasn't been in C for a decade.
The real problem is a lack of understanding of RAII, and a fear of exceptions.
Fear of exceptions, STL containers, iostream, and the like may come from having worked on a platform with less than a megabyte of RAM. Case in point: Hello World takes 180 KiB out of a handheld device's 256 KiB of program RAM, and that's after turning on size optimizations, Thumb (compressed instructions), and experimental dead-code elimination in the linker.
you need to be able to handle literal strings.
If you have literal strings in your program, end users who don't speak English won't be able to use it. That's why you're supposed to wrap your strings with gettext macros, so that they get translated to UTF-8 strings in the chosen language pack at runtime.
C++0x is the draft name. If it is published by the ISO in 2011 then it will be C++11.
Ruby-style package management. I'm back on java at the moment, but I fell in love with the Gem system the moment I saw it. Actually I'd like to see a high level package management interface exported by the operating system itself that package managers of all sorts could communicate with, and a C++ package manager that talks to THAT. It's amazing how much of a difference having access to high quality open source libraries makes on the development process.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
C++ jumped the shark some time in the early 90's; it's been going downhill ever since, becoming more and more bizarre and bloated.
What's wrong with overloading "()" and "->"? That's indispensable for smart pointers and function-like objects (callable things with optional state... i.e. closures).
Exactly.
I've seen some pretty horrible resource leaks and reentrancy problems because of allegedly smart pointers that are neither smart nor pointers. I've seen function-like objects become a witch's brew of nasty bugs.
Beginners love that shit, but then they get themselves into a mess and need somebody like me to rescue them. I do, once I get past my "WTF!!!" reaction to whatever wild feature it is that they are using.
BTW, in most cases this holds true for threads as well. Use fork() and ppoll() if you want to do the job without bugs.
"C++ is disproportionally used where performance really matters."
But, as a freelance software dev, this disregard for proportion, is more than bread and butter.
It covers coke + hookers too. Thanks BS! I hope you keep at it for a while yet....
Some implementations (e.g. g++) give a warning if you use NULL in a non-pointer context. This is not possible with the literal 0 (because the compiler has no way to know that this specific instance of the literal 0 was meant to be a null pointer, and not a zero).
The Tao of math: The numbers you can count are not the real numbers.
C++0x is the draft name. If it is published by the ISO in 2011 then it will be C++11.
Typical C++ design. To save two bytes of RAM they skipped the century testing in the name itsefl, so in 2098 the ISO committee will crash with double-pointer-allocation errors.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
Darl McBride (ex CEO of The SCO Group.) : "And C++ programming languages, we own those, have licensed them out multiple times, obviously. We have a lot of royalties coming to us from C++. (August 15, 2002, [1])"
http://en.wikiquote.org/wiki/Darl_McBride
For even writing the piece of shit.
Hey KID! Yeah you, get the fuck off my lawn!
When:
- a base class has a virtual member function
- the base class exposes its "this" pointer externally (for instance: by linking itself into a list)
- a derived class overrides the virtual member function
- the derived class of the base class has members of object type that have constricution and/or has calls to external functions in member initializers
- the construction or other initialization of the derived class members BEFORE executing the body of the derived class constructor calls the virtual function.
what version (base, derived, something breaks) of the function is executed?
Similarly for destructors.
IMHO the specification should REQUIRE that the BASE class version of the virtual function is the one that is executed at any stage prior to the execution of the first line of the body of the constructor and after the execution of the last line of the body of the destructor, while the DERIVED class version is executed during the execution of the body of the constructor, destructor, and at all times between them.
This was "broken" in 1985ish, when a project I was associated with tried to use C++ as its language. (Treating the constructor and destructor cases separately gives you four binary combinations of behavior of which one is "right" and three are "wrong". Cfront and cfront-derived compilers got it "wrong" one way, three C++ compilers available on IBM PCs got it "wrong" a second way, and gcc got it "wrong" the third way.
I tried in both ANSI standardization processes to get it "fixed", i.e. defined as I suggest above. I was rebuffed both times. It was declared explicitly undefined behavior in the first ANSI C++ standard and "don't do it" in the second.
Question: Has it been fixed, or even defined, YET?
This is NOT an academic issue. C++ (unlike, for instance, Smalltalk and Objective C) has construction semantics that promote and demote the behavior of objects of derived classes in a way that keeps the debugging of unchanged parts of base classes intact when modifications are derived from them, which is one of the things that makes C++ code more robust. And its ability for classes to have members of object type has potential to greatly reduce memory management overhead compared to webs of heap-allocated pieces in the Smalltalk style.
But this oversight in the specification of behavior on construction and destruction forced that project to the web-of-little-heap-things style regardless, and also has the potential to sucker the programmer into creating extraordinarily subtle bugs.
So didja fix it, guys? PLEASE tell me you fixed it!
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Most, if not all, of the AAA game industry uses C++, as does Microsoft Windows from about 2000 on, along with Active Directory and SQL Server.
I'm sorry, you were saying something about how C++ is just academic wankery? Why is the games industry and Microsoft not satisfied with plain old vanilla C, then?
To take one stab at an answer: because anyone building anything major in C invariably implements part or all of an object or templating system to manage the complexity.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
Forward looking company is looking for a self starting, dynamic and versatile C++0X developer. Must have 2 years in depth experience in C++0X.
Starting rate is $39k
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
One louder?
Compilers that have different ABIs use different mangling schemes so that you don't combine incompatible code -- you get big error messages up front, rather than mixing code that assumes different layouts, or different calling conventions, etc.
When compilers implement shared ABIs (as some C++ compilers do), linking code produced by them just works.
Treat the ++ as silent, and an obvious solution presents itself.
Personally, I think C++ doesn't merit a roll-off-the-tongue name, drawing as much inspiration as it does from INTERCAL ;)
Lisp is a compiled language, so you don't need C extensions so much, other than to call a foreign API. When you use CPU-intensive routines like cryptography, regular expressions, etc, in a Lisp program, those things are also written in Lisp. The performance is comparable to using C libraries, though Lisp programs can call C libraries easily, and Lisp routines can be passed as callbacks to C code.
Lisp supports the business model of writing a tamper-resistant proprietary application, distributed to users in binary form, just like C++.
You can program using Python syntax and semantics in Lisp thanks to the CLPython implementation, which works by compiling the Python code to Lisp forms, which are then compiled by your Lisp compiler. Since Lisp is an extensible language, CLPython appears to you as a library that you add to your program, which then lets parts of your program to be written in Python.
You're not helping make a case for it. The reason nobody has ever wanted lambdas is because they're ugly, confusing, and difficult to maintain. The code is cleaner and better formatted using an actual function.
I still have more fans than freaks. WTF is wrong with you people?
Some additions are long overdue, but boy is the syntax ugly. I guess there are only so many neat ways to hack the parser for the already overcomplicated language.
And of course, Boost demonstrates everything that is wrong with the C++ mainstream these days, including extreme template bloat and failure to address the existence of shared libraries. For practical programming, I'd recommend C++-by-Qt and Vala.
My exception safety is -fno-exceptions.
Committees should standardize what is out there. Once that is done, they have achieved their purpose and it's time to disband.
The problem with the C++ committee is that their egos prevent them from going their separate ways.
Once a committee thinks that it is so important that it can start inventing new features and dictating them to the programmers and implementors, it is the beginning of a disaster.
Almost never should a draft language contain features that no compiler has. This should only happen very early in the standardization, when there is no other way to solve some conflict between dialects.
You can program using Python syntax and semantics in Lisp thanks to the CLPython implementation,
Great! That lets you combine the poor libraries of CommonLisp with the syntactic limitations of Python.
The performance is comparable to using C libraries,
It is possible to get C-like performance out of a CommonLisp compiler, but you have to jump through hoops to do it, and the necessary declarations are different from compiler to compiler (and sometimes even between versions).
The reason nobody has ever wanted lambdas
Why do you speak for other people? I don't know a single experienced C++ developer who wasn't excited about lambdas. For one thing, they finally make STL algorithms actually usable, because you don't have to write insane amount of boilerplate.
For that matter, consider the fact that someone bothered enough to write Boost.Bind and Boost.Lambda, and that even more people used that. This alone shows that a lot of people wanted lambdas.
they're ugly, confusing, and difficult to maintain.
Ugly is subjective.
Confusing - every mainstream language today except Java has them. Heck, VB - VB of all things! - has them, and VB code monkeys don't find it confusing. Perhaps you should catch up with times?
Difficult to maintain - what, more difficult than hand-written functors with explicit state capture and all that entails? I highly doubt so.
The code is cleaner and better formatted using an actual function.
When comparing lambdas to functions, you miss the crucial point of lambdas, which is the fact that they can capture state - that's what makes them so useful. If you e.g. need a function object to pass to std::find_if, and you need to compare against a value of the local variable in that function object, it's trivial to do with lambda:
The above is concise (compared to the old way, anyway; Rubyists would probably chuckle), and perfectly clear in its intent.
On the other hand, you cannot use find_if that way with a plain function at all. You can do it with a handwritten class with overloaded operator(), but then you have to declare the field to save the state, and make sure you initialize it properly. What's worse is that it's tucked away from where it's actually used, so the call to find_if is that much less readable due to need to jump to the definition of the class.
One of my favorite rants on C++: http://bit.ly/bchSYy
You drank my drink, you drunk!
C with Classes... oops I mean C++ is actually a fantastic language when combined with a proper, modern set of libraries. At the moment the only thing we have is Qt. I've heard from avid Boost users how great their system was, but their code tends to be ugly as since and far more complex than necessary.
While I still code every day in C++, and sadly because of lack of a useful standard library, I work on "roll your own" on our platform, my daily projects tend to be written in VM based languages with bindings to C++ where necessary. C++ is just too old and far too limited to be considered as the base of a new project these days.
Of course, when it comes to UI development, Qt is just the only option available to a cross platform developer. You have 3 choices these days.
Develop a new UI for every platform in the native toolkit.
Use GTK+, Windows.Forms, SWT etc... which actually looks like shit on every platform other than what they were written for in the first place... or in the case of SWT is just plain weird looking on all platforms.
Use Qt which looks, feels and behaves properly on the platforms it supports.
In any of the three choices, you still have to customize for every platform because only an idiot would ship a program designed to look great on Windows for Mac, or a designed for Mac for KDE, or designed for KDE on a mobile phone etc... but, Qt makes it easier than most.
So, these days, while I've love to work in a great language like C# as opposed to a ancient clunker like C++ or C, to make anything even moderately professional in style and features, I need to use Qt and use C++ to do it (don't bother mentioning Jambi, Java was a great experiment, but it's obsolete now)
C++ : An octopus made by nailing extra legs to a dog
So you don't like auto because you prefer to type more... I see.
Quick way to get 30% Funny 70% Troll: defend Opera browser on
It takes a lot of time to maintain header files. I assume that almost 40% of a project is spent on writing and maintaining header files.
It is a job that could be done perfectly by the computer, and it could be easily fixed with some simple changes:
1) When the preprocessor finds an #include directive (for example "foo.hpp"), it checks if the header exists.
2) If the header does not exist, then try to open the file 'foo.cpp' and extract the header automatically. Put the header in the same folder as the implementation file.
3) If the header exists, then compare its date and time with the date and time of the implementation file. If the header is older than the implementation file, extract a new header from the implementation file.
4) cache all headers of all projects into a compiler's directory... a sort of precompiled headers mechanism that is independent of projects and completely automatic.
These simple changes will boost c++, even much more than the changes in the language itself. I understand that these changes have little to do with the language(*), but, nevertheless, they are extremely significant.
(*)perhaps for this to work some new toplevel keywords may be required; for example, using 'public:' and 'private:' at translation unit level would help the compiler extract the header as needed.
There are some very easy improvements that have missed:
1) giving lambda types names. Without specific names for lambda types, functions cannot be statically overloaded for lambdas. They could have named the type '__anonymous_function' or '__lambda_function', where T is the function's signature.
2) giving a type to the literal {1, 2, 3...}. Standard literals have a type (for example, 3.14 is a double, 3.14f is a float, 5 is an integer, 5L is a long etc). This literal does not have a type, and uniform construction over the initialization list has to be a special case for the compiler.
3) giving a type to the literal {1, 3.14, "a"}. Since the new language would have tuples, the type of this literal could be the relevant tuple.
4) allowing functions to be invoked by passing them a tuple, instead of an arguments list. For example, a function foo(int a, double d) could have been called by foo({1, 3.14}) or foo(t) where t is std::tuple.
5) removing the restriction of having to have a template prototype in order to specialize it. Why not make classes like functions and allow classes to be parametrized with 0, 1 or more template arguments? for example, one could have a class Point, which is the original implementation (say, over integers) and then a new class Point, which contains a double implementation. The compiler would then choose the appropriate class, based on selection of type.
6) a way to enumerate the members of a struct, function stack record and translation unit variables at compile time. This would open the door for some easy to implement introspection library, as well as other possibilities (a tracing collector, for example).
7) a way to invoke functions with assignment syntax or without parentheses when they have no arguments. For example, a class could have the functions 'name()' and 'name(string s)', which could be used like 'name = foo.name' and 'foo.name = "bar"' respectively. This could open the door to having object properties via convention.
8) named arguments. A lot of code is of the form:
x = new X; ...
x->setA(a);
x->setB(b);
x->setC(c);
This could be avoided by having named arguments:
x = new X(A = a, B = b, C = c);
Plus it would make the code much more readable.
9) default parameters not only at the right side of a function header, but in any position. A function could be invoked by simply omitting the relevant argument. For example:
void foo(int x = 0, int y = 0, int a, int b);
foo(,,1, 2);
An annual interview with Bjarne Stroustrup, about the upcoming C++0x standard:
http://developers.slashdot.org/story/10/10/14/1947247/Bjarne-Stroustrup-Reflects-On-25-Years-of-C
http://tech.slashdot.org/story/09/08/07/1518205/Bjarne-Stroustrup-On-Concepts-C0x
And strangely LISP has had Lambdas since the 50s and has experienced neither of these problems.
Sounds like you're a fan boy making excuses to me.
It's not a big deal in Unix world where source code is generally available these days, which is why Unix compilers (e.g. g++ and Intel) converged on a common one; but Windows stuff is still broadly incompatible.
Just like everyone else except the US is using this non-standard and incompatible "metric system". ;-)
...and if you ever ran VS 6, you have used a prodcut that tries to use null pointers in many parts of is source.
I hope we are not using C++ anymore by 2098...
Rethinking email
I'm not sure of the answer to your question, but the answer to your problem is not to do this:
- the construction or other initialization of the derived class members BEFORE executing the body of the derived class constructor calls the virtual function.
This is a circular dependency that will never make logical sense, much less have a sensible implementation. If you find yourself needing to do this, there should be a way to renormalize your object model so that the member objects are not dependent on (or even aware of) the existence of the thing they are destined to be members of (at least until all the parties involved have completed their constructors, but preferably maintaining orthogonality through the entire life cycle)
For great justice.
You can program using Python syntax and semantics in Lisp thanks to the CLPython implementation,
Great! That lets you combine the poor libraries of CommonLisp with the syntactic limitations of Python.
The performance is comparable to using C libraries,
It is possible to get C-like performance out of a CommonLisp compiler, but you have to jump through hoops to do it, and the necessary declarations are different from compiler to compiler (and sometimes even between versions).
Common Lisp has great libraries, and can easily call foreign API's. Lisp can call C functions, pass Lisp functions to C as callbacks. Lisp compilers have extensions that let you manage argument data right on the stack. Recently I needed to call some Win32 functions from Clozure, and found all the goodies there to do the job with minimal overhead.
Common Lisp declarations for type and optimization are part of the ANSI standard, and generally do the same thing across different compilers.
"possible to get C-like performance" (Lisp) is a heck of a lot better than "impossible to get C-like performance" (CPython, Ruby, ...). To get "C like performance" from C, you also have to jump through hoops sometimes.
Of course, I would like "same from compiler to compiler", but when that is not available, my next choice will be "different from compiler to compiler". My third choice after that would be "only one compiler", and an unfortunate fourth would be "no compiler" (CPython, Ruby).
A well-behaved Win32 program uses the system libraries and language runtimes found on the target platform
Practically, this means that a well-behaved Win32 program is built with Microsoft tools, not free tools. This wasn't practical until Microsoft committed to making Visual Studio Express available to all Windows users with a cable, DSL, or better connection. (Satellite and 3G are out because downloading the 2 GB of VC++ Express and Windows SDK would consume a big chunk of the monthly transfer cap.) By then, MinGW had already frozen into an incompatible C++ ABI.
The Windows DDKs and Platform SDKs (recently renamed to Windows SDK) were free downloads to just get the compiler and libraries
I checked on Microsoft.com today, and the current Windows SDK comes on a 1.4 GB DVD image. Good luck downloading that much data in one sitting on satellite or 3G.
"The C++ Programming language" mentions it twice, and says it's a C thing which you should avoid -- just use 0. Which is what I do.
And then you have to do all sorts of workarounds for it when you have overloaded functions where it thinks you are passing it to the one that takes an integer instead of the one assuming a pointer.
In ten years of C++ use I never ended up in that situation -- it's probably very rare to overload on integer types and raw pointers which may be null. But I suppose that's one reason they added nullptr.
Sadly, designers do not have much interest in 'fixing' things when they can design new stuff AND increase the number of places their design can be used. That is the problem with C++... the people steering it want a language to solve all problems, and increasingly it becomes worse at solving any,.. or at minimal the increasing number of solutions to any given problem embedded in C++ makes understanding it more and more difficult.
You make it sound as if they are pushing out troublesome new vanity features in C++ weekly, making the language worse and worse. Examples, please?
In *my* world, the current standard is 13 years old, and the only important thing that has happened since then is that gcc and VC++ have stopped sucking.
This is a circular dependency that will never make logical sense ...
This is SO not true. I'll give you some examples in a bit.
If you find yourself needing to do this, there should be a way to renormalize your object model so that the member objects are not dependent on (or even aware of) the existence of the thing they are destined to be members of (at least until all the parties involved have completed their constructors, but preferably maintaining orthogonality through the entire life cycle)
Again not true. The issue is not that the members have an awareness of the eventual object. The issue is that the base class EXPORTS knowledge of and access to common behavior of all classes derived from the base class but the details of which vary depending on which derived class is in question. The promotion of the instance to the derived class "switches on" the details of the behavior - but if this occurs, and is invoked, before the derived class is able to initialize the underpinnings of the behavior, things break.
One example from the project: Garbage collection via a mark-and-sweep algorithm:
- All heap-allocated objects subject to garbage collection are members of classes derived from a base class ("Heaper") whose constructor hooks the objects into a list of all allocated Heapers and whose destructor unhooks it.
- The virtual function in question is the mark-yourself part of the pointer-following marker. (Its guts are generated by a preprocessor that parsed the class declaration.) In a Heaper-derived class it knows about the pointers to other Heaper-class objects at its level. It calls the baseward version of itself and if it returns TRUE calls the mark-yourself functions of all the objects pointed-to at its level. At Heaper itself the function marks the object itself and returns TRUE if it was unmarked.
- When garbage collection is invoked the Heapers are all unmarked. The collector first calls the mark-yourself functions pointed to by "smartpointers" that constitute the data-structure roots, then walks the list of Heapers, freeing the unmarked and unmarking the marked.
The problem arises because constructors of member objects of the derived class may cause memory allocation (either temporary or permanent) and this may invoke the garbage collector. If the class has already been promoted to the derived type (i.e. if calling its mark-yourself virtual function gets the derived class version) the garbage collector will try to follow the derived class pointers - which may not be initialized yet. Oops!
Another case: Exception handling. (This project was running before "catch" and "throw" were more than reserved words.) The similar problem occurs because destructors are such a virtual function. If an exception is thrown from a member object and the class under construction was promoted too soon, you end up running the destructor of the derived class before the constructor was run, again while some or all of the member variables are uninitialized.
These are two concrete examples from the project. The general case is "promoting/demoting at the 'wrong' stage runs behavior whose underpinnings are not constructed or already destructed". For instance: Hooking a display object into a display list that's interpreted by a periodic process running in another thread. If it's time to display while the object is under construction or destruction, and the promotion/demotion timing was "wrong", the display processing manger invokes services whose infrastructure are not yet constructed or already destructed.
With "correct" timing of promotion/demotion you can have an object that is always consistent, even if only partially formed. (Constructors and destructors, for instance, can have "stage of construction" member variable(s) that modulate(s) the behavior of other member functions depending on whether their underpinnings are ready, and this can be initialized to "nothing ready" before the object is promoted a
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Common Lisp declarations for type and optimization are part of the ANSI standard, and generally do the same thing across different compilers.
I was a CommonLisp user for many years and that's not true. CommonLisp had a lot of potential, but it never quite got it right.
Confusing - every mainstream language today except Java has them.
And even Java will soon. http://www.javac.info/.
Advice: on VPS providers
In the garbage collection case, either
1. The parent should not have been hooked to garbage collection before its members were contstructed
or
2. Garbage collection should be suppressed during a constructor
In the exception case, a constructor that is going to throw has the responsibility of cleaning up its members before it throws. When a constructor throws, the destructor is not run. If a constructor fails and exceptions aren't available, it should still clean up its members and set a flag to let the destructor know not to do anything.
For great justice.
In the garbage collection case, either
1. The parent should not have been hooked to garbage collection before its members were contstructed
That gives you the class-hierarchy doubling I described earlier. The "be collectible" flag has to be cleared by the final level of class derivation, which can not have further classes derived from it. This breaks the class paradigm by requiring you to distinguish leaf classes that can exist from their immediate all-but-collectible precursors which can be further modified.
or
2. Garbage collection should be suppressed during a constructor
Out of memory. Crash! Also all the leaf/stem problems if 1.
They both break the class paradigm another way: The garbage collectible behavior is supposed to be INHERITABLE. So it should all be encapsulated in the base class. Why are you forcing it to be moved to a derived level which has NOTHING TO DO with this behavior, just to work around an issue with the compiler's code generator?
In the exception case, a constructor that is going to throw has the responsibility of cleaning up its members before it throws. When a constructor throws, the destructor is not run. If a constructor fails and exceptions aren't available, it should still clean up its members and set a flag to let the destructor know not to do anything.
The problem is not the constructor throwing. Constructors know what they're constructing and can handle it.
The problem is a member constructor throwing. Does it have to understand everything that might contain it (including things that were written years later by a different team)? How can it do that? How can it do that without breaking the entire point of the encapsulation information-hiding paradigm?
What happens if something called by something called by something ... called by a member constructor throws. Now everything that throws has to understand how to unwind every layer between it and the object that catches.
If the promotion of the object occurs in the way I described as "correct" it's trivial to solve both these problems - and others - through the activation of the appropriate levels of the virtual member functions. If it happens otherwise they aren't readily soluble - and either aren't solved at all or aren't solved in a practical way by your suggestions.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Functors are a complete hack and should never be used. If you find yourself ever wanting to use functors or lambdas- you're doing it wrong.
Yes, that means the entire part of the STL dealing with generic functions is doing it wrong. They're unmaintainable code. THe correct way to do it is to write the entire loop as a separate function, or to embed it as a standard while/for/do loop. Templates should only be used for container classes.
The correct way to write your code is
I still have more fans than freaks. WTF is wrong with you people?
I see - you're one of those guys who, back in 60s, insisted that structured programming is a confusing idea that came out of academia and is therefore worthless for real-world programming, and that GOTO is perfectly readable. I'm not going to try to convince you otherwise - if you fail to see the obvious clues that things have moved on since hard-coded loops, it's your own problem.
Keep telling yourself that. In reality- nobody writing C++ uses functors. Nobody uses the boost lambda. ANd nobody wants to start, on either. It just isn't a readable method of programming.
I still have more fans than freaks. WTF is wrong with you people?