MSVC non-compliance again
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?
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.
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.
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...
_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...
Have a look at www.dinkumware.com VC++ STL fixes. They have fixes for VC++ STL. Or get their STL library.
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!
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)
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)
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.
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.
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.
..
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.
..
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)
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)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement