unique objects and stl containers

Discussion in 'C++' started by Claudio Jolowicz, Apr 9, 2004.

  1. Is it possible to store unique objects in an STL container?

    Suppose an object of class C is unique:

    class C
    {
    public:
    C() {}
    ~C() {}
    private:
    C(const C&);
    operator=(const C&);
    };

    Another class manages and operates on collections of these objects:

    class User
    {
    public:
    void addC(const C& c)
    {
    m_lstCs.push_back(c);//error!
    }
    protected:
    std::list<C> m_lstCs;
    };

    This leads to an error, because std::list<C>::push_back() calls C's
    copy constructor. Is a list of pointers the only solution, or is there
    a better way?

    --
    Claudio Jolowicz

    Department of Computing
    180 Queen's Gate
    South Kensington campus
    Imperial College
    LONDON SW7 2AZ

    http://www.doc.ic.ac.uk/~cj603
    Claudio Jolowicz, Apr 9, 2004
    #1
    1. Advertising

  2. Claudio Jolowicz

    Mike Wahler Guest

    "Claudio Jolowicz" <> wrote in message
    news:p...
    > Is it possible to store unique objects in an STL container?
    >
    > Suppose an object of class C is unique:
    >
    > class C
    > {
    > public:
    > C() {}
    > ~C() {}
    > private:
    > C(const C&);
    > operator=(const C&);
    > };
    >
    > Another class manages and operates on collections of these objects:
    >
    > class User
    > {
    > public:
    > void addC(const C& c)
    > {
    > m_lstCs.push_back(c);//error!
    > }
    > protected:
    > std::list<C> m_lstCs;
    > };
    >
    > This leads to an error, because std::list<C>::push_back() calls C's
    > copy constructor. Is a list of pointers the only solution, or is there
    > a better way?


    One of the requirements of containers is that objects
    stored in them must be both 'copyable' and 'assignable'.
    So yes, a pointer would be the only way.

    -Mike
    Mike Wahler, Apr 9, 2004
    #2
    1. Advertising

  3. Claudio Jolowicz

    Leor Zolman Guest

    On Fri, 9 Apr 2004 03:34:09 +0100, Claudio Jolowicz <>
    wrote:

    >Is it possible to store unique objects in an STL container?


    Is "unique" a technical term I haven't encountered yet? There are
    "Singletons", but by definition you wouldn't have more than one, so I can't
    for the life of me imagine why you'd /want/ to be able to store them in a
    container.

    Another possible meaning of "unique" would be as in "Is it possible to have
    an STL container in which all objects have unique values". Sure, that's
    what std::set is, a collection of uniquely-valued objects.

    >
    >Suppose an object of class C is unique:
    >
    >class C
    >{
    >public:
    > C() {}
    > ~C() {}
    >private:
    > C(const C&);
    > operator=(const C&);
    >};


    What is it about Cs that make them "unique"? They can't be copy constructed
    or assigned, but that wouldn't stop you from having a bunch of them...
    whether they have equivalent values or not.
    >
    >Another class manages and operates on collections of these objects:
    >
    >class User
    >{
    >public:
    > void addC(const C& c)
    > {
    > m_lstCs.push_back(c);//error!
    > }
    >protected:
    > std::list<C> m_lstCs;
    >};
    >
    >This leads to an error, because std::list<C>::push_back() calls C's
    >copy constructor.


    That's a basic requirement for storing any object in an STL container: that
    it can be copied.

    > Is a list of pointers the only solution, or is there
    >a better way?


    Whatever it is you're trying to do, a collection of pointers (smart or
    otherwise) would be a work-around for collecting non-copyable objects in
    STL containers. I can't tell you if there's a "better way", because I can't
    understand what you're trying to do.
    -leor


    --
    Leor Zolman --- BD Software --- www.bdsoft.com
    On-Site Training in C/C++, Java, Perl and Unix
    C++ users: Download BD Software's free STL Error Message Decryptor at:
    www.bdsoft.com/tools/stlfilt.html
    Leor Zolman, Apr 9, 2004
    #3
  4. On Fri, 9 Apr 2004, Leor Zolman wrote:

    >On Fri, 9 Apr 2004 03:34:09 +0100, Claudio Jolowicz <>
    >wrote:
    >
    >>Is it possible to store unique objects in an STL container?

    >
    >Is "unique" a technical term I haven't encountered yet? There are
    >"Singletons", but by definition you wouldn't have more than one, so I can't
    >for the life of me imagine why you'd /want/ to be able to store them in a
    >container.
    >
    >Another possible meaning of "unique" would be as in "Is it possible to have
    >an STL container in which all objects have unique values". Sure, that's
    >what std::set is, a collection of uniquely-valued objects.
    >
    >>
    >>Suppose an object of class C is unique:
    >>
    >>class C
    >>{
    >>public:
    >> C() {}
    >> ~C() {}
    >>private:
    >> C(const C&);
    >> operator=(const C&);
    >>};

    >
    >What is it about Cs that make them "unique"? They can't be copy constructed
    >or assigned, but that wouldn't stop you from having a bunch of them...
    >whether they have equivalent values or not.


    To clarify, "unique" was used in the sense of having copy operations
    private, as in Stroustrup, 3rd ed. p.249 (§ 10.4.6.3). Theoretically, I
    agree there could be another, equivalent instance. But you might not be
    able to create such an equivalent instance, because you don't know the
    exact type, or you don't have access to private data, etc.

    >>
    >>Another class manages and operates on collections of these objects:
    >>
    >>class User
    >>{
    >>public:
    >> void addC(const C& c)
    >> {
    >> m_lstCs.push_back(c);//error!
    >> }
    >>protected:
    >> std::list<C> m_lstCs;
    >>};
    >>
    >>This leads to an error, because std::list<C>::push_back() calls C's
    >>copy constructor.

    >
    >That's a basic requirement for storing any object in an STL container: that
    >it can be copied.
    >
    >> Is a list of pointers the only solution, or is there
    >>a better way?

    >
    >Whatever it is you're trying to do, a collection of pointers (smart or
    >otherwise) would be a work-around for collecting non-copyable objects in
    >STL containers. I can't tell you if there's a "better way", because I can't
    >understand what you're trying to do.
    > -leor
    >


    Some of the objects represent items in a trading environment (my post
    yesterday), each item having a unique ID. Another class defines an agent
    running on a thread. It might be more reasonable to allow copy
    construction and define an equivalence relation using the item/thread
    IDs. Copy assignment is a problem since associations between items are
    represented as references. But as far as I know (please correct me),
    copy assignment is not required for elements of a std::list.


    >
    >--
    >Leor Zolman --- BD Software --- www.bdsoft.com
    >On-Site Training in C/C++, Java, Perl and Unix
    >C++ users: Download BD Software's free STL Error Message Decryptor at:
    > www.bdsoft.com/tools/stlfilt.html
    >


    --
    Claudio Jolowicz

    Department of Computing
    180 Queen's Gate
    South Kensington campus
    Imperial College
    LONDON SW7 2AZ

    http://www.doc.ic.ac.uk/~cj603
    Claudio Jolowicz, Apr 9, 2004
    #4
  5. "Claudio Jolowicz" <> wrote in message
    news:p...
    > Is it possible to store unique objects in an STL container?

    [where "unique" is intended to mean "non-copyable"]
    Non-copyable object instances shall usaually be either
    termporaries stored on the stack, or globals, or heap-based
    objects.

    So yes, you want to use a container of pointers -- but
    preferably "smart pointers" to help avoid memory leaks.

    My advice would be:
    std::list< boost::shared_ptr<C> > m_lstCs;

    See boost.org for a (thread-safe) implementation of shared_ptr.
    (note that shared_ptr is expected to be included in the next
    revision of the C++ standard).

    hth,
    Ivan
    --
    http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form
    Brainbench MVP for C++ <> http://www.brainbench.com
    Ivan Vecerina, Apr 9, 2004
    #5
  6. Claudio Jolowicz

    Buster Guest

    Claudio Jolowicz wrote:

    > [...] as far as I know (please correct me), copy assignment is not
    > required for elements of a std::list.


    23[lib.containers]/3: The type of objects stored in these components
    must meet the requirements of CopyConstructible types (20.1.3), and the
    additional requirements of Assignable types.

    --
    Regards,
    Buster.
    Buster, Apr 9, 2004
    #6
  7. Claudio Jolowicz

    Default User Guest

    Ivan Vecerina wrote:

    > So yes, you want to use a container of pointers -- but
    > preferably "smart pointers" to help avoid memory leaks.
    >
    > My advice would be:
    > std::list< boost::shared_ptr<C> > m_lstCs;
    >
    > See boost.org for a (thread-safe) implementation of shared_ptr.
    > (note that shared_ptr is expected to be included in the next
    > revision of the C++ standard).



    Was any part of Boost added to the standard in the recent revision?



    X-posted to a.c.l.l.c-c++ due to newsfeed problems.

    Brian Rodenborn
    Default User, Apr 9, 2004
    #7
  8. Default User wrote in news::

    > Ivan Vecerina wrote:
    >
    >> So yes, you want to use a container of pointers -- but
    >> preferably "smart pointers" to help avoid memory leaks.
    >>
    >> My advice would be:
    >> std::list< boost::shared_ptr<C> > m_lstCs;
    >>
    >> See boost.org for a (thread-safe) implementation of shared_ptr.
    >> (note that shared_ptr is expected to be included in the next
    >> revision of the C++ standard).

    >
    >
    > Was any part of Boost added to the standard in the recent revision?


    No (IIUC), the revesion was an update, i.e. it incorparates all
    the DR's that were effectivly bug's in the prior Standard (C++98).
    In effect the Standard hasn't changed, Its just now you can
    buy a more accurate version.

    I went here: http://std.dkuug.dk/jtc1/sc22/wg21/

    and eventually found:

    http://std.dkuug.dk/jtc1/sc22/wg21/docs/library_technical_report.html

    There's about 10 boost libraries on the list (II<Count>C)

    Its only a Technical *Report* so its still uncertain wether these libs
    will end up in the next standard.

    Rob.
    --
    http://www.victim-prime.dsl.pipex.com/
    Rob Williscroft, Apr 9, 2004
    #8
  9. "Default User" <> wrote in message
    news:...
    > Ivan Vecerina wrote:
    > > See boost.org for a (thread-safe) implementation of shared_ptr.
    > > (note that shared_ptr is expected to be included in the next
    > > revision of the C++ standard).

    >
    > Was any part of Boost added to the standard in the recent revision?


    Not yet, as the latest C++ standard still dates back to 1998.
    However, library extensions are actively being worked on,
    and the boost.org repository of libraries

    Some extensions are already "approved" for future inclusion,
    and even supported by a fewcompilers in their preliminary form (the
    recommendation for now being to keep these extensions in std::tr1).
    See:
    http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1540.pdf

    Boost users will find a few familiar classes in this round of
    proposed extensions, and probably in the next ones...

    This is yet another reason to get familiar with these
    peer-reviewed libraries.

    Regards,
    Ivan
    --
    http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form
    Brainbench MVP for C++ <> http://www.brainbench.com
    Ivan Vecerina, Apr 9, 2004
    #9
  10. Claudio Jolowicz

    David Harmon Guest

    On Fri, 9 Apr 2004 07:06:17 +0100 in comp.lang.c++, Claudio Jolowicz
    <> wrote,
    >To clarify, "unique" was used in the sense of having copy operations
    >private, as in Stroustrup, 3rd ed. p.249 (§ 10.4.6.3).


    I guess "singleton" is now the standard name for that,
    probably from _Design Patterns_ by Gamma et al.
    David Harmon, Apr 9, 2004
    #10
  11. Claudio Jolowicz

    Default User Guest

    Rob Williscroft wrote:
    >
    > Default User wrote in news::


    > > Was any part of Boost added to the standard in the recent revision?

    >
    > No (IIUC), the revesion was an update, i.e. it incorparates all
    > the DR's that were effectivly bug's in the prior Standard (C++98).


    So no new stuff this time around.

    > I went here: http://std.dkuug.dk/jtc1/sc22/wg21/


    I always seem to get lost maneuvering around there :)


    > http://std.dkuug.dk/jtc1/sc22/wg21/docs/library_technical_report.html
    >
    > There's about 10 boost libraries on the list (II<Count>C)


    Thanks!

    > Its only a Technical *Report* so its still uncertain wether these libs
    > will end up in the next standard.


    Yeah, it will be interesting to see what makes it into the Standard.



    Brian Rodenborn
    Default User, Apr 9, 2004
    #11
  12. Ivan Vecerina wrote:

    > "Default User" <> wrote in message
    > news:...
    >
    >>Ivan Vecerina wrote:
    >>
    >>>See boost.org for a (thread-safe) implementation of shared_ptr.
    >>>(note that shared_ptr is expected to be included in the next
    >>> revision of the C++ standard).

    >>
    >>Was any part of Boost added to the standard in the recent revision?

    >
    >
    > Not yet, as the latest C++ standard still dates back to 1998.


    ISO/IEC 14882:2003, you mean? It dates back to 1998 in the
    sense that it replaces ISO/IEC 14882:1998 by incorporating
    a number of corrections. No new features though.

    -- James
    James Dennett, Apr 10, 2004
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Koen
    Replies:
    1
    Views:
    489
  2. JackC
    Replies:
    3
    Views:
    577
    Alan Griffiths
    Aug 13, 2004
  3. Replies:
    7
    Views:
    536
    Pete Becker
    Jan 25, 2008
  4. Andrey Vul
    Replies:
    6
    Views:
    561
    James Kanze
    Oct 22, 2009
  5. Sebastian Mach
    Replies:
    5
    Views:
    302
Loading...

Share This Page