"Finally, which version is likely to be the most efficient? Yes, the C++ version, because it does not have to count the argument characters and does not use the free store (dynamic memory) for short argument strings."
I just compiled the C code and the C++ code using:
gcc -std=c99 -Wall -Wextra test.c -o test
g++ -std=c++11 -Wall -Wextra test.cpp -o test
This is the archetypal problem with benchmarks: not only are they hard to design, but people will incorrectly nit-pick the results.
You count the number of allocations, without looking at the big picture: this is a toy example. It provides the hard-coded input to the function. This results in the C version not having to allocate memory for the hard-coded literals and the function problably being inlined and optimized away and the strlen() calls being equally optimized away as the length of the strings are known at compile time.
In the real world, these would come from some input where they would need to be allocated on the heap, just like the C++ version does. It would use just as many allocations, except they will all be hand-rolled, hand-held, error-prone, with every bit of memory management explicit. C++ is superior in every measure here. Only in toy programs and hard-coded strings does C wins.
If the goal was to have as few allocations from hard-coded strings, then just write "foo@bar" and avoid the concatenation altogether. That is not the point of the example.
(Also, the newer C++ standard support std::string literals, FWIW.)
The articles promise is actually terribly dubious. Firstly, in the real world, name+'@'+domain is likely to exceed the capacity for any SSO anyway. Even the example composition, which is 21 chars, may resort to heap allocation under some implementations. It's a bad solution to depend on it for performance.
Secondly, as you discovered, the current GNU stdlibc++ implementation of std::string will always allocate for short strings. Even 1 byte. This is for binary back-compat and will hopefully be fixed in GCC 5.0. For now try it with Clang and libc++. See[0] for more information and a comparison of current implementations.... the standard doesn't require SSO at all.
Thirdly, and getting to the deeper issue, once the heap is involved the C version is nearly (it needs length params) optimal and will still always be more efficient than the C++ code. Why? The C++ solution uses uses operator+ which is fundamentally performing a different and less general algorithm. For composition it will introduce some amount of repeated work which even the best link-time optimizing compilers probably won't remove, and may, depending on the length of the trailing string segments, and the growth strategy used under the covers, force two allocations. The standard doesn't give complexity guarantees for mutation on std::string at all, so the resulting performance could, on some platforms, be very bad. In all cases you will be able to construct an input that forces more than one allocation (exponentially growing segment sizes).
There's also another efficiency issue in the naive op+ approach... C++s allocator specification doesn't provide realloc() so a portable solution will always use more peak memory, on average, when it is forced to reallocate.
The C++ solution is just using the wrong algorithm for the job. You can write, and I have toyed with[1], a variadic strcat() function that will be optimal in the generic case. The standard library just lacks one. It's embarrassing, but fairly understandable given that variadic templates didn't come in to the standard until 2011. I'm hoping if they introduce one it'll be called scat() :-)
I'm a big C++ fan, but we shouldn't be deluding ourselves here. Fortunately, these things can be fixed within the framework of the current language.
To paraphrase Don Knuth, "I have only proven it correct, I haven't tested it."
To be fair, he says "likely to be" and results may vary between compilers. He also makes reference to the speed penalty of calling strlen(), which isn't necessary with std:string because it stores the length. Even with more allocations, it's possible the C++ version runs faster. It should have a lower computational complexity, meaning it would be faster if the input strings were much longer than they are in this example.
In my experience, C++ compilers are great at eliding temporaries and various constructor calls (and related memory allocations), but only if optimizations are turned on.
I'm looking forward for the next part, as the last three myths are the ones I'm waiting for their answers, as they should be pretty interesting.
C++ has come a long way, and I really feel C++ 11 could very well replace Java as a learning language for computer science students (I don't think it'd be a good choice for an introduction to programming for non CS students), and I see many benefits in this, the biggests being IMHO C++ NOT being fully object-oriented, and the possibility to do either low- or high-level stuff, depending on what you're teaching.
My biggest issue with most garbage collection implementations is the lack of RAII. While I love the ease of reading and writing Python or Lua, I'd love to be able to create a local object, like an open file or a database connection, and have it destructed immediately on return.
What sort of C programmer wouldn't use snprintf to do the formatting? If the C++ program can use std::string then it's only fair to let the C program import <stdio.h>. And honestly printf is so much nicer to use than iostreams I've always considered the relative ease of putting together a formated string one of C's strengths relative to C++.
I like C++, but using it to teach beginners who have no knowledge of C or compilers in general is a horrible idea. My college CS101 course was taught using C++, and I was lucky because I already knew multiple programming languages before that.
1. There are a lot of abstractions in C++ that make it very powerful, but the reason those exist would be completely lost on a newbie. Pass-by-reference vs. pass-by-value? Oh yeah, there are pointers too that you might run into, that's almost exactly like a reference but with a different syntax. We have smart pointers instead to obscure that from you, but if you search for examples online you might run into any of these. But don't worry about all of this; these language features only exist because of type safety and performance which you have no clue about. Just change the syntax until it compiles and runs.
2. Programming is more than write->compile. Debugging is as important, if not more, and heaven help you if you're a beginner trying to debug C++. With C you'll at least get exposure to machine code that pretty much looks like the program you wrote.
3. C++11 is an improvement, but it's not ubiquitous and it adds abstraction that someone without a solid C/Assembly background will have very little chance of understanding.
Teaching C++ to someone with a firm grasp of C would be a lot easier and additive. "Here are the new features that can help the compiler make your program more performant or type-safe or fix your memory leaks." Otherwise you're throwing a bunch of solutions at students to problems they've never had.
It is the end of 2014 and I am using C++11 on Windows, OSX and Linux without too many incompatibilities. Of course, you need the latest versions of the compilers but it's ubiquitous enough.
I'm getting so tired of the word myth and how it's used so incorrectly. These may be misconceptions, but they are not myths. In truth, some of these are factually accurate and you're framing them as a misconception to drive a narrative. I can't help but consider that link-bait, even though structured differently, this would be a good article.
First, which of the "myths" are "factually accurate" and in what sense?
Second, I don't find his use of "myth" objectionable, in much the same way I (as a scientist) don't find objectionable the use of "theory" to mean "guess" in non-scientific speech (attempting to impose "guess" as a meaning when discussing scientific theories is anathema). This use of "myth" here is fairly common, at least colloquially in America, as a rhetorical flourish in place of "misconception."
Does anyone choose C++ anymore unless it is required by environment/legacy/performance constraints?
Back in the day I read Bjarne's book cover to cover, used C++ for very large scale projects, and was one of those guys who could make sense of arbitrarily complex pointer expressions.
Now I mostly regret it. Led down the rabbit hold of multiple inheritance, STL being much more complicated than templating in other languages, and watching devs take years to master all of the subtleties.
He alludes (next article) to garbage collection not being more reliable than manually memory management? Yes GC has it's own disadvantages and there are many ways in C++ to mitigate memory management problems, but seriously I wish I had a dollar for every hour of time spent on a memory allocation bug in C++.
I still use C++ because it not only allows me to write high performance code, but also allows me to easily express high level ideas without worrying about too much overhead. I can write generic algorithms in terms of monoids and semigroups and I can write device drivers. I do a lot of signal processing at work, so sometimes these high-level and low-level concepts exist side-by-side in the same codebase.
Edit: I should mention that by no means to I think C++ is perfect. Very few other languages, however, give you the amount of low-level control, and the tools to build cheap, powerful abstractions, like C++ does.
> Does anyone choose C++ anymore unless it is required by environment/legacy/performance constraints?
At work no. Typical enterprise world using JVM and .NET languages.
For side projects, surely yes!
It is the only language supported across all mobile OS SDKs with full access to the hardware.
If you have control over the codebase, the ability to use C++11/14 is quite comfortable, even in terms of memory management.
Now for the typical enterprise projects, with offshore developers at work I wouldn't use it. I already cry when I look at code written in less powerful languages.
Couldn't you say this for any language? As soon as you start applying it to larger projects things start to get more complicated. It's not the same problem per language, but each has their own issues.
Thanks. Very short post though. What I have to say is, that C++11 and onwards had indeed made C++ much more approachable. I think Herb Sutter's talk on modern C++ is also worth a look. [0]
Good luck trying to understand C++ without C. The numerous C++ traps and pitfalls will just look mad to you.
BTW, 'multi-paradigm' is an oxymoron. Not even Scala uses that concept any more.
look at it this way: suppose some alternate universe where there is no such thing as C, it just doesn't exist, nobody ever heard of it. Why would you not be able to completely master C++ that universe? The traps and pitfalls which you consider C, would then just be known as C++ (just as in reality they are C++ now, maybe not just always named as such). I think that's one thing what's being advocated here.
Anyway, what traps do you have in mind specifically?
What's a paradigm? It's a way of viewing things. What ways are there of viewing programming? Well, there's functional, there's structured, there's object-oriented, there's generic, and maybe some more.
Can C++ be used to write non-object-oriented, non-functional, purely structured-programming-style procedural code? Yes, it can. (Essentially, that's the subset that's in common between C and C++.) Can it be used to write object-oriented code? Certainly. Can it be used to write functional code? Again, yes (though not nearly as purely as the Haskell zealots would like - but C++ doesn't enforce the purity the way Haskell does precisely because C++ is multi-paradigm). Can C++ be used to write generic code? Yes. (I have heard that the STL was written in C++ because, at the time, it was the only widely used language that would do what Stepanov wanted to be able to do.)
Four different paradigms. You can write C++ code using any of them, or you can mix and match. That's multi-paradigm.
Or are you arguing that, if you have more than one paradigm, you don't have any? That might be true of a program, though I think that the argument is merely a matter of definition, and therefore not very interesting. But if the language makes it easy to write in several paradigms, it seems perfectly appropriate to call it multi-paradigm.
Linus has ported his Subsurface project to Qt, thanks to the current state of affairs in Gtk, so I imagine he might be a bit more welcoming to C++ nowadays.
A major problem with C++ is a lack of consistency, which you run into if you start trying to generalize the ideas presented in this article.
The article demonstrates string concatenation using +. That is great! Except it's inconsistent. The article's example works fine, of course:
return name+'@'+domain;
I'll skip over the weird use of '' instead of "". Now let's say I want to prepend mailto: as well:
return "mailto:" + return name+'@'+domain;
So far so good. But I think it might be clearer if the colon was separated out:
return "mailto" + ":" + name+'@'+domain;
Oops, this no longer compiles. Hey beginner programmers, let's take time out from the arduous task of learning basic programming to understand what a const char * is and how it differs from const string and why you can + two strings or a string and a const char * or a const char * and a string but you can't + two const char *s.
The next example demonstrates initializing a vector:
vector<int> v = {1,2,3,5,8,13};
This is great, of course. The example after that introduces "auto" so you don't have to write the type of a variable. Well heck, let's combine the two!
auto v = {1,2,3,5,8,13};
Kaboom. Oops. You can use auto, or you can use {} to make a vector, but you can't do both at the same time! OK, beginners, let's take some more time out from learning what you came for and instead learn about the complex machinery that handles initializing a custom type with {} and why "a = b" can do arbitrarily complex things depending on the types of a and b.
I had a job in college tutoring students in my CS department's first-semester programming course, which was taught in C++. People would routinely come in with code that wouldn't compile because of some tiny mistake, but which produced literally pages of error output. There was no way for new students who were still struggling with the concept of a loop to figure out what they were doing wrong, besides finding somebody who had already been through it.
This was a long time ago, and C++ has improved, especially in the error message department. But these problems are still there, even if somewhat diminished, and other languages don't have them.
The fundamental problem with C++ is that it grew organically from humble beginnings without any apparent plan. This allowed to adopt a lot of nifty features and become extremely powerful, but it also means that there are a ton of bizarre corner cases and inconsistencies to deal with. For many projects, the tradeoff is worthwhile. But it's one of the worst choices imaginable for teaching new people to program.
> Kaboom. Oops. You can use auto, or you can use {} to make a vector, but you can't do both at the same time!
IMO it would be more confusing if that created a vector<int>. Unless the compiler is reading your mind, how is it supposed to know you meant a vector<int>, a set<int>, deque<int>, a struct { int a,b,c,d,e,f}, or some other object who's constructor can take 6 ints?
To be fair everything you're upset about is a problem with the standard C++ library, not the language itself.
Not to say that the language doesn't have issues. The initializer list example you provide is half of one, but only because people don't like to write algorithm-based code.
This is actually fine:
auto v = {1, 2, 3, 5, 8, 13};
for (auto i : v) {
std::cout << i << '\n';
}
...all that being said, the C++ standard library gets strings very wrong. I've ranted about it here before. But, to be fair:
1. What language gets strings right?
2. C++ has some interesting ideas around the bend (concepts) that should make using library code much easier. Whether writing library code will be easier is another question, but I'm hopeful.
>>The next example demonstrates initializing a vector:
>> vector<int> v = {1,2,3,5,8,13};
>>This is great, of course. The example after that introduces "auto" so you don't have to write the type of a variable. Well heck, let's combine the two!
>> auto v = {1,2,3,5,8,13};
The auto example creates an std::initializer_list which then can be converted into a vector or a set
The aim of C++ is not to be accessible to beginners. There are other languages for that. The philosophy of C++ is to give you power and it's up to you how to handle it.
The list initialization syntax touted by Bjarne Stroustrup himself as beginner friendly is not even friendly to advanced users. Tell me how to debug or teach students the difference between
[+] [-] mike-cardwell|11 years ago|reply
I just compiled the C code and the C++ code using:
According to valgrind: Using gcc (Debian 4.7.2-5)[edit] Repeated using gcc 4.9.1 and clang 3.5.0 with -std=c++14. No difference.
[edit] Seems with Clang and libc++ it's better than the C implementation as it doesn't do any heap allocation:
But still, that's only because the C version was explicitly written to use heap allocation. It need not do so.[+] [-] pierrebai|11 years ago|reply
You count the number of allocations, without looking at the big picture: this is a toy example. It provides the hard-coded input to the function. This results in the C version not having to allocate memory for the hard-coded literals and the function problably being inlined and optimized away and the strlen() calls being equally optimized away as the length of the strings are known at compile time.
In the real world, these would come from some input where they would need to be allocated on the heap, just like the C++ version does. It would use just as many allocations, except they will all be hand-rolled, hand-held, error-prone, with every bit of memory management explicit. C++ is superior in every measure here. Only in toy programs and hard-coded strings does C wins.
If the goal was to have as few allocations from hard-coded strings, then just write "foo@bar" and avoid the concatenation altogether. That is not the point of the example.
(Also, the newer C++ standard support std::string literals, FWIW.)
[+] [-] nly|11 years ago|reply
Secondly, as you discovered, the current GNU stdlibc++ implementation of std::string will always allocate for short strings. Even 1 byte. This is for binary back-compat and will hopefully be fixed in GCC 5.0. For now try it with Clang and libc++. See[0] for more information and a comparison of current implementations.... the standard doesn't require SSO at all.
Thirdly, and getting to the deeper issue, once the heap is involved the C version is nearly (it needs length params) optimal and will still always be more efficient than the C++ code. Why? The C++ solution uses uses operator+ which is fundamentally performing a different and less general algorithm. For composition it will introduce some amount of repeated work which even the best link-time optimizing compilers probably won't remove, and may, depending on the length of the trailing string segments, and the growth strategy used under the covers, force two allocations. The standard doesn't give complexity guarantees for mutation on std::string at all, so the resulting performance could, on some platforms, be very bad. In all cases you will be able to construct an input that forces more than one allocation (exponentially growing segment sizes).
There's also another efficiency issue in the naive op+ approach... C++s allocator specification doesn't provide realloc() so a portable solution will always use more peak memory, on average, when it is forced to reallocate.
The C++ solution is just using the wrong algorithm for the job. You can write, and I have toyed with[1], a variadic strcat() function that will be optimal in the generic case. The standard library just lacks one. It's embarrassing, but fairly understandable given that variadic templates didn't come in to the standard until 2011. I'm hoping if they introduce one it'll be called scat() :-)
I'm a big C++ fan, but we shouldn't be deluding ourselves here. Fortunately, these things can be fixed within the framework of the current language.
[0] https://github.com/elliotgoodrich/SSO-23/blob/master/README....
[1] http://codepad.org/rkmNTkIn
[+] [-] BudVVeezer|11 years ago|reply
[+] [-] robert_tweed|11 years ago|reply
To be fair, he says "likely to be" and results may vary between compilers. He also makes reference to the speed penalty of calling strlen(), which isn't necessary with std:string because it stores the length. Even with more allocations, it's possible the C++ version runs faster. It should have a lower computational complexity, meaning it would be faster if the input strings were much longer than they are in this example.
[+] [-] pjmlp|11 years ago|reply
[+] [-] maxlybbert|11 years ago|reply
gcc -std=c99 -O3 -Wall -Wextra test.c -o test
g++ -std=c++11 -O3 -Wall -Wextra test.cpp -o test
In my experience, C++ compilers are great at eliding temporaries and various constructor calls (and related memory allocations), but only if optimizations are turned on.
[+] [-] Ragnarork|11 years ago|reply
C++ has come a long way, and I really feel C++ 11 could very well replace Java as a learning language for computer science students (I don't think it'd be a good choice for an introduction to programming for non CS students), and I see many benefits in this, the biggests being IMHO C++ NOT being fully object-oriented, and the possibility to do either low- or high-level stuff, depending on what you're teaching.
[+] [-] wmt|11 years ago|reply
[+] [-] Symmetry|11 years ago|reply
[+] [-] linuxlizard|11 years ago|reply
Drives me batty to see articles where malloc() is happily assumed to always succeed.
[+] [-] CountHackulus|11 years ago|reply
[+] [-] robert_tweed|11 years ago|reply
PS: Since HN is specially humour-impaired, and for the DNRTFA crowd: this is a complaint about the article's formatting.
[+] [-] drblast|11 years ago|reply
1. There are a lot of abstractions in C++ that make it very powerful, but the reason those exist would be completely lost on a newbie. Pass-by-reference vs. pass-by-value? Oh yeah, there are pointers too that you might run into, that's almost exactly like a reference but with a different syntax. We have smart pointers instead to obscure that from you, but if you search for examples online you might run into any of these. But don't worry about all of this; these language features only exist because of type safety and performance which you have no clue about. Just change the syntax until it compiles and runs.
2. Programming is more than write->compile. Debugging is as important, if not more, and heaven help you if you're a beginner trying to debug C++. With C you'll at least get exposure to machine code that pretty much looks like the program you wrote.
3. C++11 is an improvement, but it's not ubiquitous and it adds abstraction that someone without a solid C/Assembly background will have very little chance of understanding.
Teaching C++ to someone with a firm grasp of C would be a lot easier and additive. "Here are the new features that can help the compiler make your program more performant or type-safe or fix your memory leaks." Otherwise you're throwing a bunch of solutions at students to problems they've never had.
[+] [-] cheez|11 years ago|reply
[+] [-] pjmlp|11 years ago|reply
Where I took my CS degree, students were introduced to C++ straight after Pascal.
[+] [-] pherocity_|11 years ago|reply
[+] [-] Iftheshoefits|11 years ago|reply
Second, I don't find his use of "myth" objectionable, in much the same way I (as a scientist) don't find objectionable the use of "theory" to mean "guess" in non-scientific speech (attempting to impose "guess" as a meaning when discussing scientific theories is anathema). This use of "myth" here is fairly common, at least colloquially in America, as a rhetorical flourish in place of "misconception."
[+] [-] WhitneyLand|11 years ago|reply
Back in the day I read Bjarne's book cover to cover, used C++ for very large scale projects, and was one of those guys who could make sense of arbitrarily complex pointer expressions.
Now I mostly regret it. Led down the rabbit hold of multiple inheritance, STL being much more complicated than templating in other languages, and watching devs take years to master all of the subtleties.
He alludes (next article) to garbage collection not being more reliable than manually memory management? Yes GC has it's own disadvantages and there are many ways in C++ to mitigate memory management problems, but seriously I wish I had a dollar for every hour of time spent on a memory allocation bug in C++.
[+] [-] bstamour|11 years ago|reply
Edit: I should mention that by no means to I think C++ is perfect. Very few other languages, however, give you the amount of low-level control, and the tools to build cheap, powerful abstractions, like C++ does.
[+] [-] pjmlp|11 years ago|reply
At work no. Typical enterprise world using JVM and .NET languages.
For side projects, surely yes!
It is the only language supported across all mobile OS SDKs with full access to the hardware.
If you have control over the codebase, the ability to use C++11/14 is quite comfortable, even in terms of memory management.
Now for the typical enterprise projects, with offshore developers at work I wouldn't use it. I already cry when I look at code written in less powerful languages.
[+] [-] Scea91|11 years ago|reply
[+] [-] jj00|11 years ago|reply
[+] [-] 0942v8653|11 years ago|reply
[+] [-] gamesbrainiac|11 years ago|reply
[0] https://www.youtube.com/watch?v=TJHgp1ugKGM
[+] [-] ExpiredLink|11 years ago|reply
[+] [-] stinos|11 years ago|reply
look at it this way: suppose some alternate universe where there is no such thing as C, it just doesn't exist, nobody ever heard of it. Why would you not be able to completely master C++ that universe? The traps and pitfalls which you consider C, would then just be known as C++ (just as in reality they are C++ now, maybe not just always named as such). I think that's one thing what's being advocated here.
Anyway, what traps do you have in mind specifically?
[+] [-] throwawayaway|11 years ago|reply
When some people say that when you are learning C++ you should not be exposed to C, I really have to disagree.
[+] [-] AnimalMuppet|11 years ago|reply
False.
What's a paradigm? It's a way of viewing things. What ways are there of viewing programming? Well, there's functional, there's structured, there's object-oriented, there's generic, and maybe some more.
Can C++ be used to write non-object-oriented, non-functional, purely structured-programming-style procedural code? Yes, it can. (Essentially, that's the subset that's in common between C and C++.) Can it be used to write object-oriented code? Certainly. Can it be used to write functional code? Again, yes (though not nearly as purely as the Haskell zealots would like - but C++ doesn't enforce the purity the way Haskell does precisely because C++ is multi-paradigm). Can C++ be used to write generic code? Yes. (I have heard that the STL was written in C++ because, at the time, it was the only widely used language that would do what Stepanov wanted to be able to do.)
Four different paradigms. You can write C++ code using any of them, or you can mix and match. That's multi-paradigm.
Or are you arguing that, if you have more than one paradigm, you don't have any? That might be true of a program, though I think that the argument is merely a matter of definition, and therefore not very interesting. But if the language makes it easy to write in several paradigms, it seems perfectly appropriate to call it multi-paradigm.
[+] [-] aikah|11 years ago|reply
You need a basic understanding of C.But C and C++ are different languages,period.
[+] [-] Ragnarork|11 years ago|reply
Genuine question.
[+] [-] divs1210|11 years ago|reply
[+] [-] pjmlp|11 years ago|reply
[+] [-] mikeash|11 years ago|reply
The article demonstrates string concatenation using +. That is great! Except it's inconsistent. The article's example works fine, of course:
I'll skip over the weird use of '' instead of "". Now let's say I want to prepend mailto: as well: So far so good. But I think it might be clearer if the colon was separated out: Oops, this no longer compiles. Hey beginner programmers, let's take time out from the arduous task of learning basic programming to understand what a const char * is and how it differs from const string and why you can + two strings or a string and a const char * or a const char * and a string but you can't + two const char *s.The next example demonstrates initializing a vector:
This is great, of course. The example after that introduces "auto" so you don't have to write the type of a variable. Well heck, let's combine the two! Kaboom. Oops. You can use auto, or you can use {} to make a vector, but you can't do both at the same time! OK, beginners, let's take some more time out from learning what you came for and instead learn about the complex machinery that handles initializing a custom type with {} and why "a = b" can do arbitrarily complex things depending on the types of a and b.I had a job in college tutoring students in my CS department's first-semester programming course, which was taught in C++. People would routinely come in with code that wouldn't compile because of some tiny mistake, but which produced literally pages of error output. There was no way for new students who were still struggling with the concept of a loop to figure out what they were doing wrong, besides finding somebody who had already been through it.
This was a long time ago, and C++ has improved, especially in the error message department. But these problems are still there, even if somewhat diminished, and other languages don't have them.
The fundamental problem with C++ is that it grew organically from humble beginnings without any apparent plan. This allowed to adopt a lot of nifty features and become extremely powerful, but it also means that there are a ton of bizarre corner cases and inconsistencies to deal with. For many projects, the tradeoff is worthwhile. But it's one of the worst choices imaginable for teaching new people to program.
[+] [-] jlarocco|11 years ago|reply
> Kaboom. Oops. You can use auto, or you can use {} to make a vector, but you can't do both at the same time!
IMO it would be more confusing if that created a vector<int>. Unless the compiler is reading your mind, how is it supposed to know you meant a vector<int>, a set<int>, deque<int>, a struct { int a,b,c,d,e,f}, or some other object who's constructor can take 6 ints?
[+] [-] humanrebar|11 years ago|reply
Not to say that the language doesn't have issues. The initializer list example you provide is half of one, but only because people don't like to write algorithm-based code.
This is actually fine:
...all that being said, the C++ standard library gets strings very wrong. I've ranted about it here before. But, to be fair:1. What language gets strings right?
2. C++ has some interesting ideas around the bend (concepts) that should make using library code much easier. Whether writing library code will be easier is another question, but I'm hopeful.
[+] [-] npalli|11 years ago|reply
>> vector<int> v = {1,2,3,5,8,13};
>>This is great, of course. The example after that introduces "auto" so you don't have to write the type of a variable. Well heck, let's combine the two!
>> auto v = {1,2,3,5,8,13};
The auto example creates an std::initializer_list which then can be converted into a vector or a set
Which seems the best you can expect with auto deduction. What else do you have in mind?[+] [-] Scea91|11 years ago|reply
[+] [-] maratc|11 years ago|reply
Apparently, the first `+` is a problem, so just take it away:
[+] [-] axiak|11 years ago|reply
[+] [-] netheril96|11 years ago|reply
[+] [-] der7leo|11 years ago|reply
[deleted]