- Boost - lists.boost.org

[Proto] Expression as fusion/MPL sequence
by Joel Falcou 03 Jun '11

03 Jun '11

Seems somethign crooky on this front. Calling fusion::at_c on expression ends up in error even after including boost/proto/fusion.hpp. Same way, flatten used as a transform seems to not give me a type that can be passed to any fusion or mpl function. Looking at proto/fusion.hpp I noticed that the iterator is indeed random_access but not the view itself which as a forward_traversal tag. Even after fixing this, no dice, at_c<N>(some_proto_expr) still fails to compile.

3 3

[test] Running regression tests
by Edward Diener 02 Jun '11

02 Jun '11

Attempting to run regression tests for the 'test' library on the Boost trunk I receive as output: "..\..\..\libs\test\build\Jamfile.v2:107: in modules.load rule boost-install unknown in module Jamfile</C:/Programming/VersionControl/boost/libs/test/build>. C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:314: in load-jamfile C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:62: in project.load C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:766: in project.use C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:89: in load-used-projects C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:73: in load C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:115: in load-parent C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:464: in initialize C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:309: in load-jamfile C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:62: in load C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:115: in load-parent C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:464: in initialize C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:309: in load-jamfile C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:62: in load C:/Programming/VersionControl/boost/tools/build/v2/build\project.jam:168: in project.find C:/Programming/VersionControl/boost/tools/build/v2\build-system.jam:570: in load C:\Programming\VersionControl\boost\tools\build\v2/kernel\modules.jam:283: in import C:\Programming\VersionControl\boost\tools\build\v2\kernel\bootstrap.jam:142: in boost-build C:\Programming\VersionControl\boost\boost-build.jam:17: in module scope" All other regression tests for libraries produce no Boost Build errors. Can anybody tell me what is wrong here ?

4 4

std::map::find() wrapper
by Olaf van der Spek 02 Jun '11

02 Jun '11

Hi, I've written a small wrapper for std::map::find() (and map-like containers/ranges) that returns a pointer to the value if found (or NULL if not found). See https://svn.boost.org/trac/boost/ticket/5227 The advantage is that you don't need the container type name (for ::reference), you can initialize the pointer inside an if condition, you don't have to compare against ::end() and you don't have to use ->second. For containers of pointers to objects, the wrapper could do an additional dereference. Do you think this would be useful for inclusion in Boost? Greetings, Olaf

17 61

[review] Heaps: size and stability
by Andrew Sutton 02 Jun '11

02 Jun '11

Tim, Do you really need to parametrize the constant-time size property? C++11 requires constant time size for all containers. I think that this is also a reasonable requirement for Heaps. I'm not aware of any applications that use so many heaps that the extra 4-8 bytes required by a size parameter would make huge difference in memory usage. Also, for heaps that can be effectively implemented in terms of other containers, they should guarantee O(1) size. The stability issue relates to a previous discussion from a couple months ago (brought up by Cliff Green, http://article.gmane.org/gmane.comp.lib.boost.devel/219330) Cliff was concerned that the implementation of stability added overhead to the normally unstable heaps (i.e., an extra size_t, I think) from the implementation. I worry that the use of a policy parameter to specify stability will result in "accidental overhead" in cases where users don't fully understand the impact of their configuration choices. Would it be better (would it be possible?) to write stable_heap as a heap adaptor? I think that this approach (if possible) has two benefits. First it encapsulates the strategy for implementing stability. It also provides a single point of reference for describing the impact of using that configuration. Andrew

3 4

safe-bool CRTP class
by Krzysztof Czainski 01 Jun '11

01 Jun '11

Hello, Vladimir Batov prepared a safebool helper class as part of his Pimpl library. I quote his rationale: /// An implicit conversion to bool (operator bool() const) is very much /// idiomatic and is often deployed in constructs like "if (foo)" and "if (!foo)" /// (with no explicit op!() defined). However, sadly, implementing "operator bool()" /// is *wrong* as that conversion kicks in far too often and unexpectedly. Like in /// "foo == 1", "foo+1", "1+foo" or potentially during lexical_cast<string>(foo) /// (if there are no op>>() and op<<() defined). Consequently, that "implicit /// conversion to bool" functionality has to be implemented in an indirect and /// somewhat awkward way via an implicit conversion to some other type. The best /// type for the purpose appears to be a pointer to a member function. For more /// see the chapter 7.7 in Alexandrescu's "Modern C++ Design" and the article at /// http://www.artima.com/cppsource/safebool.html by Bjorn Karlsson. In the review of Pimpl Joej Falcou suggested to make safebool a CRTP base class. I had prepared such a class some time ego, and I've been using it for a while now. Is there interest in adding it to boost? Perhaps as part of the operators library? /** * CRTP class, that provides operator unspecified_bool_t() const, implemented in terms of * Derived::operator! */ template < class Derived, class Base = empty_t > class boolable : public Base { void unspecified_bool_t_f() {} typedef void (boolable::*unspecified_bool_t)(); public: operator unspecified_bool_t() const { return ! static_cast<Derived const&>( *this ) ? 0 : &boolable::unspecified_bool_t_f; } }; Usage: struct X : public boolable<X> { bool operator!() const { return condition; } // inherit operator unspecified_bool_t implemented in terms of the above operator! }; Regards, Kris

13 39

[Math and numerics] interest in Circular values math and statistics library ?
by Lior Kogan 01 Jun '11

01 Jun '11

I built a C++0x circular-values math and statistics library, and posted it on CodeProject. See http://www.codeproject.com/KB/recipes/Circular-Values.aspx I wonder if such library may be a welcomed addition to Boost. Thank you, Lior

5 5

Re: [boost] [pimpl] Mini Review
by Sean Chittenden 01 Jun '11

01 Jun '11

>> I've been watching this discussion for a while (with vested >> interest), and want to use a few examples to shore up some of >> the discussion (and possibly move it off list so that things >> can proceed in a constructive manner). The concern is not that >> Pimpl is implementing an opaque pointer, it's the miscellaneous >> copy constructors, constructors, equality or whatever other >> misc "extras" that come along from using Pimpl, right? > > Not quite. Copy constructors and copy assignment, for example, are appropriate. They allow the library to manage copies of the implementation object. Problems arise, for example, from the addition of null(),operator ->(), and operator *(). This is less rhetorical than I'd like, but what's the right amount of baggage that a Pimpl implementation can bring along with it? On one side of the spectrum you have an austere implementation that is literally an opaque pointer with its relevant compilation glue ("the one true/pure pimpl"). On the other side of the spectrum you've got something that overloads functions and operators and makes a pimpl implementation easier to use, ala the Pimpl library. For example: https://github.com/sean-/Boost.Examples/blob/master/pimpl/boost/pimpl/pimpl… Not strictly necessary, but I understand why it's there and why it would be wanted in a Pimpl implementation. I also understand the puritanical argument for why you wouldn't want it. > reset(), which may be protected rather than public (I don't recall), is not as much of a problem, but my suggestion for that was that since the constructors allocate the implementation object, "resetting" the implementation should likewise not involve allocation. For that, I suggested a construct() member function template set, paralleling the constructors that implement "perfect forwarding." A constructor and a reset() that take a deleter would be appropriate for cases in which allocation is not desired. That design would be symmetrical. Got it, ok. >>> class Book : public pimpl< Book >::pointer_semantics { }; >>> // Or is the interface different because the ABI is >>> // different? >>> class Book { >>> class* impl_; >>> }; > > It's different because using inheritance and public member functions, pimpl<Book>::whatever has augmented Book's interface. Correct/agreed. >> With as (in?)efficient compilers sucking up gigs of RAM and >> frequently crashing during compilation[1], having a friendly >> mechanism to hide linkage and implementations behind opaque >> pointers is useful beyond externally exposed APIs in libraries. >> The tedium of doing this frequently makes the Pimpl library an >> easy win for many developers (though possibly not all of them >> and not in all situations). As a Pimpl consumer for over a >> year, I'm trying to concretely demonstrate where the possible >> pitfalls could be lurking with this implementation. Thanks in >> advance. -sc > > I have no problem with using the Pimpl Idiom. Just this past week I was able to advance some application testing readily because we used it in a couple of classes involved in an application's disorderly shutdown due to misconfiguration. My concern is that the Pimpl Library seems to have pushed past the idiom into something else, which is surprising to me and, clearly, to others. I should also be clear that I'm not against what the Pimpl Library has done, in terms of augmenting the derivate's interface via public inheritance, but that doing so should be in a class template and a library of a different name. That feedback makes sense, thanks Robert. I think the unease is coming from the Pimpl library implementing helpers and extending beyond only providing an opaque pointer. TBH, before using Pimpl, I'd implemented a subset of the helper functions in my own home-grown pimpl library so seeing them standardized never struck me as objectionable (the possibility of running in to name clashes, not withstanding). In fact, my search for Boost.Pimpl began because I missed adding a non-const* ->() to my implementation. After wading through pages of gcc error messages (naturally this happened in the middle of a asio/bind/wrap call) I started looking for a reference implementation that had some of this spelled out since I didn't think I should be spending my time reimplementing the wheel. I don't have an answer for what's "right" on the spectrum of austere vs "featureful", but the featureful side of Pimpl has clear merit. I'll move the rest of my comments over to the review tool. -sc http://demo.smartbear.com/boost/go?page=ReviewDisplay&reviewid=5 -- Sean Chittenden sean(a)chittenden.org

2 1

[conversion] ADL and templates
by Vicente BOTET 01 Jun '11

01 Jun '11

Hi, I've tried to add a configuration point in Boost.Conversion via overloading and ADL, but while the internal call of the library can find them using a trick that adds a parameter that contains the type of the return type, the user is not able to find them without using the same this trick, but this is too dark to be natural for user code. Next follows a simplified code of the problem. The following namespace N { struct S{}; template (*typename T*) T fct1(S const& s) { return T(s); } template (*typename T*) void fct2(T &t, S const& s) { t=s; } } void test () { N::S s1; N::S s2; fct2(s2, s1); s2=fct1(*N::S*)(s1); // (1) } Results in a compile error in (1) error: ‘fct1’ was not declared in this scope Is it standard behavior that fct1 can not be found by ADL? Thanks, Vicente P.S. Please replace (* and *) by angle brackets.

4 11

Cross-platform process library?
by Gregory Crosswhite 01 Jun '11

01 Jun '11

Hey everyone, Since there is not yet a Boost.Process library, does anyone have a suggestion for a lightweight cross-platform C++ library for launching and monitoring (i.e. being able to tell if they die) child processes? Thanks! Greg

3 2

Re: [boost] [pimpl] Mini Review
by Sean Chittenden 01 Jun '11

01 Jun '11

>>> Helping to implement copying and assignment is useful, >>> provided the class is supposed to support those operations. >> >> shared_ptr-based Pimpls copying and assignment are done by >> shared_ptr. > > That tells me that Pimpl provides copying and assignment for the derivate. > As you've noted, this is only by virtue of using private inheritance. I still don't think it is correct behavior for a library implementing the Pimpl Idiom to modify the interface class' (Book's) interface. Consider a raw pointer Pimpl design: > > class Book { > // state > }; > > becomes: > > class Book { > struct impl; > impl pimpl_; > }; > > struct Book::impl { > // state > }; > > Adding a pimpl did nothing to Book's interface. Why then should Book's interface chance when using your library? That seems to be an extension of the idiom into the territory of the Bridge Pattern or something else entirely. I've been watching this discussion for a while (with vested interest), and want to use a few examples to shore up some of the discussion (and possibly move it off list so that things can proceed in a constructive manner). The concern is not that Pimpl is implementing an opaque pointer, it's the miscellaneous copy constructors, constructors, equality or whatever other misc "extras" that come along from using Pimpl, right? To recap (using pointer semantics since that's my preferred implementation): > // book.h > class Book : public pimpl< Book >::pointer_semantics { > // interface > }; > > // book_impl.cc > template<> struct pimpl< org::example::String >::implementation : boost::noncopyable { > // impl state > } > Book::Book() : base() { } > > // user.cpp > Book b; > std::cout << "sizeof(Book): " << sizeof(b) << std::endl; From an ABI perspective, Book implemented via Pimpl maintains the same size (currently 16 bytes, regardless of Book::implementation), and thereby provides a stable ABI (if someone really was concerned about future-proofing their frontend ABI, they could pad Book in book.h). I think the concern is coming from: > Book* b2 = new Book(); > Book* b1 = b2; because there possibly isn't a clear understanding of how those mechanics would work with Pimpl (yes?). Or is it because it's unclear how you'd obtain the desired copy semantics - for example - with the proposed Pimpl library? I'm trying to tease out what the actual feedback is or what the possible suggestions could be (vs outright criticism). > Modifying the interface is the part I was referring to. > > You've said that copying and assignment are only supported (for value semantics, anyway) if the derivate provides them. That's a good approach. If everything is of that sort, then all's well, but that's not what I see. How is Book's interface different? > // Is the Interface different because of the inheritance? > class Book : public pimpl< Book >::pointer_semantics { }; > // Or is the interface different because the ABI is different? > class Book { > class* impl_; > }; Would a Pimpl implementation with preprocessor directives be more suitable because of the level of explicitness? Also, Pimpl implements an opaque pointer and successfully breaks compilation dependencies. Pimpl is not a Bridge implementation. > class Book { > PIMPL_PUBLIC_INTERFACE(Book, impl); > }; ? I use similar cpp(1) magic to implement NO_COPY_OR_ASSIGN() because I've found it to be more predictable in working (or failing) than inheriting from boost::noncopyable. With as (in?)efficient compilers sucking up gigs of RAM and frequently crashing during compilation[1], having a friendly mechanism to hide linkage and implementations behind opaque pointers is useful beyond externally exposed APIs in libraries. The tedium of doing this frequently makes the Pimpl library an easy win for many developers (though possibly not all of them and not in all situations). As a Pimpl consumer for over a year, I'm trying to concretely demonstrate where the possible pitfalls could be lurking with this implementation. Thanks in advance. -sc [1] A few years ago I came to terms with it being a Boost "Right Of Passage" to debug your first compiler crash (that wasn't the result of running out of RAM). -- Sean Chittenden sean(a)chittenden.org

2 1