March 2010 - Boost - lists.preview.boost.org

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

Why no non-null smart pointers?
by Ross MacGregor 29 Apr '14

29 Apr '14

I just created a very small smart pointer libary for our project. It will contain two types of shared pointers: SharedHandle and NullableSharedHandle. SharedHandle will be a shared pointer that cannot be null by ensuring a non-null construction while NullableSharedHandle will basically be a typedef for boost::shared_ptr. I firmly believe that code can be made more reliable by minimizing the use of nullable pointers. To this end, I think it is important that we start using non-null pointer types. Ideally the compiler would be able to understand a non-null pointer and catch bugs at compile time, but I think we can still improve things with a few runtime checks. If we make sure that a shared pointer is constructed with a non-null pointer and ban any reset() type methods, we guarentee that it points to something. This can be beneficial for the following reasons: 1. Any function that uses this type will no longer be burdened with precondition checks to make sure variables of this type are not null. 2. It's type is simply more explicit and better explains its function. 3. Moving the non-null check to the creation phase will reduce the possibility of encountering null pointer exceptions at runtime (assuming there are many more pointer references than constructor calls). So my little pointer library seems to make a lot of sense, but if so why hasn't this simple smart pointer variation made it into boost yet? Has this been discussed somewhere already? My search on non-null smart pointers is not revealing much discussion on the topic. Regards, Ross

9 16

[#pragma once]
by Sid Sacek 18 Nov '12

18 Nov '12

I've worked with the MSVC, Sun and GCC compilers. Each one of them supports #pragma once. Is there any reason to wrap this pragma within #ifdefs? Are there any compilers out there today that don't support this #pragma? #if defined( _MSC_VER ) && ( _MSC_VER >= 1020 ) # pragma once #endif Could we change this coding pattern so that it no longer looks like MSVC is being selfish? -Sid Sacek

17 20

[interprocess] message_queue hangs when another process dies
by Sergei Politov 03 Nov '11

03 Nov '11

Hi, I have found the following problem with message_queue on win32 (MSVC 2008 + Windows Vista). Suppose we have 2 processes, one sends messages to queue, another reads them. When reading process dies (for instance using End process) during message_queue.receive the another process hangs in send. As I found during investigation, it tries to lock interprocess mutex, but it is already locked by dead process. So this message queue instance becomes unusable. I attached the example. Steps to reproduce: 1) Start "mq.exe s" (i.e. with argument s) It outs: sender: $PID 2) Start mq.exe without arguments. It outs: receiver: $PID 0 1 2 3 4 This time sender outs: send done: 3) At this point the message queue is empty and receiver waits for messages. End it with Task Manager. 4) Enter some number in sender console and press Enter. 5) The sender hangs in message_queue.send Best Regards, Sergei

6 13

Re: [boost] [date_time] Time zone improvements
by Rutger ter Borg 25 May '11

25 May '11

Jeff Garland wrote: > Very cool :-) One question -- is there a portable solution where a user > could deploy a files onto a Windows system or is it a Unix only solution? > I'm fine with incorporating a *nix only solution because what your > suggesting will be a nice solution for *nix platforms, but it will need to > be clear that it's not portable. I don't see why it wouldn't be possible to deploy the (big-endian) binary files to any platform. Getting it into this binary form (using zone info compiler zic) may be harder to do cross-platform, but cygwin may help here. [snip] > As the primary maintainer of Boost date-time I can say with certainty that > there is interest in this functionality -- it's long been on my todo list > and I haven't had time to get to it. You can email me privately and we > can discuss all the details of how to get your code incorporated. I'll do! Regards, Rutger

5 9

[serialization] boost/serialization/path.hpp
by Johan Råde 21 Feb '11

21 Feb '11

There is no boost/serialization/path.hpp. I suggest the following: ---------------------------------------------------------------------------------------------------------------- #ifndef BOOST_SERIALIZATION_PATH_HPP #define BOOST_SERIALIZATION_PATH_HPP // MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) #pragma once #endif #include <boost/config.hpp> #include <boost/filesystem/path.hpp> #include <boost/serialization/level.hpp> BOOST_CLASS_IMPLEMENTATION(boost::filesystem::path, boost::serialization::primitive_type) #ifndef BOOST_NO_STD_WSTRING BOOST_CLASS_IMPLEMENTATION(boost::filesystem::wpath, boost::serialization::primitive_type) #endif namespace boost { namespace serialization { template<class Archive, class String, class Traits> void serialize(Archive& ar, boost::filesystem::basic_path<String, Traits>& p, const unsigned int version) { String s; if(Archive::is_saving::value) s = p.string(); ar & boost::serialization::make_nvp("string", s); if(Archive::is_loading::value) p = s; } }} #endif //-------------------------------------------------------------------------------------------------------------- Comments? Any suggested improvements? --Johan Råde

5 11

[C++0x] Emulation of scoped enums
by Beman Dawes 16 Feb '11

16 Feb '11

The improved type safety of the C++0x scoped enum feature is attractive, so I'd like to start using it as it becomes available in compilers. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a description. Note that the committee changed the name from strongly typed enums to scoped enums. See the attached for a boost/detail header that provides macro wrappers that use scoped enums if available, otherwise fall back on C++03 namespaces and unscoped enums. It lets a library write: BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END ... BOOST_SCOPED_ENUM(algae) sample( algae::red ); void func(BOOST_SCOPED_ENUM(algae)); and then a user can write: sample = algae::green; func( algae::cyan ); Comments or suggestions appreciated, --Beman // scoped_enum_emulation.hpp ---------------------------------------------------------// // Copyright Beman Dawes, 2009 // Distributed under the Boost Software License, Version 1.0. // See http://www.boost.org/LICENSE_1_0.txt // Generates C++0x scoped enums if the feature is present, otherwise emulates C++0x // scoped enums with C++03 namespaces and enums. The Boost.Config BOOST_NO_SCOPED_ENUMS // macro is used to detect feature support. // // Caution: only the syntax is emulated; the semantics are not emulated and // the syntax emulation doesn't include being able to specify the underlying type. // // See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a // description of the feature. Note that the committee changed the name from // strongly typed enums to scoped enums. // // Sample usage: // // BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END // ... // BOOST_SCOPED_ENUM(algae) sample( algae::red ); // void foo( BOOST_SCOPED_ENUM(algae) color ); // ... // sample = algae::green; // foo( algae::cyan ); #ifndef BOOST_SCOPED_ENUM_EMULATION_HPP #define BOOST_SCOPED_ENUM_EMULATION_HPP #include <boost/config.hpp> #ifndef BOOST_NO_SCOPED_ENUMS # define BOOST_SCOPED_ENUM_START(name) enum class name # define BOOST_SCOPED_ENUM_END # define BOOST_SCOPED_ENUM(name) name #else # define BOOST_SCOPED_ENUM_START(name) namespace name { enum enum_t # define BOOST_SCOPED_ENUM_END } # define BOOST_SCOPED_ENUM(name) name::enum_t #endif #endif // BOOST_SCOPED_ENUM_EMULATION_HPP

14 27

[process] How to run test cases
by Boris 23 Jan '11

23 Jan '11

As Boost.Process 0.3 has been released it would be great if the test cases are run on various platforms. So far I've tested Boost.Process on WinXP with MSVC 9.0, Cygwin with g++ 3.4.4 and Solaris with g++ 3.4.6 and Sun C++ 5.9. To make it as easy as possible for others to run the test cases here's a short description of how to proceed. Nearly all test cases depend on a program called "helpers". This program is built first and is started by many test cases as a child process. In order to find the program "helpers" the test cases must know its location. As there is no way to get the location at runtime it is hardcoded in the file libs/process/test/misc.hpp. As the location differs depending on what compiler is used YOU MUST CHECK FIRST THE PATH IN libs/process/test/misc.hpp! Otherwise most of the test cases will fail as they look for a program "helpers" in the wrong directory. As of today only those paths are correct and have been tested which are set for Windows, Cygwin and Solaris. Only after you have checked and maybe updated the path in libs/process/test/misc.hpp you should try to build and run the test cases: WinXP/MSVC 9.0 ************** With MSVC 9.0 you only need to open the Visual Studio 2008 Command Prompt, change to the directory with the test cases and run bjam: C:\boost_1_36_0\libs\process\test> ..\..\..\bjam.exe -q Cygwin/GCC 3.4.4 **************** On Cygwin it's important to know if the Boost libraries have been built for the POSIX or Windows API. By default Boost libraries on Cygwin use the Windows API. With the Windows API the Boost.Process test cases are not passed successfully though (there are compiler errors where I'm not sure currently if they are a Boost.Process problem and how they could be fixed). If you want to run the test cases on Cygwin you must (re-)build the Boost libraries to use the POSIX API: $ cd ~/boost_1_36_0 $ ./bjam cxxflags=-DBOOST_POSIX_API Afterwards you can run the test cases: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam cxxflags=-DBOOST_POSIX_API -q Solaris/GCC 3.4.6 ***************** At first you have to put the following line in ~/user-config.jam: using gcc : : : <linker-type>sun ; Then start building the Boost libraries: $ cd ~/boost_1_36_0 $ ./bjam --toolset=gcc cxxflags=-mcpu=ultrasparc For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. Afterwards the test cases can be run: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=gcc cxxflags=-mcpu=ultrasparc -q Solaris/Sun C++ 5.9 ******************* Build the Boost libraries with the sun toolset: $ cd ~/boost_1_36_0 $ ./bjam --toolset=sun stdlib=sun-stlport For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. If you run the test cases now you'll get this compiler error for one test case: "../../../boost/asio/detail/socket_ops.hpp", line 218: Error: Cannot assign void* to char*. "../../../boost/asio/detail/socket_ops.hpp", line 229: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 66: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 72: Error: Cannot assign void* to char*. The bug has been reported to the Boost.Asio mailing list. If you want to build that one test case, too, you need to fix the two files in Boost.Asio 1.36.0 yourself. All the test cases can be built and run with: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=sun stdlib=sun-stlport -q

4 9

[SoC] BGL project idea
by Gautam Sewani 03 Jan '11

03 Jan '11

Hi, I am a Computer Science student hoping to contribute to Boost for this year's summer of code. I had a few questions regarding the BGL project idea (https://svn.boost.org/trac/boost/wiki/SoC2010#Boost.Graph) for SOC 2010. 1. I can think of only a few places where the suggested algorithms will be used. Does the community think that these algorithms are used frequently enough to put them in a library? How important does the community consider this project? 2. Will the project proposal be expected to include the API design? Thanks and Regards Gautam

5 29

boost::thread compiler error on SUN CC 5.9
by Urs Stotz 08 Jun '10

08 Jun '10

boost::thread give a compile error on SUN CC 5.9: /opt/SUNWspro/bin/CC +d -library=stlport4 -library=stlport4 -xcode=pic32 -erroff=wvarhidemem,hidevf,hidevfinvb -errtags=yes -features=tmplife -features=tmplrefstatic -g -mt -erroff=%none -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -I"." -c -o "bin.v2/libs/thread/build/sun-5.9/debug/stdlib-sun-stlport/threading-multi/pthread/thread.o" "libs/thread/src/pthread/thread.cpp" "libs/thread/src/pthread/thread.cpp", line 77: Error, badbinaryop: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> && void*" is illegal. "libs/thread/src/pthread/thread.cpp", line 588: Error, badbinaryop: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> || void*" is illegal. 2 Error(s) detected. make: *** [thread.o] Error 2 with this small patch it will compile: --- boost_1_42_0.org/libs/thread/src/pthread/thread.cpp 2009-10-19 11:18:13.000000000 +0200 +++ boost_1_42_0/libs/thread/src/pthread/thread.cpp 2010-02-10 13:48:25.037748000 +0100 @@ -74,7 +74,7 @@ namespace boost { current=next; ++next; - if(current->second.func && current->second.value) + if(current->second.func && (current->second.value != 0)) { (*current->second.func)(current->second.value); } @@ -585,7 +585,7 @@ namespace boost { (*current_node->func)(current_node->value); } - if(func || tss_data) + if(func || (tss_data != 0) ) { current_node->func=func; current_node->value=tss_data;

3 2

safe bool operator
by Domagoj Saric 18 May '10

18 May '10

While examining source and binary code for the various safe_bool/unspecified_bool_type implementations two issues can be noticed: - source code verbosity/repetition - binary code inefficiency The first issue is made worse by the fact that even this simple idiom is broken on some compilers ('pointed out' by workarounds in smart_ptr/detail/operator_bool.hpp) so workarounds must also be copied/'rediscovered'... The second issue (related to the usual implementation with member function pointers) has two sides, one is that taking the address of a function will force it to be included in the resulting binary even if it is never used or is always inlined and the second is that some compilers produce non-optimal code. For example for the following source code: boost::optional<int> test1; boost::optional<int> test2; __declspec( noinline ) void func() { if ( test1 ) test2 = *test1; } MSVC++ 8.0 and 9.0 will produce the following binary code ... 0F923A26 movzx eax,byte ptr [test1 (0F968210h)] 0F923A2D neg eax 0F923A2F sbb eax,eax 0F923A31 test eax,offset boost::optional_detail::optional_base<int>::is_initialized (0F923B9Eh) 0F923A36 je ... ... but if the if line is changed to if ( test1.is_initialized() ) the following code will be produced: ... 0F923A26 cmp byte ptr [test1 (0F968210h)],0 0F923A2D je ... ... At first I tried a solution that takes advantage of the fact that MSVC++ has plain-pointer-sized/register-sized member function pointers for plain single inheritance non virtual member functions and worked properly but than I found old discussions about the same subject: http://lists.boost.org/Archives/boost/2003/09/52846.php http://lists.boost.org/Archives/boost/2002/10/38624.php where the solution for MSVC++ was to use a pointer member data which gives the same results as my initial solution... Anyways I've attached a .hpp file with a draft implementation proposal (missing the compiler workarounds from smart_ptr/smart_ptr/detail/operator_bool.hpp for example) that uses both approaches... It enables a one liner implementation for a safe_bool operator: class my_class { public: bool some_is_valid_function() const; operator boost::unspecified_bool_type() const { return boost::make_safe_bool( some_is_valid_function() ); } //or by using a macro BOOST_SAFE_BOOL_FROM_FUNCTION( some_is_valid_function() ) } -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman begin 666 safe_bool.hpp M(W!R86=M82!O;F-E#0HC:69N9&5F('-A9F5?8F]O;%]H<' -"B-D969I;F4@ M<V%F95]B;V]L7VAP< T*+R\M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2T-"B-I;F-L=61E(")M<&PO8F]O;"YH<' B#0HO+RTM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0T*;F%M97-P86-E(&)O;W-T#0I[#0HO M+RTM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0T*#0IN86UE<W!A M8V4@9&5T86EL#0I[#0H@(" @<W1R=6-T('5N<W!E8VEF:65D7V)O;VQ?='EP M95]H96QP97(-"B @("![#0H@(" @(" @('9O:60@;65M8F5R7V9U;F-T:6]N M*"D@>WT[#0H@(" @(" @(&EN="!M96UB97)?9&%T85\[#0H@(" @?3L-"@T* M(" @('1Y<&5D968@=F]I9" H=6YS<&5C:69I961?8F]O;%]T>7!E7VAE;'!E M<CHZ*G5N<W!E8VEF:65D7V)O;VQ?='EP95]F=6YC=&EO;BD@*"D[#0H@(" @ M='EP961E9B!I;G0@("!U;G-P96-I9FEE9%]B;V]L7W1Y<&5?:&5L<&5R.CHJ M=6YS<&5C:69I961?8F]O;%]T>7!E7V1A=&$@(" @(" @(#L-"@T*(" @('5N M:6]N(&9A<W1?<V%F95]B;V]L#0H@(" @>PT*(" @(" @("!U;G-I9VYE9"!L M;VYG(" @(" @(" @(" @(" @(" @<&QA:6Y?<&]I;G1E<E]P;&%C96AO;&1E M<CL-"B @(" @(" @=6YS<&5C:69I961?8F]O;%]T>7!E7V9U;F-T:6]N('!O M:6YT97)?=&]?;65M8F5R(" @(" @(" [#0H@(" @?3L-"@T*(" @("\O(" @ M270@:7,@87-S=6UE9"!T:&%T(&EF('1H92!C;VUP:6QE<B!I<R!A8FQE('1O M(&9I="!A('!L86EN+"!S:6YG;&4-"B @(" O+R!I;FAE<FET86YC92!M96UB M97(@9G5N8W1I;VX@<&]I;G1E<B!I;G1O('-I>F5O9B@@=F]I9" J("D@=&AA M="!I=',@;G5L; T*(" @("\O(&)I;F%R>2!R97!R97-E;G1A=&EO;B!I<R!I M9&5N=&EC86P@=&\@82!P;&%I;B!N=6QL('9O:60@<&]I;G1E<B H86QL(&)I M=',-"B @(" O+R!Z97)O960I+B!7:71H;W5T(&$@=V%Y('1O(&-H96-K('1H M:7,@870@8V]M<&EL92!T:6UE('1H:7,@87-S97)T960@870-"B @(" O+R!R M=6YT:6UE+@T*(" @("\O(" @5&AE(&%B;W9E(&YE960@;F]T(&AO;&0@9F]R M(&1A=&$@;65M8F5R('!O:6YT97)S("AE+F<N($U35D,K*R!U<V5S("TQ#0H@ M(" @+R\@9F]R(&YU;&PM9&%T82!M96UB97(@<&]I;G1E<G,I+@T*(" @('1Y M<&5D968(a);7!L.CIB;V]L7SPH('-I>F5O9B@@9F%S=%]S869E7V)O;VP@*2 \ M/2!S:7IE;V8H('5N<VEG;F5D(&QO;F<@*2 I/B!C86Y?=7-E7V9A<W1?8F]O M;%]H86-K.PT*#0H@(" @='EP961E9B!M<&PZ.FEF7PT*(" @(" @(" @(" @ M/ T*(" @(" @(" @(" @(" @(&-A;E]U<V5?9F%S=%]B;V]L7VAA8VLL#0H@ M(" @(" @(" @(" @(" @=6YS<&5C:69I961?8F]O;%]T>7!E7V9U;F-T:6]N M+ T*(" @(" @(" @(" @(" @('5N<W!E8VEF:65D7V)O;VQ?='EP95]D871A M#0H@(" @(" @(" @(" ^.CIT>7!E('5N<W!E8VEF:65D7V)O;VQ?='EP93L- M"@T*(" @(&EN;&EN90T*(" @('5N<W!E8VEF:65D7V)O;VQ?='EP92!M86ME M7W-A9F5?8F]O;%]W;W)K97(H(&)O;VP@8V]N<W0@=F%L=64L(&UP;#HZ=')U M95\@+RIU<V4@9F%S="UH86-K('9E<G-I;VXJ+R I#0H@(" @>PT*(" @(" @ M("!F87-T7W-A9F5?8F]O;"!C;VYS="!F87-T4V%F94)O;VP@/2![('9A;'5E M('T[#0H@(" @(" @(&%S<V5R= T*(" @(" @(" H#0H@(" @(" @(" @(" H M("$A9F%S=%-A9F5";V]L+G!O:6YT97)?=&]?;65M8F5R(#T]("$A=F%L=64@ M*2 F)@T*(" @(" @(" @(" @(E1H92!V;VED+7!O:6YT97(M<VEZ960@;65M M8F5R('!O:6YT97(@;G5L;"!B:6YA<GDB#0H@(" @(" @(" @(" B<F5P<F5S M96YT871I;VX@87-S=6UP=&EO;B!D;V5S(&YO="!H;VQD(&9O<B!T:&ES(@T* M(" @(" @(" @(" @(F-O;7!I;&5R+W!L871F;W)M+B(-"B @(" @(" @*3L- M"B @(" @(" @<F5T=7)N(&9A<W13869E0F]O;"YP;VEN=&5R7W1O7VUE;6)E M<CL-"B @("!]#0H-"B @("!I;FQI;F4-"B @("!U;G-P96-I9FEE9%]B;V]L M7W1Y<&5?9G5N8W1I;VX-"B @("!M86ME7W-A9F5?8F]O;%]S=&%N9&%R9%]W M;W)K97(H(&)O;VP@8V]N<W0@8F]O;%]V86QU92P@=6YS<&5C:69I961?8F]O M;%]T>7!E7V9U;F-T:6]N(&-O;G-T(&YU;&Q?=F%L=64@*0T*(" @('L-"B @ M(" @(" @<F5T=7)N(&)O;VQ?=F%L=64@/R F=6YS<&5C:69I961?8F]O;%]T M>7!E7VAE;'!E<CHZ;65M8F5R7V9U;F-T:6]N(#H@;G5L;%]V86QU93L-"B @ M("!]#0H@(" @:6YL:6YE#0H@(" @=6YS<&5C:69I961?8F]O;%]T>7!E7V1A M=&$-"B @("!M86ME7W-A9F5?8F]O;%]S=&%N9&%R9%]W;W)K97(H(&)O;VP@ M8V]N<W0@8F]O;%]V86QU92P@=6YS<&5C:69I961?8F]O;%]T>7!E7V1A=&$@ M(" @(&-O;G-T(&YU;&Q?=F%L=64@*0T*(" @('L-"B @(" @(" @<F5T=7)N M(&)O;VQ?=F%L=64@/R F=6YS<&5C:69I961?8F]O;%]T>7!E7VAE;'!E<CHZ M;65M8F5R7V1A=&%?(" @(#H@;G5L;%]V86QU93L-"B @("!]#0H-"B @("!I M;FQI;F4-"B @("!U;G-P96-I9FEE9%]B;V]L7W1Y<&4@;6%K95]S869E7V)O M;VQ?=V]R:V5R*"!B;V]L(&-O;G-T('9A;'5E+"!M<&PZ.F9A;'-E7R O*G5S M92!S=&%N9&%R9"!V97)S:6]N*B\@*0T*(" @('L-"B @(" @(" @<F5T=7)N M(&UA:V5?<V%F95]B;V]L7W-T86YD87)D7W=O<FME<B@@=F%L=64L('5N<W!E M8VEF:65D7V)O;VQ?='EP92@@," I("D[#0H@(" @?0T*?2 O+R!N86UE<W!A M8V4@9&5T86EL#0H-"@T*='EP961E9B!D971A:6PZ.G5N<W!E8VEF:65D7V)O M;VQ?='EP92!U;G-P96-I9FEE9%]B;V]L7W1Y<&4[#0H-"@T*:6YL:6YE#0IU M;G-P96-I9FEE9%]B;V]L7W1Y<&4@;6%K95]S869E7V)O;VPH(&)O;VP@8V]N M<W0@=F%L=64@*0T*>PT*(" @(')E='5R;B!D971A:6PZ.FUA:V5?<V%F95]B M;V]L7W=O<FME<B@@=F%L=64L(&1E=&%I;#HZ8V%N7W5S95]F87-T7V)O;VQ? M:&%C:R@I("D[#0I]#0H-"B\O($EF('=E(&-O=6QD('5S92!M96UB97(@<&]I M;G1E<G,@8F5F;W)E('1H92!M96UB97(@:7,@86-T=6%L;'D@9&5C;&%R960O M<V5E;@T*+R\@=V4@8V]U;&0@=7-E($-25% M8F%S960@:&5L<&5R(&-L87-S M97,@9F]R(&UI;FEM=6T@=F5R8F]S:71Y('-A9F5?8F]O; T*+R\@:6UP;&5M M96YT871I;VYS.@T*+R\@=&5M<&QA=&4@/&-L87-S($)A<V4L(&)O;VP@*$)A M<V4Z.BIB;V]L7V9U;F-T:6]N*2 H*2!C;VYS=#X-"B\O(&-L87-S('-A9F5? M8F]O; T*+R\@>PT*+R\@(" @(&]P97)A=&]R('5N<W!E8VEF:65D7V)O;VQ? M='EP92@I(&-O;G-T('L@<F5T=7)N(&UA:V5?<V%F95]B;V]L*"!S=&%T:6-? M8V%S=#Q"87-E(&-O;G-T("H^*"!T:&ES("DM/BIB;V]L7V9U;F-T:6]N*"D@ M*3L@?0T*+R\@?3L-"B\O#0HO+R!C;&%S<R!M>5]C;&%S<R Z('!U8FQI8R!S M869E7V)O;VP\;7E?8VQA<W,L("9M>5]C;&%S<SHZ=F%L:60^#0HO+RXN+@T* M#0HO+RXN+FEN<W1E860@=V4@87)E(&QE9G0@=VET:"!M86-R;W,N+BX-"B-D M969I;F4@0D]/4U1?4T%&15]"3T],7T923TU?1E5.0U1)3TXH(&-O;G-T365M M8F5R1G5N8W1I;VX@*2!<#0H@(" @;W!E<F%T;W(@8F]O<W0Z.G5N<W!E8VEF M:65D7V)O;VQ?='EP92@I(&-O;G-T('L@<F5T=7)N(&)O;W-T.CIM86ME7W-A M9F5?8F]O;"@@8V]N<W1-96UB97)&=6YC=&EO;B@I("D[('T-"@T*(V1E9FEN M92!"3T]35%]3049%7T)/3TQ?1E)/35]$051!*" @(" @8V]N<W1-96UB97)$ M871A(" @(" I(%P-"B @("!O<&5R871O<B!B;V]S=#HZ=6YS<&5C:69I961? M8F]O;%]T>7!E*"D@8V]N<W0@>R!R971U<FX@8F]O<W0Z.FUA:V5?<V%F95]B M;V]L*"!C;VYS=$UE;6)E<D1A=&$@(" @(" @*3L@?0T*#0H-"B\O+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM#0I]("\O(&YA;65S<&%C92!B M;V]S= T*+R\M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2T-"B-E 7;F1I9B O+R!S869E7V)O;VQ?:'!P#0H` ` end

7 9

[GSoC] Helping out Phoenix v3
by Joel Falcou 04 May '10

04 May '10

Joel and I pondered about getting a student from GSoC to help us complete the phoenix v3 port to proto. I currently have a few prototypes and ideas to extend it further but a few more hands are most welcome. Considering the schedule, I'll be compeltely free for mentoring this prospective student. Now, is it realistic and on topic for GSoC ?

9 33

Re: [boost] [repost][multiarray] Bug with boost::detail::multi_array::array_iterator on MSVC 2010RC?
by Thomas Klimpel 04 May '10

04 May '10

Jesse Perla wrote: > I have attached my test files. Any ideas or patches would be appreciated I could reproduce the problem with MSVC 2010beta2. I noticed that only the debug version fails to build. So I added the line #define _HAS_ITERATOR_DEBUGGING 0 and everything compiled fine. So the simplest solution is to add ADD_DEFINITIONS(-D_HAS_ITERATOR_DEBUGGING=0) to your CMakeLists.txt, which many people recommend in any case, because they claim that the debug version under MSVC would otherwise violate the "runtime complexity specifications" of the corresponding containers and iterators. (I don't know whether this is really true, but I really think that this workaround is not unreasonable.) But of course, you want to know whether this is a bug in boost::multi_array or a bug in MSVC 2010beta2. Before we come to that, another "workaround" would be to change multi_array/iterator.hpp:56 for , boost::random_access_traversal_tag to , std::random_access_iterator_tag This will most probably work, but would lying to the standard library, because the reference reference type of the corresponding iterator is not value_type& (but a proxy): http://lists.boost.org/boost-users/2006/11/23565.php What effectively happens it that the iterator gets the category "input_iterator", but std::copy wants to have an "output_iterator". I think I understand why the iterator doesn't satisfies the requirement of a "forward_iterator", but it's unclear to me why it didn't qualify as an "output_iterator". There is an "input_output_iterator_tag" in "boost/iterator/detail/facade_iterator_category.hpp", so it would have been possible for the iterator to be both "input_iterator" and "output_iterator". However, it seems to me that "input_output_iterator_tag" is never used in the Boost.Iterator library. I would have to read more about "output_iterator" to understand whether Boost.Iterator is correct here. With my current understanding of "output_iterator", I would say it's a bug in "boost/iterator/detail/facade_iterator_category.hpp". Perhaps somebody with more knowledge about "output_iterator" and Boost.Iterator can explain to me why an iterator using the "boost::random_access_traversal_tag" for the "CategoryOrTraversal" template parameter of "iterator_facade" will never get the category "output_iterator" (or "input_output_iterator_tag"). Regards, Thomas

4 6

Help with VeecoFTC - exception - cloning_test / msvc-9.0~wm5~stlport5.2
by Emil Dotchevski 24 Apr '10

24 Apr '10

Can someone help me figure out what's going on here: http://tinyurl.com/ybpbsp4 Thanks! Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

3 5

[RangeEx] Where is the current version?
by Mathias Gaunard 19 Apr '10

19 Apr '10

Where is the current version (or a fairly recent version) of RangeEx? I can't find anything on the trunk, the sandbox or the vault.

5 13

[asio] read_until -- possibly misleading documentation?
by Richard Smith 15 Apr '10

15 Apr '10

The documentation for Boost.ASIO (which is otherwise very comprehensive) says of the boost::asio::read_until set of overloads: | Read data into a streambuf until a delimiter is | encountered. <http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/reference/read_unt…> What the function actually does is to read blocks of data into the streambuf, and stop when the delimiter is found. This means that frequently data beyond the delimiter will be read into the streambuf. (And this is elaborated in more detail on the individual function's pages, if a reader looks there.) I appreciate that this behaviour is compatible with the documentation, but someone less familiar with ASIO could easily assume that the function will read as far as the delimiter and no further. (And I have just spent a fair amount of time debugging a piece of code where the author had made this assumption.) Could we change the summary documentation to read something like: | Read data into a streambuf at least until a delimiter is | encountered. The implementation may read beyond the | delimiter, but will not block when doing so. While I'm on the subject of ASIO documentation, I can't see any documentation on whether the service_name parameters to the basic_resolver_query constructors are allowed to be port numbers (e.g. "80") or whether they have to be symbolic names (e.g. "http"). Port numbers work, at least on Linux, but it's not clear whether this is something that I should be relying on. Similarly for IPv4 and IPv6 addresses in the host_name parameter. Richard Smith

3 2

Guidelines on wiki
by Daniel James 13 Apr '10

13 Apr '10

Hello, I've copied the guidelines onto the wiki now, you can see them at: https://svn.boost.org/trac/boost/wiki/Guidelines/ Any comments? I've changed the beta site to redirect to them. I haven't linked to them from the front page of the wiki as they aren't 'official' yet. I'll be moving more pages over soon-ish. Any ideas about how the wiki should be structured? Daniel

5 10

GSOC 2010 - BGL Graph Connectives.
by Tri Nguyen 12 Apr '10

12 Apr '10

Hi, I am Tri Nguyen from South Plains College. I am interested in Graph Connectives Project of BGL. In this writing, I would like to ask two questions, and then propose my idea of doing four Connectives: union, join, intersection, and difference. My first question is: How big is the graph? Or students will try to do as big as possible. My second question is: What type of data-structures (matrix or list) will be used? I attached my ideas in the PDF file below. Please have a look. I appreciate all responses, Thank you, Tri Nguyen.

4 15

GSoC2010 Sweepline Algorithm
by Andriy Sydorchuk 12 Apr '10

12 Apr '10

Hi, Boost Community! I am interested in participation in GSoC 2010. The project I liked the most is the generic implementation of Sweepline Algorithm. Basically fast and robust Sweepline Algorithm requires implementation of next data structure: 1) Event Queue (priority queue). 2) Sweep Line (self-balancing binary search tree). 3) Output datastructures (voronoi vertices, triangulation edges, etc.). Based on that I got next questions: - Which kind of self-balancing binary trees is better for that kind of approach? I am thinking about Red-Black Trees in prefer to AVL trees, as sweepline algorithm requires more adding and deletion operations. And AVL trees are better for look up operations. - STL library includes two generic implementations of self-balancing binary trees (red-black): map, set. I am quite new with Boost library, but probably there are some more specific self-balancing binary tree implementations there? - For Voronoi diagram and delaunay triangulation input data is set of points. What about input of the Medial Axis problem? -- Best, Andrii Sydorchuk

4 33

[BGL] Revisiting Parallel BGL
by Sandeep Gupta 12 Apr '10

12 Apr '10

Hi, I raised the issue of parallel BFS not working correctly here http://lists.boost.org/boost-build/2009/10/22631.php. The issue remained unresolved. I revisited it for last two days and the incorrectness in likelihood is probably due to initialization of distance property map for all non-start vertex to be infinity. Hope this helps. Thanks Sandeep

3 17

[GSOC] summary of .BigInt library details.
by Ankit Malpani 12 Apr '10

12 Apr '10

hi all, thank you Scott McMurray, Vicente and Bruno for the prompt feedback regarding my proposed BigInt library ideas .(Sorry for the delayed reply as was busy with mid-semester exams.) In general this is what i have gathered from your responses regarding what exactly is being expected by the community from a BigInt library for Boost. 1. frontend based off Boost.Proto 2. backend implemented with the help of Boost libraries like Boost.Math. 3. probably provide two levels of implementations. ( although it would really help if you could weigh the pros and cons of both and eliminate one the the two) 3a. looking at bit-level implementation(less space and probably more execution time) 3b.) digit level manipulation (more space - and probably less execution time). i.e. for an n-digit number is it ok to use up [n/2 to n] bytes of space or necessary to stick to log n amount of space for a BigInt object. my questions are :- 1. Please give your feedback/concerns regarding the above design. 2. Any other libraries like Boost.Math which would help with the backend. -- Ankit Malpani 3rd Year Undergraduate | BE. (Hons) Computer Science BITS Pilani Goa Campus

5 5

[utility/value_init] boost::value_initialized<T> direct-initialized?
by Niels Dekker - address until 2010-10-10 09 Apr '10

09 Apr '10

Can anybody please have a look at the following feature request by Edward Diener? https://svn.boost.org/trac/boost/ticket/3472 He proposed to add an explicit constructor, value_initialized(T const&), to boost::value_initialized<T>. This constructor would copy the value of its argument to the object held by value_initialized<T>. When such a constructor would be added, an object held by value_initialized<T> might no longer be value-initialized. Instead it might be direct-initialized. Does anybody have any moral (?) objections against the idea that value_initialized<T> might hold a non-value-initialized object? Personally I think it would be useful to allow the wrapped object to be direct-initialized. But I do think there's a small risk that the new explicit constructor might cause ambiguities in legacy user code. Therefor I suggested adding an extra "tag" parameter to the new constructor, of a new type, boost::direct_initialized_t: struct direct_initialized_t { }; value_initialized(T const&, direct_initialized_t) Does anyone else also think that's a good idea? Or does anyone prefer the explicit value_initialized(T const&) constructor originally proposed by Edward? See also the thread starting at: "Re: [boost] Transfer of Maintenance Rights (utility/value_init)" http://lists.boost.org/Archives/boost/2010/03/164125.php Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

6 32

GSoC 2010: Heaps and Queues
by Dan Larkin 09 Apr '10

09 Apr '10

I'm another potential student throwing my hat in the ring for the heap project. I'll save most of my personal details for my proposal, but for right now I thought I'd try to get a bit of a dialogue going with the community to help me understand what it is you guys are looking for and what it is I can work towards. So I'll start with my current understanding of the situation. The way I see it, the current heap implementations in boost/pending are rather fractured. They just have simple push/pop interfaces with no mutability (well, there's mutable_heap.hpp, but that's separate and not fleshed out). All in all, what seems to be needed is a standardized heap concept/API along with a few fully-implemented models. Standard heap functionality begs the following functions: - findMin - deleteMin - insert - changeKey - merge These can all be implemented quite efficiently (either worst case or amortized O(logn) time or better) for any heap model. I would be looking to implement the d-ary, binomial, and Fibonacci heaps for sure, with relaxed and Brodal heaps as a possibility, should time allow it. These heap models would be built as extensions of a base Heap class, which could be easily wrapped in a PriorityQueue class which takes the heap-type as a construction parameter (and defaults to a d-ary heap for instance). I know that a stable priority queue was mentioned in earlier discussion, but I'm not sure what to do about that just yet. It'll take a little more thinking before I could say whether I think it'd fall under the scope of the summer project, or if it should be put on the back-burner for later addition to the library. I guess that's basically how I see the problem so far. Please let me know what you think, or what other sort of information/planning/etc. you would like to hear from me prior to my proposal/draft. Dan Larkin

7 34

GSoC Generic Sweep Algorithm
by Sweta Yamini 09 Apr '10

09 Apr '10

Hi, I am writing my proposal for GSoC and I'm interested in writing a generic sweep algorithm. I want to write a generic algorithm which takes in functions to determine the priority of the elements to be considered in the sweep line, and a function to perform necessary computations at each such point. And supplement it with inbuilt functions for line sweep, angular sweep about a point for 2 dimensions and plane sweep for 3 dimensions. Also, implement some algorithms like Voronoi diagrams, Delaunay triangulations, visibility problems using the generic sweep algorithm. I have looked through the documentation and could not find anything related to this. Is there something I have missed? Also, could I contact anyone to discuss? Sweta Yamini Fourth Year Student Department of Computer Science And Engineering Indian Institute of Technology, Kharagpur

3 5

Re: [boost] New Boost.XInt Library, request preliminary review
by Anders Dalvander 08 Apr '10

08 Apr '10

Chad Nelson wrote: > > > This disables the copy-on-write optimization that the library uses by > > > default [...] > > > > > I'm not convinced that integers should be COW. What situations do you > > forsee where COW would be helpful but move semantics wouldn't suffice? > > > As described on the rationale page of the documentation, the primary > reason I'm using copy-on-write is that move semantics aren't widely > available yet. Portability is one of my primary goals, and while I've > seen references to a move-semantics-emulator in Boost, I've also seen > suggestions that it relies on the compiler to somehow recognize it. That > doesn't sound fully portable to me. > No offense, but I'm not confident that COW semantics for the integer class is a wise design choice. I assume you have tested the performance with and without COW semantics, as well tested the performance for thread safe operations with and without COW semantics, before making that decision. Care to disclose the numbers? I guess that you have read the COW string article (http://www.gotw.ca/gotw/045.htm) by Herb Sutter, and his conclusions. Optimizations on other parts should perhaps have been made before converting to COW semantics. Using COW semantics could also complicate the complexity requirements for most functions, as they may be "amortized O(something)" instead of just "O(something)". Another concern I have is that NaN is "signaling" as most operations on a NaN integer will throw an exception. I think it would be more sound if operations on NaN integers would result in NaN integers, compare with float NaN. Don't take these comments the wrong way, I'm very glad to see development of an arbitrary precision integer boost licensed library. Best regards, Anders Dalvander

18 136

[contract] Macro syntax?
by Lorenzo Caminiti 08 Apr '10

08 Apr '10

Hello all, I would like you to vote between one of the two options below. Which option do you prefer? (-) OPTION 1 requires programmers to repeat the function signature tokens twice -- in the function declaration and in the CONTRACT_FUNCTION() macro. (+) However, OPTION 1 seems to make the code more readable -- users not familiar with Boost.Contract can "skip" the tokens in the CONTRACT_FUNCTION() signature-sequence and just read the usual C++ function declaration. OPTION 1: The function declaration is programmed using the usual C++ syntax just before the CONTRACT_FUNCTION() macro. template<typename T> class myvector { CONTRACT_INVARIANT( ({ ... }) ) public: void push_back(const T& element) // Usual C++ push_back() declaration. CONTRACT_FUNCTION( (class) (copyable)(myvector) (public) (void) (push_back)( (const T&)(element) ) (precondition)({ ... }) (postcondition)({ ... }) (body)({ ... }) ) ... }; OPTION 2: The CONTRACT_FUNCTION() macro automatically programs also the function declaration. template<typename T> class myvector { CONTRACT_INVARIANT( ({ ... }) ) public: // No usual C++ push_back() declaration here. CONTRACT_FUNCTION( (class) (copyable)(myvector) (public) (void) (push_back)( (const T&)(element) ) (precondition)({ ... }) (postcondition)({ ... }) (body)({ ... }) ) ... }; Thank you. Lorenzo

4 7

[Review Results] Boost.Polygon library accepted into boost
by Fernando Cacciola 07 Apr '10

07 Apr '10

Dear Boosters, [first of all allow me to apology for not doing this before. My small consulting bussines suddenly grew out of proportion and now is way over my head, keeping me working/managing 16 hours a day] I am pleased to announce that the Boost.Polygon library from Lucanus Simonson has been accepted into boost provided some of the most critical concerns, detailed below, are addressed first. First of all I would like to thank Lucanus and Intel Corporation for making this work available to all C++ developers around the world. I would also like to thank all the reviewers that participated (in no particular order nor degree of participation) Thomas Klimpel Frank Mori Hess Barend Gehrels Andreas Fabri Jeffrey Hellrung Tim Keitt Markus Werle Paul A. Bristow Robert Stewart Mathias Gaunard Michael Fawcett Steven Watanabe Joachim Faulhaber John Bytheway Sebastian Redl Mika Heiskanen John Phillips Kai Benndorf Hartmut Kaiser Arash Partow Maurizio Vitale Brandon Kohn David Abrahams Gordon Woodhull Daniel James John Maddock Tom Brinkman Bo Persson Mateusz Loskot Christian Henning Jean-Sebastien Stoezel The library had 6 yes votes and 4 no votes. Those who voted no made the following major complains and remarks (they are numbered as I will refer to them back later): Barend Gehrels: (1) According to his benchmarks, intersection algorithms are unnecesarily slow as if something where fundamentally wrong in the design and/or implementation. AFAICT the implication has not been proved or disproved so far, hence I consider it a red herring and cannot take it as a reason for rejecting the library, but it is important to look at it in detail. (2) As a major complain, the library is unusable in those domains where floating point support is a requirement (like GIS). (3) The library should contain some basic polygon geometry algorithms such as convex hull and centriod Phil Endecott: (4) There is no concept checking in the code so it is difficult to adapt. (5) There where too many warnings and build errors (but Luke fixed these) (6a) The documentation needs a better overview of operations supported by the concetps. (6b) It also needs the details on the algorithms complexities. (6c) It also misses the numerical requirements for the coordinate type. (6d) And tutorials. (7) Some operators are ambiguous and it would be better to keep just one of each "flavor". (8) The polygon_data template class is parameterized by a coordiante type rather than a point type. This makes it useless for integration with existing geometric data types Michael Fawcett: (5), (6a), (6d) (9) T9he API should provide versions using output iterators in addition to output container references. (10) Theoreticall the library would be usable with a user defined coordinate type (metting certain requirements now undocumented), for example a fixed point data type, but some details in the internal design and implementation prevents this. (11) As a major complain, the library is unusable in those domains where floating point support is a requirement (like GIS). Hartmut Kaiser: (11), (1) Fernando Cacciola: (12) The name of the library should change to better indicate that is restricted to Integral coordinates and two-dimensions. (13) The documentation must contain a "credits" section acknowledging all the people that participated in the review. For the library to be effectively accepted, points (5),(6a-d),(10), (12) and (13) should properly addressed ((5) is already done AFAICT) It would be quite significant if point (1) where looked into. Once again I thank Lucanus, Intel Corporation and all the reviwers. Best regards -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com

4 4

[google summer of code] student
by Cezary Bartoszuk 05 Apr '10

05 Apr '10

Hello, I am a CS student and I would like to patricipate in developing Heaps & Queues in Boost during Google Summer Of Code '10. Where, besides the source code, should I search for information about what's already in Boost (in the meaning of heaps/queues)? Who should I talk to about participating in Boost? Best regards, Cezary Bartoszuk, --- Faculty of Mathematics Informatics and Mechanics, University of Warsaw, Poland

3 4

Interested in Boost.Graph
by Piyush Garg 05 Apr '10

05 Apr '10

hi I am interested in upgrading the boost graph library to parallel boost graph library. I want to ask that do i have to chose one of the projects in boost.graph or i have to make them all during summer. Can i make the project on that or i have to suggest my own idea? Thanks Piyush Garg.

3 7

GSoC: Enforcing Code Feature Requirements
by vicente.botet 03 Apr '10

03 Apr '10

Hi, I have recently reread the article "Enforcing Code Feature Requirements in C++" by Scott Meyers <http://www.artima.com/cppsource/codefeaturesP.html> I have posted some ideas that could improve the design (<http://www.artima.com/forums/flat.jsp?forum=226&thread=238798&start=0#372622>) I wanted to know if this could be a good subject for GSoC, if the approach I purpose to solve some issues is acceptable and if there is some students interested. Of course any comments are welcome. Best, _____________________ Vicente Juan Botet Escribá

7 14

[contract] Released Contract Programming Library on SourceForge
by Lorenzo Caminiti 02 Apr '10

02 Apr '10

Hi all, I have released on SourceForge a library that implements Contract Programming (a.k.a. Design by Contract(TM) ) for C++. I am considering to submit this library to Boost (as Boost.Contract). Contract++ Library * Download http://sourceforge.net/projects/dbcpp/ * Documentation http://dbcpp.sourceforge.net/ * Examples http://dbcpp.sourceforge.net/contract__/examples.html Comments? Regards, Lorenzo

2 9

[mpl] has_function
by Lorenzo Caminiti 02 Apr '10

02 Apr '10

Hello all, Is there a way I can check if a class has a given member function using metaprogramming? What I need is to check at compile-time if a function is overriding a virtual function or not. In the example below, z::f is overriding x::f but not y::f (which does not exist) and the compiler knows that -- is there a way I can extract that information from the compiler? struct has_function<class Base, ... /* other parameters */ > { ... /* some implementation */ }; struct x { virtual void f() {} }; struct y { virtual void g() {} }; struct z: x, y { void f() { cout << has_function<x, &z::f>::value << endl; // print 1 cout << has_function<y, &z::f>::value << endl; // print 0 } }; (This does not compile -- I do not know how to program it so it compiles -- but it should give the idea of what I am looking for.) Thank you very much. Lorenzo

16 27

[range][string_algo] Conflict between algorithm names
by Jeremiah Willcock 02 Apr '10

02 Apr '10

When I try to include both Boost.Range algorithms (in the current trunk version) and Boost.Algorithm, using a file such as the following: #include <boost/algorithm/string.hpp> #include <boost/range/algorithm.hpp> I receive several errors about duplicate definitions. I am using gcc 4.1.2 on Linux. ./boost/range/algorithm/find.hpp:28: error: ‘template<class SinglePassRange, class Value> typename boost::range_iterator::type boost::find(SinglePassRange&, const Value&)’ conflicts with previous using declaration ‘template<class RangeT, class FinderT> boost::iterator_range<typename boost::range_iterator<C>::type> boost::algorithm::find(RangeT&, const FinderT&)’ ./boost/range/algorithm/lexicographical_compare.hpp:28: error: ‘template<class SinglePassRange1, class SinglePassRange2> bool boost::lexicographical_compare(const SinglePassRange1&, const SinglePassRange2&)’ conflicts with previous using declaration ‘template<class Range1T, class Range2T> bool boost::algorithm::lexicographical_compare(const Range1T&, const Range2T&)’ ./boost/range/algorithm/lexicographical_compare.hpp:42: error: ‘template<class SinglePassRange1, class SinglePassRange2, class BinaryPredicate> bool boost::lexicographical_compare(const SinglePassRange1&, const SinglePassRange2&, BinaryPredicate)’ conflicts with previous using declaration ‘template<class Range1T, class Range2T, class PredicateT> bool boost::algorithm::lexicographical_compare(const Range1T&, const Range2T&, PredicateT)’ The using declarations mentioned in the error message are in files such as boost/algorithm/string/find.hpp. Is there a workaround or easy fix for this? -- Jeremiah Willcock

5 10

Transfer of Maintenance Rights
by Stewart, Robert 01 Apr '10

01 Apr '10

Dave asked for a policy proposal for how Boost library maintenance rights may be transferred. Edward Diener declined, so I'll offer one and go a little further while I'm at it. Consider the following as a replacement for the text at <http://www.boost.org/community/reviews.html#Maintainer>. _____________________________ Library Author's Responsibilities By submitting a library to Boost, you agree to put the library and its documentation under a Boost-compatible license, if it is accepted. If your library is accepted, you are free to change it any way you wish. Indeed, we encourage you to make constant improvements. However, because peer review is an important part of the Boost process, please consider getting Boost community feedback before making substantial changes to the interface of your library. Furthermore, if your library is accepted, you agree to be the library maintainer or to find a qualified volunteer to serve in your stead. You may, of course, assemble a qualified group to act as maintainers of your library, regardless of whether you continue to be a maintainer. Library Maintainer's Rights and Responsibilities As a library maintainer, you agree to provide timely support to users of the library, and to fix bugs and release those fixes in a timely fashion. You also agree to consider making library enhancements and improvements. Note that others may offer and even commit patches to a library you maintain, provided the patch is posted to the Boost Developer's mailing list for approval and is not rejected by anyone within a reasonable time. If you find that you can no longer fulfill your responsibilities as maintainer of a library, you are responsible to advertise this to the Boost community. If you are the sole maintainer, you are responsible to find a replacement. If for some reason you fail to fulfill your responsibilities as maintainer of a library, as judged by the Boost community, whether through willful neglect or otherwise, you agree to allow the Boost community to provide a suitable replacement. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

25 51

[bgl] Reconnecting an edge
by Matthias Walter 01 Apr '10

01 Apr '10

Hi! Is there any way to reconnect an edge in a graph? I'm interested in doing so while retaining a property map. Thus remove_edge and add_edge are not a solution, I think. If not, may it worth to add such a concept? best regards Matthias Walter

3 3

[GSoC 2010] Boost.Graph topology generators
by Omair Mohammed Abdullah 01 Apr '10

01 Apr '10

Hi, I am interested in implementing topology generators for Boost.Graph. I have a few questions: What is the scope of this project? Is it expeced to implement the common topologies with detection methods or more? For example, are generators like PLOD, Erdos-Renyi and small-world are already there. Are we supposed to extend them?

2 1

Second iteration of Boost.XInt library uploaded, requesting further comments
by Chad Nelson 01 Apr '10

01 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've just uploaded the second iteration of the Boost.XInt library to the Boost Vault. I very much appreciate all of the comments and suggestions everyone has offered on the first one, and I've incorporated a number of them. Maybe I'm just a masochist, but please take a look and let me know what you think. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuypFUACgkQp9x9jeZ9/wRD3wCeMKRKaeml9UzhMNTpl15RvBFE pw8AniN8kkXNEFelgY4VYtWNzaCi88cV =lHLU -----END PGP SIGNATURE-----

5 13

[lock-free] CDS -yet another lock-free library
by Khiszinsky, Maxim 01 Apr '10

01 Apr '10

Hi, I'd like to present to boost community the CDS (Concurrent Data Structure) C++ library at libcds.sourceforge.net. It is an attempt to generalize well-known lock-free (and a few lock-based) data structures discovered by famous researches (M.Michael, N.Shavit and others). The library is mostly header-based, only the kernel of light-weight memory managers is resided in small dynamic library. The CDS library supports a set of modern processor architectures: x86, amd64, ia64, sparc; compiler supported is GCC 4 and MS Visual C++ 2008. The last CDS release 0.6.0 is developed close to C++ Memory Model proposal. I need the recommendations from boost community about : 1. Are the atomic primitives implemented correct for each of supported processor?.. I'm not an expert in this area... 2. Is the memory order constraint (from C++1x proposal) choosed correctly for lock-free data structure implementation?.. I known it is very large and magic question. Maybe, somebody analyzes the library code and find the errors. And I be very glad if anybody joins to CDS project. It is very interesting area of computing science with nonstandard algorithms and crazy implementation (and debugging notably).

9 35

GSOC Application Dates.
by swagat konchada 31 Mar '10

31 Mar '10

Does Boost suggest submitting the proposals for GSOC'10 as early as possible? Or is it ok if I take time? -- Problem is a phenomenon indicating lack of thought. Swagat Konchada

2 1

GSOC BigInt Numeric_adaptor
by swagat konchada 31 Mar '10

31 Mar '10

> swagat konchada wrote: > > > If we consider performance issues based on design, planning the > > BigInt architecture could be designed in two ways > > > > 1. 3 layers to allow optional binding to Boost's own bigint, > > GMP, or anyother bigint library, for the user during compile > > time. > > > > 2. 2 layers if we plan to limit Boost.Bigint's options to only > > itself and GMP. > > [snip] >IMO you should look at the discussion on a numeric_adaptor by Barend Gehrels and some draft code mentioned in > http://archive.freebsd.se/?ml=freebsd-questions&a=2007-05&m=11343770<http://archive.freebsd.se/?ml=freebsd-questions&a=2007-05&m=11343770> >to get some idea of the problem and a plausible framework which might include 'BoostsOwnBigInt' as an alternative to GMP >etc. >Paul >PS But you should also be aware that another xInt project is being discussed on this group. I checked out the numeric_adaptor scheme. It has used the GMP library and the CLN library's API to optionally provide some basic arithmetic operators on arbitrary precision decimal numbers(it was surprising since i expected adaptation for integer operations first, though i realise that there'd be no much change in the code). The main idea of the numeric_adaptor scheme though is the to_traits struct, which would cast the library dependent types to Boost's types by using explicit templates(i hope this is the right term). In fact the scheme paves the way for a direct start of the implementation of Bigint since it provided the core design(the very expression template system which was called for) of an optional BigInt library. Making this expression template system exhaustive and make it work with any one of the libraries(GMP ofcourse), must be our priority. @Paul. A. Bristow : I am also following the discussion on Xint, and would comment on it asap. Suggestions and criticism please! -- Problem is a phenomenon indicating lack of thought. Swagat Konchada

1 0

[intrusive doc] slist says that both push_front and push_back are constant-time
by Andy Venikov 31 Mar '10

31 Mar '10

The doc for slist says that if using non-constant size semantics, the size of the slist is the size of a single pointer. That means that either push_front or push_back cannot be constant time since we first need to find it. Am I missing something? Thanks, Andy.

2 2

[1.43.0] Cutoff for major code changes approaching
by Beman Dawes 31 Mar '10

31 Mar '10

The cutoff date for major code changes is this weekend, so please complete any pending merges to the release branch. Also, now might be a good time to check the release regression tests and inspection reports to make sure your library is in good shape: http://beta.boost.org/development/tests/release/developer/summary.html http://boost.cowic.de/rc/inspect-snapshot.html PS: The beta is scheduled for April 17th, and the release for May 1. The calendar can be seen at: http://www.boost.org/development/index.html -- The Release Managers, Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

1 0

Proposal for semantic graph : Boost Mentors, please comment on it
by Chinmaya Poswalia 31 Mar '10

31 Mar '10

*Need For Semantic Graph* First thing I would like to mention is that semantic graph is not merely a graph with links and nodes. It’s a graph in which nodes links can be of different data types and similarly links. It's a graph of interconnected things that is machine-understandable, its meaning or "semantics" can be explicitly represented on any common database, just like its data. This is the real way to make social networks, applications, libraries and information/data open. Merely opening up their API's is just the first step. Through it, applications can start using the functions and properties written in other languages. Since the Semantic Library makes data-integration easier, it will ultimately be widely adopted and will cater most to the community. Simply put, applications that wish to access or integrate data in the modern age can more easily be done. That alone is reason enough to use this library. Summarising the above Ø Making data more accessible, connectable, and reusable across applications would be a huge benefit. Ø Ability to do more sophisticated reasoning across data. Ø Applications in which its use can directly be seen is World Wide Web. Please refer the above link for more detail. http://novaspivack.typepad.com/nova_spivacks_weblog/2007/11/defining-the-se… http://www.signosemio.com/rastier/a_graphe.asp *Project Proposal* [dog] <- (ERG) <- [bite] -> (ACC) -> [man] <---------------------- Semantic Graph Here dog, bite and man all are of different types and ERG and ACC are the relations where ERG -> *corresponds to the ergative case (the agent of an action)* ACC-> to* the accusative case (the patient of an action, the one affected by it)* I am aiming to make the first steps towards the conceptualization and formulation of Semantics Graphs for the Boost Graph Library (BGL). *1) **Node Data Structure* Node should have a container to store data and an array of functions whose scope will be limited to only process the data of its own node and attached links. These nodes can process their data individually and this functionality would be defined by the functions which user would provide through the array of functions and can transmit request for processing to another nodes through links joined to them. Nodes will also contain the pointer to all the links leaving it. *2) **Link Data Structure* Links apart from containing data it will contain some defined constants whose actions value would be provided at the start time and should. These constants would define the relation between the nodes it is connecting to. Majorly relations would include of the following types like who is the agent of action, who is the recipient of action, which is the proposed result of the action, what is the final result, what is the beneficiary action and who is the beneficent of the action, who is the comparing element and who is being compared. The following paper clearly states what semantic graph is mathematically. http://www.revue-texto.net/Parutions/Livres-E/Hebert_AS/12.Semantic-Graph.p… *3) **Algorithms For Traversal of The Graph* Here I want to state that I found a library for semantic graphs which is in the CLI library. It can be obtained at http://www.codesynthesis.com/~boris/tmp/cli/cli-0.0.2+dep.tar.bz2<http://www.codesynthesis.com/%7Eboris/tmp/cli/cli-0.0.2+dep.tar.bz2> The basic algorithm of Traversal can be used but here since the nodes and links are of different data types, this can be implemented with the help of a void pointer. Once we reaches a node, we will mark it explore and the will move to the links that leaves it. This will even provide the functionality to enable us to find a link. How knowledge will be represented and how what variables and functions need to be implemented, these issues and their solution are clearly stated in the following research paper. http://www.edmondchow.com/pubs/SS105ChowE.pdf An application of semantic sub-graph involving knowledge representation and text summarisation is given in the following paper written under Microsoft Research. http://nl.ijs.si/isjt04/zbornik/sdjt04-05leskovec.pdf Please note the fact that through this way, i think the space occupied by the graph is minimal as it only depends on the containers used by the user. We just used 3 pointers for linking the nodes.

2 1

[concept_check] silence gcc warnings
by Jürgen Hunold 31 Mar '10

31 Mar '10

Hi ! I've started to use Boost.Accumulators and I'm getting tons of ugly warnings when compiling with optimization on. See full "warn.log" for details, This boils down to boost/concept_check.hpp 335: warning: non-static reference ‘const float& boost::UnaryFunction<boost::numeric::functional::as_max<const float, void>, float, const float&>::arg’ in class without a constructor [-Wuninitialized] when the check ist called with a reference parameter. It seems that providing a dummy constructor is sufficient to silence this. Please find a patch attached. Okay to commit ? Or are the better ideas ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2

Google Summer Of Code
by Brian Bartman 30 Mar '10

30 Mar '10

Hello my name is Brian Bartman and I am an undergraduate at Kent State University Majoring in computer science. I was interested in the bits & ints project, specifically Compressed array and Compressed vector as well as the utilities for bit mask manipulation. Could some one help me better understand the requirements of this project? I would like to draft a proposal for GSoC 2010 and wanted to better understand the project before I write a proposal.

4 8

Re: [boost] [MSM] using irow "internal transitions" and constructorarguments for frontend ?
by Christophe Henry 30 Mar '10

30 Mar '10

Hi, >We have seen that there was a review early this year is there a boost >version where msm will be officially part of boost lib ?. I'm finishing it and hope to bring it into the 1.43. Hopefully, the newest version will be online in a few days. If you cannot wait, I can send it to you before. >Is anybody used boost::msm in a real life project is there any >measures about stability ?. I did but I'm biased ;-) Seriously, I know a few people who did and reported here and there a bug (which is usually corrected very fast) but nothing critical. I'd also be interested in live reports. >Furthermore we had the following problems during our evaluation: > >1.) in the documentation there is a section about internal transitions >using irow : I think this is in the documentation from the sandbox, not the vault. The doc in the sandbox is not up to date because I made an almost full rewrite. MSM 2.0 supports no internal transitions, but the subject was brought by Michael Caisse during the review and the coming version 2.10 has them. The sandbox version also has internal transitions and is usually up to date, except, as I said, the doc (but not for long). >2.) State machine constructor with arguments in the documentation >there is an example but we did not managed to get it working > >is this example correct in the documentation ?. The example is correct and should work but I admit I'm unsure if it was already in the 2.0. I guess not. Please try the sandbox or the coming 2.10. But thanks for telling me, I just realize I forgot this part in the new doc, so I will add it. Thanks, Christophe

2 1

BoostCon2010 lodging - M4MW
by Robert Ramey 30 Mar '10

30 Mar '10

I'm making arrangements to attend BoostCon2010. I'm reviewing the Aspen Meadows Resort web page. Seems like a very fancy and nice setup. The rates are $159 + 10% + $18 / day for one or two persons. I expect to be going by myself as my wife considers attendance at such an event as boring beyond belief. I'm also a free lance software developer so I will be paying myself. So it would be economically advantageous for me to share this with at least one other person (The room has a capacity up to 4 persons). So anyone who want's to split this with me should let me know via private email ramey(a)rrsd.com. BTW- I'm still considering options about getting there. I haven't been on an airplane since 1995. From what I hear, it's even more unpleasant now than it was then. But it's a long drive from where I live. Anyway ... Robert Ramey

2 1

Boost.Graph GSoC 2010
by Cezary Bartosiak 30 Mar '10

30 Mar '10

Hi, I am Cezary, a student of computer science at the Cybernetics Faculty, Military University of Technology, Warsaw. I am interested in developing the BGL. I've got an idea related to the Topology Generators. I have participated in a project concerning epidemics spreading and, as a part of the project, we have implemented several social networks generators (Barabási–Albert model for instance). I hit upon an idea to implement these algorithms apart from proposed topology generators. I know that Boost.Graph contains some algorithms for generating networks, I would like to add some extensions: 1. There is Erdős-Rényi model generator in two versions G(n, p) and G(n, m). I think I could provide some additional implementations for specific cases, I mean: a) Fast generator of sparse graphs inspired by http://www.inf.uni-konstanz.de/algo/publications/bb-eglrn-05.pdf. b) Fast generator of dense graphs, algorithm by Keith M. Briggs Mar 31, 2006 (the only implementation of this one I've seen in NetworkX library). 2. There is only Beta-model generator of Small World network in the library. I would like to add Alfa-model generator as well as Kleinberg model generator. Here are some interesting materials: http://tam.cornell.edu/tam/cms/manage/upload/SS_nature_smallworld.pdf http://www.bsos.umd.edu/socy/alan/stats/network-grad/summaries/Watts-Six%20… http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.83.381&rep=rep1&ty… 3. At the moment we've got only PLOD algorithm to generate ScaleFree networks. I could provide other ones: a) Basic generator often seen in popular libraries, for instance NetworkX. b) Generalized generator with probabilities of adding new edges and rewiring existing ones. c) Simplified models generators: A (uniform attachment) and B (no growth). Coming back to Topology Generators I would implement them for some "basic" topologies, let's say: path, star, cycle, wheel, ladder, grid, hypercube, barbell, complete, frucht and many others if time remains... I would be glad to know your opinion. Best, Cezary

2 2

[GSoC] Advanced data structures library
by Rui Gonçalves 30 Mar '10

30 Mar '10

Hello, I'm new to this community. My name is Rui Gonçalves and I'm thinking about submitting an application to Boost in Google Summer of Code. In particular, due to my own programming interests in data structures, generic programming and abstraction layer developing in general, I would be very happy in developing an advanced data structures library. As suggested in the ideias page, it would have includes various types of heaps and queues. I haven't had time to look at all different libraries, but if there is some known data structure with implementation needed, I would not mind implementing that too. I had a look at the /boost/pending available implementations. A lot of code could be reused / ported; however, I think that the source code could be more standardized between heap implementations. I'm thinking in a STL-like implementation, like: template < class T, class Heap = binary_heap<T>, class Compare = less<T> > class priority_queue; template < class T, class Container = vector<T>, class Compare = less<T> > class fibonacci_heap; I already looked in books for some more obscure details of each algorithm, and haven't found anything excessively difficult. This seems a rather simple project (although I recognize it can take some time). Is there some convention or requirements for data structures in Boost? Is there any difficulty that I should be aware of but didn't notice, or any detail about GSoC that I should know? (I'm new to that program and I feel kind of lost). Thank you in advance for your help, Rui Gonçalves

3 4

[MSM] using irow "internal transitions" and constructor arguments for frontend ?
by Richard Szabo 30 Mar '10

30 Mar '10

Hi All We are in a process to evaluate boost::msm 2.0 we would like to use it in our project. We were using sources from http://www.boostpro.com/vault/index.php?directory=Msm version 2.0. We have seen that there was a review early this year is there a boost version where msm will be officially part of boost lib ?. Is anybody used boost::msm in a real life project is there any measures about stability ?. Furthermore we had the following problems during our evaluation: 1.) in the documentation there is a section about internal transitions using irow : see : irow < Empty , cd_detected , &p::internal_action ,&p::internal_guard > but we did not find the irow definition in the sources ?. 2.) State machine constructor with arguments in the documentation there is an example but we did not managed to get it working is this example correct in the documentation ?. struct player_ : public msm::front::state_machine_def<player_> { player_(int some_value){…} } This is still possible, using the back-end as forwarding object: typedef msm::back::state_machine<player_ > player; player p(3); // do something with the state machine Thanks in Advance Richie & Michi

1 0

GSOC Boost BigInt design issues
by swagat konchada 30 Mar '10

30 Mar '10

> >swagat konchada wrote: > > > > I had a look upon the BigInt code from the sandbox. It's > > entirely wrapped around GMP(linked to gmblib). > [snip] > > That is uncompatible with the Boost license, which hinders > > the distribution > > of a Boost_bigInt library which wholly is a wrapper around GMP. > > > > Keeping in view the above issues what should be our priority? > > Improving the > > wrapping around GMP for time being or Starting Boost's own version of > > BigInt. I see mixed reactions on this subject. My personal > > opinion is that > > suggested by Paul A. Bristow, i.e, of a Boost's own BigInt, > > which I think is in line with Boost's long term aspirations. > > > Rob Stewart wrote > The usual idea is that BigInt would provide expression templates and other > optimizations to avoid calling the back end engine inefficiently. That may > require an adapter layer between the user-visible BigInt API and the > computation engine, like GMP, at the back end, to insulate the API from > differences in the back end engines. (Then again, there may be nothing left > to a layer above the adapter layer; I'm not saying there must be three > layers.) > > If GMP is an optional batck end supported by BigInt, along with other back > ends, controlled by conditional compilation, then a BigInt user can choose > to use GMP if they like, but the licensing issue will be theirs and not > Boost's. > > HTH, > > _____ > Rob Stewart robert.stewart(a)sig.com > Software Engineer, Core Software using std::disclaimer; > Susquehanna International Group, LLP http://www.sig.com > > If we consider performance issues based on design, planning the BigInt architecture could be designed in two ways 1. 3 layers to allow optional binding to Boost's own bigint, GMP, or anyother bigint library, for the user during compile time. 2. 2 layers if we plan to limit Boost.Bigint's options to only itself and GMP. In a 3 layered architecture, 3 function calls would take place for each overloaded operator, whatever the option chosen by the user. Whereas in a 2 layered architecture, in which only GMP is an extra option, there is an equal probability of a user using Boost's own bigint or GMP and thus half of the times, 2 function calls are made and in the other half only 1 function call for each overloaded operator. This means doubling in the number of function calls. Though I realize most of the time is spent inside the function rather than in calling the functions, does this result in an overhead we should worry about? -- Problem is a phenomenon indicating lack of thought. Swagat Konchada

3 2

Library dependencies and intrer-library code reuse
by Zachary Turner 30 Mar '10

30 Mar '10

There's a lot of chatter on the list recently about how to "grow" boost. I wanted to add my own idea to the pot. Due to the scope of what I describe, I don't think it's reasonable to expect everyone to be on board with it because TBH it's a lot of work, but I'm just throwing it out there, and I think that if you forget about what would be involved in actually making it happen, it actually has many highly desirable properties. But comments would be welcome. So anyway, one of the recurring questions that pops up over and over and over is that of whether or not a library should reinvent the wheel, or use some data structure / class from some other library. On one side of the fence, there's people who say that it's often ok to reinvent the wheel inside library A if it avoids introducing a dependency on boost library B. Generally, the problem is that introducing a dependency on B a) increases compile time, because often only an extremely small component of library B is needed, but the header-onlyness of most libraries causes inclusion explosion, and b) introduces logistical problems when library B is not "permitted" for use in a certain organization. This is becoming increasingly common as certain organizations begin whitelisting boost libraries that are allowed in their codebase. On the other side of the fence, there's people who say that reinventing the wheel is almost always bad. The reasons for this are obvious and I think everyone here is well aware of the issues, so I won't repeat them. Note that I'm not taking sides here, just pointing out that the argument against reinventing the wheel is well understood. Is there a way to solve *both* of these problems at the same time? I think there is. Consider the following system: 1) Library maintenance is more flexible, and not necessarily limited to only a single maintainer or a whitelisted group of maintainers. There is another thread on this topic already, so rather than debating this particular point here, it's probably better suited in the other thread. For the purposes of this post, just assume that there is *some* system, with completely unspecified parameters, where there is *some* way for people to easily get their own code into an existing library that they are not necessarily the author / maintainer of. At the very least, *other library authors* would be given a "fast track" to submitting changes to other libraries, whatever "fast track" means. 2) All libraries would be required to support both pimpl'ed and header-only implementations. I realize this is sort of a huge undertaking and requires retrofitting tons of libraries, but I think the advantages are worth it. The users end up winning in the long run, nobody ever has to have this debate again about whether or not header only libraries are good or bad. If you want header only libraries, use #include <boost/someheader.hpp>. If you want pimpl'ed libraries, use #include <boostp/someheader.hpp>. pimpled' headers only include other pimpled headers. Also it makes the system I'm describing possible. 3) The boost build process is changed to allow additional options that either: a) automatically select all libraries for external visibility, b) select a specific list of libraries for external visibility, or c) select a specific list of libraries to disable external visibility. During the build process, what is currently known as the "boost" directory (e.g. the boost folder in #include <boost/shared_ptr.hpp>), gets a different name. Perhaps it's changed to something like <boost/internal/shared_ptr.hpp>. This happens EVERYWHERE. All boost library header and source files would need to be updated to include from boost/internal. For those libraries that were selected for external visibility, a symlink is created under the boost directory inside the internal directory. On windows a directory junction is used. Note that directory junctions are supported since Windows 2000, so I don't think this is an issue. It's very easy to create them, just that people rarely do. The end result of this is the following: 1) Users notice minimal impact. The only difference, in fact, is that if they want pimpled implementations they #include <boostp/...> instead of #include <boost/...>. This means the current behavior continues to be the default. After they build boost, the build process handles all the logistics. Everything is already in the correct structure to "just work", all symlinks have been created as described in 3) above, and the user only needs to set their include path to the top level boost directory. 2) All boost libraries can use all other boost libraries with ease, regardless of whether or not an organization's policy allows use of those libraries in user code, because internally all libraries include from boost/internal. 3) Despite the fact that all these additional dependencies that a user isn't technically allowed to be using due to his organization's policy are indeed being used, compile times can be kept sane because the user has access to pimpled libraries, and pimpled libraries only depend on other pimpled libraries, which is possible since all libraries are required to support pimpled versions. So there we go. Does this work, and if not why not? Even if we agree it's a huge undertaking, is it worth it? And if not, why not? Zach

9 16

Boost, Decoupled and Accelerated
by David Abrahams 30 Mar '10

30 Mar '10

Hi All, I know I'm not the first person to notice that, as Boost has grown, it has become harder and harder to manage, Subversion is getting slow, our issue tracker is full to overflowing, and the release process is a full-time job. For me, this situation has taken a lot of the fun out of participating. It's time to make Boost development fun again. To that end, Troy Straszheim and I have started building a system called Ryppl to decentralize development, testing, release, and installation of interdependent projects, like—but not limited to—Boost libraries. I will be holding a session **Tuesday night at BoostCon** to formally unveil this system and demonstrate it in action, and I intend to propose that Boost make the move immediately thereafter. I believe this project has the potential to change the face not only of Boost, but of open-source software in general. By the time of BoostCon, ryppl will be live, and we'll be able to use it to work on Boost. I encourage anyone who is interested in these developments to register for BoostCon immediately. If you're interested in working on development of this system, *please* send me an email; we can really use your help. Be forewarned, though: this may not operate like many other open-source projects. Given the short period of time remaining before the conference, we have little time for design discussion and debate, and we need to be maximally effective: there's simply no time to waste. You can expect me to take a “Benevolent Dictator” role, if not “For Life,” (BDFL) then at least “For the Time Being” (BDFTB). Cheers, -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com

12 23

[GSoC] Generic Linked List library
by Thomas Mullaly 30 Mar '10

30 Mar '10

Hi, my name is Thomas Mullaly. I am currently an undergraduate in the Computer Science department at Kent State University and I am interested in contributing a generic linked-list library to Boost as a GSoC project and I just wanted to see if there is any interest from the Boost community about having these contributed as a library. I am implementing the linked lists project from 'Elements of Programming' (ch. 12, I think), and am trying to provide lists for both constant-time size and constant-time splice. My library currently implements a number of variations of both singly- and doubly-linked lists, and I have implemented a wrapper that adds a node count and acts as a counted list. While the basic list types are already implemented, there is still a lot of work to done on them. For my GSoC project I would like to integrate allocator support into them, clean up the existing interface, and create a generic interface to the different types of lists with the help of a mentor. By the end of my GSoC project I would like to have a functional list library to contribute to Boost. I feel that this would be a valuable library to Boost because the standards implementation limits you (depending on your library vendor) to either a constant time size() function with a linear time splice operations or constant time splice operations with a linear time size() function. With my implementations a developer will be able to pick and choose whether they want a singly or a doubly linked list, or if they want to use a counted listed instead of a non-counted list. Also their is variations in memory/runtime efficiency between the different variations of the list types which a developer will be able to choose for. Currently my list implementations make heavy use of the new features available in C++0x such as rvalue references and move semantics, but, I will be more than happy to create a backport of these for the current C++ standard so they can be included in Boost. If anyone is interested in the source code for my current list implementations I will be able to provide tarballs of them.

4 3

[GSoC] Bits and Ints
by Gaurav Menghani 30 Mar '10

30 Mar '10

Hello, I am keen on working on the Bits and Ints project. However, I would be glad if someone could answer my queries. In the project description, the second line says: "Compressed value array and vector (like vector<bool> but also for multi-bit values)" 1) When we are talking of Compressed Value Array, are we looking at a functionality similar to the Deflater() class in Java, or something like Run Length Encoding / Delta Encoding? 2) I am also not sure if I get what is meant by "but also for multi-bit values", do you mean multi-dimensional bit-fields? 3) Can we discuss the proposal-drafts on the mailing list, even after the application time frame begins (March 29, 2010, 19:00 UTC)? Warm Regards, Gaurav Menghani

2 1

5 Observations - My experience with the boost libraries
by Tom Brinkman 29 Mar '10

29 Mar '10

Over the past years, every project that I have been involved with has tried and then either abandoned boost or highly restricted its use. As a long time boost user, I can't tell you how much debate we've had about this. I want boost to succeed, grow and be successful. Its sad. As someone who has used boost from the beginning, and has taken far more than I have given, here are some of my observations. Many of the reasons don't have specifically to do with boost, but more have to do with a preference for one programming style versus another. I have identified 5 key issues about why boost was abandoned. 1) Boost uses exceptions. 2) Printf versus Iostream. 3) Dependencies. 4) Research Projects 5) Macros 1) Boost uses exceptions. This issue is best illustrated when you want to just do something as simple as converting a "string" to an "int". boost::numeric_cast throws an exception, which forces you to wrap it into a try-catch block. The seemingly trivial issue of how to handle exceptions causes endless grief. It seems that developers still prefer "C" style casts. The prevailing view on projects that I have worked on is that C++ exception handling should optional and not required. int value = 0; try {value = boost::numeric_cast<int>("3.00");}catch (...){} versus int value = atoi("3.00"); I think the lesson is that there is no correct answer here. As most "C++" projects use some "C" libraries, you will need to be flexible in your approach to exception handling. A pure "C++" approach of try-catch blocks is not practical. As boost libraries tend to throw exceptions, it forces you to put try-catch blocks all over your code. Many developers will simply ignore this issue and end up with lots of code that is not exception safe. Small issue, but is undoubtably a source of a huge amount of problems. 2) Printf versus Iostream. Most developers still prefer "printf" over "iostream" style "api's". Unfortunately, Boost libraries have long ago adopted "iostream", as the preferred API style. This issue has been the source of many hours of needless debate. Pure C++ developers seem to have a aversion to "printf" style arguments. As there are very few pure C++ projects (if any), I dont hear about this as much as I once did. Most C/C++ developers prefer a printf style api. Boost needs to start providing printf style api's. Boost needs to be more practical. By not also providing printf style api's, boost is not meeting the needs of developers. Iostream may be preferable for purely academic reasons, but for practical reason, "printf" is the api style that is universally adopted. Is it boosts goal to meet only the needs of a small subset of its c++ users? If that is the goal, than it needs be clearly stated as such. As most developers have adopted a combined C/C++ style of development, a pure academic C++ style syntax is not practical for every day use. Boost needs to look at what the popular api styles are and adopt them and not be so dogamtic about its style of so-called pure "C++". 3) Dependencies. Everyone has a few favourite boost libraries. Unfortunately, because of confusing dependencies between them, its practically impossible to isolate the ones you want from from the ones you don't. What does this mean? Well, it requires the leads of a given project to create a policy about which boost libraries are approved and which ones aren't. Because of the difficulty of doing this, after a while, its can become eaiser to just say "screw it". We won't use boost at all. This issue may seem trivial, but it is the cause endless hourse of grief. It seems that once you add boost to your project, some developers feel that you should be able to use any part of boost. For obvious reasons, project leads prefer to have control over which libraries are used in a given project. Few will just give blanket approval to all boost libraries. The way boost was developed makes this practically impossible. Boost needs to advertise itself correctly and not pretend to be something its not. Its simple a place for promising research libraries to live, to get some exposure, and possibly be adopted by the larger C/C++ community. Currently, boost provides the best place to do that, but it needs to be honest with its users. 4) Many boost libraries seem more like they research projects. The prevailing view is that boost libraries push the envelope of what is possible. This is universally considered a good thing and it is always interesting to see what the best and brightest are up too. Unfortunately, boost pretends to be something else. It pretends to be a collection of libraries that meet your day to day needs. Experience proves otherwise. The practical needs of large scale active projects are in conflict. Boost is very dogmatic and encourages a particalular style of development, which is very template based. In the right hands, a heavy templated based project can work. In my experience, however, it takes many many iterations to get a template based designed library correct and usable. Many more iterations, in fact, than the equivalent non-template design. It is soo difficult, that I am very reluctant to use others template based libraries. I approach them with fear. That being said, boost::mpl and boost::spririt are wonderful accomplishments and I use them regularly. 5) Macros. Need I say more. The core boost libraries are full of macros. So much in fact, that close examination makes many of them practically unmaintainable. I know there are practical reasons to use them. The main reason being compiler inadequacies. However, many developers question the value of a cutting-edge template library that is full of macros. What is the point of having the source code, when it take an experienced developer many weeks to understand what the library is doing underneath? What is the practical value of a library that can only be maintained by the original developer(s)? This issue has surprised many, but has comes up often. If it takes more than a day to examine a libraries source code and have some idea what its doing, its very dangerous to use. This issue will cause many to avoid complex templated macro-style boost libraries. Tom Brinkman

36 161

GSOC BigInt Licensing Issues
by swagat konchada 29 Mar '10

29 Mar '10

I had a look upon the BigInt code from the sandbox. It's entirely wrapped around GMP(linked to gmblib). #inlcude<gmp.h> #ifdef BOOST_BIGINT_HAS_GMP_SUPPORT #include <boost/bigint/bigint_gmp.hpp> namespace boost { typedef bigint_base<detail::bigint_gmp_implementation> bigint; } I also read the LGPLicense which the GMP library carries with itself. This is my inference : The bigint code(from the boost sandbox) could be addressed in LGPL terms as "An Application" : which LGPL defines "as any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library.", since it just uses the gmp.h interface and linking to gmplib. So the combined work, application and GMP, should be conveyed with a GNU GPL license. The Boost License allows skipping the copyright notices if only it's executables are used, unlike the LGPL which requires to distribute it's license. And there are even restrictions on "conveying the object code under terms of your(Boost') choice", in addition to other restrictions. That is uncompatible with the Boost license, which hinders the distribution of a Boost_bigInt library which wholly is a wrapper around GMP. Keeping in view the above issues what should be our priority? Improving the wrapping around GMP for time being or Starting Boost's own version of BigInt. I see mixed reactions on this subject. My personal opinion is that suggested by Paul A. Bristow, i.e, of a Boost's own BigInt, which I think is in line with Boost's long term aspirations. I hope my understanding of the issue is correct. I would be grateful to receive suggestions and comments which would help my GSOC proposal for BigInt, which I plan to submit as early as possible. -- Problem is a phenomenon indicating lack of thought. Swagat Konchada

3 2

[GSoC]
by Andrew Sutton 29 Mar '10

29 Mar '10

Just a reminder, Google Summer of Code student applications can now be submitted here [1]. The deadline for submitting an application is Apr 9. Ideas for some student projects and other information about the program can be found here [2]. Andrew Sutton andrew.n.sutton(a)gmail.com [1] http://socghop.appspot.com/ [2] https://svn.boost.org/trac/boost/wiki/SoC2010

1 0

[GSoC] Mentors group
by Andrew Sutton 29 Mar '10

29 Mar '10

All, If you are registered as a mentor for GSoC 2010, I'm going to invite you to the mentor's group/mailing list here [1]. This will be used to discuss student proposals and vote on the set of final projects for Boost. If you are already registered, then you probably won't be receiving a new invitation. This list is historically low-traffic. If you have any questions or comments, please let me know. Andrew Sutton andrew.n.sutton(a)gmail.com [1] http://groups.google.com/group/boost-gsoc-mentors

1 0

Observations - moving from boost_1_39_0 to boost_1_42_0
by Jeff Flinn 29 Mar '10

29 Mar '10

Lets not lose site of what boost is doing right. I've just updated to boost_1_42_0 from boost_1_39_0 for XCode and MSVC. 1. All but 2 previous workarounds for compiler warnings are non longer needed 2. One wrinkle in build for xcode - now require --layout=versioned 3. MSVC (distributed) build of my app using boost completes 20% faster 4. My app's full test suite runs 10% faster Thanks to all who've made this happen! If your curious, the workarounds are for the archive exceptions in portable_binary_archive, which should have been patched back in 1.40. These are actually in the examples folder, not fully supported by serialization at this time. Jeff

1 0

[GSoC] Boost.Process
by Moncef Mechri 29 Mar '10

29 Mar '10

Hi boosters, My name is Moncef Mechri (aka "fireboot" on IRC). I'm a 20 years old french student in my final undergraduate year at the Faculté des Sciences de Luminy, Marseille, France. I would like to apply as a student for the Boost.Process SoC idea. My main domains of interest include C and C++ programming languages, system programming (especially on POSIX systems), parallel computing, generic programming, object-oriented design, software optimizations, graph theory, and UI development (using Qt). So far I've used a couple of boost librairies : Boost.Thread, Boost.Random, some features from Boost.Interprocess (principally atomic operations), Boost.SmartPointers, Boost.Foreach and Boost.Bind. They were all a pleasure to use and it's why I've just written a (french) paper about one of them : Boost.thread [1]. I'll would be glad to help improving the set of high quality libraries that Boost is. I have some ideas to help finishing Boost.Process and I'd be happy to hear your opinions about them: 1) Abstract the string type used to name executables. This could be done for example using a traits class 2) Move find_executable_in_path() and executable_to_progname() to Boost.Filesystem. I think their job is filesystem-related so maybe it would be wise to move them accordingly. 3) On POSIX systems, provide raise(3) and kill(3) functions to respectively send a signal to the current process and send a signal to a child. Sending signals to unrelated process should probably not take place in Boost.Process but rather in Boost.Interprocess 4) On POSIX systems, when a process dies it becomes a zombie process until wait() is called. Since wait() blocks, things may become tricky if there are a lot of child process. When a process die, the SIGCHLD signal is sent to his creator. It might be nice to use that by setting up a SIGCHLD signal handler which calls wait() when this signal is received. Since a similar problem exists on Windows, Boost.Process should provide a similar solution on this platform, but I've not yet thought about a possible design for it. It might be also useful to provide a way to activate/deactivate this feature, for example with a macro BOOST_MANAGES_DEAD_PROCESS 5) Right now, boost::process::wait_children() returns the first exit code which is not equal to EXIT_SUCCESS, and if there are more than one process which finished abnormally, return values of those child processes are ignored. I think we could improve that by returning for example a vector<boost::process::status> instead of just one boost::process::status. Doing that, we can retrieve all the status codes. It might be useful to define a way to toggle on/off 6) Actually in Boost.Process, if the developer wants to be able to do asynchronous operations on Windows he has to define the BOOST_PROCESS_WINDOWS_USE_NAMED_PIPE macro. By doing so, it makes Boost.Process on Windows create named pipe for all streams even if asynchronous operations are not used in all of them. First of all I propose to add a boost::process::anonymous_pipe class to Boost.Process, and a boost::process::named_pipe class to Boost.Interprocess (because named pipe can be used between unrelated process). After that the developer should be able to choose between anonymous pipe or named pipe on a per-stream basis (but of course asynchronous operations will only work on streams using named pipes). Thanks for reading, it'd be nice if someone accept to comment my ideas Moncef Mechri. [1] http://fz-corp.net/?p=505

5 11

[Build] How to find a library (ICU)?
by Artyom 29 Mar '10

29 Mar '10

Hello, I'm trying to convert CMake build system for Boost.Locale to Boost.Build one. I have one obvious issue: how do find a library? How do I convert this CMake code to Boost.Build one: if(MSVC AND "${CMAKE_BUILD_TYPE}" STREQUAL "Debug") set(ICU_SUFFIX "d") endif() find_library(ICU_UC icuuc${ICU_SUFFIX}) find_library(ICU_DATA icudt NAMES icudata) find_library(ICU_I18N icuin${ICU_SUFFIX} NAMES icui18n${ICU_SUFFIX}) find_path(ICU_INCLUDE_DIR unicode/unistr.h) Note: I search for icuuc or icuucd under debug/msvc icuin or icui18n or icuind under debug/msvc icudata or icudt Also I need the build to fail or disable library if ICU not found. I've looked into the Jamfile of regex... but it does not look correctly for debug icu version when debug build is done! (And actually this is a bug). Also the code looks like a hack. Is there any specific way do to this? Thanks, Artyom

4 6

boost GSoC XML
by Qingli Ma 29 Mar '10

29 Mar '10

Hi ! I have studied some XML parses both in C++ and Java. After comparing with each other, I think that the API interface are more or less the same, however the performance and the complexity of programming is different. So I think mine is to improve the performance and make XML related programming easier. I decide that I am going to make a backend that supports the Reader and the dom interface. I've asked advice from my teachers and he think I am capable of such a job. Thank you!

2 2

New Boost.XInt Library, request preliminary review
by Chad Nelson 28 Mar '10

28 Mar '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I'm a long-time user (and admirer) of the Boost libraries, and I've just uploaded a new one to the Boost Vault for consideration: the Extended Integer (XInt) library, a unlimited-precision integer library that I've been working on for the last few months. I'd like to request a preliminary review of it, please. I know I was supposed to "determine interest" first, but I've seen posts going back at least five years, expressing a desire for such a library, so I didn't think that was really necessary in this case. :-) It's not perfect. The code is complete, as is the documentation text. But it doesn't yet support auto-linking or Windows DLLs, I'm not sure how the test suite would fit into the Boost test system, and I'm not sure I've got the Jamfile correct. But it should be sufficient for experimental use and review, and I'm eager to hear what you guys think of it. (I'm writing this in the wee hours of March 26th, I hope it isn't held in the moderation queue for too long.) - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkusSQoACgkQp9x9jeZ9/wSwrACfTvCVl6bEZbiTSzZ16WnB1E6B cusAoO8eBd2Ne3cYcpdVmjUoUwFmjlVU =5Ptl -----END PGP SIGNATURE-----

9 35

[GSoC] Boost.XML
by Ilie Halip 28 Mar '10

28 Mar '10

Hi! My name is Ilie Halip, and I'm a student at the Faculty of Computer Science in Iasi, Romania. I'm really interested in this year's Summer of Code, and stumbled upon your list of ideas yesterday. I have a few questions about the Boost.XML project. First, what actually needs to be done? The project proposal isn't clear about that. If it's about parsing using DOM/SAX, using XPath queries, then the project linked from the page already does that, right? So the project would involve working with the existing sources and adding validation, tests etc (as mentioned in the README)? How much working knowledge should a student have before trying to work on such a project? I must admit I haven't used Boost, nor libxml2 in the past, so I guess I should start reading documentation about both. I am good in C++, and I've been working with XML APIs for years, so that's not a problem. But the other two (Boost+libxml2) are? Is there a coding style I should follow if I were to work for this project to conform to Boost standards? Where can I find such info? Do you have any requirements from students working with GSoC? Something like: weekly reports, blogging about their experience, maintaining a wiki page about the status of the project? And last but not least... I'm actually employed right now, but my superiors are willing to give me more than 3 months of time off to be able to work for GSoC. Is that ok? Should I ask for more? I was looking over the timeline, and thought about getting a vacation between May 15th and August 30th. Would that be enough? Is it also alright if I stop working on the project for about a week in early June? Because I have a few exams then. Regards, Ilie. P.S. You can usually find me on IRC too (nickname: ihalip).

8 27

[bgl] Manual include necessary for is_in_subset predicate
by Matthias Walter 28 Mar '10

28 Mar '10

Hi! I'm using a filtered_graph for a project, which filters edges via the is_in_subset predicate. Is it intended that one must manually include boost/graph/detail/set_adaptor.hpp for this to work? If I only include boost/graph/filtered_graph.hpp and want to use the predicate, the compiler complains about missing set_contains function. I didn't find anything about manual includes in the docs, but maybe there are reasons for it. best regards Matthias Walter

2 1

[geometry] Inclusion in the next release?
by Romain CHANU 28 Mar '10

28 Mar '10

Hi boosters, Does anyone know if the Boost Geometry Library is going to be shipped in the next release of Boost? Cheers, Romain

4 12

GSoC 2010 : BigInt
by Mario Ynocente Castro 28 Mar '10

28 Mar '10

Hi, I'm a engineering student from Peru. I'm really interested in the BigInt project for GSoC 2010, but there's a part for which I would like a better explanation, the description says : "A successful proposal will include a discussion of licensing concerns". What does it mean? I must choose the license under which the code will be released and indicate it when I submit the aplication? -- Mario Ynocente Castro 20074016B FIIS - UNI

2 5

About Boost XML
by Qingli Ma 28 Mar '10

28 Mar '10

Hi! My idea about XML is listed below: 1.I have experience on processing larege scale xml files(database files).So I feel having boost proccess large xml files in SAX model will be useful and I've make that in Java before. 2.Reading spec about all kinds of XML APIs, and improve current Boost interfaces in Boost to support all kinds of processing without thinking about the backend implemention.By this, interfaces is independent from the backend, thus dynamic backend bindings is possible. 3.Maybe we need a new backend that serves for the API interface,like libxml2.It can parse,tranverse,writer and search(XPath) the document. 4.I am graduating this summer and I'll have enough time. Have you any sugguestions for me?

2 2

[GSoC 2010] Sweepline algorithm
by Marcin Fatyga 28 Mar '10

28 Mar '10

Hello, My name is Marcin Fatyga and I am doing double degree program in computer science and mathematics on Warsaw University. I would like to participate in GSoC 2010 - I would like to implement the sweepline algorithm and use it to solve the problems related to it. In my project I would like to implement the sweepline and then use Fortune's Algorithm to solve the Voronoi Diagram's problem. Then I would provide some modifications to solve the two remaining connected problems : Delanuay triangulation and medial axis. All of these problems have many applications in differnet fields of science and solving them could be useful to may users. Though I don't have quite much experience with the boost library itself, I am particularly interested in algorithms and have some experience with both C++ and generic programming. Though there is no geometry library in current release, I can see it is in development phase. Should the project be integrated with it/use it? Best wishes Marcin Fatyga

7 9

[preprocessor] Computational complexity analysis
by Lorenzo Caminiti 28 Mar '10

28 Mar '10

Hello all: Is there a computational complexity analysis of Boost.Preprocessor data structures? This would be in terms of preprocessing time. For example: Does BOOST_PP_SEQ_ELEM() run* in O(n)? Do BOOST_PP_TUPLE_ELEM() and BOOST_PP_ARRAY_ELEM() run* in O(1)? (*) "Run" within the preprocessor so maybe "expand" is a better term... Thank you. Lorenzo

2 3

[GSoC] Some Ideas about the Boost.Process
by Felipe Tanus 27 Mar '10

27 Mar '10

Hello, I have been studying the project idea about Boost.Process for a while. Some ideas/opinions poped up in my mind and I feel like to share. Please, comment. IMHO, the best design for the library is not to split the APIs from Windows and POSIX. I Believe that boost should provide a higher abstraction level, and get rid of the platform problems. 1.The current implementation of Boost.Process library has the class boost::process::child, and two classes that inherit it, win32_child and posix_child. I don't believe that this is the best solution. There is only one concept of child in both APIs; some resources are different, it is true, but the concept is only one. For example, the call "boost::process::win32_launch()" is defined to launch a process "the windows API way", with the Win32 context. I don't see why can't we create a process with this call in a POSIX system ignoring what don't apply to it (or find some similar concept and use it instead, as named pipes<->fifos). After all, if you are using a Win32 only class, there is no way to run in linux, so if the code works or don't, it does not matter. By doing this way, we could easy a possibly port to another system. This could be done with programming practices as suggested by Vicente Botet, in a previous topic [1] 2.The wait() method, to wait a process (child actually, but this is another problem) to die, is not asynchronous. Sometimes programmers want a synchronous wait() method, so there is no motive for we to remove this. We should implement a new asynchronous wait() method. This method should not be in the asio library, because it's process specific. It may require the asio library, or the asynchronous piece should be implemented in the boost.process. I'm not sure about this, both seems good for me, so please comment. 3.About the process creation, I think the following practice from the documentation should be avoided: “Another important requirement is to always pass at least one argument to the executable. This must be the name of the executable itself”. There is no motive to require a parameter that you can deduce by yourself. The first parameter, in this case, should be implicit. 4.Would really be nice boost::process::launch() be able to receive any kind of string? This tend to let the programmer go for a single platform solution. As a multiplatform library, this may be avoided. I'm not sure about this matter as well, but if the library is here to provide a higher abstraction level, should it also accept API related types? I believe it should not. There is also another points that I would like to discuss in my GSoC proposal; They are well known problems so I'll just cite they: List and access other processes functionality Named pipes and FIFO (following the item #1, would be the same thing? Something would change? Something to be researched yet) move wait from child to process (as well as future asynchronous wait) Deal with process killing bugs (as well as any other known issue) Test platform issues. Should this be enough for a GSoC proposal? Do you have any other suggestion about what could I discuss in it? Thank you for your time, []'s [1] http://thread.gmane.org/gmane.comp.lib.boost.devel/188736 -- Felipe de Oliveira Tanus E-mail: fotanus(a)gmail.com Blog: http://www.itlife.com.br Site: http://www.inf.ufrgs.br/~fotanus/ ----- "All we have to decide is what to do with the time that is given us." - Gandalf

7 18

GSOC query for Heaps and Que
by Chirag 27 Mar '10

27 Mar '10

Hello Sir The Boost C++ library has mutable_heap and mutable_que and the current container works perfectly for basic datatypes like double , int etc but for datatypes like pointers it requires that user should have knowledge of property_map types. Sir for making mutable heaps , can we ask user for a hash function from the user for the data type he want to make the heap. This way we can hash each newly added value to heap and store pointer for that which will point to its location in the original heap. Here two problem i am facing 1) Can user provide a hash function for all data types 2) Worst case of hashing search would be O(n) though it chances are very low . I know O(n) case is not wat we are aiming to achieve but for users who dont want to get into understanding of property map they can use this heap instead , and I am thinking of giving it as a option to the already available mutable que in boost. This is just a idea I am proposing and its definately not final , I am thinking on other ways to improve it . I just want to know if it is a good option to give or not. Thanks Chirag IIT guwahati -- Life is short live it happily

1 0

Stability: More on 3 level Boost libraries
by vicente.botet 27 Mar '10

27 Mar '10

Hi, I would like to come back to the 3 level proposition but from a different point of view (stability and quality) 1st level: stable Libraries belonging to this level must be very stable, any modification on the public interface must be reviewed. The goal been that changes in these libraries don't break user code, even if they will need to recompile. Libraries can pretent to be in this level if the library use only libraries at this level, has not introduced breaking changes for a given amount of time and of course if the author wants to be constrained to have a review for changes on the public interface and to correct quicky the possible tickets. 2nd level: quite stable Libraries at this level, even if stable, introduce breaking changes from time to time. Libraries can go to this level if the library use only libraries at this level or the 1st level, after a deep review of the of the interfaces, the documentation, the implementation and the test coverage and have a reduced number of tickets since a to be defined period. 3rd level: unstable It is assumed that young libraries will have a lot of breaking changes at the public interface level. Libraries can go to this level after a review of the interfaces and the documentation. Comments are welcome, _____________________ Vicente Juan Botet Escribá

10 22

Help with GSoC; BigInt and Heaps & Queue
by Lucas Gambarra 27 Mar '10

27 Mar '10

Hi, I'm very interested in participating in GSoC. While watching the list of ideas proposed by the boost C++ Libraries, I was really interested in two of them: 'Heaps & Queues' and 'BigInt'. I am a student of Computing Sciences of the Federal University of Paraíba - Brazil. I wanted information on how to contact the mentortes of such projects. Could someone help me? Forgive me for my English. ------------ --------- --------- --------- --------- --------- --------- --------- -------- Lucas Lucena Gambarra Estagiário no Laboratório de Sistemas Digitais (LASID - UFPB) Projeto Brazil-IP 2010 email: lucas.ufpb(a)gmail.com.br MSN: lucas_gambarra@hotmail. com

2 1

The problems with Boost development
by Vladimir Prus 27 Mar '10

27 Mar '10

Hello, in a recent post, Dave listed a few things that he thinks are wrong with Boost development, at present, quoting: I know I'm not the first person to notice that, as Boost has grown, it has become harder and harder to manage, Subversion is getting slow, our issue tracker is full to overflowing, and the release process is a full-time job. It seems to be important, right now, to discuss whether this problems are real, and what problems are most important. So, I would like to ask that everybody who is somehow involved in *development* -- whether in writing code, triaging bugs, sending patches, or managing thing, list three most important problems with Boost now. Please keep the items to a sentence or two, so that we can easily collect the problems. Here's my take: - Unmaintained components. Many authors are no longer active, and we have no procedures for taking over. - Reviews that are getting rare and, IMO, less interesting then before. - Turnaround time of test results Thanks, Volodya

29 67

[variant] compatibility with move-constructible objects
by Zachary Turner 26 Mar '10

26 Mar '10

I have the following rough sequence of typedefs: struct empty {}; typedef std::unique_ptr<foo> foo_ptr; typedef std::unique_ptr<bar> bar_ptr; typedef std::vector<foo_ptr> foo_ptr_vec; typedef std::vector<bar_ptr> bar_ptr_vec; typedef std::variant<empty, foo_ptr_vec, bar_ptr_vec> my_variant; I then declare an instance of my_variant in a class, and make the class moveable and noncopyable. class my_class { my_class(const my_class&); my_class& my_class(const my_class&); my_variant v_; public: my_class(my_class&& other) : v_(std::move(other.v_)) { } }; I cannot get this to compile under MSVC 10 and boost 1.42. In theory I don't see why this shouldn't be ok. Even though the objects are not copy-constructible due to unique_ptr, they are move constructible. The errors are quite long, but you can see it's trying to invoke vector::operator= from within the variant code. Is this just a technical limitation of variant, or a bug? 1> behavior_collection.cpp 1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(2144): error C2248: 'behavior_collection::behavior_impl<Output>::operator =' : cannot access private member declared in class 'behavior_collection::behavior_impl<Output>' 1> with 1> [ 1> Output=kinematic_output 1> ] 1> c:\users\zach\documents\visual studio 2010\projects\dxdemo\dxdemo\behavior_collection.h(15) : see declaration of 'behavior_collection::behavior_impl<Output>::operator =' 1> with 1> [ 1> Output=kinematic_output 1> ] 1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(2165) : see reference to function template instantiation '_OutIt std::_Copy_impl<_InIt,_OutIt>(_InIt,_InIt,_OutIt,std::_Nonscalar_ptr_iterator_tag)' being compiled 1> with 1> [ 1> _OutIt=behavior_collection::behavior_impl<kinematic_output> *, 1> _InIt=behavior_collection::behavior_impl<kinematic_output> * 1> ] 1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\vector(719) : see reference to function template instantiation '_OutIt std::_Copy_impl<behavior_collection::behavior_impl<Output>*,behavior_collection::behavior_impl<Output>*>(_InIt,_InIt,_OutIt)' being compiled 1> with 1> [ 1> _OutIt=behavior_collection::behavior_impl<kinematic_output> *, 1> Output=kinematic_output, 1> _InIt=behavior_collection::behavior_impl<kinematic_output> * 1> ] 1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\vector(709) : while compiling class template member function 'std::vector<_Ty> &std::vector<_Ty>::operator =(const std::vector<_Ty> &)' 1> with 1> [ 1> _Ty=behavior_collection::behavior_impl<kinematic_output> 1> ] 1> C:\dev\boost\1.42.0\boost/type_traits/is_pod.hpp(34) : see reference to class template instantiation 'std::vector<_Ty>' being compiled 1> with 1> [ 1> _Ty=behavior_collection::behavior_impl<kinematic_output> 1> ] 1> C:\dev\boost\1.42.0\boost/type_traits/is_pod.hpp(129) : see reference to class template instantiation 'boost::detail::is_pod_impl<T>' being compiled 1> with 1> [ 1> T=std::vector<behavior_collection::behavior_impl<kinematic_output>> 1> ] 1> C:\dev\boost\1.42.0\boost/type_traits/has_trivial_constructor.hpp(27) : see reference to class template instantiation 'boost::is_pod<T>' being compiled 1> with 1> [ 1> T=std::vector<behavior_collection::behavior_impl<kinematic_output>> 1> ] 1> C:\dev\boost\1.42.0\boost/type_traits/has_trivial_constructor.hpp(36) : see reference to class template instantiation 'boost::detail::has_trivial_ctor_impl<T>' being compiled 1> with 1> [ 1> T=std::vector<behavior_collection::behavior_impl<kinematic_output>> 1> ] 1> C:\dev\boost\1.42.0\boost/type_traits/has_nothrow_constructor.hpp(23) : see reference to class template instantiation 'boost::has_trivial_constructor<T>' being compiled 1> with 1> [ 1> T=std::vector<behavior_collection::behavior_impl<kinematic_output>> 1> ] 1> C:\dev\boost\1.42.0\boost/type_traits/has_nothrow_constructor.hpp(32) : see reference to class template instantiation 'boost::detail::has_nothrow_constructor_imp<T>' being compiled 1> with 1> [ 1> T=std::vector<behavior_collection::behavior_impl<kinematic_output>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/not.hpp(41) : see reference to class template instantiation 'boost::has_nothrow_constructor<T>' being compiled 1> with 1> [ 1> T=std::vector<behavior_collection::behavior_impl<kinematic_output>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/aux_/preprocessed/plain/and.hpp(25) : see reference to class template instantiation 'boost::mpl::not_<T>' being compiled 1> with 1> [ 1> T=boost::has_nothrow_constructor<std::vector<behavior_collection::behavior_impl<kinematic_output>>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/aux_/preprocessed/plain/and.hpp(55) : see reference to class template instantiation 'boost::mpl::aux::and_impl<C_,T1,T2,T3,T4>' being compiled 1> with 1> [ 1> C_=true, 1> T1=boost::mpl::apply1<boost::mpl::protect<boost::detail::variant::find_fallback_type_pred>,boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>>>, 1> T2=boost::mpl::true_, 1> T3=boost::mpl::true_, 1> T4=boost::mpl::true_ 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/iter_fold_if.hpp(46) : see reference to class template instantiation 'boost::mpl::and_<T1,T2>' being compiled 1> with 1> [ 1> T1=boost::mpl::not_<boost::is_same<boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>>,boost::mpl::l_iter<boost::mpl::l_end>>>, 1> T2=boost::mpl::apply1<boost::mpl::protect<boost::detail::variant::find_fallback_type_pred>,boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/aux_/preprocessed/plain/apply_wrap.hpp(49) : see reference to class template instantiation 'boost::mpl::aux::iter_fold_if_pred<Predicate,LastIterator>::apply<State,Iterator>' being compiled 1> with 1> [ 1> Predicate=boost::mpl::protect<boost::detail::variant::find_fallback_type_pred>, 1> LastIterator=boost::mpl::l_iter<boost::mpl::l_end>, 1> State=boost::mpl::int_<1>, 1> Iterator=boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/aux_/preprocessed/plain/apply.hpp(63) : see reference to class template instantiation 'boost::mpl::apply_wrap2<F,T1,T2>' being compiled 1> with 1> [ 1> F=boost::mpl::protect<boost::mpl::aux::iter_fold_if_pred<boost::mpl::protect<boost::detail::variant::find_fallback_type_pred>,boost::mpl::l_iter<boost::mpl::l_end>>>, 1> T1=boost::mpl::int_<1>, 1> T2=boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/aux_/preprocessed/plain/iter_fold_if_impl.hpp(62) : see reference to class template instantiation 'boost::mpl::apply2<F,T1,T2>' being compiled 1> with 1> [ 1> F=boost::mpl::protect<boost::mpl::aux::iter_fold_if_pred<boost::mpl::protect<boost::detail::variant::find_fallback_type_pred>,boost::mpl::l_iter<boost::mpl::l_end>>>, 1> T1=boost::mpl::int_<1>, 1> T2=boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/aux_/preprocessed/plain/iter_fold_if_impl.hpp(102) : see reference to class template instantiation 'boost::mpl::aux::iter_fold_if_forward_step<Iterator,State,ForwardOp,Predicate>' being compiled 1> with 1> [ 1> Iterator=boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>>, 1> State=boost::mpl::int_<1>, 1> ForwardOp=boost::mpl::protect<boost::mpl::next<boost::mpl::na>>, 1> Predicate=boost::mpl::protect<boost::mpl::aux::iter_fold_if_pred<boost::mpl::protect<boost::detail::variant::find_fallback_type_pred>,boost::mpl::l_iter<boost::mpl::l_end>>> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/iter_fold_if.hpp(94) : see reference to class template instantiation 'boost::mpl::aux::iter_fold_if_impl<Iterator,State,ForwardOp,ForwardPredicate,BackwardOp,BackwardPredicate>' being compiled 1> with 1> [ 1> Iterator=boost::mpl::l_iter<boost::mpl::l_item<boost::mpl::long_<3>,behavior_collection::null_behavior,boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>>>, 1> State=boost::mpl::int_<0>, 1> ForwardOp=boost::mpl::protect<boost::mpl::next<boost::mpl::na>>, 1> ForwardPredicate=boost::mpl::protect<boost::mpl::aux::iter_fold_if_pred<boost::mpl::protect<boost::detail::variant::find_fallback_type_pred>,boost::mpl::l_iter<boost::mpl::l_end>>>, 1> BackwardOp=boost::mpl::na, 1> BackwardPredicate=boost::mpl::always<boost::mpl::false_> 1> ] 1> C:\dev\boost\1.42.0\boost/mpl/iter_fold_if.hpp(102) : see reference to class template instantiation 'boost::mpl::iter_fold_if<Sequence,State,ForwardOp,ForwardPredicate>::result_' being compiled 1> with 1> [ 1> Sequence=boost::mpl::l_item<boost::mpl::long_<3>,behavior_collection::null_behavior,boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>>, 1> State=boost::mpl::int_<0>, 1> ForwardOp=boost::mpl::protect<boost::mpl::next<boost::mpl::na>>, 1> ForwardPredicate=boost::mpl::protect<boost::detail::variant::find_fallback_type_pred> 1> ] 1> C:\dev\boost\1.42.0\boost/variant/variant.hpp(170) : see reference to class template instantiation 'boost::mpl::iter_fold_if<Sequence,State,ForwardOp,ForwardPredicate>' being compiled 1> with 1> [ 1> Sequence=boost::mpl::l_item<boost::mpl::long_<3>,behavior_collection::null_behavior,boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>>, 1> State=boost::mpl::int_<0>, 1> ForwardOp=boost::mpl::protect<boost::mpl::next<boost::mpl::na>>, 1> ForwardPredicate=boost::mpl::protect<boost::detail::variant::find_fallback_type_pred> 1> ] 1> C:\dev\boost\1.42.0\boost/variant/variant.hpp(1079) : see reference to class template instantiation 'boost::detail::variant::find_fallback_type<Types>' being compiled 1> with 1> [ 1> Types=boost::mpl::l_item<boost::mpl::long_<3>,behavior_collection::null_behavior,boost::mpl::l_item<boost::mpl::long_<2>,std::vector<behavior_collection::behavior_impl<kinematic_output>>,boost::mpl::l_item<boost::mpl::long_<1>,std::vector<behavior_collection::behavior_impl<dynamic_output>>,boost::mpl::l_end>>> 1> ] 1> c:\users\zach\documents\visual studio 2010\projects\dxdemo\dxdemo\behavior_collection.h(39) : see reference to class template instantiation 'boost::variant<T0_,T1,T2>' being compiled 1> with 1> [ 1> T0_=behavior_collection::null_behavior, 1> T1=behavior_collection::kinematic_behaviors, 1> T2=behavior_collection::dynamic_behaviors 1> ]

2 3

Re: [boost] Library dependencies and intrer-library code reuse
by Brian Wood 26 Mar '10

26 Mar '10

Dave Abrahams writes: At Fri, 26 Mar 2010 03:45:51 -0700 (PDT), Vicente Botet Escriba wrote: <snip whole thread> > > > > > > > Please don't top post. > > Vicente Please don't overquote. just-for-symmetry-ly y'rs, Dave, are you aware your messages are being duplicated on the list? I've seen that a few times with others, but often it is the case with your messages. I would also appreciate it if people would stop with the top posting and excessive quoting. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

2 1

GSoC Parallel BGP implementation
by Naresh Reddy Sankapelly 26 Mar '10

26 Mar '10

hi, I am naresh, a student pursuing B.Tech 4th year from Indian Institute of Information Technology- Allahabad, India. I am keen to get involved in open source project development as part of GSoC 2010 with Boost. I went though the ideas list provided in the site. I'm interested to work on parallel graph algorithms for BGL in particular with graph connectives project. I took this because I have worked on parallelizing graph algorithms as a part of my Parallel Computing course. I would be happy to know few things. 1. Can I work on library of my own for parallel computing like Intel's TBB ?or should I use MPI only? 2. It would be helpful for me if I can have one more student working on sequential part of graph algorithms. Is it allowed? If it is, and any one interested please reply me back. 3. Can I get few more details of Computer Vision algorithms? I look forward to your replies soon. Thanks

3 4

Is there anyone can tell me who is in charge of the Google Summer of Code in boost community for this year
by Qingli Ma 26 Mar '10

26 Mar '10

Hello , I want to take part in the Google Summer of Code( http://socghop.appspot.com/site/home/site) but can not find who I should contact. XML is very useful.I have used Jdom,dom and SAX for XML.Therefor,I want get the boost library support XML operations better. So ,is there anyone can tell me who should I contact with to tell my ideas and ask for suggestions.

4 3

Should Boost adopt pimpl/d-pointer as much as it can?
by Artyom 26 Mar '10

26 Mar '10

Hello, There are recently lots of discussions about current development issues. I would like to point to one small but extremely important issue (from user point of view). Boost has too many logic in header part of library, by meaning too much I mean painfully too much. I think that Boost should adopt as policy: 1) All implementation related code **should** be put in sources. 2) Any non-template based class should have opaque/d/pimpl pointer in its body. Why? I give you a simple example: one of the pearls of Boost: Boost.Asio is one of most painful libraries to use. I created a simple example of echo server written with Boost.Asio and written with a small pimpl-wrapped Boost.Asio (I had written myself as proof of concept - that uses boost.asio in implementation): http://art-blog.no-ip.info/files/asio_pimpl.tar.gz These are results of compilation times with gcc-4.3 (seconds): -O0 -O2 -O3 -O2+link asio 2.56 4.65 4.96 4.75 pimpl 0.59 0.85 0.89 0.94 diff *4.3 *5.5 *5.6 *5.05 And this is trivial echo server. When the code gets larger and bigger it becomes even more painful. For me, compilation of components based on Asio is total nightmare because of unacceptable compilation times. Another issue is executable size. I had took same echo sever placed in 10 object compiled under different namespaces once I did it with Boost.Asio and then I did it with pimpl-ed Asio. Result (liked executable size with gcc-4.3): Build Size (-Os stripped) Asio: 245K Pimpl: 190K ---------------------------- Conclusions: ============ There are too many good libraries (Asio as good example) that use headers too much or headers only, this terribly increases compilation times and makes executable sizes much bigger (this is especially relevant for embedded systems). Should Boost wellcome pimpled libraries more? I think yes. It would solve two problems: 1. It would give faster compilation times. 2. It would allow to provide changes easily without breaking compatibility (even would allow to provide backward ABI compatibility) Dear Boosters. What do you think about? Artyom

17 36

Re: [boost] GSOC query for Heaps and Que
by Andrew Sutton 26 Mar '10

26 Mar '10

Hi Chirag, 1) Relaxed Fibbonacci Heaps by Chandrasekhar Boyapati C. Pandu Rangan > 2) Relaxed Weak Que by Amr Elmasry Claus Jensen Jyrki Katajainen > 3) Soft Heap by Bernand Chazelle > > Please tell can I add these datastuctures to my proposal for GSOC . > I think those data structures are in the spirit of the proposal. It would not be a bad idea. > I also want to add radix tree and generalized version of union find > datastructure into my proposal. > Will it be a good proposal ? > That might be a little ambitious for a 3 month project. I would try to keep your proposal a little more focused. Andrew Sutton andrew.n.sutton(a)gmail.com

1 0

Re: [boost] [gil] Can not open test.jpg
by Mariusz Kwiczala 26 Mar '10

26 Mar '10

Christian, >>This file needs to be swapped out. Will do that next week. >Done. Thank you. >Marius, do you wanna try out it the new gil::io? It's located here: >http://gil-contributions.googlecode.com/svn/trunk/gil_2/boost/gil/extension / Will it be available in 1.43? >Let me know if you have questions, problems, etc. I have one suggestion: Gil::Io extensions do not work without required libjpeg libpng, libtiff ... There is no way to run examples from "boost_1_42_0\libs\gil\example" without required libs. There are problems to match boost::gil and "external graphlibs" i.e. http://stackoverflow.com/questions/2442335/libpng-boostgil-png-infopp-null-n ot-found I think that libjpeg libpng, libtiff libs should be included into boost and compiled with use bjam. Regards, Mariusz

8 34

Re: [boost] [transact] code in sandbox
by vicente.botet 26 Mar '10

26 Mar '10

----- Original Message ----- From: <strasser(a)uni-bremen.de> To: "vicente.botet" <vicente.botet(a)wanadoo.fr> Sent: Friday, February 12, 2010 2:00 AM Subject: Re: Re:[boost] [transact] code in sandbox > Zitat von "vicente.botet" <vicente.botet(a)wanadoo.fr>: >> IMO the transaction must be accesible during the handling of the exceptions. > > why? I see one reason in your examples (although I don't understand > force_to_abort, maybe that's another one, see below), and that is > committing on exception: > >>>> #define BOOST_TRANSACT_BASIC_RETHROW(TXMGR, TX, E) \\ >>>> catch (E&) {(TX).commit(); throw;} > > why can't the user create his own try/catch block for that?: > (using your syntax) > BOOST_TRANSACT_ATOMIC(_) { > try{ > ... > }catch(my_exc &){ > _.commit(); > } > }BOOST_TRANSACT_COMMIT(); Yes this is always possible. However, transactions and exception handling are used for the same goal, recover from errors. Thus it is interesting to handle them in the same way and in a single try-cactch block. >> _.force_to_abort(); > > what does this do? retry the transaction but make sure it fails? why? > why don't you just go ahead and throw an exception that is not caught > inside the transaction scope? When the user wants to undo whatever the transacton block did, the simple way is to abort the transaction. Don't forget that transactions can be used in a single-threaded application to make exception-safe code. >>> at some point I think the macros loose their benefit and you might >>> just as well write the loop yourself. e.g. if you need to execute >>> custom code on retry. >> >> You are right. The specific macros are not important. What is >> important is that the provided macros can be extended naturaly. > > that's what I'm not so sure of. if you need to control the number of > retries or execute custom code on retry, why don't you just write this > instead of using macros: > > for(int c=0;c<10;++c){ > try{ > transaction tx; > ... > tx.commit(); > break; > }catch(isolation_exceotion &e){ > e.unwind(); > std::cerr << "my custom retry code\n"; > } > } > > doesn't seem a whole lot more verbose to me. > but I'm not against adding more macros for convenience. the one thing > I would like is not complicating the simplest use case. the user > shouldn't have to to add something like "(_)" if he doesn't need it > and has no idea what it is there for. the default use case should be > as simple as possible. I would like also to don't need to add a transaction variable name. I need the name of the transaction variables to implement break and continue in a language-like. From my side, the inclusion of the macros is to be close to what the user will write if the language provided some specific transaction constructs. The user is always free to use directly the class interface. The question is what is the simple case. for an INNER transaction Boost.STM provides a macro #define BOOST_STM_USE_ATOMIC(TX) \ for (boost::stm::transaction TX; \ ! TX.committed() \ && TX.restart(); \ TX.commit()) that the user ca use like BOOST_STM_USE_ATOMIC(_) { // transaction statement } In this case every exception scape the transaction block, and will be managed by the outer transaction block. This is simple, recall a possible language statement transaction { // transaction statements } The parameter is needed only if we want to return from the transaction block. If needed we can add a simple #define BOOST_STM_INNER_TRANSACTION \ for (boost::stm::transaction __TX; \ ! __TX.committed() \ && __TX.restart(); \ __TX.commit()) use as follows BOOST_STM_INNER_TRANSACTION { // transaction statement } As I said in a preceding post, we can provide initialy both sets of macros and see which set the users use more often. Best, Vicente

7 48

About adding XML API in the boost.
by Qingli Ma 26 Mar '10

26 Mar '10

Hello,everyone! I am from china and want to take part in the boost commnnity. Support for XML is limited in boost, so I want to do something about this. Also I see some information at https://svn.boost.org/trac/boost/wiki/SoC2010. I wish to take part in the Google Summer of Code(http://socghop.appspot.com/). Can you give me some ideas about that?Who should I contact with? Thank you for your sugguestion!

2 1

GSOC - Boost.XML
by Shrinidhi Hudli 26 Mar '10

26 Mar '10

Hello, I am interested to send a proposal to work on Boost.XML for GSOC 2010. I have a couple of questions: 1. Would it make sense to provide C++ binding for XML using XSD? This would make it much more convenient that using parsers explicitly. 2. Is the project mostly to develop an abstraction for the backend parsers so that different parsers can be "plugged-in"? Thanks for the clarification. -- Shrinidhi Hudli

2 1

Re: [boost] [lexical_cast] A non-throwing lexical cast? [Was: 5Observations - My experience with the boost libraries]
by pete＠pcbartlett.com 26 Mar '10

26 Mar '10

On Fri 26/03/10 01:25 , Gennadiy Rozental <rogeeff(a)gmail.com> wrote: > Rene Rivera writes: > > > > Tom Brinkman wrote: > > > boost::lexical_cast_no_throw() > > > > Or.. > > > > template > > T lexical_cast(const S & arg, const T & error_default_value); > > > I've implemented later in my own version of lexical cast. In 99% of > the time > this is exactly what I need: either convert string to number or take > this > default value. Another good consequence is that I do not need > template parameter > anymore. > Gennadiy Looking at the various threads it seems like three different behaviours in the event of conversion failure have been requested. - Default Value - boost::system::error_code - throw custom exception. So this would suggest an interface like template< typename T , typename S, typename FailureHandler > lexical_cast(S const& arg , FailureHandler fh) with specializations if FailureHandler = T or FailureHandler = boost::system::error_code&. You do lose your "good consequence" with this formulation though. As I said in another message, the original author of lexical_cast has said several times over the years that doing something like this is too far from the spirit of a *_cast, though, so if it gets into Boost I think it will have to be in the StringConvert library.

1 0

[lexical_cast] A non-throwing lexical cast? [Was: 5 Observations - My experience with the boost libraries]
by pete＠pcbartlett.com 26 Mar '10

26 Mar '10

On Wed 24/03/10 03:40 , Jonathan Franklin <franklin.jonathan(a)gmail.com> wrote: > On Tue, Mar 23, 2010 at 9:31 PM, Tom Brinkman wrote: > > ... All I'm saying is that in the real world, most > > projects are mixed C/C++ and that the needs of both communities > need > > to be addressed if boost is going to remain relevent. > For the sake of not arguing, let's assume that your assertion is > true. > Let's hear your *actionable* proposal for improving boost. E.g. > show > us the better interface for <insert Boost library here> Taking an example from way back at the start othis thread, in my personal experience a non-throwing version of lexical_cast<> would be very nice. If I look at the cases where I pass user data through my libraries into boost libraries without some pre-validation, there are very few, and naturally these are the cases where the validation would as difficult as the "parse": - boost::spirit::phrase_parse - Just returns a true/false, and I build a nice context-driven error message myself if necessary. - boost::lexical_cast - throws. Almost always needs to be caught and re-thrown.

7 10

Re: [boost] [lexical_cast] A non-throwing lexical cast? [Was: 5 Observations - My experience with the boost libraries]
by Pete Bartlett 25 Mar '10

25 Mar '10

Kim Barrett wrote: > On Mar 24, 2010, at 5:20 PM, Bruno Santos wrote: >>boost::bad_lexical_cast is not derived from >>my_project::invalid_user_input o or whatever. This happens a lot with >>boost::lexical_cast. >> >If the user data is data that comes from a file or user interface, I >agree in your assertion. > >However, if it's from someone using your library, it's an obvious >programming error, doing exception translation in this case is >pointless. Agreed, but the source of data in a text format that should be a numeric format is much more likely to be end-user systems and inputs rather than that created within a client application, IME. >Anyway, in my opinion, passing a boost::system::error_code as the second >parameter for a non throwing version would be the best solution. As Jeff points out, others have been here before us, and it looks like the proposed Boost.StringConvert is the result of prior discussions. Perhaps our energies would be best spent making sure that library meets our needs by being reviewers or even the review manager [one is still needed, according to the schedule]. Pete

1 0

GSOC 2010 Boost-Graph
by Chinmaya Poswalia 25 Mar '10

25 Mar '10

Hi Myself Chinmaya Poswalia Computer Science an Engineering B.Tech, Indian Institute of Technology, Guwahati I am finding all the graph topic(my favorite topic to work on) very interesting that's why i asked a lot of questions regarding all in one mail. - i want to work on semantic graph - how about maintaining an adjacency list, denote V as nodes and E as edges, so the space complexity will be O(V+E). - Also we can employ pointers of type void* to point to edges/vertices of different types so as to maintain the graph of different edge and vertex types. - rather than employing a vector in each node and edge either we should allocate space during insertion or we maintain the size of vector array by ourself. - Through generic programming, all the operations being implemented on graph up till now will be made applicable on these new members of the library. - various functions that can be induced on these graphs are 1. Distribution of node degree 2. finding clustering co-efficient of semantic graph 3. relevance of a link and node 4. scale on semantic graph 5. disparity of connected types/dispersion co-efficient. - Semantic graph are generating huge level of importance in networking (network semantics on web), video screening, statistical analysis of data,etc so it will be a great thing to work on it. Can you suggest some more links to read on for these I am working on my proposal about the graph and your help is crucial for me. With regards Chinmaya

2 1

[log] Boost.Log formal review result
by Vladimir Prus 25 Mar '10

25 Mar '10

First of all, I would like to thank Andrey for this submission and the active discussion during the review. I also would like to thank everybody who participated in the review. The comments on the library were generally positive. Several reviewers have tried it in practical projects already, and found it superior to other libraries. It clearly will benefit the users of Boost right away. Therefore, the library is accepted. Congratulations, Andrey! On the other hand, some concerns about the ease of use and performance and implementation details were raised. Of those, some can be easily addressed as part of normal maintenance, while some seem to require significant rework and may change the library quite consirably. Therefore, the library is accepted subject to several conditions -- listed below under "Critical issues". Because the changes can be large, I think a mini-require is required when those issues are addressed. To avoid delays, it's probably not necessary to formally schedule and conduct a mini-review -- just posting a email asking for discussion will be sufficient. Statistics ========== There were roughly 300 emails during formal review (I have a mbox archive if anybody needs it). The following persons submitted a review with a vote. Some of votes are "provisional", this is not reflected below, but affects the list of critical issues below. - Boris Schaeling (yes) - Roland Bock (yes) - Ralf Globisch (yes) - Sean Chittenden (yes) - Darryl Green (no) - Tom Brinkman (no) - Barend (yes) - Sam Gundry (yes) - Vicente Botet (yes) - Robert Stewart (yes) - Alexander Arhipenko (yes) - "M-Square" (yes) Critical issues =============== These issues must be addressed, and be passed through informal mini-review, before the library can be added to SVN. - It appears that the 'trivial' logging is not sufficiently good to just take and use. The library should provide an out-of-the-box mechanism that: - supports channel/severity attributes, without creating new logger for each severity. It also should be possible to filter out specific channel by essentially poking at some "map", and without manually composing a new filter that checks for a set of allowed channels sequentally. I believe that at least Christian, Roland, Robert and myself requested this. - has no observable effect on compile time. One second (or more) that trivial.hpp imposes is not acceptable. - outputs to console by default, but permits changing that - outputs only component/severity/message by default, but probably permits changing that. - By default, the library should try hard to continue working no matter what errors happen during processign a log record -- including things like invalid attribute names or types, or other exceptions. - The library should not reinvent wheels. In particular, custom implementations of TSS and RW mutex seems like a very bad idea. Use of a custom lambda implementation was pointed by many as not great -- we already have a couple, so let's not add more to the mix. - Library interface is too geared towards lambda. In particular, implementing formatters/filters as free-standing functions appears to require considerably more code. In particular, it should be possible to access an attribute using a single function call. Also, logging::extract taking a lambda for callback complicates matters, it's desirable to have a more direct variant. Important issues ================ These issues are important enough to be mentioned here, but can be addressed as convenient. - The reported run-time performance can be improved. In particular the performance with date attributes seems scary and 2x slowdown relative to some other library in the 'most records are filtered out' case is also concerning. - I don't think it was satisfactory explained why 'attr' exists in two namespaces, as opposed to being a single type that is used for both formatting and filtering. Other notes =========== These issues seem important and should be considered, but might not even be fixable within the current design. - Several reviewers said the library is "too flexible" and this makes it harder to understand. Probably nothing can be done about that at this point, but interesting data point notwithstanding. - It was suggested that the library include an API that another Boost log may use in a way that permits plugging another logging library should end user of a Boost so desire. This seems a good idea, but I think it's up to Andrey to implement such API or not. - Alternative design approaches were proposed, in particular (i) permitting user log records and templating/basing other components on a user-defined record type and (ii) using compile-time indexing to access attributes. Also, it was proposed that named parameters not be necessary to use the library, and a more conventional interface be available. It does not seem that implementing those suggestions is fully possible without writing a different library from scratch, so it's up to Andrey to consider those proposals. - It was suggested to use newer Spirit to address poor compile times for the library itself. Thanks, Volodya

4 4

[log] How to derive from a logger
by Andreas Huber 25 Mar '10

25 Mar '10

Hi Andrey As discussed earlier, we're kind of desperate to add functionality to a logger class provided by Boost.Log. Instead of duplicating severity_channel_logger_mt, I'm wondering whether it's a good idea to derive from it, as follows: class Logger : public ::boost::log::sources::severity_channel_logger_mt< Severity > { public: typedef ::boost::log::sources::severity_channel_logger_mt< Severity > logger_base; BOOST_LOG_FORWARD_LOGGER_CONSTRUCTORS(Tracer) void SetMinimumSeverity(Severity severity); Severity GetMinimumSeverity(); private: Severity minimumSeverity; }; Elsewhere we'd use this class as follows: BOOST_LOG_DECLARE_GLOBAL_LOGGER_INIT(Whatever, Logger) { // ... } It seems to work, but is this a good idea? Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 4

Re: [boost] GSOC 2010 Boost-Graph
by Chinmaya Poswalia 25 Mar '10

25 Mar '10

On Thu, Mar 25, 2010 at 3:21 AM, Chinmaya Poswalia < chinmaya.poswalia(a)gmail.com> wrote: > Hi Andrew, > I am finding all the graph topic(my favorite topic to work on) very > interesting that's why i asked a lot of questions regarding all in one mail. > > > - i want to work on semantic graph > > > - how about maintaining an adjacency list, denote V as nodes and E as > edges, so the space complexity will be O(V+E). > > > - Also we can employ pointers of type void* to point to edges/vertices > of different types so as to maintain the graph of different edge and vertex > types. > > > - rather than employing a vector in each node and edge either we should > allocate space during insertion or we maintain the size of vector array by > ourself. > > > - Through generic programming, all the operations being implemented on > graph up till now will be made applicable on these new members of the > library. > - various functions that can be induced on these graphs are > > > 1. Distribution of node degree > 2. finding clustering co-efficient of semantic graph > 3. relevance of a link and node > 4. scale on semantic graph > 5. disparity of connected types/dispersion co-efficient. > > > - Semantic graph are generating huge level of importance in networking > (network semantics on web), video screening, statistical analysis of > data,etc so it will be a great thing to work on it. > > Can you suggest some more links to read on for these > > > > I am working on my proposal about the graph and your help is crucial for > me. > With regards > Chinmaya >

1 0

GSOC Proposal for BIGINT - Long Mail
by swagat konchada 25 Mar '10

25 Mar '10

I had a look around in the Boost Sandbox and I found a BigInt implementation done by zeux during GSoC 07. I had a look at the code and I wanted to know its deficiencies. I'm interested in proposing some improvements in bigint and new bigdecimal implementation that is building on this code. There are 2 questions that I wanted to ask the list before moving further on this track: 1. Is there sufficient interest for a BigDecimal proposal on the lines of the Java implementation of BigDecimal (or has there been some prior work that can be used as a foundation?) 2. What are the deficiencies of bigint that have prevented its inclusion into the Boost distribution so as to address the same as part of my GSoC proposal. I did some homework and contrasted the bigint api in Boost and Java and found some interesting things that could be done. Boost.bigint was written by zeux and he used GMP bigint's features writing the Boost.bigint code around it. I think I could learn and analyse more after having a look at GMP bigint. After all, I think Boost.bigint should be more exhaustive. -------------------------------------------------------------------------------------------------------------------------------------------------------------- Feature Boost bigint Java BigInt -------------------------------------------------------------------------------------------------------------------------------------------------------------- Constructors from | int | byte[] #byte array with 2's complement representation of the BigInt. | unsigned int | int bitlen, int certainity #random BigInt with given bit length | int64_t | | uint64_t | | char *, int base | String | string& str, int base | String, radix -------------------------------------------------------------------------------------------------------------------------------------------------------------- *Conversion from string of digits to bigint is present. However conversion from/to byte-array(2's complement notation) to/from bigint isn't. Also the generation of a random arbitrary precision bigint should be done. int bitCount() #return the no of bits in 2's complement of the bigint; int bitLength() #no of bits excluding the sign bit double doubleValue() #casting bigint to double must be done. #even casts to int, uint and int64_t, char * must be done.* -------------------------------------------------------------------------------------------------------------------------------------------------------------- Arithmetic Operators += In Java, add, subtract, multiply, etc., | -= | *= | /= | %= | |= | &= | ^= #xor | <<= | >>= | ++ #postfix & prefix | -- #postfix & prefix -------------------------------------------------------------------------------------------------------------------------------------------------------------- Unary Operators + - BigInteger[] negate() ~ BigInteger[] not() ! #is zero < int compareTo(BigInteger val) <= BigInteger max,min(BigInteger val) > >= == != -------------------------------------------------------------------------------------------------------------------------------------------------------------- *These are some bit manipulators BigInteger clearBit(int n) #not in Boost.bigint #even setBit & toggleBit could be done, with a feature of changing the precision of the bigint. BigInteger[] testBit(int n) #also bit testers l* -------------------------------------------------------------------------------------------------------------------------------------------------------------- Binary Operators + BigInteger add(BigInteger val) - * BigInteger multiply(BigInteger val) {bigint lhs, int rhs} {int lhs, bigint rhs} / BigInteger divide(BigInteger val) % BigInteger mod(BigInteger val) , BigInteger modPower(BigInteger val) | BigInteger or(BigInteger val) & BigInteger and(BigInteger val) ^ BigInteger andNot(BigInteger val) << BigInteger shiftLeft(int n) >> BigInteger shiftRight(int n) -------------------------------------------------------------------------------------------------------------------------------------------------------------- Math function overloads abs(bigint_base) BigInteger abs(int exponent) pow(bigint_base, uint64_t) BigInteger pow(int exponent) div(bigint_base lhs, bigint_base rhs, bigint_base& remainder) BigInteger[] divideAndRemainder(BigInteger val) sqrt(bigint_base) ----------No Java version for BigInterger------------ -------------------------------------------------------------------------------------------------------------------------------------------------------------- *BigInteger gcd(BigInteger val) #GCD would be one of the most important requirements for bigint #Also the Java function of bool ProbablyPrime() is very interesting and would be challenging to implement.* -------------------------------------------------------------------------------------------------------------------------------------------------------------- -- Problem is a phenomenon indicating lack of thought. Swagat Konchada

3 2

Debugging Visualizers
by Alex Miller 25 Mar '10

25 Mar '10

quoted from the ongoing "5 Observations" thread: On Tue, Mar 23, 2010 at 4:36 PM, Steven Watanabe <watanabesj(a)gmail.com>wrote: > > Perhaps you would find this useful: > https://svn.boost.org/trac/boost/wiki/DebuggerVisualizers > > It is mentioned there that the same thing could be done for GDB,etc. However, I can't seem to find anything of the sort by googling (although it's very possible I'm just searching poorly). Could anyone point me towards where docs on how to do this could be found at?

2 2

filesystem::create_directories error
by Zachary Turner 24 Mar '10

24 Mar '10

I'm trying to use boost::filesystem::create_directories() with a path of the form \\?\Volume{Guid}\foo on windows. This seems to break the filesystem library because it doesn't understand the path syntax. when recursing up the parents it removes the slash at each level, so it ends up calling boost::filesystem::exists(L"\\?\Volume{Guid}") which always returns false, I think because GetFileAttributes() requires that paths in this syntax end with a trailing \, whereas the trailing \ has been removed. I'm tempted to fix this, but I'm sure this algorithm is fragile and any change I apply is likely to break another case. Does anyone have any suggestions on how to fix this? Thanks

3 4

[log] review part 1
by Steven Watanabe 24 Mar '10

24 Mar '10

AMDG I mostly have documentation notes at this point. Andrey, since I have so many, and they're mostly fairly minor, would it be better if I made a patch for the documentation source? I think newbies should probably be replace globally with new users, since I kind of feel that the term newbie is somewhat derogatory. http://boost-log.sourceforge.net/libs/log/doc/html/log/moti.html: ================================================================================ Mismatched number: Most of the time ***applications*** ... to monitor ***its*** execution... The beginning of the second paragraph could be improved: "This is where logging may help. The application stores all essential information of its run time to log, and once something goes wrong this information can be used to analyze program behavior and make necessary corrections." Here's my suggestion: "This is where logging can help. The application stores all the essential information about its execution to a log, and when something goes wrong this information can be used to analyze the program's behavior and make the necessary corrections." "out-of-box" should be "out-of-the-box" This phrase sounds rather clunky to me: "...along with public interfaces ready to be used to extend the library." This too: "A user should be able to extend functionality of the library with regard to collecting and storing information into logs." "The library should make as least performance impact..." should be "The library should have as little performance impact..." http://boost-log.sourceforge.net/libs/log/doc/html/log/how_to_read.html: ================================================================================ In the beginning of the second paragraph, I don't like the phrase "to have the first glance on" How about something like "...to get a feel for the library's capabilities..." "The tutorial gives the overview of the library features..." Suggestion: "The tutorial gives an overview of the library's features..." "The simple form typically describes the most common and easy way to do the task and it is being recommended to be read by newbies." Suggestion: "The simple form typically describes the most common and easy way to do the task and is recommended for new users." "The advanced form usually gives an expanded way to do the same thing but with ability to do some extra customization and in-depth explanation." I would like a definite article before "ability" and I would also like "and in-depth explanation" to be placed differently so that it doesn't sound like you're saying that the user has the ability to do in-depth explanation. "This form may come handy for more experienced users and should generally be read if your needs are not satisfied with the easy way." Suggestion: "This form may come in handy for more experienced users and should generally be read if the easy way does not satisfy your needs." "This part gives description of other tools..." should be "This part gives descriptions of other tools..." "This chapter is better to be read on per-case basis." Suggestion: "This chapter is best read on a case by case basis." "there is a reference which gives the formal description of library components. " The work "description" should be plural, "descriptions". "For simplicity in the code snippets in this documentation it shall be assumed that the following namespace aliases were defined" Suggestion: "To keep the code snippets in this documentation simple, the following namespace aliases are assumed to be defined" "Aside from these namespaces the library also provides boost::log::experimental namespace." Suggestion: "In addition to these namespaces the library also provides the boost::log::experimental namespace." "and thus are not advertized for productional usage" The word "productional" should be "production" http://boost-log.sourceforge.net/libs/log/doc/html/log/supported_compilers.…: ================================================================================ "The library should build and work with a reasonably well-compliant compiler" delete "well-" http://boost-log.sourceforge.net/libs/log/doc/html/log/installation.html ================================================================================ "The library has the compiled part which should be built as described in the Getting Started article." Suggestion: "The library has a separately compiled part which should be built as described in the Getting Started guide." For BOOST_LOG_NO_THREADS "Has effect on both the library compilation and user's code compilation." Suggestion: "Affects compilation of both the library and users' code." "The macro is automatically defined if no threading support detected." add "is" before "detected" For: BOOST_LOG_USE_CHAR Same as the first comment for BOOST_LOG_NO_THREADS. (This appear many times, I won't repeat it again) For: BOOST_LOG_USE_WCHAR_T "it is assumed the both character types support is enabled" Suggestion: "support for both character types will be enabled" "Defining only one of them allows to significantly reduce binary size of the library." Suggestion: "Defining only one of them significantly reduces the binary size of the library." For BOOST_LOG_NO_QUERY_PERFORMANCE_COUNTER: "If defined, disables support for QueryPerformanceCounter API" Suggestion: "If defined, disables support for the QueryPerformanceCounter API" For BOOST_LOG_USE_NATIVE_SYSLOG: "Has effect on the library compilation stage." Suggestion: "Affects only the compilation of the library." (repeated later as well) "If for some reason the support for native SysLog API is not detected, define this macro to forcibly enable support for native SysLog." Suggestion: "If for some reason support for the native SysLog API is not detected automatically, define this macro to forcibly enable it." For BOOST_LOG_NO_SETTINGS_PARSERS_SUPPORT: "If defined, all facilities related to settings parsing are not built." Suggestion: "If defined, none of the facilities related to the parsers for settings will be built." "You may define configuration macros..." should be "You can define configuration macros..." http://boost-log.sourceforge.net/libs/log/doc/html/log/defs.html ================================================================================ For Log record: I don't like the expression "A single pack of information," although I can't think of anything better off hand. "that is candidate to be put into log" Suggestion: "that is a candidate to be put into the log" For Attribute "functional objects" should be "function objects" "which return the actual attribute value upon invoking" Suggestion: "which return the actual attribute value when invoked" For Log sink: "collected from user's application" should be "collected from the user's application" "It is sink's nature that defines where..." Suggestion: "The sink defines where..." For Log source "An entry point for user's application..." should be "An entry point for the user's application..." "upon user's request" should be "upon the user's request" For Log formatter "functional object" should be "function object" "...that forms up the final shape of the textual output" is awkward. "Some sinks, like binary logging sink" should be "Some sinks, like the binary logging sink" For Logging core "The global entity that maintains connection between" should be "The global entity that maintains the connection between" "It is mainly used on the logging library initialization stage." replace "on" with "in." http://boost-log.sourceforge.net/libs/log/doc/html/log/design.html ================================================================================ I htink "scheme" with "figure" "The library provides configuration facilities to leave only one needed version of the library to be compiled." Suggestion: "The library provides configuration facilities to compile only the version of the library needed." "For example, if your application is in critical state" should be "For example, if your application is in a critical state" "so that user sees an error message..." should be "so that the user sees an error message..." "This allows to use the library" Suggestion: "This allows use of the library" "...require users to use loggers to write logs" "use" and "log" are used too many times here. "The more generic term "log source" is used to designate the entity" Suggestion: "The more generic term "log source" designates the entity" "You may see on the scheme that the" suggestion: "You can see on the scheme that the" "and allows to quickly wipe away unneeded log records" suggestion: "and allows quickly wiping away unneeded log records" anyway, don't split infinitives. "The sink-specific filtering allows to direct log records to particular sinks." Suggestion: "The sink-specific filtering allows log records to be directed to particular sinks." "Backends, on the opposite" suggestion: "Backends, on the other hand" "most probable places of the library extension" suggestion "most likely places for extending the library" "Along with the described above primary facilities" should be "Along with the primary facilities described above" ================================================================================ Issues: Instead of compiling a narrow or wide library, why don't you use libboost_log and libboost_wlog? I agree with other comments that I saw about Attribute being a poor choice for what it does. I would prefer that the term "Attribute" should be used for what you call an "Attribute Value," and that there should be a different term, like "Attribute Extractor" for what you call an "Attribute." In Christ, Steven Watanabe

3 10

[ASIO] Create SSL stream from native socket?
by Marcel Fransen 24 Mar '10

24 Mar '10

Hi, I would like to create an ssl stream for an already accepted native socket, just like is possible with basic_stream_socket< tcp >. How should this be done? Currently there is only one ssl::stream constructor which takes one parameter that is passed to the basic_stream_socket: template <typename Arg, typename Context_Service> explicit stream(Arg& arg, basic_context<Context_Service>& context) : next_layer_(arg), service_(boost::asio::use_service<Service>(next_layer_.get_io_service())), impl_(service_.null()) { service_.create(impl_, next_layer_, context); } To be able to create an ssl stream from an existing socket we would need a constructor which passes three parameters to the basic_stream_socket like this: template <typename Arg1, typename Arg2, typename Arg3, typename Context_Service> explicit stream(Arg1& arg1, Arg2& arg2, Arg3& arg3, basic_context<Context_Service>& context) : next_layer_(arg1, arg2, arg3), service_(boost::asio::use_service<Service>(next_layer_.get_io_service())), impl_(service_.null()) { service_.create(impl_, next_layer_, context); } Would it be a problem to add constructors that passes two and three parameters to the basic_stream_socket or can this be done in another way? Kind regards, M. Fransen _________________________________________________________________ New Windows 7: Simplify what you do everyday. Find the right PC for you. http://windows.microsoft.com/shop

2 1

Re: [boost] GSOC 2010 Boost.Graph
by Chinmaya Poswalia 24 Mar '10

24 Mar '10

Topology Generators : 1) along with path, cycle, star how about also adding bus ,mesh and hybrid topologies. 2) we can also include dual, complement , line and power of a graph.

1 0

Re: [boost] GSOC 2010 Boost.Graph
by Chinmaya Poswalia 24 Mar '10

24 Mar '10

Bindings to Python : there are tools as SWIG as language bindings. is it good employ them in making the bindings. Could anyone please suggest some tutorial for binding creation. I was not not able to find on google

1 0