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)."
Nice name, chief. (Score:5, Funny)
I saw the headline and thought I was seeing some 1337 form of "cox."
huhuhuuhuhuh he said "form."
C#++? (Score:3, Funny)
Re:C#++? (Score:5, Insightful)
Because performance is important to some people.
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: (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: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:C#++? (Score:5, Insightful)
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.
Re: (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
Re:C#++? (Score:5, Informative)
Re: (Score:3, Interesting)
Re: (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 wri
Truer words have never been spoken. (Score:5, Funny)
C++ is to C as Lung Cancer is to Lung
Comment removed (Score:4, Informative)
Re:Truer words have never been spoken. (Score:4, Insightful)
True today as it was then; i.e. not true at all.
Re: (Score:3, Funny)
Nah, Stroustrup just decided to save time, so he's included the first buffer overflow in the language's name.
Objective C and C++ (Score:4, Interesting)
If anyone has used both Objective-C and current C++, can anyone tell me whether the new specification is a clear improvement on either if these?
I can. (Score:5, Funny)
Re:Objective C and C++ (Score:5, Interesting)
No, not really.
In fact C++ is barely managing to hold its own any more against C# and Java.
It's not that C++ isn't good, its just that its harder to do things in it then it is to do those same things in either C# or Java. Harder to do means more expensive, and businesses all over are having to tighten their purse strings.
I keep finding that for fast number crunching apps, C beats C++, and for less intensive work its usually easier to use Java or C#, or indeed python, then it is to use C++.
Also, its certainly true to say that in the UK C++ is not anywhere near as useful in terms of getting yourself a job as it used to be.
Re: (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 th
Re: (Score:3, Informative)
I still haven't seen anything matching it for real time stuff. Not that I wouldn't mind, at all.
But writing I don't think I've seen OpenGL code in another language that wasn't incredibly slow. Maybe that's just momentum, but regardless, it's still the state of things.
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: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: (Score:3, Informative)
Not to mention that C is not a subset of C++. The differences are minor and mostly subtle but they are there and they matter. For example, this trivial bit of very typical C code will not compile in a conforming C++ compiler:
char *x = malloc(10);
I'd suggest asking your "C/C++" interviewees to produce some code that's legal C but not legal C++. It will at the very least be amusing to watch them squirm.
Re:Objective C and C++ (Score:5, Informative)
Objective-C is essentially unrelated to C++ in every way. C++0x does not change this fact at all. Comparing the two makes just slightly more sense than comparing C++ and Prolog.
Re:Objective C and C++ (Score:4, Funny)
If you're writing C++, the spec is an improvement. If you're writing Objective-C, you probably don't care because you've already got a great language.
Also, you'll gnash your teeth because god knows how long it will take for apple to provide a compiler toolchain ( gcc? llvm? clang? ) which supports the new features.
On of the features: (Score:5, Funny)
"control of alignment"
I'd like chaotic good please
Re:On of the features: (Score:5, Funny)
I hate to be the one to break the news, but C++ isn't the only thing that's been revised recently...
LOL C++0x0Rz (Score:5, Funny)
Re:LOL C++0x0Rz (Score:5, Funny)
Re: (Score:3, Funny)
"C lets you shoot yourself in the foot. C++ lets you reuse the bullet."
Re: (Score:3, Insightful)
Early interview still more interesting (Score:4, Funny)
Just want to remind everybody (Score:5, Informative)
http://yosefk.com/c++fqa/ [yosefk.com] - this site says it all.
And it's also being argumentative and verbose at that, unlike your routine 'C++ sucks' rant.
Re: (Score:3, Interesting)
I looked at that, and at first it seemed, well, this is fair. A lot of these things are drawbacks, and it's pretty well laid out. Then I read into it a little further... and I really have to wonder. A lot of it is just WILDLY exaggerated. I mean, the author clearly tried to blow some minor problems up to ridiculous proportions. Some of the stuff in there is just absurd. Gems like this:
Re: (Score:3, Informative)
Your example uses a const std::vector<T> . He's talking about const std::vector<T*> , i.e. a const vector holding pointers. In such a case, you most certainly can modify the objects those pointers reference.
Fingers Crossed for Native Implementations (Score:3, Informative)
I really, really, really hope a lot of these things are implemented as compiler- or runtime-level features. I understand the purity aspect of implementing features as templates, but it just bloats my code and slows my compile times. A lot of the compile time for my apps is spent regenerating the same template crap over and over, then waiting on the linker to weed out what's duplicated. It takes forever.
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:Time for the C++ haters to post... (Score:4, Funny)
To be fair, the majority of complaints you hear about most programming languages on Slashdot are complete bull. People complain about the ones they don't like or don't know well enough and praise the ones they do like.
Once in a while you'll get someone who admits their pet language has faults and warts who explains why they use it anyway. On rare occasions, you might even hear someone say that a language they dislike has their language beat in some way or another. None of these are the rule, though.
Personally, I think of the C family of languages as an actual family... The patriarch C is somewhat portable macro assembly all grown up with some new tricks his dad never knew. C++ is C's little brother on steroids, complete with the unsightly rippling veins and man boobs. Java is C++ castrated and off the juice. Perl is the awkward bastard child of C and sed with a great skill for vocabulary but a wild of ADHD. C# is Java's soap-opera style evil twin. Objective C is C++'s hot female tree-hugging cousin from northern California who can't quite understand why the family always bickers and can't just get along. D kind of married into the family (probably to Objective C) and brought in a bunch of non-C things back to a style that suits C pretty well, even if he is a young punk. Cmm is the weird survivalist uncle none of C's kids, nieces, and nephews really want to spend time with at the holidays.
It's a pretty dysfunctional family, but on some level they all belong together. They're not as sophisticated as the Lisp family down the street. They don't coordinate as well as the Concurrents. The Pascal and Modula clan talks a lot more and is stricter with their rules. The C family just keeps getting useful work done, though, and that's why people keep coming back to them.
My primary language is Perl, but then again I'm an awkward guy with a gift for vocabulary and a wild case of ADHD. At least I know who my father is.
C++ has one major problem (Score:5, Insightful)
auto rocks (Score:5, Interesting)
The new "auto" declarations really fix one of the biggest gripes with C++. Everybody is dead tired of doing
std::map::iterator it = m.begin()
Now you can just do:
auto ip = m.begin()
It takes much of the pain away from static typing...
Re: (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 ;)
C++ is no longer a modern language (Score:3, Interesting)
C++ was once thought to be a language that was powerful enough that it could be used to express most features that other languages had. With things like operator overloading, multiple inheritance, and templates, you could pretty much make a class behave however you want. But years later, we have seen that C++ failed at that mission. There are simple and common OO constructs that C++ is unable to represent. Rather than focusing on improving the template functionality, I want the OO syntax fixed.
Let me cite some examples:
1) It is impossible to make a string class that behaves "normally"
Plenty of people have tried. QT, Boost, STL, Gnome, WxWidgets, all have their own string classes. Years ago, when VB developers touted how easy it was to use strings compared to C++, I told them it was merely because nobody had made a good string class. After 10 years of trying to write one, and using dozens of other ones people created, I realized that C++ is simply too weak and too loosely typed to do this.
Suppose I make a string class, kinda like the STL string:
string foo;
1) foo = "whatever";
2) foo = foo + "bar";
3) foo = 7;
4) foo = foo + 7;
5) foo += 7;
Take a look at these. The first one is no problem. That can call an assignment operator to copy the char * contents to the string. The second one can also be done with a + operator. The third one can also be done via assignment. But what if you forget that? Well, the compiler will see that as foo = foo(7) which will call the constructor that allocates 7 characters, and then assign that. So instead of the string "7" you get a blank string. The next example is a problem too. If the string class can be converted to a const char *, as is common, then does this mean to use the + operator on string and an integer? Or did it mean to convert foo to a const char *, then move 7 characters ahead, then assign it? That can result in a crash. This is because pointer arithmetic is intrinsic in C++, but it is inherently type unsafe.
Then how about a function that returns a string? A simple case in most languages, but in C++ it results in redundant copies across the stack. So people revert to funny things like auto_ptr and other wrappers, or complex mechanisms for doing shallow copies to prevent that. Other languages just avoid the problem entirely by not allocating things on the callee's stack. It's just an intrinsic problem in the old everything-goes-on-the-stack-by-default mentality of C++. It just doesn't always work.
Properties are another one. This is something that various libraries try to do, and is free in most new OO languages. But just cant be done in C++ // C#
class Foo
{
private int _x;
public int x
{
get { return _x; }
set { _x = value; }
}
}
So in the above class, I want to access _x via a property get/set. C# has a built-in construct for this. In C#, I could do:
MyFoo.x = 7;
MyFoo.x++;
MyFoo.x = MyFoo.x + 3;
MyFoo.x/= 7;
etc. The compiler knows how to get/set x, and it can even be inlined! This allows me to do things like log when x changes, or see what accesses the variable. Now, let's try that in C++.
class Foo
{
private:
int _x;
public: // Get X // Set X // Another way to get/set X
int x();
void x(int);
int &x2();
};
MyFoo.x(); // Gets x, no problem // Weird syntax, but that is fine // Does not modify the value of x, hmmm... //
MyFoo.x(7);
MyFoo.x()++;
MyFoo.x2()++;// Modifies x, but only lets you track the get, not the set.
MyFoo.x()/=7;// Same exact issue
MyFoo.x(MyFoo.x()/7);
Re: (Score:3, Interesting)
Properties are another one. This is something that various libraries try to do, and is free in most new OO languages. But just cant be done in C++
I never really understood this effort. What is so good about properties? Why is writing () after getter function name so hard? And for setters, setter chain is much less verbose anyway, like
mywidget.NoWantFocus().SetReadOnly();
instead of
mywidget.nowantfocus = true;
mywidget.readonly = true;
Why should any language look like Visual Basic?
Re: (Score:3, Informative)
Re: (Score:3, Informative)
The problem isn't that it c
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: (Score:3, Interesting)
I guess D is dead? Could have been a lot of hype but it sounded like the language you were looking for.
Wait a minute... (Score:3, Informative)
The C syntax is horrendous, the conversion rules chaotic
Bjarne Stroustrup, creator of C++, is saying that C has a horrendous syntax and chaotic conversion rules...
Hahahahahahahahaha.
Re:Interesting suffix (Score:4, Informative)
Yes. It's already been done once, aka C99. This isn't the thing that will replace C++, it's the next revision of the language, with multithreading support etc. Once C++ has worked out the hard stuff, C will have it's own next revision based on that.
Once everything's finished, it should be finalized as C++09. It may carry on another year, in which case you might call it "C++0xa" ;)
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.
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:I just don't get it.... (Score:5, Interesting)
Well, here's what I personally dislike about C++. You don't have to agree with them, but this is how I feel and I think it's how many other people do as well. Certainly when talking to people who prefer other languages over C++, they have expressed similar sentiments.
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.
Please note that this is just my opinion, and you asked for it. Feel free to disagree, but please don't flame.
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:Some counterpoints. (Score:5, Interesting)
Counter-counterpoints:
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.
Re: (Score:3, Informative)
Now you're just being unfair.
1. I found it pretty easy. Most Boost libraries are header-only so you only need to put the relevant header files in your project, adjust your header search path, and you're done.
2. Your example hasn't got much to do with C++, and everything to do with static vs dynamic typed languages. The C++ version will be about the same size as the Java and C# versions.
3. Uhm sorry, "real garbage collector" and "Python"? You do know that Python uses reference counting, right? Just like shar
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: (Score:3, Informative)
Well, something in the range of 99% of the desktop applications available on Mac OS X are written in a duck-typed true OO language.
I hold that the main reason that C++ is used so much for large desktop applications on Other Platforms is inertia, pure and simple. Programmers hate change. I realize that this is a purely a statement of opinion and I have no way to back it up.
Re: (Score:3, Informative)
It's the difference between being able to type "import", and having to search, download, compile, and pray. As for few modules being part of the language, every example I listed is built in to Python.
Re:Some counterpoints. (Score:4, Informative)
Yes, if C++ included the same libraries that Python does, this objection would go away. (Why wouldn't it?) The other objections would remain.
And no, GC does stop you from having to think about memory management. So-called "soft leaks" aren't a memory management problem, they're just a regular old code bug. GC doesn't save you from all bugs, or even from a particularly large number of them. It mainly just saves you from programming overhead.
GC also doesn't save you from having to manage external resources as that SafeHandle class does.
RAII is definitely not the design pattern I want. Believe me, I know what RAII is, and I know what I want, and the two do not intersect in any way.
I know it's hard to believe, but there are people out there who legitimately do not like C++. Not because we're stupid, or clueless, or because we've been misled, but simply because we have different constraints on our programming or even just different opinions.
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: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:Some counterpoints. (Score:5, Interesting)
It doesn't solve anything that *couldn't* be solved before, but that's not the point, as anything can be solved given enough time and effort.
But out of the box, without even any compilation needed(!) you can get smart pointer implementations, timers, asynchronous I/O, a multithreading toolbox, conversion libraries, containers, memory pools, and tons more (some would say so much more that its bloated) with the added peace of mind knowing that tons of people out there are using them as well and they are thoroughly debugged. Its worth it for the shared_ptr's alone- those alone dramatically reduce the biggest source of C++ bugs.
In my previous company, I worked on a system that was about 10 years old- started before the STL came into existence, and long before it was well supported by compilers, and thus the team had spent a lot of time building STL-like functionality with dynamic strings, iterator like functionality, vector/list work-alikes, etc. This meant that now once the STL came around, a programmer familiar with "standard" C++ had to learn how to re-do mundane things like string and container manipulation. Similarly, that team had created smart pointer implementations, logger classes, multithreaded and socket libraries, etc. Boost not only provides all of this functionality, but you get it working right out of the box, and since Boost is well known, you don't have to wait for a programmer to get up to speed for a month or two while he becomes familiar with your code.
There are some more exotic features that you don't have to use, but I recently used multi_index to implement what is more or less an in-memory database cache in about 100 lines of code. This replaced a lot of code that read records and then threw them into hash maps or vectors using the OrderId as a key, then the CustomerId as a key, etc... so we had fast lookups to our most commonly used objects.
What are its advantages over ACE? ACE is a great networking and concurrency library, which not all applications necessarily need, and ACE's strong point is multi-platform networking and concurrency, which while I wouldn't call a small niche anymore, can't be used across all applications. At least some of Boost's libraries, most notably shared_ptr, can be used in any C++ program. In fact, until Boost::asio was released relatively recently, I would say ACE and Boost were entirely complementary. Also, boost is more or less a testing ground for the C++ standards committee, so it is more or less "blessed" and can be seen as a Beta for future versions of the standard.
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.
Re: (Score:3, Informative)
Easy:
Re: (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 buil
Re: (Score:3, Interesting)
Twisted? I wasn't talking about a 68000 or a Palm. I was talking about an embedded microcontroller with a grand total of 32kB of RAM. About half of that is left to hold both program and data once the kernel gets done taking what it wants. Can you fit Python into 16kB of RAM for both program and data, and still have enough space left over to do anything useful? I'll be very interested if your answer is "yes", but I'm doubtful.
Don't get me wrong, I'm a huge advocate for higher level languages. But there are c
Re: (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
Re: (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
Re: (Score:3, Informative)
no, I think he meant a map where the value part can be any type, not just the one stated in the definition.
eg.
map.insert(1, "hello");
map.insert(2, 69);
map.insert(3, myobj);
etc. Boost::any is what he's after in that case so its a pretty moot point.
Re:I just don't get it.... (Score:4, Funny)
Error 2317 - Invalid analogy - no wheels. Bailing...
Re: (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: (Score:3, Informative)
And when it does, it's trivial to go in and write the speed-sensitive portions of the program in a faster language.
Agreed. Premature optimization is the root of all evil. Write the control flow in a high-level, easy-to-debug language, and later optimize the pieces running unacceptably slow by rewriting them in C. No object-oriented language with legacy holdovers, static typing, and gross syntax needed.
Despite knowing it is a fallacy, I will instruct by appealing to my experience: 27 years coding, 10 of that with a salary, and 5 years before that as an entrepreneur. I have forgotten more C++ than most people know, ha
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: (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
Re: (Score:3, Informative)
Read: http://www.amazon.co.uk/Modern-Design-Applied-Generic-Patterns/dp/0201704315 [amazon.co.uk]
It's a good introduction to modern C++. While the book itself is not really helpful, it gives you a nice overview of "modern" development techniques.
Re:It hurts you to learn C++ is still being used. (Score:5, Interesting)
I am not going to go read a book simply to settle an argument: you need to summarize here.
In particular, explain to me why his techniques are not generally applicable to other languages (or to Python or Ruby in particular) or why using those techniques or similar ones and interfacing to C when necessary actually provide a less efficient development environment.
I know C++ can be made "acceptable" as a high-level language through sufficient effort; I spent 7 years doing such a thing. I want to know why that's a better solution than using tools that are---out-of-the-box and without reference to a magic cookbook---ready to do the things that require months of development or dozens of third-party libraries to achieve in C++.
Re: (Score:3, Informative)
To summarize it, C++ now moves toward design which allows to catch more and more errors during compilation. But at the same time C++ provides tools which allow to write generic code.
Re: (Score:3, Interesting)
Yes, this sounds logical. C++ has only recently become interesting. C++0x back in, say, 1999, would have totally killed off Java.
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.
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)
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.
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:5, Interesting)
> I'm just positively amazed that Slashdot, in theory home of programmer geeks anywhere, should have such a violent dislike of C++.
Because C++ is not a pure language. It is a multi-paradigm language (imperative, OO and functional) with both a high and low-level language features and people seem to hate the aspect they which they don't prefer.
The close-to-the-metal types hate the high-level aspects and rather use C. Disregarding the fact, that changing the code from C to C++ is purely syntactical and runs without any detriment in performance. Exactly the prime idea behind C++.
The high-level people dislike C++ exactly for this approach. They don't like that the basics are so clearly visible, and are even the default. You have to hop through some loops, before you get to a higher abstraction layer. E.g. you have to use external libraries and/or special classes for memory management.
Personally, I like C++ for exactly that reason. I can start on a fairly abstract layer with pure virtual interfaces, smart pointer, signal slots and there is not a single (raw) pointer or a manual deallocation to see (or other manual resource deallocation).
Granted, it is more verbose than in a pure high level language, but that is what the machine has to do.
And if there is a performance bottleneck, I can seamless go down in the abstraction level from simple inline functions, over imperative functions with pointer arithmetic, down to inline assembler and can even guarantee a certain timing, if necessary.
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.
Re: (Score:3, Interesting)
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),
I work a lot with C++/Qt, but it's damn near that I want to say I program in Qt instead of C++. What's the problem with that? Well, I'm essentially lost if I have to work on a STL/WinAPI/MFC/wxWorks/boost/whatever project. Not in that I don't grok C++ which I do, but that I don't know any of the objects or functions or whatnot being in use. I do realize that there are differences between the libraries but certain basic functions should just be common, there's no reason why you'd need more than one string cl
Ha! Yeah right. (Score:3, Funny)
Those languages are way too high level. What you make up in development time will nowhere near compensate you for the greater processing time. I mean, CPU costs are through the roof these days!
But I have to say - even C++ is too high level. I hand code assembler with vi. That's what real number crunchers do.
Re:And Then COBOL 2009 (Score:4, Insightful)
Re: (Score:3, Insightful)
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: (Score:3, Interesting)
These are all very good points, particularly regarding RAII. I'm sure you know this already, but other languages such as Python provide deterministic resource management as well (in Python, it's the "with" statement). Java, along with C, seems to be one of the few languages that have absolutely no faculties for the RAII pattern.
Re: (Score:3, Interesting)
"Java, along with C, seems to be one of the few languages that have absolutely no faculties for the RAII pattern."
Really?
What about:
COBOL
FORTRAN
VB
Prolog
Lisp
ML
In fact any non-OO languages , given that RAII is an OO concept.
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 curi
Re: (Score:3, Interesting)
> I have been involved in developing code for simulating cosmic-ray acceleration in expanding supernova remnants, this in Python.
Well, Python is a different game than Java or C#, which both have a much better JIT-compiler.
I mainly program in C++ (real-time data processing), but I feel hard-pressed to believe, that Java has to be severely slower than C++ in numeric computations. The Java implementations of FFT [googlepages.com] and LinPack [shudo.net] suggest, that comparable performance should be possible. The SciMark 2.0 should also
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:Why not just call it C++#? (Score:5, Insightful)
Oh please. Pascal does everything C++ can now [freepascal.org].
Re: (Score:3, Funny)
Not to worry. As a result of the nuclear launches following the panic resulting from the 2038 Unix date rollover, the remaining cockroach hordes will not evolve sentience until at least 2105, thus avoiding the 2099 crisis completely. So it's all good.
Re: (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 shou
Re:Garbage Collection? No? BAH! (Score:4, Informative)
Re:To all the C++ haters (Score:4, Funny)
Please elaborate; I'd like to hate C++ more effectively.