- Boost - lists.boost.org

[ANN] CLI 1.1.0 released
by Boris Kolpackov 21 Dec '09

21 Dec '09

Hi, Seeing that I've got a lot of useful feedback for the initial release, I am pleased to announce the availability of CLI 1.1.0. CLI is an open-source (MIT license), cross-platform command line interface compiler for C++. It allows you to specify the options that your program supports, their types, default values, and documentation. This specification can then be automatically translated to C++ classes that implement parsing of the command line arguments and provide a convenient and type-safe interface for accessing the extracted data. The automatic usage and documentation generation is by far the biggest new feature in this release. The usage information is formatted during compilation and the documentation can be generated in the HTML and man page formats. For an example of the HTML output, see the documentation for the CLI compiler itself (you may also want to check the cli.1 man page and the usage information printed by the compiler): http://www.codesynthesis.com/projects/cli/doc/cli.xhtml Other new features in this release: * Optional generation of modifiers in addition to accessors. * Support for erasing the parsed elements from the argv array. * Support for custom argument sources via an abstract scanner interface. * Support for reading command line arguments from the argv array as well as files specified with command line options. For a more detailed list of new features in this release see: http://www.codesynthesis.com/pipermail/cli-users/2009-December/000001.html More information, documentation, and source code distributions are available from the project's web page: http://www.codesynthesis.com/projects/cli/ Enjoy, Boris -- Boris Kolpackov, Code Synthesis http://codesynthesis.com/~boris/blog Open-source XML data binding for C++ http://codesynthesis.com/products/xsd XML data binding for embedded systems http://codesynthesis.com/products/xsde Command line interface to C++ compiler http://codesynthesis.com/projects/cli

5 7

[serialization] optional serialization and non-default-constructables
by Felipe Magno de Almeida 21 Dec '09

21 Dec '09

Hello, serialization for boost.optional calls load_construct_data but doesn't call save_construct_data. Which causes serialization for non-default-constructables to break. Regards, -- Felipe Magno de Almeida

1 1

Re: [boost] [msm] Review
by Christophe Henry 21 Dec '09

21 Dec '09

>> You brought 2 reasons for this impossibility: >> 1. Automatic entry/exit. You answer that "With separate FSMs you'd >> have to manage this yourself". >> 2. Automatic event dispatch. You answer that "Again, with separate >> FSMs you'd have to do that yourself (dispatch to first FSM and if that >> didn't consume the event, dispatch to second FSM and so on)." > > It appears that you should read the 2005 post a lot more carefully, > especially the quoted context. The remarks you quote above have *nothing* to > do with the impossibility I claimed. No, I won't spend "a lot more" time trying to decipher the supposedly hidden meaning of your post and invest the time more wisely by making MSM more useful. The link I added seems quite clear to me and anyone interested can make himself his own opinion by opening it. You did not bother bringing an argumentation disproving my claim, so I will simply keep it. As you also didn't address the more important technical part (multiple TU) of my answer, I will consider it accepted.

3 2

What about "Maybe" ?
by Arnaud Masserann 21 Dec '09

21 Dec '09

Hi, Is there any interest for a "Maybe" utility class, like the one in Haskell ? For those who don't know about Maybe, here is the Haskell ref : http://www.haskell.org/ghc/docs/6.10.4/html/libraries/base/Prelude.html#t%3… And a code snippet showing its use : http://pastebin.com/m3a590d6e Arnaud

5 7

How to detect if f() returns void or not?
by Frédéric Bron 21 Dec '09

21 Dec '09

I would like to detect if the return type of a function is void or not within C++03 standard? I need that to implement new type traits to detect if types can be compared and to detect for example operator< returning void. The following code compiles only with c++0x standard and keyword decltype but not with c++03 standard and BOOST_TYPEOF. Frédéric #include <iostream> #include <boost/type_traits/is_void.hpp> #include <boost/typeof/typeof.hpp> void returns_void(); int returns_int(); int main() { std::cout<<std::boolalpha; // std::cout<<boost::is_void< BOOST_TYPEOF(returns_void()) >::value<<'\n'; // std::cout<<boost::is_void< BOOST_TYPEOF(returns_int()) >::value<<'\n'; std::cout<<boost::is_void< decltype(returns_void()) >::value<<'\n'; std::cout<<boost::is_void< decltype(returns_int()) >::value<<'\n'; return 0; }

17 36

[bind] Function call operator is a template?!
by Andy Venikov 20 Dec '09

20 Dec '09

All this time I've been using bind quite happily without really going into the details of its implementation. Recently, however, I had to discover the hard way that the function call operator that is produced as part of the bind() return is a template! I guess most of the time one would not care if it's a template or not as long as you can call the resulting functor with the right signature. It does, however, make a difference. The difference can be seen when calling the resulting functor with wrong arguments. The error detection happens earlier in the case when functor's operator() is a concrete function as opposed to a template. And that plays bad tricks with SFINAE. You see, recently I was faced with a challenge where I had to check at compile time whether calling a template argument with a specific signature is a well-formed expression. Something similar to Eric Niebler's "can_be_called<>": http://www.boost.org/doc/libs/1_41_0/doc/html/proto/appendices.html#boost_p… Well, this technique won't work with bind(), because the template member operator() will happily accept ANY argument during SFINAE and the error detection will happen much later, when you actually try to call the functor. I'm not going to debate whether it's right or wrong, but I'm still curious - why did it have to be a template? When bind() is called it already has all the information about the function's signature so it could construct a concrete member operator() without resorting to templates. For example bind(main) could easily determine that the signature is <int (int, char * [])> and could create a functor with a single "int operator()(int, char *[])", instead of a template. It's not like it's lambdas, where when you say _1 + _2 you literally mean parameters of any type. Thanks, Andy.

4 5

getting errors whti boost.
by ch.asad＠gmail.com 19 Dec '09

19 Dec '09

Hi I am getting errors when i ininclude boost header file in my project. my progrm is running fine. I want ot use boost asio in my program. But when just write "include<boost/asio>" or any other header fie of boost in my program i am getting below errors. It just started all of a suddden before that it was working fine. I am tring it with Eclpse and MinGW.Please also guide me how t setup boost for Visual C++.net 9.0. I have tried boost_1_38_0 and boost_1_41_0 but same problem. i am getting the following errors on eclipse. Thanks in advance, -Asad Description Resource Path Location Type (Errors 5) D:/boost/boost_1_38_0/boost/system/error_code.hpp undefined reference to `boost::system::get_generic_category()' test project 206 C/C++ Problem D:/boost/boost_1_38_0/boost/system/error_code.hpp undefined reference to `boost::system::get_generic_category()' test project 211 C/C++ Problem D:/boost/boost_1_38_0/boost/system/error_code.hpp undefined reference to `boost::system::get_generic_category()' test project 212 C/C++ Problem D:/boost/boost_1_38_0/boost/system/error_code.hpp undefined reference to `boost::system::get_system_category()' test project 205 C/C++ Problem D:/boost/boost_1_38_0/boost/system/error_code.hpp undefined reference to `boost::system::get_system_category()' test project 213 C/C++ Problem (Warnings 9) Description Resource Path Location Type D:/boost/boost_1_38_0/boost/asio/detail/socket_types.hpp #warning Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target). test project 39 C/C++ Problem D:/boost/boost_1_38_0/boost/asio/detail/socket_types.hpp #warning For example, add -D_WIN32_WINNT=0x0501 to the compiler command line. test project 38 C/C++ Problem D:/boost/boost_1_38_0/boost/asio/detail/socket_types.hpp #warning Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. test project 37 C/C++ Problem D:/boost/boost_1_38_0/boost/date_time/filetime_functions.hpp left shift count >= width of type test project 101 C/C++ Problem Invalid project path: Include path not found (C:\MinGW\include\c++\4.3.2-dw2). test project pathentry Path Entry Problem Invalid project path: Include path not found (C:\MinGW\include\c++\4.3.2-dw2\backward). test project pathentry Path Entry Problem Invalid project path: Include path not found (C:\MinGW\include\c++\4.3.2-dw2\i686-pc-mingw32). test project pathentry Path Entry Problem Invalid project path: Include path not found (C:\MinGW\lib\gcc\i686-pc-mingw32\4.3.2-dw2\include-fixed). test project pathentry Path Entry Problem Invalid project path: Include path not found (C:\MinGW\lib\gcc\i686-pc-mingw32\4.3.2-dw2\include). test project pathentry Path Entry Problem And on the console it shows like : **** Internal Builder is used for build **** g++ -ID:\boost\boost_1_38_0 -O0 -g3 -Wall -c -fmessage-length=0 -osrc\test project.o ..\src\test project.cpp In file included from D:/boost/boost_1_38_0/boost/asio/detail/win_iocp_io_service_fwd.hpp:24, from D:/boost/boost_1_38_0/boost/asio/io_service.hpp:37, from D:/boost/boost_1_38_0/boost/asio/basic_io_object.hpp:20, from D:/boost/boost_1_38_0/boost/asio/basic_socket.hpp:24, from D:/boost/boost_1_38_0/boost/asio/basic_datagram_socket.hpp:25, from D:/boost/boost_1_38_0/boost/asio.hpp:20, from ..\src\test project.cpp:12: D:/boost/boost_1_38_0/boost/asio/detail/socket_types.hpp:37:5: warning: #warning Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. D:/boost/boost_1_38_0/boost/asio/detail/socket_types.hpp:38:5: warning: #warning For example, add -D_WIN32_WINNT=0x0501 to the compiler command line. D:/boost/boost_1_38_0/boost/asio/detail/socket_types.hpp:39:5: warning: #warning Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target). In file included from D:/boost/boost_1_38_0/boost/date_time/microsec_time_clock.hpp:23, from D:/boost/boost_1_38_0/boost/date_time/posix_time/posix_time_types.hpp:11, from D:/boost/boost_1_38_0/boost/asio/detail/select_reactor.hpp:25, from D:/boost/boost_1_38_0/boost/asio/impl/io_service.ipp:27, from D:/boost/boost_1_38_0/boost/asio/io_service.hpp:550, from D:/boost/boost_1_38_0/boost/asio/basic_io_object.hpp:20, from D:/boost/boost_1_38_0/boost/asio/basic_socket.hpp:24, from D:/boost/boost_1_38_0/boost/asio/basic_datagram_socket.hpp:25, from D:/boost/boost_1_38_0/boost/asio.hpp:20, from ..\src\test project.cpp:12: D:/boost/boost_1_38_0/boost/date_time/filetime_functions.hpp: In function `uint64_t boost::date_time::winapi::file_time_to_microseconds(const FileTimeT&)': D:/boost/boost_1_38_0/boost/date_time/filetime_functions.hpp:101: warning: left shift count >= width of type g++ -LC:\boost_1_38_0\libs -LC:\STLport-5.2.0\build\lib -otestproject.exe src\test project.o src\test project.o: In function `Z41__static_initialization_and_destruction_0ii': D:/boost/boost_1_38_0/boost/system/error_code.hpp:205: undefined reference to `boost::system::get_system_category()' D:/boost/boost_1_38_0/boost/system/error_code.hpp:206: undefined reference to `boost::system::get_generic_category()' D:/boost/boost_1_38_0/boost/system/error_code.hpp:211: undefined reference to `boost::system::get_generic_category()' D:/boost/boost_1_38_0/boost/system/error_code.hpp:212: undefined reference to `boost::system::get_generic_category()' D:/boost/boost_1_38_0/boost/system/error_code.hpp:213: undefined reference to `boost::system::get_system_category()' src\test project.o: In function `ZN5boost6detail17sp_counted_impl_pINS_4asio6detail12winsock_initILi2ELi0EE7do_initEE11get_deleterERKSt9type_info': D:/boost/boost_1_38_0/boost/detail/sp_counted_impl.hpp:(.text$_ZN5boost4asio6detail12winsock_initILi2ELi0EE7do_initD1Ev[boost::asio::detail::winsock_init<2, 0>::do_init::~do_init()]+0x7): undefined reference to `WSACleanup@0' D:/boost/boost_1_38_0/boost/detail/sp_counted_impl.hpp:(.text$_ZN5boost4asio6detail12winsock_initILi2ELi0EE7do_initC1Ev[boost::asio::detail::winsock_init<2, 0>::do_init::do_init()]+0x1f): undefined reference to `WSAStartup@8' D:/boost/boost_1_38_0/boost/detail/sp_counted_impl.hpp:(.text$_ZN5boost4asio5error19get_system_categoryEv[boost::asio::error::get_system_category()]+0x7): undefined reference to `boost::system::get_system_category()' collect2: ld returned 1 exit status Build error occurred, build is stopped Time consumed: 4886 ms. -- View this message in context: http://old.nabble.com/getting-errors-whti-boost.-tp26856283p26856283.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

Re: [boost] [msm] Review
by Christophe Henry 18 Dec '09

18 Dec '09

>> Now it's proven that the concepts of the MPL book were right, that it >> was indeed possible to implement at least as much as statechart with >> metaprogramming techniques. >> That this wasn't evident, as shown here >> (http://lists.boost.org/Archives/boost/2005/03/81853.php) > >For the record, back in 2005 I only expressed the opinion that it's not >possible to implement a purely meta-programming-based FSM framework that >supports both multi-TU machines and orthogonal regions. This should be >obvious from the context quoted in the linked message. I'm happy that you offer to clarify your thoughts because I'm afraid it isn't that obvious to me. You brought 2 reasons for this impossibility: 1. Automatic entry/exit. You answer that "With separate FSMs you'd have to manage this yourself". 2. Automatic event dispatch. You answer that "Again, with separate FSMs you'd have to do that yourself (dispatch to first FSM and if that didn't consume the event, dispatch to second FSM and so on)." Your point was that these 2 cases would have to be managed manually by the user and I fail to see what this has to do with multiple-TUs. Could you please explain this as it still seems unclear to me? Your answer was not about compile-time or recompiling if the structure of a region or separate FSM was changed, which would have been another issue and I would perfectly understand and accept this argument. What I understood from your post is that a full-metaprogramming fsm would not manage these 2 points because of some statechart-specific multiple-TU considerations, and I'd be grateful if you could explain them to me. >IIUC then MSM does not support multi-TU FSMs and you have so far not >expressed any plans to support them, right? I fail to see the difference with Statechart except on the amount of metaprogramming done. Please help me on that one, if I changed in Statechart the reactions typedef in the submachine and thus the submachine header, it would be, from a recompiling perspective, the same result as a full-metaprogramming fsm, right? If this really only is a difference in compile-time, I think this has already been discussed. To multiple TUs with MSM: An application is made of a fsm structure and lots more of user code. This user code can well be in another TU. The metaprogramming in the top-level fsm needs the header of a sub-fsm in order to let the compiler do its job, which is probably also what Statechart does or am I missing something? Reading again the explanation in Statechart's doc (http://www.boost.org/doc/libs/1_40_0/libs/statechart/doc/tutorial.html#Spre…) I found in Camera.cpp: #include "Shooting.hpp" Which increases my confusion. It seems that Statechart's top-level fsm also needs the submachine header, which seems to make the multiple-TU point moot. Recompiling is another issue, which you didn't mention at that time (though it would have been a valid one), so please allow me to discuss it already now as it's likely that you'll bring this one next. By moving your submachines' application code into different TUs, you'll gain some compile-time if the submachine actions or application code also would cause long compile-times. You'll also gain that a change in a sub-fsm will not cause all to recompile but only the TUs of this fsm and the top-level one. The fact that I put all my submachines into one header doesn't force you to do the same. So yes, you probably can't spread the library metaprogramming work around different TUs, but you can full well spread the application work. Depending of how much this is, it can reduce your compile-time or be not visible. Again, what is concretely the difference with Statechart? Christophe

2 1

boost_1_40_0/boost/lambda/if.hpp && merging different return types
by Peter Foelsche 18 Dec '09

18 Dec '09

Am I doing something wrong, or is this patch really necessary? I'm using if_then_else_return() and the return types are different. I'm overloading return_type_2<other_action<ifthenelsereturn_action>, A, B> to let the compiler deduce the correct return type. Peter diff -w -c ./if.hpp /users/pfoelsch/boost_1_40_0/boost/lambda/if.hpp *** ./if.hpp Sat Jun 28 06:57:20 2008 --- /users/pfoelsch/boost_1_40_0/boost/lambda/if.hpp Tue Dec 15 15:19:50 2009 *************** *** 310,318 **** template<class RET, CALL_TEMPLATE_ARGS> RET call(CALL_FORMAL_ARGS) const { return (detail::select(boost::tuples::get<0>(args), CALL_ACTUAL_ARGS)) ? ! detail::select(boost::tuples::get<1>(args), CALL_ACTUAL_ARGS) : ! detail::select(boost::tuples::get<2>(args), CALL_ACTUAL_ARGS); } }; --- 310,318 ---- template<class RET, CALL_TEMPLATE_ARGS> RET call(CALL_FORMAL_ARGS) const { return (detail::select(boost::tuples::get<0>(args), CALL_ACTUAL_ARGS)) ? ! RET(detail::select(boost::tuples::get<1>(args), CALL_ACTUAL_ARGS)) : ! RET(detail::select(boost::tuples::get<2>(args), CALL_ACTUAL_ARGS)); } };

1 1

[fiber] version 03.1 docu update (incl. html)
by Oliver Kowalke 18 Dec '09

18 Dec '09

version 0.3.1 has an updated documentation - html pages are added to the archive regards, Oliver

1 0