- Boost - lists.boost.org

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