- Boost - lists.boost.org

[serialization] alternative with inter-thread and network messaging
by Scott Woods 21 Apr '10

21 Apr '10

Hi Boost, I've been developing a serialization library to prove a few concepts and this has recently started to bear fruit. It tackles the problem space in quite a distinct way resulting in features like runtime-selectable encodings and out-of-the-box network messaging. Feel free to poke around in the software at; http://groups.google.co.nz/group/pact-serialization/web Aspects of the design came from sources such as; * SDL (http://www.sdl-forum.org/SDL/index.htm) * Active Objects (http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf<http://www.cs.wustl.edu/%7Eschmidt/PDF/Act-Obj.pdf> ) The work was motivated by years of battling with proprietary encodings, configuration files, data formats, telephony signaling systems and TCP application protocols. This is a framework to give all the related pieces a proper place and more importantly, to keep things like network APIs out of application code. I would be interested in submitting this for Boost review but suspect that the library is too big. It also overlaps with a long list of existing components including serialization, asio, MPI, threads, uuid, any, variant and statechart. Maybe the integration of all those facilities is interesting to Boost? Or if there was something that could be carved off for separate submission - perhaps the UTF templates? Advice from moderators would be appreciated. Cheers, Scott

1 0

[serialization] alternative with inter-thread and network messaging
by Scott Woods 21 Apr '10

21 Apr '10

Hi Boost, I've been developing a serialization library to prove a few concepts and this has recently started to bear fruit. It tackles the problem space in quite a distinct way resulting in features like runtime-selectable encodings and out-of-the-box network messaging. Feel free to poke around in the software at; http://groups.google.co.nz/group/pact-serialization/web Aspects of the design came from sources such as; * SDL (http://www.sdl-forum.org/SDL/index.htm) * Active Objects (http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf) The work was motivated by years of battling with proprietary encodings, configuration files, data formats, telephony signaling systems and TCP application protocols. This is a framework to give all the related pieces a proper place and more importantly, to keep things like network APIs out of application code. I would be interested in submitting this for Boost review but suspect that the library is too big. It also overlaps with a long list of existing components including serialization, asio, MPI, threads, uuid, any, variant and statechart. Maybe the integration of all those facilities is interesting to Boost? Or if there was something that could be carved off for separate submission - perhaps the UTF templates? Cheers, Scott

1 0

[range] Request to merge minor small defect fixes
by Neil Groves 20 Apr '10

20 Apr '10

Please may I merge some very small defect fixes for Boost.Range, and an additional test? The defect fixes are to improve return types consistency. I would like to get the interface correct for the first release of the merged RangeEx code. I have also added a test case that checks the use of non-member functions as functors and explicitly tests chaining of Range Adaptors. I believe this provides appreciably better visibility of the state of the library on the various compilers. These changes have been passing tests on the trunk for several days. The changes are also extremely low impact as they are in the new Range code that is not yet used within the rest of the Boost libraries. Thanks, Neil Groves

3 5

Bug #2501: upgrade_to_unique_lock doesn't compile on C++0x mode
by Rodolfo Schulz de Lima 20 Apr '10

20 Apr '10

Hi, is there any chance that the patch attached to bug #2501 can/will be in 1.43? It works for me (with minor patch adjustments) and IMHO is safe to be merged into trunk. I've been patching my local copy of boost for the last 6 releases... I'm a little tired of doing that :) []s, rod

3 4

[release] Permission to merge fix for issue 2501 in boost.thread
by Anthony Williams 20 Apr '10

20 Apr '10

Hi, I just committed a fix for issue 2501 to trunk. Can I merge this to release once the tests have cycled? Thanks, Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

3 2

[GSoC] Requesting a review on my GSoC proposal
by Stefan 20 Apr '10

20 Apr '10

Hello. I apologize for being so persevering but I have posted a comment on my proposal and received no feedback yet. It would be greatly appreciated if you could let me know of your opinion in connection to my application as well as request any clarification if applicable. Proposal link: http://socghop.appspot.com/gsoc/student_proposal/private/google/gsoc2010/ms… (private, thus viewable only by mentors) Best wishes, Stefan

1 0

[mpl] aux_::template_arity subtly broken on gcc-4.5
by Eric Niebler 20 Apr '10

20 Apr '10

First, I freely acknowledge that I have been relying on an implementation detail of MPL, and I will spend an appropriate amount of time doing penance in programmer purgatory after I die. That said ... Xpressive is broken on gcc-4.5 because mpl::aux_::template_arity is causing instantiations on that compiler that it shouldn't. Consider the following program that compiles on gcc-4.4 but not gcc-4.5. #include <boost/mpl/aux_/template_arity.hpp> #include <boost/mpl/aux_/lambda_arity_param.hpp> template<class A> struct T : A::x {}; template< class T BOOST_MPL_AUX_LAMBDA_ARITY_PARAM( int Arity = boost::mpl::aux::template_arity<T>::value ) > struct S {}; template<template<class A> class P, class X> struct S<P<X> BOOST_MPL_AUX_LAMBDA_ARITY_PARAM(1)> {}; int main() { S<T<int> > s0; } The error I get is: bug4109.cpp: In instantiation of ‘T<int>’: ../../../boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:85:5: instantiated from ‘const int boost::mpl::aux::template_arity_impl<T<int>, 1>::value’ ../../../boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:93:5: instantiated from ‘const int boost::mpl::aux::template_arity<T<int> >::value’ ../../../boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:98:30: instantiated from ‘boost::mpl::aux::template_arity<T<int> >’ bug4109.cpp:23:14: instantiated from here bug4109.cpp:6:3: error: ‘int’ is not a class, struct, or union type Any chance of a fix? -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 3

Re: [boost] [Bind] How do I get bind to deduce the return type of for_each?
by Thomas Jordan 20 Apr '10

20 Apr '10

Thomas Jordan wrote: > [snip] > Thanks for the suggestion, Roland, I am sure you could get something like this to work easily enough. However, if I understand correctly your suggestion involves defining a separate functor - myClass - to take the vocType's, and which I guess wraps the inner call to for_each. I had hoped for a more generic solution which doesn't involve the creation of new functors. I was hoping I could accomplish the objective of passing an algorithm into an algorithm jgenerically, just doing everything at point of call using just Boost.bind, the std::algorithms (wrapped) and using if necessary some boost.function functors to help type deduction. Are we saying this isn't possible? > Roland Bock replied: ************************************ Hi Thomas, we don't say it isn't possible :-) Here you go: // ----------------------------------------------------------- #include <boost/bind.hpp> #include <boost/bind/protect.hpp> #include <boost/function.hpp> #include <vector> #include <iostream> using namespace std; using namespace boost; int initValue = 0; class myClass { public: myClass(): mValue(initValue) {} myClass(const myClass& rhs): mValue(initValue++) { } void func() { cout << mValue << endl; } private: int mValue; }; typedef vector<myClass> vocType; typedef vector<vocType> vovType; int main() { vovType vov(10, vocType(10, myClass())); for_each(vov.begin(), vov.end(), bind(for_each< vocType::iterator, function<void (myClass&)> >, bind<vocType::iterator>(&vocType::begin, _1), bind<vocType::iterator>(&vocType::end, _1), protect(bind(&myClass::func, _1)) ) ); } // ----------------------------------------------------------- Please let me know if this is working for you. Regards, Roland ************************************************************** Thanks a lot, Roland, this looks good. I felt there must be some way to do it, but it was just beyond my grasp. Always learning! Regards, Tom.

2 1

[config] Compiler defects value-initialization
by Niels Dekker - address until 2010-10-10 19 Apr '10

19 Apr '10

The Config/trunk regression page currently shows some detailed information of various compiler defects regarding value-initialization: http://www.boost.org/development/tests/trunk/developer/config_.html If anyone wants to have a look at these results, please do so quickly! The output is from boost_no_complete_value_initialization::test(), which tests whether a specific compiler should have a new defect macro defined, BOOST_NO_COMPLETE_VALUE_INITIALIZATION. In a few days, I'm planning to add this definition to the Boost Config files of those compilers [Boost #4080], and then the test output will disappear automatically. According to the current test results, two compilers do an excellent job w.r.t. value-initialization: Intel (10.1, 11.0, 11.1) on Mac OS X, and GCC 4.4.3 (both on Linux and Windows). Compilers that don't completely do value-initialization include Microsoft Visual C++ (including msvc-10.0), Borland (including CodeGear 2010), Sun 5.10, and IBM XL V10.1. The MSVC defect was reported back in 2005 [Visual Studio #100744]. I recently reported the value-initialization defects I encountered on Embarcadero CodeGear [Embarcadero #83751, #83851] and IBM XL. The Windows version of Intel 11.1 doesn't do so well either, according to results from Huang-Vista-x86_32_intel. I still wonder why, because on Mac OS X, Intel does so well. GCC also has regression failures w.r.t. value-initialization, but those are only on earlier GCC versions, like gcc-4.2.4 and gcc-4.3.4. The last GCC bug in this area, AFAIK, [GCC #30111] was fixed for GCC 4.4. As far as I have seen, any compiler supports value-initialization of integers, floating point numbers and pointers correctly. However, problems occur for structs, classes, and arrays. Objects of those types may be left partially or entirely uninitialized, when they should have been value-initialized, depending on the compiler. I hope to have the test and the defect macro included with Boost 1.44. Please let me know if you have any comment or question about them. https://svn.boost.org/svn/boost/trunk/libs/config/test/boost_no_com_value_i… Kind regards, Niels References: [Boost #4080] "Various compilers need BOOST_NO_COMPLETE_VALUE_INITIALIZATION", https://svn.boost.org/trac/boost/ticket/4080 [Visual Studio #100744] "Value-initialization in new-expression", reported by Pavel Kuznetsov: https://connect.microsoft.com/VisualStudio/feedback/details/100744 [Embarcadero #83751, #83851] Two value-initialization bugs I recently reported: http://qc.embarcadero.com/wc/qcmain.aspx?d=83751 http://qc.embarcadero.com/wc/qcmain.aspx?d=83851 [GCC #30111] "Value-initialization of POD base class doesn't initialize members", reported by Jason Merrill: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111 -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 0

Re: [boost] [Bind] How do I get bind to deduce the return type offor_each?
by Thomas Jordan 19 Apr '10

19 Apr '10

Thomas Jordan wrote: > Thanks a lot for the suggestion, I did take a look at Lambda library, and > I saw that it used some extra type information in its STL > algorithm wrappers (the 'sig') to help it figure out the return types. > However, I am against using the Lambda library > for other reasons, I only want to use the bind library. I'd appreciate > some specific advice on how to get the type deduction > with the Boost.bind library. Or is this just not possible with > Boost.bind? Peter Dimov replied: ----------------- It's not. Boost.Bind only supports function objects with a specific, fixed type. There is no mechanism to tell it that the return type of struct myForEach { template <typename II, typename F> F operator()(II begin, II end, F function) const { return std::for_each(begin, end, function); } }; is the same as its third argument. In this specific case I'd just use struct myForEach { typedef void result_type; template <typename II, typename F> void operator()(II begin, II end, F function) const { std::for_each(begin, end, function); } }; -------------------- Thanks, Peter, and thanks to everyone else who replied, for their helpful suggestions. FWIW, I'm putting together a presentation for my colleagues, to show the facilities for higher-order programming in STL and Boost, and I wanted to show a couple of 'out-there' examples to illustrate their power. I'm a bit of an arriviste and my C++ is 'improving,' but I'm really impressed that you can do functional-style programming so nicely in C++. Regards, Tom.

2 1