Boost logo

Boost :

From: Jonathan Turkanis (turkanis_at_[hidden])
Date: 2008-01-15 14:12:35


Hi,

I make one fairly modest use of result_of in Boost.Iostreams.

My initial implementation included result_of.hpp and guarded the use of
result_of with the macro BOOST_NO_RESULT_OF. I then discovered that
Borland 5.9.2 and Borland 5.9.3 don't support result_of well enough for
my needs, but that result_of.hpp header doesn't set BOOST_NO_RESULT_OF
for these toolsets (since they supposedly support SFINAE). So I added
checks for Borland version to the guard around result_of.

This worked until yesterday. Now it seems that simply including the
result_of header fails on Borland (see std_test_result_of_header:
http://tinyurl.com/26umcr).

I'd like to patch Iostreams as soon as possible, so I'm wondering
whether this regression will be resolved by making the header includable
by Borland or by marking std_test_result_of_header as an expected
failure. It seems to me that result_of.hpp either has to be
unconditionally includable, or BOOST_NO_RESULT_OF has to be defined in
boost/config.hpp so I can tell whether to include it.

If result_of is now really unusable on Borland (and if late model
Borland really supports SFINAE), then it's no longer true that
BOOST_NO_RESULT_OF is simply the disjunction of two existing config
macros, and so it seems natural to define it in config.hpp instead of in
result_of.hpp. (It could be defined in config/compiler/borland.hpp and
also in config/suffix.hpp if BOOST_NO_SFINAE or
BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION is defined.)

Thanks,

-- 
Jonathan Turkanis
CodeRage
http://www.coderage.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk