0

I'm stuck with two .hpp files that have a lot of classes / methods that share same names and so on. My problem is that A.hpp is wrapped inside a namespace so I can use whatever I want using> A::className objName(...);

But I don't know how to use anything from B.hpp, which is not wrapped inside namespace, so I can't write B::className objName(...).

Process of demanding access to change any of .hpp files (where I would just wrap B inside namespace) would take about a day, so I'm looking for alternate and quicker solution.

Thank you.

Rorschach
  • 734
  • 2
  • 7
  • 22
  • If it is not wrapped within a namespace B, then just skip B:: and use the names directly after doing a #include "B.hpp" – MSS Dec 11 '18 at 08:42
  • I tried, can't do it. It still says that "reference to `Class` is ambiguous" – Rorschach Dec 11 '18 at 09:05
  • @Rorschach If that's the case can you wrap B in a namespace? If the two share named functions/members it would be a good idea to have separate namespaces for them anyway – Tom Dec 11 '18 at 09:15
  • @Tom yes, as I said I would need to send emails to sysadmin, wait for them to `chmod` this file, blah blah, that's why I'm looking for alternative. But yes, I'm sure that would work. – Rorschach Dec 11 '18 at 09:23
  • There's probably "using namespace A" somewhere, try removing it. – n. m. could be an AI Dec 11 '18 at 09:29
  • didnt find a dupe but this is related https://stackoverflow.com/questions/7662802/regarding-the-global-namespace-in-c – 463035818_is_not_an_ai Dec 11 '18 at 09:52

1 Answers1

2

First, and potentially safest, you can explicitly qualify look up in the global scope by prefixing a name with the unary scope operator :::

::classFromB foo(/*...*/);
::globalFuncFromB( foo, &::globalVarFromB ); // Obviously this gets rather tedious.

Second, assuming no using directives (using namespace A;) or declarations (using conflictsWithB = A::className), or other declarations, produce a conflict, you can generally rely on unqualified look up:

classFromB foo(/*...*/);
globalFuncFromB( foo, &globalVarFromB  );

Finally, you can wrap the entire contents of an included file in a namespace:

namespace B {
#include "B.hpp"
}

This has numerous potential problems, particularly if any declarations in B.hpp are assumed to be or actually defined either in the header itself or elsewhere (implementation B.cpp?) in global scope. Not the best idea, but sometimes useful. Be very cautious if you consider this approach.

pandorafalters
  • 162
  • 10
  • Thank you, first option works nice, and it will work until I get access to change files and wrap everything in two separate namespaces. – Rorschach Dec 11 '18 at 09:31
  • Wrapping inclusion of a header file in a namespace won't work if any functions or objects declared in `B.hpp` are defined in separate compilation unit. In particular, it won't work if the source for those functions or that defines those objects is unavailable (e.g. only available in a compiled object or library). – Peter Dec 11 '18 at 09:32
  • @Peter That was the intended meaning of my note following that option. Essentially that it _can_ work, but often _won't_ - or even produce a mixture of parts that work and parts that don't. – pandorafalters Dec 11 '18 at 09:37
  • @pandorafalters - probably will be easier to say that it only works if the header defines everything that it declares. For example, it will work if B is a header-only library (and the namespace `B` is not `std` or an alias for it, since declaring names in `std` gives undefined behaviour in all but some specific cases). – Peter Dec 11 '18 at 09:51
  • @Peter I was attempting, perhaps badly, to address the broadest range of possibilities in a short warning. For example, even a header-only library may fail when included into a namespace if any of its "internal" lookups are explicitly qualified. – pandorafalters Dec 11 '18 at 10:11