os_fixes.hpp
1: #ifndef OS_FIXES_HPP
2: #define OS_FIXES_HPP
3: /*------------------------------------------------------------------------------
4:
5: Author: Andy Rushton
6: Copyright: (c) Andy Rushton, 2004
7: License: BSD License, see ../docs/license.html
8:
9: Contains work arounds for OS or Compiler specific problems to try to make
10: them look more alike
11:
12: It is strongly recommended that this header be included as the first
13: #include in every source file
14:
15: ------------------------------------------------------------------------------*/
16:
17: ////////////////////////////////////////////////////////////////////////////////
18: // Problem with MicroSoft defining two different macros to identify Windows
19: ////////////////////////////////////////////////////////////////////////////////
20:
21: #if defined(_WIN32) || defined(_WIN32_WCE)
22: #define MSWINDOWS
23: #endif
24:
25: ////////////////////////////////////////////////////////////////////////////////
26: // Problems with unnecessary or unfixable compiler warnings
27: ////////////////////////////////////////////////////////////////////////////////
28:
29: #if defined(_MSC_VER)
30: // Microsoft Visual Studio
31: // shut up the following irritating warnings
32: // 4275 - VC6, exported class was derived from a class that was not exported
33: // 4786 - VC6, identifier string exceeded maximum allowable length and was truncated (only affects debugger)
34: // 4305 - VC6, identifier type was converted to a smaller type
35: // 4503 - VC6, decorated name was longer than the maximum the compiler allows (only affects debugger)
36: // 4309 - VC6, type conversion operation caused a constant to exceeded the space allocated for it
37: // 4290 - VC6, C++ exception specification ignored
38: // 4800 - VC6, forcing value to bool 'true' or 'false' (performance warning)
39: // 4675 - VC7.1, "change" in function overload resolution _might_ have altered program
40: // 4996 - VC8, 'xxxx' was declared deprecated
41: #pragma warning(disable: 4275 4786 4305 4503 4309 4290 4800 4675 4996)
42: #endif
43:
44: #if defined(__BORLANDC__)
45: // Borland
46: // Shut up the following irritating warnings
47: // 8008 - Condition is always true.
48: // Whenever the compiler encounters a constant comparison that (due to
49: // the nature of the value being compared) is always true or false, it
50: // issues this warning and evaluates the condition at compile time.
51: // 8060 - Possibly incorrect assignment.
52: // This warning is generated when the compiler encounters an assignment
53: // operator as the main operator of a conditional expression (part of
54: // an if, while, or do-while statement). This is usually a
55: // typographical error for the equality operator.
56: // 8066 - Unreachable code.
57: // A break, continue, goto, or return statement was not followed by a
58: // label or the end of a loop or function. The compiler checks while,
59: // do, and for loops with a constant test condition, and attempts to
60: // recognize loops that can't fall through.
61: #pragma warn -8008
62: #pragma warn -8060
63: #pragma warn -8066
64: #endif
65:
66: ////////////////////////////////////////////////////////////////////////////////
67: // Problems with redefinition of min/max in various different versions of library headers
68: ////////////////////////////////////////////////////////////////////////////////
69:
70: // The Windows headers define macros called max/min which conflict with the templates std::max and std::min.
71: // So, to avoid conflicts, MS removed the std::max/min rather than fixing the problem!
72: // From Visual Studio .NET (SV7, compiler version 13.00) the STL templates have been added correctly.
73: // This fix switches off the macros and reinstates the STL templates for earlier versions (SV6).
74: // Note that this could break MFC applications that rely on the macros (try it and see).
75:
76: // For MFC compatibility, only undef min and max in non-MFC programs - some bits of MFC
77: // use macro min/max in headers. For VC7 both the macros and template functions exist
78: // so there is no real need for the undefs but to it anyway for consistency. So, if
79: // using VC6 and MFC then template functions will not exist
80:
81: // I've created extra template function definitions minimum/maximum that avoid all the problems above
82:
83: #if defined(_MSC_VER) && !defined(_MFC_VER)
84: #define NOMINMAX
85: #undef max
86: #undef min
87: // replace missing template definitions in VC6
88: #if defined(_MSC_VER) && (_MSC_VER < 1300)
89: namespace std
90: {
91: template<typename T> const T& max(const T& l, const T& r) {return l > r ? l : r;}
92: template<typename T> const T& min(const T& l, const T& r) {return l < r ? l : r;}
93: }
94: #endif
95: #endif
96:
97: template<typename T> const T& maximum(const T& l, const T& r) {return l > r ? l : r;}
98: template<typename T> const T& minimum(const T& l, const T& r) {return l < r ? l : r;}
99:
100: ////////////////////////////////////////////////////////////////////////////////
101: // Problem with missing __FUNCTION__ macro
102: ////////////////////////////////////////////////////////////////////////////////
103: // this macro is used in debugging but was missing in Visual Studio prior to version 7
104: // it also has a different name in Borland
105:
106: #if defined(_MSC_VER) && (_MSC_VER < 1300)
107: #define __FUNCTION__ 0
108: #endif
109:
110: #if defined(__BORLANDC__)
111: #define __FUNCTION__ __FUNC__
112: #endif
113:
114: ////////////////////////////////////////////////////////////////////////////////
115: // Problems with differences between namespaces
116: ////////////////////////////////////////////////////////////////////////////////
117:
118: // problem in gcc pre-v3 where the sub-namespaces in std aren't present
119: // this mean that the statement "using namespace std::rel_ops" created an error because the namespace didn't exist
120:
121: // I've done a fix here that creates an empty namespace for this case, but I
122: // do *not* try to move the contents of std::rel_ops into namespace std
123: // 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. ==)
124:
125: #if defined(__GNUC__)
126: namespace std
127: {
128: namespace rel_ops
129: {
130: }
131: }
132: #endif
133:
134: ////////////////////////////////////////////////////////////////////////////////
135: // Problems with the typename keyword
136: ////////////////////////////////////////////////////////////////////////////////
137:
138: // There are problems with using the 'typename' keyword. Technically, if you
139: // use a type member of a template class (i.e. a type declared within the
140: // template class by a local typedef), you need to tell the compiler that it
141: // is a type name. This is because the compiler cannot work out whether a
142: // member is a type, a method or a data field at compile time. However,
143: // support for the typename keyword has traditionally been incomplete in both
144: // gcc and Visual Studio. I have used macros to try to resolve this issue. The
145: // macros add the keyword for compiler versions that require it and omit it
146: // for compiler versions that do not support it
147:
148: // There are five places where typename keywords cause problems:
149: //
150: // 1) in a typedef where a template class's member type is being mapped onto
151: // a type definition within another template class or function
152: // e.g. template<typename T> fn () {
153: // typedef typename someclass<T>::member_type local_type;
154: // ^^^^^^^^
155: // Note that the typename keyword is only required when the type is of this form - a member of a template class
156: // This situation is handled by the macro TYPEDEF_TYPENAME
157: //
158: // 2) in a function parameter declaration, with similar rules to the above
159: // e.g. template<typename T> fn (typename someclass<T>::member_type)
160: // ^^^^^^^^
161: // Note that the typename keyword is only required when the type is of this form - a member of a template class
162: // This situation is handled by the macro PARAMETER_TYPENAME
163: //
164: // 3) in instantiating a template, the parameter to the template, with similar rules to the above
165: // e.g. template_class<typename someclass<T>::member_type>
166: // ^^^^^^^^
167: // Note that the typename keyword is only required when the type is of this form - a member of a template class
168: // This situation is handled by the macro TEMPLATE_TYPENAME
169: // 4) Return expressions
170: // e.g. return typename ntree<T>::const_iterator(this,m_root);
171: // ^^^^^^^^
172: // Note that this typename is only required when the return type is a member of a template class
173: // 5) Creating temporary objects when passing arguments to a function or constructor
174: // e.g. return typename ntree<T>::const_prefix_iterator(typename ntree<T>::const_iterator(this,m_root));
175: // ^^^^^^^^
176: // Note that the typename keyword is only required when the temporary's type is a member of a template class
177:
178: // default values, overridden for individual problem cases below
179: #define TYPEDEF_TYPENAME typename
180: #define PARAMETER_TYPENAME typename
181: #define TEMPLATE_TYPENAME typename
182: #define RETURN_TYPENAME typename
183: #define TEMPORARY_TYPENAME typename
184:
185: #if defined(__GNUC__)
186: // GCC
187: // - pre-version 3 didn't handle typename in any of these cases
188: // - version 3 onwards, typename is required for all three cases as per default
189: #if __GNUC__ < 3
190: // gcc prior to v3
191: #undef TYPEDEF_TYPENAME
192: #define TYPEDEF_TYPENAME
193: #undef PARAMETER_TYPENAME
194: #define PARAMETER_TYPENAME
195: #undef TEMPLATE_TYPENAME
196: #define TEMPLATE_TYPENAME
197: #undef RETURN_TYPENAME
198: #define RETURN_TYPENAME
199: #undef TEMPORARY_TYPENAME
200: #define TEMPORARY_TYPENAME
201: #endif
202: #endif
203:
204: #if defined(_MSC_VER)
205: // Visual Studio
206: // - version 6 (compiler v.12) cannot handle typename in any of these cases
207: // - version 7 (.NET) (compiler v.13) requires a typename in a parameter specification but supports all
208: // - version 8 (2005) (compiler v.14) requires parameters and templates, supports all
209: #if _MSC_VER < 1300
210: // compiler version 12 and earlier
211: #undef TYPEDEF_TYPENAME
212: #define TYPEDEF_TYPENAME
213: #undef PARAMETER_TYPENAME
214: #define PARAMETER_TYPENAME
215: #undef TEMPLATE_TYPENAME
216: #define TEMPLATE_TYPENAME
217: #undef RETURN_TYPENAME
218: #define RETURN_TYPENAME
219: #undef TEMPORARY_TYPENAME
220: #define TEMPORARY_TYPENAME
221: #endif
222: #endif
223:
224: ////////////////////////////////////////////////////////////////////////////////
225: // problems with missing functions
226: ////////////////////////////////////////////////////////////////////////////////
227:
228: #if defined(_MSC_VER) || defined(__BORLANDC__)
229: unsigned sleep(unsigned seconds);
230: #else
231: #include <unistd.h>
232: #endif
233:
234: ////////////////////////////////////////////////////////////////////////////////
235: // Function for establishing endian-ness
236: ////////////////////////////////////////////////////////////////////////////////
237: // Different machine architectures store data using different byte orders.
238: // This is referred to as Big- and Little-Endian Byte Ordering.
239: //
240: // The issue is: where does a pointer to an integer type actually point?
241: //
242: // In both conventions, the address points to the left of the word but:
243: // Big-Endian - The most significant byte is on the left end of a word
244: // Little-Endian - The least significant byte is on the left end of a word
245: //
246: // Bytes are addressed left to right, so in big-endian order byte 0 is the
247: // msB, whereas in little-endian order byte 0 is the lsB. For example,
248: // Intel-based machines store data in little-endian byte order so byte 0 is
249: // the lsB.
250: //
251: // This function establishes byte order at run-time
252:
253: bool little_endian(void);
254:
255: ////////////////////////////////////////////////////////////////////////////////
256: #endif