#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]

Pete Vidler wrote:

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.
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.]
What does this have to do with Java APIs?

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/java...es2/index.html
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

[Howard]

"Steven T. Hatton" <su******@setid ava.kushan.aa> wrote in message
news:Io******** ************@sp eakeasy.net...

Steven T. Hatton wrote:

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?
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.

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

/*didn't work*/
class East
class West
class North
class South

class Diamond
{
public:
Diamond();
~Diamond();
private:
East e;
North n;
West w;
South s;
};
};

--

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]

"Steven T. Hatton" <su******@setid ava.kushan.aa> wrote in message
news:Io******** ************@sp eakeasy.net...

Steven T. Hatton wrote:

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?
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.

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

/*didn't work*/
class East
class West
class North
class South

class Diamond
{
public:
Diamond();
~Diamond();
private:
East e;
North n;
West w;
South s;
};
};

--

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]

Howard wrote:

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

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]

Howard wrote:

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

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

[red floyd]

"Steven T. Hatton" <su******@setid ava.kushan.aa> wrote in message news:<Io******* *************@s peakeasy.net>.. .

Steven T. Hatton wrote:
[redacted]

Because in order to derive from a class, it must be fully defined
(note to Standards Gurus, my terminology may be off).

The compiler must know the full definition of the parent class before
it can be derived, so that it can know about any virtual base classes,
etc... as well as vtbl layout, and how much storage to allocate for
the base class.

Example:

class B;
class D : public B
{
public:
int x;
D(int);

D d;
-- end example

How does the compiler know how big to make D?

[red floyd]

"Steven T. Hatton" <su******@setid ava.kushan.aa> wrote in message news:<Io******* *************@s peakeasy.net>.. .

Steven T. Hatton wrote:
[redacted]

Because in order to derive from a class, it must be fully defined
(note to Standards Gurus, my terminology may be off).

The compiler must know the full definition of the parent class before
it can be derived, so that it can know about any virtual base classes,
etc... as well as vtbl layout, and how much storage to allocate for
the base class.

Example:

class B;
class D : public B
{
public:
int x;
D(int);

D d;
-- end example

How does the compiler know how big to make D?

[Steven T. Hatton]

red floyd wrote:

"Steven T. Hatton" <su******@setid ava.kushan.aa> wrote in message
news:<Io******* *************@s peakeasy.net>.. .

Steven T. Hatton wrote:
[redacted]
Because in order to derive from a class, it must be fully defined
(note to Standards Gurus, my terminology may be off).

The compiler must know the full definition of the parent class before
it can be derived, so that it can know about any virtual base classes,
etc... as well as vtbl layout, and how much storage to allocate for
the base class.

Example:

class B;
class D : public B
{
public:
int x;
D(int);

D d;
-- end example

My example wasn't using inheritance, but the the same argument probably
applies.
How does the compiler know how big to make D?

That wasn't the part I was uncertain of. It was why the implementation
wasn't available to the compiler at the time. It turns out I probably was
correct regarding the assumption that the implementation was part of the
translation unit. But it seems the forward declaration was not sufficient
to get the compiler to postpone the attempt to process the class
definition. I think the answer is probably in Clause 2 of PL-C++03 (The
Standard).
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

[Steven T. Hatton]

red floyd wrote:

"Steven T. Hatton" <su******@setid ava.kushan.aa> wrote in message
news:<Io******* *************@s peakeasy.net>.. .

Steven T. Hatton wrote:
[redacted]
Because in order to derive from a class, it must be fully defined
(note to Standards Gurus, my terminology may be off).

The compiler must know the full definition of the parent class before
it can be derived, so that it can know about any virtual base classes,
etc... as well as vtbl layout, and how much storage to allocate for
the base class.

Example:

class B;
class D : public B
{
public:
int x;
D(int);

D d;
-- end example

My example wasn't using inheritance, but the the same argument probably
applies.
How does the compiler know how big to make D?

That wasn't the part I was uncertain of. It was why the implementation
wasn't available to the compiler at the time. It turns out I probably was
correct regarding the assumption that the implementation was part of the
translation unit. But it seems the forward declaration was not sufficient
to get the compiler to postpone the attempt to process the class
definition. I think the answer is probably in Clause 2 of PL-C++03 (The
Standard).
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

[Steven T. Hatton]

Steven T. Hatton wrote:

That wasn't the part I was uncertain of. It was why the implementation
wasn't available to the compiler at the time. It turns out I probably was
correct regarding the assumption that the implementation was part of the
translation unit. But it seems the forward declaration was not sufficient
to get the compiler to postpone the attempt to process the class
definition. I think the answer is probably in Clause 2 of PL-C++03 (The
Standard).

In the simplest terms my question is this:
what's the formal rule that tells me this won't compile?

struct A;

struct D {
A a;
};

struct A {};

int main(){}
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org