Ambiguous symbol. Need to keep both namespaces

Question

I'm reading from an Oculus Rift and writing via serial to control an Arduino, but I'm having some problems with namespaces since I'm new to C++.

The beginning of my code goes like this:

#using <System.dll>

#include "OVR.h"
#include <iostream>
#include <conio.h>

using namespace System;
using namespace System::IO::Ports;
using namespace System::Threading;
using namespace OVR;

The original error ocurred when I tried to use String, since it is defined in both System and OVR. I changed the code to System::String but now I got an error telling me that System is ambiguous because it is already defined in OVR::System

Is there some way to avoid this conflict? Some way to exclude OVR::String and OVR::System from being affected by the 'using' clause? I can't get rid of one of the 'using' clauses because I have a lot of reference to the members of those namespaces in my code.

Answer 1

First, you can always fully-qualify a name to use it specifically:

::System::String^ string; // this will always work

You can also use specific using directives to disambiguate without having to fully-qualify names:

using ::System::String;
String^ string;

Using directives can be placed at any level and will only affect this level. For instance, if you put one at the global level, all of your file will be affected by it. If you put it inside a function, only your function will be affected by it.

Also, I don't know if you realize it, but you're using C++CLI, an extension to C++ that lets you use .NET classes with C++-like code. This only works on Microsoft platforms.

Answer 2

The OVR namespace includes tons of things which have common names and might conflict with something you're using, so don't import it. In other words, don't do this:

using namespace OVR;

Instead, import the specific OVR items that you want like this:

using OVR::Matrix4f;

You can now using the Matrix4f class unadorned in your code, without having to worry about other types that you didn't import conflicting.

If there's still an issue where you're going to have a conflict (say you need to use the OVR Matrix4f class and your own Matrix4f class) then you have two options. Either accept that you're going to have to use explicit namespaces for one of them, or create typedefs for one of them:

typedef OVR::Matrix4f OVRMat4;
Matrix4f foo;
OVRMat4 foo;