Interview Update With Bjarne Stroustrup On C++0x 589
An anonymous reader writes "DevX interviewed Bjarne Stroustrup about C++0x, the new C++ standard that is due in 2009. Bjarne Stroustrup has classified the new features into three categories: Concurrency, Libraries and Language. The changes introduced in Concurrency makes C++ more standardized and easy to use on multi-core processors. It is good to see that some of the commonly used libraries are becoming standard (eg: unordered_maps and regex)."
Re:It hurts you to learn C++ is still being used. (Score:2, Insightful)
Try writing a large program that needs to do heavy number-crunching in Java/Ruby/Perl/Python, or whatever is your preferred language.
Re:It hurts you to learn C++ is still being used. (Score:5, Insightful)
Been there, done that.
Most of the time, the potentially reduced running time of the C++ implementation never comes close to the months saved in development.
And when it does, it's trivial to go in and write the speed-sensitive portions of the program in a faster language.
Re:Interesting suffix (Score:1, Insightful)
Re:And Then COBOL 2009 (Score:4, Insightful)
Re:And Then COBOL 2009 (Score:3, Insightful)
Why not just call it C++#? (Score:2, Insightful)
That's what this is... automatic memory management...bigger libraries... restricting pointers more and more....
I mean, C++ is evolving so badly it makes Pascal suddenly look a lot better as a compile time language.
Re:On of the features: (Score:1, Insightful)
Hopefully C++'s revision is better than the crapfest that is "D&D" 4.0.
Re:C#++? (Score:5, Insightful)
Because performance is important to some people.
I just don't get it.... (Score:5, Insightful)
...what do people find so difficult about C++? Use the standard libraries, exception handling, and make sure your news all have deletes, and it's no more difficult than any scripting language. I actually prefer it over scripting languages, which have their place, but feel all sloppy and unspecific. It's like the difference between building a house out of 2x4s and building one out of sticks you found laying on the ground.
Re:And Then COBOL 2009 (Score:5, Insightful)
I'll consider Java and C# as C++ replacements once they get:
These points are serious, especially the first, without real templates, generic programming/metaprogramming at compile-time is not possible. These two are one of C++'s biggest strenghts, though.
To be fair, C# 3.0 is somewhat nice, especially its functional core. Java is a totally uninteresting language with very small expressiveness. Of course, if the job requires it, there is no discussion, but in my spare time, I prefer C++.
Re:Why not just call it C++#? (Score:4, Insightful)
Trust your uncle Bjarne. If you don't use it, you don't pay for it. You need not worry that the language is turning into C# or Python. It's still just as efficient for bare-metal programming as C ever was (and more so in some cases, with template specialization at compile time).
As for 'automatic memory management', that was one of C's big features. Remember the 'auto' keyword?
Re:It hurts you to learn C++ is still being used. (Score:4, Insightful)
I've found that the biggest advantage for C++ is the portability. I have written an application backend for PC's (back in the days of DOS) and since then ported it through various versions of windows, Linux (for web use), Palms, and Pocket PC's.
Using C++ allowed me to very easily make the different processor needs, compatible, by writing little compatibility layers, which would swap bigend values, unpack data structures from disk into memory (so is on even boundary). and so on.
Yes the fast speed was why I originally went with the C/C++ route, but the big benefit has been the portability.
Re:It hurts you to learn C++ is still being used. (Score:5, Insightful)
...and roll on the C++-hatred! Second C++ article in a short time, and again lots of venom and anger. "Months saved in development"? Really? What are you doing, implementing your own OS before you start application development? Here's a newsflash: C++ also has support libraries, just like Java, Perl, Python and Ruby. They may not be part of the language specification (and I still think that's a weird idea to begin with, but I'm old-fashioned that way), but that doesn't mean they don't exist.
Anything you could want for in a modern language is there. And nobody is holding a gun to your head and making you write those scary templates if you don't want to.
I'm just positively amazed that Slashdot, in theory home of programmer geeks anywhere, should have such a violent dislike of C++. Not that there is nothing to criticize about it, but it is still an amazingly powerful, versatile tool that programmers anywhere would do well to learn.
Re:It hurts you to learn C++ is still being used. (Score:1, Insightful)
You are forgetting about the areas where everything is "unacceptably slow" by default. I.E it's never fast enough. (Real time A/V processing for example)
What is needed in those circumstances is a language that is both "close to the metal" and allows for inline ASM, but also lets you do OO on the structural level.
What are the options there? D maybe?
Re:It hurts you to learn C++ is still being used. (Score:4, Insightful)
And I can say with a straight face that you are wrong.
If you base your experiences on pre-2000s C++, you know very little of modern C++. I have been developing in it for more than 10 years, and a few years ago I would have agreed with you, but things have changed. Really.
Re:Why not just call it C++#? (Score:2, Insightful)
Uh, things like smart pointers have been a standard part of C++ for well over a decade. Way back when C++ first took off, a lot of people got it into their heads that it was just "C with classes", and that stuck around for a hell of a long time because of poor compiler support for the more advanced features. But seriously, you're working with a totally out of date concept of what C++ is. You're like the people who last used Windows when it was 3.11 and haven't updated their understanding of it.
Time for the C++ haters to post... (Score:4, Insightful)
We will see the usual litany of C++ hating here in this thread. The hating will be generally based around misconceptions or problems that are 5 years old.
So to get them out of the way:
If you're leaking memory or spending time managing memory in C++, then you're using C++ wrong. Get a book written in the last 5 years.
If you're worried about compiler compatibility (with the exception of export which isn't much use anyway), get a compiler written in the last 5 years.
If you think that C does some subset of your task better, then write it in the common subset of C and C++ and quit whining. Or, write it in C and link it against your C++ code and quit whining.
If you think that templates simply provide code bloat, then get a compiler newer than 5 years old.
If you think C++ is slower than C, then get a good optimizing compiler (you know one written in the last 5 years) and do a benchmark. You will generally find that templates make C++ faster.
If you think "modern" languages are more expressive, then give "modern" C++ a try (insert comment about recent compilers here).
Sure there are valid complaints about C++, but the majority of them I hear on slashdot are complete bull. The majority of the remaining complaints will be fixed by C++0x.
One remaining problem is the lack of a vast array of standard, business oriented libraries. I don't write business oriented code, and I find the C++ STL one of the best libraries out there since it provides really good support for writing efficient algorithms.
Another problem is the difficulty in parsing C++. Sadly that's never going away.
But if you're going to complain about C++ compared to recent languages here, make sure that you're talking about recent C++ too, and try to make sure the complaints are accurate.
Re:It hurts you to learn C++ is still being used. (Score:5, Insightful)
You do know that you don't have to screw around with any of that in a managed language, right? "Very easily make the different processor needs compatible" my ass--Java/C# do it on their own.
C++ has one major problem (Score:5, Insightful)
Re:C#++? (Score:5, Insightful)
If it was as good as it stands, then newer languages such as C# wouldn't take off.
Don't get me wrong, I love C++ and it's my primary programming language, but to say it's perfect as it is, is just silly.
Re:I just don't get it.... (Score:3, Insightful)
There is nothing preventing anybody from bad habits in coding and putting nails into own foot. Whether you use hammer or nailgun it makes your foot ache all the same.
Re:It hurts you to learn C++ is still being used. (Score:5, Insightful)
No, the "premature optimization" thing applies to all areas. Especially areas where it's never fast enough.
Why? It's simple: resource management.
You have X amount of resources to put into your product. X is always finite. It's kind of tough to measure X, but you can think of it as lines of code, man-years, or even just dollars. The amount of resources you have varies a lot depending on your budget, how much time you have, and the quality of the programmers you have. But the important thing is that X is always limited.
Now you have two approaches:
Paradoxically, I hold that #2 will produce a faster program. This is because the X you spend on making the program faster in #2 will be more effective, because you've already laid the groundwork for it. It's always difficult and time consuming to optimize code that doesn't even run yet. It's much more efficient to optimize code that already works. So the result, even though you spend less X on speed, is a faster program.
Think of it as transporting a lot of material into the wilderness somewhere. If you first spend some of your resources on building a road, you'll get the job done for less time and money than if you just start hauling stuff into the woods immediately.
To all the C++ haters (Score:2, Insightful)
You're doing it wrong.
Some counterpoints. (Score:3, Insightful)
1. Boost.
2. Nonsense. Boost has facilities for this ("any", iirc) and also for something called "sum" types which can achieve what you want in a better way ("variant", iirc).
3. shared_ptr, weak_ptr.
4. Yup. Going to be fixed by C++0x.
5. C++ can be written to be a lot more portable than your Ruby or Python.
6. A matter of taste.
Re:It hurts you to learn C++ is still being used. (Score:3, Insightful)
And I can say with a straight face that you are wrong.
If you base your experiences on pre-2000s C++, you know very little of modern C++. I have been developing in it for more than 10 years, and a few years ago I would have agreed with you, but things have changed. Really.
Citation needed. What is post-2000's C++? Please enlighten me. All of my professional C++ experience occurred between 1999 and 2006, conforming to the 1998 ISO/IEC spec sitting on my desk, with various modifications made for broken compilers (e.g., VC++6, the lack of support for the export keyword in any C++ compiler I've used, etc.). If there's a later "version" of C++ that is supported by gcc, I have not heard of it.
I did some C++ programming in high school and college, but didn't really dig in until 1999. From that point forward, I spent far too much time building tools---like the aforementioned refcounter, or utilities for atomic access to shared variables across threads---to make up for C++'s shortcomings. After some time, I realized that I was wasting my time and should switch to using a language that comes with these features built-in.
My advice to my junior colleagues is simple: use Python or Ruby (not so much Perl, because of its syntactic ugliness and hacked-up object and exception models) for the control flow, and interface to C when necessary, using open source, peer-reviewed C libraries with existing Python/Ruby interfaces wherever possible. You will not only develop code more quickly, and develop more reliable code with better failure modes; you will make debugging much easier for other engineers who will inevitably have to dig into your code later.
Re:C#++? (Score:3, Insightful)
The day when McDonalds can get away with requiring MS CS, MS EE, AND get an abundance of qualified applicants for fry cook positions is rapidly approaching.
Goodbye helloworld.c, hello wantfrieswiththat.cxx
Re:Some counterpoints. (Score:5, Insightful)
Boost has in many eyes really transcended from "just an external library" to an integral part of the C++ platform. It compiles on every major platform, and it is open source.
Boost is moving C++ forward at a rate 10x that of the standards committee. I am not sure why you felt integrating it with your project was difficult- it is header only for the most part and does not require you to use any specific pieces. Shared_ptr's, which are the most useful library of all, do tend to be viral in the sense that you have to use them everywhere, but this is a GOOD thing.
If you are doing C++ without Boost these days, you are really missing the boat.
Re:It hurts you to learn C++ is still being used. (Score:4, Insightful)
There are vanishingly few programmer geeks left on slashdot. Most of the "programmers" here, these days, are folks who've written a few scripts or set up a movable type install.
There are a few real programmers left here, but they're lost in the noise. You know, the roaring noise made by the python and ruby folks.
This post brought to you by a C++ programmer who happens to love Python and Ruby ( and javascript! it's an amazing language ), but uses the different languages where appropriate.
templates... (Score:3, Insightful)
I used to think like that, but then all the things you talk about are just syntactic sugar. There is nothing you can do with proper generic that you can't do in Java or C#. Yes, C++ is way more expressive than almost any other language, but that is also its peril.
And when was the last time you used meta programming to solve a concrete problem that could not be elegantly solved otherwise.
Most people learn how to calculate a factorial using meta programming techniques and stop right there. It's more of a curiosity than useful practical technique.
Re:Time for the C++ haters to post... (Score:1, Insightful)
And now, back to reality where some of us actually have to work with C++ for a living every once in a while...
From professional experience, C++ is unportable, the compilers (still) suck (which is no wonder when you take the complexity of the language into account), simple code always ends up being complex, compile times are worse than ever and C++ still has no data hiding.
Speaking of C, no C doesn't do a subset of my tasks better. C does all of my tasks better than C++ could ever dream of.
BTW, I like your oxymoron of having "good" and "C++ compiler" in the same sentence.
Also, you do realise that portability means that the code has to work on all C++ compilers, right? You can't just go and tell a customer "sorry, your compiler is not the latest alpha version of GCC, go away."
It becomes even more hilarious by the fact that any version of GCC released in the past 5 years, as you seem to recommend, explodes in your face on every oppurtunity and leaves you with hard to find wrongcode cases.
In fact, you've said nothing which hasn't been said 5 years ago. Or 10 years ago. The fact is that C++ is still not a usable language, and I somehow doubt that it will ever be one. It's time to throw it out and start over (or just avoid it like the rest of us do)
Someone already linked to the C++FQA. The problem is that it'll easily take half a day to read it, and most C++ fanatics just jump on one chapter and yell "OMG WTF HE WANTS GARBAGE COLLECTION WHAT A MORON" and then dismiss it and go back to padding themselves on the back about how good C++ is.
Anyway, enjoy your mess of a programming language. At least it gives me job security by providing a never ending source of completely broken code to fix.
Re:Objective C and C++ (Score:3, Insightful)
The more I look at it, Java's Just in time compiler is just about as fast as C++.
The biggest difference tends to be how you program.
When you really learn to program OO, you tend to create many small objects that outlive the object that created them.
In C++, that would mean running thousands of mallocs a second, and having some other random (arbitrary) object delete them later.
That's not the way to code C++. Since you are constantly required to think of object lifetime, you usually have an object die with the method that created it. When you are doing that, you can put it on the stack instead of allocating it on the heap. Stack allocations tend to be much cheaper because there is no deallocation.
But if you actually coded C++ OO, not caring where objects were destroyed, keeping many more small objects around, etc, your performance would be as bad as Java or worse.
For something that doesn't allocate at all--well a simple test was just created on Cedric's weblog that compared a good algorithm in different languages and C++ couldn't match Java's performance until it was compiled with -O3.
For java, apps just keep getting aster (even for programs that have already been deployed). To increase the speed of a deployed C++ program, you need new hardware.
A VM system CAN BE superior to a compiled one in every way since it can be compiled to exactly the same (or much better) assembly code if the VM determines that would be best. Not sure why this whole speed thing keeps coming up. When I see a Java program written to avoid memory allocation, it tends to perform almost exactly like it's C++ counterpart.
Re:I just don't get it.... (Score:3, Insightful)
Flexibility. In C++ it is essentially impossible to make, say, a dictionary where each key can refer to an object of a completely different type. This is what you refer to as "sloppy", but I actually find this flexibility to be essential in designing good software. The fact that C++ does not allow it forces me to either twist my program's design in unnatural ways to fit the language, or do a lot of extra work to twist C++ to fit my program's design.
If you're not offended by the idea of using the Boost libraries, the boost::any class will let you be sloppy like that.
Manual memory management. In any complex program, balancing your news with deletes is not as simple as you make it out to be. Object ownership is a tough problem. Lots of C++ code solves this problem by making a lot of defensive copies, which in turn hurts performance greatly.
The boost::shared_ptr class has changed the way I write C++ code. It's a header-only class, so it's possible to only include it, and nothing else from Boost, in your project.
Readability and writability. With all the type information being declared all over the place, big template declarations, and the like, I find that C++ takes considerably more effort to both read and write.
I have found that wise use of typedefs can hugely improve readability and writability. On the other side of the coin, some people go overboard with typedefs, essentially making worse the problem they originally intended to solve. Like code formatting or any other convention, it has to be used where it makes the most sense. (Avoid developers with hammers who think everything is a nail, or needs to be turned into a nail, so they can hit it.)
For example, I find this to be quite readable and writable:
typedef std::vector<SomeHairyClass> SomeHairyList;
typedef std::map<CuddlyKeyClass, SomeHairyList> HairyListMap;
HairyListMap foo;
Saying all that without some judicious use of typedefs would of course be nearly unreadable, especially if later you have to make use of iterators and nested types in the vector or map.
The really big issues for me are the flexibility and the lack of libraries. The rest is less important. But with C++ it's like building a house out of 2x4s that you're not allowed to cut to length, whereas with moer modern languages it's more like building a house out of prefabricated rooms, with a ready supply of 2x4s and tools to shape them as you need if the prefabbed rooms don't fit your needs.
On the contrary, I find that C++ gives you all the 2x4's, wood panelling, nails, screws, and all the tools you need. You just have to become a half-decent carpenter before you can start building your house. It's just a little bit harder to quickly make working prototypes (build a home from prefab parts), but as you indirectly pointed out, there are plenty of other languages that are better suited to that building style. The right tools for the right job.
Please note that this is just my opinion, and you asked for it. Feel free to disagree, but please don't flame.
Duly noted, just adding mine to the discussion. :)
Re:Garbage Collection? No? BAH! (Score:3, Insightful)
I want to like C++, heck, it was the first language I learned. But after so many hours of memory leaks and pointer-induced errors...
perhaps you didn't learn it very well. Check out RAII [hackcraft.net] for one way round your problem, learn about references and destructors for another, and learn about auto_ptr/shared_ptr if you still have difficulties.
If you absolutely must have a GC, put one in [hp.com]. Mono uses this one, so I assume they think its quite good. Stroustrup says that GC has a place in memory management, but it should be the last resort not the first. I agree - if you can't program without getting so lost you lose memory all over the place, GC will not magically help you* as you'll end up losing track of other non-memory resources instead**.
* - unless you're an ex-VB programmer, in which case you need all the help you can get :-)
** - eg. you create an object that opens a file, if you 'leak' that object, the GC will collect it for you when it feels like it, so you may end up trying to reopen that file only to find that its still in use. There's still 'soft leaks' that the GC will not manage where your objects are still referenced even though you think they aren't.
Re:Objective C and C++ (Score:5, Insightful)
Generally speaking, I agree with your post. However...
That's a really, really awful way to think about C.
C has a completely different set of best practices and design principals; anyone who puts "C/C++" on a resume I'm reviewing loses points as opposed to listing them separately.
Re:C#++? (Score:4, Insightful)
"MBA's will not need programmers anymore, so we'll be able to code OSS full time!"
You realize that is what they said when they introduced COBOL, right?
Re:Ha! Yeah right. (Score:2, Insightful)
Re:It hurts you to learn C++ is still being used. (Score:2, Insightful)
I'm just positively amazed that Slashdot, in theory home of programmer geeks anywhere, should have such a violent dislike of C++.
There are at least two ways to interpret that:
Now, "most popular" isn't automatically the same as "best", or else McDonald's make the most delicious hamburgers. Still, if a huge crowd of people who at least hypothetically have experience with the subject matter tend to have the same opinion, perhaps there's something to it.
Not that there is nothing to criticize about it, but it is still an amazingly powerful, versatile tool that programmers anywhere would do well to learn.
It could be that we learned it, cringed in horror, and went back to our more expressive dynamic languages. I have no fear of programming to the metal, but I bought a computer so that I don't have to deal with all the low-level gruntwork on a daily basis. There's nothing more powerful or versatile than raw machine code, but there's a reason why most of us use something else.
Re:C#++? (Score:3, Insightful)
It's not that people think that's the only use for them; it's that that's the killer use.
It's a lot easier to persuade people to learn a new feature by saying "this will make your life easier" than by saying "this will let you write better code". Most people don't care how "tight" their code is, as long as it works. What they care about is how easy it is to write and maintain.
Re:Why not just call it C++#? (Score:5, Insightful)
Oh please. Pascal does everything C++ can now [freepascal.org].
Re:Some counterpoints. (Score:5, Insightful)
First off, if you have a problem with using external libraries, then you just won't get anywhere with a C/C++. They are VERY general purpose, and intentionally so, and the whole idea is that implementation specific things are supposed to be provided in libraries, rather than the core language. That said:
1. Boost is actually very easy to integrate for most of its features. A few (small handful) of its components require compilation, but the vast majority of them are template-based and header only. Meaning just include a header file and there you go, you're using boost. No extra compilation/installation required.
2. This kind of thing is GREAT for doing small scripts, but HORRIBLE for doing large complex applications where type safety can be VERY important for avoiding bugs. If all you ever do are small, quick, limited scripts, then you're absolutely right that you should avoid C++, that's certainly not what it was meant for, and not so much the domain of a strongly typed language. For things like the software that runs large financial institutions and whatnot, there's a reason code like that should be avoided at all costs.
3. I have trouble imagining a situation where a real garbage collector would ever be superior to an RAII model with shared smart pointers for stuff allocated on the heap, outside of plugging up a leaking legacy app. Maybe for very simple programs, but once you get non-trivial destructors (for example, with objects that lock system resources), then you start having to do manual memory management in your GC environment anyway, and end up with a horribly ugly conglomeration of "mixed metaphors" as it were. Smart pointers really give you the best of both worlds: deterministic destruction, without having to worry about manually releasing anything. It's just a matter of getting used to declaring a smart pointer wherever you would have a "type *name" instead. So yes, I'd argue they ARE a substitute for garbage collection in almost any situation.
4. Sorry to be blunt, but you should probably RTFA on this one. The problem is solved through "concepts," which is the part of the new specification which deals with this specifically. It's essentially a C++ implementation of the "design by contract" metaphor.
5. In this case "can be" equates to "do whatever you like and it'll be portable on all major general purpose computers, and who uses Ruby or Python on embedded platforms anyway?" If you are able to compile with GCC, which is the case for pretty much every computer/OS combination in existence, then you can count on it being pretty damn portable. If you are programming for something like an ATM or a set-top box, then you probably aren't going to be using a high level scripting language anyway.
6. Yeah, it can get ugly. Thankfully this will be largely fixed with the "auto" keyword in C++0x.
What tool is better than C++? (Score:3, Insightful)
I also have an extensive experience with C++, and I tend to agree with a lot of the criticism that it gets.
But the problem is that no alternative exists for the type of problems where C++ is used extensively. I guess the most important area is games.
The world really NEEDS a language (the last low-level language) with the low-level performance of C++/C and with a full, modern library, and modern language features (threading, modern module system (not based on #includes and a crude preprocessor...), optional strong typing system a la Ada with optional runtime-checking etc etc etc.
Basically, a really nice, compiled, well-performing, modern low-level language could easily exist. But it doesn't. So we'll have to settle for C++ until someone makes something better.
Re:Some counterpoints. (Score:5, Insightful)
It is the discussion. Judging c++ with boost excluded is like judging perl with CPAN excluded. Who cares whether it's "part of the language" or not? Everyone who uses the language seriously uses them, and they're critical to understanding how the language is used effectively.
Re:LOL C++0x0Rz (Score:3, Insightful)
An interesting thing is I have written some highly structured code in some rather low level languages. To do so required a skilled architect and an agreement between developers that we were going to honor the rules, even if the complier did not punish us. It can be an expensive way to develop, as competent computer people costs money, which is why it is often more economical to allow the complier to do the thinking.
Re:Some counterpoints. (Score:4, Insightful)
Again, I don't think I'm being unfair, I'm just saying why I use what I use. Python provides more libraries for the stuff I use than C++ does. "Batteries included" makes my life easier. Maybe this isn't fair to C++. So what if it's not? Should I make my life more difficult by using C++ out of a sense of fairness?
As for GC goes, no, it's not "just another memory management aid". Non-GC versus GC is the difference between having to think about memory management and not having to. Automatic refcounting still forces you to manually find and break reference cycles, and garbage collection does not.
Re:C#++? (Score:5, Insightful)
Re:Some counterpoints. (Score:3, Insightful)
For 32KB systems, I would recommend either absolute assembler, or program conversion - higher order to lower order (subset Scheme to assembler, and possibly TinyScheme). Even C is excessive, but possible. C++? Unless you have absolute control on template production, I would doubt it.
Simply because using the STL and making a SINGLE type change can result in inclusion of thousands of bytes of code (as the templates instantiate). Example: modify a short vector to a long int vector on the platform. The machine code will now have to include math libraries, and all the overhead of instantiating. Easily 30KB, which then blows out your 16KB deliverable.
And, it isn't possible to put source level checks in place to prevent this.
Yes, C is a "high level" assembler (low level language), but is better suited for this type of development. Now, the code being targeted at this platform typically DOES NOT HAVE TO BE PORTABLE. Normally, every byte has to be accounted for anyway, making absolute assembler very practical. None of the higher order C++ constructs are useful, because abstraction is simply not a consideration on these platforms. C is useful, because it is easier than learning yet another assembler. Scheme can be useful, because it is easy to generate a subset compiler yourself to the target platform. (more people can do the Scheme, than can successfully generate a C compiler).
Back to "portability": In this space the following code would make a lot of sense, and is considered "portable"
#define BASE 0x7000 ... ...
#define STATUS (BASE+1)
#define READY 0x0001
#define NOTHING
char *status = (char *)STATUS;
while ((*status & READY) == 0)
NOTHING;
(but there is no timeout implemented, this was just an example).
My CV in this area: biometers, micro-controllers (SCSI, other), heads-up displays, etc. And with ALL systems in the 64KB and less capacity, I have NEVER been asked to do C++. Nor have I ever recommended it. I would be curious if there have been success stories in this particular space.
Re:Objective C and C++ (Score:4, Insightful)
Nothing else in your post either supports, or even directly addresses this assertion.
This is the same bullshit that's trotted out there every time this topic comes up, and it's no more true now than it ever was, which is not at all. If you do a little looking around, you'll find very elegant libraries that support every single feature you'll see in ANY other imperative language, and MANY declarative language features to boot. If you're against code reuse and third party libraries on some sort of general principle, then you're kinda missing the whole point of C++.
I'll be blunt, maybe an ass, maybe a troll, but having used all three of those languages extensively, I can say with almost absolute certainty that the only reason you should be having so much more trouble doing things in C++ (ESPECIALLY as compared to those two languages) is that you're either a very poor C++ programmer or have a pathological aversion to third party libraries.
Another thing that's been very much in the vogue to say lately, but I just haven't seen any meaningful evidence for. I think Bjarne covered this topic fairly even-handedly in TFA, and if he's to be believed then C++ usage is not suffering like popular belief seems to indicate. The crux of it being that web scripting was never a strong domain of C++ in the first place, and in actual applications programming C++ is still the leader of the pack.
Re:auto rocks (Score:3, Insightful)
std::map::iterator it = m.begin()
That'd be "map<signed short int, unsigned long int>::iterator it = m.begin()". And you can write "using namespace std;" instead of "std::", saving a net minus 15 characters ;)
Re:Some counterpoints. (Score:3, Insightful)
d = {"name":"Bob", "age":42}
print "Name is %s and age is %d" % (d["name"], d["age"])
Keep in mind that this is a complete python program, no further code is required.
So you don't count the Python runtime as further code?
These types of examples are meaningless. Any programming language can implement the same functionality, they just use different syntactic sugar to do it. So great, Python allows you to define a dictionary in a single line of text. Doesn't mean you can't define a dictionary to do the same thing in C++, it is just the form looks different.
But notice that in your language, you had to know that d["age"] is an integer and d["name"] is a string when you built your print method (%s, %d), where as in C++ you could do:
std::cout << "Name is " << d["name"] << " and age is " << d["age"];
So does that make C++ better than Python because I the programmer don't have to worry about a which format flag to use? No. Each language offers different types of simplifications based on what the design requirements for the language were. You like Python because you like the language simplifications it provides you. Nothing wrong with that, use what you like and what works for you. But just because another language doesn't provide the same techniques you like in yours, doesn't make it a worse language. It makes it different.
The bigger point that was made higher up is that C++ lacks the comprehensive consistently available libraries that Java, Python and C# developers get to depend on. Those others should be more viewed as environments for a language, versus C++ which is truly just a programming language.
Were there to be a common, consistent library for C++, available on all platforms, such as what exists in Java or Python, then C++ developers could have the level of productivity you enjoy from the tools you use and then we would have a good basis for comparison.
Re:C#++? (Score:3, Insightful)
Well that's just it, C++ is designed to be as general a language as you can manage (which is why so many people don't "get" it or complain that it's complicated because not much is done for you in comparison to other languages) which is why other languages may be better suited to certain tasks.
The example you gave for C# is a pretty good one, but it still highlights that there are areas where C++ isn't well suited to certain tasks and until it is, it's fair to say there's room for improvement.
Thus I welcome any improvements to the language, especially as Bjarne certainly seems to know what he's doing.
Re:Truer words have never been spoken. (Score:4, Insightful)
True today as it was then; i.e. not true at all.
Re:It hurts you to learn C++ is still being used. (Score:3, Insightful)
Kay can say anything he likes, but he did not invent the first OO language - it was Simula 67, also a statically typed language, and OOP in C++ has very visible roots in Simula (dot-notation to access members, "virtual" and "protected" originate there, for example; but in general, the very concepts of classes with methods and fields, combined interface/implementation class inheritance, object instances, special syntax for message receiver in a method call, object identity, object references and null, upcasting and downcasting, explicit polymorphism via virtual declarations and overrides, controlled encapsulation by means of visibility levels, etc).
Re:C#++? (Score:4, Insightful)
If you make language even an idiot can use, idiots will be using it. Like with VB.
So lets make the language as difficult as possible. That way only good programmers will even be able to write code in it. Never mind the fact that they'll have to spend all their mental effort getting the code to work instead of focusing on the problem they're trying to solve.
The fact that an easy versatile language makes it easy for idiots to program in it is no reason to artificially make a language overly complex. That's insane. It's like making a hammer that requires a PhD to use just to prevent bad handymen from doing handywork.
In other words plenty of good code was written in VB by non-idiots who didn't want to focus on the language but had a practical problem to solve. You can leave the morons to survival of the fittest.