- Boost - lists.boost.org

Re: [boost] Slow Bugs Tracker
by Olaf van der Spek 29 Apr '12

29 Apr '12

Hi, A few months ago there seemed to be plans to improve Trac. What's the status of those plans? Trac is still slow as hell. http://lists.boost.org/Archives/boost/2011/12/188639.php http://lists.boost.org/Archives/boost/2011/12/188937.php -- Olaf

7 44

[utility] convention inconsistencies
by lcaminiti 29 Apr '12

29 Apr '12

Hello all, I'm adding IdentityType to Boost.Utility and I have a couple of question about conventions: 1) Is there a reason why utility.hpp does not include all headers in boost/utility/? 2) Is there a reason why in the Documentation the utility sub-libraries are not named Boost.Utility/EnableIf bust just Boost.EnableIf? http://www.boost.org/doc/libs/1_49_0/ In boost/utility/ directory: addressof.hpp base_from_member.hpp binary.hpp compare_pointees.hpp declval.hpp enable_if.hpp identity_type.hpp in_place_factory.hpp result_of.hpp swap.hpp typed_in_place_factory.hpp value_init.hpp But boost/utility.hpp includes only some of those: #ifndef BOOST_UTILITY_HPP #define BOOST_UTILITY_HPP #include <boost/utility/addressof.hpp> #include <boost/utility/base_from_member.hpp> #include <boost/utility/binary.hpp> #include <boost/utility/enable_if.hpp> #include <boost/checked_delete.hpp> #include <boost/next_prior.hpp> #include <boost/noncopyable.hpp> #endif // BOOST_UTILITY_HPP Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-utility-convention-inconsistencies… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[function] The cost of boost::function
by Michael Kochetkov 28 Apr '12

28 Apr '12

Hello, as far as I subscribed to boost mail list for a reason I have decided to share an interesting (at least for me) observation of boost::function facility I have encountered several years ago. The observation is about the cost of the solution and you probably may be interested if you use boost in your production. Let us consider the following code: #include <boost/bind.hpp> #include <boost/function.hpp> inline int g(int i) { return ++i; } int main() { // AAAAA boost::function< int (int) > f1 = boost::bind(&g, _1 ); f1(1); // BBBB boost::_bi::bind_t<int,int (*)(int),boost::_bi::list1<boost::arg<1> > > f2 = boost::bind(&g, _1 ); f2(1); // CCCC auto f3 = boost::bind(&g, _1 ); f3(1); } I have compiled it with Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 the following way (maximal optimization): cl -EHsc -Ox -GL -Ob2 -Oi -Fa -IE:\Work\3dparty\boost_1_48_0 m054.cpp The resulting code for AAAA is: ; Line 10 mov eax, OFFSET ?g@@YAHH@Z ; g mov DWORD PTR $T109940[esp+60], eax mov eax, DWORD PTR $T109845[esp+64] lea ecx, DWORD PTR $T109940[esp+60] push ecx mov DWORD PTR $T109940[esp+68], eax call ?has_empty_target@function@detail@boost@@YA_NZZ ; boost::detail::function::has_empty_target add esp, 4 test al, al jne SHORT $LN20@main mov edx, DWORD PTR $T109940[esp+60] mov eax, DWORD PTR $T109940[esp+64] mov ecx, OFFSET ?stored_vtable@?1???$assign_to@V?$bind_t@HP6AHH@ZV?$list1@U?$arg@$00@boost@@ @_bi@boost@@@_bi@boost@@@?$function1@HH@boost@@AAEXV?$bind_t@HP6AHH@ZV?$list 1@U?$arg@$00@boost@@@_bi@boost@@@_bi@2@@Z@4U?$basic_vtable1@HH@function@deta il@2@B ; `boost::function1<int,int>::assign_to<boost::_bi::bind_t<int,int (__cdecl*)(int),boost::_bi::list1<boost::arg<1> > > >'::`2'::stored_vtable or ecx, 1 mov DWORD PTR _f1$[esp+68], edx mov DWORD PTR _f1$[esp+72], eax mov DWORD PTR _f1$[esp+60], ecx jmp SHORT $LN18@main $LN20@main: mov DWORD PTR _f1$[esp+60], 0 $LN18@main: ; Line 11 lea ecx, DWORD PTR _f1$[esp+60] mov DWORD PTR __$EHRec$[esp+68], 0 call ??R?$function1@HH@boost@@QBEHH@Z ; boost::function1<int,int>::operator() The resulting code for BBBB is: ; Line 15 push 1 call ?g@@YAHH@Z ; g add esp, 4 The resulting code for CCCC is: ; Line 19 push 1 call ?g@@YAHH@Z ; g add esp, 4 I have learned that personally I shall never use boost::function. You probably may want to investigate such a code bloat. Though it is probably the known and expected behavior. And I do agree that CCCC is not quite relevant here. Just for information. -- Michael Kochetkov P.S. The traditional full story for AAAA, that includes intermediate calls. Though it is not really full -- I have given up for three more calls inside the boost::function1<int,int>::operator() function. ; // AAAAA ; boost::function< int (int) > f1 = boost::bind(&g, _1 ); ; f1(1); 002661B9 mov eax,261170h 002661BE mov dword ptr [esp+4],eax 002661C2 mov eax,dword ptr [esp+8] 002661C6 lea ecx,[esp+4] 002661CA push ecx 002661CB mov dword ptr [esp+0Ch],eax 002661CF call 00261160 002661D4 add esp,4 002661D7 test al,al 002661D9 jne 002661F9 002661DB mov edx,dword ptr [esp+4] 002661DF mov eax,dword ptr [esp+8] 002661E3 mov ecx,26A028h 002661E8 or ecx,1 002661EB mov dword ptr [esp+14h],edx 002661EF mov dword ptr [esp+18h],eax 002661F3 mov dword ptr [esp+0Ch],ecx 002661F7 jmp 00266201 002661F9 mov dword ptr [esp+0Ch],0 00266201 lea ecx,[esp+0Ch] 00266205 mov dword ptr [esp+38h],0 0026620D call 002611D0 ; ?has_empty_target@function@detail@boost@@YA_NZZ ; boost::detail::function::has_empty_target 00DD1160 xor al,al 00DD1162 ret ; ??R?$function1@HH@boost@@QBEHH@Z ; boost::function1<int,int>::operator() 00DD11D0 push 0FFFFFFFFh 00DD11D2 push 0DD7810h 00DD11D7 mov eax,dword ptr fs:[00000000h] 00DD11DD push eax 00DD11DE sub esp,58h 00DD11E1 push esi 00DD11E2 mov eax,dword ptr ds:[00DDB038h] 00DD11E7 xor eax,esp 00DD11E9 push eax 00DD11EA lea eax,[esp+60h] 00DD11EE mov dword ptr fs:[00000000h],eax 00DD11F4 mov eax,dword ptr [ecx] 00DD11F6 test eax,eax 00DD11F8 jne 00DD1248 00DD11FA lea eax,[esp+0Ch] 00DD11FE push eax 00DD11FF lea ecx,[esp+14h] 00DD1203 mov dword ptr [esp+10h],0DDA008h 00DD120B call 00DD187F 00DD1210 mov dword ptr [esp+10h],0DDA058h 00DD1218 lea eax,[esp+10h] 00DD121C lea esi,[esp+1Ch] 00DD1220 mov dword ptr [esp+68h],0 00DD1228 call 00DD1600 00DD122D lea esi,[esp+3Ch] 00DD1231 mov byte ptr [esp+68h],1 00DD1236 call 00DD1640 00DD123B push 0DDA7A8h 00DD1240 mov ecx,esi 00DD1242 push ecx 00DD1243 call 00DD23CA 00DD1248 and eax,0FFFFFFFEh 00DD124B mov edx,dword ptr [eax+4] 00DD124E add ecx,8 00DD1251 push 1 00DD1253 push ecx 00DD1254 call edx 00DD1256 add esp,8 00DD1259 mov ecx,dword ptr [esp+60h] 00DD125D mov dword ptr fs:[0],ecx 00DD1264 pop ecx 00DD1265 pop esi 00DD1266 add esp,64h 00DD1269 ret

6 8

[1.50] Is there a schedule?
by John Maddock 27 Apr '12

27 Apr '12

OK, so it's too soon at present anyway, but should there be some sort of schedule on the calendar so we all know where we are? Cheers, John.

2 1

Boost.Variant known_get
by David Sankel 27 Apr '12

27 Apr '12

I noticed the detail::known_get function in boost variant. Is there any reason this function, which would be useful in high performance scenarios, is not exposed as part of the rest of the interface? David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

1 0

Boost.units autoscaling doesn't seem to work with the measurement type.
by Paul A. Bristow 27 Apr '12

27 Apr '12

I have previously used Boost.Units and autoscaled using << engineering_prefix nicely, and this works as expected for quantity of type double. but it seems that code that I believe worked previously does not autoscale when using a *user-defined type*, like the measurement example in kitchen_sink.cpp. To confirm this, I have added after //[kitchen_sink_snippet_8 in kitchen_sink.cpp at line 445 a measurement quantity where the length is long enough to trigger conversion to km, thus quantity<length,measurement<double> > biglen(measurement<double>(12345.0,123.0)*meters); std::cout << "Biglen autoscaled "<< engineering_prefix << biglen << std::endl; but I get a *unscaled* value :-( Biglen autoscaled 12345(+/-123) m rather than the expected conversion to kilometers 12.345(+/- 0.123) km Am I doing something wrong, or has something changed? Thanks Paul PS Using Microsoft Visual Studio 2010 Version 10.0.40219.1 SP1Rel Microsoft .NET Framework Version 4.0.30319 SP1Rel Boost-trunk (Boost.1.49) --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

1 1

Re: [boost] [decimal] Proposed portable implementation of std::decimal
by Josh Quigley 27 Apr '12

27 Apr '12

As previously mentioned, the plan is to wire up existing (C interface) packages to a C++ std::decimal, raising licensing issues around the 3rd party code. I don't believe there is an issue, the licences are very short and read like plain English to me. Also, gcc includes both of these in it's implementation, and distributes under an open licence. I've copy-pasted below the relevant bits out of the EULAs. If anyone thinks there might be an issue, please let me know. INTEL EULA Copyright (c) 2011, Intel Corp. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, his list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of Intel Corporation nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. IBM Licence Copyright (c) 1995-2012 International Business Machines Corporation and others All rights reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, provided that the above copyright notice(s) and this permission notice appear in all copies of the Software and that both the above copyright notice(s) and this permission notice appear in supporting documentation.

3 3

Variadic to Head/Tail TMP List
by Fernando Pelliccioni 27 Apr '12

27 Apr '12

Hi, Is this piece of code useful ? http://pastebin.com/tRrqVHTw The purpose is to tranform code like the following: typedef cons<int, cons<float, cons<char, cons<string>>>> t0; // fusion::cons or similar data structures in typedef chain_generator<cons, nil> cons_gen; typedef cons_gen::gen<int, float, char, std::string>::type t1; I don't know if there is something similar in a library. I think it could be useful. Compiler tests: GCC 4.7 -> Compiler Error GCC 4.7.1 & Trunk -> OK http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53108 Clang Trunk -> OK MSVC 11 beta -> has no Variadic Templates Regards, FP.

2 2

Boost.ntree_container (bi_tree, quad_tree, oct_tree, etc ptr containers) Is there any interest in this?
by Dan Walters 27 Apr '12

27 Apr '12

Hi all, I am proposing adding spacial containers for efficiently storing and accessing data of a spacial nature in fixed size trees. n-tree data structures would be useful where data relates to a 1D, 2D or 3D location, providing n-array searching of an n-array volume. N-tree data structures are commonly used in 3d applications, and are rarely particularly specialized. Their use is fundamental however they are frequently written by application programmers, due to a lack of free open source implementations (to the limit of my research). Their sophistication, like any container, is slim but easy to get wrong and beyond the ability and time contraints that should be assumed of the application programmer. It is a flexible and standard enough concept that a single implementation can be expected to meet a majority of requirements. I think there is the opportunity to create a solid implementation of templated n-tree pointer containers. The ntree container would be a tree representing an narray of elements with all dimensions being the same and being a power of two. The tree is memory efficient where areas within the volume are not occupied, and so "branches" and "leaves" are not created. The tree is well suited to geometrical operations such as ray picking or plane culling of the volume. An n-tree structure could be used in the place of any sparely populated n dimensional array where memory saving is the objective. The existing libraries I have found are licensed under GNU licenses. A ntree container should implement: get reset overloaded (array style) operators Optional implementations: views - a subset object representing an area or volume within the tree for accelerated access to a group of leaves that are positioned near to each other raycasting plane culling (getting leaves within a set of planes) etc. Is there interest in such a library? Many thanks, Dan

7 7

[interprocess] ppc compile error
by Tim Blechmann 27 Apr '12

27 Apr '12

hi all, one of my users reported the following compile error when building my application for ppc/osx(10.5): /var/folders/+D/+DUo7PxAEgCfHTatXKIeMU+++TI/-Tmp-//ccPubDFs.s:5566:Unknown pseudo-op: .subsection /var/folders/+D/+DUo7PxAEgCfHTatXKIeMU+++TI/-Tmp-//ccPubDFs.s:5566:Rest of line ignored. 1st junk character valued 50 (2). /var/folders/+D/+DUo7PxAEgCfHTatXKIeMU+++TI/-Tmp-//ccPubDFs.s:5569:Unknown pseudo-op: .previous the specific part of the assembly is: -- 4010 L686: 4011 sync 4012 lwarx r8,0,r11 4013 cmpw r8, r3 4014 bne- 2f 4015 stwcx. r9,0,r11 4016 bne- 2f 4017 addi r2,0,1 4018 1:.subsection 2 4019 2: addi r2,0,0 4020 b 1b 4021 .previous 4022 4023 cmpwi cr7,r2,0 4024 mr r3,r8 4025 beq cr7,L686 4026 stw r8,20(r10) 4027 mulli r3,r8,12 4028 add r3,r3,r10 4029 addi r3,r3,28 4030 bl L__ZNK5boost12interprocess10offset_ptrIfimLm0EE14to_raw_pointerEv$stub 4031 addi r1,r1,96 4032 stw r3,4(r30) 4033 lwz r0,8(r1) 4034 nop 4035 lmw r30,-8(r1) 4036 mtlr r0 4037 blr -- this error occurs with boost-1.49.0 ... is this a known issue or some workaround? thanks, tim

2 2