Inline funtions (STL) not inlining

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Mick O''Neill - 30 Dec 2006 05:40 GMT

I asked about this a few days ago, and not found an aswer yet, but I have
tracked down further info. I am getting the problems occrrung with the stl,
under thses sorts of circumstances:

#include "LibraryHeader.h"
#include <list>

namespace MyNamespace {
public ref MyClass {
public:
MyMethod() {
list<LibraryNamespace::LibraryObject> myList;
....
}
};
}

What occurs is I end up with a link 2001 error, trying to reference the
list<LibraryNamespace::LibraryObject> constructor. Note that the Library is
unmanaged code.

Reply to this Message

Bruno van Dooren [MVP VC++] - 30 Dec 2006 06:13 GMT

>I asked about this a few days ago, and not found an aswer yet, but I have
> tracked down further info. I am getting the problems occrrung with the
[quoted text clipped - 18 lines]
> is
> unmanaged code.

Could you please post the complete compiler error message?

Signature

Kind regards,
Bruno van Dooren
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"

Reply to this Message

Mick O''Neill - 30 Dec 2006 06:27 GMT

> >I asked about this a few days ago, and not found an aswer yet, but I have
> > tracked down further info. I am getting the problems occrrung with the
[quoted text clipped - 20 lines]
>
> Could you please post the complete compiler error message?

ok: I am trying to wrap the ImageMagick library at the moment: Here is a
paste of the message (with the real function names)

error LNK2001: unresolved external symbol "public: void __thiscall
std::list<class Magick::Coordinate,class std::allocator<class
Magick::Coordinate> >::push_back(class Magick::Coordinate const &)"
(?push_back@?$list@VCoordinate@Magick@@V?$allocator@VCoordinate@Magick@@@std@@@std@@$$FQAEXABVCoordinate@Magick@@@Z) NETMagick.obj

error LNK2001: unresolved external symbol "public: __thiscall
std::list<class Magick::Coordinate,class std::allocator<class
Magick::Coordinate> >::list<class Magick::Coordinate,class
std::allocator<class Magick::Coordinate> >(void)"
(??0?$list@VCoordinate@Magick@@V?$allocator@VCoordinate@Magick@@@std@@@std@@$$FQAE@XZ) NETMagick.obj

and the code causing it....

public ref class IMDrawableBezier : public
IMDrawable<Magick::DrawableBezier> {
public:
IMDrawableBezier(System::Collections::Generic::IList<IMCoordinate^>%
coordinateList) {
std::list<Magick::Coordinate> lst;
for each (IMCoordinate^ point in coordinateList) {
lst.push_back(::Magick::Coordinate(point->X, point->Y));
}
pDraw = new CLASS(lst);
}
};

Reply to this Message

Carl Daniel [VC++ MVP] - 30 Dec 2006 08:36 GMT

> I asked about this a few days ago, and not found an aswer yet, but I
> have tracked down further info. I am getting the problems occrrung
[quoted text clipped - 16 lines]
> the list<LibraryNamespace::LibraryObject> constructor. Note that the
> Library is unmanaged code.

Does "LibraryHeader.h" contain a #pragma managed directive?

If not, you're probably ending up with an ODR violation with LibraryObject
being defined as both a CLR class and a native class - that could be the
source of your error. You might try:

#pragma managed (push, off)
#include "LibraryHeader.h"
#include <list>
#pragma managed (pop)

to see if that resolves the error.

-cd

Reply to this Message

Mick O''Neill - 30 Dec 2006 09:36 GMT

> > I asked about this a few days ago, and not found an aswer yet, but I
> > have tracked down further info. I am getting the problems occrrung
[quoted text clipped - 31 lines]
>
> -cd

Thanks Carl - something I hadn't thought of. However, just tried it, and
made no difference. I'll keep trying to find a work around. Maybe something
will click.

Mick

Reply to this Message

Mick O''Neill - 30 Dec 2006 13:13 GMT

Hey everyone - I've figured it out. It has to do with the way the ImageMagick
headers builds the libraries and/or DLL's. Because I'm wrapping the whole
thing in a .NET assembly, but linking to the static ImageMagick libraries,
the Headers are getting confused, and thinking the assembly is a DLL build of
the library, and prefixing the declarations with a __declspec(dllexport),
effectively stopping the inlining.

Now I've figured out the "why", should be simple enough to stop it all.

Thanks for your help folks.

Reply to this Message

Rate this thread:

Inline funtions (STL) not inlining

Free Magazines