what all a class has by default

[Ajay]

Hi all,
i want to know when i create a class.what all it contains.I
know the following things are there by default if i do not declare them
by myself.Please tell the other things that are left.

1. constructor
2.Destructor
3.Copy constructor
4. Assignment operator

Thanks in advance.

 

[Gavin Deane]

Hi all,
i want to know when i create a class.what all it contains.I
know the following things are there by default if i do not declare them
by myself.Please tell the other things that are left.

1. constructor

You need to be more specific with this one. The compiler will generate
a default constructor (that is, a constructor called with no arguments)
_only_ if you do not declare _any_ constructors.

2.Destructor
3.Copy constructor
4. Assignment operator

Correct. For each of those, if you haven't declared it the compiler
will generate it for you. The "Rule of Three" says that if you need to
define your own implementation of one of those three because the
compiler generated one does the wrong thing, you probably need to
define all three.

Gavin Deane

 

[Guest]

If you do not implement your own Destructor, a compiler maybe generates
one automatically or generates nothing,. BUT it does not generate one
does the wrong thing .

 

[Gavin Deane]

If you do not implement your own Destructor, a compiler maybe generates
one automatically or generates nothing,. BUT it does not generate one
does the wrong thing .

Well I suppose that depends on what one means by "wrong", so let me
clarify.

A conforming compiler will, of course, generate a destructor that does
exactly what the standard says compiler-generated destructors do. So in
that sense, the destructor is not doing the "wrong" thing.

However, given this class

#include <string>

class foo
{
public:
foo() : pstr(new std::string("Leak")) {}
private:
// Let's just disable these
foo(const foo&);
foo& operator=(const foo&);

std::string* pstr;
};

the compiler-generated destructor will not delete the string allocated
in the constructor and so every object of foo type will leak memory
when it is destroyed. This is (presumably) not the behaviour you want
so you need to write the destructor yourself. That's what I mean by the
compiler-generated destructor doing the "wrong" thing. It does exactly
what the standard says it should do, but I need it to do something
else.

Gavin Deane

 

[osmium]

i want to know when i create a class.what all it contains.I
know the following things are there by default if i do not declare them
by myself.Please tell the other things that are left.

1. constructor
2.Destructor
3.Copy constructor
4. Assignment operator

Your list is complete, there ain't no more. The implicit copy constructor,
especially, can really spoil your day if you are a novice. Because a novice
may not be aware that he is even invoking the copy constructor, much less
realize that the CC does not do what he needs to have done. It might be
nice to have a C++ compiler with training wheels that emits the following
message:

"Warning! You have implicitly called the copy constructor. You may be
sorry."

 

[Gernot Frisch]

Your list is complete, there ain't no more. The implicit copy
constructor, especially, can really spoil your day if you are a
novice. Because a novice may not be aware that he is even invoking
the copy constructor, much less realize that the CC does not do what
he needs to have done. It might be nice to have a C++ compiler with
training wheels that emits the following message:

"Warning! You have implicitly called the copy constructor. You may
be sorry."

Even better: The standart should tell the default CC to use the
(default or not) = operator.

 

[Richard Herring]

Even better: The standart should tell the default CC to use the
(default or not) = operator.

Definitely not. The semantics of copy and assign are quite different:
operator= has to clean up the old value before assigning the new one,
while the copy constructor starts with a blank slate

And if operator= is defined (as is common because of this) in terms of
copy and swap, you're inviting infinite recursion.

 

[Guest]

yes , Gavin is right. So I suggest that you implement constructor and
destructor at the same time or nothing.

 

[Ben Pope]

yes , Gavin is right. So I suggest that you implement constructor and
destructor at the same time or nothing.

And if you implement a destructor, you need to either implement the
assignment operator and copy constructor, or disable them.

Ben Pope

 

[Diego Martins]

if you implement ANY constructor, the default constructor is not
generated

at first sight, it seems quite irrelevant, but I had troubles when i
only implemented the COPY constructor

I had to create an empty default constructor because my compiler did
not generate one in this case

 

[Daniel T.]

Hi all,
i want to know when i create a class.what all it contains.I
know the following things are there by default if i do not declare them
by myself.Please tell the other things that are left.

1. constructor
2.Destructor
3.Copy constructor
4. Assignment operator

Thanks in advance.

From Scott Meyers' book:

.... if you write this:

class Empty { };

it's the same as if you'd written this:

class Empty {
public:
Empty() { }
Empty( const Empty& rhs );
~Empty() { }
Empty& operator=( const Empty& rhs );
Empty* operator&() { return this; }
const Empty* operator&() const { return this; }
};

 

[Alf P. Steinbach]

* Daniel T.:

From Scott Meyers' book:

... if you write this:

class Empty { };

it's the same as if you'd written this:

class Empty {
public:
Empty() { }
Empty( const Empty& rhs );
~Empty() { }
Empty& operator=( const Empty& rhs );
Empty* operator&() { return this; }
const Empty* operator&() const { return this; }
};

Uhuh. Did Scott Meyer really write that?

 

[Daniel T.]

* Daniel T.:

Uhuh. Did Scott Meyer really write that?

"Effective C++ Second Edition" by Scott Meyers, item 45.

 

[Alf P. Steinbach]

* Daniel T.:

"Effective C++ Second Edition" by Scott Meyers, item 45.

Well, if that's correct, then the good Scott Meyers is teaching Wrong
Things (TM). There is no automatically generated address operator
member function, and the two classes above are /not/ equivalent. That
means, you can do things with one that you can't with the other:

class Empty1 {};

class Empty2 {
public:
Empty2() { }
Empty2( const Empty2& rhs );
~Empty2() { }
Empty2& operator=( const Empty2& rhs );
Empty2* operator&() { return this; }
const Empty2* operator&() const { return this; }
};

int main()
{
// OK
Empty2& (Empty2::*a)( Empty2 const& ) = &Empty2:perator=;
Empty2 const* (Empty2::*b)() const = &Empty2:perator&;
Empty2* (Empty2::*c)() = &Empty2:perator&;

// OK
Empty1& (Empty1::*d)( Empty1 const& ) = &Empty1:perator=;
// ERROR:
Empty1 const* (Empty1::*e)() const = &Empty1:perator&;
// ERROR:
Empty1* (Empty1::*f)() = &Empty1:perator&;
}

 

[usenet]

From Scott Meyers' book:

... if you write this:

class Empty { };

it's the same as if you'd written this:

class Empty {
public:
Empty() { }
Empty( const Empty& rhs );
~Empty() { }
Empty& operator=( const Empty& rhs );
Empty* operator&() { return this; }
const Empty* operator&() const { return this; }
};

Ah, but from the errata list for that book
(http://www.aristeia.com/BookErrata/ec++2e-errata_frames.html):

A class declaring no operator& function(s) does NOT have them
implicitly declared. Rather, compilers use the built-in address-of
operator whenever "&" is applied to an object of that type. This
behavior, in turn, is technically not an application of a global
operator& function. Rather, it is a use of a built-in operator.

I eliminated mention of operator& as an automatically generated
function and adjusted the index to eliminate entries for the removed
material.

This was fixed in September 2001. I apologize for getting it wrong in
the first place.

I can't help but remark that I encourage you to take a look at the
third edition of the book, which came out about a year ago. Not only
does it not contain errors such as this (*), it includes lots of new
information that I believe is essential for effective C++ programming,
e.g., using objects to manage resources, writing exception-safe code,
implementing traits classes, etc.

Scott

(*) It contains different kinds of errors, sigh. For the current
list, check out
http://www.aristeia.com/BookErrata/ec++3e-errata_frames.html.

 

[Jaspreet]

Your list is complete, there ain't no more. The implicit copy constructor,
especially, can really spoil your day if you are a novice. Because a novice
may not be aware that he is even invoking the copy constructor, much less
realize that the CC does not do what he needs to have done. It might be
nice to have a C++ compiler with training wheels that emits the following
message:

"Warning! You have implicitly called the copy constructor. You may be
sorry."

The list broadly covers what a compiler provides by default for a
class. (That may or may not be what you would really want, as mentioned
in the above post).

However, do we also need to include the & (address of operator) in the
list to be one of the operators which we can use on a class without
explicitly defining it.

For instance..

class myEx {
-----
};

-----

int main() {
myEx *pEx;
myEx aEx;
pEx = &aEx;

 

[Jaspreet]

Ah, but from the errata list for that book
(http://www.aristeia.com/BookErrata/ec++2e-errata_frames.html):

A class declaring no operator& function(s) does NOT have them
implicitly declared. Rather, compilers use the built-in address-of
operator whenever "&" is applied to an object of that type. This
behavior, in turn, is technically not an application of a global
operator& function. Rather, it is a use of a built-in operator.

I eliminated mention of operator& as an automatically generated
function and adjusted the index to eliminate entries for the removed
material.

This was fixed in September 2001. I apologize for getting it wrong in
the first place.

I can't help but remark that I encourage you to take a look at the
third edition of the book, which came out about a year ago. Not only
does it not contain errors such as this (*), it includes lots of new
information that I believe is essential for effective C++ programming,
e.g., using objects to manage resources, writing exception-safe code,
implementing traits classes, etc.

Scott

Thanks for the errata link. I stand corrected that & operator is not
automatically generated.