1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
---|
2 | |
---|
3 | <html> |
---|
4 | <head> |
---|
5 | <meta http-equiv="Content-Language" content="en-us"> |
---|
6 | <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> |
---|
7 | |
---|
8 | <title>Portability Hints: Borland C++ 5.5.1</title> |
---|
9 | </head> |
---|
10 | |
---|
11 | <body bgcolor="#FFFFFF" text="#000000"> |
---|
12 | <table border="1" bgcolor="#007F7F" cellpadding="2" summary=""> |
---|
13 | <tr> |
---|
14 | <td bgcolor="#FFFFFF"><img src="../boost.png" alt= |
---|
15 | "boost.png (6897 bytes)" width="277" height="86"></td> |
---|
16 | |
---|
17 | <td><a href="../index.htm"><font face="Arial,Helvetica" color= |
---|
18 | "#FFFFFF"><big>Home</big></font></a></td> |
---|
19 | |
---|
20 | <td><a href="../libs/libraries.htm"><font face="Arial,Helvetica" color= |
---|
21 | "#FFFFFF"><big>Libraries</big></font></a></td> |
---|
22 | |
---|
23 | <td><a href="../people/people.htm"><font face="Arial,Helvetica" color= |
---|
24 | "#FFFFFF"><big>People</big></font></a></td> |
---|
25 | |
---|
26 | <td><a href="faq.htm"><font face="Arial,Helvetica" color= |
---|
27 | "#FFFFFF"><big>FAQ</big></font></a></td> |
---|
28 | |
---|
29 | <td><a href="index.htm"><font face="Arial,Helvetica" color= |
---|
30 | "#FFFFFF"><big>More</big></font></a></td> |
---|
31 | </tr> |
---|
32 | </table> |
---|
33 | |
---|
34 | <h1>Portability Hints: Borland C++ 5.5.1</h1> |
---|
35 | |
---|
36 | <p>It is a general aim for boost libraries to be <a href= |
---|
37 | "lib_guide.htm#Portability">portable</a>. The primary means for achieving |
---|
38 | this goal is to adhere to ISO Standard C++. However, ISO C++ is a broad and |
---|
39 | complex standard and most compilers are not fully conformant to ISO C++ |
---|
40 | yet. In order to achieve portability in the light of this restriction, it |
---|
41 | seems advisable to get acquainted with those language features that some |
---|
42 | compilers do not fully implement yet.</p> |
---|
43 | |
---|
44 | <p>This page gives portability hints on some language features of the |
---|
45 | Borland C++ version 5.5.1 compiler. Furthermore, the appendix presents |
---|
46 | additional problems with Borland C++ version 5.5. Borland C++ 5.5.1 is a |
---|
47 | freely available command-line compiler for Win32 available at <a href= |
---|
48 | "http://www.borland.com/">http://www.borland.com/</a>.</p> |
---|
49 | |
---|
50 | <p>Each entry in the following list describes a particular issue, complete |
---|
51 | with sample source code to demonstrate the effect. Most sample code herein |
---|
52 | has been verified to compile with gcc 2.95.2 and Comeau C++ 4.2.44.</p> |
---|
53 | |
---|
54 | <h2>Preprocessor symbol</h2> |
---|
55 | |
---|
56 | <p>The preprocessor symbol <code>__BORLANDC__</code> is defined for all |
---|
57 | Borland C++ compilers. Its value is the version number of the compiler |
---|
58 | interpreted as a hexadecimal number. The following table lists some known |
---|
59 | values.</p> |
---|
60 | |
---|
61 | <table border="1" summary=""> |
---|
62 | <tr> |
---|
63 | <th>Compiler</th> |
---|
64 | |
---|
65 | <th><code>__BORLANDC__</code> value</th> |
---|
66 | </tr> |
---|
67 | |
---|
68 | <tr> |
---|
69 | <td>Borland C++ Builder 4</td> |
---|
70 | |
---|
71 | <td>0x0540</td> |
---|
72 | </tr> |
---|
73 | |
---|
74 | <tr> |
---|
75 | <td>Borland C++ Builder 5</td> |
---|
76 | |
---|
77 | <td>0x0550</td> |
---|
78 | </tr> |
---|
79 | |
---|
80 | <tr> |
---|
81 | <td>Borland C++ 5.5</td> |
---|
82 | |
---|
83 | <td>0x0550</td> |
---|
84 | </tr> |
---|
85 | |
---|
86 | <tr> |
---|
87 | <td>Borland C++ 5.5.1</td> |
---|
88 | |
---|
89 | <td>0x0551</td> |
---|
90 | </tr> |
---|
91 | |
---|
92 | <tr> |
---|
93 | <td>Borland C++ Builder 6</td> |
---|
94 | |
---|
95 | <td>0x0560</td> |
---|
96 | </tr> |
---|
97 | </table> |
---|
98 | |
---|
99 | <h2>Core Language</h2> |
---|
100 | |
---|
101 | <h3>[using-directive] Mixing <code>using</code>-declarations and |
---|
102 | <code>using</code>-directives</h3> |
---|
103 | |
---|
104 | <p>Mixing <code>using</code>-directives (which refer to whole namespaces) |
---|
105 | and namespace-level <code>using</code>-declarations (which refer to |
---|
106 | individual identifiers within foreign namespaces) causes ambiguities where |
---|
107 | there are none. The following code fragment illustrates this:</p> |
---|
108 | <pre> |
---|
109 | namespace N { |
---|
110 | int x(); |
---|
111 | } |
---|
112 | |
---|
113 | using N::x; |
---|
114 | using namespace N; |
---|
115 | |
---|
116 | int main() |
---|
117 | { |
---|
118 | &x; // Ambiguous overload |
---|
119 | } |
---|
120 | </pre> |
---|
121 | |
---|
122 | <h3>[using template] <code>using</code>-declarations for class |
---|
123 | templates</h3> |
---|
124 | |
---|
125 | <p>Identifiers for class templates can be used as arguments to |
---|
126 | <code>using</code>-declarations as any other identifier. However, the |
---|
127 | following code fails to compile with Borland C++:</p> |
---|
128 | <pre> |
---|
129 | template<class T> |
---|
130 | class X { }; |
---|
131 | |
---|
132 | namespace N |
---|
133 | { |
---|
134 | // "cannot use template 'X<T>' without specifying specialization parameters" |
---|
135 | using ::X; |
---|
136 | }; |
---|
137 | </pre> |
---|
138 | |
---|
139 | <h3>[template const arg] Deduction of constant arguments to function |
---|
140 | templates</h3> |
---|
141 | |
---|
142 | <p>Template function type deduction should omit top-level constness. |
---|
143 | However, this code fragment instantiates "f<const int>(int)":</p> |
---|
144 | <pre> |
---|
145 | template<class T> |
---|
146 | void f(T x) |
---|
147 | { |
---|
148 | x = 1; // works |
---|
149 | (void) &x; |
---|
150 | T y = 17; |
---|
151 | y = 20; // "Cannot modify a const object in function f<const int>(int)" |
---|
152 | (void) &y; |
---|
153 | } |
---|
154 | |
---|
155 | int main() |
---|
156 | { |
---|
157 | const int i = 17; |
---|
158 | f(i); |
---|
159 | } |
---|
160 | </pre> |
---|
161 | |
---|
162 | <h3>[function address] Resolving addresses of overloaded functions</h3> |
---|
163 | |
---|
164 | <p>Addresses of overloaded functions are not in all contexts properly |
---|
165 | resolved (std:13.4 [over.over]); here is a small example:</p> |
---|
166 | <pre> |
---|
167 | template<class Arg> |
---|
168 | void f( void(*g)(Arg) ); |
---|
169 | |
---|
170 | void h(int); |
---|
171 | void h(double); |
---|
172 | |
---|
173 | template<class T> |
---|
174 | void h2(T); |
---|
175 | |
---|
176 | int main() |
---|
177 | { |
---|
178 | void (*p)(int) = h; // this works (std:13.4-1.1) |
---|
179 | void (*p2)(unsigned char) = h2; // this works as well (std:13.4-1.1) |
---|
180 | f<int>(h2); // this also works (std:13.4-1.3) |
---|
181 | |
---|
182 | // "Cannot generate template specialization from h(int)", |
---|
183 | // "Could not find a match for f<Arg>(void (*)(int))" |
---|
184 | f<double>(h); // should work (std:13.4-1.3) |
---|
185 | |
---|
186 | f( (void(*)(double))h); // C-style cast works (std:13.4-1.6 with 5.4) |
---|
187 | |
---|
188 | // "Overloaded 'h' ambiguous in this context" |
---|
189 | f(static_cast<void(*)(double)>(h)); // should work (std:13.4-1.6 with 5.2.9) |
---|
190 | } |
---|
191 | </pre> |
---|
192 | |
---|
193 | <p><strong>Workaround:</strong> Always use C-style casts when determining |
---|
194 | addresses of (potentially) overloaded functions.</p> |
---|
195 | |
---|
196 | <h3>[string conversion] Converting <code>const char *</code> to |
---|
197 | <code>std::string</code></h3> |
---|
198 | |
---|
199 | <p>Implicitly converting <code>const char *</code> parameters to |
---|
200 | <code>std::string</code> arguments fails if template functions are |
---|
201 | explicitly instantiated (it works in the usual cases, though):</p> |
---|
202 | <pre> |
---|
203 | #include <string> |
---|
204 | |
---|
205 | template<class T> |
---|
206 | void f(const std::string & s) |
---|
207 | {} |
---|
208 | |
---|
209 | int main() |
---|
210 | { |
---|
211 | f<double>("hello"); // "Could not find a match for f<T>(char *)" |
---|
212 | } |
---|
213 | |
---|
214 | </pre> |
---|
215 | |
---|
216 | <p><strong>Workaround:</strong> Avoid explicit template function |
---|
217 | instantiations (they have significant problems with Microsoft Visual C++) |
---|
218 | and pass default-constructed unused dummy arguments with the appropriate |
---|
219 | type. Alternatively, if you wish to keep to the explicit instantiation, you |
---|
220 | could use an explicit conversion to <code>std::string</code> or declare the |
---|
221 | template function as taking a <code>const char *</code> parameter.</p> |
---|
222 | |
---|
223 | <h3>[template value defaults] Dependent default arguments for template |
---|
224 | value parameters</h3> |
---|
225 | |
---|
226 | <p>Template value parameters which default to an expression dependent on |
---|
227 | previous template parameters don't work:</p> |
---|
228 | <pre> |
---|
229 | template<class T> |
---|
230 | struct A |
---|
231 | { |
---|
232 | static const bool value = true; |
---|
233 | }; |
---|
234 | |
---|
235 | // "Templates must be classes or functions", "Declaration syntax error" |
---|
236 | template<class T, bool v = A<T>::value> |
---|
237 | struct B {}; |
---|
238 | |
---|
239 | int main() |
---|
240 | { |
---|
241 | B<int> x; |
---|
242 | } |
---|
243 | |
---|
244 | </pre> |
---|
245 | |
---|
246 | <p><strong>Workaround:</strong> If the relevant non-type template parameter |
---|
247 | is an implementation detail, use inheritance and a fully qualified |
---|
248 | identifier (for example, ::N::A<T>::value).</p> |
---|
249 | |
---|
250 | <h3>[function partial ordering] Partial ordering of function templates</h3> |
---|
251 | |
---|
252 | <p>Partial ordering of function templates, as described in std:14.5.5.2 |
---|
253 | [temp.func.order], does not work:</p> |
---|
254 | <pre> |
---|
255 | #include <iostream> |
---|
256 | |
---|
257 | template<class T> struct A {}; |
---|
258 | |
---|
259 | template<class T1> |
---|
260 | void f(const A<T1> &) |
---|
261 | { |
---|
262 | std::cout << "f(const A<T1>&)\n"; |
---|
263 | } |
---|
264 | |
---|
265 | template<class T> |
---|
266 | void f(T) |
---|
267 | { |
---|
268 | std::cout << "f(T)\n"; |
---|
269 | } |
---|
270 | |
---|
271 | int main() |
---|
272 | { |
---|
273 | A<double> a; |
---|
274 | f(a); // output: f(T) (wrong) |
---|
275 | f(1); // output: f(T) (correct) |
---|
276 | } |
---|
277 | </pre> |
---|
278 | |
---|
279 | <p><strong>Workaround:</strong> Declare all such functions uniformly as |
---|
280 | either taking a value or a reference parameter.</p> |
---|
281 | |
---|
282 | <h3>[instantiate memfun ptr] Instantiation with member function |
---|
283 | pointer</h3> |
---|
284 | |
---|
285 | <p>When directly instantiating a template with some member function |
---|
286 | pointer, which is itself dependent on some template parameter, the compiler |
---|
287 | cannot cope:</p> |
---|
288 | <pre> |
---|
289 | template<class U> class C { }; |
---|
290 | template<class T> |
---|
291 | class A |
---|
292 | { |
---|
293 | static const int v = C<void (T::*)()>::value; |
---|
294 | }; |
---|
295 | </pre> |
---|
296 | |
---|
297 | <p><strong>Workaround:</strong> Use an intermediate |
---|
298 | <code>typedef</code>:</p> |
---|
299 | <pre> |
---|
300 | template<class U> class C { }; |
---|
301 | template<class T> |
---|
302 | class A |
---|
303 | { |
---|
304 | typedef void (T::*my_type)(); |
---|
305 | static const int v = C<my_type>::value; |
---|
306 | }; |
---|
307 | </pre> |
---|
308 | |
---|
309 | <p>(Extracted from e-mail exchange of David Abrahams, Fernando Cacciola, |
---|
310 | and Peter Dimov; not actually tested.)</p> |
---|
311 | |
---|
312 | <h2>Library</h2> |
---|
313 | |
---|
314 | <h3>[cmath.abs] Function <code>double std::abs(double)</code> missing</h3> |
---|
315 | |
---|
316 | <p>The function <code>double std::abs(double)</code> should be defined |
---|
317 | (std:26.5-5 [lib.c.math]), but it is not:</p> |
---|
318 | <pre> |
---|
319 | #include <cmath> |
---|
320 | |
---|
321 | int main() |
---|
322 | { |
---|
323 | double (*p)(double) = std::abs; // error |
---|
324 | } |
---|
325 | </pre> |
---|
326 | |
---|
327 | <p>Note that <code>int std::abs(int)</code> will be used without warning if |
---|
328 | you write <code>std::abs(5.1)</code>.</p> |
---|
329 | |
---|
330 | <p>Similar remarks apply to seemingly all of the other standard math |
---|
331 | functions, where Borland C++ fails to provide <code>float</code> and |
---|
332 | <code>long double</code> overloads.</p> |
---|
333 | |
---|
334 | <p><strong>Workaround:</strong> Use <code>std::fabs</code> instead if type |
---|
335 | genericity is not required.</p> |
---|
336 | |
---|
337 | <h2>Appendix: Additional issues with Borland C++ version 5.5</h2> |
---|
338 | |
---|
339 | <p>These issues are documented mainly for historic reasons. If you are |
---|
340 | still using Borland C++ version 5.5, you are strongly encouraged to obtain |
---|
341 | an upgrade to version 5.5.1, which fixes the issues described in this |
---|
342 | section.</p> |
---|
343 | |
---|
344 | <h3>[inline friend] Inline friend functions in template classes</h3> |
---|
345 | |
---|
346 | <p>If a friend function of some class has not been declared before the |
---|
347 | friend function declaration, the function is declared at the namespace |
---|
348 | scope surrounding the class definition. Together with class templates and |
---|
349 | inline definitions of friend functions, the code in the following fragment |
---|
350 | should declare (and define) a non-template function "bool N::f(int,int)", |
---|
351 | which is a friend of class N::A<int>. However, Borland C++ v5.5 |
---|
352 | expects the function f to be declared beforehand:</p> |
---|
353 | <pre> |
---|
354 | namespace N { |
---|
355 | template<class T> |
---|
356 | class A |
---|
357 | { |
---|
358 | // "f is not a member of 'N' in function main()" |
---|
359 | friend bool f(T x, T y) { return x < y; } |
---|
360 | }; |
---|
361 | } |
---|
362 | |
---|
363 | int main() |
---|
364 | { |
---|
365 | N::A<int> a; |
---|
366 | } |
---|
367 | </pre> |
---|
368 | |
---|
369 | <p>This technique is extensively used in boost/operators.hpp. Giving in to |
---|
370 | the wish of the compiler doesn't work in this case, because then the |
---|
371 | "instantiate one template, get lots of helper functions at namespace scope" |
---|
372 | approach doesn't work anymore. Defining BOOST_NO_OPERATORS_IN_NAMESPACE (a |
---|
373 | define BOOST_NO_INLINE_FRIENDS_IN_CLASS_TEMPLATES would match this case |
---|
374 | better) works around this problem and leads to another one, see |
---|
375 | [using-template].</p> |
---|
376 | <hr> |
---|
377 | |
---|
378 | <p><a href="http://validator.w3.org/check?uri=referer"><img border="0" src= |
---|
379 | "http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01 Transitional" |
---|
380 | height="31" width="88"></a></p> |
---|
381 | |
---|
382 | <p>Revised |
---|
383 | <!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->03 |
---|
384 | December, 2006<!--webbot bot="Timestamp" endspan i-checksum="38512" --></p> |
---|
385 | |
---|
386 | <p><i>Copyright © 2000-2002 <a href="../people/jens_maurer.htm">Jens |
---|
387 | Maurer</a></i></p> |
---|
388 | |
---|
389 | <p><i>Distributed under the Boost Software License, Version 1.0. (See |
---|
390 | accompanying file <a href="../LICENSE_1_0.txt">LICENSE_1_0.txt</a> or copy |
---|
391 | at <a href= |
---|
392 | "http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>)</i></p> |
---|
393 | </body> |
---|
394 | </html> |
---|