From: Pavol Droba (droba_at_[hidden])
Date: 2005-02-17 15:46:16
On Thu, Feb 17, 2005 at 09:10:45PM +0100, JOAQUIN LOPEZ MU?Z wrote:
> IMHO, "cloned/clonable container" hardly suggests what the
> lib is about: a clonable object has a rather well defined
> meaning, and so a clonable container seems to mean a container
> with some sort of clone() memfun. "Clonable objects
> container" (better than "clonable pointer container")
> is 100% accurate, but too verbose.
> A possibility without ambiguities is "clone container",
> i.e. a container of clones.
> As for the "managed" line, I think it resonates with some issues
> none of which has to do with the subject at hand:
> * "managed" as bounds checked.
> * "managed" as belonging to the world of C++/CLI (ugh!)
> So, if we rule out "indirect" for the reasons you explained,
> we're left with "pointer container". I think this is good:
> * std::set is a value container (elements have value
> semantics), so it is natural to extend the idea to ptr_set
> being a pointer container.
> * The term has some tradition.
> * It doesn't sugest anything different to what the lib is
> about. Actually ptr_containers do more than just holding
> pointers, but well.
> * When you augment the lib to support shared_ptrs, the name
> still holds.
> To sum it up, I vote for "pointer container", "clone container"
> being my close-second choice.
As a short remark, I second this opinion with the strong preference
over "pointer container".
The library combines serveral aspects, but the "pointer" is actualy
the only unifying entity in all of them.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk