I'm replying to my own post since my comments relate to the
various replies so far...
Anyway, the need for efficiency is questioned recurrently in
the replies; my justification is indeed suggested in the OP:
what I'm trying to do is a library that aims at being useful
for a variety of applications. Some of those applications
will be such that the inefficiency due to extra copies or to
unneeded initialization would be irrelevant; but some other
applications may be have tight efficiency requirements, so
I would like to make my library suitable for those. That's
why I'm trying to make my best reasonable effort to avoid
inefficiencies.
No, allocating on the stack is not an option, since the
string can be arbitrarily long, and it is not known at
compile-time.
I guess my question about the UB was not specific enough;
I mean, yes, allocating with new [] and releasing with
delete *is* UB... My question was (or should have been):
*in practical terms*, does this undefined behaviour goes
all the way down to the memory allocation algorithms used
by the compiler or the runtime memory-management system?
Or does it simply go to the point of failing to call the
destructor for each and every element?
For example, the following code leaks memory:
string * ptr = new string [10];
delete ptr;
Since only one string would be destructed (well, it
causes memory leak plus any other side-effect of failing
to call a destructor on a fully constructed object).
But if instead of string, we have a built-in, for which
the destructor is a no-op, then *in practical terms*,
the undefined behaviour would/could systematically
manifest in having no adverse effect on the code.
The thing is, the "buggy" code using auto_ptr does
compile and run as expected --- even when linked with
Electric Fence (not 100% if electric fence does cover
memory leaks as well as illegal memory accesses). In
any case, it runs without EFence objecting.
I guess at this point I'm more curious than anything
else, in that I think even doing something as silly as
a simple class house_keeper (you know, to do the
housekeeping upon return) with:
template <typename T>
class house_keeper
{
T * p;
public:
house_keeper (T * p) : p(p) {}
~house_keeper() { delete [] p; }
};
And then:
char * result = new char [ ... ];
house_keeper<char> r (result);
// ... (use the raw pointer result as needed)
return string (result, result + length);
Seems like I'm getting the very small required subset of
auto_ptr or scoped_prt/array that provides me with memory
management and exception-safety at a very low cost (I wouldn't
want to have to include a dependency to boost just because of
such a silly detail... Now, *if and when* I decide to include
regular expressions as part of my library needs to do, then
perhaps my threshold to decide to go for boost::scoped_xxx
might dramatically decrease, since I would be already using
boost's facilities).
Thanks again for all the comments/feedback so far !
Carlos
--
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
