unique objects and stl containers

[Claudio Jolowicz]

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>:ush_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

 

[Mike Wahler]

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>:ush_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

 

[Leor Zolman]

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>:ush_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

 

[Claudio Jolowicz]

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.


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.

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


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

 

[Ivan Vecerina]

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

 

[Buster]

[...] 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.

 

[Default User]

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

 

[Rob Williscroft]

Default User wrote in

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.

 

[Ivan Vecerina]

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

 

[David Harmon]

On Fri, 9 Apr 2004 07:06:17 +0100 in comp.lang.c++, Claudio Jolowicz

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.

 

[Default User]

Default User wrote in news:[email protected]:

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

 

[James Dennett]

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