98c84967
From: miles@gnu.org
Mathias Gaunard writes:
> All in all, I think there is sufficient work to do here that you don't
> gain much by using std::vector as a memory backend rather than the
> more flexible std::allocator.
You gain at least the one specific, if simple, thing: no need to
worry about freeing. [and of course the std::vector can use whatever
allocator you tell it, so you don't actually lose much flexibility.]
More importantly, by _consistently_ using something like std::vector,
except in cases where there are good reasons why you shouldn't
(and no, vague and constantly shifting hand-waving like nmm has been
doing thus far doesn't count as a "good reason"), you actually do gain
robustness.
In other words, it's not the case of one specific class viewed in
isolation that's interesting -- after all, given any one class, you
_can_ add the deallocations, handle the exceptions, etc, and the
malloc-style method will basically work OK -- but the case of what
_policies_ (whether personal, institutional, or whatever) one adopts.
Using std::vector whenever possible, instead of malloc/new/whatever,
_will_ reduce the number of accidental memory leaks; no programmer
(even nmm!) is perfect, and in the aggregate, using tools to simply
the task -- even rather simple tools like std::vector -- has a
positive impact.
Of course one could use other policies, write one's own
allocate-wrapper class, etc, to achieve the same ends, but for typical
usage, I don't see any obvious reason to do so; despite nmm's constant
insinuations, std::vector actually seems to accomplish this (and other
simple tasks) pretty well...
-Miles
--
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
