December 2009 - Boost - lists.preview.boost.org

Interprocess message queue implementation
by Alex Miller 22 Dec '09

22 Dec '09

Hello, I have been looking over the implementation of Boost.Interprocess's message queues, and have become slightly confused as to the reasoning for how it was designed. Assuming my understanding is correct, it allocates a piece of shared memory, and then constructs a message queue within that piece of memory. Is there a reason that this was done in favor over implementing it by using SystemV's message queues ( the one located in <sys/msg.h> )? Thanks, Alex Miller

1 0

Re: [boost] [date_time] quarters as new durations?
by pete＠pcbartlett.com 22 Dec '09

22 Dec '09

On Tue 22/12/09 13:27 , "Stewart, Robert" <Robert.Stewart(a)sig.com> wrote: > Jeff Garland wrote: > > Stewart, Robert wrote: > > > Thomas Lemm wrote: > > >> I am happily using the boost date_time library and I plan to > > >> extend it towards including quarters as new (gregorian) date > > >> durations, just the way months are included already > > >> (excluding parsing of quarters) > > > > > > Why excluding parsing? That would imply only partial > > > support relative to other durations, right? > > > > > Well, so quarters turns out to be like months as far as > > durations go -- that is, it's mathematical like days and > > weeks. So the big drawback you face is dealing with the > > associated "fuzzy math". For example, what's the result > > of > > > > date("2008-Feb-28") + quarters(1) = ? > > date("2008-Feb-27") + quarters(1) = ? > > > > Month durations play some games to handle this problem (see > > docs for details) which quarters could adopt. But if you > > adopt the month rules then I don't thing you buy much more > > than simply writing > > > > const months quarters = months(3); > That's an excellent point. I don't think the fuzzy math approach is > appropriate for quarters because they have a precise definition: 1/4 > of a year. Months are less precise, though 365 / 4 is not a whole > number, of course. Possibly opening a can of worms here, but a quarter in my line of work is invariably three months. If your mileage varies, then there could be a problem in providing a fully meaningful quarter duration type if people think it means different things. > There is probably still a need to use some fuzzy math in order to > determine the calendar date for quarter boundaries. Quarters are > usually associated with a fiscal year and there are different > definitions of those, so you probably need to add fiscal year support > and make quarters a derived concept. > > There's also an argument against adding quarters as a > > duration. I have an app somewhere in which I have quarter > > defined as a date_period so I could write: > > > > date_period q = quarter(2009, 1); > > > > To me at least this seems like the more likely application. > I agree. I didn't consider the ramifications of duration versus > period. The issue routinely occurs with months already though. Month durations and date_periods spanning a specific month already have to work closely with each other: date_period month_containing(date d) { return date_period(date(d.year(),d.month(),1) , months(1) ); } so it may not be a big issue.

2 1

[date_time] quarters as new durations?
by Thomas Lemm 22 Dec '09

22 Dec '09

Hi, I am happily using the boost date_time library and I plan to extend it towards including quarters as new (gregorian) date durations, just the way months are included already (excluding parsing of quarters) Now my question: What are the chances that his change might make it into the boost date_time library? Is there some interest in this feature, if so I would provide a patch to update source and documentation to include the quarters as a new duration. Please let me know, Kind regards Thomas Lemm

3 3

[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

iPhone mangled symbol size explosion in release
by Michael Marcin 18 Dec '09

18 Dec '09

We're currently working to ship an iPhone application that makes heavy use of Boost. The compiled executable is absurdly large, partly to third party libraries, partly to our own insufficent coding practices, but strikingly it seems that (from looking at the executable in a hex editor) around 4MB of the 9.5MB app size is mangled boost function names. We are statically linking against the libraries in Boost we are using. Here are some examples: __ZN5boost13serialization9singletonIN S_7archive6detail11oserializerINS2_12 xml_oarchiveEN6newton18Vector3InitializerEEEE12get_instanceEv __ZNK5boost6spirit8sequenceINS1_INS1_ INS0_6strlitIPKwEENS0_4ruleINS0_7scan nerIN9__gnu_cxx17__normal_iteratorIPc SsEENS0_16scanner_policiesINS0_16iter ation_policyENS0_12match_policyENS0_1 3action_policyEEEEENS0_5nil_tESI_EEEE NS0_5chlitIwEEEENS0_6actionISJ_NS_7ar chive3xml11assign_implISsEEEEE5parseI SH_EENS0_13parser_resultISU_T_E4typeERKSX_ AFAIK All application functions should have been hard-linked since we're statically linking and thus not require any type of named reference. Am I perhaps missing or misusing a Boost configuration setting or compiler flag? Thanks, Michael Marcin

2 2

Failed to upgrade to Boost 1.39.0 (from 1.34.0)
by gaofg 17 Dec '09

17 Dec '09

Hi, In past years, we have been used boost 1.34.0 in our projects, and it works fine. Now days, we want to update the boost to 1.39.0, but when we change the include directories and lib path to use boost 1.39.0, the following compile error occured: 1>d:\reference\boost\v1_39_0\boost\type_traits\type_with_alignment.hpp(138) : error C2061: syntax error : identifier 'BOOST_PP_LIST_FOLD_RIGHT_BOOST_PP_IIF_BOOST_PP_BITAND_1BOOST_PP_LIST_FOLD_LEFT_CHECK_BOOST_PP_IIF_BOOST_PP_CHECK' 1> d:\reference\boost\v1_39_0\boost\type_traits\type_with_alignment.hpp(143) : see reference to class template instantiation 'boost::detail::lower_alignment<target>' being compiled 1>d:\reference\boost\v1_39_0\boost\type_traits\type_with_alignment.hpp(138) : error C2059: syntax error : ')' 1>d:\reference\boost\v1_39_0\boost\type_traits\type_with_alignment.hpp(138) : error C2143: syntax error : missing ')' before '(' 1>d:\reference\boost\v1_39_0\boost\type_traits\type_with_alignment.hpp(138) : error C2061: syntax error : identifier 'BOOST_PP_LIST_FOR_EACH_I_M' ... I have tried several ways to resovlve it, but all failed. Does anyone know how to fix this issue or any advice? I really appreciate your help. Best Regards, wind.

2 1

[TypeTraits] is it possible to add something to boost.type_traits?
by frederic.bron＠alcan.com 17 Dec '09

17 Dec '09

Dear boost implementers, TypeTraits is very useful, thanks you. However, recently, I needed something to know if a type is comparable (with operator<) and that was not in the library. Fortunately, somebody forwarded me an earlier post on the users list where I could find what I wanted. The implementation was inspired from boost/detail/is_incrementable.hpp I have written is_less_comparable, is_less_equal_comparable, is_greater_comparable... inspired from the same source and I wonder if it could be possible to add it to the library as I think it could be helpful for others. I give the source code below (if it is useful) but I am not able to make it fully general as it is in boost/type_traits. In particular, I do not understand all the macros that are used. Regards, F. Bron (See attached file: is_comparable.hpp) Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

11 23

[property] interest in C# like properties for C++?
by Peder Holt 17 Dec '09

17 Dec '09

I have implemented a prototype support for properties in C++. It has no space overhead as it manages to deduce the this pointer of the class owning it. Code sample: #include <boost/static_assert.hpp> #include <boost/property.hpp> #include <iostream> class class_with_property { public: //Implement property template template<typename Base> class property_with_a_sensible_name : public Base { public: void set(const double& a) { //Implement setting of the variable here. m_var=a; //You can access the owner of the property's this value by calling self(), e.g. self()->refresh(); } const double& get() const { return m_var; } private: double m_var; }; void refresh() { std::cout << "Refreshed"; } //Instantiate property template. These can be reused. BOOST_PROPERTY(class_with_property,property_with_a_sensible_name,property_name); }; //And usage: void test() { class_with_property cls; cls.property_name=54.3; BOOST_STATIC_ASSERT(sizeof(class_with_property)==sizeof(double)); } The trick used is the following: class my_class { public: class property_x { public: my_class* self() { //Find offset of member relative to my_class size_t offset=size_t(&((my_class*)0)->x); //Use this to deduce the address of my_class return reinterpret_cast<my_class*>(size_t(this)-offset); } }; property_x x; }; It currently support: Read/Write properties Read properties Write properties Not supported yet: indexed properties operator overloads for properties, e.g. my_class.property*my_class.property will currently fail. Regards Peder

17 64

[ptr_container] ptr_map insert with non-const vs. const reference
by Martin B. 17 Dec '09

17 Dec '09

Hi there, After thinking a while about the issue with the two insert functions of ptr_map and why the one with the raw pointer takes a non-const reference ... See: http://www.boost.org/doc/libs/1_41_0/libs/ptr_container/doc/faq.html#why-do… or http://lists.boost.org/boost-users/2007/09/31014.php I would like to add the following thoughts: ptr_map provides two functions (a) std::pair<iterator,bool> insert( key_type& k, value_type x ); (b) template< class U > std::pair<iterator,bool> insert( const key_type& k, std::auto_ptr<U> x ); Now, I understand the rationale behind having (a) take a non-const reference since this means less potential ctor calls means less potential for a leak. I think the rationale makes sense but it's still easily possible for users to shoot themselves in the foot. Maybe the documentation of these two functions should be expanded upon as I've just spent about 1 1/2 hours to make sense of it all :-) Consider these examples: using namespace std; using namespace typedef boost::ptr_map<string, Foo> foomap_t; foomap_t the_foo_map; // 1 (a) - correct usage string key("key-string"); // need key object to take reference Foo* p = new Foo(); the_foo_map.insert(key, p); // compiles OK // 2 (a) - incorrect usage Foo* p = new Foo(); string key("key-string"); // need key object to take reference - leaks p if throws the_foo_map.insert(key, p); // compiles OK // 3 (b) - correct usage std::auto_ptr<Foo> p(new Foo()); the_foo_map.insert("key-string", p); // 4 (b) - incorrect usage Foo* p = new Foo(); the_foo_map.insert("key-string", std::auto_ptr<Foo>(p)); // compiles OK, but may leak if the implicit Key constructor throws (which only happens for string for bad_alloc, but this is just an example) So my point is, that the non-const reference insert() fails to protect the user from shooting himself in the foot, but it succeeds at highlighting the problem, so the problem should be expanded upon in the docs, shouldn't it? If we have a raw-pointer then no matter of fiddling on ptr_maps part can make it completely exception safe, the user code has to provide that. The raw pointer should already be wrapped in a smart-pointer. So (a) is unsuited for the case where the raw-pointer exists prior to the key object. There is only one case where having the (a) version around makes sense and that is when we have another smart-ptr type: // 5 (a) correct usage string key("key-string"); the_foo_map.insert(key, p.Detach()); // makes a lot more sense than std::auto_ptr<Foo> ap(p.Detach()); the_foo_map.insert("key-string", ap); cheers, Martin

2 1

Any interest in static plugins?
by Dave van Soest 16 Dec '09

16 Dec '09

Hi all, I created a template-based header-only library for creating static plugin systems. I'm wondering whether there would be any interest to include such a library in Boost. About static plugins: Static plugins are not as common as dynamic plugins, but they have some useful applications. Static plugins are a way to extend the functionality of a program or library without having to change the existing source files, just by adding a source file or object file, which is then linked statically against the already existing object files. Some reasons you might be doing this: - You don't have permission to change the existing source files. - You don't have the source files, only the object and header files. - You don't want to have to change existing sources every time you extend functionality. - Simply including or excluding the object file from the linking process adds or removes functionality from the program or library, leaving no traces inside. - Different configurations can be build easily this way. - Testing only the required functionality without having to build the full application. - And some other advantages it shares with dynamic plugins. If there appears to be any interest I will post more information and some code and code examples. Best regards, Dave van Soest

9 30

[endian] ARM support
by Phil Endecott 16 Dec '09

16 Dec '09

Dear All, Can ARM support be added to detail/endian.hpp ? It's complicated by the fact that ARM systems may have either endianness. I believe that the symbols __ARMEL__ and __ARMEB__ are defined by gcc for the little- and big-endian cases respectively. However, it also seems that gcc defines __LITTLE_ENDIAN__; can we just test for that? There is possibly some confusion with __LITTLE_ENDIAN and __BIG_ENDIAN (no trailing __s) which I believe glibc defines both of as 4321 and 1234, but it should be OK to write: #elif defined(__LITTLE_ENDIAN__) && !defined(__BIG_ENDIAN__) ... I suspect someone has looked at this before. It can't do any harm to add all of the potential tests, can it? Thanks, Phil.

1 0

Re: [boost] [explore] Extending namespace std
by Jeffrey Faust 16 Dec '09

16 Dec '09

Hello again. I previously presented an argument of why our best option for container streaming is to extend namespace std. I was surprised by the dearth of responses, but I understand that we're all busy and I admit was a bit wordy. Here is my argument again with, heavily snipped. I think this is the most important issue in making this a boost library. Thanks for reading. Jeffrey Faust wrote: > In my opinion the ideal interface is the most natural, > simplest, and the most familiar to C++ developers: 'cout << c;' where > c is a container of type C. > > The only way I know how to make 'cout << c;' work for all cases is to > put operator<<(C) in the same namespace as C. For example, > variant<C, ...> will not stream if C is in std and operator<<(C) is > not. > > In regards to extending namespace std, I understand what the standard > says and I think I understand the reasons behind it. One could add > something to namespace std that conflicts with an existing item, > changing the behavior. This is undefined behavior, and the > standard is right in restricting it. I don't believe this problem > exists for this library in how we plan to extend std. > > If we know that on all supported compilers that extending namespace > std in this way behaves correctly, what is the concrete problem of > doing so? -- Jeff Faust

3 2

[thread] 1.41.0 regression
by Dmitry Goncharov 16 Dec '09

16 Dec '09

Hi, The thread_data_base constructor is defined in a header file. Function make_external_thread_data() is defined in a .cpp file. This can lead to a situation when different libraries contain the definitions of these functions. The example below explains how this can happen and why this causes problems. The new version of struct thread_data_base contains an std::map member. The size of an std::map object depends on if libboost_thread.so was build with or w/o _GLIBCXX_DEBUG. libboost_thread.so contains make_external_thread_data(). This function allocates an instance of thread_data_base. Due to an std::map member the size of the allocated object depends on _GLIBCXX_DEBUG. There is a library (e.g. libuser.so) which uses the Boost.Thread library. Since the thread_data_base constructor is defined in a header file libuser.so can contain its definition. Again, the size of thread_data_base object, that the thread_data_base constructor from libuser.so expects, depends on if libuser.so was built with _GLIBCXX_DEBUG defined or not. An application cannot link agains both libboost_thread.so and libuser.so if these libraries were built with different _GLIBCXX_DEBUG definitions (or different alignment, etc). While loading the application the dynamic linker will use the definition of thread_data_base constructor either from libuser.so be or from libboost_thread.so. Whichever it finds first. Can both the thread_data_base constructor and make_external_thread_data() reside either in a .cpp file or in a header? BR, Dmitry

2 3

[Build] Boost 1.41(?) and OpenSuSE 11.2: i386 no more?
by Christoph Duelli 16 Dec '09

16 Dec '09

Building Boost 1.41 against OpenSuSE 11.2 works fine... until you try to link a lib against a program: You get the following linker error: <path to boost_1_41_0>/lib/libboost_program_options-mt-Melos.so: undefined reference to `__sync_fetch_and_add_4' Googling around indicated that libc or something no longer supports i386 which is Boost's default -march setting for gcc. (see tools/build/v2/tools/gcc.jam) When I changed the default to i686 and rebuilt Boost, the program linked ok. [See: http://sourceware.org/ml/libc-alpha/2007-02/msg00009.html] I am not sure if this is not rather a bug in OpenSuSE 11.2, but it is annoying nevertheless. * Is there an easy way (I modified gcc.jam for my test) to configure -march? (Pleae see my post (yesterday) "Build boost for i686 (instead of i386)" in boost.user.) * Or maybe i386 is no longer a safe default to assume? Best regards, and thank you Christoph

1 0

[function] Using boost::function when rtti is not available
by David Genest 15 Dec '09

15 Dec '09

Hi, Reposting this from the user mailing list, as it generated no comments. I am in a gaming build environment that has traditionally turned off rtti because of space and portability issues. But, I would like to use the very useful boost::function. On MSVC boost::function works, but fails on g++ for the ps3. I have read on the lists that it is possible to implement a rtti-less version, and that this is even wanted in the future. See: http://article.gmane.org/gmane.comp.lib.boost.devel/192378 And http://article.gmane.org/gmane.comp.lib.boost.devel/191945 I know of a lot of people that would like this dependency on rtti removed. My question to the list is: did anyone have a try at an implementation and could share it ? I have toyed with boost::function and sp_typeinfo.hpp and tried to replace occurrences of type_info in function_base.hpp, but I don't have enough understanding to finish the work and my early attempts have failed. As my current understanding goes, the function type could be generated with the sp_typeinfo trick. Is the sp_typeinfo.hpp route a viable one ? Thank you, David.

4 13

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

15 Dec '09

Hi Darryl, >Anyway, I hope that clarifies my concern is not primarily with the >failure to compile on older gcc versions. Yes it does and it's a good point. >I can accept eUML as an experimental library.... Does that help? Yes, I think it's a good term and I'll put it like this in the doc with a word of explanation about compilers and fsm size. >Oh - I also neglected to suggest that a better name for euml is badly needed I like the name eUML. "Embedded UML" is really what it wants to be, UML syntax in the code. Besides you know by now my taste for names which sound cool ;-) Of course, if you find some really cool name... Christophe

1 0