-#ifndef STLPLUS_PORTABILITY_FIXES\r
-#define STLPLUS_PORTABILITY_FIXES\r
-////////////////////////////////////////////////////////////////////////////////\r
-\r
-// Author: Andy Rushton\r
-// Copyright: (c) Southampton University 1999-2004\r
-// (c) Andy Rushton 2004-2009\r
-// License: BSD License, see ../docs/license.html\r
-\r
-// Contains work arounds for OS or Compiler specific problems to try to make\r
-// them look more alike\r
-\r
-// It is strongly recommended that this header be included as the first\r
-// #include in every source file\r
-\r
-////////////////////////////////////////////////////////////////////////////////\r
-\r
-////////////////////////////////////////////////////////////////////////////////\r
-// Problem with MicroSoft defining two different macros to identify Windows\r
-////////////////////////////////////////////////////////////////////////////////\r
-\r
-#if defined(_WIN32) || defined(_WIN32_WCE)\r
-#define MSWINDOWS\r
-#endif\r
-\r
-////////////////////////////////////////////////////////////////////////////////\r
-// Problems with unnecessary or unfixable compiler warnings\r
-////////////////////////////////////////////////////////////////////////////////\r
-\r
-#ifdef _MSC_VER\r
-// Microsoft Visual Studio\r
-// shut up the following irritating warnings\r
-// 4786 - VC6, identifier string exceeded maximum allowable length and was truncated (only affects debugger)\r
-// 4305 - VC6, identifier type was converted to a smaller type\r
-// 4503 - VC6, decorated name was longer than the maximum the compiler allows (only affects debugger)\r
-// 4309 - VC6, type conversion operation caused a constant to exceeded the space allocated for it\r
-// 4290 - VC6, C++ exception specification ignored\r
-// 4800 - VC6, forcing value to bool 'true' or 'false' (performance warning)\r
-// 4675 - VC7.1, "change" in function overload resolution _might_ have altered program\r
-// 4996 - VC8, 'xxxx' was declared deprecated\r
-#pragma warning(disable: 4786 4305 4503 4309 4290 4800 4675 4996)\r
-#endif\r
-\r
-#ifdef __BORLANDC__\r
-// Borland\r
-// Shut up the following irritating warnings\r
-// 8026 - Functions with exception specifications are not expanded inline\r
-// 8027 - Functions with xxx are not expanded inline\r
-#pragma warn -8026\r
-#pragma warn -8027\r
-#endif\r
-\r
-////////////////////////////////////////////////////////////////////////////////\r
-// Problems with redefinition of min/max in various different versions of library headers\r
-////////////////////////////////////////////////////////////////////////////////\r
-\r
-// The Windows headers define macros called max/min which conflict with the templates std::max and std::min.\r
-// So, to avoid conflicts, MS removed the std::max/min rather than fixing the problem!\r
-// From Visual Studio .NET (SV7, compiler version 13.00) the STL templates have been added correctly.\r
-// For MFC compatibility, only undef min and max in non-MFC programs - some bits of MFC\r
-// use macro min/max in headers. \r
-\r
-// I've created extra template function definitions minimum/maximum that avoid all the problems above\r
-\r
-namespace stlplus\r
-{\r
- template<typename T> const T& maximum(const T& l, const T& r) {return l > r ? l : r;}\r
- template<typename T> const T& minimum(const T& l, const T& r) {return l < r ? l : r;}\r
-}\r
-\r
-////////////////////////////////////////////////////////////////////////////////\r
-// Problems with differences between namespaces\r
-////////////////////////////////////////////////////////////////////////////////\r
-\r
-// Note: not sure of the relevance of this - maybe deprecated?\r
-// problem in gcc pre-v3 where the sub-namespaces in std aren't present\r
-// this mean that the statement "using namespace std::rel_ops" created an error because the namespace didn't exist\r
-\r
-// I've done a fix here that creates an empty namespace for this case, but I\r
-// do *not* try to move the contents of std::rel_ops into namespace std\r
-// This fix only works if you use "using namespace std::rel_ops" to bring in the template relational operators (e.g. != defined i.t.o. ==)\r
-\r
-#ifdef __GNUC__\r
-namespace std\r
-{\r
- namespace rel_ops\r
- {\r
- }\r
-}\r
-#endif\r
-\r
-////////////////////////////////////////////////////////////////////////////////\r
-// problems with missing functions\r
-////////////////////////////////////////////////////////////////////////////////\r
-\r
-#ifdef MSWINDOWS\r
-unsigned sleep(unsigned seconds);\r
-#else\r
-#include <unistd.h>\r
-#endif\r
-\r
-////////////////////////////////////////////////////////////////////////////////\r
-// Function for establishing endian-ness\r
-////////////////////////////////////////////////////////////////////////////////\r
-// Different machine architectures store data using different byte orders.\r
-// This is referred to as Big- and Little-Endian Byte Ordering. \r
-//\r
-// The issue is: where does a pointer to an integer type actually point?\r
-//\r
-// In both conventions, the address points to the left of the word but:\r
-// Big-Endian - The most significant byte is on the left end of a word\r
-// Little-Endian - The least significant byte is on the left end of a word\r
-//\r
-// Bytes are addressed left to right, so in big-endian order byte 0 is the\r
-// msB, whereas in little-endian order byte 0 is the lsB. For example,\r
-// Intel-based machines store data in little-endian byte order so byte 0 is\r
-// the lsB.\r
-//\r
-// This function establishes byte order at run-time\r
-\r
-namespace stlplus\r
-{\r
- bool little_endian(void);\r
-}\r
-\r
-////////////////////////////////////////////////////////////////////////////////\r
-#endif\r
+#ifndef STLPLUS_PORTABILITY_FIXES
+#define STLPLUS_PORTABILITY_FIXES
+////////////////////////////////////////////////////////////////////////////////
+
+// Author: Andy Rushton
+// Copyright: (c) Southampton University 1999-2004
+// (c) Andy Rushton 2004-2009
+// License: BSD License, see ../docs/license.html
+
+// Contains work arounds for OS or Compiler specific problems to try to make
+// them look more alike
+
+// It is strongly recommended that this header be included as the first
+// #include in every source file
+
+////////////////////////////////////////////////////////////////////////////////
+
+////////////////////////////////////////////////////////////////////////////////
+// Problem with MicroSoft defining two different macros to identify Windows
+////////////////////////////////////////////////////////////////////////////////
+
+#if defined(_WIN32) || defined(_WIN32_WCE)
+#define MSWINDOWS
+#endif
+
+////////////////////////////////////////////////////////////////////////////////
+// Problems with unnecessary or unfixable compiler warnings
+////////////////////////////////////////////////////////////////////////////////
+
+#ifdef _MSC_VER
+// Microsoft Visual Studio
+// shut up the following irritating warnings
+// 4786 - VC6, identifier string exceeded maximum allowable length and was truncated (only affects debugger)
+// 4305 - VC6, identifier type was converted to a smaller type
+// 4503 - VC6, decorated name was longer than the maximum the compiler allows (only affects debugger)
+// 4309 - VC6, type conversion operation caused a constant to exceeded the space allocated for it
+// 4290 - VC6, C++ exception specification ignored
+// 4800 - VC6, forcing value to bool 'true' or 'false' (performance warning)
+// 4675 - VC7.1, "change" in function overload resolution _might_ have altered program
+// 4996 - VC8, 'xxxx' was declared deprecated
+#pragma warning(disable: 4786 4305 4503 4309 4290 4800 4675 4996)
+#endif
+
+#ifdef __BORLANDC__
+// Borland
+// Shut up the following irritating warnings
+// 8026 - Functions with exception specifications are not expanded inline
+// 8027 - Functions with xxx are not expanded inline
+#pragma warn -8026
+#pragma warn -8027
+#endif
+
+////////////////////////////////////////////////////////////////////////////////
+// Problems with redefinition of min/max in various different versions of library headers
+////////////////////////////////////////////////////////////////////////////////
+
+// The Windows headers define macros called max/min which conflict with the templates std::max and std::min.
+// So, to avoid conflicts, MS removed the std::max/min rather than fixing the problem!
+// From Visual Studio .NET (SV7, compiler version 13.00) the STL templates have been added correctly.
+// For MFC compatibility, only undef min and max in non-MFC programs - some bits of MFC
+// use macro min/max in headers.
+
+// I've created extra template function definitions minimum/maximum that avoid all the problems above
+
+namespace stlplus
+{
+ template<typename T> const T& maximum(const T& l, const T& r) {return l > r ? l : r;}
+ template<typename T> const T& minimum(const T& l, const T& r) {return l < r ? l : r;}
+}
+
+////////////////////////////////////////////////////////////////////////////////
+// Problems with differences between namespaces
+////////////////////////////////////////////////////////////////////////////////
+
+// Note: not sure of the relevance of this - maybe deprecated?
+// problem in gcc pre-v3 where the sub-namespaces in std aren't present
+// this mean that the statement "using namespace std::rel_ops" created an error because the namespace didn't exist
+
+// I've done a fix here that creates an empty namespace for this case, but I
+// do *not* try to move the contents of std::rel_ops into namespace std
+// This fix only works if you use "using namespace std::rel_ops" to bring in the template relational operators (e.g. != defined i.t.o. ==)
+
+#ifdef __GNUC__
+namespace std
+{
+ namespace rel_ops
+ {
+ }
+}
+#endif
+
+////////////////////////////////////////////////////////////////////////////////
+// problems with missing functions
+////////////////////////////////////////////////////////////////////////////////
+
+#ifdef MSWINDOWS
+unsigned sleep(unsigned seconds);
+#else
+#include <unistd.h>
+#endif
+
+////////////////////////////////////////////////////////////////////////////////
+// Function for establishing endian-ness
+////////////////////////////////////////////////////////////////////////////////
+// Different machine architectures store data using different byte orders.
+// This is referred to as Big- and Little-Endian Byte Ordering.
+//
+// The issue is: where does a pointer to an integer type actually point?
+//
+// In both conventions, the address points to the left of the word but:
+// Big-Endian - The most significant byte is on the left end of a word
+// Little-Endian - The least significant byte is on the left end of a word
+//
+// Bytes are addressed left to right, so in big-endian order byte 0 is the
+// msB, whereas in little-endian order byte 0 is the lsB. For example,
+// Intel-based machines store data in little-endian byte order so byte 0 is
+// the lsB.
+//
+// This function establishes byte order at run-time
+
+namespace stlplus
+{
+ bool little_endian(void);
+}
+
+////////////////////////////////////////////////////////////////////////////////
+#endif
projects / chaz / yoink / blobdiff