Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Kylotan

MSVC non-compliance again

This topic is 6143 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Grr. The MSVC documentation defines this as part of the numeric_limits class: static const bool is_signed = false; Yet the header file declares it as an enum, thus: enum { is_signed = false }; This means that anything expecting is_signed to be a bool, as specified in the standard, gets the equivalent of an int instead, which is annoying when you''re trying to write out bools with ''boolalpha'' to write ''true'' or ''false'' to the stream, and you get ''1'' or ''0'' instead. Why would they do this?

Share this post


Link to post
Share on other sites
Advertisement
as for why:

I believe MSVC''s implementation is based largely on the HP reference STL implementation. It was possibly changed in standards, and they just never updated it.

Share this post


Link to post
Share on other sites
The annoying thing, is that it''s actually implemented like this:

_SOME_DUMB_MACRO(bool, is_signed, false)

and the definition is:

#define _SOME_DUMB_MACRO (type, name, value) { enum name = value }

So, the type information was available to them, they just choose to discard it at compile time. Mad. Maybe I should just fix the macro and see how much it breaks...

Share this post


Link to post
Share on other sites
Have a look at www.dinkumware.com VC++ STL fixes. They have fixes for VC++ STL. Or get their STL library.

Share this post


Link to post
Share on other sites
quote:
Original post by Void
Have a look at www.dinkumware.com VC++ STL fixes. They have fixes for VC++ STL. Or get their STL library.


Actually, MSVC uses Dinkumware''s STL. Perhaps, though, Dinkumware has improved versions on their website as you suggest.

Better yet, get STLport or another more compliant STL implementation.



---- --- -- -
Blue programmer needs food badly. Blue programmer is about to die!

Share this post


Link to post
Share on other sites
MSVC uses an STL written by PJ Plauger (name may be incorrect), which is based on the 1996 STL standard.

Dinkumware is founded by PJ Plauger, an has an updated version of the STL that complys with the 1998 standard (or at least come close considering VC pathetic template support).

The advantage that dinkumware STL has over STLport is VC++ programs can compile in level 4 without warnings. If you are using STLport, you have to either edit the headers or add many #pragma warning (disable)

Share this post


Link to post
Share on other sites
I have all the MSVC fixes installed. Sadly, they are just that: fixes. Although Visual C++''s compliance has been upgraded, the library with it still doesn''t support a large proportion of the syntax that it should (initialising one container from a range from another container is the big one annoying me right now). It''s possible I could hack a few of these changes in myself, but I''d rather not.

I tried STLPort and found that it was difficult to get working. Why on earth does it need such massive compiled libraries? It was compiling for 3hrs on my system before it ran out of memory! It seems like most of the alternative STL distributions either don''t have an accompanying IOStreams implementation, or require you to jump through a lot of hoops to be able to use one.

Share this post


Link to post
Share on other sites
The simplest solution, sadly, requires money. The dinkumware STL v308 purchase would give you less headaches, though it wouldn''t solve VC++ 6.limited template support.

STLport compiling for 3 hours? That''s bizzare. I could try it setting it up again when I get home (at work rite now). Last time, I don''t believe it took that long.

The IOstream is indeed a quirk. There seems to be differing implementations for each STL distribution. Fortunately, the interface is, at least, quite consistent.

..

Share this post


Link to post
Share on other sites
Hi again,

I did try rebuilding the stlport 4 (july release).

It took about 10 mins (p3-700,256 MB Ram).

Unfortunately, it cannot compile a simple hello world. An error
"set_new_handler is not a member of global namespace" occurs at this line

using ::set_new_handler;

I vaguely remember somewhere if you have define/undefine some memory management macros to get it working. Oh well.

If you want, I can have pass the binaries to you. (~7 MB zipped)

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!