On 2/7/2011 10:42 AM, Frédéric Bron wrote:

...

Excellent. As always I am keenly interested in following this.

Do not hesitate to give it a try and report for issues. At some point, I would need to run the tests with MSVC++ and intel-linux (I work with g++). I have installed MSVC++ and I will see if I can get the testing procedure to work (I am not used to running bjam on windows). I would like first to fix everything with g++.

I would be willing to run the tests using VC8, VC9, and VC10. I wonder if you could create a target in the test jamfile just for the operatory traits on which you are working, since I would like to focus in my test on just the operator traits.

On 2/8/2011 3:55 PM, Frédéric Bron wrote:

...

I would be willing to run the tests using VC8, VC9, and VC10.

I wonder if you could create a target in the test jamfile just for the operatory traits on which you are working, since I would like to focus in my test on just the operator traits.

Done in revision r68732 of the sandbox. If you go in sandbox/type_traits/libs/type_traits/test $ bjam operators

Frédéric _______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Running this command line: bjam --boost=C:/Programming/VersionControl/boost toolset=msvc-10.0 operators from the test directory I get many lines like: compile-c-c++ ..\bin.v2\test\has_operator_multiplies_test.test\msvc-10.0\debug\threading-multi\has_operator_multiplies_test.obj has_operator_multiplies_test.cpp C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(147) : error C2065: 'has_operator_multiplies' : undeclared identifier C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(147) : error C2065: 'LHS' : undeclared identifier C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(147) : error C2065: 'RHS' : undeclared identifier C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(147) : error C2065: 'LHS' : undeclared identifier C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(147) : error C2065: 'RET' : undeclared identifier C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(147) : error C2062: type 'void' unexpected C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(147) : error C2065: 'LHS' : undeclared identifier C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(147) : error C2065: 'RHS' : undeclared identifier C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(147) : error C2065: 'RET' : undeclared identifier C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(147) : error C2955: 'boost::detail::has_operator_multiplies_impl::has_operator_multiplies_impl' : use of class template requires template argument list C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(136) : see declaration of 'boost::detail::has_operator_multiplies_impl::has_operator_multiplies_impl' etc. etc. Obviously something in the jamfile is not correct. I am pointing in my --boost parameter to bjam to my Boost tree of the trunk in SVN. Should I run against Boost 1.4.5 instead ?

On 2/9/2011 12:04 PM, Frédéric Bron wrote:

...

bjam --boost=C:/Programming/VersionControl/boost toolset=msvc-10.0 operators

from the test directory I get many lines like:

compile-c-c++ ..\bin.v2\test\has_operator_multiplies_test.test\msvc-10.0\debug\threading-multi\has_operator_multiplies_test.obj has_operator_multiplies_test.cpp C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(147) : error C2065: 'has_operator_multiplies' : undeclared identifier C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(147) : error C2065: 'LHS' : undeclared identifier

etc. etc.

Obviously something in the jamfile is not correct. I am pointing in my --boost parameter to bjam to my Boost tree of the trunk in SVN. Should I run against Boost 1.4.5 instead ?

I am compiliing againt 1.44. Can you try to bjam -d 2 so that we have more information about the commands that are executed.

Here is some of the information when running bjam with -d 2: "file ..\bin.v2\test\has_operator_multiplies_test.test\msvc-10.0\debug\threading-multi\has_operator_multiplies_test.obj.rsp "has_operator_multiplies_test.cpp" -Fo"..\bin.v2\test\has_operator_multiplies_test.test\msvc-10.0\debug\threading-multi\has_operator_multiplies_test.obj" -TP /Z7 /Od /Ob0 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t /wd4675 /EHs -c "-IC:\Programming\VersionControl\boost" "-IC:\Programming\VersionControl\sandbox\type_traits" compile-c-c++ ..\bin.v2\test\has_operator_multiplies_test.test\msvc-10.0\debug\threading-multi\has_operator_multiplies_test.obj call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"..\bin.v2\test\has_operator_multiplies_test.test\msvc-10.0\debug\threading-multi\has_operator_multiplies_test.obj.rsp" " and in the rsp file: "has_operator_multiplies_test.cpp" -Fo"..\bin.v2\test\has_operator_multiplies_test.test\msvc-10.0\debug\threading-multi\has_operator_multiplies_test.obj" -TP /Z7 /Od /Ob0 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t /wd4675 /EHs -c "-IC:\Programming\VersionControl\boost" "-IC:\Programming\VersionControl\sandbox\type_traits" What appears to be happening is that the include path for the entire Boost tree installation, which in my case I am pointing to the latest SVN trunk, takes precedence to the include path in the sandbox type_traits directory. This may be the reason why the errors are being seen since if it picks up the appropriate include files from the SVN Boost trunk it will not find your changes. I am not sure how I can change this to make it work properly, even if I pointed to another Boost tree, such as 1.4.5 or 1.4.4 which I have on my machine. It would still be picking up from that tree first. Nor do i know how to tell bjam how to use your snadbox include files first. And naturally I need to point to some Boost tree distribution, else none of the libraries Type Traits depend on, such as Boost MPL, will be found if I do not. It seems the only solution is that I must put the sandbox type_traits on top of the type_traits in the SVN trunk and then test from within the trunk. But that is a real PITA. I wish I knew if there was a way to get the Boost Build system to pick up the sandbox include path before it does the Boost tree inslude path.

I have just tried a small example in VC++2010 and it works fine, although there are plenty of warnings. in linux, I have BOOST_BUILD_PATH pointing to path_to_boost_1_44_0/tools/build/v2 I do not use the command line option --boost but it is probably the same? maybe if I get a windows binary of bjam for windows, I can try the same as you.

Frédéric _______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Who knows how to run the tests in the sandbox on windows with msvc? Or who could test for us?

I have made some progress: using the following user-config.jam: using msvc : 10.0 : : <compileflags>"\"-ID:\\Softs\\Microsoft Visual Studio 10.0\\VC\\include\"" <compileflags>"\"-ID:\\sandbox\\type_traits\"" <compileflags>"\"-ID:\\Softs\\1.5\\mgw-release\\boost\\include\"" ; But the linker says it cannot find msvcprtd.lib. I would like to say to the linker to look in D:\Softs\Microsoft Visual Studio 10.0\VC\lib for libraries. How do I say that in user-config.jam? Frédéric

On 2/10/2011 8:08 AM, Vicente Botet wrote:

Frédéric Bron wrote:

...

...

Who knows how to run the tests in the sandbox on windows with msvc? Or who could test for us?

I have made some progress: using the following user-config.jam: using msvc : 10.0 : : <compileflags>"\"-ID:\\Softs\\Microsoft Visual Studio 10.0\\VC\\include\"" <compileflags>"\"-ID:\\sandbox\\type_traits\"" <compileflags>"\"-ID:\\Softs\\1.5\\mgw-release\\boost\\include\"" ;

But the linker says it cannot find msvcprtd.lib. I would like to say to the linker to look in D:\Softs\Microsoft Visual Studio 10.0\VC\lib for libraries. How do I say that in user-config.jam?

Hi,

as a possible user/tester of the library I would prefer if the library package contains only the new files so we can decompress them directly on the boost root system. If the name of the directory was specific this could be even easier (e.g. why not movie temporary all your new files to a specific directory "operators")

One should be able to test a sandbox library within its own sandbox directory. I think it is a fault of the Boost Build system that it does not automatically place the compiler include flag for the sandbox library before the compiler include flag for a Boost distribution when executing the compiler's command line and BOOST_ROOT ( or BOOST ) points to a Boost distribution.

as a possible user/tester of the library I would prefer if the library package contains only the new files so we can decompress them directly on the boost root system. If the name of the directory was specific this could be even easier (e.g. why not movie temporary all your new files to a specific directory "operators")

Can you tell me what you would like more precisely: - only the header files, - everything, including test files and documentation? I could tar it so that if you extract it from a boost distribution you get: boost/type_traits/has_operator_xxx.hpp libs/type_traits/test/... libs/type_traits/doc/... For the doc however the merge could be a problem... Frédéric

On 2/10/11 12:52 PM, "Frédéric Bron" <frederic.bron@m4x.org> wrote:

...

as a possible user/tester of the library I would prefer if the library package contains only the new files so we can decompress them directly on the boost root system. If the name of the directory was specific this could be even easier (e.g. why not movie temporary all your new files to a specific directory "operators")

Can you tell me what you would like more precisely: - only the header files, - everything, including test files and documentation?

I could tar it so that if you extract it from a boost distribution you get: boost/type_traits/has_operator_xxx.hpp libs/type_traits/test/... libs/type_traits/doc/...

For the doc however the merge could be a problem...

When trying to work on a modularized boost, it would be very helpful if each library was set up like so: type_traits/ test/ doc/ ... src/ build/ *.jam boost/ type_traits/hasoperator_xxx.hpp Then use the .jam file to copy/symlink libs/type_traits/boost/typetraits to boost_1_45_0/boost/typetraits Then developers could create a git,svn,cvs,tar.gz repository of just 'type_traits' and put it in boost/libs and it would be very easy to manage individual libraries without having to worry about the problems with 'overlaying' two directory structures manually via .zip files. It seems like such a change would be relatively small, yet ease the transition to something like ryppl or Boost.CMake.

Frédéric _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Feb 10, 2011, at 3:34 PM, Edward Diener wrote:

On 2/10/2011 2:14 PM, Daniel Larimer wrote:

...

On 2/10/11 12:52 PM, "Frédéric Bron"<frederic.bron@m4x.org> wrote:

...

...

as a possible user/tester of the library I would prefer if the library package contains only the new files so we can decompress them directly on the boost root system. If the name of the directory was specific this could be even easier (e.g. why not movie temporary all your new files to a specific directory "operators")

Can you tell me what you would like more precisely: - only the header files, - everything, including test files and documentation?

I could tar it so that if you extract it from a boost distribution you get: boost/type_traits/has_operator_xxx.hpp libs/type_traits/test/... libs/type_traits/doc/...

For the doc however the merge could be a problem...

When trying to work on a modularized boost, it would be very helpful if each library was set up like so:

type_traits/ test/ doc/ ... src/ build/ *.jam boost/ type_traits/hasoperator_xxx.hpp

Then use the .jam file to copy/symlink libs/type_traits/boost/typetraits to boost_1_45_0/boost/typetraits

Then developers could create a git,svn,cvs,tar.gz repository of just 'type_traits' and put it in boost/libs and it would be very easy to manage individual libraries without having to worry about the problems with 'overlaying' two directory structures manually via .zip files.

It seems like such a change would be relatively small, yet ease the transition to something like ryppl or Boost.CMake.

I do not think a jamfile should be copying anything to a hardcoded path outside of the directories in which the library resides. That is a real recipe for ticked off end-users.

Boost.Context used something like this to overwrite boost/context/context.hpp with the proper version for the platform it was on. The only other option to avoid a copy would be to add boost/libs/typetraits to the include path, but ultimately the headers need to be 'installed' someplace. I don't think it is any different than the jam file writing to the bin dir. And having an unzip go wrong is much more likely to tick off a user than a 'well defined' bjam script. Presumably a library 'owns' its directory in libs/MODULE and boost/MODULE and boost/MODULE.hpp so as long as the library maintainer tells it to do the right thing that maintainer will not tick off end-users.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Feb 10, 2011, at 5:41 PM, Edward Diener wrote:

On 2/10/2011 5:20 PM, Daniel Larimer wrote:

...

On Feb 10, 2011, at 3:34 PM, Edward Diener wrote:

...

On 2/10/2011 2:14 PM, Daniel Larimer wrote:

...

On 2/10/11 12:52 PM, "Frédéric Bron"<frederic.bron@m4x.org> wrote:

...

...

as a possible user/tester of the library I would prefer if the library package contains only the new files so we can decompress them directly on the boost root system. If the name of the directory was specific this could be even easier (e.g. why not movie temporary all your new files to a specific directory "operators")

Can you tell me what you would like more precisely: - only the header files, - everything, including test files and documentation?

I could tar it so that if you extract it from a boost distribution you get: boost/type_traits/has_operator_xxx.hpp libs/type_traits/test/... libs/type_traits/doc/...

For the doc however the merge could be a problem...

When trying to work on a modularized boost, it would be very helpful if each library was set up like so:

type_traits/ test/ doc/ ... src/ build/ *.jam boost/ type_traits/hasoperator_xxx.hpp

Then use the .jam file to copy/symlink libs/type_traits/boost/typetraits to boost_1_45_0/boost/typetraits

Then developers could create a git,svn,cvs,tar.gz repository of just 'type_traits' and put it in boost/libs and it would be very easy to manage individual libraries without having to worry about the problems with 'overlaying' two directory structures manually via .zip files.

It seems like such a change would be relatively small, yet ease the transition to something like ryppl or Boost.CMake.

I do not think a jamfile should be copying anything to a hardcoded path outside of the directories in which the library resides. That is a real recipe for ticked off end-users.

Boost.Context used something like this to overwrite boost/context/context.hpp with the proper version for the platform it was on.

If it is writing to some place outside of its tree, it is wrong. How can a library know where the user is running its jam files from ? Unless of course the library spells out a restriction that it must be installed on top of some Boost distribution to work.

...

The only other option to avoid a copy would be to add boost/libs/typetraits to the include path, but ultimately the headers need to be 'installed' someplace.

I have put a query in the build NG as to why the Boost Build system places the includes for a Boost distribution before the includes of a sandbox library itself. This to me is clearly wrong.

...

I don't think it is any different than the jam file writing to the bin dir. And having an unzip go wrong is much more likely to tick off a user than a 'well defined' bjam script. Presumably a library 'owns' its directory in libs/MODULE and boost/MODULE and boost/MODULE.hpp so as long as the library maintainer tells it to do the right thing that maintainer will not tick off end-users.

The bin directory is within the directory structure of a Boost distribution or sandbox library. If I am testing a sandbox library from its own directory how can it know where to put files outside its own directory structure ? It does not even know what Boost distributions I have on my system.

I think you misunderstood what I was saying. I was not suggesting that it should install anyplace outside of the boost_1_4x_0 directory where you are building. You could have multiple boost versions/sandboxes. I am simply suggesting that to "add an unofficial library" to your sandbox you should only have to unzip (or git clone) one folder in libs and not have to manually place files in multiple locations. boost_1_44_0 ... boost_1_45_0/ libs/ context/ (context git repository) boost/ context/ context.hpp src examples ... build .jam (creates symlink or copies ../boost/context to ../../../boost/context ) boost/ context -> ../libs/context Currently there is no way (that I know of) to have a git repository checkout 'partial trees' such that you can overlay multiple git repositories (one for context, one for atomic, one for some other library) inside the same sandbox.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 2/9/2011 3:50 PM, Frédéric Bron wrote:

...

What appears to be happening is that the include path for the entire Boost tree installation, which in my case I am pointing to the latest SVN trunk, takes precedence to the include path in the sandbox type_traits directory. This may be the reason why the errors are being seen since if it picks up the appropriate include files from the SVN Boost trunk it will not find your changes.

This is strange as with linux it does the contrary. For me, it is even more difficult as it seems that MS Visual Studio Express 2010 does not modify the PATH so I had to add some directories by hand. Even with that, the compiler cannot find the standard headers: fatal error C1083: Cannot open file include: 'cstddef': No such file or directory But I can see that the include directories are in the wrong order as for you. Maybe John you can help on that point?

So the question is: Who knows how to run the tests in the sandbox on windows with msvc? Or who could test for us?

I needed to change the project-root.jam in the sandbox libs/type_traits so that the last lines read: project tt : requirements <include>$(tt-header-include)&&$(boost-root) : # build everything in ./bin.v2 build-dir bin.v2 ; This forces the tt header directory to be included before a Boost distribution. Finally I could run the test using msvc 10.0 without compiler errors: When I ran the operator tests I see, as an example: has_operator_multiplies_test.cpp msvc.link ..\bin.v2\test\has_operator_multiplies_test.test\msvc-10.0\debug\threading-multi\has_operator_multiplies_test.exe msvc.manifest ..\bin.v2\test\has_operator_multiplies_test.test\msvc-10.0\debug\threading-multi\has_operator_multiplies_test.exe testing.capture-output ..\bin.v2\test\has_operator_multiplies_test.test\msvc-10.0\debug\threading-multi\has_operator_multiplies_test.run ====== BEGIN OUTPUT ====== c:\programming\versioncontrol\sandbox\type_traits\libs\type_traits\test\has_no_pointer_operator_test.hpp:312: The expression: "(::boost::has_operator_multiplies<bool,bool,bool>::value)" had an invalid value (found 0, expected 1) c:\programming\versioncontrol\sandbox\type_traits\libs\type_traits\test\has_no_pointer_operator_test.hpp:313: The expression: "(::boost::has_operator_multiplies<bool,char,bool>::value)" had an invalid value (found 0, expected 1) c:\programming\versioncontrol\sandbox\type_traits\libs\type_traits\test\has_no_pointer_operator_test.hpp:314: The expression: "(::boost::has_operator_multiplies<bool,signed char,bool>::value)" had an invalid value (found 0, expected 1) c:\programming\versioncontrol\sandbox\type_traits\libs\type_traits\test\has_no_pointer_operator_test.hpp:315: The expression: "(::boost::has_operator_multiplies<bool,short int,bool>::value)" had an invalid value (found 0, expected 1) c:\programming\versioncontrol\sandbox\type_traits\libs\type_traits\test\has_no_pointer_operator_test.hpp:316: The expression: "(::boost::has_operator_multiplies<bool,int,bool>::value)" had an invalid value (found 0, expected 1) c:\programming\versioncontrol\sandbox\type_traits\libs\type_traits\test\has_no_pointer_operator_test.hpp:317: The expression: "(::boost::has_operator_multiplies<bool,long int,bool>::value)" had an invalid value (found 0, expected 1) This goes on for each line of that test. There is also a huge amount of chuff for some other test along the lines of: compile-c-c++ ..\bin.v2\test\has_operator_not_equal_to_test.test\msvc-10.0\debug\threading-multi\has_operator_not_equal_to_test.obj has_operator_not_equal_to_test.cpp C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(102) : warning C4805: '!=' : unsafe mix of type 'bool' and type 'char' in operation C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(141) : see reference to class template instantiation 'boost::detail::has_operator_not_equal_to_impl::has_operator_not_equal_to_impl1<LHS,RHS,RET,forbidden_if>' being compiled with [ LHS=bool, RHS=char, RET=void, forbidden_if=false ] C:\Programming\VersionControl\sandbox\type_traits\boost/type_traits/detail/has_binary_operator.hpp(147) : see reference to class template instantiation 'boost::detail::has_operator_not_equal_to_impl::has_operator_not_equal_to_impl<LHS,RHS,RET>' being compiled with [ LHS=bool, RHS=char, RET=void ] c:\programming\versioncontrol\sandbox\type_traits\libs\type_traits\test\has_comparison_operator_test.hpp(87) : see reference to class template instantiation 'boost::has_operator_not_equal_to<LHS,RHS>' being compiled with [ LHS=bool, RHS=char ] And this warning is repeated for line 102 of has_binary_operator.hpp endlessly. You need a pragma in there to turn off C4806 else the output is very huge and unreadable. I will put something in there myself temporarily to try to remove the warning for VC and then try to run the test again.

On 2/11/2011 11:27 AM, Frédéric Bron wrote:

Thanks for running the tests. Very useful. Any difference between versions of VC++? Could you also send a list of tests that passed and tests that did not? Or maybe just drop the log file in the vault so that I can get it and process it.

First I need to filter out the warning message, which by its repetition creates a huge log file. Then I will drop results in the vault for VC8, VC9, and VC10 for your library as long as I have access to the Boost vault. I hope to have this for you by the end of the weekend at latest.

On 2/12/2011 1:21 AM, Frédéric Bron wrote:

...

First I need to filter out the warning message, which by its repetition creates a huge log file. Then I will drop results in the vault for VC8, VC9, and VC10 for your library as long as I have access to the Boost vault. I hope to have this for you by the end of the weekend at latest.

Take your time, I have already some work with what you already sent. I am trying to understand why msvc does not work as g++ for has_opeartor_multiplies<bool, bool, bool>.

After getting your latest update from the sandbox I ran the tests using VC++ 8,9,10. All the tests passed but with many warnings, which you should probably attempt to eliminate as much as possible. I uploaded the test results to the Boost Vault in the Home / Test directory as msvctests.zip. In order to run the tests I had to make a change to the project-root.jam locally. The last lines of that file with my change read: project tt : requirements <include>$(tt-header-include)&&$(boost-root) : # build everything in ./bin.v2 build-dir bin.v2 ; This forces the sandbox directory to be included before any Boost directory when compiling.

On 2/15/2011 3:34 PM, Frédéric Bron wrote:

...

After getting your latest update from the sandbox I ran the tests using VC++ 8,9,10. All the tests passed but with many warnings, which you should probably attempt to eliminate as much as possible. I uploaded the test results to the Boost Vault in the Home / Test directory as msvctests.zip.

This is very encouraging! I will put some pragma to remove the warnings and then I will ask you if you can rerun the tests because I cannot myself. I have only the Express version of VC++ and for a reason I do not know, linking does not work outside the IDE. Thanks a lot for testing. I am getting closer to the review.

That is fine. Tell me whenever you have updated the sandbox and I will get the latest changes, run the tests again, and upload the results to the same folder in the vault. I am glad to help as I intend to use your type traits operators for another library on which I am working.

On 2/16/2011 2:48 PM, Frédéric Bron wrote:

...

That is fine. Tell me whenever you have updated the sandbox and I will get the latest changes, run the tests again, and upload the results to the same folder in the vault. I am glad to help as I intend to use your type traits operators for another library on which I am working.

I have added some more testing of cv-qualifiers and references and discovered some new bugs which I have corrected. I have added the #pragma to remove the warnings.

Could run again the tests: - vault unix newlines: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits.tar.bz2&directory=Extension& - vault dos newlines: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits-dos.tar.bz2&directory=Extension& - sandbox: http://svn.boost.org/svn/boost/sandbox/type_traits/

I think the code is pretty ready for review now. I must work a bit more on the documentation.

I obtained your latest code from the sandbox and VC++ 8,9, and 10 all pass with no warnings at all ! Congrats !

I obtained your latest code from the sandbox and VC++ 8,9, and 10 all pass with no warnings at all ! Congrats !

I have uploaded a new version of the code with one more operator (prefix *) and more testing. - vault unix newlines: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits.tar.bz2&directory=Extension& - vault dos newlines: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits-dos.tar.bz2&directory=Extension& - sandbox: http://svn.boost.org/svn/boost/sandbox/type_traits/ In addition, I have been able to fix an issue leading to compile time error when the return type RET of an existing operator had operator,(RET, int) overloaded. Example: struct RET { void operator,(int); }; struct A { RET operator-(); } boost::has_operator_prefix_minus<A>::value; // this yielded an compile time error -> now fixed. As this will be the last version for the review starting on March 14th. Would you (Edward) be so kind to run all the tests again with MSVC 8, 9 and 10? Kind regards, Frédéric

Just tested with intel-linux 11.1: all tests pass. Frédéric