- Boost - lists.boost.org

[general] Preventing compiler ABI clashes
by Vicente J. Botet Escriba 12 May '12

12 May '12

Hi, After some exchanges with Anthony, I have recently reread http://www.boost.org/development/separate_compilation.html#abi and I suspect that I'm not the single one that misunderstood the context of this protocol. As noted in "Counter Argument #2: Prefix/suffix headers have a tendency to "spread" to other boost libraries - for example if boost::shared_ptr<> forms part of your class's ABI, then including prefix/suffix headers in your code will be of no use unless shared_ptr.hpp also uses them. Authors of header-only boost libraries may not be so keen on this solution - with some justification - since they don't face the same problem. " even header-only libraries should use this protocol if other not-header only libraries must conform to it. Shouldn't every Boost library use this protocol? Or at least, allows the user to enable it? What about adding an attribute (ABI Clash Protected) to the library documentation stating if a library supports this protocol? Is there a way to check if a library supports this protocol completely? Best, Vicente

1 0

[hash] Turn on BOOST_HASH_NO_IMPLICIT_CASTS by default
by Daniel James 12 May '12

12 May '12

Hello everyone, There have been occasional issues where Boost.Hash will incorrectly hash an object that doesn't have a hash function but is convertible to bool. I added an extra templated overload of hash_value which contains a static assert. The idea is that it's a better match than the implicit cast, so it will cause a compile error in this case. This is currently only activated when a macro is defined, as it could break otherwise valid code. I was a bit worried about making any interface changes because at this stage, Boost.Hash should be very stable from release to release. The problem turned up again yesterday, so I'm starting to think it's enough of a problem that it's worth activating this be default. A different solution might be to change the implement of Boost.Hash for bools, so that the bool overload isn't required. But that would be treating the sympton, as other implicit casts could cause problems. An example of valid code that will now break is something like: struct base; std::size_t hash_value(base const&); struct derived : base { void some_method_but_no_extra_state(); }; boost::hash<derived> derived_hash; Currently that will automatically use base's hash_value, with this change it will be a compile error. Although that might be a good thing, as sometime it is an error to use the base's hash function. Of course, there will be a macro to keep the old behaviour. Any objections to this change?

3 5

Re: [boost] [Review Request] Multiprecision Arithmetic Library
by Christopher Kormanyos 11 May '12

11 May '12

Sorry, John my file was too big and admin rejected post. The candidate file is now 7-zip and should make it through. <snip> >> I experimented with FFTs. We need your inputs if we *really* >> want to make very high-precision available at this stage. <snip> >> maybe about 30 lines of code. > Nice, had no idea it could be implemented in such a small space! Ooops, my bad. It was 100 lines. I guess I was in a daze by then. <snip> > So my gut feeling is to hold off for now, and maybe do things > properly later (dynamic allocation, better std lib support etc)? I agree. We should pull the reigns on it for now. We won't get the reliability we need if we try to do something fast. I could go on indefinitely with big-numbs, but we have to get that first version potentially reviewed. I should really get back to my book project soon. But I'm definitely in on any relevant review issues. > I think the existing ones work out quite nicely now thanks, > I could use some ideas for integer and maybe rational number examples, > but that's a whole other ball game ;-) I'm not an integer guy. Maybe someone could help us out here. But what springs to my mind is: * Prime factorization * Greatest common denominator (GCD) * Primality testing for Mersenne Primes (has an exceptionally simple algo) * MD5, SHA-1, 2, etc. (but cool std::uint32_t reference apps already exist)<snip> >> I resolved the excessive guard digit issue and reduced the guard digits >> to the necessary amount (and provide rationale in a code comment). <snip> > Sure, or mail me a patch and I'll run the full tests > (or you can - just cd into libs/multiprecision/test and > do a "bjam --enable-specfun" and then wait for a long time!) > Thanks, John. OK. I attached my proposed version in /big_number/multiprecision/cpp_dec_float.hpp. The diffs include the removal of some non-needed constants, the trimming of max_digits10 and a minor improvement to the multiplication. Thanks, Chris.

4 29

[config] New NO_COPYABLE, DELETE_COPY_CTOR and DELETE_COPY_ASSIGN macros
by Vicente J. Botet Escriba 11 May '12

11 May '12

Hi, I'm using the following BOOST_NO_COPYABLE, BOOST_DELETE_COPY_CTOR, BOOST_DELETE_COPY_ASSIGN and macros in Boost.Thread (see http://svn.boost.org/svn/boost/trunk/boost/thread/detail/delete.hpp) I guess some of you have their own similar macros. For uniformity purposes, couldn't them be added to Boost.Config/ Boost Helper Macros <cid:part1.09000208.02050709@wanadoo.fr> if I provide a patch with doc and tests? Best, Vicente [section:delete `=delete` emulation] C++11 allows to delete some implicitly generated functions as constructors and assignment using '= delete' as in public: CLASS(CLASS const&) = delete; CLASS& operator=(CLASS const&) = delete; On compilers not supporting this feature, we can relays on a partial simulation, by declaring the function as private without definition. private: CLASS(CLASS &); CLASS& operator=(CLASS&); The emulation is good but partial as the private functions are still visible. To have the best the user should write public: #ifndef BOOST_NO_DELETED_FUNCTIONS CLASS(CLASS const&) = delete; CLASS& operator=(CLASS const&) = delete; #else // BOOST_NO_DELETED_FUNCTIONS private: CLASS(CLASS&); CLASS& operator=(CLASS&); public: #endif // BOOST_NO_DELETED_FUNCTIONS The following macros allows to take in account the features the compiler provides and have the same effect public: BOOST_DELETE_COPY_CTOR(CLASS) BOOST_DELETE_COPY_ASSIGN(CLASS) As these come together quite often when we want to make a non copyable class the user can use instead public: BOOST_NO_COPYABLE(CLASS) [section:delete_copy_ctor `BOOST_DELETE_COPY_CTOR(CLASS)`] This macro deletes the copy constructor when the compiler supports it or makes it private. It can be included on the public section only. [endsect] [section:delete_copy_assign `BOOST_DELETE_COPY_ASSIGN(CLASS)`] This macro deletes the copy assignment when the compiler supports it or makes it private. It can be included on the public section only. [endsect] [section:no_copyable `BOOST_NO_COPYABLE(CLASS)`] This macro makes a class as no copyable, disabling copy construction and assignment. It can be included on the public section only. [endsect] [endsect]

3 3

[build]
by Emil Dotchevski 11 May '12

11 May '12

Hello, I get the following Boost Build error and I have no idea what's wrong. Halp! C:\Users\Zajo\z\git\reverge\bjam\test c:/Users/Zajo/z/git/munch/boost-build/build\feature.jam:138: in feature.feature from module feature error: feature already defined: error: in feature declaration: error: feature "boost.locale.iconv" : "on" "off" : "optional" "propagated" c:\Users\Zajo\z\git\lib\boost_1_49_0\libs\locale\build\Jamfile.v2:19: in modules.load from module Jamfile</c:/Users/Zajo/z/git/lib/boost_1_49_0/libs/locale/build> c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:314: in load-jamfile from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:62: in project.load from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:766: in project.use from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:89: in load-used-projects from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:73: in project.load from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:766: in project.use from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:89: in load-used-projects from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:73: in project.load from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:766: in project.use from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:89: in load-used-projects from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:73: in load from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:115: in load-parent from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:464: in initialize from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:309: in load-jamfile from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:62: in load from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:115: in load-parent from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:464: in initialize from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:309: in load-jamfile from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:62: in load from module project c:/Users/Zajo/z/git/munch/boost-build/build\project.jam:168: in project.find from module project c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:369: in find-really from module object(project-target)@683 c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:435: in object(project-target)(a)683.find from module object(project-target)@683 c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:816: in resolve-reference from module targets c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:833: in targets.generate-from-reference from module targets c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:1217: in generate-dependencies from module object(typed-target)@1905 c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:1268: in object(typed-target)(a)1905.generate from module object(typed-target)@1905 c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:732: in generate-really from module object(main-target)@2599 c:/Users/Zajo/z/git/munch/boost-build/build\targets.jam:704: in object(main-target)(a)2599.generate from module object(main-target)@2599 c:/Users/Zajo/z/git/munch/boost-build\build-system.jam:736: in load from module build-system c:\Users\Zajo\z\git\munch\NT\..\..\munch\boost-build\kernel\modules.jam:283: in import from module modules c:\Users\Zajo\z\git\munch\NT\..\..\munch\boost-build\kernel\bootstrap.jam:142: in boost-build from module c:\Users\Zajo\z\git\munch\NT\..\..\munch\boost-build.jam:6: in module scope from module Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 2

For Boost PP: IF_NONEMPTY(), IS_NONEMPTY
by Daniel Santos 11 May '12

11 May '12

I came up with some macros the other day trying to solve a kernel problem and I haven't seen them anywhere else and if I found one, I sure would have stolen it. :) I used this to have a single function-like macro service different numbers of parameters, essentially adding "optional parameter" support so I didn't have to have different version of the macro. IF_NONEMPTY(test, result) expands to result if test is non-empty, empty otherwise. IS_NONEMPTY(arg) expands to 0 if arg is empty, 0x1 if it isn't. OPT_OFFSETOF(type, member) isn't very useful in C++, but it is an example of how the above can be used. It expands to a compiler-time constant that is the offset of the member in the struct or union type, unless member isn't specified, in which case it's zero. #define __JUNK junk, #define _if_nonempty(arg1_or_junk, result) __if_nonempty(arg1_or_junk, result) #define __if_nonempty(__ignored, result, ...) result #define CONCAT_TOKEN(a, b) _concat_token(a, b) #define _concat_token(a, b) a ## b #define IF_NONEMPTY(test, result) _if_nonempty(__JUNK##test, result) #define IS_NONEMPTY(arg) CONCAT_TOKEN(0, IF_NONEMPTY(arg, x1)) #define OPT_OFFSETOF(type, m) ((size_t) &((*((type *)0)) IF_NONEMPTY(m,.)m))

3 3

[reference_wrapper] add operator()(Args...) to reference_wrapper
by Philipp Moeller 10 May '12

10 May '12

Given that Boost now has perfect forwarding emulation through Boost.Move and a better result_of, would it be possible to enable reference_wrapper to forward the function call operator? The current behavior is somewhat surprising and makes a few of the most promising applications of reference_wrapper (reference wrap polymorphic boost::function objects) impossible with code that is no prepared to work with reference_wrapper. It would also be more consistent with reference_wrapper of the stdlib. I can file a corresponding bug report and add a patch, if there is interest. Cheers, Philipp Moeller

2 5

[multi_array] Updated patches
by Bill Buklis 10 May '12

10 May '12

For the multi_array library, there is an updated version of the library in the trunk plus a few tickets that have proposed patches. These are updates for some fairly important issues. I'd absolutely love it if these patches could be incorporated into the next boost release, whenever that may be. I realize that the official maintainer, Garcia, is understandably very busy, so could one of the powers that be please review these patches for correctness and update the official libraries as needed? Here are the tickets that already have proposed fixes: ticket:4874 <https://svn.boost.org/trac/boost/ticket/4874> - multi_array compile errors using Visual C++ 2010 in debug mode ticket:6554 <https://svn.boost.org/trac/boost/ticket/6554> - Compiler error dereferencing multi_array value via an iterator ticket:6811 <https://svn.boost.org/trac/boost/ticket/6811> - Default argument of type multi_array fails under MSVC 2010 SP1 Thanks, -- Bill

1 0

[preprocessor] include speed question
by lcaminiti 10 May '12

10 May '12

Hello all, I have a general question about what's the best way to include files that results in faster compilation time. In my example, I have *a lot* of files that use different parts of Boost.Preprocessor. Each header includes the specific Boost.Preprocessor headers that it needs. As a results the same Boost.Preprocessor header and #included many times (50+?) even if the including has no effect after the first inclusion. Furthermore, at the end essentially all Boost.Preprocessor header get included. This way is more module in that each single file includes all the headers that it needs. But, does that slow down compilation? Would it be faster to just #include <boost/preprocessor.hpp> just once into a front-end header that then includes all my single header files? (Maybe with modern compilers and file-systems this makes no difference?) Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-preprocessor-include-speed-questio… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

Scoped enum emulation
by Anthony Williams 10 May '12

10 May '12

Hi, On trunk there are currently two scoped enum emulation headers. One is the one that Beman wrote, in boost/detail/scoped_enum_emulation.hpp and the other is the one that Vicente has developed for the new version of Boost.Thread, in boost/thread/detail/scoped_enum.hpp It seems to me that it is a shame to have two implementations of the same thing in boost. Since Vicente's version provides additional facilities, I would therefore like to merge Vicente's code into the boost/detail header. We could retain the simple macros from Beman's header as wrappers for the more complex macros that Vicente has written. What do you think? Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++11 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