By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,563 Members | 1,307 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,563 IT Pros & Developers. It's quick & easy.

Class with functions that return STL containers with incomplete types

P: n/a
Greetings,

Having classes with member objects that have STL containers of objects
whose definitions are incomplete results in undefined behavior. See
for example:

http://www.ddj.com/database/184403814#8
http://www.parashift.com/c++-faq-lit...html#faq-39.14

I am wondering: is it okay to have member functions that return an STL
container with an incomplete type? My member objects do not contain
incomplete types. For instance, would the following code be OK?
Thanks. --Omari

#include <boost/shared_ptr.hpp>
#include <vector>

class HasSelf
{
public:
HasSelf(std::vector<HasSelf>& contents);
std::vector<HasSelfgetContents() const;

private:
std::vector<boost::shared_ptr<HasSelf _contents;
};
Jan 9 '08 #1
Share this Question
Share on Google+
3 Replies


P: n/a
massysett <Or***********@gmail.comwrote in
news:31**********************************@h11g2000 prf.googlegroups.com:
Greetings,

Having classes with member objects that have STL containers of objects
whose definitions are incomplete results in undefined behavior. See
for example:

http://www.ddj.com/database/184403814#8
http://www.parashift.com/c++-faq-lit...sues.html#faq-
39
.14

I am wondering: is it okay to have member functions that return an STL
container with an incomplete type? My member objects do not contain
incomplete types. For instance, would the following code be OK?
Thanks. --Omari

#include <boost/shared_ptr.hpp>
#include <vector>

class HasSelf
{
public:
HasSelf(std::vector<HasSelf>& contents);
std::vector<HasSelfgetContents() const;

private:
std::vector<boost::shared_ptr<HasSelf _contents;
};
shared_ptr<does not require that the class be complete, but in this
case, shared_ptr itself is complete. Therefore you can have a vector of
shared_ptrs to an incomplete class. I assume that since the member is a
vector of shared_ptrs, that the other vectors are also vectors of
shared_ptrs?
joe
Jan 9 '08 #2

P: n/a
Joe Greer wrote:
massysett <Or***********@gmail.comwrote in
news:31**********************************@h11g2000 prf.googlegroups.com:
>Greetings,

Having classes with member objects that have STL containers of
objects whose definitions are incomplete results in undefined
behavior. See for example:

http://www.ddj.com/database/184403814#8
http://www.parashift.com/c++-faq-lit...sues.html#faq-
39 .14

I am wondering: is it okay to have member functions that return an
STL container with an incomplete type? My member objects do not
contain incomplete types. For instance, would the following code be
OK? Thanks. --Omari

#include <boost/shared_ptr.hpp>
#include <vector>

class HasSelf
{
public:
HasSelf(std::vector<HasSelf>& contents);
std::vector<HasSelfgetContents() const;

private:
std::vector<boost::shared_ptr<HasSelf _contents;
};

shared_ptr<does not require that the class be complete, but in this
case, shared_ptr itself is complete. Therefore you can have a vector
of shared_ptrs to an incomplete class. I assume that since the
member is a vector of shared_ptrs, that the other vectors are also
vectors of shared_ptrs?
That would require at least creating them using some kind of memory
management (like 'new'), which is more expensive and less efficient
than letting a 'vector' handle the entire array of those. Of course,
if legality is the primary concern, it seems like the only viable
solution...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jan 9 '08 #3

P: n/a
On Jan 9, 9:38 pm, Joe Greer <jgr...@doubletake.comwrote:
massysett <OriginalOm...@gmail.comwrote
innews:31**********************************@h11g20 00prf.googlegroups.com:
Having classes with member objects that have STL containers of objects
whose definitions are incomplete results in undefined behavior. See
for example:
http://www.ddj.com/database/184403814#8
http://www.parashift.com/c++-faq-lit...html#faq-39.14
I am wondering: is it okay to have member functions that return an STL
container with an incomplete type? My member objects do not contain
incomplete types. For instance, would the following code be OK?
#include <boost/shared_ptr.hpp>
#include <vector>
class HasSelf
{
public:
HasSelf(std::vector<HasSelf>& contents);
std::vector<HasSelfgetContents() const;
private:
std::vector<boost::shared_ptr<HasSelf _contents;
};
shared_ptr<does not require that the class be complete, but
in this case, shared_ptr itself is complete. Therefore you
can have a vector of shared_ptrs to an incomplete class. I
assume that since the member is a vector of shared_ptrs, that
the other vectors are also vectors of shared_ptrs?
If I understand correctly, the vector isn't his problem. He
knows that that's OK. The problem is the parameter of the
constructor and the return value of getContents.

If I interpret the situation correctly: according to the
standard, it is undefined behavior to instantiate vector with an
incomplete type (and HasSelf only becomes complete at the
closing brace). However (§14.7.1/1), "[...], the class template
is implicitly instantiated when the specialization is referenced
in a context that requires a completely-defined object type or
when the completeness of the class type affects the semantics of
the program." Since a reference or a return value may be an
incomplete type; the compiler should not instantiate the
template in this case, so the code is correct. (On the other
hand, converting between vector< HasSelf and vector<
shared_ptr< HasSelf is typically not a trivial operation.
Quite frankly, I think I'd just use a std::vector< HasSelf >* as
the member.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jan 10 '08 #4

This discussion thread is closed

Replies have been disabled for this discussion.