- Boost - lists.boost.org

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

some ptr_container issues
by Ross Boylan 18 Jul '05

18 Jul '05

I'm using the cvs version (as of a couple of days ago) of the ptr_container library with a regular 1.32 boost. Should transfer operations between dissimilar containers (e.g., ptr_vector and ptr_list, assuming both have the same underlying type) work? They don't seem to. I can't quite tell from the docs (which define these abstractly, e.g., for ptr_sequence) whether this should work or not. Previous versions of the docs made it explicit that the operations were templated on the type of the second container. Second, the definition of transfer does not say where the elements are to be inserted (i.e., whether they go before the "before" iterator, or whether the "before" iterator will end up before the inserted elements). While it's not hard to guess right with some knowledge of how the standard works (and even how other ptr_container functions work), it would be nice to be explicit. Third, I didn't see any explicit discussion of circumstances that invalidate iterators. Again, it's pretty easy to guess this is the same as the corresponding standard classes, but it's probably worth saying so. Finally, the discussion of exception classes does not describe the circumstances under which the exceptions are thrown. Some functions do discuss their exceptions, but I'm not sure if they all do. I was surprised that at throws bad_ptr_container_operation; I would have expected bad_index (this behavior *is* documented--I'm just saying it seems odd). Thanks for your work on these utilities. -- Ross Boylan wk: (415) 502-4031 530 Parnassus Avenue (Library) rm 115-4 ross(a)biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 476-9856 University of California, San Francisco San Francisco, CA 94143-0840 hm: (415) 550-1062

2 3

Re: [boost] Macros at namespace scope: trailing semicolon?
by Dave Gomboc 18 Jul '05

18 Jul '05

You were asking another, but... > 1) Do you think that the LOG() macro should contain a trailing > semicolon? The macro itself should, yes, so the user need not type one. > 2) I'm pretty sure you'll say #1, but which of the following examples > do you prefer? > > int foo() > { > LOG("NO SEMICOLON HERE?") // 1 > stuff(); > > LOG("OR does this seem better?"); // 2 > more_stuff(); > } #1. If someone did #2, yielding an extra, empty statement, it's not a tragedy, however (unless my compiler warned about such empty statements -- in which case I would delete the extraneous semicolon.) There's undoubtedly some compiler that boost supports that will do this, so best not to have the extra one there in the first place, I think. > 3) Do you see harm if the macro does not contain the trailing > semicolon? If so, what harm is it? Specifically, how does usage > #2 above re-enforce bad understanding of macros? (Or am I > misconstruing the nature of your objection?) It's logically inconsistent for the macro to not to perform its entire job. If that job is to "expand into an expression", certainly, it shouldn't generate a semicolon. If that job is to "expand into a statement", then just as certainly, it should. But its job ought not to be to "expand into a statement except for the trailing semicolon": that would be absurd. > 4) What is the important degree of indirection that I would be missing > by talking about the usage of the LOG macro as a call to the log > function? I understand that I could call it "a macro that expands > to a call to the log function" but I don't think that anyone would > be more enlightened by that. Other than being more detailed about > what's really happening, it's not clear to me what important > mistake is being made that bothers you. If our coding convention > states that macros are uppercase, then we already know it's a > macro, so simply repeating that is unnecessary, IMHO. Referring to it as the log function is clearly wrong. The listener might doubt your understanding, even if you knew perfectly well that it was indeed a macro that expanded to a function call. I see no disadvantage in referring to it as the LOG macro. Dave

1 0