May 2011 - Boost - lists.boost.org

none_t I/O operators
by Gregory Crosswhite 05 Jun '11

05 Jun '11

Hey everyone, I have recently run into a scenario where it was useful to have << and >> I/O operators defined for none_t. I was using Boost Program Options to create a list of program options, and I wanted one of my options to be a help message. Since this option has no value except for the side effect of printing a help message and exiting, I gave it the type none_t, i.e.: options.add_options() ( "help" ,opts::value<none_t>()->zero_tokens()->notifier(...function that prints help message...) ,"print help message and exit\n" ) When I did this, it complained that the >> operator was not defined for none_t, so I went ahead and defined my own I/O operators, which are essentially just no-ops: inline std::istream& operator>> (std::istream& in, boost::none_t& _) { return in; } inline std::ostream& operator<< (std::ostream& out, const boost::none_t& _) { return out; } It seems to me that these are the natural I/O operators to define for this type, and so it would be useful to have them be officially part of Boost. Although it is unlikely that a user would ever call them directly, their existence could prove useful in various circumstances where a generic I/O function is being applied to a none_t, such as the case I ran into/ If people were willing to accept a patch that adds these operators to Boost, then I would be willing to write such a patch. Obviously I would need to generalize the istream/ostream types to the full generic versions which include the template parameters for character traits, etc. I would also add forward declarations of istream and ostream just before these declarations so that the implementation would not need to have the <istream> and <ostream> headers as dependencies, though this would be tricky because I'd need to figure out how to detect if <istream> and/or <ostream> have not been included yet. Thoughts? Cheers, Greg

3 6

Re: [boost] [msm] need to increase the fusion set and map size to 30
by Christophe Henry 05 Jun '11

05 Jun '11

> So i added these two statements at the beginning, and this solved the > problem. > > # define FUSION_MAX_SET_SIZE 30 > # define FUSION_MAX_VECTOR_SIZE 30 > > Perhaps we can add this somewhere in the doc. Hi Kim, Maybe I should make this subject more visible. It is described here: http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/ch05.html I think that FUSION_MAX_VECTOR_SIZE is actually enough, but it's only due to the fact that set is implemented in terms of vector (to be exact, as I only use fusion::set, FUSION_MAX_SET_SIZE ought to be enough, but it's not, so I suppose it's a fusion bug). Regards, Christophe

2 2

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

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

02 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

[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

[function] [1.47.0] #4717: Non-const local static variable stored_vtable
by Kazutoshi Satoda 01 Jun '11

01 Jun '11

I want the fix for the following ticket (regression, I think) included in 1.47. "#4717: Non-const local static variable stored_vtable" https://svn.boost.org/trac/boost/ticket/4717 Here is a quote of a essential part of the fix. - static vtable_type stored_vtable = + static const vtable_type stored_vtable = { { &manager_type::manage }, &invoker_type::invoke }; https://svn.boost.org/trac/boost/attachment/ticket/4717/djw_function_const_… I did same request for 1.46 and 1.46.1, and got no response. http://lists.boost.org/Archives/boost/2011/03/177769.php http://lists.boost.org/Archives/boost/2011/01/175248.php Please let me know if there is more effective way to push the fix, or if I'm doing something wrong. -- k_satoda

2 2

[shared_ptr] Some design advice
by Johnny Willemsen 31 May '11

31 May '11

Hi, I want to create some refcounted objects using shared_ptr. For example if I have class A_impl, I want my users only to use A. So, I created the following code: class A_impl { public: virtual ~A_impl () {}; void dosomething () {}; }; typedef shared_ptr <A_impl> A; The challenge is now that I want to provide some typedefs on A (which is a shared_ptr()). So that my users can use: A::my_value_type; I am aware of the reference_type, but I need to have some additonal typedefs and constants as part of A. I have started with a partial template specialization of shared_ptr, but I have my doubts whether this is the correct way. Another option would be to create our own shared_ptr that just embeds the boost_shared_ptr and exposes just some of its methods. Any specific ideas on this? Regards, Johnny

2 1