- Boost - lists.boost.org

Detecting if a class overrides free store functions
by Michael Marcin 07 Jan '09

07 Jan '09

I want to create a STL allocator that uses a class's static new function if it exists and will fallback on std::allocator::allocate if it doesn't. I think it should be easy to do this with sfinae but I don't see an appropriate type trait to detect if a class provides allocation and deallocation functions. Should these be provided? Maybe boost::has_allocation_function<T> boost::has_deallocation_function<T> or just boost::has_new<T> boost::has_delete<T> -- Michael Marcin

3 3

[smart ptr] implicit auto_ptr r-value initialization for scoped_ptr?
by Jason Moore 07 Jan '09

07 Jan '09

This is absolute genius!!! (i.e. implicit only for r-values of type std::auto_ptr<T>) std::auto_ptr<T> Create(); ... if (boost::shared_ptr<T> my_ptr = Create()) { my_ptr->doIt(); } Why is this feature not provided for boost::scoped_ptr? Thanks, Jason Moore

1 0

is_convertible problems associated with move-only types
by Howard Hinnant 07 Jan '09

07 Jan '09

I'm continuing to refine a boost::unique_ptr emulation and testsuite. One thing I've just uncovered is that I'm hitting a brick wall with is_convertible and move-only deleters used within the unique_ptr move constructor. The problem is that boost::is_convertible<From, To> assumes From is an lvalue. is_convertible<Deleter, Deleter> gets instantiated and it is all over. I've modified my copy of is_convertible (without really knowing what I'm doing) like so: Index: is_convertible.hpp =================================================================== --- is_convertible.hpp (revision 50433) +++ is_convertible.hpp (working copy) @@ -119,6 +119,8 @@ struct any_conversion { template <typename T> any_conversion(const volatile T&); + template <typename T> any_conversion(volatile T&); + template <typename T> any_conversion(const T&); template <typename T> any_conversion(T&); }; @@ -131,8 +133,8 @@ template <typename From, typename To> struct is_convertible_basic_impl { - static From _m_from; - static bool const value = sizeof( detail::checker<To>::_m_check(_m_from, 0) ) + static From _m_from(); + static bool const value = sizeof( detail::checker<To>::_m_check(_m_from(), 0) ) == sizeof(::boost::type_traits::yes_type); }; @@ -291,7 +293,8 @@ template <typename From, typename To> struct is_convertible_impl { - typedef typename add_reference<From>::type ref_type; +// typedef typename add_reference<From>::type ref_type; + typedef From ref_type; BOOST_STATIC_CONSTANT(bool, value = (::boost::type_traits::ice_and< ::boost::type_traits::ice_or< This hits just the part targeting gcc. The intent is that in boost::is_convertible<From, To> From is now considered an rvalue (unless From is a (lvalue) reference type). This makes my test case happy. I can now move construct a unique_ptr with a move-only deleter. Fwiw, this definition of is_convertible is consistent with std::is_convertible in N2800: > In order to instantiate the template is_convertible<From, To>, the > following code shall be well formed: > > template <class T> > typename add_rvalue_reference<T>::type create(); > To test() { > return create<From>(); > } > > [ Note: This requirement gives well defined results for reference > types, > void types, array types, and function types. -- end note ] I've got a much more refined unique_ptr testsuite on the way which will contain the unique_ptr header and test case for this (not there yet, I'll post when it is). -Howard

3 9

[partition_point][iterator][multi_index] partition_point now in sandbox
by Arno Schödl 07 Jan '09

07 Jan '09

I checked the first version of the "partition_point" library into the sandbox. Unit tests are still missing. Besides "partition_point", there are also "iterator" and "multi_index" directories that contain partition_point overloads that upon acceptance will go into the respective libraries (right, Dave?). shared_container_iterator has the problem that container_ref is not publicly accessible, so to make the code work, shared_container_iterator needs an accessor for that information a la transform_iterator::predicate() or declare partition_point as a friend. Dave, Joaquin, feel free to make changes to the overloads. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

3 2

[iterator] counting_iterator::reference should be value_type?
by Arno Schödl 07 Jan '09

07 Jan '09

Hello, currently, counting_iterator<T>::reference is Incrementable const&. This makes reverse_iterator< counting_iterator<T> >::dereference return a reference to a temporary variable: typename super_t::reference dereference() const { return *boost::prior(this->base()); } IMO, the solution is to make counting_iterator return by value. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

4 10

[Unit Test] formulas in documentation wrong
by David Walthall 07 Jan '09

07 Jan '09

Hello. It appears that some of the math formulas are wrong. E.g. http://www.boost.org/doc/libs/1_37_0/libs/test/doc/html/utf/testing-tools/f… has |u v| |u| |u v| |v| instead of | u - v | <= e * |u| or | u - v | <= e * |v| The documentation seems to have gone wrong between 1.35 and 1.36: http://www.boost.org/doc/libs/1_35_0/libs/test/doc/components/test_tools/fl… http://www.boost.org/doc/libs/1_36_0/libs/test/doc/html/utf/testing-tools/f… Thanks, David

2 1

[test] Broken with VC7.1?
by John Maddock 07 Jan '09

07 Jan '09

All the math lib tests are now failing with VC7.1 due to an unresolved external from Boost.Test: http://tinyurl.com/9s9s8e Any fixes? Cheers, John.

2 2

Re: [boost] [variant]compile-time-checked boost::get<T>?
by Arno Schödl 06 Jan '09

06 Jan '09

Hello, would anyone object to changing the semantics of boost::get to do the compile time check, rather than introducing a boost::checked_get? I think changing the semantics is o.k., at least if the first version does not allow casts. If existing code does not compile, it can be fixed by a) replacing the boost::get with a NULL constant or a throw statement, b) or, if the code is generic (and I doubt there is such code), with a compile-time check, and for the case of a type not contained in the variant, using a). I think changing the semantics may reveal more unknown bugs than unnecessarily break code. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

2 1

Re: [boost] Futures - Reviews Needed (January 5, 2009)
by Tom Brinkman 06 Jan '09

06 Jan '09

>> Are we reviewing both libraries at once? That is my understanding. However, at this point, until persuaded otherwise, I'm inclined to suggest to both authors that they should find a way to work together and issue a joint release. I've looked at both libraries and the differences are subtle. Maybe we just need to persuade them that it would not diminish their work in any way if they were to submit a joint release. As both submissions are of high quality, I would not want to discourage either author. It would also seem to me that the logging library proposals have the same problem. It would be my hope that we could get the authors of the various logging library proposals to work together and issue a joint release as well. One could dream.

3 3

XML Digester
by Themis Vassiliadis 06 Jan '09

06 Jan '09

Hi All, I'm finishing a preliminary version of a class with similar behavior like Java Digester. In this class the developer defines triggers witch will be fired when specific tags are found from XML file. Let me explain better with an example: A simple approach will be to use the following Digester in the following way to set up the parsing rules, and then process an input file containing this document: digester = new boost::xml_digester::xml_digester((std::istream*)&st); digester->setValidating( false ); digester->addObjectCreate<classFoo>("foo"); digester->addObjectCreate<classBar>("foo/bar"); digester->addCallMethod<classBar>("foo/bar/prop1", &classBar::setProp1); digester->addSetProperty<classBar>("foo/bar/prop2", &classBar::prop2); digester->addSetNext<classFoo>("foo/bar", &classFoo::addBar); digester->parse(); .... class classBar { std::string prop1; public: std::string prop2; void setProp1(std::string value) { prop1 = value; } }; class classFoo { std::vector<classBar*>obj_bars; public: void addBar(void *instance) { obj_bars.push_back((classBar*)instance); } }; XML: <?xml version='1.0' encoding='UTF-8'?> <foo> <bar> <prop1>xxxxxx</prop1> <prop2>yyyyyy</prop2> </bar> <bar> <prop1>zzzzzz</prop1> <prop2>kkkkkk</prop2> </bar> </foo> In order, these rules do the following tasks: 1. When a nested <foo> element is encountered, create a new instance of "classFoo" and push it on to the object stack. At the end of the <foo> element, this object will be popped off of the stack. 2. When a nested <bar> element is encountered, create a new instance of "classBar" and push it on to the object stack. At the end of the <bar> element, this object will be popped off of the stack (i.e. after the remaining rules matching foo/bar are processed). 3. Cause method setProp1 of class "classBar" to be called each time "prop1" is loaded. A std::string type parameter is passed as the value. 4. Cause property "prop2" of class "classBar" to be set each time "prop2" is loaded. The property must have public scope and its type must be std::string. 5. Cause the "addBar" method of class "classFoo" to be called, passing the instance of "classBar" created in the step 2. This rule allow to establish a parent/child relationship between "classFoo" and "classBar". I think that with these features the developer might do everything that he need to parse XML files to objects in 90% of cases. Of course the Java Digester is more powerful and complex and for next releases we can improve it. Regards, -- Themis Vassiliadis

3 3