
Hi everybody, If anybody can try or has recently tried the proposed typeof library with any compilelr, other than GCC or MSVC, can you please let me know what the results are? You can take the library at its usual place: http://boost-sandbox.sourceforge.net/vault/, typeof.zip Thanks a lot in advance. Regards, Arkadiy

Arkadiy Vertleyb wrote:
Hi everybody,
If anybody can try or has recently tried the proposed typeof library with any compilelr, other than GCC or MSVC, can you please let me know what the results are?
After some portability changes to the build files, this is what compiling on CodeWarrior 8.3 on Windows2K shows... ...found 669 targets... ...updating 12 targets... cw-C++-action bin\test\typeof.exe\cw-8_3\debug\threading-multi\main.obj ### mwcc Compiler: # File: main.cpp # ----------------- # 294: ); # Warning: ^ # illegal empty declaration ### mwcc Compiler: # 294: ); # Warning: ^ # illegal empty declaration ### mwcc Compiler: # 298: ); # Warning: ^ # illegal empty declaration ### mwcc Compiler: # 298: ); # Warning: ^ # illegal empty declaration ### mwcc Compiler: # 303: ); # Warning: ^ # illegal empty declaration ### mwcc Compiler: # 303: ); # Warning: ^ # illegal empty declaration cw-C++-action bin\test\typeof.exe\cw-8_3\debug\threading-multi\test_compliant.obj cw-C++-action bin\test\typeof.exe\cw-8_3\debug\threading-multi\odr1.obj cw-C++-action bin\test\typeof.exe\cw-8_3\debug\threading-multi\odr2.obj cw-Link-action bin\test\typeof.exe\cw-8_3\debug\threading-multi\typeof.exe ### mwld Linker Note: # Adding default library "MSL_All-DLL_x86_D.lib" to link order ### mwld Linker Note: # Adding default library "gdi32.lib" to link order ### mwld Linker Note: # Adding default library "kernel32.lib" to link order ### mwld Linker Note: # Adding default library "user32.lib" to link order ### mwld Linker Note: # Adding default library "MSL_All_x86.lib" to link order ### mwld Linker Note: # Including default library "MSL_All-DLL_x86_D.lib" ### mwld Linker Note: # Including default library "kernel32.lib" ### mwld Linker Warning: # No symbols were exported, deleting import library 'typeof.lib' cw-C++-action bin\test\typeof.exe\cw-8_3\release\threading-multi\main.obj ### mwcc Compiler: # File: main.cpp # ----------------- # 294: ); # Warning: ^ # illegal empty declaration ### mwcc Compiler: # 294: ); # Warning: ^ # illegal empty declaration ### mwcc Compiler: # 298: ); # Warning: ^ # illegal empty declaration ### mwcc Compiler: # 298: ); # Warning: ^ # illegal empty declaration ### mwcc Compiler: # 303: ); # Warning: ^ # illegal empty declaration ### mwcc Compiler: # 303: ); # Warning: ^ # illegal empty declaration cw-C++-action bin\test\typeof.exe\cw-8_3\release\threading-multi\test_compliant.obj cw-C++-action bin\test\typeof.exe\cw-8_3\release\threading-multi\odr1.obj cw-C++-action bin\test\typeof.exe\cw-8_3\release\threading-multi\odr2.obj cw-Link-action bin\test\typeof.exe\cw-8_3\release\threading-multi\typeof.exe ### mwld Linker Note: # Adding default library "MSL_All-DLL_x86.lib" to link order ### mwld Linker Note: # Adding default library "gdi32.lib" to link order ### mwld Linker Note: # Adding default library "kernel32.lib" to link order ### mwld Linker Note: # Adding default library "user32.lib" to link order ### mwld Linker Note: # Adding default library "MSL_All_x86.lib" to link order ### mwld Linker Note: # Including default library "MSL_All-DLL_x86.lib" ### mwld Linker Note: # Including default library "kernel32.lib" ### mwld Linker Warning: # No symbols were exported, deleting import library 'typeof.lib' ...updated 12 targets... Is there more to it than just compiling the program? Should it be run? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

Thanks a lot, Rene! "Rene Rivera" <grafik.list@redshift-software.com> wrote
After some portability changes to the build files, this is what compiling on CodeWarrior 8.3 on Windows2K shows...
[...] ...updated 12 targets...
Just warnings? Not bad at all :-) I will work on removing them...
Is there more to it than just compiling the program? Should it be run?
You can run it -- it should produce some meaningless output of a few similar lines... But the test is not really designd to test runtime stuff -- it is all about compile time assertions. Best regards, Arkadiy

Hi Rene, "Rene Rivera" <grafik.list@redshift-software.com> wrote
After some portability changes to the build files, this is what compiling on CodeWarrior 8.3 on Windows2K shows...
...found 669 targets... ...updating 12 targets... [some warnings] ...updated 12 targets...
The warnings should disappear if semicolons are removed from the lines 294, 298, 303. I will upload the updated version once I fix some other problems. Also some more questions: 1) Does this compiler have a native typeof? 2) Does it have some kind of "GCC mode"? I believe some compiler does, but I think it was Intel... 3) Does it support partial template specialization (I believe all compilers support it except vc6/7.0)? 4) What portability changes did you make to the build files? I am just trying to figure out which path the compiler chose... It would be much simpler if I knew of a portable way to output a message, like MSVC's pragma: #pragma message("using compliant implementation") Does CodeWarrior have anything similar? Thanks a lot, Regards, Arkadiy

Arkadiy Vertleyb wrote:
"Rene Rivera" <grafik.list@redshift-software.com> wrote
After some portability changes to the build files, this is what compiling on CodeWarrior 8.3 on Windows2K shows...
...found 669 targets... ...updating 12 targets... [some warnings] ...updated 12 targets...
The warnings should disappear if semicolons are removed from the lines 294, 298, 303.
I know :-)
I will upload the updated version once I fix some other problems.
Good.. Just holler if you need more testing.
Also some more questions:
Some of the questions are answered by looking at: http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/out... [http://tinyurl.com/55e52] Other answers...
1) Does this compiler have a native typeof? 2) Does it have some kind of "GCC mode"? I believe some compiler does, but I think it was Intel...
If by "GCC mode" you mean, compile like GCC. No. The only "GCC" compatibility I know of that it has is configuring it so that it searches for includes as GCC does.
3) Does it support partial template specialization (I believe all compilers support it except vc6/7.0)? 4) What portability changes did you make to the build files?
a. [minor] in boost-build.jam you can just use "/" instead of "$(SLASH)". BB will deal with it :-) -- Not really a portability issue for absolute paths, but it would be if using a relative path. b. Use "Jamfile", and "Jamrules" instead of "jamfile", and "jamrules". Case is important in non-windows platforms. c. In Jamfile, using "sysinclude" instead of "include". It matters for some compilers that make clear distinctions between the two, like CW. d. In Jamfile, use an "absolute" path instead of < include >../../.. -- The path will only work if the compiler uses the current directory to search from. And will break as soon as someone compiles outside of the specific directory. I'm attaching my version of Jamfile.
I am just trying to figure out which path the compiler chose... It would be much simpler if I knew of a portable way to output a message, like MSVC's pragma:
#pragma message("using compliant implementation")
Does CodeWarrior have anything similar?
It supports exactly that. CW supports most of the Microsoft "features" just so it can deal with windows.h :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org project-root ; variant debug_native : debug ; variant release_native : release ; local .pwd. = [ PWD ] ; exe typeof : main.cpp compliant/test_compliant.cpp compliant/odr1.cpp compliant/odr2.cpp : <sysinclude>C:/DevRoots/Boost/boost <sysinclude>$(.pwd.)/../../.. <gcc><debug><define>BOOST_TYPEOF_COMPLIANT <gcc><release><define>BOOST_TYPEOF_COMPLIANT <msvc><debug><define>BOOST_TYPEOF_VINTAGE <msvc><release><define>BOOST_TYPEOF_VINTAGE <vc-7><debug><define>BOOST_TYPEOF_VINTAGE <vc-7><release><define>BOOST_TYPEOF_VINTAGE <vc-7_1><debug><define>BOOST_TYPEOF_COMPLIANT <vc-7_1><release><define>BOOST_TYPEOF_COMPLIANT : debug debug_native ;

"Rene Rivera" <grafik.list@redshift-software.com> wrote
Arkadiy Vertleyb wrote:
"Rene Rivera" <grafik.list@redshift-software.com> wrote
After some portability changes to the build files, this is what compiling on CodeWarrior 8.3 on Windows2K shows...
...found 669 targets... ...updating 12 targets... [some warnings] ...updated 12 targets...
The warnings should disappear if semicolons are removed from the lines 294, 298, 303.
I know :-)
I will upload the updated version once I fix some other problems.
Good.. Just holler if you need more testing.
Also some more questions:
Some of the questions are answered by looking at:
http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/out put/metacomm-bin-boost-status-config_info-test-cw-8_3-debug-threading-multi. html
I didn't realise it was MetroWerks... No wonder it worked so smoothly -- it just used native typeof implementation :-) The emulation can also be tested on this compiler by defining BOOST_TYPEOF_COMPLIANT, but I don't know how much sense it would make...
Other answers...
1) Does this compiler have a native typeof? 2) Does it have some kind of "GCC mode"? I believe some compiler does,
but
I think it was Intel...
If by "GCC mode" you mean, compile like GCC. No. The only "GCC" compatibility I know of that it has is configuring it so that it searches for includes as GCC does.
3) Does it support partial template specialization (I believe all compilers support it except vc6/7.0)? 4) What portability changes did you make to the build files?
a. [minor] in boost-build.jam you can just use "/" instead of "$(SLASH)". BB will deal with it :-) -- Not really a portability issue for absolute paths, but it would be if using a relative path.
b. Use "Jamfile", and "Jamrules" instead of "jamfile", and "jamrules". Case is important in non-windows platforms.
c. In Jamfile, using "sysinclude" instead of "include". It matters for some compilers that make clear distinctions between the two, like CW.
d. In Jamfile, use an "absolute" path instead of < include >../../.. -- The path will only work if the compiler uses the current directory to search from. And will break as soon as someone compiles outside of the specific directory.
I'm attaching my version of Jamfile.
I am just trying to figure out which path the compiler chose... It would be much simpler if I knew of a portable way to output a message, like MSVC's pragma:
#pragma message("using compliant implementation")
Does CodeWarrior have anything similar?
It supports exactly that. CW supports most of the Microsoft "features" just so it can deal with windows.h :-)
Thanks, Arkadiy

Arkadiy Vertleyb wrote:
Hi everybody,
If anybody can try or has recently tried the proposed typeof library with any compilelr, other than GCC or MSVC, can you please let me know what the results are?
$ uname -a Linux x1000 2.6.11-hardened-r1 #1 Mon Mar 14 20:23:32 MSK 2005 i686 Intel(R) Pentium(R) M processor 1300MHz GenuineIntel GNU/Linux $ icc -V Intel(R) C++ Compiler for 32-bit applications, Version 8.0 Build 20031016Z Package ID: l_cc_p_8.0.055 Copyright (C) 1985-2003 Intel Corporation. All rights reserved. FOR NON-COMMERCIAL USE ONLY icc: Command line error: no files specified; for help type "icc -help" $ cat ./run time icc -I ~/src/boost/boost_1_32_0 -I ../../../.. test_compliant.cpp odr1.cpp odr2.cpp ../main.cpp time icc -I ~/src/boost/boost_1_32_0 -I ../../../.. test_compliant.cpp odr1.cpp odr2.cpp ../main.cpp -DBOOST_TYPEOF_COMPLIANT $ ./run 2> icc.err $ cat icc.err <attached> -- Alexander Nasonov

Arkadiy Vertleyb wrote:
Hi everybody,
If anybody can try or has recently tried the proposed typeof library with any compilelr, other than GCC or MSVC, can you please let me know what the results are?
You can take the library at its usual place:
http://boost-sandbox.sourceforge.net/vault/, typeof.zip
Hi Arkadiy, here are my results from testing with different versions of BCC. I had to tweak things around a bit to see some more than just the first lethal problem and attached a patch to document the changes described in this post. Note that this is _not_ intended as a patch to the library since things can and should be fixed more properly. BCC dies parsing the source: Error E2040 e:\Libs\Boost\MainCVS\boost/typeof/compliant/vector.hpp 56: Declaration terminated incorrectly Error E2299 e:\Libs\Boost\MainCVS\boost/typeof/compliant/vector.hpp 56: Cannot generate template specialization from 'v_iter<V,Pos>' This is macro code so the error actually comes from line 49. I changed the macro definition to: typedef vector ## n self; typedef v_iter<self , boost::mpl::int_<0> > begin; After fixing this it continues to complain in other places: All function-releated types other than function pointers cannot be handled by template specialization. This can be worked around for plain functions and function references by detecting them as function pointers (I still have some toy code for this, somewhere - in case you are interested). Member function pointers can only be matched via overloading when compiling with BCC. I just disabled the lower part of 'register_functions_iterate.hpp', for now. After this I get error from within the test suite (using the latest version): Borland C++ 5.6.5 for Win32 Copyright (c) 1993, 2004 Borland main.cpp: Error E2219 mpl/register.hpp 14: Wrong number of arguments in call of macro 'BOOST_PP_CHECK_2' Error E2219 mpl/register.hpp 14: Wrong number of arguments in call of macro 'BOOST_PP_SEQ_ELEM_III' Error E2219 mpl/register.hpp 14: Wrong number of arguments in call of macro 'BOOST_TYPEOF_MAKE_OBJ' Error E2219 mpl/register.hpp 14: Wrong number of arguments in call of macro 'BOOST_PP_CHECK_2' Error E2219 mpl/register.hpp 14: Wrong number of arguments in call of macro 'BOOST_PP_SEQ_ELEM_III' Error E2219 mpl/register.hpp 14: Wrong number of arguments in call of macro 'BOOST_PP_SEQ_HEAD' Error E2303 mpl/register.hpp 14: Type name expected Error E2293 mpl/register.hpp 14: ) expected Error E2293 mpl/register.hpp 14: ) expected Error E2219 mpl/register.hpp 14: Wrong number of arguments in call of macro 'BOOST_PP_SEQ_ELEM_III' Error E2219 mpl/register.hpp 14: Wrong number of arguments in call of macro 'BOOST_PP_SEQ_HEAD' Error E2219 mpl/register.hpp 15: Wrong number of arguments in call of macro 'BOOST_PP_CHECK_2' Error E2219 mpl/register.hpp 15: Wrong number of arguments in call of macro 'BOOST_PP_SEQ_ELEM_III' Error E2219 mpl/register.hpp 15: Wrong number of arguments in call of macro 'BOOST_TYPEOF_MAKE_OBJ' Error E2219 mpl/register.hpp 15: Wrong number of arguments in call of macro 'BOOST_PP_CHECK_2' Error E2219 mpl/register.hpp 15: Wrong number of arguments in call of macro 'BOOST_PP_SEQ_ELEM_III' Error E2219 mpl/register.hpp 15: Wrong number of arguments in call of macro 'BOOST_PP_SEQ_HEAD' Error E2303 mpl/register.hpp 15: Type name expected Error E2238 mpl/register.hpp 15: Multiple declaration for 'BOOST_PP_IIF_BOOST_PP_BOOL_BOOST_PP_IIF_BOOST_PP_BOOL_BOOST_PP_DEC_BOOST_PP_SEQ_SIZE_BOOST_PP_SEQ_SIZE_0BOOST_PP_SEQ_TAIL_IBOOST_PP_TUPLE_ELEM_3_2BOOST_PP_IIF_BOOST_PP_BOOL_BOOST_PP_DEC_BOOST_PP_SEQ_SIZE_BOOST_PP_SEQ_SIZE_0BOOST_PP_IIF_' Error E2344 mpl/register.hpp 14: Earlier declaration of 'BOOST_PP_IIF_BOOST_PP_BOOL_BOOST_PP_IIF_BOOST_PP_BOOL_BOOST_PP_DEC_BOOST_PP_SEQ_SIZE_BOOST_PP_SEQ_SIZE_0BOOST_PP_SEQ_TAIL_IBOOST_PP_TUPLE_ELEM_3_2BOOST_PP_IIF_BOOST_PP_BOOL_BOOST_PP_DEC_BOOST_PP_SEQ_SIZE_BOOST_PP_SEQ_SIZE_0BOOST_PP_IIF_' Error E2293 mpl/register.hpp 15: ) expected Error E2293 mpl/register.hpp 15: ) expected Error E2219 mpl/register.hpp 15: Wrong number of arguments in call of macro 'BOOST_PP_SEQ_ELEM_III' Error E2219 mpl/register.hpp 15: Wrong number of arguments in call of macro 'BOOST_PP_SEQ_HEAD' Error E2219 mpl/register.hpp 16: Wrong number of arguments in call of macro 'BOOST_PP_CHECK_2' Error E2228 mpl/register.hpp 16: Too many error or warning messages *** 26 errors in Compile *** Looks like something goes wrong preprocessing (I stopped here). There's even more trouble with Version 5.5: It complains about "size_t" in template paramter lists in 'typeof_impl.hpp'. I believe the type is just not visible at this point because using "std::size_t" instead solves it. The identifiers "at" and "size" seem to clash (with mpl ? - I did not fix this). And while we're at it - this (found in 'typeof_impl.hpp') can be problematic, too: template<...> char (&func(params))[ ice ]; and can be worked around like this: typename char_array< ice >::type func(params); The "size_t-issue" mentioned above continues in 'int_encoding.hpp' and "pack<...>::value" needs full qualification when used as a non-type template argument, so the compiler correctly it as an integral constant expression. Then BCC <= 5.5 finally dies with an internal compiler error (I didn't try to fix things any further because I wasn't sure that "compliant" is the right implementation type for BCC and if you plan to support old BCC versions, anyway | this might have to do with the unfixed name clash, metioned above). Regards, Tobias diff -ruN typeof/compliant/int_encoding.hpp typeof_modified/compliant/int_encoding.hpp --- typeof/compliant/int_encoding.hpp Fri Mar 4 21:36:00 2005 +++ typeof_modified/compliant/int_encoding.hpp Mon Apr 11 12:24:17 2005 @@ -37,13 +37,13 @@ ////////////////////////// - template<size_t n, bool Overflow> + template<std::size_t n, bool Overflow> struct pack { enum {value = (n + 1) * 2 + (Overflow ? 1 : 0)}; }; - template<size_t m> + template<std::size_t m> struct unpack { enum {value = (m / 2) - 1}; @@ -52,17 +52,17 @@ //////////////////////////////// - template<class V, size_t n, bool overflow = (n >= 0x3fffffff)> + template<class V, std::size_t n, bool overflow = (n >= 0x3fffffff)> struct encode_size_t : mpl::push_back< V, - boost::mpl::size_t<pack<n, false>::value> + boost::mpl::size_t< ::boost::type_of::pack<n, false>::value> > {}; - template<class V, size_t n> + template<class V, std::size_t n> struct encode_size_t<V, n, true> : mpl::push_back<typename mpl::push_back< V, - boost::mpl::size_t<pack<n % 0x3ffffffe, true>::value> >::type, + boost::mpl::size_t< ::boost::type_of::pack<n % 0x3ffffffe, true>::value> >::type, boost::mpl::size_t<n / 0x3ffffffe> > {}; @@ -73,17 +73,17 @@ /////////////////////////// - template<size_t n, class Iter, bool overflow> + template<std::size_t n, class Iter, bool overflow> struct decode_size_t; - template<size_t n, class Iter> + template<std::size_t n, class Iter> struct decode_size_t<n, Iter, false> { enum {value = n}; typedef Iter iter; }; - template<size_t n, class Iter> + template<std::size_t n, class Iter> struct decode_size_t<n, Iter, true> { enum {m = boost::mpl::deref<Iter>::type::value}; diff -ruN typeof/compliant/register_functions_iterate.hpp typeof_modified/compliant/register_functions_iterate.hpp --- typeof/compliant/register_functions_iterate.hpp Sun Mar 20 18:38:00 2005 +++ typeof_modified/compliant/register_functions_iterate.hpp Mon Apr 11 12:00:46 2005 @@ -28,8 +28,9 @@ // function references +#if !defined(__BORLANDC__) || __BORLANDC__ > 0x0645 template<class V, class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class P)> - struct encode_type_impl<V, R(&)(BOOST_PP_ENUM_PARAMS(n, P))> + struct encode_type_impl<V, R(&)(BOOST_PP_ENUM_PARAMS(n, P)) > { typedef R BOOST_PP_CAT(P, n); typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_REF_ID + n) type; @@ -79,6 +80,7 @@ #define BOOST_TYPEOF_qualifier volatile const #define BOOST_TYPEOF_id VOLATILE_CONST_MEM_FUN_ID #include <boost/typeof/compliant/register_mem_functions.hpp> +#endif } #undef n diff -ruN typeof/compliant/typeof_impl.hpp typeof_modified/compliant/typeof_impl.hpp --- typeof/compliant/typeof_impl.hpp Fri Mar 4 21:36:00 2005 +++ typeof_modified/compliant/typeof_impl.hpp Mon Apr 11 12:38:42 2005 @@ -24,15 +24,29 @@ namespace boost{namespace type_of{ + template<std::size_t N> + struct char_array + { + typedef char (&type)[ N ]; + }; + + template<typename T> + struct value_of + { + BOOST_STATIC_CONSTANT(std::size_t, value = T::value); + }; + template<int pos, class T> - char(&at(const T&))[ - mpl::at<typename encode_type<BOOST_TYPEOF_VECTOR(0)<>, T>::type, mpl::int_<pos> >::type::value - ]; + typename char_array< + ::boost::type_of::value_of< typename mpl::at<typename encode_type<BOOST_TYPEOF_VECTOR(0)<>, T>::type, mpl::int_<pos> >::type >::value + >::type + at(const T&); template<class T> - char(&size(const T&))[ - mpl::size<typename encode_type<BOOST_TYPEOF_VECTOR(0)<>, T>::type>::value - ]; + char_array< + ::boost::mpl::size<typename encode_type<BOOST_TYPEOF_VECTOR(0)<>, T>::type>::value + >::type + size(const T&); }} #define BOOST_TYPEOF_AT(n, expr) sizeof(boost::type_of::at<n>(expr)) diff -ruN typeof/compliant/vector.hpp typeof_modified/compliant/vector.hpp --- typeof/compliant/vector.hpp Sat Mar 19 15:18:00 2005 +++ typeof_modified/compliant/vector.hpp Mon Apr 11 11:40:09 2005 @@ -45,8 +45,9 @@ template<BOOST_PP_ENUM_PARAMS(n, class P) BOOST_PP_COMMA_IF(n) class T = void>\ struct vector ## n\ {\ + typedef vector ## n self;\ typedef v_tag tag;\ - typedef v_iter<vector ## n, boost::mpl::int_<0> > begin;\ + typedef v_iter<self , boost::mpl::int_<0> > begin;\ typedef mpl::int_<n> size;\ BOOST_PP_REPEAT(n, BOOST_TYPEOF_typedef_item, ~)\ };

Arkadiy Vertleyb wrote:
Hi everybody,
If anybody can try or has recently tried the proposed typeof library with any compilelr, other than GCC or MSVC, can you please let me know what
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote the
results are?
You can take the library at its usual place:
http://boost-sandbox.sourceforge.net/vault/, typeof.zip
Hi Arkadiy,
here are my results from testing with different versions of BCC.
Thanks, Tobias. Looks like we are not very close to having it ported to this compiler... Regards, Arkadiy

Arkadiy Vertleyb wrote:
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote
Arkadiy Vertleyb wrote:
Hi everybody,
If anybody can try or has recently tried the proposed typeof library
with
any compilelr, other than GCC or MSVC, can you please let me know what
the
results are?
You can take the library at its usual place:
http://boost-sandbox.sourceforge.net/vault/, typeof.zip
Hi Arkadiy,
here are my results from testing with different versions of BCC.
Thanks, Tobias. Looks like we are not very close to having it ported to this compiler...
I looked a little deeper into it (-; maybe your pessimism made me curious). The preprocessor bug isn't a typeof issue: BOOST_PP_UNARY isn't working correctly with the preprocessor of BCC and always expands to nothing. So I changed 1,2,3 to (class),(class)(class) and (class)(class)(class), respectively. Then there are a few problems parsing the registration code for integral template parameters because of this bug: template... struct foo { typedef ... type; // typedef ... type ... another_type; // won't work typedef foo self; typedef ... self::type ... another_type; // works }; When fixed the registration parses correctly. It still has problems to parse the actual typeof expression. Unfortunately it completely blows up the parser (probably an internal limit is exceeded) and doesn't leave me with much error reporting. Is there a configuration option to scale down the size of the MPL-vector used for the encoding ? Regards, Tobias

"Tobias Schwinger" <tschwinger@neoscientists.org> wrote
I looked a little deeper into it (-; maybe your pessimism made me curious).
The preprocessor bug isn't a typeof issue:
BOOST_PP_UNARY isn't working correctly with the preprocessor of BCC and always expands to nothing.
Yes, I remember Paul Mensonides warned me that I would have to make a workaround for Borland...
So I changed 1,2,3 to (class),(class)(class) and (class)(class)(class), respectively.
Then there are a few problems parsing the registration code for integral template parameters because of this bug:
template... struct foo { typedef ... type; // typedef ... type ... another_type; // won't work typedef foo self; typedef ... self::type ... another_type; // works };
When fixed the registration parses correctly. It still has problems to parse the actual typeof expression. Unfortunately it completely blows up the parser (probably an internal limit is exceeded) and doesn't leave me with much error reporting. Is there a configuration option to scale down the size of the MPL-vector used for the encoding ?
BOOST_TYPEOF_LIMIT_SIZE By default it's 50 -- try to set it to 15 -- should be enough to compile main.cpp (but not test_compliant.cpp). Regards, Arkadiy

"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
parse the actual typeof expression. Unfortunately it completely blows up the parser (probably an internal limit is exceeded) and doesn't leave me with much error reporting. Is there a configuration option to scale down the size of the MPL-vector used for the encoding ?
BOOST_TYPEOF_LIMIT_SIZE
By default it's 50 -- try to set it to 15 -- should be enough to compile main.cpp (but not test_compliant.cpp).
I don't understand all the issues, but I get the impression that BOOST_TYPEOF_LIMIT_SIZE isn't a good analogue for BOOST_MPL_LIMIT_XXX_SIZE because most of the time you're not supposed to change the latter. Should we be changing one of these names, or maybe do something to clearly advertise any differences? -- Dave Abrahams Boost Consulting www.boost-consulting.com

"David Abrahams" <dave@boost-consulting.com> wrote
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
parse the actual typeof expression. Unfortunately it completely blows up the parser (probably an internal limit is exceeded) and doesn't leave me with much error reporting. Is there a configuration option to scale down the size of the MPL-vector used for the encoding ?
BOOST_TYPEOF_LIMIT_SIZE
By default it's 50 -- try to set it to 15 -- should be enough to compile main.cpp (but not test_compliant.cpp).
I don't understand all the issues, but I get the impression that BOOST_TYPEOF_LIMIT_SIZE isn't a good analogue for BOOST_MPL_LIMIT_XXX_SIZE because most of the time you're not supposed to change the latter. Should we be changing one of these names, or maybe do something to clearly advertise any differences?
Well, it's not exactly an analogue. Typeof uses only numbered (or what is the correct name for it?) versions of the mpl::vector. Setting BOOST_TYPEOF_LIMIT_SIZE to, e.g., 15 means that vector15 is used to store the encoded type, and numbered versions up to vector15 are used to build it, regardless what the value of BOOST_MPL_LIMIT_VECTOR_SIZE is. If typeof limit happens to exceed the mpl limit, additional numbered MPL vector definitions are built with PP lib, as suggested by Aleksey some time ago. To add a little to the confusion, by default I don't use mpl::vector. Instead I use my own very simple MPL-compatible vector definition, which allows me to avoid the gcc-mpl::vector performance problem discussed some time ago. To really use MPL, BOOST_TYPEOF_USE_MPL_VECTOR has to be defined. This may be reconsidered after the MPL problem is fixed. Most of the time you wouldn't have to change BOOST_TYPEOF_LIMIT_SIZE either. I would use BOOST_MPL_LIMIT_VECTOR_SIZE as a convenient default, but I think it's currently 10 (?) and too low for typeof... Do you have a better name in mind or is it enough to just put the above description somewhere in the document? Regards, Arkadiy

"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
Typeof uses only numbered (or what is the correct name for it?) versions of the mpl::vector. Setting BOOST_TYPEOF_LIMIT_SIZE to, e.g., 15 means that vector15 is used to store the encoded type, and numbered versions up to vector15 are used to build it, regardless what the value of BOOST_MPL_LIMIT_VECTOR_SIZE is. If typeof limit happens to exceed the mpl limit, additional numbered MPL vector definitions are built with PP lib, as suggested by Aleksey some time ago.
Okay, as long as Aleksey is coordinating with you on this I feel fine about it.
To add a little to the confusion, by default I don't use mpl::vector. Instead I use my own very simple MPL-compatible vector definition, which allows me to avoid the gcc-mpl::vector performance problem discussed some time ago. To really use MPL, BOOST_TYPEOF_USE_MPL_VECTOR has to be defined. This may be reconsidered after the MPL problem is fixed.
It now is, IIUC.
Most of the time you wouldn't have to change BOOST_TYPEOF_LIMIT_SIZE either. I would use BOOST_MPL_LIMIT_VECTOR_SIZE as a convenient default, but I think it's currently 10 (?) and too low for typeof...
Do you have a better name in mind or is it enough to just put the above description somewhere in the document?
I don't have a better name in mind, and I'm not sure what belongs in the document. I just wanted not to inadvertently encourage people to encourage BOOST_MPL_LIMIT_VECTOR_SIZE. -- Dave Abrahams Boost Consulting www.boost-consulting.com

Arkadiy Vertleyb wrote:
If anybody can try or has recently tried the proposed typeof library with any compilelr, other than GCC or MSVC, can you please let me know what the results are?
Tried it on Tru64, CXX 6.5. Run script and results are attached. Especially interesting are the compile times I think. :-) HTH, Markus CXX="cxx -version V6.5-042 -ieee -model ansi -timplicit_local -noimplicit_include -D__USE_STD_IOSTREAM -nousing_std" time $CXX -O0 -I $HOME/net/src/boost/boost_1_32_0 -I ../../../.. test_compliant.cpp odr1.cpp odr2.cpp ../main.cpp time $CXX -O0 -I $HOME/net/src/boost/boost_1_32_0 -I ../../../.. test_compliant.cpp odr1.cpp odr2.cpp ../main.cpp -DBOOST_TYPEOF_COMPLIANT test_compliant.cpp: cxx: Error: test_compliant.cpp, line 26: no instance of function template "boost::type_of::at" matches the argument list argument types are: (const boost::lambda::lambda_functor<boost::lambda::lambda_funct or_base<boost::lambda::logical_action<boost::lambda::and_ action>, boost::tuples::tuple<boost::lambda::lambda_functor<boost: :lambda::lambda_functor_base<boost::lambda::relational_ac tion<boost::lambda::greater_action>, boost::tuples::tuple<boost::lambda::lambda_functor<boost: :lambda::placeholder<1>>, const int, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>>>, boost::lambda::lambda_functor<boost::lambda::lambda_funct or_base<boost::lambda::relational_action<boost::lambda::l ess_action>, boost::tuples::tuple<boost::lambda::lambda_functor<boost: :lambda::placeholder<2>>, const int, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>>>, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>>>) BOOST_AUTO(fun, _1 > 15 && _2 < 20); ----^ cxx: Info: Error limit reached. cxx: Info: 30 errors detected in the compilation of "test_compliant.cpp". cxx: Info: Compilation terminated. odr1.cpp: cxx: Error: odr.hpp, line 19: no instance of function template "boost::type_of::at" matches the argument list argument types are: (double) detected during instantiation of class "sum_t<T, U> [with T=double, U=char]" at line 17 of "odr1.cpp" typedef BOOST_TYPEOF_TPL(T() + U()) result_type; ------------^ cxx: Info: Error limit reached. cxx: Info: 30 errors detected in the compilation of "odr1.cpp". cxx: Info: Compilation terminated. odr2.cpp: cxx: Error: odr.hpp, line 19: no instance of function template "boost::type_of::at" matches the argument list argument types are: (double) detected during instantiation of class "sum_t<T, U> [with T=double, U=char]" at line 17 of "odr2.cpp" typedef BOOST_TYPEOF_TPL(T() + U()) result_type; ------------^ cxx: Info: Error limit reached. cxx: Info: 30 errors detected in the compilation of "odr2.cpp". cxx: Info: Compilation terminated. ../main.cpp: cxx: Error: ../main.cpp, line 55: no instance of function template "boost::type_of::at" matches the argument list argument types are: ( boost::mpl::vector1<template_template::tt_test<template_t emplate::C, 4>>) detected during instantiation of class "typeof_test<T> [with T=template_template::tt_test<template_template::C, 4>]" at line 89 BOOST_TYPEOF_TPL(typeof_test_helper(reinterpret_cast<mpl::vector1<T>*>(0))), --------^ cxx: Info: Error limit reached. cxx: Info: 30 errors detected in the compilation of "../main.cpp". cxx: Info: Compilation terminated. real 17108.3 user 8393.6 sys 13.5 test_compliant.cpp: cxx: Error: test_compliant.cpp, line 26: no instance of function template "boost::type_of::at" matches the argument list argument types are: (const boost::lambda::lambda_functor<boost::lambda::lambda_funct or_base<boost::lambda::logical_action<boost::lambda::and_ action>, boost::tuples::tuple<boost::lambda::lambda_functor<boost: :lambda::lambda_functor_base<boost::lambda::relational_ac tion<boost::lambda::greater_action>, boost::tuples::tuple<boost::lambda::lambda_functor<boost: :lambda::placeholder<1>>, const int, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>>>, boost::lambda::lambda_functor<boost::lambda::lambda_funct or_base<boost::lambda::relational_action<boost::lambda::l ess_action>, boost::tuples::tuple<boost::lambda::lambda_functor<boost: :lambda::placeholder<2>>, const int, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>>>, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>>>) BOOST_AUTO(fun, _1 > 15 && _2 < 20); ----^ cxx: Info: Error limit reached. cxx: Info: 30 errors detected in the compilation of "test_compliant.cpp". cxx: Info: Compilation terminated. odr1.cpp: cxx: Error: odr.hpp, line 19: no instance of function template "boost::type_of::at" matches the argument list argument types are: (double) detected during instantiation of class "sum_t<T, U> [with T=double, U=char]" at line 17 of "odr1.cpp" typedef BOOST_TYPEOF_TPL(T() + U()) result_type; ------------^ cxx: Info: Error limit reached. cxx: Info: 30 errors detected in the compilation of "odr1.cpp". cxx: Info: Compilation terminated. odr2.cpp: cxx: Error: odr.hpp, line 19: no instance of function template "boost::type_of::at" matches the argument list argument types are: (double) detected during instantiation of class "sum_t<T, U> [with T=double, U=char]" at line 17 of "odr2.cpp" typedef BOOST_TYPEOF_TPL(T() + U()) result_type; ------------^ cxx: Info: Error limit reached. cxx: Info: 30 errors detected in the compilation of "odr2.cpp". cxx: Info: Compilation terminated. ../main.cpp: cxx: Error: ../main.cpp, line 55: no instance of function template "boost::type_of::at" matches the argument list argument types are: ( boost::mpl::vector1<template_template::tt_test<template_t emplate::C, 4>>) detected during instantiation of class "typeof_test<T> [with T=template_template::tt_test<template_template::C, 4>]" at line 89 BOOST_TYPEOF_TPL(typeof_test_helper(reinterpret_cast<mpl::vector1<T>*>(0))), --------^ cxx: Info: Error limit reached. cxx: Info: 30 errors detected in the compilation of "../main.cpp". cxx: Info: Compilation terminated. real 17459.0 user 8559.1 sys 13.1
participants (6)
-
Alexander Nasonov
-
Arkadiy Vertleyb
-
David Abrahams
-
Markus Schöpflin
-
Rene Rivera
-
Tobias Schwinger