Member Avatar for ferrant

Hi,

I am getting warnings when I export a class that contains an STL deque. Note that for a simple stl vector there are no warnings, only for the deque ... I applied the rules defined on the msn page : [url]

But still get a compile warning that I would like to get rid of.

Any hints would be appreciated !

Thanks alot !

matt-

code snippet and associated warning below :

#ifdef IPGENPROC_EXPORTS
#define IPGENPROC_API __declspec(dllexport)
#define IPGENPROC_TEMPLATE
#else
#define IPGENPROC_API __declspec(dllimport)
#define IPGENPROC_TEMPLATE extern
#endif


class IPGENPROC_API Point3D
{
public:
    short x,y,z;
public:
    bool operator < (const Point3D c) const
    {
        return (z < c. z) && (y < c. y) && (x < c.z);
    }
    bool operator == (const Point3D c) const
    {
        return (z == c. z) && (y == c. y) && (x == c.z);
    }
};

IPGENPROC_TEMPLATE template class IPGENPROC_API allocator<Point3D>;
IPGENPROC_TEMPLATE template class IPGENPROC_API deque<Point3D>;




C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\deque(54) : warning C4251: 'std::_Deque_map<_Ty,_Alloc>::_Almap' : class 'std::allocator<_Ty>' needs to have dll-interface to be used by clients of class 'std::_Deque_map<_Ty,_Alloc>'
        with
        [
            _Ty=Point3D,
            _Alloc=std::allocator<Point3D>
        ]
        and
        [
            _Ty=std::_Deque_map<Point3D,std::allocator<Point3D>>::_Tptr 
        ]
        and
        [
            _Ty=Point3D,
            _Alloc=std::allocator<Point3D>
        ]
Edited by Reverend Jim because: Fixed formatting
  • 2 Contributors
  • 2 Replies
  • 224 Views
  • 7 Hours Discussion Span
  • Latest Post Latest Post by ferrant

Dani AI

Generated

Short version: warning C4251 is telling you the DLL is exporting a type that, under the MSVC STL implementation, contains internal types without a dll-interface (in this case the deque's internal map/allocator). The compiler can emit the warning for deque even when the same trick works for vector, because deque instantiation brings in additional implementation types that are not easy or safe to export.

Practical options, ranked by safety:

  • Best: hide the STL container behind a stable interface (pImpl or a façade). Keep the deque private inside the DLL and export functions or methods that use only PODs or simple handles. That removes ABI/allocator coupling and works across compiler/runtime versions.
  • If a C-like API is acceptable, export create/destroy/size/get/set functions and pass buffers or indices rather than the container type itself.
  • Returning a copy of a container is less risky only when the DLL and all clients are built with the same compiler and CRT; still not recommended for long-term compatibility.
  • Last resort: silence C4251 (as suggested). This only suppresses the warning — it does not fix the ABI risk. Use it only when both sides are controlled and documented to use the same toolchain.

Concrete migration checklist:

  • Stop exporting the deque type in public headers.
  • Introduce an opaque pointer or private member that owns the deque.
  • Add exported wrapper methods that copy/serialize elements into plain arrays or POD structs for crossing the boundary.
  • Document and enforce identical compiler/CRT settings if any STL types must cross boundaries.

One more note for : the posted Point3D overloads look like they have typos and use pass-by-value; make the operators take const Point3D& and fix coordinate comparisons so x compares to x, y to y, z to z. That will avoid logical bugs regardless of the DLL issue.

Recommended Answers

All 2 Replies

Member Avatar for Ancient Dragon

I had that same question some time ago and was told that templates can't be exported in a DLL. So I just use a pragma to disable that warning because the class will work anyway. #pragma warning(disable: 4251)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.