4 ms·
Let's be a little consistent here, shall we? static const int kNumNumbers = 10; std::vector<int> numbers(kNumNumbers); for (int i=0; i<kNumNumbers; ++i)
by aggieben 19y ago
Let's be a little consistent here, shall we?
static const int kNumNumbers = 10;
std::vector<int> numbers(kNumNumbers);
for (int i=0; i<kNumNumbers; ++i)
numbers[i] = i; // no .push_back necessary
// do something interesting
numbers.clear();
In your example (aside from the memset), you use .push_back(), and only use the defaults for std::vector, both of which aren't what you're doing with int[].
In my example, the only difference is that numbers is initialized with a () instead of [].
As for the call to memset(), looking at the documentation for API to see that you empty the vector with
std::vector<>::clear()
is not getting "burned by quirks". That's how you go about becoming productive in C++, which is what he wants. Also, getting burned by memset()-ing an object is not a quirk of the STL.
In general, what I'm not arguing is that he should use the entire STL right away. Of course you'll get burned by doing stupid stuff that you'll later realize is stupid. What you're arguing is to avoid the STL alltogether, and instead write C in a file with ".cpp" at the end, which is equally bad (because it's not productive C++).
The way to go is to put into practice the bits and pieces of the STL that you can right away. std::vector and std::list are the simplest containers, the fastest to learn, and the most commonly used, so he should start there. Once he discovers iterators, allocators, and <algorithm> (oh my!), he will wake up one day and realize that he now understands a large chunk of the expressiveness of C++.
- palish 19y agoIt isn't possible to use a vector exactly as an array, and my example was an illustration of time that is spent getting used to the differences. The consensus seems to be that native arrays are bug-prone. However, using STL without sufficient knowledge is far more bug prone. Also, your example clears the vector (resets its size to zero) whereas mine sets each number inside the array to zero.
- aggieben 19y agoYou're not getting the point. He is asking what will be an efficient way to learn to be productive in C++. If he follows your advice, he may be less bug-prone (doubtful, but maybe) in the beginning, but he also won't be learning C++. Instead of learning the ins and outs of a library that he will have to learn to achieve productiveness, he'll be learning the ins and outs of how sloppy your C can be and still get by the compiler, which isn't productive. If learning C++ is the goal (and he stated it so), then he should use C++, which is how he will get the "sufficient knowledge" you seem to see as a roadblock. And by the way...it's long since past time that we stopped calling it the STL. It's been a standard for plenty long enough that we should all be calling it the standard library.
- palish 19y agoI don't use a lot of STL, and I'm productive. Neither does John Carmack or John Ratcliff, and the word "productive" doesn't capture just how much they accomplish. I'd like to ask, are you understanding my point? An amount of open-mindedness is required. Common wisdom has been proven incorrect time and time again throughout history, and the common wisdom of C++ that "you need to use STL containers and Boost to be productive" is incorrect. Pierre can illustrate some of the issues more succinctly than I: http://72.14.205.104/search?q=cache:UV4RcASt8mMJ:www.codercorner.com/blog/%3Fp%3D25+site:codercorner.com/blog+standard&hl=en&ct=clnk&cd=3&gl=us http://72.14.205.104/search?q=cache:UV4RcASt8mMJ:www.coderco...
- nuggien 19y agoYou are trying too hard to make a point that people don't agree with. You don't need STL/Boost to be a productive c++ programmer. That's fine, no arguments there. But you don't have to avoid STL/Boost in order to be a productive/efficient c++ programmer either. Get over it.
- scott_s 19y agoQuoting Stroustrup from his 2007 History of Programming Languages paper: 'Alex named his containers, iterators, and algorithm library “the STL”. Usually, that’s considered an acronym for “Standard Template Library”. However, the library existed —with that name—long before it was any kind of standard and most parts of the standard library rely on templates. Wits have suggested “STepanov and Lee” as an alternative explanation, but let’s give Alex the final word: “ ‘STL’ stands for ‘STL’ ”. As in many other cases, an acronym has taken on a life of its own.' http://www.research.att.com/~bs/hopl-almost-final.pdf http://www.research.att.com/~bs/hopl-almost-final.pdf