|
Boost : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-12-19 08:02:02
"Caleb Epstein" <caleb.epstein_at_[hidden]> wrote in message
news:989aceac0512182000m4bffe9caq67b1a9d8697b0da0_at_mail.gmail.com...
> ***See: http://tinyurl.com/7pp9r
>
> *These test results appear to pre-date line 69 below:
>
> 62 // BOOST_FILESYSTEM_STATUS_CACHE enables status_flags cache in
> 63 // dir_itr_increment. The config tests are placed here because
> some
> of the
> 64 // macros being tested come from dirent.h.
> 65 //
> 66 // TODO: "|| defined(__APPLE__)" compiles, but at runtime d_type is
> alwasy 0. Why?
> 67 // TODO: find out what macros enable dirent::d_type on various
> operating systems.
> 68 # if !defined(__CYGWIN__) && !defined(__osf__) \
> 69 && !(defined(__sun) && defined(__GLIBCXX__)) \
> 70 && (defined(BOOST_WINDOWS_API) \
> 71 || defined(__USE_BSD) || defined(_DIRENT_HAVE_D_TYPE) \
> 72 )
> 73 # define BOOST_FILESYSTEM_STATUS_CACHE
> 74 # endif
>
> So I expect Filesystem will compile properly on my Monday test run.
>
> However I think the macro test should just be for defined(__sun), and not
> both __sun && __GLIBCXX__.
>
> The lack of d_type in dirent is a C library issue, not a C++ library issue
> and as would affect any compiler on Solaris (e.g. SunPRO CC would hit this
> too).
My thinking was that there might be different C libraries available on Sun,
and I was trying to use __GLIBCXX__ to differentiate. But you are probably
right, so I'll make the change. In any can we are talking about an
optimization, so turning it off does no functional harm (although it may
impact performance).
Thanks,
--Beman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk