Re: stl <vector> clear and erase.
On 2012-05-02 21:10, Edward Rosten wrote:
On May 1, 3:33 pm, Daniel Kr?gler<daniel.krueg...@googlemail.com>
wrote:
In theory, a compiler could deduce that the initial 0 value for a
statically sized vector of int is never read in the program, and so
elide the initialization, in the same way that it could elide the
obviously no-op pseudo-destructor. I agree that that would be
harder for the compiler to deduce reliably though.
In theory, yes, but I haven't seen this happening in real life. It
would require a much more kind of non-local code analysis, while the
above mentioned pseudo-destructor elimination can easily be done by
means of portable library code.
Compilers (well, gcc, and I assume the other popular ones) are now
getting very good at this sort of thing, for stack allocated data.
In fact, gcc knows about malloc() and free(), and the following
program:
#include<cstdlib>
using namespace std;
int main()
{
int* a = (int*)malloc(10);
for(int i=0; i< 16; i++)
a[i]=7;
free(a);
}
never bothers to initialise the memory before deleting it.
Bad example, I think. The above code does nothing that makes the
initialization of a observable nor does it read the memory pointed to by
a. This is not a realistic example.
It doesn't yet remove calls to malloc and free, however.
Understandable, because both functions affect non-local resources. To
make your example more reasonable, try the following:
// main.cpp
#include <vector>
#include <stddef.h>
#include <iostream>
#include <iterator>
#include <algorithm>
int fill_array(char* data, size_t n);
int main() {
std::vector<char> vc(20);
fill_array(&vc.front(), vc.size());
std::copy(vc.begin(), vc.end(),
std::ostream_iterator<char>(std::cout, ", "));
}
// other.cpp:
#include <stddef.h>
int fill_array(char* data, size_t n)
{
for (size_t i = 0; i != n; ++i) {
data[i] = char('0' + (i % 10));
}
return 0;
}
I would be interested to know whether there exist compilers that
eliminate the value-initialization of the char-sequence within
std::vector<char> vc(20);
given that program. It requires that the compiler inspects the external
function fill_array to decide whether all elements are replaced by new
values. I don't say that this is impossible, but this task is much
harder than a simple library-trick as explained in my previous reply.
The usual technique is to evaluate
some trait, like is_trivially_destructible (or corresponding compiler
intrinsics that did already exist in C++03) and to make a compile-time
code branch here. There is no much magic involved and therefore this
technique is very popular.
I'm not sure there's any need for that any more. The compiler seems to
be good at doing this kind of thing itself.
I'm quite sure that a high-quality library implementation that takes
advantage of simple compile-time evaluation of built-in type property
predicates is much less demanding than deferring everything to the
compiler. In additional to that general remark, such library
implementation techniques are typically applied to all build types
(including debug builds) and do not require to activate some extreme
optimizations flags which again would typically require lengthier
compile or link times.
Understand me right: Compilers *can* do astonishing code optimizations,
but these capabilities are not for free.
Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]