#include verse class class_name

[Steven T. Hatton]

I will assume many people reading this would never create anything similar
to the example below. So let me preface this with _*IF*_ you were in a
situation where you had to chose between using #includes or forward
declaring each class in diamond.h, which would you choose? Why?

If there is something fundamentally wrong with the way I've approached the
structure of this example, I am interested to know. As for preferences and
tastes, I would really like to stay focused on the question above.

//north.cpp
#include "north.h"
namespace diamond {
North::North(){ }
North::~North() {}
};

//east.cpp
#include "east.h"
namespace diamond {
East::East() : North(){}
East::~East(){}
};

//west.cpp
#include "west.h"
namespace diamond {
West::West() : North(){}
West::~West(){}
};

//south.cpp
#include "south.h"
namespace diamond {
South::South(): East(), West(){}
South::~South() {}
};

//diamond.cpp
#include "diamond.h"
namespace diamond {
Diamond::Diamon d(){}
Diamond::~Diamo nd(){}
};

//north.h
#ifndef DIAMONDNORTH_H
#define DIAMONDNORTH_H
namespace diamond {
class North{
public:
North();
~North();
};
};
#endif

//east.h
#ifndef DIAMONDEAST_H
#define DIAMONDEAST_H
#include "north.h"
namespace diamond {
class East : virtual public North
{
public:
East();
~East();
};
};
#endif

//west.h
#ifndef DIAMONDWEST_H
#define DIAMONDWEST_H
#include "north.h"
namespace diamond {
class West : virtual public North
{
public:
West();
~West();
};
};
#endif

//south.h
#ifndef DIAMONDSOUTH_H
#define DIAMONDSOUTH_H
#include "east.h"
#include "west.h"
namespace diamond {
class South : virtual public East, virtual public West
{
public:
South();
~South();
};
};
#endif

//diamond.h
#ifndef DIAMONDDIAMOND_ H
#define DIAMONDDIAMOND_ H
namespace diamond
{
class Diamond
{
public:
Diamond();
~Diamond();
private:
East e;
North n;
West w;
South s;
};
};

--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Steven T. Hatton]

Correction:Re: #include verse class class_name

Steven T. Hatton wrote:
[color=blue]
> I will assume many people reading this would never create anything similar
> to the example below. So let me preface this with _*IF*_ you were in a
> situation where you had to chose between using #includes or forward
> declaring each class in diamond.h, which would you choose? Why?[/color]

As it turns out, in this case I have to use the #includes. I'm not 100% sure
why that is. I just know it didn't compile, and gave an error saying the
class definitions were incomplete.
[color=blue]
> //diamond.h
> #ifndef DIAMONDDIAMOND_ H
> #define DIAMONDDIAMOND_ H
> namespace diamond
> {[/color]
/*didn't work*/
class East
class West
class North
class South[color=blue]
> class Diamond
> {
> public:
> Diamond();
> ~Diamond();
> private:
> East e;
> North n;
> West w;
> South s;
> };
> };
>[/color]

--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Steven T. Hatton]

Correction:Re: #include verse class class_name

Steven T. Hatton wrote:
[color=blue]
> I will assume many people reading this would never create anything similar
> to the example below. So let me preface this with _*IF*_ you were in a
> situation where you had to chose between using #includes or forward
> declaring each class in diamond.h, which would you choose? Why?[/color]

As it turns out, in this case I have to use the #includes. I'm not 100% sure
why that is. I just know it didn't compile, and gave an error saying the
class definitions were incomplete.
[color=blue]
> //diamond.h
> #ifndef DIAMONDDIAMOND_ H
> #define DIAMONDDIAMOND_ H
> namespace diamond
> {[/color]
/*didn't work*/
class East
class West
class North
class South[color=blue]
> class Diamond
> {
> public:
> Diamond();
> ~Diamond();
> private:
> East e;
> North n;
> West w;
> South s;
> };
> };
>[/color]

--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Pete Vidler]

Re: Correction:Re: #include verse class class_name

Steven T. Hatton wrote:
[snip]

Prefer forward declarations. If you include (unnecessary) other headers
in yours you will slow down compilation without any real benefit.
[color=blue]
> /*didn't work*/
> class East
> class West
> class North
> class South[/color]
[snip][color=blue][color=green]
>> East e;
>> North n;
>> West w;
>> South s;[/color][/color]
[snip]

That's because you stored them by value. The compiler needs to determine
the size of your class.. how can it do this for diamond without the full
data about East, West, etc.

You can only get away with forward declarations in the following
circumstances (might have missed a few):

1) Your class/header never *contains* the forward declared class by value.

2) Your class/header never has a method/function that takes the forward
declared class by value (reference or pointer is fine, as is returning
it by value).

3) Your header never uses the forward declared class for scope
resolution (e.g. East::whatever) .

4) You do not inherit from the forward declared class.

To get around this you can use the compiler firewall idiom:

// diamond.h
#ifndef DIAMONDDIAMOND_ H
#define DIAMONDDIAMOND_ H

namespace diamond
{
class Diamond
{
public:
Diamond();
~Diamond();

private:
// If these aren't private then they need special
// handling to make a copy of the pointer below.
Diamond( const Diamond& ); // Not implemented
Diamond& operator=( const Diamond& ); // Not implemented.

struct Impl;
Impl* impl_;
};
}

#endif // !DIAMONDDIAMOND _H

// diamond.cpp
#include "diamond.h"
#include "north.h"
#include "south.h"
#include "east.h"
#include "west.h"

namespace diamond
{
struct Diamond::Impl
{
// Any constructor/extra members you want here.

East e;
North n;
West w;
South s;
};

Diamond::Diamon d() : impl_( new Impl ) {}
Diamond::~Diamo nd() { delete impl_; }
}

Personally I use a boost::scoped_p tr to hold the impl_ pointer so I
don't have to worry about deleting it. Note also that you need extra
care if the object will be copyable.

If you do want to use scoped_ptr, you must remember to have your
constructor and destructor *after* the Impl class definition. Otherwise
the compiler complains about incomplete types.

See also:

http://www.gotw.ca/gotw/024.htm

http://www.gotw.ca/gotw/028.htm

http://c2.com/cgi/wiki?PimplIdiom

...and many others available from google. The guru of the week archive is
filled with this kind of stuff (www.gotw.ca/gotw).

-- Pete

[Pete Vidler]

Re: Correction:Re: #include verse class class_name

Steven T. Hatton wrote:
[snip]

Prefer forward declarations. If you include (unnecessary) other headers
in yours you will slow down compilation without any real benefit.
[color=blue]
> /*didn't work*/
> class East
> class West
> class North
> class South[/color]
[snip][color=blue][color=green]
>> East e;
>> North n;
>> West w;
>> South s;[/color][/color]
[snip]

That's because you stored them by value. The compiler needs to determine
the size of your class.. how can it do this for diamond without the full
data about East, West, etc.

You can only get away with forward declarations in the following
circumstances (might have missed a few):

1) Your class/header never *contains* the forward declared class by value.

2) Your class/header never has a method/function that takes the forward
declared class by value (reference or pointer is fine, as is returning
it by value).

3) Your header never uses the forward declared class for scope
resolution (e.g. East::whatever) .

4) You do not inherit from the forward declared class.

To get around this you can use the compiler firewall idiom:

// diamond.h
#ifndef DIAMONDDIAMOND_ H
#define DIAMONDDIAMOND_ H

namespace diamond
{
class Diamond
{
public:
Diamond();
~Diamond();

private:
// If these aren't private then they need special
// handling to make a copy of the pointer below.
Diamond( const Diamond& ); // Not implemented
Diamond& operator=( const Diamond& ); // Not implemented.

struct Impl;
Impl* impl_;
};
}

#endif // !DIAMONDDIAMOND _H

// diamond.cpp
#include "diamond.h"
#include "north.h"
#include "south.h"
#include "east.h"
#include "west.h"

namespace diamond
{
struct Diamond::Impl
{
// Any constructor/extra members you want here.

East e;
North n;
West w;
South s;
};

Diamond::Diamon d() : impl_( new Impl ) {}
Diamond::~Diamo nd() { delete impl_; }
}

Personally I use a boost::scoped_p tr to hold the impl_ pointer so I
don't have to worry about deleting it. Note also that you need extra
care if the object will be copyable.

If you do want to use scoped_ptr, you must remember to have your
constructor and destructor *after* the Impl class definition. Otherwise
the compiler complains about incomplete types.

See also:

http://www.gotw.ca/gotw/024.htm

http://www.gotw.ca/gotw/028.htm

http://c2.com/cgi/wiki?PimplIdiom

...and many others available from google. The guru of the week archive is
filled with this kind of stuff (www.gotw.ca/gotw).

-- Pete

[Steven T. Hatton]

Re: Correction:Re: #include verse class class_name

Pete Vidler wrote:
[color=blue]
> That's because you stored them by value. The compiler needs to determine
> the size of your class.. how can it do this for diamond without the full
> data about East, West, etc.[/color]

Based on that, I tried putting the other includes /before/ #include
diamond.h in diamond.cpp. That compiled without even needing forward
declarations. I've already expressed my fondness for headers, so there's no
point in repetition.

#include "east.h"
#include "north.h"
#include "south.h"
#include "west.h"
#include "diamond.h"

namespace diamond
{

Diamond::Diamon d(): n(),e(),w(),s()
{}

Diamond::~Diamo nd()
{}

};

[color=blue]
> To get around this you can use the compiler firewall idiom:
>
> // diamond.h
> #ifndef DIAMONDDIAMOND_ H
> #define DIAMONDDIAMOND_ H
>
> namespace diamond
> {
> class Diamond
> {
> public:
> Diamond();
> ~Diamond();
>
> private:
> // If these aren't private then they need special
> // handling to make a copy of the pointer below.
> Diamond( const Diamond& ); // Not implemented
> Diamond& operator=( const Diamond& ); // Not implemented.
>
> struct Impl;
> Impl* impl_;
> };
> }
>
> #endif // !DIAMONDDIAMOND _H
>
> // diamond.cpp
> #include "diamond.h"
> #include "north.h"
> #include "south.h"
> #include "east.h"
> #include "west.h"
>
> namespace diamond
> {
> struct Diamond::Impl
> {
> // Any constructor/extra members you want here.
>
> East e;
> North n;
> West w;
> South s;
> };
>
> Diamond::Diamon d() : impl_( new Impl ) {}
> Diamond::~Diamo nd() { delete impl_; }
> }[/color]

This looks like a common approach used for implementing APIs in Java.
[color=blue]
> Personally I use a boost::scoped_p tr to hold the impl_ pointer so I
> don't have to worry about deleting it. Note also that you need extra
> care if the object will be copyable.
>
> If you do want to use scoped_ptr, you must remember to have your
> constructor and destructor *after* the Impl class definition. Otherwise
> the compiler complains about incomplete types.
>
> See also:[/color]

This explains the use with API implementations :
[color=blue]
> http://www.gotw.ca/gotw/024.htm[/color]

"In C++, when anything in a class definition changes (even private members)
all users of that class must be recompiled. To reduce these dependencies, a
common technique is to use an opaque pointer to hide some of the
implementation details:"

--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Steven T. Hatton]

Re: Correction:Re: #include verse class class_name

Pete Vidler wrote:
[color=blue]
> That's because you stored them by value. The compiler needs to determine
> the size of your class.. how can it do this for diamond without the full
> data about East, West, etc.[/color]

Based on that, I tried putting the other includes /before/ #include
diamond.h in diamond.cpp. That compiled without even needing forward
declarations. I've already expressed my fondness for headers, so there's no
point in repetition.

#include "east.h"
#include "north.h"
#include "south.h"
#include "west.h"
#include "diamond.h"

namespace diamond
{

Diamond::Diamon d(): n(),e(),w(),s()
{}

Diamond::~Diamo nd()
{}

};

[color=blue]
> To get around this you can use the compiler firewall idiom:
>
> // diamond.h
> #ifndef DIAMONDDIAMOND_ H
> #define DIAMONDDIAMOND_ H
>
> namespace diamond
> {
> class Diamond
> {
> public:
> Diamond();
> ~Diamond();
>
> private:
> // If these aren't private then they need special
> // handling to make a copy of the pointer below.
> Diamond( const Diamond& ); // Not implemented
> Diamond& operator=( const Diamond& ); // Not implemented.
>
> struct Impl;
> Impl* impl_;
> };
> }
>
> #endif // !DIAMONDDIAMOND _H
>
> // diamond.cpp
> #include "diamond.h"
> #include "north.h"
> #include "south.h"
> #include "east.h"
> #include "west.h"
>
> namespace diamond
> {
> struct Diamond::Impl
> {
> // Any constructor/extra members you want here.
>
> East e;
> North n;
> West w;
> South s;
> };
>
> Diamond::Diamon d() : impl_( new Impl ) {}
> Diamond::~Diamo nd() { delete impl_; }
> }[/color]

This looks like a common approach used for implementing APIs in Java.
[color=blue]
> Personally I use a boost::scoped_p tr to hold the impl_ pointer so I
> don't have to worry about deleting it. Note also that you need extra
> care if the object will be copyable.
>
> If you do want to use scoped_ptr, you must remember to have your
> constructor and destructor *after* the Impl class definition. Otherwise
> the compiler complains about incomplete types.
>
> See also:[/color]

This explains the use with API implementations :
[color=blue]
> http://www.gotw.ca/gotw/024.htm[/color]

"In C++, when anything in a class definition changes (even private members)
all users of that class must be recompiled. To reduce these dependencies, a
common technique is to use an opaque pointer to hide some of the
implementation details:"

--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Pete Vidler]

Re: Correction:Re: #include verse class class_name

Steven T. Hatton wrote:[color=blue]
> Pete Vidler wrote:[color=green]
>>That's because you stored them by value. The compiler needs to determine
>>the size of your class.. how can it do this for diamond without the full
>>data about East, West, etc.[/color]
>
> Based on that, I tried putting the other includes /before/ #include
> diamond.h in diamond.cpp. That compiled without even needing forward
> declarations. I've already expressed my fondness for headers, so there's no
> point in repetition.
>
> #include "east.h"
> #include "north.h"
> #include "south.h"
> #include "west.h"
> #include "diamond.h"[/color]

This does not solve your problem. The diamond.h file still requires
those headers, so every source file that includes it will need to
include those headers first. You just shifted the problem onto the
people (and source files) that use your headers.

Much better to use the compiler firewall idiom to free your header file
from requiring east.h, south.h, etc. This way source files that include
diamond.h only need to inlude those headers that are actually required
by that source file (and not by the header).

I believe it's good practice for headers to be self contained. This
means that everything required by the header should be contained in the
header (either by being in the header, being forward declared or by
being #included). In other words, you should be able to #include the
header at the very top of any source file and not get errors.

[snip][color=blue]
> This looks like a common approach used for implementing APIs in Java.[/color]

I have no idea what you're talking about.

[snip][color=blue]
> This explains the use with API implementations :
>[color=green]
>>http://www.gotw.ca/gotw/024.htm[/color]
>
> "In C++, when anything in a class definition changes (even private members)
> all users of that class must be recompiled. To reduce these dependencies, a
> common technique is to use an opaque pointer to hide some of the
> implementation details:"[/color]

What does this have to do with Java APIs?

-- Pete

[Pete Vidler]

Re: Correction:Re: #include verse class class_name

Steven T. Hatton wrote:[color=blue]
> Pete Vidler wrote:[color=green]
>>That's because you stored them by value. The compiler needs to determine
>>the size of your class.. how can it do this for diamond without the full
>>data about East, West, etc.[/color]
>
> Based on that, I tried putting the other includes /before/ #include
> diamond.h in diamond.cpp. That compiled without even needing forward
> declarations. I've already expressed my fondness for headers, so there's no
> point in repetition.
>
> #include "east.h"
> #include "north.h"
> #include "south.h"
> #include "west.h"
> #include "diamond.h"[/color]

This does not solve your problem. The diamond.h file still requires
those headers, so every source file that includes it will need to
include those headers first. You just shifted the problem onto the
people (and source files) that use your headers.

Much better to use the compiler firewall idiom to free your header file
from requiring east.h, south.h, etc. This way source files that include
diamond.h only need to inlude those headers that are actually required
by that source file (and not by the header).

I believe it's good practice for headers to be self contained. This
means that everything required by the header should be contained in the
header (either by being in the header, being forward declared or by
being #included). In other words, you should be able to #include the
header at the very top of any source file and not get errors.

[snip][color=blue]
> This looks like a common approach used for implementing APIs in Java.[/color]

I have no idea what you're talking about.

[snip][color=blue]
> This explains the use with API implementations :
>[color=green]
>>http://www.gotw.ca/gotw/024.htm[/color]
>
> "In C++, when anything in a class definition changes (even private members)
> all users of that class must be recompiled. To reduce these dependencies, a
> common technique is to use an opaque pointer to hide some of the
> implementation details:"[/color]

What does this have to do with Java APIs?

-- Pete

[Steven T. Hatton]

Re: Correction:Re: #include verse class class_name

Pete Vidler wrote:
[color=blue]
> This does not solve your problem. The diamond.h file still requires
> those headers, so every source file that includes it will need to
> include those headers first. You just shifted the problem onto the
> people (and source files) that use your headers.[/color]

So I learned the hard way. As soon as I tried to use it from outside of the
implementation, I was back at square one.

[snip good advice, etc.]
[color=blue]
> What does this have to do with Java APIs?[/color]

I would really have to do some digging to determine how closely the
approaches correspond, but here is one example of API amd implementation
done in Java:

http://xml.apache.org/xerces2-j/javadocs/api/index.html

http://xml.apache.org/xerces2-j/javadocs/xerces2/index.html

--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Steven T. Hatton]

Re: Correction:Re: #include verse class class_name

Pete Vidler wrote:
[color=blue]
> This does not solve your problem. The diamond.h file still requires
> those headers, so every source file that includes it will need to
> include those headers first. You just shifted the problem onto the
> people (and source files) that use your headers.[/color]

So I learned the hard way. As soon as I tried to use it from outside of the
implementation, I was back at square one.

[snip good advice, etc.]
[color=blue]
> What does this have to do with Java APIs?[/color]

I would really have to do some digging to determine how closely the
approaches correspond, but here is one example of API amd implementation
done in Java:

http://xml.apache.org/xerces2-j/javadocs/api/index.html

http://xml.apache.org/xerces2-j/javadocs/xerces2/index.html

--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Howard]

Re: Correction:Re: #include verse class class_name


"Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote in message
news:IoKdnUq4gv pPtujd4p2dnA@sp eakeasy.net...[color=blue]
> Steven T. Hatton wrote:
>[color=green]
> > I will assume many people reading this would never create anything[/color][/color]
similar[color=blue][color=green]
> > to the example below. So let me preface this with _*IF*_ you were in a
> > situation where you had to chose between using #includes or forward
> > declaring each class in diamond.h, which would you choose? Why?[/color]
>
> As it turns out, in this case I have to use the #includes. I'm not 100%[/color]
sure[color=blue]
> why that is. I just know it didn't compile, and gave an error saying the
> class definitions were incomplete.
>[color=green]
> > //diamond.h
> > #ifndef DIAMONDDIAMOND_ H
> > #define DIAMONDDIAMOND_ H
> > namespace diamond
> > {[/color]
> /*didn't work*/
> class East
> class West
> class North
> class South[color=green]
> > class Diamond
> > {
> > public:
> > Diamond();
> > ~Diamond();
> > private:
> > East e;
> > North n;
> > West w;
> > South s;
> > };
> > };
> >[/color]
>
> --[/color]

You could store pointers instead of the objects themselves, and instantiate
them in your Diamond constructor. That only requires that your diamond.cpp
file include those other headers instead of including them in diamond.h.
(Of course, then you have to maintain those pointers yourself.)
-Howard

[Howard]

Re: Correction:Re: #include verse class class_name


"Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote in message
news:IoKdnUq4gv pPtujd4p2dnA@sp eakeasy.net...[color=blue]
> Steven T. Hatton wrote:
>[color=green]
> > I will assume many people reading this would never create anything[/color][/color]
similar[color=blue][color=green]
> > to the example below. So let me preface this with _*IF*_ you were in a
> > situation where you had to chose between using #includes or forward
> > declaring each class in diamond.h, which would you choose? Why?[/color]
>
> As it turns out, in this case I have to use the #includes. I'm not 100%[/color]
sure[color=blue]
> why that is. I just know it didn't compile, and gave an error saying the
> class definitions were incomplete.
>[color=green]
> > //diamond.h
> > #ifndef DIAMONDDIAMOND_ H
> > #define DIAMONDDIAMOND_ H
> > namespace diamond
> > {[/color]
> /*didn't work*/
> class East
> class West
> class North
> class South[color=green]
> > class Diamond
> > {
> > public:
> > Diamond();
> > ~Diamond();
> > private:
> > East e;
> > North n;
> > West w;
> > South s;
> > };
> > };
> >[/color]
>
> --[/color]

You could store pointers instead of the objects themselves, and instantiate
them in your Diamond constructor. That only requires that your diamond.cpp
file include those other headers instead of including them in diamond.h.
(Of course, then you have to maintain those pointers yourself.)
-Howard

[Steven T. Hatton]

Re: Correction:Re: #include verse class class_name

Howard wrote:
[color=blue]
> You could store pointers instead of the objects themselves, and
> instantiate
> them in your Diamond constructor. That only requires that your
> diamond.cpp file include those other headers instead of including them in
> diamond.h. (Of course, then you have to maintain those pointers yourself.)
> -Howard[/color]

That is my prefered approach. I just did it with the value members to see
what happened. Most of the code I've written that does anything other than
dump a few lines of text uses Qt. That takes care of most of the need to
release memory without me having to do anything.

I guess I sould start working some of the problems in TC++PL(SE). Just
reading the text really isn't enough.

--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Steven T. Hatton]

Re: Correction:Re: #include verse class class_name

Howard wrote:
[color=blue]
> You could store pointers instead of the objects themselves, and
> instantiate
> them in your Diamond constructor. That only requires that your
> diamond.cpp file include those other headers instead of including them in
> diamond.h. (Of course, then you have to maintain those pointers yourself.)
> -Howard[/color]

That is my prefered approach. I just did it with the value members to see
what happened. Most of the code I've written that does anything other than
dump a few lines of text uses Qt. That takes care of most of the need to
release memory without me having to do anything.

I guess I sould start working some of the problems in TC++PL(SE). Just
reading the text really isn't enough.

--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org