- Boost - lists.boost.org

Repost (putting together boost::any, mpl::vector, and filter_iterator)
by Stephen Gross 15 Sep '05

15 Sep '05

I've put together a class called 'AnyVector' for doing type-based iteration on a vector. The basic idea is that AnyVector wraps a std::vector<boost::any>. The AnyVector lets you iterate across a subset of the underlying vector by using filter_iterators. The filter iterators, in turn, dereference to the requested type for ease of use. For instance, you can do the following: === CODE === AnyVector<> a; a.push_back(1); a.push_back(std::string("hello")); a.push_back(2); a.push_back(std::string("goodbye")); for(AnyVector<>::Iterator<int> i = a.begin<int>(); i != a.end<int>(); ++i) std::cout << (*i + 5); for(AnyVector<>::Iterator<std::string> i = a.begin<std::string>(); i != a.end<std::string>(); ++i) std::cout << i->length(); ============ Furthermore, you can restrict (at compile-time) which objects are allowed to be inserted into the AnyVector. This is done by listing those types when you create your AnyVector: === CODE ==== AnyVector<int, std::string> a; // Only allows int's and string's a.push_back(3.5); // Fails at compile time - double's not allowed! ============= Would this be a useful addition to boost, or does it already exist somewhere in boost and I just missed it? --Steve Stephen Gross Case Western School of Medicine Cleveland, OH "By Grabthar's hammer, by the sons of Worvan, you shall be avenged." - Dr. Lazarus -- Stephen Gross Case Western School of Medicine Cleveland, OH "By Grabthar's hammer, by the sons of Worvan, you shall be avenged." - Dr. Lazarus

2 2

Interest in an arbitrary precision library?
by Joel Eidsath 15 Sep '05

15 Sep '05

I've used several different arbitrary precision libraries with C++ and I have always been somewhat disappointed. And now I'm finally disappointed enough to start on my own. Here are the attributes that I think a C++ arbitrary precision library needs: 0) As much as possible, the library types should be drop-in replacements for the built-in types. a) This probably means some sort of numeic_limits support. I am unclear on the best implementation of this. b) Any automatic type conversions should behave in an obvious manner. c) Ease of use may take priority over efficiency. 1) The library should be both useful for number theory and a way of improving code robustness by minimizing overflow errors. 2) It should also provide equivalents of the basic C++ math functions. Implementing TR1 functions should be a priority. 3) As well as arbitrary precision, it should provide error range math: 2.00 * 2.00 is not generally the same thing as 2.0 * 2.0 4) It should use fast algorithms for multiplication and division, but instead of trying to compete with other libraries in computation speed (GMP uses hand-coded assembly in places), it should concentrate on code portability and ease of extension. 5) I do not envision any fancy memory management. The "big int" class will probably use a std::vector<int> to store it's implementation data. 6) Providing math functions beyond those already in C++ will not be a priority. a) GCD will be at least one exception to this. 7) It should work well with other Boost libraries where possible. 8) Divide by zero errors for integers should be handled with an exception. 9) Precision for rational numbers may be set as a static member variable or it may not. In the second case, expressions involving rational numbers of different. 10) Drop-in algorithm replacement for various operations might be a nice feature. Comments, suggestions, desired features? Some of the parts of this list are off the top of my head, so feel free to suggest changes. Joel Eidsath

12 58

[metamath] File inclusion and use of static
by Matt Calabrese 15 Sep '05

15 Sep '05

I recently started toying with metamath for use in a current project of mine with some really great results, though I ran into some unintuitive organization in regards to inclusion that should probably be fixed. The main "problem" comes from the fact that double.hpp does not include the arithmetic specializations for double_. The reason why I consider this a problem is that it makes working with generic mathematical metafunctions difficult, as it requires the user of the function to know the inner workings of the metafunction in order to know which associated arithmetic operation files for double to include. For instance: template< typename A, typename B, typename C > struct math_function : ::boost::mpl::plus< ::boost::mpl::times< A, B >, C > { }; Now, this metafunction may be meant to be used with any kind of compile-time values (not just double_). All the file really should be required to include is <boost/mpl/times.hpp> and <boost/mpl/plus.hpp>, or at least declarations of the associated templates. Because of this, with the current layout of metamath, the person using math_function from another file now has the responsibility to include <boost/metamath/double/times.hpp> and <boost/metamath/double/plus.hpp>, otherwise the metafunctions obviously will not work correctly (well, assuming that they are actually instantiated, of course). However, this is not a good solution since it means that the user of math_function must know its implementation details in order to know to include the appropriate metamath double operations. The other alternative would be to include the double operations from the math_function file itself, which also is not a good solution, since it implies that it knows about double, which, considering it is a generic function meant to work with any number of types which comply to the currently unspoken compile-time value abstraction (unspoken for non-integral types, correct me if I'm wrong?), is not feasible. The only truely intuitive, fully functional solution I see is to have double's file include everything it needs to make it conformant to the compile-time value pure abstraction (i.e. all of the proper arithmetic operations). Short of this, there should at least be another file that you can include which includes all of the appropriate operations to make it comply to the proper pure abstraction which programmers would usually include. Also, the files for arithmetic operations currently use ::boost::mpl::apply2, yet never include <boost/mpl/apply.hpp>. Slightly less damaging is that the double_macros file does not include double.hpp, which is more just a little bit annoying, since it requires one to include both files explicitly in order to actually use the macro in any practical situation. Finally, the constants pi, e, etc. are currently defined as being static objects at namespace scope, which, as per Annex D.2 of the C++ standard, is deprecated usage of the static keyword (one should prefer unnamed namespaces instead). "ten" is also left out of these definitions, despite its existance as a typedef in the meta sub-namespace. -- -Matt Calabrese

2 1

[assign] a bug in map_list_of?
by Alexey Bakhvalov 15 Sep '05

15 Sep '05

The following example doesn't compile under VC7.1 and VC8.0b2: [code] #include <boost/assign/list_of.hpp> #include <boost/assert.hpp> #include <map> using namespace std; template<class T> void func1() { } template<class T> void func2() { } void func() { } int _tmain(int argc, _TCHAR* argv[]) { typedef void (*TFunc)(); map<const wchar_t *, TFunc> next = boost::assign::map_list_of<const wchar_t *, TFunc> (L"test1", &func1<char>) (L"test2", &func2<char>) ; } [/code] But if I replace (L"test2", &func2<char>) with (L"test2", &func) or (std::make_pair(L"test2", &func2<char>)) then everything works fine.

2 2

asio file I/O
by Felipe Magno de Almeida 15 Sep '05

15 Sep '05

Hi boosters, I've implemented asynchronous file IO for linux in asio using aio_* functions. I created a class called basic_stream_file (and a typedef called stream_file) with almost the same interface as basic_stream_socket. But with read/write and async_read/async_write functions and an aio_demuxer_service. I writed it for the 0.3.2 version. For now to be able to use this new demuxer, is needed to create a demuxer of type: asio::basic_demuxer<asio::detail::aio_demuxer_service>. The implementation is attached. I didnt had time to test it very much, but it seems to be working okay. There are some problems that are related to aio_* in linux, since it isnt completely implemented in today's kernels and isnt implemented at all in 2.4.* kernels(there are patches however). And the aio_* functions only work really asynchronous for now if used with O_DIRECT and aligned buffers. But at least it could have a single interface for AIO with files in Windows and Linux. I'm planning to write asynchronous file I/O for windows with io completions ports too. IMO it would be interesting to be able to have a single demuxer in windows for file and socket AIO. I'm sending attached a file that uses these classes as an example. It must be linked with -laio and -lpthread and libaio must be installed. (It wasnt in my slackware 10.1, dont know about the default setup of other distributions). Any feedback will be appreciated. Thanks, Felipe. -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."

3 4

[preprocessor] help generating create functions
by Jason Hise 14 Sep '05

14 Sep '05

Background: I am using a few functions which have the following form: void create ( ); template < typename P1 > void create ( P1 p1 ); template < typename P1, typename P2 > void create ( P1 p1, P2 p2 ); [...] I am trying to generate these using the boost preprocessor library, but I am getting an error. This is probably because I do not fully understand how the order of expansion of function-like macros works. The error is: warning C4002: too many actual parameters for macro 'BOOST_PP_IIF_1' My code is as follows: #define BOOST_PP_LOCAL_LIMITS (0, BOOST_SINGLETON_PTR_MAX_CONSTRUCTOR_PARAMS) #define BOOST_PP_LOCAL_MACRO(n) \ BOOST_PP_IF(n, template < BOOST_PP_ENUM_PARAMS(n, typename P) >, \ BOOST_PP_EMPTY()) void create ( BOOST_PP_ENUM_BINARY_PARAMS(n, \ typename ::boost::call_traits < P, >::param_type p ) ) \ { \ policy_ptr->get_creator ( )->create \ ( BOOST_PP_ENUM_PARAMS(n, p) ); \ } #include BOOST_PP_LOCAL_ITERATE() What am I doing wrong? -Jason

3 3

typeof compilers support expectation
by Arkadiy Vertleyb 14 Sep '05

14 Sep '05

Hi All, How important it is for the Typeof library to support the following compilers: gcc 2.95 sunpro borland dmc? It looks like these four would represent most significant problems in porting. Regards, Arkadiy

1 0

Re: [boost] Checked Integral Class
by Matt Doyle 14 Sep '05

14 Sep '05

I have pretty much the same template in my lib with the main exceptions being that, where possible, I statically assert as well, and I (sort of) allow for non-integral types (run time only). TBoundValue<typename RT, typename DT, RT min, RT max> I would love to figure out how to trick the compiler into evaluating a floating point, non-type argument but so far I haven't found it (a few ideas though :) Anyway, if there's interest in it I'd be willing to work together with you on it and merge our approaches together. Matt > I've written a template class to hold a range of valid > integral values. My > intent was to mimic Ada's ability to define a type like this: > > type SmallInt is range -10 .. 10; > > One can then declare objects of this type and any subsequent > assignment that > violated this range constraint woud throw an exception. > > I have built a C++ template class that does the same thing: > > template<typename T, T min, T max> > struct CheckedIntegralValue > > To define a type that can hold the same range as the example above: > > typedef CheckedIntegralValue<int, -10, 10> SmallIntType; > > SmallIntType i = -10;//OK > SmallIntType i2 = -100;//Will throw an exception at run-time > for value > out-of-range > > I won't include the whole thing here, but I can do so if > there is enough > interest. I have defined most of the operators one needs to > use this type > just as one would use a 'normal' integer. > > Would anyone be interested in something like this in the > Boost libraries? > > Regards, > > Dan McLeran > > Scanned by Fortigate {X3BTB534}

3 3

Re: [boost] Checked Integral Class
by Matt Doyle 14 Sep '05

14 Sep '05

> > I also do some static assertions and I was thinking of adding static > functionality to add, multiply, divide, etc. at compile time. > One could do > this if one knew the lhs & rhs values at compile-time. > > What's the "typename DT" template parameter for? > RT = range type, and DT = data type. That's what I meant by "sort of" for the floats. When I was able to do my math with ints it worked great but when I had to switch to doubles that's the closest I got. Bounding the floating point value against integral limits. >Let me clean up what I've got and I'll send it to you via email with a small >test program and we can kick it around a while. O.K. I'll clean mine up too. I also want to look at what Cromwell & Peder are working on. I really like the idea of performing as much of the math as possible at compile time. There-in lies part of the tricky bit though, if it can't be resolved at compile time it needs to revert to a run-time operation. Matt Scanned by Fortigate {X3BTB534}

1 0

[metamath] Error and question about function calls
by Chris Weed 14 Sep '05

14 Sep '05

Hi, I was trying to test the trigonometric functions and add an exp function in the metamath library. I am not sure how to call them. Also line 58 of string_to_double.hpp needs to be changed to the following to compile in gcc: typedef typename pow_impl<unsigned_exponent>::template apply<T>::type positive_pow; Thanks, Chris

2 3