Queries regarding namespaces and typedef

[Konstantinos]

Hi all,

I have developed a routing protocol which is inside its own namespace and uses a typedef for the definition of a set as follows:

filename: clwpr-repositories.cc

namespace ns3 {
namespace clwpr {
... // other stuff here

typedef std::vector<NeighborTuple> NeighborSet; ///< Neighbor Set type.

} // end clwpr
} // end ns3

In a similar way, OLSR has defined the same NeighborSet type, basically because I used OLSR as base of my protocol.

filename: olsr-repositories.cc

namespace ns3 {
namespace olsr {
... // other stuff here

typedef std::vector<NeighborTuple> NeighborSet; ///< Neighbor Set type.

} // end olsr
} // end ns3

When I create a scenario with both module headers (i.e. manet-routing-compare file) I get the following error:

./ns3/clwpr-state.h:40: error: reference to 'NeighborSet' is ambiguous
./ns3/clwpr-repositories.h:299: error: candidates are: typedef class std::vector<ns3::clwpr::NeighborTuple, std::allocator<ns3::clwpr::NeighborTuple> > ns3::clwpr::NeighborSet
./ns3/olsr-repositories.h:292: error: typedef class std::vector<ns3::olsr::NeighborTuple, std::allocator<ns3::olsr::NeighborTuple> > ns3::olsr::NeighborSet
./ns3/clwpr-state.h:40: error: 'NeighborSet' does not name a type

In the complaining file (clwpr-state.h) I have specified "using namespace clwpr;" which should solve the problem of the ambiguity, right?

Any ideas?

Regards,

Konstantinos

[Tommaso Pecorella]

On Tuesday, April 22, 2014 6:25:47 PM UTC+2, Konstantinos wrote:

Hi all,

[...]

In the complaining file (clwpr-state.h) I have specified "using namespace clwpr;" which should solve the problem of the ambiguity, right?

Wrong... that's what you should avoid. See for example http://stackoverflow.com/questions/14575799/using-namespace-std-in-a-header-file

Basically using a "using namespace" in a header file is to avoid at all cost. 

To understand why, remember how header inclusion works: by substituting the #include directive with the header's file content. Then the preprocessor does its magics.

If you have a "using namespace" in a header, the following included headers will use that namespace as well, with funny (not really) results.

In this case, the olsr header found the "using namespace clwpr" directive and it isn't happy about it.

Cheers,

T.

[Konstantinos]

Alrighty then... 

that will give me another bug submission for OLSR that does exactly that 

using namespace olsr;

in a header file!

Cheers,

K.

[Konstantinos]

https://www.nsnam.org/bugzilla/show_bug.cgi?id=1903 

[Tommaso Pecorella]

Totally right :)

T.