- Boost - lists.boost.org

Re: [boost] multi_array 64-bit patch
by Thomas Klimpel 19 Jul '05

19 Jul '05

Ronald Garcia wrote: > I made the changes you show below thanks > with the exception of the switch to ptrdiff_t for the index type. > It's not obvious to me that that is the correct change to make I have to admit that the name "std::ptrdiff_t" sounds strange in the context of "index", but there are some container classes in boost that use std::ptrdiff_t as the argument type for operator[], "boost::scoped_array" and "boost::shared_array" for example. And I think "std::ptrdiff_t" makes perfect sense as the index type for an operator[] that accepts both negative and positive integers. There might be types with more comforting names like typedef boost::intmax_t index; // from "boost/cstdint.hpp" typedef boost::detail::integer_traits<std::size_t>::difference_type index; // from "boost/detail/numeric_traits.hpp" typedef intmax_t index; typedef intptr_t index; but "intmax_t" and "intptr_t" seem to be more part of the "c standard" than of the "c++ standard", and the boost types don't help me with the annoying warnings on 32-bit windows with Visual C++.NET. On 32-bit windows, size_t is defined as "typedef _W64 unsigned int size_t;" where the _W64 just means that I will get warning messages, if I convert this type to a type without _W64. Now ptrdiff_t works for me, because it is defined as "typedef _W64 int ptrdiff_t;". Besides the warnings issue, "boost::detail::multi_array::index" should be a signed integer type, that satisfies the assertion "assert(sizeof(boost::detail::multi_array::index) == sizeof(std::size_t));". While this assertion will probably be satisfied on all current platforms, it is not garantied by the standard, which just reads: "The types are 'ptrdiff_t' which is the signed integer type of the result of substracting two pointers; 'size_t' which is the unsigned integer type of the result of the sizeof operator;". Thanks, Thomas

1 0

extra semicolons
by Arkadiy Vertleyb 19 Jul '05

19 Jul '05

Hi all, Not having extra semicolons is one of the strongest arguments against incuding a trailing semicolon into a statement-generating macro. Can anybody explain why having an extra semicolon is considered a potential problem by some compilers? Isn't null as good as any other number? Shouldn't an empty statement be considered as good as any other statement? Regards, Arkadiy

6 15

Generic Factory Library
by Dean Michael Berris 19 Jul '05

19 Jul '05

Good Day, For the past few years, I have been exposed to both C++ software development as well as Java software development. I have been lucky enough to get to use many different frameworks from both languages (ACE in C++ and countless othes in Java). Introductions aside, I would like to ask whether a generic object factory implementation would be best put in a framework or a library. What I am looking for is something to the effect of the Spring [1] framework but in C++. With the issues like late/dynamic binding having many different implementations in many different platforms, the best I could conceptualize is a static template for different object types. What I'm looking for is something that will be able to allow me to forget about reimplementing the static factory every time I need it, and use a generic template instead. Something that will allow me the following functionalities: <code> // return a reference to a _huge_ statically allocated object, // too impractical to always instantiate whenever an instance of it // is needed: static_factory<Object> ObjectFactory; ... Object & object1 = ObjectFactory.getObject(); ... // later perhaps Object & object2 = ObjectFactory.getObject(); ... // later still Object & object3 = ObjectFactory.getObject(); </code> For other cases when I want a different instance returned every time I need a reference to something new, there's a dynamic_factory -- returning a pointer or reference to an object: <code> dynamic_factory<Object> ObjectFactory; Object instance1 = ObjectFactory.getObject(); std::auto_ptr<Object> instance2 (ObjectFactory.getObject()); </code> -- Of course, it is assumed that `Object' has a default constructor in both dynamic_factory and static_factory. Do you know of anything similar to these already? Otherwise, I would be most glad to put up a sample implementation soon. TIA PS. Perhaps XML definition files may be used to provide object registration when the factory is used dynamically to load object definitions from dynamic libraries. -- Dean Michael C. Berris <mikhailberis(a)free.net.ph> GPG Key: 0x08AE6EAC http://mikhailberis.blogspot.com Mobile: +63 921 7841815

3 4

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 19 Jul '05

19 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando Cacciola > Sent: Saturday, July 16, 2005 12:48 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] New Library Proposal: dual_state <clip -- discussion on why ?: is clearer than "adaptor"> > You said that > > "the door has been flung open to many templated constructs > that are more difficlt with the ?: operator. For example, a > boost::transform_iterator could be created with the adaptor > to automatically access the underlying objects in a sequence." > > I disagree.. can you post a concrete example with a construct > that is indeed more difficult with operator ?: (... and be > fair; i.e. code the operator version the right way...) > > > IMO you still need to show that the adpator is indeed a good > thing; if you do that we can start discussing a proper design > and implementation for it. > Okay, I'll try. How about finding the max_element (or min_element) of a series of optional integers? Using the ?: operator, we might do this in two steps, the first to filter out non-existent values, the second to apply the max_element algorithm. Another way would be to write a custom predicate function that knows how to compare "full" and "empty" Boost::Optional objects or that duplicates the functionality of adaptor. However, by using an adaptor in conjunction with boost::transform_iterator, the job can be accomplished in one loop without the difficulty of writing a custom predicate. Here is some example code (BTW, others seem to prefer the spelling "adaptor," which is more consistent with other standardized names like "iterator," so I'll conform to that): // -- begin typedef boost::optional<int> opt_int; typedef std::vector<opt_int> Vec; typedef Vec::const_iterator cIter; Vec v; int max; v.push_back(0); v.push_back(1); v.push_back(2); v.push_back(boost::none); v.push_back(3); v.push_back(4); v.push_back(boost::none); v.push_back(5); // METHOD #1a: copy to a new vector std::vector<int> tmp; for( cIter p = v.begin(); p != v.end(); ++p ) { if( *p ) tmp.push_back( p->get() ); } max = *std::max_element( tmp.begin(), tmp.end() ); // METHOD #1b: copy using ?: to provide a signal value for undefined elements (similar to adaptor) tmp.clear(); for( cIter p = v.begin(); p != v.end(); ++p ) { tmp.push_back( *p ? p->get() : -1 ); } max = *std::max_element( tmp.begin(), tmp.end() ); // METHOD #2a: define a custom predicate template< class T, class Pred, T Def = T() > class optPred : public std::binary_function<boost::optional<T>, boost::optional<T>, bool> { Pred f; T _eval( const boost::optional<T>& x ) const { return ( x ? x.get() : Def ); } public: optPred() : f( Pred() ) {} bool operator()( const first_argument_type& a, const second_argument_type& b ) const { return f( _eval(a), _eval(b) ); } }; opt_int opt_max; opt_max= *std::max_element( v.begin(), v.end(), optPred< int, std::less<int>, -1 >() ); // METHOD #2b: use an adaptor-like predicate template< class T > class adaptor_substitute : public std::unary_function< boost::optional<T>, T > { T Def; public: _adaptor_() : Def( T() ) {} _adaptor_(T def) : Def( def ) {} T operator()(const argument_type& x ) { return ( x ? x.get() : Def ); } }; max = *std::max_element( boost::make_transform_iterator( v.begin, adaptor_substitute<int>(-1) ), boost::make_transform_iterator( v.end, adaptor_substitute<int>(-1) ) ); // METHOD #3: use an adaptor max = *std::max_element( boost::make_transform_iterator( v.begin, boost::optional<int>::adaptor(-1) ), // NOTE: boost::optional<int>::adaptor does not currently exist boost::make_transform_iterator( v.end, boost::optional<int>::adaptor(-1) ) ); // -- end It seems to me the adaptor, at the very least, saves us the trouble of defining a custom predicate. The similar exercise for min_element can be done by choosing a different signal value, such as 0x7FFFFFFF (the point at "infinity"). I hope this clears up my comment about using adaptor with boost::transform_iterator, but let me know if I haven't convinced you. -Andy

2 1

[iostreams][tru64] can't pass static mem fn to API expecting extern "C"
by Jonathan Turkanis 19 Jul '05

19 Jul '05

Hi, Compaq C++ for Tru64 seems to have found a problem with the iostreams library that none of the other compilers caught. zlib and libbz2 allow the programmer to customize memory management by specifying a pair of function pointers for allocation and deallocation. I wanted to provide an adaption layer so that users could specify standard library compatible allocators instead. To do this, I defined a class template parameterized by an allocator and having two static member functions with the same signature as the allocation and deallocation functions, and then passed pointers to these static member functions to the zlib and libbz2 API. Unfortunately, when compiled as C++, the zlib and libbz2 headers declare the allocation and deallocation function pointer types as extern "C", and Compaq (correctly, I think) refuses to let me assign pointers to static member functions to variables whose type are declared extern "C". Is there some way to get around this? If not, what should I do? 1. expose the C-language customization interface (yuck) 2. remove the customization interface 3. remove the customization interface only for platforms where it doesn't work 4. Use some more elaborate trick, such as supplying extern "C" allocation functions which operate by delegating to pointers stored in a table. I like 2. Jonathan

4 4

[mpl] integral_c bool partial specialization
by Matt Calabrese 19 Jul '05

19 Jul '05

The bool partial specialization of ::boost::mpl::integral_c currently does not appear to contain a value_type type member meaning it does not fully conform to the Integral Constant pure abstraction specified in documentation.

2 1

[tokenizer] Type requirements
by Nikolay Mladenov 18 Jul '05

18 Jul '05

Hi All, What are the requirements on the Type template parameter of boost::tokenizer. I could not find this in the documentation. I want to pass type similar to std::pair < std::string::const_iterator, std::string::const_iterator > . But it seems that the type should have operator += and/(or?) assign member. Is that correct? Is there any other customization mechanism here? Thanks Nikolay

1 0

multi_array 64-bit patch
by Thomas Klimpel 18 Jul '05

18 Jul '05

Hello, The Boost Multi_Array library produces some 64-bit related warnings when used with Visual C++.NET. It seems to me that these warnings are valid and correspond to real 64-bit problems. To get rid of these annoying warnings, I have fixed two minor inconsistencies in multi_array/iterator.hpp and multi_array/multi_array_ref.hpp, but that was not enough. I also had to change the definition of boost::detail::multi_array::index in multi_array/types.hpp from "typedef int index;" to "typedef std::ptrdiff_t index;". There might be better solutions, but it was the best I could think of, because std::ptrdiff_t is a signed type and will adapt to a 64-bit environment. Index: multi_array/iterator.hpp =================================================================== --- multi_array/iterator.hpp (Revision 1040) +++ multi_array/iterator.hpp (Arbeitskopie) @@ -98,7 +98,7 @@ array_iterator() {} - array_iterator(int idx, TPtr base, const size_type* extents, + array_iterator(index idx, TPtr base, const size_type* extents, const index* strides, const index* index_base) : idx_(idx), base_(base), extents_(extents), Index: multi_array/types.hpp =================================================================== --- multi_array/types.hpp (Revision 1040) +++ multi_array/types.hpp (Arbeitskopie) @@ -26,7 +26,7 @@ // needed typedefs typedef std::size_t size_type; -typedef int index; +typedef std::ptrdiff_t index; } // namespace multi_array } // namespace detail Index: multi_array/multi_array_ref.hpp =================================================================== --- multi_array/multi_array_ref.hpp (Revision 1040) +++ multi_array/multi_array_ref.hpp (Arbeitskopie) @@ -389,7 +389,7 @@ // Calculate the array size num_elements_ = std::accumulate(extent_list_.begin(),extent_list_.end(), - 1,std::multiplies<index>()); + size_type(1),std::multiplies<size_type>()); #if 0 assert(num_elements_ != 0); #endif

2 1

[Preprocessor] Workaround for CW8.3
by David Abrahams 18 Jul '05

18 Jul '05

BOOST_PP_SEQ_ENUM is failing for me when invoked from another macro; When the argument is (A0) I get BOOST_PP_SEQ_ENUM_2 and when the argument is (A0)(A1) I get BOOST_PP_SEQ_ENUM_4 I think what happens is that CW "sees through" the outer set of parens in # define BOOST_PP_SEQ_ENUM(seq) BOOST_PP_CAT(BOOST_PP_SEQ_ENUM_, BOOST_PP_SEQ_SIZE(seq)) seq and pastes seq to itself, yielding a length of 4 instead of 2. Here's a workaround: # define BOOST_PP_SEQ_ENUM_I(size,seq) BOOST_PP_CAT(BOOST_PP_SEQ_ENUM_, size) seq # define BOOST_PP_SEQ_ENUM(seq) BOOST_PARAMETER_SEQ_ENUM_I(BOOST_PP_SEQ_SIZE(seq), seq) I hope this is useful. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[1.33.0] Inspection report
by Douglas Gregor 18 Jul '05

18 Jul '05

The inspection report shows that we have a bunch of little fixes to make before we release. Please check it out and fix whatever you can: http://www.boost.org/regression-logs/inspection_report.html Doug

8 14