473,796 Members | 2,903 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

#include verse class class_name

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
Jul 22 '05 #1
28 2023
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;
};
};


--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #2
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;
};
};


--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #3
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.
/*didn't work*/
class East
class West
class North
class South

[snip]
East e;
North n;
West w;
South s;

[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
Jul 22 '05 #4
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.
/*didn't work*/
class East
class West
class North
class South

[snip]
East e;
North n;
West w;
South s;

[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
Jul 22 '05 #5
Pete Vidler wrote:
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.
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()
{}

};

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_; }
}
This looks like a common approach used for implementing APIs in Java.
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:
This explains the use with API implementations :
http://www.gotw.ca/gotw/024.htm


"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
Jul 22 '05 #6
Pete Vidler wrote:
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.
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()
{}

};

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_; }
}
This looks like a common approach used for implementing APIs in Java.
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:
This explains the use with API implementations :
http://www.gotw.ca/gotw/024.htm


"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
Jul 22 '05 #7
Steven T. Hatton wrote:
Pete Vidler wrote:
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.
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"


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] This looks like a common approach used for implementing APIs in Java.
I have no idea what you're talking about.

[snip] This explains the use with API implementations :
http://www.gotw.ca/gotw/024.htm


"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:"


What does this have to do with Java APIs?

-- Pete
Jul 22 '05 #8
Steven T. Hatton wrote:
Pete Vidler wrote:
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.
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"


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] This looks like a common approach used for implementing APIs in Java.
I have no idea what you're talking about.

[snip] This explains the use with API implementations :
http://www.gotw.ca/gotw/024.htm


"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:"


What does this have to do with Java APIs?

-- Pete
Jul 22 '05 #9
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
Jul 22 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

28
1806
by: Steven T. Hatton | last post by:
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...
0
9679
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
10223
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10172
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10003
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
7546
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5441
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5573
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
3730
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
2924
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.