Ambiguous Symbol -- Compiler Error C2872

I recently encountered the Ambiguous Symbol error, specifically: “error C2872: 'IMasterLoader' : ambiguous symbol” when using an interface I wrote in C# with a class built in C++.

   1:  namespace IMasterLoader
   2:  {
   3:     public interface IMasterLoader<T> where T : class
   4:     {
   5:        bool Load(T master, ref string strError);
   6:     }
   7:  }
Code producing the error:
   1:  // LmCellSectorLog.h
   2:  #pragma once
   3:  using namespace System;
   4:  using namespace System::Collections::Generic;
   5:  using namespace System::Data;
   7:  namespace LmCellSectorLog {
   8:      using namespace IMasterLoader;
   9:      public ref class CLmCellSectorLogLoader : IMasterLoader<CLmCellSectorLogMaster^>
  10:      {
  11:      public:
  12:          virtual bool Load(CLmCellSectorLogMaster^ master, String^% strError);
  13:      };
  14:  }



Compiler generated error C2872: 'IMasterLoader' : ambiguous symbol:

While searching for a solution to this problem, I encountered the Compiler Error C2872 (C++) page from MSDN, which didn’t have my exact solution, but led me to think differently about the syntax.

Jumping forward to the solution:

Assuming the problem was the compiler’s “scope” and recognition of the interface, I eventually changed the reference by fully qualifying the interface name with the “scope resolution operator (::)” and that solved the problem.

At that point, it was no longer necessary to reference the interface at the namespace:

   1:  public ref class CLmCellSectorLogLoader : ::IMasterLoader::IMasterLoader<CLmCellSectorLogMaster^>
   2:  {
   3:  public:
   4:      virtual bool Load(CLmCellSectorLogMaster^ master, String^% strError);
   5:  };



posted @ Wednesday, April 20, 2011 9:26 AM

Comments on this entry:

# re: Ambiguous Symbol -- Compiler Error C2872

Left by Robin Wernick at 1/3/2013 7:33 PM
Like most people you got half of the "if" question right. What if!!! you wanted it to go the other way, then you wouldn't have an answer. The solution shouldn't have to do with wrapping everything in a namespace either.

Your comment:

(not displayed)


Live Comment Preview: