Which will be more space-efficient and faster?
Which will be more space-efficient and faster?
Ussually the STL. And probably more reliant since many people have worked on it and tested it vs not many.
Woop?
In my opinion that depends on how good you are. If you're really good programer than probably you can write more efficient algorithms regarding your data structures comapring with STL algorithms. But with flexibility that STL offer... that's a question. My advice is to stick to STL because you have very rich set of very powerful and well defined algorithms.
- Micko
Gotta love the "please fix this for me, but I'm not going to tell you which functions we're allowed to use" posts.
It's like teaching people to walk by first breaking their legs - muppet teachers! - Salem
Yeah - stick with the STL. It'll make it easier to work with other programmers, and unless you need to really save a couple of clock cycles by having a custom-built algorithm, there's no practical reason to avoid the concenience of STL.
I need to write a space efficient and fast algorithm.
But I am not an expert in programming.
But which is uses less space? A normal array or a STL vector?
It depends on the situation. If you know the exact size of the array you need beforehand, use an array so you can avoid the overhead. If you need variable-length arrays and the functions already built-in to vectors, use STL. The STL is space efficient and fast - there isn't a huge amount to gain by doing it yourself.
> But which is uses less space? A normal array or a STL vector?
If you use say reserve() to allocate the right amount up-front, it's going to be the same
http://www.sgi.com/tech/stl/Vector.html
> But I am not an expert in programming.
In which case, the STL is likely to be hard to beat, and a lot of work on your part before you succeed.
Premature optimisation is a terrible disease - get it working first, then ask how it might be improved.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
ok, thanks for your advice =)
I just try a simple test. I assigned both STL vector and a normal array with 6 elements
I initialize them by:
<vector>int Arr(6); //vector
int Arr(6); //normal array
I used Valgrind to check how much space they consume. The vector took about 1600bytes while the normal array about 20 something bytes. I can't recall the exact amount.
Why didn't you just do that in the first place?I used Valgrind to check how much space they consume.
The array would take up 24 bytes - 4 bytes per int. The vector takes up the same amount of space, plus all the space required to store the member functions. For large amounts of data, this overhead becomes negligible. We've helped you all you can - we don't know exactly what you're trying to do, so you need to make the call yourself now.
> The vector took about 1600bytesCode:#include <iostream> #include <vector> using namespace std; int main ( ) { vector<int> a1(6); int a2(6); // not an array, just an int initialised to 6 int a3[6]; cout << a1.capacity() * sizeof(int) << endl; cout << sizeof(a2) << " " << a2 << endl; cout << sizeof(a3) << endl; return 0; } $ ./a.out 24 4 6 24
Maybe so, but that could well be down to the underlying allocator (which you have very little control over), so even if you did
There's still no guarantee that it wouldn't allocate a larger amount behind your back.Code:int *myarray = new int[6];
The point (or so you said) was to be comparitively efficient at the large scale. Minor differences in overhead will barely show up when you start allocating 1000's of these things.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
And of course the fact that a hand-coded version would come out in much higher bytes too.
Warning: Have doubt in anything I post.
GCC 4.5, Boost 1.40, Code::Blocks 8.02, Ubuntu 9.10 010001000110000101100101
it depends on how good you are at programming. for example, the 'sqrt()' function. if you've come up with a better/faster algorithm of finding the square root of a number, then by all means, use it! if not, just stick to the sqrt() function provided by the STL.
Actually that is incorrect, member functions are not stored in instances of classes, the member function is actually turned into a function that takes a pointer to the object as a parameter.Originally Posted by sean_mackrory
This code gets translated by the compiler into something like this:Code:class my_class { public: my_class(int val) { value = val; } int square() { return value*value; } private: int value; }; int main() { my_class a(10),b(20),c(30); //all take up sizeof(int) memory std::cout << a.square(); //square is invoked as shown below return 0; }
Therefore, no matter how many instances of my_class exist, there exists only one function to manipulate the member data.Code:struct my_class { int value; }; int square(my_class* this) { return this->value * this->value; }
Furthermore, a vector of 6 integers would take up and additional (sizeof(int*) * 2) bytes, as the vector stores a pointer to the start of the data, a pointer to the end of the data, and a pointer to the end of the allocated space.
The main speed problem with the vector is that it uses dynamic memory. If you don't want this to occur, and know the size of the array, then rolling out your own using a template parameter ought to execute slightly faster. The STL algorithms can be still be use by forming a forward iterator using the beginning and ending of the array. (I don't think backward iterators work but you might check your documentatino)I need to write a space efficient and fast algorithm.
But I am not an expert in programming.
But which is uses less space? A normal array or a STL vector
ComputerPhreak, yea, I think perhaps he's confusing virtual member functions with just plain member functions.Therefore, no matter how many instances of my_class exist, there exists only one function to manipulate the member data.
