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.
Regards,
Pavol