Re: memory leak in the code?
In article <7a6ef05b-eff9-4f21-bf22-
86e0b961862c@j78g2000hsd.googlegroups.com>, grizlyk1@yandex.ru says...
[ ... ]
3. If requested concept of array is less than concept of vector<>,
then vector<> can produce poor code, because not-used properties of
more complex concept of vector<> can produce not-used data and code.
"will do produce" or "will do not produce" depends only from concrete
implementation of concrete vector<> for concrete target arch.
In order to detect, you need refer to the concrete implementation of
of concrete vector<> for concrete target arch.
(Any reference to implementation violates encapsulation - bad desing
way).
This is more or less the case: vector can do things an array cannot do
on its own. The most obvious is that a vector can expand to hold more
items as you insert them, which an array cannot. If you're really never
using that capability, your program can include code that's never used.
The cost of this dead code is relatively low though -- it's stored on
disk, but if it's never used, it may never even be paged into physical
memory.
To support that, std::vector also uses dynamically allocated memory,
which means all access to the memory is via a pointer. Depending on the
processor and such, this _may_ be marginally slower than direct access
to the memory (though, in all honesty, it's been quite a while since I
saw a processor for which this was likely to be an issue).
For situations where these constitute real problems, TR1 and C++ 0x both
include an array class that acts more like a built-in array -- it's size
is set at creation time, and remains constant until it's destroyed.
[ ... ]
Object oriented paradigm is required perfect access to interfaces of
any library, otherwise probably perfect and already existed code will
be lost for C++ programmer only due to difficulties of the access.
I disagree. In fact, the containers (and iterators and algorithms) in
the standard library have very little object orientation at all. They
are designed to be generic, but not to be object oriented. Just for one
obvious example of this, they are NOT designed to be used with
inheritance at all.
This ties back nicely to your concern for efficiency. Being template
based, all the type inferencing (and such) involved with using these
parts of the standard library takes place at compile time. An object
oriented interface, by contrast, typically means using virtual function
calls (for one example) which carry some runtime overhead. Admittedly,
the overhead is quite small, but it can be significant anyway.
Being template based also means that the algorithms in the standard
library are often faster than (for example) their counterparts from the
C part of the library. One obvious example is the c-library qsort
function. This uses a rather object oriented interface, though the
"virtual function" used for comparison is exposed as a pointer to a
function (since C doesn't support virtual functions directly).
std::sort, by contrast uses a template so the comparison function is
resolved at compile time. The result is that it's generally much
_faster_ to use std::sort on a vector than it is to use qsort on an
array. Here's a quick comparison test:
#include <vector>
#include <algorithm>
#include <stdlib.h>
#include <time.h>
int compare(void const *a, void const *b) {
if (*(int *)a > *(int *)b)
return -1;
if (*(int *)a == *(int *)b)
return 0;
return 1;
}
const int size = 200000;
typedef unsigned long ul;
void report(char const *title, clock_t ticks) {
printf("%s took %f seconds\n", title, ticks/(double)CLOCKS_PER_SEC);
}
void wait() {
while (clock() == clock())
;
}
int main(void) {
static int array1[size];
static int array2[size];
srand(time(NULL));
for (int i=0; i<size; i++)
array1[i] = rand();
const int iterations = 100;
clock_t total = 0;
for (int i=0; i<iterations; i++) {
memcpy(array2, array1, sizeof(array1));
wait();
clock_t start = clock();
qsort(array2, size, sizeof(array2[0]), compare);
total += clock()-start;
}
report("qsort", total);
total = 0;
for (int i=0; i<iterations; i++) {
memcpy(array2, array1, sizeof(array1));
wait();
clock_t start = clock();
std::sort(array2, array2+size);
total += clock()- start;
}
report("std::sort (array)", total);
total = 0;
for (int i=0; i<iterations; i++) {
std::vector<int> array3(array1, array1+size);
wait();
clock_t start = clock();
std::sort(array3.begin(), array3.end());
total += clock()-start;
}
report("std::sort (vector)", total);
return 0;
}
At least with the compilers I've tested so far, std::sort is
consistently at least twice as fast as qsort. std::sort on an array is
sometimes faster than std::sort on a vector -- but sometimes it's
slower. I'm pretty sure you'd have to do the test extremely carefully
(and often) to be sure whether there's a statistically significant
difference between the two. Even if there is a difference, I'm quite
certain it's too small to care about most of the time.
--
Later,
Jerry.
The universe is a figment of its own imagination.