Compiler wanring C4251 when building with API v1.2

__11

When I build my project - or the sample projects that are included in FileGDB_API_VS2010_1_2.zip - I get several of these warnings:

c:\mitch\filegdb_api\include\util.h(138): warning C4251: 'FileGDBAPI::SpatialReference::m_spatialReference' : class 'std::basic_string<_Elem,_Traits,_Ax>' needs to have dll-interface to be used by clients of class 'FileGDBAPI::SpatialReference'
          with
          [
              _Elem=wchar_t,
              _Traits=std::char_traits<wchar_t>,
              _Ax=std::allocator<wchar_t>
          ]

In each case the warning is on a private std:wstring member.

These warnings do not occur with API v1.1, with exactly the same DevStudio setup.

Why are the warnings appearing in 1.2 ?
Is a fix required in the API code and/or do I need to change my build or DevStudio settings?

LanceShipman

This only happens in VS2010 and it has to do with exporting classes with STL members from the APIs dll to client exes. In these cases, it�??s complaining about std::wstring declared in some of our classes in Util.h.

After reading over the doc and searching forums about this warning (which is level 1, so it seems serious), our suggestion is to simply ignore it, or disable it as follows:
Util.h:
�?�
#ifndef EXPORT_FILEGDB_API
# if defined linux || defined __APPLE__
#  define EXT_FILEGDB_API
# else
#  define EXT_FILEGDB_API _declspec(dllimport)
#  pragma warning (disable : 4251) �?� Add this line
# endif
�?�

If you don't want to change our header, then the same line into your code.

The MSDN explanation (http://msdn.microsoft.com/en-us/library/esew7y1w.aspx) states that all the problems have to do with static data access and inlined functions or some combination of the both. Looking over various forums, the problem seems to be with those issues, and more generally, allowing  direct access to STL members from clients, which we�??re not doing (all of our std::wstring objects are private). Furthermore, none of our std::wstring objects are static so we are not sure why this warning is even showing up. MSDN states that the warning can be ignored sometimes but not other times so it�??s not very clear what the problem is in this case.