C++Talk.NET

mzdude · Guest

I'm in the process of cleaning up code that has evolved over the last
6-7 years. In many cases a header file will contain the following:

hdr1.h

struct MyStuff {
// stuff
};
typedef std::vector< MyStuff > StuffArray;

which is O.K. Then another header will have

hdr2.h
#include "hdr1.h" // required for StuffArray definition
void MyFunct( const StuffArray &sa );

which requires the inclusion of hdr1.h for the typedef. I have found
that redefining the original typedef as a class:

hdr1.h
struct MyStuff {
// stuff
};
class StuffArray : public std::vector< MyStuff > {};

I can now do the following in hdr2.h

class StuffArray; // just a forward reference
void MyFunct( const StuffArray &sa );

I know that stl containers aren't designed to be base classes, since
they don't have virtual destructors, but in this case I think it's OK.
Are there any significant drawbacks to the class declaration vs the
typedef? In many cases, by using the forward declaration, significant
compile time dependacies get reduced. I have checked this out with
several different versions of a compiler (not noted for it's adherance
to the standard) and it seems to function correctly.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Paul Rosen · Guest

mzdude wrote:

[...]

Éric Malenfant · Guest

A drawback of the inheritance approach is that you loose std::vector's
constructors. For example, with the typedef you could write:
StuffArray some_array(10);
but can't with the version using inheritance.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Francis Glassborow · Guest

In article <6gRFe.10038$oZ.5296 (AT) newsread2 (DOT) news.atl.earthlink.net>, Paul
Rosen <prosen (AT) fte (DOT) com> writes

Greg · Guest

mzdude wrote:

kanze@gabi-soft.fr · Guest

mzdude wrote:

kanze@gabi-soft.fr · Guest

Paul Rosen wrote:

tony_in_da_uk@yahoo.co.uk · Guest

HI mzdude,

Personally, I think it's a terrible thing to do. This type of "class
X;" forward declaration has all the problems of embedding "extern void
fn();" statements in implementation files. It quickly leads to
unmaintainable code, as the code doesn't break when then real header
changes, and errors notification is delayed to link or run time.

What if the implementer changes StuffArray's type? Your makefiles
won't trigger a recompile, your "class X" won't get updated, and you
may get a run-time crash. If X changes to a typedef again, your link
will break.

If you're concerned about your build times, follow the example of
<iosfwd> and create a fwd-declaration-header with declarations
sufficient for pointers and references to your types, and include that
from both the existing header and your client code. Some projects use
a separate extension or naming for such headers: .hh, .fwd.h etc..

Tony

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

mzdude · Guest

Somehow sprinkling typedefs all over the code seems ... wrong. Too
many years of single definitions to overcome for me to embrace that
particular solution. I did think about a separate header file but
rejected it for the following reason. It increases coupling, which is
what I'm trying to avoid. By putting *all* or most of my typedefs in a
single header file any time one is added, deleted or modified, every
file that includes the common typedef header file will have to be
recompiled, even though the change will not effect most of them.

Our application is split in several dll's (less than 10). A small
change that requires releasing all of them tends to make users
nervous. Not to mention it freaks out the Q/A guys. They like to see a
change limited to 1 or at most 2.

I agree that typedefs tend to stabilize fairly quickly in development.
I would like to find a *style* that can be used for projects that are
new, in development and mature.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

mzdude · Guest

Changing the type *will* force a recompile. Any changes to
MyArrayDef.h file will force the appropriate files to recompile. The
..cpp file that includes the header will realize the change, and
recompile. That's the point. Only the .cpp's effected will recompile.

MyArrayDef.h
struct MyStruct {
//
};
class MyArray : public std::vector< MyStruct > {};

Myfile.h
class MyArray; // forward ref
viod MyFunction( const class MyArray & );

MyFile.cpp
#include "MyFile.h"
#include "MyArrayDef.h" // definition of MyArray required for
file to compile

void MyFunction( const class MyArray &ma )
{
// do good stuff with ma
}

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dave Harris · Guest

[email]jsanga (AT) cox (DOT) net[/email] (mzdude) wrote (abridged):

Dave Harris · Guest

[email]prosen (AT) fte (DOT) com[/email] (Paul Rosen) wrote (abridged):

Dave Harris · Guest

[email]greghe (AT) pacbell (DOT) net[/email] (Greg) wrote (abridged):

tony_in_da_uk@yahoo.co.uk · Guest

Say the programmer who supports MyArrayDef changes the type of MyArray
in MyArrayDef.h. In a large system, they're unlikely to know about all
the client code that uses their class, and will have to assume that
these client systems will detect the change to the header and recompile
if necessary.

Your MyFile.cpp example is safe: and as long as other programs using
MyFile.o proactively trigger MyFile's makefile, which is an entirely
reasonable assumption (if all-too-often overlooked in corporate
systems).

But there are other, more subtle, issues. For example:

- Lib.h declares a traits template and wants traits for MyArray. To
avoid including MyArrayDef.h, it embeds a forward declaration "class
MyArray;". There's nothing keeping these traits in sync with
MyArrayDef.h. Run-time errors result.

- Say a facility stores a pointer to an application-wide "active"
MyArray, which it forward declares. This facility doesn't need to
include MyArrayDef.h anywhere, so it continues to compile unchanged
even if the real MyArray is moved into another namespace, or becomes a
typedef. Only when a client program eventually goes to use the
facility will someone become aware that there's a compilation issue,
and the facility is out of sync. This means the library maintainers
are being reactive rather than proactive in maintaining a working
facility for their clients.

If I had half an hour, I could probably think of better examples, but
at least this establishes that there are some....

Tony

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]