If I have the following classes:

class B {};
typedef B tB;

if A is:

class A
{

On 20 Aug, 14:31, nguillot <nicolas.guil...@gmail.com> wrote:

If I have the following classes:

class B {};
typedef B tB;

if A is:

class A
{
    void f(B* pB) {}

But what for typedef:

if A is:

class A
{
    void f(tB* pB) {}

I tried several syntax, but finally, is it possible to declare a
typedef like we do for a class?

// A.h
#ifndef A_H_
#define A_H_

#include <iostream>
#include "B.h"

class A
{
  public:
    void f(const tB& rb)
    {
      std::cout << "n = ";
      std::cout << rb.get();
      std::cout << std::endl;
    }

// B.h
#ifndef B_H_
#define B_H_

class B
{
  int n;
public:
  B() : n(99) { }
  int get() const { return n; }

#endif

// test.cpp
#include "A.h"

int main()
{
  A a;
  tB b;
  a.f( b );

If the developer of the header declaring B thinks including the header
imposes (or may one day impose) a significant performance penalty,
they should provide a forward-declaration header (e.g. <iosfwd>
instead of <iostream>).  If they haven't provided such a header, and
you can't talk them into doing so, and you're working on a non-trivial
project with many source files using their header, then you can create
and maintain a single forward-declaration header yourself.  Still
painful, but at least centralised.

Declaring things that the B-developer is quite entitled to change at
any time (e.g. from a class to a typedef to a template instantiation)
is as bad as the olden-days habit of not using headers, and having
extern declarations for the extra-translation-unit functions you plan
to call....

To make the most of your build tools (e.g. make), you have to work in
with their logic about recompilation, not fight it with hacks.
Changes with compatible usage should trigger a rebuild.

    // A.h

    class B;

    typedef B tB;

I disagree, at least in the case where I am the author of class B and
can change both B and the code which uses it whenever needed.
Bringing down compilation times is worth a lot, in my opinion.  I also
prefer my code seeing as few names as possible, even if everything is
in namespaces and there are no macros with too generic names.

To answer the original question a bit: I think the problem he sees
with typedefs is a reason many people prefer not to typedef classes.

/Jorgen

This would seem to indicate that some .CPP file includes both
A.h and B.h.

As others have said, you want to resist this scheme.
If you absolutely need it, can't do without it, then...

So what to do about that? Well, clearly what you need is
some kind of include guard. Getting down to the level of
individual typedefs is, maybe, a little finicky.

But as somebody suggested, you want a Bfwd, or forward
defn header. And it gets its own include guards. If you
have control of both B.h and A.h then you can have B.h
include Bfwd.h for the typedef, and that way make sure
it is identical in  both B.h and A.h.

To answer to some comments:

I don't see why typedef B tB; is ugly.
If B is std::map<std::string, std::.....> the typedef is worth.
With the typedef I can write tB::iterator, instead of
std::map<std::string, std::.....>::iterator.
And it factorizes the code.

About providing compileable code, so you only can guess... Do you
really think it's a problem.
I guess the problem was explain (and the problem is not about pointer
or reference), it's about including header or forwarding declarations;
and how to forward the declaration of a typedef. Not more about
protecting header with the guard #ifdef...
But sorry if my question was not clear.

My main question was indeed (but I learned the correct vocabulary by
reading your answers):
how to forward declare a typedef.

About using headers instead of forward declaration, I guess it's a
real debate. Good authors defend one way or the other.

For my problem, I would need this forward declaration to decrease the
compilation time (really decrease!).
A.h as B.h are my code, I have access to it.

So because it's really worth to decrease compilation time, the
solution would to provide a forward header... I'll try that way.

As a library developer defining a class X in a header, I would argue
that you are entitled to replace it with "template <typename T> class
XT {...}; typedef XT<int> X;", as well-written client code that
includes your header will seamlessly recompile and work.  This is
standard practice when evolving code is generalised to arbitrary
types.

But - silently from the perspective of the library developer who
doesn't necessarily know about all client usage or trigger client app
recompilation - poorly-written client code hard-coding "class X;" will
break.  Scenario: Some production issue requires a urgent bug fix and
instead the app developer finds unrelated parts of their app aren't
compiling any more and must be fixed simultaneously, delaying
deployment of the fix.  If the library developer considers their
clients as part of their overall "system" (a responsible attitude and
generally expected in corporate life at least), then yes their change
broke their system.  But they're not really to blame....

Can it be worse?  Probably.  Thinking about all the combinations of
layers of objects, headers, static vs load-time vs run-time binding
etc. does my head in and I'd need a better reason for suffering that
than this thread.

About the best that can be said is that at least some of these issues
differ from extern function abuses, where the consequences are more
consistently in the SIGSEGV category ;-).