- Boost - lists.preview.boost.org

Thanks to everyone for all the work on 1.55.0
by Marshall Clow 11 Nov '13

11 Nov '13

I just wanted to take off my "release manager" hat and say, personally, thank you to all the people who tried out the RCs/Betas/etc, reported bugs, and suggested fixes. You were all a big help in making the release. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[release][1.55.0] Visual C++ known bugs
by Daniel James 11 Nov '13

11 Nov '13

Hello everyone, I'm compiling a list of known issues in boost with Visual Studio 2013/Visual C++ 12. I've made a quick start at: http://www.boost.org/users/history/version_1_55_0.html#version_1_55_0.known… Please let me know if there's anything I should add. Also, if available, tested patches against the release branch or release candidate would be very useful (I don't have the compiler myself, so I can't do that). If you can, please make them using subversion from the root of the repository. thanks, Daniel

5 9

New Version (0.4) of Boost.Application (Aspect Based) available to comments (RFC).
by Renato Forti 11 Nov '13

11 Nov '13

>> How is that supposed to work in Windows? (Does it need to?) Well, a simple analysis, it seems to be specific in POSIX, we do not have anything like it in WINDOWS. (I do not speak for sure) >> Its sensible to expose 'something' that can be integrated to native event loops, but the ideal choice under Windows is probably an event, not a pipe descriptor. I agree. I'm thinking of adding this aspect only in posix, Then if user want use it need add it and use it only on UNIX, e.g.: class myapp { public: int operator()(application::context& context) { #if defined(BOOST_ BOOST_POSIX_API) boost::shared_ptr<application:: selfpipe > selfpipe = context.get_aspect<application:: selfpipe >(); select(...,selfpipe->readfd(),...); #endif return 0; } }; // main int main(int argc, char *argv[]) { myapp app; application::context app_context; #if defined(BOOST_ BOOST_POSIX_API) app_context.add_aspect<application:: selfpipe>( boost::make_shared<application:: selfpipe>()); #endif return application::launch<application::common>(app, app_context); } Comments, Ideas, please! >> I think some analysis is needed. I need help in this subject, if any one with great experience on both sides can propose something (shine a light), it would be of great value! Thanks for help

2 2

Data Structure and Algorithms yet to be inplemented
by Manmohit Rekhi 11 Nov '13

11 Nov '13

Hi, I would really be grateful if could get to know 1)which Data Structures and Algorithms are yet to be implemented? 2)How can i get started on them? 3)Are there any constraints on the libraries i can use to implement them? Thanking you Manmohit Rekhi

1 0

[UUID] Document typo
by Naked Short-Selling 11 Nov '13

11 Nov '13

http://www.boost.org/doc/libs/1_55_0/libs/uuid/uuid.html#Nil I believe is_null() really meant "is_nil()" here...

2 1

[git][ Last merge before git conversion.
by Vicente J. Botet Escriba 10 Nov '13

10 Nov '13

Hi, I would like to know if there will be some time (~1 week) to merge the new features and bug fixed in the release branch before svn is closed for git migration. Note that the provisional calendar was: 8 November : release 1.55 15 November: Provisional: Close subversion for git conversion. Best, Vicente

2 1

[intrusive] possible workaround for vc12 compile errors
by Daniela Engert 10 Nov '13

10 Nov '13

Hi, I've attached a patch to ticket #9332 "has_member_function_callable_with.hpp compile error on msvc-12.0" (https://svn.boost.org/trac/boost/ticket/9332) This patch seems to fix the problem. My far-from-perfect understanding of C++ seems to indicate, that the root cause is in line 201: template< class F , std::size_t N = sizeof((boost::move_detail::declval<F>(). BOOST_INTRUSIVE_HAS_MEMBER_FUNCTION_CALLABLE_WITH_FUNCNAME (), 0))> struct BOOST_PP_CAT(zeroarg_checker_, BOOST_INTRUSIVE_HAS_MEMBER_FUNCTION_CALLABLE_WITH_FUNCNAME) the sizeof expression is evaluated with an unknown type U in declval<U>(). Ciao Dani

2 1

Re: [boost] sqlpp11: SQL for C++
by Roland Bock 10 Nov '13

10 Nov '13

On 2013-11-10 15:58, niXman wrote: > Roland Bock 2013-11-10 12:15: > >> No, sqlpp11 itself only depends on a decent C++11 compiler and matching >> STL. > > I think I can write a code generator using boost.preprocessor. But I > need the documentation of DDL, of course. > I was talking about SQL's DDL (http://en.wikipedia.org/wiki/Data_definition_language) Unfortunately every vendor seems to be using some additions, so that the task is not too simple in all generality, I guess... But using the preprocessor to generate the table types could be a very nice tool in some cases. For instance if you are using in-memory databases with Sqlite3. As a trivial byproduct it could also produce the create table string, so that I would not have to maintain that in two places. Also for such a purpose, it would make sense to restrict the DDL to a common subset. With larger tables, I guess I'd stick with my current approach though: running a separate code-generator as part of the build process. The main benefit is that I get clearer error message pointing to C++ code that exists outside the compiler memory in case the code generator produces incorrect output or I use the generated code in the wrong way, etc. Another benefit of using external code generators is string handling. In our company we use CamelCase for classes, camelCase for members and underscore separated compounds for SQL names. An external code generator can easily translate, of course, but the preprocessor is not equipped for string manipulation, afaik. But again, I can imagine a nice usage of a prepocessor-based code generator for in-memory databases with no external representation. Regards, Roland

1 0

[utility] Any interest for a macro which automatically creates default move-semantics, comparisson etc for a class
by Viktor Sehr 10 Nov '13

10 Nov '13

I've created a macro which automatically creates: - move constructor\assignment - swap member function - operator== and operator!= - operator< - assignment operator without side-effects if it throws. Example usage: class Foo { public: Foo() {} DEFAULT_EVERYTHING(Foo, ( (int)(a) ) ( (std::vector<int>)(b) ) ( (float)(c) ) ); }; Any interest, suggestions or ideas? Ofcourse it might be split into several macros depending on what operators the class requests (if it's a move-only class etc), and perhaps an extra parameter enable if a member is up for sorting and comparison. Code available here: https://www.dropbox.com/s/dhkxj94rrh83az0/DefaultEverything.h

3 10

[containers] Are there flat_map/set and stable_vector proposals at work?
by Klaim - Joël Lamotte 09 Nov '13

09 Nov '13

All is in the title: I would like to know if flat_map, flat_set and stable_vector have been proposed for inclusion in the C++ standard library, or if there are works going on to write such a proposal. I find that I use a bit more flat associative containers than tree-based standard associative containers in all my recent projects, and I think that having option in the standard to choose one or the other would be very useful for a lot of devs.

5 20

New Version (0.4) of Boost.Application (Aspect Based) available to comments (RFC).
by Renato Forti 09 Nov '13

09 Nov '13

Hi, I will answer on list too. >> I would like to know if your application class is related only to console applications or is it a generic class that could be implemented also as a gui::application? It is generic. But now we don't provide any specific support to GUI, you can for sample use it with QT, to do this you need use "common mode". >> I'm trying to write a cross platform header only gui library, so I wonder if I should use it (hoping it's a header only library too) or have my own different gui::application class. http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica tion/f_a_q_.html#boost_application.f_a_q_.can_i_build_another_application_mo de__what_is_needed_ Well, you can build a application mode that will use your GUI lib, e.g. application::gui use application::common as model. But we have some problem here! 1. Boost.Application is not a boost library yet! (have no support od boost.org) , and it is in working progress status. Things can change! 2. Boost.Application is header only, but have some dependencies that are not header only. http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica tion/dependencies.html PS. If you think that this library is interesting to boost, please post on boost.devel, that you have interest on it. http://news.gmane.org/gmane.comp.lib.boost.devel Hope this helps in your decision. If you have any other questions, let me know! -- Renato Forti

1 0

New Version (0.4) of Boost.Application (Aspect Based) available to comments (RFC).
by Renato Forti 09 Nov '13

09 Nov '13

Hi Stas, Thanks for your comments! >> I think it worth noting in documentation that SIGUSR1 is reserved for internal purposes. I will do! >> What do you think about self pipe built-in functionality? It is a widely used trick. I think it can be implemented as an aspect in a quite straightforward way. Can you give more details about what you're proposing here? Elegant signal handler is my main problem in this lib! I want ideas to get it correctly designed! Thanks for documentation appointments, I will fix all! And I forgot to put the main question on message: "Is there any interest in a library like this?" What you think? Thanks a lot!

3 4

[string_ref] string literal constructor
by Michael Marcin 08 Nov '13

08 Nov '13

I noticed string_ref doesn't have a constructor for a string literal. Wouldn't this save a call to strlen for a common case? Ex. template< std::size_t N > basic_string_ref( const charT( &str )[N] ) : basic_string_ref( str, N-1 ) { static_assert(N >= 1, "not a string literal"); } string_ref test( "test" ); I see that adding this directly doesn't work as the compiler is always choosing to decay and pick the const char* overload. Is there no way to make this work?

10 15

New Version (0.4) of Boost.Application (Aspect Based) available to comments (RFC).
by Renato Forti 07 Nov '13

07 Nov '13

Hi All, I have a new "Prototype" version (Version 0.4) of Boost.Application ready to use. This version use a concept of "aspects" suggested by 'Vicente J. Botet Escriba'. Thus the library is much more flexible than version 0.3 (old-version), now the components are independents (loosely coupled). The documentation (work in progress status) is available on : <http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html> http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html The lib can be downloaded on : <https://github.com/retf/Boost.Application> https://github.com/retf/Boost.Application Please send your feedback! -- Older Version (0.3): If you want to make a comparison with the previous version (0.3), check: <http://www.dokfile.com/appbeta3/docs/libs/application/doc/html/index.html> http://www.dokfile.com/appbeta3/docs/libs/application/doc/html/index.html Thanks

2 1

[1.55.0] Release candidate 2 available
by Marshall Clow 07 Nov '13

07 Nov '13

RC2 files for 1.55.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 93780777cfbf999a600f62883bd54b17 *boost_1_55_0_rc2.tar.gz d6eef4b4cacb2183f2bf265a5a03a354 *boost_1_55_0_rc2.tar.bz2 8aca361a4713a1f491b0a5e33fee0f1f *boost_1_55_0_rc2.zip 4e5bbc15fc8c80df8be428f8a5b5a823 *boost_1_55_0_rc2.7z Thanks! -- The release managers === Changes to release since rc1 === ---- Author: bemandawes Date: 2013-10-28 13:16:50 EDT (Mon, 28 Oct 2013) New Revision: 86503 URL: http://svn.boost.org/trac/boost/changeset/86503 Log: Merge 86426 from trunk. This should fix msvc test failures. ---- Author: bemandawes Date: 2013-10-29 09:15:03 EDT (Tue, 29 Oct 2013) New Revision: 86514 URL: http://svn.boost.org/trac/boost/changeset/86514 Log: Merge 84443 from trunk, to fix mpl assert failures for msvc in many libraries. ---- Author: eric_niebler Date: 2013-10-29 12:53:08 EDT (Tue, 29 Oct 2013) New Revision: 86516 URL: http://svn.boost.org/trac/boost/changeset/86516 Log: merge [86460] from trunk, fix bootstrap on mingw --- Author: jhunold Date: 2013-10-29 13:19:33 EDT (Tue, 29 Oct 2013) New Revision: 86519 URL: http://svn.boost.org/trac/boost/changeset/86519 Log: Merge 84402 from ^/trunk ------------------------------------------------------------------------ r84402 | jhunold | 2013-05-21 14:23:20 +0200 (Di, 21 Mai 2013) | 4 lines Fix: cache file loading and saving must use native paths Fixes caching at least on Windows platform ------------------------------------------------------------------------ --- Author: johnmaddock Date: 2013-11-01 05:32:55 EDT (Fri, 01 Nov 2013) New Revision: 86532 URL: http://svn.boost.org/trac/boost/changeset/86532 Log: Merge fix for dependency tracking. --- Author: danieljames Date: 2013-11-03 14:20:09 EST (Sun, 03 Nov 2013) New Revision: 86551 URL: http://svn.boost.org/trac/boost/changeset/86551 Log: Merge Visual C++ 12 fix for Unordered. --- Author: viboes Date: 2013-11-03 15:43:42 EST (Sun, 03 Nov 2013) New Revision: 86552 URL: http://svn.boost.org/trac/boost/changeset/86552 Log: Thread: merge [86540] to fix #9319.

11 16

Re: [boost] [1.55.0] Release candidate 2 available
by Peter Dimov 06 Nov '13

06 Nov '13

Robert Ramey wrote: > lol - I'm already dealing with the fallout from a previous "trivial one > line fix". I actually do understand, because most trivial one-line fixes aren't. This one (adding the missing #include <algorithm>) really is, though. (At least according to my experience.)

1 0

Re: [boost] [1.55.0] Release candidate 2 available
by Eric Niebler 06 Nov '13

06 Nov '13

On 11/5/2013 1:46 AM, LeMay.Steve wrote: > VS2013 needs archive's transform_width.hpp to #include <algorithm> so > that std::min will be properly defined. Looks like it. Can you file the bug please? -- Eric Niebler Boost.org http://www.boost.org

11 17

[math] Contribution and TODO-list implementation.
by Bikineev 06 Nov '13

06 Nov '13

Hello. I'm russian student. My department is Applied Math. I need to make my magister work and I would like to relate it with Boost.Math development. I think this work could be something like implementation of tasks mentioned in TODO-list. New feature development may take a long time. In the best case, I would be glad to take job and reviewer for it. If anyone has an idea - I'm ready to take serious and big job for 1,5 years. Thanks.

5 11

Boost API System or Library Calls ..
by Rahul Mathur 06 Nov '13

06 Nov '13

Out of curiosity, wish to know if BOOST ASIO calls like - boost::asio::read() boost::asio::transfer_all() boost::asio::write() BOOST LEXICAL calls like - boost::lexical_cast<std::string>() BOOST POSIX TIME calls like - boost::posix_time::microsec_clock::universal_time() boost::posix_time::microsec_clock::ptime() are LIBRARY or SYSTEM calls. How to know which calls of BOOST are SYSTEM and LIBRARY calls? Thanks.

3 3

Re: [boost] [modularization] Dependency to Boost.Exceptionunavoidable?
by Ahmed Charles 05 Nov '13

05 Nov '13

What about combining throw_exception.hpp and exception.hpp and move that header to config, since it won't depend on anything else and only really does configuration anyways? Note, if you don't like config as a choice, the new version of detail which only depends on config sounds nice as well. ________________________________ From: Emil Dotchevski Sent: 11/3/2013 12:29 PM To: boost(a)lists.boost.org Subject: Re: [boost] [modularization] Dependency to Boost.Exceptionunavoidable? On Sat, Nov 2, 2013 at 5:19 PM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: > On 1 Nov 2013 at 16:01, Emil Dotchevski wrote: > >> 1. If BOOST_NO_EXCEPTIONS is defined, libraries should not throw. One >> option to implement that behavior is to pass exception objects (of the >> usual documented library-defined types) to boost::throw_exception. > > I wonder how useful supporting exceptions disabled is in recent years? I agree that many Boost libraries are impractical with exception handling disabled, but there is no harm done in supporting BOOST_NO_EXCEPTIONS via boost::throw_exception, since its specification does not allow it to return. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 3

[unordered] Visual C++ 2013 initializer_list overload failure.
by Daniel James 05 Nov '13

05 Nov '13

Hi, I'm getting some test failures for inserting an initializer_list into the unordered containers: http://www.boost.org/development/tests/trunk/developer/output/teeks99-10-wi… I don't have access to Visual C++ 12 to investigate this. This is just a guess, but I think the problem is converting an initializer_list of string literals to an initializer list of std::string. This works okay with clang and g++ so I assume it's allowed. A minimal test might be something like the following (although it might not). #include <initializer_list> #include <string> template <typename T> struct thing { void insert(T const&) {} void insert(T&&) {} void insert(std::initializer_list<T>) {} }; int main() { thing<std::string> x; x.insert("a"); x.insert({"a"}); x.insert({"a", "b"}); }

5 13

Re: [boost] [tweener] Doxygen documentation issues
by Andrew Hundt 05 Nov '13

05 Nov '13

On Tue, Feb 26, 2013 at 4:28 PM, Julien Jorge < julien.jorge(a)stuff-o-matic.com> wrote: > Hi, > > I am writing the documentation of Boost.Tweener and I encounter various > difficulties. One of them is the generation of the class documentation > with doxygen. It seems that it cannot extract the class and member > documentation from .ipp files. Another alternative may be the EXTENSION_MAPPING section of a doxyfile. http://www.stack.nl/~dimitri/doxygen/manual/config.html#cfg_extension_mappi… Cheers! Andrew Hundt

1 0

[modularization] Modularizing Boost (modularization)
by Stephen Kelly 05 Nov '13

05 Nov '13

Hi there, my plan for modularizing and modernizing Boost was roughly this: * Phase 0 - remove dead weight by bumping compiler feature requirements * Phase 1 - move some files around so that the modularized repos form a mostly directed graph * Phase 2 - Form some kind of 'boost core library' or 'boost feature normalization library' from the guts of existing libraries like type_traits, static_assert, config mpl and utilities. * Phase 3 - Try to port the mpl to variadic templates so that the dependency on Boost.PP is not needed when variadic templates are available. I recommend completing up to phase 2 before migrating to git, as otherwise files will have to be deleted from one repo, and added to another without history. Phase 0 is aborted, so let's look at phase 1. [Note: This should go without saying, but my experience on this list tells me it needs to be said: * I do not propose making many commits with the commit message 'migrate' * The below is scripted for your understanding only. Scripting gives an exactness which prose does not, and allows reproducibility. Don't take it too literally. * Of course, forwarding headers should be understood to be left behind when a file is moved, where possible. * Don't cry too loudly about where I'm moving files to. See Phase 2 above, and understand that this is partly only an experiment to see how modularization can be done. EndNote] If the dependencies between repositories are analysed, the result is this graph: http://steveire.com/boost/graph_all.dot http://steveire.com/boost/graph_all_small.png There are 104 nodes and 1159 edges. Each edge is a real dependency which exists between repos, and which will exist between boost modularized packages. They should not be considered optional. If we remove any nodes which are not strongly connected, we are left with a new graph of nodes which are all strongly connected: http://steveire.com/boost/graph_strong.dot http://steveire.com/boost/graph_strong_small.png There are 68 nodes and 675 edges. Move enable_if from utility to type_traits: git submodule foreach 'git grep -l -P utility/enable_if.hpp -- include/boost | xargs sed -i "s|utility/enable_if.hpp|type_traits/enable_if.hpp|" || echo' mv libs/utility/include/boost/utility/enable_if.hpp libs/type_traits/include/boost/type_traits git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 670 edges and 68 nodes. Next, move boost/detail/workaround.hpp to the config library/repo: git submodule foreach 'git grep -l -P boost/detail/workaround.hpp -- include/boost | xargs sed -i "s|boost/detail/workaround.hpp|boost/config/workaround.hpp|" || echo' mv libs/detail/include/boost/detail/workaround.hpp libs/config/include/boost/config/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 661 edges and 68 nodes. Next, move boost/limits.hpp to the config library/repo: git submodule foreach 'git grep -l -P boost/limits.hpp -- include/boost | xargs sed -i "s|boost/limits.hpp|boost/config/limits.hpp|" || echo' mv libs/detail/include/boost/limits.hpp libs/config/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 653 edges and 68 nodes. Next, move boost/detail/iterator.hpp and boost/iterator/iterator_traits.hpp to the type_traits library/repo: git submodule foreach 'git grep -l -P boost/detail/iterator.hpp -- include/boost | xargs sed -i "s|boost/detail/iterator.hpp|boost/type_traits/detail/iterator.hpp|" || echo' git submodule foreach 'git grep -l -P boost/iterator/iterator_traits.hpp -- include/boost | xargs sed -i "s|boost/iterator/iterator_traits.hpp|boost/type_traits/iterator_traits.hpp|" || echo' mv libs/detail/include/boost/detail/iterator.hpp libs/type_traits/include/boost/type_traits/detail/ mv libs/iterator/include/boost/iterator/iterator_traits.hpp libs/type_traits/include/boost/type_traits git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 650 edges and 68 nodes. Next, move boost/iterator.hpp from iterator to the utility library/repo: mv libs/iterator/include/boost/iterator.hpp libs/utility/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 649 edges and 68 nodes. utility no longer depends on iterator. Move boost/version.hpp to config: mv libs/detail/include/boost/version.hpp libs/config/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 512 edges and 64 nodes. The config, integer, io and static_assert libraries are no longer part of the mesh Next, move boost/pointee.hpp from iterator to detail: mv ./libs/iterator/include/boost/pointee.hpp libs/detail/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' Move exception/detail/attribute_noreturn.hpp into config: git submodule foreach 'git grep -l -P boost/exception/detail/attribute_noreturn.hpp -- include/boost | xargs sed -i "s|boost/exception/detail/attribute_noreturn.hpp|boost/config/attribute_noreturn.hpp|" || echo' mv libs/exception/include/boost/exception/detail/attribute_noreturn.hpp libs/config/include/boost/config/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' Move boost/throw_exception.hpp and exception.hpp into utility: mv libs/exception/include/boost/throw_exception.hpp libs/utility/include/boost mv libs/exception/include/boost/exception/exception.hpp libs/utility/include/boost/utility git submodule foreach 'git grep -l -P boost/exception/exception.hpp -- include/boost | xargs sed -i "s|boost/exception/exception.hpp|boost/utility/exception.hpp|" || echo' git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 485 edges and 64 nodes. Several libraries form an inner mesh: $ grep -P "^\s*(type_traits|mpl|detail|utility|smart_ptr|typeof)" output.dot detail->mpl detail->type_traits detail->smart_ptr detail->utility utility->mpl utility->type_traits utility->detail type_traits->detail type_traits->mpl type_traits->typeof type_traits->utility smart_ptr->type_traits smart_ptr->detail smart_ptr->utility mpl->type_traits mpl->detail mpl->utility typeof->mpl typeof->type_traits If we treat them as one element for now, we get a new graph from the rest http://steveire.com/boost/graph_with_corelib.dot http://steveire.com/boost/graph_with_corelib.png There are now 138 edges and 39 nodes Move parts of {vector_,}property_map into graph_parallel: sed '1,/BOOST_GRAPH_USE_MPI/d;/BOOST_GRAPH_USE_MPI/,$d' libs/property_map/include/boost/property_map/property_map.hpp > tmp.hpp sed -i '/BOOST_GRAPH_USE_MPI/,/BOOST_GRAPH_USE_MPI/d' libs/property_map/include/boost/property_map/property_map.hpp sed '1,/BOOST_GRAPH_USE_MPI/d;/BOOST_GRAPH_USE_MPI/,$d' libs/property_map/include/boost/property_map/vector_property_map.hpp >> tmp.hpp sed -i '/BOOST_GRAPH_USE_MPI/,/BOOST_GRAPH_USE_MPI/d' libs/property_map/include/boost/property_map/vector_property_map.hpp sed -i '/#undef PBGL_DISTRIB_PMAP/r tmp.hpp' libs/property_map/include/boost/property_map/parallel/distributed_property_map.hpp rm tmp.hpp git submodule foreach 'git grep -l -P boost/property_map/parallel/distributed_property_map.hpp -- include/boost | xargs sed -i "s|boost/property_map/parallel/distributed_property_map.hpp|boost/graph/parallel/distributed_property_map.hpp|" || echo' git submodule foreach 'git grep -l -P boost/property_map/parallel/impl/distributed_property_map.ipp -- include/boost | xargs sed -i "s|boost/property_map/parallel/impl/distributed_property_map.hpp|boost/graph/parallel/detail/distributed_property_map.hpp|" || echo' mv libs/property_map/include/boost/property_map/parallel/distributed_property_map.hpp libs/graph_parallel/include/boost/graph/parallel mv libs/property_map/include/boost/property_map/parallel/impl/distributed_property_map.ipp libs/graph_parallel/include/boost/graph/parallel/detail git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' http://steveire.com/boost/graph_after_parallel.dot http://steveire.com/boost/graph_after_parallel.png There are now 95 edges and 33 nodes The remaining problematic edges are: conversion->range conversion->math range->algorithm math->multiprecision concept_check->parameter Assuming they can be broken by moving some files aroung (I believe they can be), we end up with a small graph of strongly connected components: http://steveire.com/boost/graph_after_remaining.dot http://steveire.com/boost/graph_after_remaining.png There are now 18 edges and 11 nodes. Looking at the entire graph again, we get this: http://steveire.com/boost/graph_final.dot http://steveire.com/boost/graph_final_small.png Obviously, this is not perfect, but it is a beginning, and it is mostly now a directed graph. Any comments? Thanks, Steve.

29 162

Re: [boost] [tweener] Doxygen documentation issues
by Paul A. Bristow 05 Nov '13

05 Nov '13

> -----Original Message----- > From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Watanabe > Sent: Wednesday, February 27, 2013 4:48 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] [tweener] Doxygen documentation issues > > AMDG > how can I also disable the extraction of the private members in the documentation? > > > > Doxygen XML is a bit annoying about that. Last time I tried, it seemed to ignore the option that's > supposed to hide private members. What we usually use is > /** INTERNAL ONLY */ which will cause BoostBook to strip it out. I've added this in all the namespace detail section and this is effective at reducing the items that are in the C++ reference section (from Quickbook). This is what a typical *user* wants - the implementation stuff in namespace detail (for example) is just clutter. But an *author or maintainer* might want all the detail sections included in the C++ reference section. I can achieve this by horribly hacking the *.*pp files to change all INTERNAL ONLY to INTERNAL AS WELL - or something. Can you suggest a better way of switching this INTERNAL ONLY feature on/off? Thanks Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

2 1

[parameter] referring to argument types in BOOST_PARAMETER_FUNCTION return values
by Erik Erlandson 05 Nov '13

05 Nov '13

There is documentation that demonstrates using boost::parameter::value_type<> to extract the type of an argument in the boost::parameter library. However, the example does *not* use the BOOST_PARAMETER_FUNCTION() macro, and so the resulting function doesn't benefit from all the features you can get from that macro: Section 3.2.2: http://www.boost.org/doc/libs/1_54_0/libs/parameter/doc/html/index.html#mor… I was able to fairly easily obtain the same kind of arg type information inside of a BOOST_PARAMETER_FUNCTION() declaration, which I show in this example: https://gist.github.com/erikerlandson/7319975 To come up with that, I had to throw '-E' and examine the macro expansions to determine that 'Args' is the appropriate argument-pack template name to use. In other words, what I did doesn't appear to be officially supported: // not officially documented or supported? (typename boost::parameter::value_type<Args, tag::c, int>::type) However, I don't see any barrier to officially supporting the above. All it requires is a promise that 'Args' is the template name that will be generated by the macros. Alternatively, provide a new utility macro, such as: #define BOOST_PARAMETER_ARG_TYPE(arg_name) typename boost::parameter::value_type<[template arg name], [namespace]::arg_name, int>::type

1 0