- Boost - lists.preview.boost.org

[1.46.0] Release candidates available
by Beman Dawes 21 Feb '11

21 Feb '11

Release candidate files for the 1.46.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. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers

9 13

Re: [boost] Formal Review of Proposed Boost.Process library
by Max Sobolev 21 Feb '11

21 Feb '11

(First, please, excuse me for my "english".) This variant of the Boost.Process library should NOT (--never--) be accepted. The Boost.Process must be implemented as a DSEL (probably through the Boost.Proto expression templates framework) with a nice (commonly known) syntax like: using boost::process; using process::arg; namespace fs = boost::filesystem; process ls("ls"), grep("grep"); fs::path libs = "/usr/lib"; auto pipe = ls [--arg("reverse") % -arg('l') % libs] | grep ["^d"]; run(pipe); // or: // pipe(); // or: // ls(); This approach provide a declarative, not an imperative programming style. (A lot of work done by expression templates' inner mechanics.) The library must support: * i/o redirection * process piping; [implicit pipes] * named/unnamed pipe objects; [explicit pipes] * runned processes surfing (boost::process::processes_iterator): - CreateToolhelp32Snapshot()/Process32First()/Process32Next() API functions in Windows - /proc filesystem parsing in linux/some unix * loaded shared libraries surfing (boost::process::modules_iterator): - CreateToolhelp32Snapshot()/Module32First()/Module32Next() API functions in Windows - /proc filesystem parsing in linux/some unix * child processes surfing (boost::process::children_iterator) - parsing processes_iterator's range results - /proc filesystem parsing in linux/(perhaps) some unix - empty iterator range by default * runned thread per process surfing (boost::process::threads_iterator) - filtered results of CreateToolhelp32Snapshot()/Thread32First()/Thread32Next() API functions in Windows - /proc filesystem parsing in linux (see /proc/[pid]/task filesystem branch since linux 2.6.0-test6) - empty iterator range by default * runned thread surfing (boost::threads_iterator) - CreateToolhelp32Snapshot()/Thread32First()/Thread32Next() API functions in Windows - FOR-EACH process IN system: back_inserter(boost::process::threads_iterator(process), boost::process::threads_iterator(), threads); * (any) process stats * process creation * daemonization - through Service API on Windows * process security and privacy aspects (probably this is subject for an another separate library, part of which must be integrated with the Boost.Process) _________________________________ More examples: using boost::process; using process::arg; using process::env; namespace fs = boost::filesystem; // echo $PATH # (%PATH% in Windows) process("echo") [env("PATH")] (); // or: run(process("echo") [env("PATH")]); // ps -aux > ps.out process ps("ps"); run(ps [-arg('a', 'u', 'x')] > "ps.out"); process::_this_ > "file.out" < "file.in"; // probably static_assert() on Windows platform process::_this_ >> "file.out" < "file.in"; std::cin >> ...; // read from "file.in" std::cout << ...; // write to "file.out" // grep -i -n searched_word file.in > file.out: process grep("grep"); run( grep [-arg('i') % -arg('n') % "searched_word" % "file.in"] > "file.out"); // cat /etc/rc.d/xinetd | grep -v '^#' | sed '/^$/d' > file.out process cat("cat"), grep("grep"), sed("sed"); fs::path conf("/etc/rc.d/xinetd"); auto pipe = cat [conf] | grep [-arg('v') % "^#"] | sed ["/^$/d"] > "file.out"; pipe(); using namespace process::placeholders; process rm("rm"); rm [arg("filename") % "non_existent"] > "file.out", _2 >& _1; rm(); // or: run(rm); _________________________________ Some mini-review (concerning interface design only) on the proposed variant of the library: * process::find_executable_in_path() is a redundant function. His job must be done by default (when the filename() path's suffix supplied only instead of the full/relative path), if it's supposed on the target platform when the command shell gets the prog name from the user. In rare case the user can manipulates paths through the env(ironment variables) class (or put the full path explicitly), if default behavior is not suitable. By the way, a parameter and an return value must have been the boost::filesystem::basic_path<>, not a std::string. Obviously, the library must be integrated with the Boost.Filesystem. * A "stream behavior" boost::function<> mechanism is not obvious and not straightforward; unwarrantly hard to use. * environment(-variables) and args-list are solid abstractions (with a sharp behavior), not data structures. * child process subtype is a wrong abstraction (his "child" property isn't enough for his existence). Name it process simply. I.e. delete a child subtype from an inheritance tree; In Unix environment (similar in Windows) all processes, except INIT, have a parent: each process is a child almost without exceptions. * ----code excerpt from the User Guide-- int exit_code = child.wait(); #if defined(BOOST_POSIX_API) if (WIFEXITED(exit_code)) exit_code = WEXITSTATUS(exit_code); #endif std::cout << exit_code << std::endl; ---------------------------------------- IFDEFs must be incapsulated in the wait() member function. Signal terminating/stopping status of process can be abstracted into another terms, which are clear enough for a non "signal-conformant" platforms.

6 12

Formal Review of Proposed Boost.Process library ends Sunday!
by Marshall Clow 21 Feb '11

21 Feb '11

If you haven't submitted a review (and plan to), please do not delay. Writing a review ================ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager (me!) Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. -- 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

4 3

Re: [boost] [1.46.0] Release candidates available
by Steve M. Robbins 21 Feb '11

21 Feb '11

Successfully built the release candidate on Debian linux, 64bits. gcc (Debian 4.4.5-12) 4.4.5 -Steve

1 0

[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

Distributed Boost with CMake: proposal and volunteering
by Daniel Pfeifer 21 Feb '11

21 Feb '11

Hi all, I would like to propose my approach to a modularized build of the Boost C++ Libraries with CMake. The project is found on http://github.com/purpleKarrot/Boost.CMake The following features are currently implemented: * Aggregate modules from different sources (CVS, SVN, GIT, tarballs, ...). * Build, Test, Install * Create a binary installer with selectable components for Windows. * Create a source package (with the modules included) that can do everything in this list (except the first entry). * Create a Debian source package that can be uploaded to a Launchpad PPA where it is built and packaged into many binary Debian packages. * Build Documentation (the usual quickbook-doxygen-boostbook-chain). * Tested on Windows (Visual Studio 10) and Ubuntu (GCC). * Precompiled headers (currently MSVC only). * Build two Boost.MPI libraries on Debian: boost_openmpi and boost_mpich2. * Tests actually make use of Boost's autolinking feature. This tool would allow the following Boost development process: * Each Boost library uses it's own repository (no matter which VCS) * Boost.CMake has a list of modules (or multiple list: eg 'boost' and 'incubating') * A modules definition consists of the information about where to get the source code from. * Boost.CMake can be used to aggregate all modules, run tests, build release packages... * Incubating libraries can be tested before they become an official part of boost. Please note that I am not proposing a development process. I am just proposing a tool. I am volunteering to extend and maintain the tool so that it can (help to) drive the development process. If you decide that all libraries should use git, I can drop the support for all other VCSs, no problem. Also, I am happy to implement other missing features. In the next couple of days I was going to write some documentation and a tutorial how to migrate the libraries to CMake. Cheers, Daniel

7 13

[gsoc] Project proposals
by Andrew Sutton 21 Feb '11

21 Feb '11

Hi all, Just a reminder the Google Summer of Code will be starting soon. Sort of. The org's application is due some time next week. If anybody has project ideas and would be willing to mentor, please add them to the wiki page, here: https://svn.boost.org/trac/boost/wiki/SoC2011 If you are adding project ideas, please remember that terse, intentionally vague descriptions will (hopefully) cause prospective students to do a little more investigation before submitting a proposal. Also, experimental projects are encouraged. The work doesn't have to be part of the Boost distribution. Long-term (multi-summer) projects may also be possible, depending on commitments from students and mentors. Please note that achieving group consensus on the requirements or design of any particular project is distinctly *not* encouraged. Trying to hash out details of a students project on the mailing list can scare away students and discourage mentors. It we be great if we can avoid a replay of the XML fiasco from last year. Finally, there was some early consensus about requiring an aptitude test in addition to the proposal. Are there any ideas on what form this should take? I think that the minimal requirement is that the user check Boost or some part of the sandbox out of SVN and build some kind of hello world program. It would be great if that program required some demonstration of familiarity with or ability to use the standard library. Any thoughts? Andrew Sutton

1 0

Re: [boost] [filesystem] temp_dir_path()
by Domagoj Saric 21 Feb '11

21 Feb '11

"Beman Dawes" <bdawes(a)acm.org> wrote in message news:AANLkTinFigAxpqkbgwQCnOXrr-Jg44=_dep1QWn+hy-Z@mail.gmail.com... > On Tue, Oct 19, 2010 at 3:35 AM, Domagoj Saric <dsaritz(a)gmail.com> wrote: >> Would it be perhaps possible to provide a lower-level function (even in >> the detail namespace) that uses a plain char buffer and an error code, >> that is free of std::vectors, std::strings, boost::paths, >> system::error_codes and >> other things one might not want to pay for (especially if one does not >> use them otherwise) just to make a system API call..? The 'proper' >> version can then wrap the thinner one... > > It would be technically possible, of course, but ... > > What you are really asking for, I think, is a C language interface or > something pretty close to that. The attitude/assumption that anything C++ must implicitly become intimate with the keywords new, virtual and throw otherwise it is actually 'only C' is just plain wrong in the fullest sense of the word: - it is wrong 'factually' not only because (most of) C is a subset of C++ but because it is quite possible to do heavy C++ programming (e.g. so heavy that it causes GCC 4.2.1 to allocate tens of gigabytes of RAM before it eventually kills the entire OS) practically without using any of the before mentioned STL 'goodies'... - it is wrong 'morally' because it is guilty of the typical 'premature pessimization' that feeds the typical anti C++ and anti Boost arguments...IOW Linus will no longer have to ask 'How many memory allocations does it take a C++ programmer to concatenate two strings?' but 'Guess how many tens of kilobytes will calling boost::temp_dir_path() add to your binary?' The 'plain char buffer' can also be understood in a more 'relaxed'/'broader' way to for example also encompass a, more C++ like, iterator_range that specifies a preallocated chunk of storage... > I could have designed the library that way, but didn't want to add a > third way for users to do things, and didn't want to take on the > increased documentation, test, etc, workload. Calling it a 'third way' is bit too hard IMO, why not think of it just as an overload (albeit of a more extreme kind)? -- "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

3 2

Re: [boost] [1.46.0] Release candidates available
by ktc＠ktchan.info 21 Feb '11

21 Feb '11

Philipp Reh wrote: > > I reported this problem on January 30th to the boost-devel list, > right after the beta came out, but nobody cared. Hey, I reported it before the release branch code freeze and nobody cared. *shrug* KTC -------------------------------------------------------------------- myhosting.com - Premium Microsoft® Windows® and Linux web and application hosting - http://link.myhosting.com/myhosting

3 2

schedule for 1.47 new libraries
by Barend Gehrels 21 Feb '11

21 Feb '11

hi list, According to the schedule: https://svn.boost.org/trac/boost/wiki/ReleaseSchedule version 1.47 will be scheduled for the first monday of May (May 2). New libraries should be added 7 weeks before, March 14. These dates are not yet published on the Calendar: http://www.boost.org/development/index.html Are these dates correct for 1.47? Thanks, Barend Gehrels (Boost.Geometry)

2 2

PCH support for clang-linux (clang-darwin tester needed)
by Bryce Lelbach 20 Feb '11

20 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have committed a patch which fixes Boost.Build for clang-linux. The Boost.Build configuration for clang precompiled headers used a command line invocation of clang which, to my knowledge, has never worked. - -pch-use and -pch-create were the flags used, and no -o flag was placed before the target output file. I cannot find a version of clang that ever supported this syntax. There are three major distributions of clang for Linux; LLVM/Clang itself (source only), RPMs (source and binaries) and .debs (source and binaries). As the existing Boost.Build implementation of PCH support for Clang does not seem to by the clang versions shipped via any of these three mediums, I've junked the old bjam actions entirely and replaced them with actions that work. This fixs Boost.Math for clang on linux (previously clang-linux failed to compile the Boost.Math shared libraries because of this). clang-darwin has been fine because the PCH generators were disabled (I guess whoever did that forgot to do the same for clang-linux). I am not going to move these changes over to the clang-darwin toolset, because I do not have access to a darwin tester. If someone on darwin is willing to test for me, please let me know and I'll provide a patched version of clang-darwin.jam that should provide PCH support. - -- Bryce Lelbach aka wash boost-spirit.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk1XgFAACgkQ9cB/V3/s9Ez65ACfXxWcm6v5v/P6UXeCcsOmqSXJ uLMAoJHkhxA/4w3CM53ZUDVc8d7rwyI7 =AN6v -----END PGP SIGNATURE-----

2 3

[DateTime] warnings patch
by Juergen Hunold 20 Feb '11

20 Feb '11

Hi, please find a patch removing a clang warning from gregorian _calendar.ipp. The warning is warning: equality comparison with extraneous parentheses [-Wparentheses] note: use '=' to turn this equality comparison into an assignment note: remove extraneous parentheses around the comparison to silence this warning The right fix is to remove the extra parentheses. See the patch for further details. Okay to commit? 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 !

1 0

[optionał] warnigs patch
by Juergen Hunold 20 Feb '11

20 Feb '11

Hi, please find a small patch removing some gcc "unused variable" warnings attachted. Okay to commit? 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 !

1 0

[trunk] access denied
by Joachim Faulhaber 20 Feb '11

20 Feb '11

Hi, I am unable to commit changes to trunk. Attempts (using tortoise-SVN on windows) result in: Error: access to '/svn/boost/!svn/act/91b0fcb8-4a55-a041-8d53-63a889463250' forbidden can someone help? Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 1

[quickbook] issues writing the documentation for has_operator_xxx
by Frédéric Bron 19 Feb '11

19 Feb '11

I am trying to write the documentation of the operator traits using quickbook. You can have a look at it here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… untar and open type_traits/libs/type_traits/doc/html/boost_typetraits/category/value_traits/operators.html I have encountered some issues: * syntax highlighting is not working (c++ code is not in color, just in courrier font) * tables have no lines around cells, header has no special formatting as in the documentation of quickbook * table columns are two large because they adjust to their content. I would like to have some new lines inside some cells (in particular header cells) but the only way I found was to have a new paragraph which creates huge vertical space between lines. In fact, the best would be to set the column width but I did not find how to do that. * I was not able to put macros in table captions. * `code` is not recognized in table caption Maybe somebody could help me, Apart from that, quickbook is easy to use and the documentation is easy to follow. Regards, Frédéric

3 5

Requesting review manager for the variadic_macro_data library
by Edward Diener 19 Feb '11

19 Feb '11

I am looking for a review manager for my variadic_macro_data library in the Boost sandbox. It has been added to the review queue by Ron Rivera and I have been asked to try to find someone to serve as review manager for the library. The variadic_macro_data library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. The library comes with full documentation in both HTML and PDF format, as well as a series of tests. The documentation can also be regenerated from the jamfile and the tests can be run from the jamfile. The library has been tested extensively with gcc ( MingW) and VC++ on Windows and should work with any C++ compiler which supports variadic macros and does not define BOOST_NO_VARIADIC_MACROS in its compiler configuration in Boost.

1 0

[BGL] Typo in transitive_reduction.hpp
by Shaun Jackman 19 Feb '11

19 Feb '11

There appears to be a typo in transitive_reduction.hpp where a semicolon should be a comma. Cheers, Shaun --- graph/transitive_reduction.hpp (revision 68995) +++ graph/transitive_reduction.hpp (working copy) @@ -99,7 +99,7 @@ transitive_reduction(const Graph& g, Gra { //and run through all vertices in topological order typename std::vector<Vertex>::reverse_iterator - rit = topo_order.rbegin(); + rit = topo_order.rbegin(), rend = topo_order.rend(); for(; rit != rend; ++rit ) { //looking if they are successors of *it

2 1

program_options negative numbers
by Andrzej Zielinski 18 Feb '11

18 Feb '11

I am using boost::program_options and found a problem with passing a series of positive/negative numbers. i.e myProgram.out --system 0 -2 2 -3 Similar problem like in: http://stackoverflow.com/questions/4107087/accepting-negative-doubles-with-… I do not want to disable short options. I want to make quotes working. So when I call myProgram.out --system '0 -2' error: in option 'system': invalid option value myProgram.out --system 0 -2 error: unknown option -2 What quotation do you mean ? I am using bash, on CYGWIN and in linux Let me know your answer. Regards Andrzej.

2 2

[interfaces] Boost Interface Library (2004?)
by Daniel Larimer 18 Feb '11

18 Feb '11

I recently ran across the unofficial Boost Interface Library (http://www.coderage.com/interfaces) but it appears that it is was never adopted nor much discussed since I joined this mailing list. Boost.Interfaces provides a macro-based Interface Definition Language (IDL) which can be used to define C++ class types called interfaces. An interface is a lightweight value type associated with a set of named function signatures. An interface instance can be bound at runtime to any object which implements the interface, i.e., to any object of a type with accessible non-static member functions having the same name and signature as the set of functions associated with the interface. The functions of the bound object can then be invoked through the interface instance using the �dot� operator. Binding is completely non-intrusive: the object's type need not declare any virtual functions or derive from any particluar base class. Interfaces were described in a September 2004 C/C++ Users Journal article by Christopher Diggins. After looking through the library I concluded that I did not like how it was implemented. Too many macros, unnatural syntax. I guess few people liked it enough for it to be kept up to date (6+ years old now). I have also looked at the Boost Mirror library which provides reflection of just about everything at the expense of some nasty macros and no clear path toward defining dynamic interfaces based upon the reflected type information. I think the goal of the interface library should be a more flexible/powerful version of "boost::any" that allows you to define the interface of the object stored in the 'any'. In this way it takes type erasure to a new level. That said, I have a need for developing an interface library that abstracts the differences between direct pointer access, RPC, and asynchronous inter-thread communication. So I have developed and tested a new 'api' for defining interfaces with the hope that it would be considered worthwhile for boost. Goals / Non-Goals 1) Define Interfaces in Natural C++ Syntax 2) Provide the ability to define 'dynamic' implementations of an interface for calling RPC, scripting language interface, etc. 3) Objects that implement 'interfaces' should be long-lasting 'actors' where overhead of creating/copying/destroying the interface along with any memory usage is of secondary importance to the ease of defining dynamic interfaces and achieving 'type erasure'. 4) Ideally each member of an interface is a function object that can be bound to anything. I am interested in feedback on what the API/features should be of a generic interface library to improve upon BIL. Should the interface definition classes be in a namespace such as idl_definition or should the BOOST_IDL_INTERFACE macro place the interface type in an 'idl' namespace? Example: namespace idl_definition { struct SomeBase { // these methods need not be implemented anywhere as they are never called. std::string name()const; }; struct Shape : public SomeBase { double area(int); std::string type(); std::string my_mem; }; } BOOST_IDL_INTERFACE( SomeBase, BOOST_PP_NIL, (name) ) BOOST_IDL_INTERFACE( Shape, (SomeBase,BOOST_PP_NIL), (area) (type) (my_mem) ) class print_api_visitor : public boost::idl::visitor<print_api_visitor> { public: template<typename InterfaceName, typename M> bool accept( M& m, const char* name ) { std::cerr << boost::idl::get_typestring<InterfaceName>::str() << "::" << name << " " << boost::idl::get_typestring<typename M::signature>::str() << (M::is_const ? "const" : "") << std::endl; return true; } }; class Circle { public: std::string name()const{ return "CircleName"; } double area(int v) { return v*3.1415; } std::string type() { return "circle"; } std::string my_mem; }; int main( int argc, char** argv ) { boost::shared_ptr<Circle> c(new Circle()); Shape s = c;//Circle(); //new Circle(); s.my_mem = std::string("HelloWOrld"); std::string tmp = s.my_mem; std::cerr<<"type: "<<s.type() << std::endl; std::cerr<<"area: "<<s.area(3) << std::endl; std::cerr<<"area: "<<*s.my_mem << std::endl; std::cerr<< "9*pi = "<<boost::idl::make_delegate( c.get(), Shape::__idl__area::get_member_on_type<Circle>() )(9) << std::endl; std::cerr<< "my_mem = "<< c.get()->*Shape::__idl__my_mem::get_member_on_type<Circle>() << std::endl; std::cerr<< "my_mem = "<< c.get()->*s.my_mem.get_member_on_type<Circle>() << std::endl; std::cerr<<"print api!\n"; print_api_visitor papi; papi.start(s); Circle* c2 = new Circle; c2->my_mem = "Circle2!!!"; boost::idl::set_delegate_visitor<Circle> sd(c2); sd.start(s); std::cerr<<"c->area: "<< *s.my_mem << std::endl; return 0; } Here is an example of the visitor used to setup the delegate: template<typename T> class set_delegate_visitor : public boost::idl::visitor<set_delegate_visitor<T> > { public: set_delegate_visitor( T* self = 0) :m_self(self){} template<typename InterfaceName, typename M> bool accept( M& m, const char* name ) { m.set_delegate( m_self, M::template get_member_on_type<T>() ); return true; } private: T* m_self; }; Output ==================== type: circle area: 9.4245 area: HelloWOrld c->area: HelloWOrld sizeof(s): 120 9*pi = 28.2735 my_mem = HelloWOrld my_mem = HelloWOrld print api! SomeBase::name std::string()const Shape::area double(int32_t) Shape::type std::string() Shape::my_mem std::string c->area: Circle2!!!

6 14

[ICL] cardinality of float interval
by John Reid 18 Feb '11

18 Feb '11

cardinality( interval< float >( 1, 5 ) ) == 18446744073709551615 Can this be true? Is this by design?

3 3

shared_from_this() fails from boost.serialization load()
by Allan Johns 18 Feb '11

18 Feb '11

Hi, Consider class A, which contains an instance of class B, which in turn contains a weak reference to its parent A instance (note: pseudocode): class A; class B { weak_ptr<A> m_parent; } class A { shared_ptr<B> m_child; } I have a case where I am boost-serializing class A, and its load() method looks like so: template<class Archive> void A::load(Archive& ar, const unsigned int) { ar & m_child; m_child->m_parent = shared_from_this(); } Note that B does *not* serialize its m_parent member (this is by design). The problem I have is that the shared_from_this() call in A::load() fails, even though I am guaranteeing that A is serialized via a shared_ptr. Presumably boost.serialize is not placing the default-constructed instance of A into its containing shared_ptr<A>, before calling A::load(). My question is, is there any reason why boost.serialize couldn't deal with this special case, which would allow me to call shared_from_this() from load()? I don't have a workaround for this in my code, other than to resort to a raw ptr for B::m_parent. ps - I suppose you could argue that since you can't do this in A's constructor, you shouldn't be able to do it in its load() function either. However I do have a legitimate case where I need to do this... I can extrapolate on the whole situation if necessary, but I've left it out here in the interests of simplicity). Thanks boosters, Allan

1 1

BOOST_NOEXCEPT macro?
by Beman Dawes 18 Feb '11

18 Feb '11

Should we add a BOOST_NO_NOEXCEPT config macro, and then provide a header with something like: #ifdef BOOST_NO_NOEXCEPT # define BOOST_NOEXCEPT throw() #else # define BOOST_NOEXCEPT noexcept #endif --Beman

7 9

[interprocess] named_mutex issues
by Sam Partington 17 Feb '11

17 Feb '11

Hello, I recently found a bug in my own implementation of named_mutex (which uses record locking) and thought that it was high time that I investigated the boost implementation to replace my own version. Unfortunately I found the documentation extremely unclear about what guarantees named_mutex makes under certain circumstances. e.g. 1) What happens if I call boost::named_mutex::remove whilst I have it opened or locked in another process. 2) What happens if the process terminates when a mutex is locked without calling the destructors? (e.g. Ctrl-C or seg fault) 3) The docs describe the mutex as "A mutex with a global name, so it can be found from different processes", what about other users? Is this intended to work or not? 4) Does ~named_mutex unlock the mutex if it is still locked? 5) What names are valid? Slashes, spaces, etc? To find these out I had to follow the implementation right down through many layers of indirection and compile time switches to discover what the underlying synchronisation mechanism was (POSIX Semaphore on linux). And of course write a couple of examples to test my interpretations. The answers on linux at least are 1) It removes the semaphore, but as it's link count is not 0 it remains and the other process keeps it's lock. Meanwhile another process can then create a new named_mutex of the same name AND lock it. Essentially messing up the whole mutual exclusion policy as two processes lock the same mutex. I don't think there is a (reasonable) solution to this and IMO this potential pitfall needs to be made clear in the docs. 2) If the process does not shutdown cleanly whilst the mutex is locked it doesn't release the lock. Another process could in theory create the lock again and unlock it again. But I don't know how it could detect this situation, unless some process is the 'master' and can initialise all state to a known state. (This doesn't apply in my use case for example) 3) This doesn't really work because the process umask means that the semaphore is likely to be created 0755 and can't be opened by other users. They get permission denied even if the mutex is not locked. a simple { int oldmask = umask(0); ... umask(oldmask); around the sem_open would solve this. 4) No the mutex is not unlocked if destroyed when locked. I thought this was a bit surprising. Unfortunately I don't suppose you can really change that now, but it should de documented. 5) slashes must not be used to conform with POSIX, and it must not be longer than MAX_PATH other platforms I don't know. I appreciate with so many platforms and different implementations it must be very difficult to document these things. But at least it should not be so hard to find out what the underlying mechanism is. Ultimately though the whole point of an abstraction library like this is to make it so that you don't have to worry about the specifics of the implementation or the platform, but to provide a common set of guarantees and specifications. Without those the abstraction layer is kind of missing the point. Another thing I found on the way is that strictly speaking the call to sem_open is undefined behaviour (at least according to POSIX.4. Programming for the real world by Bill O. Gallmeister). As you should not pass any of O_RDONLY O_WRONLY or O_RDWR. See http://books.google.co.uk/books?id=4Kb_1sKprCMC&lpg=PA432&ots=v7mIM0xVHS&dq… http://preview.tinyurl.com/5slzcu6 Although another reference I found suggested that it would be merely unspecified not undefined. I guess I will have to stick with my own implementation because 2) is incompatible with my requirements. Sam PS I tested this on boost 1.45 with the following code : #include <boost/interprocess/sync/named_mutex.hpp> #include <iostream> #include <string> using namespace boost::interprocess; int main() { named_mutex m(open_or_create, "named_mutex_test"); m.lock(); std::cout << "Lock obtained, type something + press enter:"; std::string s; std::cin >> s; m.unlock(); named_mutex::remove("named_mutex_test"); }

1 0

Adding libc++ support to boost.
by Christopher Jefferson 17 Feb '11

17 Feb '11

Hello, I want to add support for libc++, the c++ standard library attached to clang, to boost. Fixes required should not be attached to clang, as clang can use various standard libraries. Is there a standard way I should add the library, or just add the macro where needed. The best macro to use for detecting libc++ is _LIBCPP_VERSION. Hopefully the changes required will be minimal. One place where libc++ needs to be mentioned in is detail/container_fwd.hpp, as forward declarations simply don't work. Can I just attach _LIBCPP_VERSION to: #if defined(BOOST_DETAIL_NO_CONTAINER_FWD) \ || ((defined(__GLIBCPP__) || defined(__GLIBCXX__)) \ && (defined(_GLIBCXX_DEBUG) || defined(_GLIBCXX_PARALLEL))) \ || BOOST_WORKAROUND(__BORLANDC__, > 0x551) \ || BOOST_WORKAROUND(__DMC__, BOOST_TESTED_AT(0x842)) \ || (defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)) Or is there a better / more offical way libc++ should be worked in? Chris

4 7

[Boost-interest] C++ library for runtime-concepts (type-erasure)
by Germán Diago 17 Feb '11

17 Feb '11

Hello all. My name is Germán Diago and I'm been implementing a library for runtime concepts that I would like to submit to boost someday. It's a library that is targeting a way to be able to play well with boost.concept_check library, complementing it with the ability to hold those concepts in a runtime fashion. The target of the library is: -100% nonintrusive: -Being able to specify that a class models a concept without touching the class (via traits, not done yet). -Adapt via adl names of functions which don't match a concept for a class to be able to use that class as a concept. -Feel natural: being able as much as possible to convert from concept hierarchies as it's done for base and derived types. -Playing nicely with boost.concept_check. -Being able to specify that a class models more than one unrelated concept (via mpl::vector maybe). The features for the library, for now, just target movable and noncopyable objects, but I'll make it more general over time. I would like to hear feedback from all of you. Currently, the library can specify a runtime type that can hold objects modeling a concept. It's better to explain the workings of the library with an example, so here it goes: //Compile-time concepts namespace Concepts { template <class T> std::size_t getCapacityInMB(const T & t) { return t.getCapacityInMB(); } template <class T> void onOpen(T & t) { t.onOpen(); } template <class T> void onRemove(T & t) { t.onRemove(); } template <class T> struct Device { BOOST_CONCEPT_USAGE(Device) { t.getCapacityInMB(); } T t; static std::size_t getCapacityInMB(const T & v) { using Concepts::getCapacityInMB; return getCapacityInMB(v); } }; template <class T> struct PlugableDevice : Device<T> { BOOST_CONCEPT_USAGE(PlugableDevice) { plug_dev.onOpen(); plug_dev.onRemove(); } T plug_dev; static void onRemove(T & t) { using Concepts::onRemove; onRemove(t); } static void onOpen(T & t) { using Concepts::onOpen; onOpen(t); } }; } First, I must explain my runtime concept implementation as of now. We have a model and an interface class for each runtime concept we want to model. A concept is a class that is templated like this: template <class ConceptInterface, template <class> class Model, class BaseConcept = EmptyType, template <class> class ConceptCheckingClass = EmptyConcept> When we template this class with the ConceptInterface and with the model class, we can hold instances modeling that concept. Besides that, we can (optionally) enforce the compilance of our types with the compile-time concepts if we provide the concept checking class in the last template parameter. The template parameter BaseConcept specifies wether the concept refines another concept. This way it plays nicely with implicit conversions from derived-to-base. If a class inherits a concept, that concept will be inherited by the typedef. The storage for the class is held in the root of the hierarchy, and it always holds models for the most derived concept that a class models (though you have to tell the compiler which Concepts a class models) These are two classes covering two concepts (compile-time). We want to be able to hold unrelated instances modeling those concepts at runtime, so we can do something like this for both instances. //Runtime Concepts layer class IDeviceC { public: virtual std::size_t getCapacityInMB() const = 0; }; template <class T> class DeviceCModel : public MovableModelBase<T>, public IDeviceC { public: IMPLEMENT_MODEL_DEFAULT_MEMBERS(DeviceCModel) virtual std::size_t getCapacityInMB() const { return Concepts::Device<T>::getCapacityInMB(this->getData()); } }; typedef MovableConceptBase<IDeviceC, DeviceCModel, EmptyType, Concepts::Device> DeviceC; //Refined concept class IPlugableDeviceC : public IDeviceC { public: virtual void onOpen() = 0; virtual void onRemove() = 0; }; template <class T> class PlugableDeviceCModel : public MovableModelBase<T>, public IPlugableDeviceC { public: IMPLEMENT_MODEL_DEFAULT_MEMBERS(PlugableDeviceCModel) virtual void onOpen() { Concepts::PlugableDevice<T>::onOpen(this->getData()); } virtual std::size_t getCapacityInMB() const { Concepts::PlugableDevice<T>::getCapacityInMB(this->getData()); } virtual void onRemove() { Concepts::PlugableDevice<T>::onRemove(this->getData()); } }; //Create concept class that refines DeviceC, The 3rd parameter is the concept it refines typedef MovableConceptBase<IPlugableDeviceC, PlugableDeviceCModel, DeviceC, Concepts::PlugableDevice> PlugableDeviceC; Now we can provide a program with classes that model those concepts and try a little: class LegacyDevice : NonCopyable { public: //This class models DeviceC concept typedef DeviceC ModelOfType; std::size_t getCapacityInMB() const { return 10; } }; class IpodDevice : NonCopyable { public: //This class models PlugableDeviceC concept typedef PlugableDeviceC ModelOfType; void onOpen() { std::cout << "Opening Ipod device" << std::endl; } void onRemove() {} std::size_t getCapacityInMB() const { return 32 * 1024; } }; int main(int argc, char * argv[]) { std::vector<DeviceC> devices; IpodDevice ipod; LegacyDevice legacy; //devices.push_back(move(legacy_device)); devices.push_back(move(ipod)); devices.push_back(move(legacy)); DeviceC & dev_ref = devices[0]; std::cout << dev_ref->getCapacityInMB() << std::endl; for (auto & device : devices) { //device->onOpen(); std::cout << device->getCapacityInMB() << std::endl; } //TODO: Doesn't work downcasting because of the lvalue reference, buf dev_ref is actually holding a model that inherits the most-derived //PlugableDeviceC & pd = dynamic_cast<PlugableDeviceC&>(dev_ref); //pd->onOpen(); std::shared_ptr<DeviceC> dev_sptr(new PlugableDeviceC(IpodDevice())); std::cout << "Shared pointers:\n"; std::cout << (*dev_sptr)->getCapacityInMB() << std::endl; auto derived_ptr = dynamic_pointer_cast<PlugableDeviceC>(dev_sptr); (*derived_ptr)->onOpen(); IpodDevice & ipod_device = static_cast<IpodDevice&>(*derived_ptr); std::cout << "Ipod device back to concrete type: " << ipod_device.getCapacityInMB() << std::endl; std::cout << "Size of DeviceC " << sizeof(DeviceC) << std::endl; std::cout << "Size of PlugableDeviceC " << sizeof(PlugableDeviceC) << std::endl; std::cout << "The end" << std::endl; } You can see that conversions work, except for downcasting. The downcasting does not work because of an lvalue-ness problem, but if you instantiate a class like this: IpodDevice dev; DeviceC device(move(dev)); It will be holding an object modeling the PlugableDevice concept. The problem is that I cannot convert to a PlugableDeviceC because it's being held in a DeviceC, but the most-derived model is correctly instantiated. There are still things to do, but I feel they can be accomplished: -Downcasting: I can make a special type View<PlugableDeviceC> which can point to instances held in a DeviceC (maybe, don't know). -Generalize MovableConceptBase and MovableModelBase classes, so that you can use classes that are copyable, equality_comparable, etc. With these two pieces and maybe some improvements, I think I can provide a library that plays well with Boost.concept_check library and which is the runtime counterpart of it. Feedback is very welcome.

6 19