A question about the rule of three....

[SpreadTooThin]

I have a class
class myImage: public std::list<myObject>
{
private:
std::string myImageName;
unsigned long size;
public:
myImage(void);
myImage & operator=(const myImage &i);
myImage(const myImage &i);
~myImage(void);

// There is no public data.
// A bunch of methods...
};

My question is:

as there is no use of 'new' is there anything that needs be done in
the
assignment operator, copy constructor and destructor?
specifically... the std::list<myObjectthat this class is deriving
from...

Is there any point in defining these three in this class?
Shouldn't the list of objects, the name and size be copied and
destroyed automatically?

[dasjotre]

On 13 Jun, 17:27, SpreadTooThin <[e-mail]:

I have a class
class myImage: public std::list<myObject>
{
private:
std::string myImageName;
unsigned long size;
public:
myImage(void);
myImage & operator=(const myImage &i);
myImage(const myImage &i);
~myImage(void);

// There is no public data.
// A bunch of methods...

};

My question is:

as there is no use of 'new' is there anything that needs be done in
the
assignment operator, copy constructor and destructor?
specifically... the std::list<myObjectthat this class is deriving
from...

you should know whether something else needs to be
done since you're the one who designed this class.

if you write
class myImage: public std::list<myObject>
{
private:
std::string myImageName;
unsigned long size;
};

compiler will generate default constructor,
copy constructor, assignment operator and
destructor. all doing what you would expect
them to do.

default constructor will call default constructor
of the base and members, copy constructor
will call copy constructors of the base and of
the members, etc...

Is there any point in defining these three in this class?

not unless compiler generated ones are not sufficient.

Shouldn't the list of objects, the name and size be copied and
destroyed automatically?

Of course.

DS

[Zeppe]

SpreadTooThin wrote:

I have a class
class myImage: public std::list<myObject>
{
private:
std::string myImageName;
unsigned long size;
public:
myImage(void);
myImage & operator=(const myImage &i);
myImage(const myImage &i);
~myImage(void);

// There is no public data.
// A bunch of methods...
};

My question is:

as there is no use of 'new' is there anything that needs be done in
the
assignment operator, copy constructor and destructor?
specifically... the std::list<myObjectthat this class is deriving
from...

Is there any point in defining these three in this class?
Shouldn't the list of objects, the name and size be copied and
destroyed automatically?

yes, the list will be destroyed and allocated properly, you needn't
worry about that. However, are you sure that you want to derive from
std::list? It seems a little bit strange, because conceptually an image
is not a list of object. Consider a std::list member if you don't
actually need a list interface, in order to improve the information hiding.

Also, the size is not the same as the size of the list, is it?

Regards,

Zeppe

[SpreadTooThin]

On Jun 13, 11:09 am, Zeppe
<zep_p@.remove.all.this.long.comment.yahoo.itwrote :

SpreadTooThin wrote:

I have a class
class myImage: public std::list<myObject>
{
private:
std::string myImageName;
unsigned long size;
public:
myImage(void);
myImage & operator=(const myImage &i);
myImage(const myImage &i);
~myImage(void);

// There is no public data.
// A bunch of methods...
};

My question is:

as there is no use of 'new' is there anything that needs be done in
the
assignment operator, copy constructor and destructor?
specifically... the std::list<myObjectthat this class is deriving
from...

Is there any point in defining these three in this class?
Shouldn't the list of objects, the name and size be copied and
destroyed automatically?

yes, the list will be destroyed and allocated properly, you needn't
worry about that. However, are you sure that you want to derive from
std::list? It seems a little bit strange, because conceptually an image
is not a list of object. Consider a std::list member if you don't
actually need a list interface, in order to improve the information hiding.

Also, the size is not the same as the size of the list, is it?

Regards,

Zeppe

Well in this instance it kinda is a list of objects.. Its like a tiff
file.
and ya I think your right it probably is a better idea to stash the
list as a private memeber variable.

[Zeppe]

SpreadTooThin wrote:

On Jun 13, 11:09 am, Zeppe
<zep_p@.remove.all.this.long.comment.yahoo.itwrote :

>SpreadTooThin wrote:

>>I have a class
class myImage: public std::list<myObject>
{
private:
std::string myImageName;
unsigned long size;
public:
myImage(void);
myImage & operator=(const myImage &i);
myImage(const myImage &i);
~myImage(void);
// There is no public data.
// A bunch of methods...
};
My question is:
as there is no use of 'new' is there anything that needs be done in
the
assignment operator, copy constructor and destructor?
specifically... the std::list<myObjectthat this class is deriving
from...
Is there any point in defining these three in this class?
Shouldn't the list of objects, the name and size be copied and
destroyed automatically?

yes, the list will be destroyed and allocated properly, you needn't
worry about that. However, are you sure that you want to derive from
std::list? It seems a little bit strange, because conceptually an image
is not a list of object. Consider a std::list member if you don't
actually need a list interface, in order to improve the information hiding.

Also, the size is not the same as the size of the list, is it?

Regards,

Zeppe

Well in this instance it kinda is a list of objects.. Its like a tiff
file.
and ya I think your right it probably is a better idea to stash the
list as a private memeber variable.

It is useful also if you don't want to give access to the data in the
list directly, but you want to perform some action for example before
the insertion/deletion....
and a small suggestion: usually one may want to derive from a standard
container in order to use the standard library algorithms, which can ba
an advantage. But you can do that with a member variable providing
access to the iterators and the typedefs in order to hide the iterator
types:

class MyImage
{
public:
typedef std::list<MyObject>::iterator iterator;
typedef std::list<MyObject>::const_iterator const_iterator;

const_iterator begin() const { return components_.begin(); }
const_iterator end() const { return components_.end(); }
iterator begin() { return components_.begin(); }
iterator end() { return components_.end(); }

// something to insert and delete the parts in a safe way

private:
std::list<MyObjectcomponents_;
};

in this way you can also easily decide to change container at any time.

Regards,

Zeppe

[SpreadTooThin]

On Jun 13, 11:25 am, Zeppe
<zep_p@.remove.all.this.long.comment.yahoo.itwrote :

SpreadTooThin wrote:

On Jun 13, 11:09 am, Zeppe
<zep_p@.remove.all.this.long.comment.yahoo.itwrote :

SpreadTooThin wrote:
I have a class
class myImage: public std::list<myObject>
{
private:
std::string myImageName;
unsigned long size;
public:
myImage(void);
myImage & operator=(const myImage &i);
myImage(const myImage &i);
~myImage(void);
// There is no public data.
// A bunch of methods...
};
My question is:
as there is no use of 'new' is there anything that needs be done in
the
assignment operator, copy constructor and destructor?
specifically... the std::list<myObjectthat this class is deriving
from...
Is there any point in defining these three in this class?
Shouldn't the list of objects, the name and size be copied and
destroyed automatically?
yes, the list will be destroyed and allocated properly, you needn't
worry about that. However, are you sure that you want to derive from
std::list? It seems a little bit strange, because conceptually an image
is not a list of object. Consider a std::list member if you don't
actually need a list interface, in order to improve the information hiding.

Also, the size is not the same as the size of the list, is it?

Regards,

Zeppe

Well in this instance it kinda is a list of objects.. Its like a tiff
file.
and ya I think your right it probably is a better idea to stash the
list as a private memeber variable.

It is useful also if you don't want to give access to the data in the
list directly, but you want to perform some action for example before
the insertion/deletion....
and a small suggestion: usually one may want to derive from a standard
container in order to use the standard library algorithms, which can ba
an advantage. But you can do that with a member variable providing
access to the iterators and the typedefs in order to hide the iterator
types:

class MyImage
{
public:
typedef std::list<MyObject>::iterator iterator;
typedef std::list<MyObject>::const_iterator const_iterator;

const_iterator begin() const { return components_.begin(); }
const_iterator end() const { return components_.end(); }
iterator begin() { return components_.begin(); }
iterator end() { return components_.end(); }

// something to insert and delete the parts in a safe way

private:
std::list<MyObjectcomponents_;

};

in this way you can also easily decide to change container at any time.

Regards,

Zeppe- Hide quoted text -

- Show quoted text -

Very nice.. Thank you. :)

[James Kanze]

On Jun 13, 6:27 pm, SpreadTooThin <[e-mail]:

I have a class
class myImage: public std::list<myObject>
{
private:
std::string myImageName;
unsigned long size;
public:
myImage(void);
myImage & operator=(const myImage &i);
myImage(const myImage &i);
~myImage(void);

// There is no public data.
// A bunch of methods...
};

My question is:

as there is no use of 'new' is there anything that needs be
done in the assignment operator, copy constructor and
destructor? specifically... the std::list<myObjectthat this
class is deriving from...

Is there any point in defining these three in this class?

Yes. As others have pointed out, the default versions provided
by the compiler do have the appropriate semantics (probably).
But they are inline, and they are, in this case, far from
trivial, so not providing them yourself may result in
significant code bloat and unnecessary compiler dependencies.

--
James Kanze (GABI Software, from CAI) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Gavin Deane]

On 14 Jun, 08:44, James Kanze <[e-mail]:

On Jun 13, 6:27 pm, SpreadTooThin <[e-mail]:

I have a class
class myImage: public std::list<myObject>
{
private:
std::string myImageName;
unsigned long size;
public:
myImage(void);
myImage & operator=(const myImage &i);
myImage(const myImage &i);
~myImage(void);
// There is no public data.
// A bunch of methods...
};
My question is:
as there is no use of 'new' is there anything that needs be
done in the assignment operator, copy constructor and
destructor? specifically... the std::list<myObjectthat this
class is deriving from...
Is there any point in defining these three in this class?

Yes. As others have pointed out, the default versions provided
by the compiler do have the appropriate semantics (probably).
But they are inline, and they are, in this case, far from
trivial, so not providing them yourself may result in
significant code bloat and unnecessary compiler dependencies.

Why compiler dependencies? Are you suggesting that some aspect of the
compiler-generated functions has implementation-defined behaviour?

Gavin Deane

[Default User]

SpreadTooThin wrote:
[very large snip]

>
Very nice.. Thank you. :)

Please trim your quotes to the minimum needed for context.


Brian

[Gennaro Prota]

On Thu, 14 Jun 2007 03:47:22 -0700, Gavin Deane wrote:

>Yes. As others have pointed out, the default versions provided
by the compiler do have the appropriate semantics (probably).
But they are inline, and they are, in this case, far from
trivial, so not providing them yourself may result in
significant code bloat and unnecessary compiler dependencies.

Why compiler dependencies? Are you suggesting that some aspect of the
compiler-generated functions has implementation-defined behaviour?

No no, don't panic :-) He meant "unnecessary compile-time
dependencies" (IOWS unnecessary recompilations).

--
Gennaro Prota -- Need C++ expertise? I'm available
https://sourceforge.net/projects/breeze/
(replace 'address' with 'name.surname' to mail)

[Gennaro Prota]

On Fri, 15 Jun 2007 10:40:28 +0200, Gennaro Prota wrote:

(IOWS unnecessary recompilations).

^^^^

And I meant *IOW :-)

--
Gennaro Prota -- Need C++ expertise? I'm available
https://sourceforge.net/projects/breeze/
(replace 'address' with 'name.surname' to mail)