Ambiguous symbol error

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

rodri rodri - 24 Jan 2005 11:07 GMT

I have done a program with windows forms in "Visual C++". I have implemented a function that returns two values. For example:

double functionExample(int parameter, [Out] double __gc* result2);

And in a header file, I have written this line:

using namespace System::Runtime::InteropServices;

This line is necessary for [Out] key word. But when compiling the project, I get this error:

C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\WinBase.h(3140): error C2872: 'FILETIME' : ambiguous symbol could be 'C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\WinDef.h(354) : _FILETIME FILETIME' or 'stdafx.cpp(0) : System::Runtime::InteropServices::FILETIME'

How can I solve it? Thanks.

Reply to this Message

Steve McLellan - 26 Jan 2005 19:08 GMT

You could try using:
#undef FILETIME
using namespace System::Runtime::InteropServices;

You're unlikely to need the version in WinDef.h in this compilation unit.
This sort of thing's quite common (MessageBox is one) and occurs because the
standard Windows headers (usually included from <windows.h>) have a load of
#defines that clash with .NET-defined stuff.

Steve

>I have done a program with windows forms in "Visual C++". I have
>implemented a function that returns two values. For example:
[quoted text clipped - 15 lines]
>
> How can I solve it? Thanks.

Reply to this Message

rahoo - 27 Jan 2005 14:31 GMT

Thank you for answering me. I have tried to solve it writing:
#undef FILETIME

But the problem does not get solved and keeps on giving the same error.

"File1.h" has this line: "using namespace System::Runtime::InteropServices;"
And "Form1.cpp" has this line: "#include <windows.h>

/*File1.h*/

#pragma once

using namespace System::Runtime::InteropServices;

public __gc __interface interface1
{
public:
    double function1(int parameter, [Out] double __gc& result2);
};

/*Form1.h*/

#include "stdafx.h"
#include "Form1.h"
#include <windows.h>

using namespace namespace1;

int APIENTRY _tWinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
{
    System::Threading::Thread::CurrentThread->ApartmentState =
System::Threading::ApartmentState::STA;
    Application::Run(new Form1());
    return 0;
}

/*stdafx.h*/

#pragma once

#define WIN32_LEAN_AND_MEAN

#include <stdlib.h>
#include <malloc.h>
#include <memory.h>
#include <tchar.h>

#include "File1.h"

----------------------------------------------------------

> You could try using:
> #undef FILETIME
[quoted text clipped - 26 lines]
> >
> > How can I solve it? Thanks.

Reply to this Message

Steve McLellan - 27 Jan 2005 15:48 GMT

Hi,

This example code doesn't make sense; the code labelled as Form1.h is (I
presume) meant to be Form1.cpp but Form1.h doesn't appear to be present.
Where did you put the #undef FILETIME? It needs to come after #include
<windows.h> but before using namespace System::Runtime::InteropServices

If this still doesn't work, then it may be something else, but I've seen
this problem before (though not specifically with FILETIME) and it's been
due to this kind of name clash every time.

Steve

> Thank you for answering me. I have tried to solve it writing:
> #undef FILETIME
[quoted text clipped - 85 lines]
>> >
>> > How can I solve it? Thanks.

Reply to this Message

Larry Brasfield - 27 Jan 2005 18:05 GMT

If you look at the diagnostics that the OP got, you will realize
that the problem cannot be a preprocessor issue. The name
that gives rise to the ambiguity, (as a result of an unfortunate
use of the 'using' directive), is declared in both the global
namespace and the namespace he has dumped via 'using'.
He can #undef that name until Hell freezes over, but since
it was never #define'd in the first place, it will do no good.

When the OP finally fixes this, it will be by some variation
on the advice I gave days ago. Until then, all I can say is:
Have fun fiddling with the irrelevant preprocessor.

Signature

--Larry Brasfield
email: donotspam_larry_brasfield@hotmail.com
Above views may belong only to me.

> Hi,
>
[quoted text clipped - 91 lines]
>>> >
>>> > How can I solve it? Thanks.

Reply to this Message

Steve McLellan - 28 Jan 2005 13:11 GMT

Hi,

My apologies.

Steve

> If you look at the diagnostics that the OP got, you will realize
> that the problem cannot be a preprocessor issue. The name
[quoted text clipped - 113 lines]
>>>> >
>>>> > How can I solve it? Thanks.

Reply to this Message

Ambiguous symbol error

Free Magazines