- Boost - lists.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