January 2012 - Boost - lists.preview.boost.org

boost log project - compile with mingw (gcc 4.5.4) on win7- problems
by Aleksander Sandro GRM 19 Jan '12

19 Jan '12

Dear, recently I started to use boost::log api. I work on win7 machine and use mingw-x86-64 compiler ver. 4.5.4. Now I got trunk version for boost and boost::log api and encountered problems with compilation. Problem is with: C:\Users\sandro\Documents\progs\opt\cpp_libs\boost_trunk>bjam --with-log -a toolset=gcc target-os=windows variant=release link=shared runtime-link=sha red define=BOOST_ALL_DYN_LINK define=BOOST_LOG_USE_CHAR stage C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\generators.jam:1085: in ensure-type from module generators error: target { simple_event_log.mc. } has no type C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\generators.jam:1319: in generators.construct from module generators C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1495: in construct from module object(typed-target)@354 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1298: in object(typed-target)(a)354.generate from module objec t(typed-target)@354 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:732: in generate-really from module object(main-target)@834 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:704: in object(main-target)(a)834.generate from module object( main-target)@834 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:258: in object(project-target)(a)343.generate from module obje ct(project-target)@343 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:848: in targets.generate-from-reference from module targets C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1217: in generate-dependencies from module object(install-ta rget-class)@97 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1269: in object(install-target-class)(a)97.generate from modul e object(install-target-class)@97 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:732: in generate-really from module object(main-target)@808 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:704: in object(main-target)(a)808.generate from module object( main-target)@808 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:848: in targets.generate-from-reference from module targets C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1217: in generate-dependencies from module object(top-level- target)@106 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1269: in alias-target-class.generate from module object(top- level-target)@106 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk\boostcpp.jam:409: in build-multiple from module object(top-level-target)@106 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk\boostcpp.jam:373: in object(top-level-target)(a)106.generate from module object(top-level-targe t)@106 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:732: in generate-really from module object(main-target)@812 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:704: in object(main-target)(a)812.generate from module object( main-target)@812 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2\build-system.jam:736: in load from module build-system C:\Users\sandro\Documents\progs\opt\cpp_libs\boost_trunk\tools\build\v2/kernel\modules.jam:283: in import from module modules C:\Users\sandro\Documents\progs\opt\cpp_libs\boost_trunk\tools\build\v2/kernel/bootstrap.jam:142: in boost-build from module C:\Users\sandro\Documents\progs\opt\cpp_libs\boost_trunk\boost-build.jam:17: in module scope from module To correct the error in the spirit of link ...( unfortunately I can't find it now ) 1. boost_trunk\tools\build\v2\tools\mc.jam: line 41: actions compile { # mc $(MCFLAGS) -h "$(<[1]:DW)" -r "$(<[2]:DW)" "$(>:W)" # --- replace mc with windmc --- windmc $(MCFLAGS) -h "$(<[1]:DW)" -r "$(<[2]:DW)" "$(>:W)" } 2. boost_trunk\tools\build\v2\tools\gcc.jam: line 28: addin additional import import fortran ; import mc ; After compile starts but got errors in compile time. All compile message is attached in compile.log I use trunk versions from date 18.01.2012 for both, boost and boost::log api. Best regards, Sandro.

1 0

Re: [boost] [thread] Boost.Thread defines boost::move which conflicts with Boost.Move
by Evan Wallace 18 Jan '12

18 Jan '12

On Thu, 05 Jan 2012 07:00:27 +0100, Vicente J. Botet Escriba wrote:>Mankarse please, could you post here the patch for the boost.thread >class so that I can start the integration of what you have already done? I have attached a patch to the ticket (https://svn.boost.org/trac/boost/ticket/6194) This patch is fairly comprehensive in terms of code, but it does not include any tests or documentation. In the course of writing the patch, I created some simple tests, but I have not yet translated these into Boost.Test testcases, or included them in the patch. I have tested the basic functionality on a number of compilers, but there are probably still some bugs in the patched code. The patch contains a number of known problems that may be worth discussing:1) Explicit move() and copy() calls:boost::thread and boost::packaged_task both have templated constructors that take an rvalue reference to a functor (which they move or copy as appropriate). Templates parameters cannot be deduced to a type that is only reachable through an conversion operator. Template constructors can also never be explicitly instansiated. (As far as I know.) This means that the overloads that are used in the definitions of BOOST_COPYABLE_AND_MOVABLE types (BOOST_RV_REF(type), BOOST_CATCH_CONST_RLVALUE(type), type&), are not matched for rvalue objects (in C++03 mode). Example: //In C++11 the `CopyableAndMovableFunctor` would be //moved into the thread. //In C++03 this does not compile. boost::thread((CopyableAndMovableFunctor())) Here, no overload would be matched, because the `type` in the overloads is templated. To solve this problem I modified Boost.Move to add two member functions - `copy()` and `move()` - which forward to the rv const& and rv& conversion operators. With these, the above example can be rewritten as: //In both C++11 and C++03 the `CopyableAndMovableFunctor` //will be moved or copied into the thread as appropriate. boost::thread(CopyableAndMovableFunctor().move()), boost::thread(CopyableAndMovableFunctor().copy()) I can imagine the names `copy` and `move` being quite common, so this might cause unfortunate conflicts. Is this an acceptable change to Boost.Move? Is there another way to get the functionality that does not require this? 2) SFINAE requiredBoost.Move requires SFINAE, and by extension Boost.Thread now also requires SFINAE. Previously, Boost.Thread did not require SFINAE. Is this an acceptable regression, or should more work be put into maintaining compatibility with compilers that do not support SFINAE? 3) Not using has_move_emulation_enabledI did not notice the `has_move_emulation_enabled` metafunction, and instead used `is_convertible!(T&, boost::rv!(T))`. This may mean that some situations that `has_move_emulation_enabled` accounts for will not be accounted for by the code in the patch. I have not yet evaluated whether simply replacing all the occurrences will work. Any thoughts? 4) Not using Vicente's patches for #6174 or #5990By the time that I was aware of these patches, I had already independently fixed the issues. I have not looked at either patch in detail, but they each go about fixing the issues in a significantly different way from my patch. Which code should be used in each of these cases? Where should I go from here? I could do the integration into the svn trunk version, write the documentation, or update the tests to the new version. Are there any other tasks that I can help out with? I will of course keep the patch updated with fixes for any bugs that I find in it. Evan Wallace

5 11

[preprocessor] Warning: Incoming
by Paul Mensonides 18 Jan '12

18 Jan '12

I'm about to commit a relatively significant changeset to the pp-lib. This is the result of work by Edward Diener and I to add limited variadic support to the pp-lib. Edward can comment in more detail regarding the extent of those changes, but they do not add ground-up support. However, there are significant changes to heavily used low-level facilities such as BOOST_PP_TUPLE_ELEM (sometimes even complete implementation replacements). We have put in a great deal of effort to avoid introducing new errors or warnings in either the building of the Boost binaries or in the regression tests. However, we may have missed some issues. Regards, Paul Mensonides

11 42

[preprocessor] [variadic] BOOST_PP_VARIADICS vs BOOST_NO_VARIADIC_MACROS
by lcaminiti 18 Jan '12

18 Jan '12

Hello all, Why does Boost.Preprocessor redefines BOOST_PP_VARIAIDCS instead of just using BOOST_NO_VARIADIC_MACROS from Boost.Config? Furthermore, GCC supports variadics also when C++11 extensions are not enabled so I think the following should not && __GXX_EXPERIMENTAL_CXX0X__: // File: boost/preprocessor/config/config.hpp # /* Wave (C/C++), GCC (C++) */ # elif defined __WAVE__ && __WAVE_HAS_VARIADICS__ || defined __GNUC__ && __GXX_EXPERIMENTAL_CXX0X__ # define BOOST_PP_VARIADICS 1 Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-preprocessor-variadic-BOOST-PP-VAR… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

Need some 64-bit testing help.
by John Maddock 18 Jan '12

18 Jan '12

Folks, I need some help with the tests in: sandbox/big_number/libs/multiprecision/test Which I have an suspicion may have problems in 64-bit release mode (though I hope not!), so I'm looking for some folks to do a: bjam release --disable-concepts in that directory with whatever 64-bit compilers you have access to. Many thanks in advance! John.

4 8

Request for Interest in several Modules
by Artyom Beilis 18 Jan '12

18 Jan '12

Hello, I have several modules/libraries I developed and released under Boost License. - CppDB Sql Connectivity - Stack Trace - Shared Object Loading - Nowide UTF-8 friendly standard C/C++ library API. ---------------------------------- Let's start Boost.CppDB CppDB library: Sql Connectivity library currently not Boostified, released and actively maintained. http://cppcms.sourceforge.net/sql/cppdb/index.html How much interest in this library as-is with small obvious modifications like using Boost Namespace Boost.SharedObject: Simple Shared Object class for loading DLLs/SO - i.e. cross platfrom dlopen/dlclose + naming (libfoo.3.dylib/libfoo.so.3/foo-3.dll) http://cppcms.sourceforge.net/cppcms_ref_v0_99/classbooster_1_1shared__obje… Any interest in this simple class? Boost.StackTrace Collecting stack trace automatically from exception and printing it. Very Very useful for debugging. http://cppcms.sourceforge.net/cppcms_ref_v0_99/namespacebooster_1_1stack__t… http://cppcms.sourceforge.net/cppcms_ref_v0_99/backtrace_8h_source.html Any interest in this library. It works (collects a trace and prints it) on: Windows, Solaris, Linux, Mac OS X Boost.NoWide Standard C and C++ library UTF-8 friendly API for windows classes/functions: boost { nowide { [of]stream - iostreams with UTF-8 file names f(re)open - FILE * functions with UTF-8 file names remove, rename- UTF-8 parameters getenv,putenv - UTF-8 environment variables args - UTF-8 argc, argv } } Under non windows just (using std::...) These functions (like Boost.Locale) all are parts of CppCMS C++ Web framework. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

17 43

[build] How to build a multi version non-header-library
by Vicente J. Botet Escriba 18 Jan '12

18 Jan '12

Hi, I want to provide two versions for Boost.Thread, one using Boost.Chrono and the other not. Boost.Thread is a non-header-only library so I guess that I need to build two libraries with different names. Is there already a library in Boost in the same context on which I can base my build design? What is the simples way to do this with Boost.build? Any pointers to the doc? Thanks in advance, Vicente

2 2

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 18 Jan '12

18 Jan '12

Hi, Sorry for the late reply. On 1/10/2012 11:01 AM, Topher Cooper wrote: > > On 1/10/2012 1:37 AM, Adrian Michel wrote: >> The way I see it, the only common point between different optimization >> algorithms (if they are generic enough) is the objective function, >> which should have a very simple prototype: >> >> double f( std::vector< double> ); >> >> so in theory if different algorithms are implemented to accept the >> same types (in C++ sense) of objective functions, then you could run >> them interchangeably between GA, DE etc without any modification to >> the function or algorithm. > > That ignores multi-objective optimization. In that case the return type > would be, at a minimum std:vector<double>, and might require information > on what characteristics are maximized. > ... > The points you raised make sense, but I think they go beyond the intended scope of this initial release. Unlike many other boost libraries whose main purpose is to enhance the language, DE is intended almost exclusively for solving domain specific problems. Because DE can be applied in many areas, by developers with a variety of requirements and levels of knowledge, I believe taking an iterative approach based on users' feedback will increase the chances of creating a library that's useful in solving real problems. As I mentioned before, this is an initial implementation. Some of the features I intend to add in a later release are: - multi-objective optimization - constraint functions (as opposed to just plain boundary constraints) - design centering ("Design centering is a constraint satisfaction problem whose goal is to find the solution, which, when perturbed, remains feasible more often than any other solution") and others. But these features are not trivial, and it would help me to get a sense of how the library is used before I start working on them. So far, I have received several good suggestions, I would like to nail down a list of specific additional requirements that this library needs to meet before moving on to the next step (and I'm not sure what that may be). Please let me know how to proceed. Adrian www.tradery.com

1 0

Re: [boost] Proposal for a Differential Evolution C++library
by Adrian Michel 18 Jan '12

18 Jan '12

On 1/10/2012 1:32 AM, Graham, Jeff wrote: > > I can help test on i686, amd64 and arm9 running linux. > Great, thanks! Can you please download the library from http://www.amichel.com/de/de.zip and try to build it? Let me know if you need help or have any questions. Best, Adrian www.tradery.com

1 0

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 18 Jan '12

18 Jan '12

On 1/11/2012 11:29 AM, Simonson, Lucanus J wrote: >The DE library description needs to be > very clear that it is for non-linear numerical optimization. I'm also > curious about how it compares industrial solvers like CPLEX. That is what I > had in mind when I said "good". It may be DE is one of the best ways to > solve a class of problems for which we don't know of a good way. There is > no point arguing about it in subjective terms, however. Instead, > quantifying how big of a problem it can handle in how many compute hours and > then providing a reference comparison to other solvers for other classes of > problem will put it into context and people will understand easily that it > is what it is and be able to tell if it is right for their problem or not. > There are people who may need it and not know it. There are people who may > need something else and not know it. The documentation should help both types of people. > Noted. In general I prefer to link to other sources that deal with the subject in much greater detail, but I can certainly add more information to help first time readers get a sense of why this library may be useful to them. > As far as design goes I would say that you want to split it into generic > genetic algorithm engine and a module for performing DE mutations. The GA > and DE-mutation modules would be configured separately and then composed to > produce the solution. That means you need to define an interface between > the GA and DE modules, but once you do that then you are able to easily swap > out GA engines or apply different mutation modules to achieve different GA > algorithms. I don't think that the mutation module needs to couple to > anything to do with the objective function at all. If someone wants to plug > in their HADOOP powered genetic algorithm instead of using the library > provided one then they would just use the DE mutations module. Alternately > they could use ASIO to build their own distributed GA module based on the > one provided by the library. There are already several policy components to allow user customization of DE, one of them being the "Mutation Policy" component. Does this address your suggestion, or are you referring to something even more general than that? Thanks, Adrian www.tradery.com

1 0

[config] How to use on Mac with C++11 dialect?
by John M. Dlugosz 17 Jan '12

17 Jan '12

I've asked this on Boost-User and had no reply. Maybe someone here would know? Using the current Boost 1.48 and the current Clang for the Apple Macintosh, when the compiler is set to accept the C++11 dialect (that is, new "auto" usage, lambda functions, rvalue references, etc.) then Boost headers choke. So currently we can use either C++11 or Boost, but not both. I'm sure it's a matter of configuration, of telling Boost headers that the compiler is indeed supporting these constructs. Can someone please point out what needs to be done? Thanks, —John

3 2

Re: [boost] compile time parser generator
by Martin Bidlingmaier 16 Jan '12

16 Jan '12

I'm not sure it's possible to get a string literal in a template< char ... > class string; 'Literals transformation is redefined into two distinct phases: raw and cooked. A raw literal is a sequence of characters of some specific type, while the cooked literal is of a separate type. The C++ literal 1234, as a raw literal, is this sequence of characters '1', '2', '3', '4'. As a cooked literal, it is the integer 1234. The C++ literal 0xA in raw form is '0', 'x', 'A', while in cooked form it is the integer 10. Literals can be extended in both raw and cooked forms, with the exception of string literals, which can only be processed in cooked form. This exception is due to the fact that strings have prefixes that affect the specific meaning and type of the characters in question.' - source: wikipedia - http://en.wikipedia.org/wiki/C%2B%2B11#User-defined_literals . Parsing string literals with constexpr is described in this article: http://akrzemi1.wordpress.com/2011/05/11/parsing-strings-at-compile-time-pa… For building the parser generator I used compile time polymorphism. Each symbol in EBNF would be represented as a class. The interface each symbol defines looks like this: struct symbol { constexpr symbol( const_string str , unsigned int begin = 0 ); //for an implementation of const_string see the article I linked constexpr bool valid(); constexpr unsigned int end(); }; For example, a symbol that parses a single character 'a' looks like this: struct sym_a { constexpr sym_a( const_string str , unsigned int begin = 0 ) : m_end ( begin >= str.size() ? 0u - 1 : //invalid index str[ begin ] == 'a' ? begin + 1 : 0u - 1 ) { } constexpr bool valid() { return m_end != 0u - 1; } constexpr unsigned int end() { return m_end; } unsigned int m_end; }; constexpr sym_a s1( "a" ); constexpr sym_a s2( "b" ); static_assert( s1.valid() , "" ); static_assert( !s2.valid() , "" ); The source for my current version of the parser generator is appended. I've also created a simple calculator that can handle + and * (and will accept any digit sequence as number, including "00000"). Notice, that currently only char strings are completely supported, defining terminals and the opt< T > operator won't work with other literals. (I know I can improve this for terminals, but I'm not sure about opt< T >.) The source compiles with gcc 4.6 and c++11 turned on without errors. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

6 19

Re: [boost] boost threads: pthread mutex priority inheritance + patches
by Jason Newton 16 Jan '12

16 Jan '12

Ack, no discussion on this since I posted it back in July. In my opensuse packages, I apply the following patch to insure priority inheritence on mutexs. I had to go inside the mutex ctor to do the work. -Jason On Wed, Jul 27, 2011 at 5:40 PM, Jason Newton <nevion(a)gmail.com> wrote: > On Wed, Jul 27, 2011 at 4:48 PM, Jason Newton <nevion(a)gmail.com> wrote: > >> For the moment, the few lines that compose the mutex class are easily >> copied so that I can do my own business inside the constructor but I expect >> others will run into this problem down the line and this solution is a bit >> unsavory. Any better advice? >> > > Actually a private copy of mutex didn't work so well overall as pthread > conditions are hard coded to > void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) > > -Jason >

2 1

"protected" APIs
by Lorenzo Caminiti 16 Jan '12

16 Jan '12

Hello all, Boost.Closure (formerly, Boost.Local) needs to use some macros, types, etc that are currently marked private in Boost.ScopeExit: BOOST_SCOPE_EXIT_AUX_TAG boost::scope_exit::aux::undeclared ... So I will move these symbols from AUX/aux to another prefix/namespace. How shall the new prefix/namespace be named? These symbols should not go into the public API of ScopeExit because they should never be used by the end user. These symbols are only meant to be used by other parts of Boost so they should use some sort of "protected" prefix/namespace. For example, I could use "detail": "aux" for ScopeExit private API and "detail" for ScopeExit API that can be used within Boost but not by general users: BOOST_SCOPE_EXIT_DETAIL_TAG boost::scope_exit::detail::undeclared However, other Boost components already use "detail" for their private API (synonymous of "aux"). So, I could use "protected" instead: BOOST_SCOPE_EXIT_PROTECTED_TAG boost::scope_exit::protected_::undeclared What's the best convention to follow here? Thanks a lot. --Lorenzo

8 8

build error in Release branch
by Barend Gehrels 15 Jan '12

15 Jan '12

Hi, I get a build error in the release branch: .../release/tools/build/v2/build/project.jam:266: unbalanced parentheses I just looked for differences in Trunk and Release and indeed that line differs. I updated the file conform trunk, locally, and I can build now. I then get the message: warning: mismatched versions of Boost.Build engine and core warning: Boost.Build engine (bjam) is 2011.12.00 warning: Boost.Build core (at /home/barend/svn/boost/release/tools/build/v2) is 2011.04-svn So this might be my problem (not sure). However I'm normally using only one bjam, copying it to /usr/local/bin, but this time I cannot do that... Should I use different bjam's for Trunk/Release versions? Is this a known problem / will this be solved? Regards, Barend

2 2

[scope_exit] improvements
by Lorenzo Caminiti 15 Jan '12

15 Jan '12

Hello all, I've been working with Alex to make the following improvements to Boost.ScopeExit (as they were discussed during Boost.Local's review). The update docs: https://svn.boost.org/svn/boost/sandbox/closure/libs/scope_exit/doc/html/in… 1) It is possible to use variadic macros on compilers that support them: int r = 0, v = 0; BOOST_SCOPE_EXIT(&r, v) { r = v; } BOOST_SCOPE_EXIT_END To support compilers without variadics and for backward compatibility with previous ScopeExit versions, all macros also accepts pp-sequences: BOOST_SCOPE_EXIT( (&r) (v) ) { r = v; } BOOST_SCOPE_EXIT_END 2) It is possible to capture no variable using `void`: BOOST_SCOPE_EXIT(void) { std::cout << "cout is a global variable << std::endl; } BOOST_SCOPE_EXIT_END This same syntax works on compilers with and without variadics. 3) From within member functions, it is possible to capture the object this using `this_`: BOOST_SCOPE_EXIT(&r, v, this_) { r = this_->f(v); } BOOST_SCOPE_EXIT_END On C++11, you can also (but you don't have to) use `this`: BOOST_SCOPE_EXIT(&r, v, this) { // C++11 only. r = this->f(v); } BOOST_SCOPE_EXIT_END 4) On C++11, you can (but you don't have to) use `;` instead of BOOST_SCOPE_END. 5) On C++11, there is an additional macro that allows to capture all variables using lambda-style `&` or `=`: BOOST_SCOPE_EXIT_ALL(&, v, this) { // C++11 only. r = this->f(v); }; Or equivalently: BOOST_SCOPE_EXIT_ALL(=, &r) { // C++11 only. r = this->f(v); }; I still have to move these changes from the sandbox into trunk. Comments are welcome. Thanks, --Lorenzo

2 1

[typeof] TYPEOF(this) on MSVC 7.1 and 8.0
by Lorenzo Caminiti 14 Jan '12

14 Jan '12

Hello all, BOOST_TYPEOF(this) generates error C2355 on MSVC 7.1 and 8.0 because of a MSVC bug. The code below was suggested to workaround the problem but it only works with native typeof. Is there a way to make BOOST_TYPEOF(this) work on MSVC 7.1 and 8.0 with Boost.Typeof in emulation mode? // Adam Butcher's workaround to deduce `this` type on MSVC revision < 10. // Boost.Typeof for VC71's typeid-based workaround does not work to determine // `this` type due to error C2355 being incorrectly reported. The typical // avoidance strategy implemented below is to make an indirect compile-time // constant by assigning an enum and use that as type-index-- this only works // with the sizeof() approach and not with the typeid() approach. This does not // work in typeof emulation mode. #if BOOST_WORKAROUND(BOOST_MSVC, >= 1300) && /* MSVC 7.1 */ \ BOOST_WORKAROUND(BOOST_MSVC, <= 1400) && /* MSVC 8.0 */ \ !defined(BOOST_TYPEOF_EMULATION) /* doesn't work in typeof-emu mode */ namespace boost { namespace scope_exit { namespace aux { namespace msvc_typeof_this { template<int Id> struct msvc_typeid_wrapper { typedef typename boost::type_of::msvc_extract_type<boost::mpl::int_<Id> >::id2type id2type; typedef typename id2type::type type; }; template<> struct msvc_typeid_wrapper<4> { typedef msvc_typeid_wrapper<4> type; }; template<typename T> struct encode_type { BOOST_STATIC_CONSTANT(unsigned, value = boost::type_of::encode_counter<T>::count); typedef typename boost::type_of::msvc_register_type<T, boost::mpl::int_<value> >::id2type type; BOOST_STATIC_CONSTANT(unsigned, next = value + 1); }; template<class T> struct sizer { typedef char(*type)[encode_type<T>::value]; }; template<typename T> typename boost::disable_if< typename boost::is_function<T>::type , typename sizer<T>::type >::type encode_start(T const&); template<typename T> typename boost::enable_if< typename boost::is_function<T>::type , typename sizer<T>::type >::type encode_start(T&); template<typename Organizer, typename T> boost::type_of::msvc_register_type<T, Organizer> typeof_register_type(const T&, Organizer* = 0); } } } } #define BOOST_SCOPE_EXIT_AUX_TYPEDEF_TYPEOF_THIS_INDEX_(id) \ BOOST_PP_CAT(boost_se_thistype_index_, id) #define BOOST_SCOPE_EXIT_DETAIL_TYPEDEF_TYPEOF_THIS(id, new_type) \ enum { \ BOOST_SCOPE_EXIT_AUX_TYPEDEF_TYPEOF_THIS_INDEX_(id) = sizeof( \ *::boost::scope_exit::aux::msvc_typeof_this::encode_start(this)) \ }; \ typedef ::boost::scope_exit::aux::msvc_typeof_this::msvc_typeid_wrapper< \ BOOST_SCOPE_EXIT_AUX_TYPEDEF_TYPEOF_THIS_INDEX_(id) \ >::type new_type; #else // typeof(this) on other compilers are OK. #define BOOST_SCOPE_EXIT_DETAIL_TYPEDEF_TYPEOF_THIS(id, new_type) \ typedef BOOST_TYPEOF(this) new_type; #endif // typeof(this) For example: // within a member function BOOST_SCOPE_EXIT_DETAIL_TYPEDEF_TYPEOF_THIS(__LINE__, this_type); this_type obj = this; Thanks. --Lorenzo

1 0

[context] mini-review comments
by Jeffrey Lee Hellrung, Jr. 14 Jan '12

14 Jan '12

[Late, I know] [I'm going off http://ok73.ok.funpic.de/boost/libs/context/doc/html/index.html] [Apologies if these are just repeating previous comments!] How do you store the function and function arguments passed to the context constructor? Are they bundled into memory allocated by the stack allocator? I couldn't find it in the documentation, and whatever the answer, seems like something that should be mentioned. "The maximum number of arguments of *context-function* is defined by BOOST_CONTEXT_ARITY (default is 10) and might be changed." Hopefully you mean, more specifically, that BOOST_CONTEXT_ARITY might be *increased*. Also, consider using variadic templates if available? Great examples! Would it be possible to also show the expected output, just so the reader can verify that he or she understands what should be happening? Given that void pointers are used to communicate between contexts, I almost would've expected the context constructor to simply take a void (*)( void* ) argument and context::start to take a void* argument which would be passed to the function pointer. Can you elaborate on the rationale for the low-level interface for communicating between contexts while still providing a relatively high level interface for specifying the context function? The documentation for the stack allocator concept doesn't completely define the semantics of the size parameter of stack_allocator::allocate/deallocate. I presume it is the stack size in bytes, but that should be explicit in the documentation. And I presume allocate is only required to return a pointer to *at least* size bytes of free memory. Also, you don't mention alignment requirements; what are they? I'm somewhat surprised default_stacksize() always returns 256*1024. I think it might be safer to make this implementation-defined, but some minimum size (as with everything else in C++...). Also, strictly speaking, the documentation is incorrect. It reads "Defines a default stack size of 256 kB", but defalt_stacksize() doesn't define anything, it just returns a number. And this description is inconsistent with the remaining function descriptions. I would do: "Returns the default stack size, which is implementation-defined but at least 256 kB." In "Low level API (boost_fcontext_t)", s/stated/started/. Also, what's the magic number 262144? Oh, I see, 262144 = 256 * 1024...maybe the latter expression would be more intuitive? Again, I can guess what the output of the example would be, but would be helpful to have the expected output handy. Just a nitpick on member variable names. boost_fcontext_stack::ss_base/ss_limit: what does "ss" mean? boost_fcontext::fc_stack/fc_link: I presume the prefix "fc" is short for "fcontext", in which case, isn't it redundant? Normally I wouldn't be picky about member variable names but these are precisely the documented API. In "Rationale", you give "[o]ther low level APIs and their caveats"; I'm guessing these are, specifically, alternatives to boost_fcontext_t but are *deficient* in some respect. It might clear things up if you make that explicit, and further group "setjump()/longjmp()", "ucontext_t", and "Windows fibers" into a common heading. Overall, I think the documentation and interface are good. I didn't look at the implementation, but I did see that someone else did, so...I'm not too worried about a correct implementation. As long as there's a full suite of tests. I also didn't try to use the library, but now I'll have to find an excuse :) These are all relatively minor comments, and although I hope Oliver will address them, it won't hold up my approval of Boost.Context. - Jeff

3 7

[fusion] Getting the adapted structure's member names
by Andy Venikov 14 Jan '12

14 Jan '12

struct alien { std::string color_; std::string planet_; bool benevolent_; }; BOOST_FUSION_ADAPT_STRUCT( alien, (std::string, color_) (std::string, planet_) (bool, benevolent_) ) I know how I can get to the actual member values, i.e. I could check at<2>(anAlien) to see if I should run away or not. But what if I wanted to get to the member names? (In this example it would be "color_", "planet_" and "benevolent_") It could be very useful for example for serialization that stores not just values but also the names of the values. Printing structures to stdout for inspection would be a breeze too. Since BOOST_FUSION_ADAPT_STRUCT is a macro, surely the member names could be strigized and stored somewhere. Thanks, Andy.

2 1

__COUNTER__ vs __LINE__
by lcaminiti 13 Jan '12

13 Jan '12

Hello all, Many of Boost macro APIs PP_CAT symbols with either __LINE__ or __COUNTER__ to make them unique (MPL_STATIC_ASSERT, SCOPE_EXIT, etc). AFAIK, __LINE__ is C++03 standard while __COUNTER__ is only a MSVC extension. I think using __COUNTER__ instead of __LINE__ might allow to expand a macro multiple times on the same line... but a part from that: What's the reason for using __COUNTER__ on MSVC instead of just using __LINE__ for all compilers? Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-COUNTER-vs-LINE-tp4286398p4286398.… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 6

[Boost.Move] A few notes
by Dan Ivy 13 Jan '12

13 Jan '12

Hi, I was recently trying out Boost.Move and a few issues worth sharing surfaced: 1. It would be helpful to have configuration macros to force emulation mode, even on C++11 compilers, as well as to disable move semantics altogether (that is, the conversion operators to boost::rv& should be disabled, and move/forward should return lvalue-references. BOOST_RV_REF and friends should remain intact, so that overloads remain unique.) In many cases, the higher level semantics of a program are expected to be identical under all three configurations, so having a quick way to switch between them is useful during testing/debugging. 2. Boost.Move is a little bit too opaque, as it stands. What's really missing are Boost.Move-aware type traits. Things like add_rvalue_reference are often necessary to calcuate return types of move-aware generic functions, and so on. Whether this belongs in Boost.TypeTraits or Boost.Move is a separate question. Likewise, there should be type traits to calculate the return types of boost::move and, in particular, boost::forward. On C++11, the return type of forward<T> conincides with add_rvalue_reference<T>, but not so in emulation mode, hence the necessity for this trait. 3. For some reason, the emulated boost::move is written so it doesn't accept temporaries. This doesn't play too nicely with forwarding: Unavoidably on C++03, there has to be made a choice whether forwarding functions use non-const or const-qualified references (bad wording, but you get the point), where the former accepts modifiable lvalues and rejects temporaries, and the latter does the opposite (well, sort of). Boost.Move chooses the latter. This means that while BOOST_FWD_REF parameters accept temporaries, these temporaries are bound as lvalues, which pretty much defeats the purpose of the library (note that these temporaries aren't eligible for copy-elision, since they're bound to a reference.) While there's not much you can do about it on the callee-side, callers could use boost::move on the temporaries to force them into rvalue-refs. Only that they can't. This creates a somewhat confusing situation where forwarding functions are able to take temporaries, but they won't move them, while the only things that can actually be moved are lvalues... Ultimately, this is what I suggest: First of all, have boost::move accept temporaries. Secondly, seriously consider changing the definition of BOOST_FWD_REF(T) from const T& to T&, as this would acheive two desirable, IMO, goals:: a. Forwarding functions would accept modifiable lvalues (and keep them modifiable). b. Forwarding functions would REJECT temporaries, UNLESS they're passed through boost::move, which assures that they're treated as rvalues. A few notes on the implementation: 4. There are many one-liner functions floating around that aren't declared inline. This is a big-deal for less-capable compilers, such as Sun and older versions of GCC. In fact, they simply won't inline boost::move calls without it. 5. boost::rv<T> unconditionally inherits from T, with the assumption that it would never get instanciated for non-class types, since it is only ever used as a reference. This is a false assumption in general. In the context of overload-resolution, the compiler is allowed, though not required, to instanciate the types of function parameters, even if the best overload can be determined without doing this. Consider this move-aware, but not very useful vector class: #include <boost/move/move.hpp> template <typename T> struct vector { void push_back(const T&) {} void push_back(BOOST_RV_REF(T)) {} }; int main() { vector<int> v; v.push_back(123); } The last line of main could potentially instanciate rv<int>, breaking the program. And it does. Sun falls right into this trap. It doesn't take much to make it break on GCC either, for the same reason. Fortunately, the fix is trivial: specialize boost::rv correctly for non-class types. All comments refer to the 1.48 release. I don't know what's going on on trunk. HTH

5 14

Release 1.49
by Barend Gehrels 13 Jan '12

13 Jan '12

Hi, I did not see (m)any recent mail traffic on the list w.r.t. release 1.49. According to the Calendar it was to be merged last Monday (major changes) and next Monday (all changes). Is this planning still up-to-date? Thanks, Barend

2 2

[interprocess] Crash of singleton_module in Windows
by JOAQUIN M. LOPEZ MUÑOZ 13 Jan '12

13 Jan '12

Steps to reproduce the problem: * Create singleton_dll.dll. * Create singleton_exe.exe, which uses singleton_dll.dll. * Run. On exit, an access violation happens. Seemingly, the problem happens when two different singletons are created, one in the main executable and the other in a DLL. If both singletons are created in the same module everything's OK, though. Best regards, Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx

4 7

[bjam] if MSVC 7.1 or 8.0 compile-fail
by lcaminiti 13 Jan '12

13 Jan '12

Hello all, If there a way to program the following within a Jamfile? import testing ; if(MSVC 7.1 or MSVC 8.0) { # How do I program this? [ compile-fail native_tu_test.cpp native_tu1.cpp native_tu2.cpp : : : <define>BOOST_TYPEOF_NATIVE ] } else { [ run native_tu_test.cpp native_tu1.cpp native_tu2.cpp : : : <define>BOOST_TYPEOF_NATIVE ] } Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-bjam-if-MSVC-7-1-or-8-0-compile-fa… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[Boost.Variant] Parameterized Visitors
by Andy Jost 13 Jan '12

13 Jan '12

New poster. When I'm using Boost.Variant, I often want to pass additional parameters to a visitor. A common case is when the variant is a class member and I want to have access to other members (or even "this") in the visitor. I muddled through for a long time writing visitors with explicit constructors and data members to take whichever parameters I needed, but I finally got around to making this generic with Boost.Fusion and I love it. I'm wondering whether I should submit this for consideration as an addition to the Boost.Variant library and how. First a few questions: 1. Is there already an equivalent solution that I should be aware of? 2. Should this be considered for an addition to Boost? 3. If so, how do I begin the review process? 4. This is a small change (400 or so lines of code). Is there anyone willing to help with the logistics, testing, and/or documentation (perhaps in exchange for a credit in the docs)? Here's an example, which should be fairly self-explanatory: struct A {}; struct B {}; struct C {}; struct my_visitor1 : param_visitor<my_visitor1, bool> { result_type operator()(int, float, char, A) const {...} result_type operator()(int, float, char, B) const {...} result_type operator()(int, float, char, C) const {...} }; struct my_visitor2 : fused_param_visitor<my_visitor2, bool> { template<typename Sequence> result_type operator()(Sequence const &, A) const {...} ... }; int main() { boost::variant<A,B,C> abc; boost::apply_visitor(my_visitor1().tie(1, 3.14, 'k'), abc); boost::apply_visitor(my_visitor2().tie(1, 3.14, 'k'), abc); return 0; } In terms of technical detail, there's not much to it. The base classes provide tie() and load() methods to take arguments by reference or value, respectively. A call to one of those returns a helper object that contains a copy of the derived visitor and a fusion::vector of arguments. Visiting that causes the user-defined visitor to be called with all of the arguments. For parameter forwarding, I use an implementation of perfect forwarding based on boost/flyweight/detail/dyn_perfect_fwd.hpp (I used a default limit of 4 parameters). Thanks, Andy

2 2