[uitility/result_of] CodeGear support of result_of
Hi, Seemingly, CodeGear does not support boost::result_of http://tinyurl.com/8onbjj I propose that this is officially recognized so that including <boost/utility/result_of.hpp> results in BOOST_NO_RESULT_OF being defined rather than the current compile error. This will benefit those result_of-dependent libraries honoring BOOST_NO_RESULT_OF (vg. Boost.Parameter). Joaquín M López Muñoz Telefónica, Investigación y Desarrollo||* *
joaquin@tid.es wrote:
Seemingly, CodeGear does not support boost::result_of
Isn't it, rather, that Boost.Config wrongly detects the compiler has decltype support?
On Jan 16, 2009, at 4:29 AM, Mathias Gaunard wrote:
joaquin@tid.es wrote:
Seemingly, CodeGear does not support boost::result_of http://tinyurl.com/8onbjj
Isn't it, rather, that Boost.Config wrongly detects the compiler has decltype support?
I believe so. The change below will remove the decltype configuration from codegear, but someone with more knowledge of this compiler's feature set should probably audit the config file, just in case. Daniel Walker Index: boost/config/compiler/codegear.hpp =================================================================== --- boost/config/compiler/codegear.hpp (revision 50629) +++ boost/config/compiler/codegear.hpp (working copy) @@ -65,7 +65,7 @@ # define BOOST_HAS_LONG_LONG //# define BOOST_HAS_ALIGNOF -# define BOOST_HAS_DECLTYPE +//# define BOOST_HAS_DECLTYPE # define BOOST_HAS_EXPLICIT_CONVERSION_OPS //# define BOOST_HAS_RVALUE_REFS # define BOOST_HAS_SCOPED_ENUM
In article <gkpk2n$22v$1@ger.gmane.org>, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Isn't it, rather, that Boost.Config wrongly detects the compiler has decltype support?
Well, decltype support is there, but this looks like yet another bug in CodeGear's templates and it just happens to be in a use case with decltype. -- -David
On Jan 16, 2009, at 6:17 PM, siliconman wrote:
In article <gkpk2n$22v$1@ger.gmane.org>, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Isn't it, rather, that Boost.Config wrongly detects the compiler has decltype support?
Well, decltype support is there, but this looks like yet another bug in CodeGear's templates and it just happens to be in a use case with decltype.
When did codegear begin decltype support? The current codegear config header configures Boost to assume decltype for all versions, which seems suspect. If codegear supports decltype well enough to configure Boost to use it, but not well enough to enable a C++0x-style result_of implementation, we could revert to the old result_of for the specific codegear version until someone finds a workaround or codegear's C++0x support matures. I don't have access to codegear myself. Daniel Walker
In article <E3FFB208-D69C-407B-B536-DC66617981A3@gmail.com>, Daniel Walker <daniel.j.walker@gmail.com> wrote:
When did codegear begin decltype support? The current codegear config header configures Boost to assume decltype for all versions, which seems suspect.
0x610 which is the first version that has __CODEGEARC__ defined. anything earlier would be the old __BORLANDC_ defines.
If codegear supports decltype well enough to configure Boost to use it, but not well enough to enable a C++0x-style result_of implementation, we could revert to the old result_of for the specific codegear version until someone finds a workaround or codegear's C++0x support matures. I don't have access to codegear myself.
I'm willing to try out any patches. -- -David
On Jan 16, 2009, at 8:05 PM, siliconman wrote:
In article <E3FFB208-D69C-407B-B536-DC66617981A3@gmail.com>, Daniel Walker <daniel.j.walker@gmail.com> wrote:
When did codegear begin decltype support? The current codegear config header configures Boost to assume decltype for all versions, which seems suspect.
0x610 which is the first version that has __CODEGEARC__ defined. anything earlier would be the old __BORLANDC_ defines.
Ah, I can't keep track of what's what anymore, all this rebranding and what not. ;)
If codegear supports decltype well enough to configure Boost to use it, but not well enough to enable a C++0x-style result_of implementation, we could revert to the old result_of for the specific codegear version until someone finds a workaround or codegear's C++0x support matures. I don't have access to codegear myself.
I'm willing to try out any patches.
OK. Patch attached. Actually, the decltype-based result_of implementation comes from a patch I submit and Doug applied last year. https://svn.boost.org/trac/boost/ticket/862 I went ahead and put my name on it even though this is mostly Doug's idea and all I did was code it up, write the test cases, update the documentation, and I suppose now, I'm attempting to support it as best I can. :) The patch adds a new macro. As always, compilers that cannot support result_of at all get BOOST_NO_RESULT_OF defined. But now, compilers that cannot support this implementation of the ISO draft specification of result_of get BOOST_NO_ISO_RESULT_OF defined. CodeGear tested at 0x610 is in the second camp but not the first. See the update documentation in utility.htm. Daniel Walker
participants (4)
-
Daniel Walker -
joaquin＠tid.es -
Mathias Gaunard -
siliconman