- Boost - lists.preview.boost.org

[graph] Archetype's redundant members (Re: [graph]Direct Edge Access)
by Takatoshi Kondo 14 Mar '13

14 Mar '13

Hi Jeremiah, Thanks for your advice. I studied about archetypes. If I understood the minimal archetype requirements based on concepts correctly, some graph archetypes seems to have redundant members. In addition, vertex_list_graph_archetype::degree_size_type should inherit from incidence_graph_archetype. So, I wrote a patch. After applying the patch, all Boost.Graph tests passed. Could you check the patch? -- Takatoshi Kondo On Thu, Mar 7, 2013 at 4:41 PM, Jeremiah Willcock <jewillco(a)osl.iu.edu> wrote: > On Thu, 7 Mar 2013, Takatoshi Kondo wrote: > >> Hi Jeremiah, >> >> Thank you for your reply. I'm relieved that I understand correctly. I >> come up with a related question. >> I think that general graph algorithm developers should test two >> different things. >> >> One is concepts. If function my_algo() required >> VertexAndEdgeListGraphConcept for the parameter g, it should be >> checked as follows: >> >> #include <boost/graph/graph_concepts.hpp> >> >> template <typename Graph> >> void my_algo(Graph g) { >> BOOST_CONCEPT_ASSERT(( boost::VertexAndEdgeListGraphConcept<Graph> )); >> >> boost::edge(0, 1, g); // accidental invalid use ... Line A >> } >> >> But this test cannot detect out of concepts functions usage as Line A >> if class Graph accidentally provide them. >> So, these problems should be detected the following test: >> >> void my_algo_test() { >> typedef /* Only satisfies VertexAndListGraphConcept*/ Graph; // ... >> Line B >> Graph g; >> my_algo(g); >> } >> >> How do I define the type that is only satisfied specific concepts? > > > Those are called "archetypes" in the terminology of the Boost Concept Check > Library > (http://www.boost.org/doc/libs/1_53_0/libs/concept_check/concept_check.htm) > There is a set of them for Boost.Graph concepts in > <boost/graph/graph_archetypes.hpp>. They do not appear to have > documentation, but example uses include most files with the name pattern > *_cc.cpp in libs/graph/test (e.g., bfs_cc.cpp). > > > -- Jeremiah Willcock > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 1

boost_svn_expor
by DongInn Kim 13 Mar '13

13 Mar '13

Hi, Can anyone tell me what boost_svn_expor does? I did not look up the program and who is running it yet but I thought someone in the boost group may already have answer for this. > [root@wowbagger dikim]# pstree 8271 > httpd─┬─59*[httpd] > └─httpd───boost_svn_expor─┬─boost_svn_expor─┬─boost_svn_expor───svn > │ ├─boost_svn_expor───boost_svn_expor > │ ├─bzip2 > │ ├─cut > │ ├─star───star > │ ├─tar───tar───bzip2 > │ └─tee > └─cat > [root@wowbagger dikim]# ps -ef | grep boost_svn > apache 23534 23510 0 15:40 ? 00:00:00 /bin/sh /home/grafik/www.boost.org/boost_svn_export_archive.sh trunk > apache 23543 23534 0 15:40 ? 00:00:00 /bin/sh /home/grafik/www.boost.org/boost_svn_export_archive.sh trunk > apache 23544 23543 0 15:40 ? 00:00:00 /bin/sh /home/grafik/www.boost.org/boost_svn_export_archive.sh trunk > apache 23552 23543 0 15:40 ? 00:00:00 /bin/sh /home/grafik/www.boost.org/boost_svn_export_archive.sh trunk > root 23809 23332 0 15:42 pts/1 00:00:00 grep boost_svn > [root@wowbagger dikim]# This program almost kills the boost server. Its loadaverage is > 30 now. :-( Regards, -- - DongInn

2 2

[spirit] hold_any invalid assignment to destructed object?
by Rob Desbois 13 Mar '13

13 Mar '13

Hi, The boost::spirit::hold_any implementation includes the following functions defined in the detail sub-namespace: // member of fxns<mpl::true_> specialisation, line 99 static void move(void* const* src, void** dest) { reinterpret_cast<T*>(dest)->~T(); *reinterpret_cast<T*>(dest) = *reinterpret_cast<T const*>(src); } // member of fxns<mpl::false_> specialisation, line 99 static void move(void* const* src, void** dest) { (*reinterpret_cast<T**>(dest))->~T(); **reinterpret_cast<T**>(dest) = **reinterpret_cast<T* const*>(src); } As I understand it, the object is destroyed _and then assigned to_; does it not need to be constructed at this point, i.e. have something like this (for the first specialisation): new (reinterpret_cast<T*>(dest)) T( *reinterpret_cast<T const*>(src) ); Thanks & apologies if I've misunderstood --rob <http://theotherbranch.wordpress.com/>

2 3

Meeting C++ 2013 - Call for Papers
by Jens Weller 12 Mar '13

12 Mar '13

Hello C++ & boost Community! Today, the 2nd Edition of the Meeting C++ conference has been announced! We will meet in Düsseldorf again at the 2nd November Weekend for two days full of C++! Call for Papers: http://www.meetingcpp.com/index.php/newsreader/items/call-for-papers-124.ht… Announcement with further Details on the conference: http://www.meetingcpp.com/index.php/newsreader/items/meeting-cpp-2013-annou… Talks about boost, C++11/14 are very welcome to the conference! kind regards, Jens Weller

1 0

[BGL] ticket 6780
by Fernando Vilas 12 Mar '13

12 Mar '13

Hi, I am still working on a few studies involving maximum adjacency search. How close is ticket 6780 to being accepted? The test cases for Stoer-Wagner now pass again on my computer. -- Thanks, Fernando Vilas fvilas(a)iname.com

1 0

[log] Release candidate 1
by Andrey Semashev 11 Mar '13

11 Mar '13

Hi, I've finished the docs update and released the RC1 of Boost.Log v2. The code can be downloaded here: http://sourceforge.net/projects/boost-log/files/boost-log-2.0-RC1-r847.zip/… The code can also be checked out from SVN: svn co https://boost-log.svn.sourceforge.net/svnroot/boost-log/trunk/boost-log The updated docs are available online: http://boost-log.sourceforge.net/libs/log/doc/html/index.html Aside from the docs updates there were a few changes I made as a part of the reviewing process (some were pointed out by users): - The add_attr manipulator was renamed to add_value. The new name better follows the terminology of the library. - The attribute value visitation API no longer forwards the result of the visitor. This feature is rarely needed but it slows down compilation significantly. To acquire the result one can use the new save_result function object wrapper. - Formatter and sink factories for settings parsers are now classes rather than simple function objects. This follows the pattern set by filter factories, which were classes before. - Fixed a few bugs and compilation problems. Sadly, there was almost no discussion of the library in this list. I received a few private emails on the library, mostly concerning some problems here and there and porting issues from v1. While valuable, this feedback can hardly replace a good review of the Boost community. I encourage everyone interested to take a look at the library, however deep you like, and provide your feedback. I don't plan to make any significant changes to the code, except maybe some include optimization and fixing the problems. If everything's fine, I'm going to post a request for permission to merge to trunk in a week or two.

6 25

Re: [boost] [log] Release candidate 1 usage question
by Alex Perry 11 Mar '13

11 Mar '13

Hi, I've been following with interest the development of this Log v2 code which looks very useful. However having read through the documentation I can't see any easy way of solving the following issue. I'm wondering if I'm just missing something obvious so thought I'd ask. I was hoping to replace some existing logging in an application which has been built on top of log4cpp - as far as I can see all the functionality of log4cpp we use is included (or some equivalent behaviour) in the boost log v2 and in a much more "natural looking" C++ idiom. However I can't see any easy way of solving the main problem we have with our current logging which is why I am looking to change it in the first place. The application is delivered as a group of related processes rather than as a single individual process - the logging is currently configured for this group and so messages need to be formatted with a source pid as well as a source tid - then grouped together and output to the appropriately configured streams (be it to a rolling file appender or syslog appender to use log4cpp names). Currently this is implemented by having one process taking the role of logging-server which is responsible for reading and managing the configuration for log4cpp, setting up the appropriate named loggers and appenders, then reading output from a shared memory circular buffer. The other logging-client processes then simply write their log output to this shared memory. Other than a bit of faffing around with timestamps to make sure that the timestamp recorded for a log message is the one when the message was written to the shared memory rather than when it was written to the log4cpp layer by the server, the server simply reads the shared memory and outputs the log messages to the current log4cpp configuration. The biggest issue with this setup is supporting the "filtering" required of log messages - obviously there is quite a large overhead in formatting a log message, locking the shared memory and writing to it. To avoid this overhead the server process writes the maximum severity of messages required for a "named log stream" to the shared memory - in the client processes this severity is checked before proceeding with the formatting of the log message. However unfortunately there is currently only support for a fixed number of these "named streams" - this actually means in practise (though wasn't the original design intention) that all logging output is written to one of 2 named log streams "trace" and/or "audit". Whilst this has worked well enough up to now enabling "trace" at "DEBUG" level can generate huge amounts of logging information which can be very time-consuming to parse when diagnosing a problem. I would like to go to a much more granular approach in the logging - so each component or sub-process, particularly for the general purpose "trace", "DEBUG" log messages, has its own name and may be switched on independently - preferably dynamically rather than by being loaded from some static configuration file. Having looked through the boost.log documentation I can't see anything that directly supports this type of multi-process logging. Whilst I'd be very happy to write a sink backend which writes to some shared memory in a similar manner to our current implementation and a custom log source to read from this and write in one "elevated" process , I'm not quite sure that this is the correct design. It appears to me that I really want to share the majority of the configuration of the logging "core" between the processes. Ie the configuration of filtering in particular needs to be shared between the processes. I see that support for loading the configuration of the core from a boost.ptree already exists. Would a good approach be to get the "server" process to write the configuration into a ptree which is then serialised and passed to the other processes by some mechanism (+some way of signalling that a change to logging configuration has occurred)? Or is there some way that the logging core could be maintained in boost interprocess containers or some such avoiding complex message passing between the processes (actually probably a bad idea - how do you avoid locking contention in the filtering check)? I can't imagine that I'm the only one ever to want this sort of "logger server/daemon" behaviour however what is other peoples experience with this sort of logging? Is it just simpler to let each process write to its own separate log for debug tracing? Whilst this will make for more searching when diagnosing issues (which process actually fulfilled the particular request I'm interested in) the simplicity will win out provided that more general "audit" messages are collated and in a single output to make finding which log output to search possible. Alex

2 1

[sandbox] [tree_node] Major update
by Cromwell Enage 11 Mar '13

11 Mar '13

Hello, fellow Boosters. In the hope that some of you here are still interested in easily extensible / augmented tree implementations, I've updated my Boost.TreeNode library in the sandbox. It provides adaptors for augmenting counts (a la countertree), heights, and even Boost.Accumulator values (which can solve the use cases mentioned in <http://je4d.blogspot.com/2013/01/boostintrusive-annotated-trees-part-1.html>), as well as concepts against which you can write your own adaptors. For a quick glance, documentation is at <http://svn.boost.org/svn/boost/sandbox/tree_node/libs/tree_node/doc/html/in…>. I'm still looking at the other two proposals. They have performance benchmarks which my library does not currently possess. However, at first glance I see no comparably straightforward way to augment user-defined data (e.g. Boost.Accumulator features) in either library. Feedback appreciated! Cromwell D. Enage

5 6

[test] spurious clang complier warnings
by Ian Emmons 10 Mar '13

10 Mar '13

When I compile my test code with clang on Macintosh (now Apple's default compiler), I get the two compiler warnings listed below. Could these be suppressed, please? I know this is a low priority item, but I expect it's pretty easy to fix. -Ian Emmons ============================== In file included from MyTest.cpp:6: In file included from ./MyTest.h:7: In file included from /Users/iemmons/dev/boost_1_53_0/boost/test/unit_test.hpp:19: In file included from /Users/iemmons/dev/boost_1_53_0/boost/test/test_tools.hpp:21: /Users/iemmons/dev/boost_1_53_0/boost/test/floating_point_comparison.hpp:251:25: warning: unused variable 'check_is_close' [-Wunused-variable] check_is_close_t const& check_is_close = unit_test::ut_detail::static_constant<check_is_close_t>::value; ^ /Users/iemmons/dev/boost_1_53_0/boost/test/floating_point_comparison.hpp:273:25: warning: unused variable 'check_is_small' [-Wunused-variable] check_is_small_t const& check_is_small = unit_test::ut_detail::static_constant<check_is_small_t>::value; ^ 2 warnings generated.

4 3

boost::interprocess::unique_ptr vs Boost.SmartPtr
by Adam Romanek 09 Mar '13

09 Mar '13

Hi! If I'm correct then the first "serious" implementation of unique_ptr for C++03 was written by Howard Hinnant, which was later adopted to Boost.Interprocess library. Unfortunately, I suppose not many people are aware of the fact that unique_ptr for C++03 is available in Boost. Even worse, I know people who are aware of it but who are afraid of using it just because it is provided by Boost.Interprocess, not by Boost.SmartPtr. Therefore, here's my proposal: - boost::interprocess::unique_ptr could be pulled into the top-level boost namespace - Boost.SmartPtr could provide a header file for unique_ptr that would pull the implementation from Boost.Interprocess; such a header file could also be placed in the top-level boost directory so that it could be accessed more easily - boost::unique_ptr could be documented in the documentation for Boost.SmartPtr library, providing use cases, emulation limitations etc. I believe that would make unique_ptr for C++03 available to wider audience. What do you think about this idea? With best regards, Adam Romanek

3 2