|
Boost : |
From: John Maddock (John_Maddock_at_[hidden])
Date: 1999-09-29 05:56:03
If I can reply to both at the same time....
>That's bugware. And bugware is a Bad Thing.<
Agreed,
>On the system where the library isn't in std (and
only those), if you #define std /*nothing*/, then
std::printf works fine.<
Thats fine, but what if the C++ library is in std, and the C libary is in
::
std::printf will be fine but now try and use std::list and your stuffed,
this is problem that I'm trying to work around - unfortunately this is the
problem which occurs in a compiler that has a very large market share -
MSVC.
>2) is my preference for .cpp files. But also check the C header is needed
at all. I have caught myself using <climits> for problems better solved
via <limits>.<
Agreed, I'll see how few C functions I can get away with, I was planning to
use things like memcpy to optimise some operations for POD types, via a
port of SGI's type_traits header. I guess an alternative would be
std::copy - its just a pity that so many standard library implementions
don't optimise this for POD types (only SGI does as far as know).
Perhaps I can pick your brains on a another related issue as well?
The problem is that some implementations of std::locale are distictly
non-standard (MSVC again) or absent altogether (SGI/gcc), now I can either
target only those implementaions that are standard (which means Rogue
Wave's standard libary + a decent compiler) or I can work around the
problem with a couple of macros for use_facet and has_facet, or use the C
localisation/string API's which takes us back to C header problems....
Before posting suggestions remember that this is all template code - which
means it's all in headers until someone starts supporting template
export....
... all of which means its starting to feel kind of rocky (as in hard
place) again :-)
Thanks again,
John.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk