Given the following C++/CLI program:
#pragma managed(push, off)
class FooBar
{
FooBar(const FooBar& that) { *this = that; }
const FooBar& operator =(const FooBar& that);
};
#pragma managed(pop)
int main()
{
return 0;
}
Gives the following linker output:
Severity Code Description Project File Line Suppression State
Error LNK2019 unresolved external symbol "private: class FooBar const & __thiscall FooBar::operator=(class FooBar const &)" (??4FooBar##AAEABV0#ABV0##Z) referenced in function "private: __thiscall FooBar::FooBar(class FooBar const &)" (??0FooBar##AAE#ABV0##Z) ConsoleApplication1 C:\Users\SomeUser\Documents\Visual Studio 2019\Projects\ConsoleApplication1\ConsoleApplication1\ConsoleApplication1\ConsoleApplication1.obj 1
But the following C++ program does not:
class FooBar
{
FooBar(const FooBar& that) { *this = that; }
const FooBar& operator =(const FooBar& that);
};
int main()
{
return 0;
}
The reason I need this to work is because I'm including a header file which is beyond my control that does this. Although I never need to use the copy constructor or the assignment operator.
Compiled using v142 platform toolset.
Related
The below program works fine while having functions with primitive return type functions specifically the Pop function defined below works and I'm able to build properly, but when I build the solution with a function having non primitive return type as in PopC like below project doesn't build, but definitions are syntatically correct and I'm able to see the types being referred properly with proper namespace definitions in pch.h file.
Have defined the below code in the StreamSamplePool.idl file,
namespace WinRTComponent
{
[default_interface]
runtimeclass StreamSamplePool
{
StreamSamplePool();
Int32 MyProperty;
// MediaStreamSample PopC();
Int32 Pop();
}
}
And inside the StreamSamplePool.cpp file have defined the respective methods as follows
#include "pch.h"
#include "StreamSamplePool.h"
#include "StreamSamplePool.g.cpp"
#include <stack>
#include <queue>
using namespace winrt::Windows::Storage::Streams;
using namespace winrt::Windows::Foundation;
using namespace std;
//using namespace Platform;
using namespace winrt::Windows::Media::Core;
namespace winrt::WinRTComponent::implementation
{
int32_t StreamSamplePool::MyProperty()
{
throw hresult_not_implemented();
}
int32_t StreamSamplePool::Pop()
{
return int32_t();
}
//MediaStreamSample StreamSamplePool::PopC()
//{
// MediaStreamSample sample = MediaStreamSample::CreateFromBuffer(NULL,
//TimeSpan());
// //sample.Processed += OnSampleProcessed;
// return sample;
//}
void StreamSamplePool::MyProperty(int32_t /* value */)
{
throw hresult_not_implemented();
}
}
And have defined the following code inside StreamSamplePool.h
namespace winrt::WinRTComponent::implementation
{
struct StreamSamplePool : StreamSamplePoolT<StreamSamplePool>
{
StreamSamplePool() = default;
int32_t Pop();
//MediaStreamSample PopC();
int32_t MyProperty();
void MyProperty(int32_t value);
};
}
namespace winrt::WinRTComponent::factory_implementation
{
struct StreamSamplePool : StreamSamplePoolT<StreamSamplePool,
implementation::StreamSamplePool>
{
};
}
Error info
Error MIDL2011 [msg]unresolved type declaration [context]: WinRTComponent.MediaStreamSample [ Procedure 'PopC' ( RuntimeClass
'WinRTComponent.StreamSamplePool' ) ] WinRTComponent D:\Prithvi\Work\WinRTComponent\StreamSamplePool.idl 9
Compiler output
1>D:\...\StreamSamplePool.idl(9): error MIDL2011: [msg]unresolved type declaration [context]: WinRTComponent.MediaStreamSample [ Procedure 'PopC' ( RuntimeClass 'WinRTComponent.StreamSamplePool' ) ]
1>Done building project "WinRTComponent.vcxproj" -- FAILED.
The issue can be reduced to the following IDL file:
namespace WinRTComponent
{
[default_interface]
runtimeclass StreamSamplePool
{
StreamSamplePool();
MediaStreamSample PopC();
}
}
Compiling this using a default-generated C++/WinRT Component project produces the following error:
1>C:\...\StreamSamplePool.idl(7): error MIDL2011: [msg]unresolved type declaration [context]: WinRTComponent.MediaStreamSample [ Procedure 'PopC' ( RuntimeClass 'WinRTComponent.StreamSamplePool' ) ]
It contains all the information required to resolve the issue. In particular it's naming the error ("unresolved type declaration"), and the procedure affected ("PopC"). To solve this you'll have to provide the fully-qualified type name in the IDL file, i.e.
namespace WinRTComponent
{
[default_interface]
runtimeclass StreamSamplePool
{
StreamSamplePool();
Windows.Media.Core.MediaStreamSample PopC();
}
}
With that done, go to the "Generated Files\sources" directory under the project root, and copy the respective parts of the "StreamSamplePool.h" and "StreamSamplePool.cpp" files that the build system generated to your source files.
I have a c++ code that needs to be called in c# by a cli wrapper. I am stuck at the operator overloading part.
//this is my code
//Cppclass.h
#ifdef CPP_EXP_EXPORTS
#define CPP_EXP __declspec(dllexport)
#else
#define CPP_EXP __declspec(dllimport)
#endif
class CPP_EXP Cppclass;
CPP_EXP Cppclass operator-(Cppclass const &, Cppclass const &);
class CPP_EXP Cppclass
{
public:
friend CPP_EXP Cppclass operator-(Cppclass const &, Cppclass const &);
};
//this is my managed c++ code.
#include "Cppclass.h"
namespace Wrapper
{
public ref class cppwrapclass
{
public:
static cppwrapclass ^ operator-(cppwrapclass%A,cppwrapclass%B)
{
operator-(A.obj,B.obj);
return gcnew cppwrapclass();
}
private:
Cppclass *obj;
};
}
Its showing an intellisense error and not getting compiled.
You write a wrapper like this:
public ref class cppwrapclass
{
public:
cppwrapclass(Cppclass *obj)
: obj(obj)
{
}
~cppwrapclass()
{
this->!cppwrapclass();
}
!cppwrapclass()
{
if (obj)
{
delete obj;
obj = nullptr;
}
}
static cppwrapclass^ operator-(cppwrapclass% A, cppwrapclass% B)
{
return gcnew cppwrapclass(new Cppclass(*A.obj - *B.obj));
}
private:
Cppclass* obj;
};
A.obj is of type Cppclass*, therefore *A.obj is of type Cppclass, and *A.obj - *B.obj is a temporary Cppclass which needs to be moved to the heap in order to be referenced by the wrapper, hence the copy constructor call: new Cppclass(*A.obj - *B.obj).
The rest is the Dispose pattern and finalizer plumbing code.
I'm attempting to make some of our IJW wrappers between our C++ and our .NET code easier to use.
The following is a test situation with our wrapper platform:
// NativeWrapper.h
#pragma once
template <class T>
public ref class NativeWrapper
{
public:
// ...
operator T* ();
operator T& ();
// ...
};
// Test.h
#pragma once
class Test { /* ... */ };
#pragma make_public( Test )
// TestN.h
#pragma once
#include "NativeWrapper.h"
#include "Test.h"
public ref class TestN : public NativeWrapper<Test>
{ /* ... */ };
// main.cpp
#include "TestN.h"
void f(const Test&) { /* ... */ }
int main()
{
TestN^ t = gcnew TestN();
f(t);
return 0;
}
The implicit cast from TestN^ to const Test& via the user-defined operator Test&() works just fine, as I had expected.
However, when I try this in my production code, something is different. It cannot find the proper conversion. I must do the following:
f((Test&)t);
I haven't been able to identify any fundamental differences between what I'm doing in my test and what I'm doing in the main codebase. The NativeWrapper template is identical.
What types of situations might cause the compiler to fail to use a non-const conversion operator when the only acceptable type is the const reference type?
Thanks.
So I have a wrapper shown below:
Wrapper.h
#pragma once
#include "Engine.h"
namespace Wrapper
{
public ref class EngineWrapper
{
public:
EngineWrapper();
virtual ~EngineWrapper();
protected:
!EngineWrapper();
private:
CEngine *m_engine;
};
}
Wrapper.cpp
#include "stdafx.h"
#include "Wrapper.h"
using namespace Wrapper;
EngineWrapper::EngineWrapper()
{
m_engine = new CEngine();
}
EngineWrapper::~EngineWrapper()
{
if (m_engine)
{
delete m_engine;
m_engine = NULL;
}
}
EngineWrapper::!EngineWrapper()
{
if (m_engine)
{
delete m_engine;
m_engine = NULL;
}
}
and this is some of my native engine code (in another project):
Engine.h
class CEngine
{
public:
CEngine();
virtual ~CEngine();
// other stuff
}
Engine.cpp
CEngine::CEngine()
{
// do stuff
}
CEngine::~CEngine()
{
// do stuff
}
My Wrapper project is a C++/CLI project compiled using /clr
My Engine project is a native C++ project which produces a .dll, .lib, and .exp (from looking at the output when this project builds)
For the Wrapper project, I've added the location of the native .lib to the linker input.
My issue: I get the following errors:
Error 126 error LNK2028: unresolved token (0A000380) "public: __thiscall
CEngine::CEngine(void)" (??0CEngine##$$FQAE#XZ) referenced in function "public:
__clrcall Wrapper::EngineWrapper::EngineWrapper(void)" (
0EngineWrapper#Wrapper##$$FQ$AAM#XZ) C:\..\..\Wrapper.obj Wrapper
Error 127 error LNK2019: unresolved external symbol "public: __thiscall
CEngine::CEngine(void)" (??0CEngine##$$FQAE#XZ) referenced in function "public:
__clrcall Wrapper::EngineWrapper::EngineWrapper(void)" (
0EngineWrapper#Wrapper##$$FQ$AAM#XZ) C:\..\..\Wrapper.obj Wrapper
As I think it is finding the library correctly, how come it doesn't recognize the native ctor?
Export the CEngine class in the native C++ project, check this URL for details
I have spotted something like this in code:
void foo(IList<int>^ const & list ) { ... }
What does this ^ const& mean? I looked in the C++/CLI specification, but found no comments on making constant tracking references, nor the ^& combo.
Is this legal?
This code was probably written by a C++ programmer that used common C++ idiom to write C++/CLI. It is quite wrong, passing a reference to tracking handle is only possible if the handle is stored on the stack. It cannot work if the passed List<> reference is stored in a field of an object on the heap, the garbage collector can move it and make the pointer invalid. The compiler will catch it and generate an error. The ^ is already a reference, no additional reference is needed.
Without the reference, the const keyword doesn't make a lot of sense anymore either. Not that it ever did before, the CLR cannot enforce it. Not that this mattered much here, this code could not be called from any other .NET language. They won't generate a pointer to the tracking handle.
Just fix it, there's little point in keeping bad code like this:
void foo(IList<int>^ list ) { ... }
Example of code that shows that the reference cannot work:
using namespace System;
using namespace System::Collections::Generic;
ref class Test {
public:
IList<int>^ lst;
void foo(IList<int> const &list) {}
void wontcompile() {
foo(lst); // C3699
IList<int>^ okay;
foo(okay);
}
};
It's a reference which is constant to a tracking handle.
It allows you to pass the handle by reference instead of by value. Presumably the author thinks it's more efficient than copying the handle.
If the author meant to make the handle constant he should have used either of
Method(TestClass const ^ const & parameter)
Method(TestClass const^ parameter)
Or alternatively
Method(TestClass const^& parameter) - but the caller must const up the handle first
with
TestClass const^ constHandle = nonConstHandle
An example of each:
// test.cpp : Defines the entry point for the console application.
#include "stdafx.h"
ref class TestClass
{
public:
void setA(int value)
{
a = value;
}
TestClass() :
a(10)
{
}
private:
int a;
};
class TakesHandle
{
public:
void methodX1(TestClass const ^ const & parameter)
{
// Un-commenting below causes compiler error
// parameter->setA(11);
}
void methodX2(TestClass const^ parameter)
{
// Un-commenting below causes compiler error
// parameter->setA(11);
}
void methodX3(TestClass const^& parameter)
{
// Un-commenting below causes compiler error
// parameter->setA(11);
}
};
int _tmain(int argc, _TCHAR* argv[])
{
TakesHandle takes;
TestClass ^ test1 = gcnew TestClass();
// compiles
takes.methodX1(test1);
// compiles
takes.methodX2(test1);
TestClass const ^ constHandle = test1;
takes.methodX3(constHandle);
return 0;
}