]> Dogcows Code - chaz/yoink/blobdiff - src/stlplus/portability/portability_fixes.hpp
testing new non-autotools build system
[chaz/yoink] / src / stlplus / portability / portability_fixes.hpp
diff --git a/src/stlplus/portability/portability_fixes.hpp b/src/stlplus/portability/portability_fixes.hpp
new file mode 100644 (file)
index 0000000..b6a030c
--- /dev/null
@@ -0,0 +1,127 @@
+#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
This page took 0.028073 seconds and 4 git commands to generate.