shared_ptr ticket #398, "Support for embedded VC++ 4.0"
#398, "Support for embedded VC++ 4.0", http://svn.boost.org/trac/boost/ticket/398 complains that shared_ptr doesn't compile under eVC++ 4.0 because "'type_info' is not a member of 'std'". Can someone who uses or has access to eVC++ 4.0 look at it? Is the ticket still relevant? Can shared_ptr.hpp be made to compile on this platform?
On Saturday 07 July 2007 19:10:26 Peter Dimov wrote:
#398, "Support for embedded VC++ 4.0",
http://svn.boost.org/trac/boost/ticket/398
complains that shared_ptr doesn't compile under eVC++ 4.0 because "'type_info' is not a member of 'std'".
Can someone who uses or has access to eVC++ 4.0 look at it?
The obvious workaround for this is simply namespace std { using ::type_info; } Alternatively, and I really suggest that, you could use STLport (the 5.x series work pretty well under CE) and get a) a mostly complete C++ stdlibrary and b) several of such workarounds already applied.
Is the ticket still relevant? Can shared_ptr.hpp be made to compile on this platform?
I'm not sure if it is still relevant, but I guess so. Other than that, shared_ptr works for me on MS Windows CE. Concerning the ticket, I couldn't comment it there. Any time I tried 'preview' the new page just said | Bad Request | Missing or invalid form token. Do you have cookies enabled? I did not log in in any way but only provided my email address. Uli
Hi Ulrich, thanks for taking a look, Ulrich Eckhardt wrote:
On Saturday 07 July 2007 19:10:26 Peter Dimov wrote:
#398, "Support for embedded VC++ 4.0",
http://svn.boost.org/trac/boost/ticket/398
complains that shared_ptr doesn't compile under eVC++ 4.0 because "'type_info' is not a member of 'std'".
Can someone who uses or has access to eVC++ 4.0 look at it?
The obvious workaround for this is simply
namespace std { using ::type_info; }
Probably, but have you tried it and does it work? It would need to be guarded somehow, I guess?
Alternatively, and I really suggest that, you could use STLport (the 5.x series work pretty well under CE) and get a) a mostly complete C++ stdlibrary and b) several of such workarounds already applied.
I don't need to use anything, just to resolve the ticket one way or the other, and it specifically refers to eVC++ 4.0 in its default configuration. There's no ticket for STLport since it works. :-)
On Sunday 08 July 2007 18:23:21 Peter Dimov wrote:
Ulrich Eckhardt wrote:
The obvious workaround for this is simply
namespace std { using ::type_info; }
Probably, but have you tried it and does it work?
No, haven't tried it, I only know the workaround because I'm partially maintaining the STLport port for CE.
It would need to be guarded somehow, I guess?
Yes. defined(UNDER_CE) as boolean to detect a build for MS Windows CE. AFAIK, all CE versions are affected.
Alternatively, and I really suggest that, you could use STLport (the 5.x series work pretty well under CE) and get a) a mostly complete C++ stdlibrary and b) several of such workarounds already applied.
I don't need to use anything, just to resolve the ticket one way or the other, and it specifically refers to eVC++ 4.0 in its default configuration. There's no ticket for STLport since it works. :-)
I just wanted to hint people at this, because IMHO the vendor-supplied stdlib is so crippled that it isn't even worth programming for CE without some replacement, be it STLport or Dinkumware, which AFAIK also supports CE. cheers Uli
participants (3)
-
Peter Dimov -
Peter Dimov -
Ulrich Eckhardt