October 2007 - Boost - lists.preview.boost.org

[fusion] compiler complaining about incomplete type
by Michael Marcin 17 Oct '07

17 Oct '07

RVCT 2.2 is complaining about "return vector<>();" on like 41 of as_vector.hpp (svn trunk) because vector is an incomplete type. This is almost certainly a compiler bug related to it checking the member template before it is instantiated. The simplest workaround is to move "#include <boost/fusion/sequence/conversion/detail/as_vector.hpp>" from the top of <boost/fusion/sequence/container/vector/vector.hpp> to the bottom of the file. It's the same problem I reported here: http://lists.boost.org/Archives/boost/2007/07/124309.php Thanks, Michael Marcin

4 3

[fusion] Can you store noncopyable items in a fusion map?
by Michael Marcin 17 Oct '07

17 Oct '07

Can you store non-copyable items in a fusion map? I'm just using it to map types to ptr_containers and I don't want to copy it ever. Windows works just fine but another compiler complains about not being able to create the implicit copy constructor for fusion::map. The documentation implies that a fusion::pair must be assignable and copyable in its expression semantics but I think this may be overly restrictive. Looking at the code it seems that I may need to make a noncopyable_map and noncopyable_pair to achieve this goal. Is this the easiest way? Thanks, Michael Marcin

1 0

[iterator][msvc-8.0][trunk] iterator_adaptor with incomplete Value
by "JOAQUIN LOPEZ MU?Z" 17 Oct '07

17 Oct '07

Seems like in MSVC++ 8.0 boost::iterator_adaptor doesn't work when the associated Value type is incomplete. For instance, the following program: #include <boost/iterator/iterator_adaptor.hpp> template<typename T> struct my_iterator: boost::iterator_adaptor<my_iterator<T>,T*> { }; struct foo { my_iterator<foo> it; }; int main(){} results in: ...\boost\type_traits\is_pod.hpp(34) : error C2139: 'foo' : an undefined class is not allowed as an argument to compiler intrinsic type trait '__is_pod' ...\sandbox.cpp(10) : see declaration of 'foo' ...\type_traits\is_pod.hpp(128) : see reference to class template instantiation 'boost::detail::is_pod_impl<T>' being compiled [...] ...\boost\iterator\iterator_facade.hpp(652) : see reference to class templateinstantiation 'boost::detail::operator_brackets_result<Iterator,Value,Reference >' being compiled with [ Iterator=my_iterator<foo>, Value=foo, Reference=foo & ] [...] while the following variation using a custom "adaptor" works just fine: template<typename Derived,typename Base> struct my_iterator_adaptor { Base b; }; template<typename T> struct my_iterator: my_iterator_adaptor<my_iterator<T>,T*> { }; struct foo { my_iterator<foo> it; }; int main(){} IMHO, boost::iterator_adaptor should be compilable with incomplete Value just as the canonical Value* does. Any possibility that this can be addressed in MSVC++ 8.0? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

A *smaller* release concept
by Michael Caisse 17 Oct '07

17 Oct '07

Was there any consideration of doing a release that consisted of 1.34.1 and new libraries that have been accepted recently. No other changes. Stable and working libraries such as Boost.Test and Boost.Thread would just be the same as in the 1.34.1 release; however, the package would also contain libraries such as asio that have been waiting on the side lines. -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

9 11

[program_options] Feature request: settable argument names
by Joe Gottman 17 Oct '07

17 Oct '07

I recently used the program_options library for the first time and found it very useful. However, there's one easily implemented feature that's missing: the ability to set the name of a parameter that's associated with a particular option. In the first example in the tutorial we have the code po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("compression", po::value<int>(), "set compression level") ; When desc is then sent to cout, the output then looks like Allowed options: --help : produce help message --compression arg : set compression level But suppose we wanted the name of the parameter associated with the --compression option to be something other than arg. As program_options is now written there's no way to do this. This is unfortunate, because replacing arg with a more relevant argument name could make it clearer to the user what type of values should be passed in. I suggest adding the following member to the typed_value template class: typed_value *argument_name(const std::string &); This function would change the name of the arguement associated with the option from "arg" to whatever string was passed in. If it isn't called then the argument name can remain as "arg". If this function were included, then the code above could be rewritten as po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("compression", po::value<int>()->argument_name("level-number"), "set compression level") ; and then the output would be Allowed options: --help : produce help message --compression level-number : set compression level Joe Gottman

2 1

Re: [boost] [test] REVERTED
by Eric Niebler 17 Oct '07

17 Oct '07

Gennadiy Rozental wrote: > "Eric Niebler" <eric(a)boost-consulting.com> wrote in message > news:47150CB0.8060302@boost-consulting.com... >> Beman Dawes wrote: >>> Eric Niebler wrote: >>>> We seem to be having a lot of problems >>>> with Boost.Test lately. This is really bad. Should we revert Boost.Test >>>> to something that works? >>> Yes. This is a disaster. >>> >>> Can you do the revert? I'm tied up. It looks like a series of changes >>> where make on revisions 40065-40078, and then 40090. >> >> I've reverted all the Boost.Test changes since r40064. > > You reverted to wrong version. 40064 includes the issue with infinite > recursion. OK, but you didn't say which revision I should revert to, so I just reverted all the way back to r40013, which is just before a huge number of Boost.Test changes. Beman, others, please give this a shot. -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

[intrusive] Expected failure markup.
by Markus Schöpflin 17 Oct '07

17 Oct '07

Hello, I would like to ask if the expected failure markup for intrusive could be removed for Tru64/CXX. There are still many failures left, but as this platform has lost it's 'officially supported' boost status the expected failure markup isn't relevant anyway. It would help me a lot in fixing the remaining issues, as it gives a nice overview of what already works and what doesn't. Regards, Markus

3 3

[fusion] missing map_tie documentation from spirit website
by Michael Marcin 17 Oct '07

17 Oct '07

The map_tie documentation link on http://tinyurl.com/yw5le8 is broken. Thanks, Michael Marcin

1 0

[test] broken on gcc 3.4?
by Eric Niebler 17 Oct '07

17 Oct '07

This is gcc-3.4 (cygwin). In file included from C:\cygwin\home\ericne\boost\org\trunk\libs\test\src\execution_monitor.cpp:16: ../../boost/test/impl/execution_monitor.ipp: In function `void boost::detail::execution_monitor_jumping_signal_handler(int, siginfo_t*, void*)': ../../boost/test/impl/execution_monitor.ipp:635: error: expected id-expression before "__extension__" ../../boost/test/impl/execution_monitor.ipp:635: error: expected `;' before "__extension__" ../../boost/test/impl/execution_monitor.ipp:635: error: expected primary-expression before ')' token ../../boost/test/impl/execution_monitor.ipp:635: error: expected `;' before ')' token I'm fully sync'ed up to svn head. We seem to be having a lot of problems with Boost.Test lately. This is really bad. Should we revert Boost.Test to something that works? -- Eric Niebler Boost Consulting www.boost-consulting.com

4 4

[parameter] Macro for CodeGear SFINAE problems (answering Dave's comment)
by Nicola Musatti 17 Oct '07

17 Oct '07

Dave wrote in a Ticket comment: > OK, then if you can find the time, I would prefer then to have another > configuration macro (parameter-library-specific if no other libs need it) > for this purpose. Code repetition is evil, even PP code. [I'm moving this discussion: http://svn.boost.org/trac/boost/ticket/1305 to the mailing list, as it seems more appropriate.] Where you thinking of something like BOOST_CODEGEAR_SFINAE_BUG? If so, I'll look into it. Cheers, Nicola Musatti

2 1