January 2005 - Boost-users - lists.preview.boost.org

RE: [Boost-users] Re: C++ Template Metaprogramming - Exercise 2-0
by Trask, Bruce (US SSA) 11 Jan '05

11 Jan '05

Philippe, > Given that, it is trivial to modify Eric's solution to have the > proper result. > Right. As they say in New England, Dawn in beginning to break over Marblehead. It took me four cracks to get it, but I think I got it now (see below and tell me if I do). (thanks for not telling me the answer outright) I starting to get the hang of it. Exercise 2.0 down. That's one in a row :) #include <iostream> #include <boost/type_traits/is_reference.hpp> #include <boost/type_traits/add_reference.hpp> #include <boost/type_traits/add_const.hpp> #include <boost/type_traits/is_same.hpp> #include <boost/static_assert.hpp> using namespace std; template<typename T> struct add_const_ref { typedef typename boost::add_reference<typename boost::add_const<T>::type>::type type; }; int main() { BOOST_STATIC_ASSERT((boost::is_same<boost::add_const<int>::type, const int>::value)); BOOST_STATIC_ASSERT((boost::is_same<boost::add_reference<int>::type, int&>::value)); BOOST_STATIC_ASSERT((boost::is_same<boost::add_const<int&>::type, int&>::value)); BOOST_STATIC_ASSERT((boost::is_same<boost::add_reference<boost::add_cons t<int>::type>::type, int const&>::value)); BOOST_STATIC_ASSERT((boost::is_same<add_const_ref<int&>::type, int&>::value)); BOOST_STATIC_ASSERT((boost::is_same<add_const_ref<int>::type, int const&>::value)); return 0; } Thanks for the input, Bruce > Philippe > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: C++ Template Metaprogramming - Exercise 2-0
by Lemings, Eric B. (Contr) 11 Jan '05

11 Jan '05

Dave Abrahams wrote: > Actually there's a much more concise solution using the type traits > library. That is, after all, the focus of the chapter. I believe that would be: template <typename T> struct add_const_ref { typedef add_const<add_ref<T>::type>::type type; }; Correct me if I'm wrong. Eric.

1 0

Re: C++ Template Metaprogramming - Exercise 2-0
by Lemings, Eric B. (Contr) 11 Jan '05

11 Jan '05

Dave Abrahams wrote: > Actually there's a much more concise solution using the type traits > library. That is, after all, the focus of the chapter. I believe that would be: template <typename T> struct add_const_ref { typedef add_const<add_ref<T>::type>::type type; }; Correct me if I'm wrong. Eric.

3 2

Zero/Null Metafunction?
by Lemings, Eric B. (Contr) 10 Jan '05

10 Jan '05

Hi, I was wondering if there is a zero/null value metafunction in the Boost libraries? Something like the following: null<int>::value // 0 null<float>::value // 0.0 null<void*>::value // 0 or NULL null<int&>::value // undefined Thanks, Eric.

1 0

Re: [sigc] Re: [Boost-users] Signals & Slots
by Doug Gregor 10 Jan '05

10 Jan '05

On Jan 9, 2005, at 11:35 AM, Martin Schulze wrote: > Am 07.01.2005 14:19:20 schrieb(en) Douglas Gregor: >> If I'm right in assuming that the code will not compile (because the >> signatures do not match exactly), then the "No Clue" could be replaced >> by "Not Applicable", because >> Signals performs all of the implicit conversions. > > I'm afraid, you're wrong here. Implicit conversions do work. > retype(_return) is for explicit conversions. > However, using implicit conversions in libsigc++-2.0 without > retype(_return) can cause troubles (at least warnings) with some > compilers. Okay, good. Then I don't have to try to motivate the need for implicit conversions :) >> - About ptr_fun/mem_fun: you can use them in either library, if >> you'd >> like to be more explicit. >> - About bind: bind is now in the C++ Library TR (an addendum to the >> standard, which should be approved in the near future), so we're >> forced >> to build on it to create any signals & slots library for the standards >> committee. (We'll have a long, uphill battle if we try to introduce >> our >> own special binders and don't support bind). > > Is there a way to deduce the return type of the bind functor object > that is part of the TR? Yes. It's called "result_of" in the Library TR. > Will it be possible to "visit the targets" that are stored in the > bind functor object with a function like Boost::visit_each() or > sigc::visit_each()? This functionality was not included because it was not necessary for anything in the Library TR (and would otherwise be hard to motivate). We could propose this as part of a signals 'n' slots system, of course. >> - Regarding libsigc++'s specialization for T_accumulator=nil: We >> don't need to discuss this in a standards proposal, because it's >> entirely a quality-of-implementation issue. >> - Regarding Signals and Function: They don't play well together, >> but >> we're going to have to deal with this one way or another because >> Function is also part of the C++ Library TR. > > I always thought that Boost had quite some influence on standard > proposal? Who come that the TR is in a bad shape for a signal system, > then? I wouldn't say that it is in bad shape for a signal system. The problem with {boost:: or tr1::}function and a signals system is that they both do the same thing: erase the static type of a function object so that it can be called through an entity that does not encode that type. The problem is that we need to call visit_each before we erase that type: 'function' shouldn't do it all the time, because that could be costly, and the signal/slot can't do it because the type is gone. We can probably come up with a not-too-painful solution, if we're clever enough. Doug

2 2

Dumb multi_array question about assignment
by Grant Goodyear 10 Jan '05

10 Jan '05

I'm currently working on a numerical project that uses boost.python, and since we already had boost as a dependency we've begun using boost/multi_array_ref to simplify multi-dimensional array handling in our code. I was rather surprised when the following code fragment spit out pages of errors when I tried to compile it: float* data = (float*) malloc(nx*ny*sizeof(float)); [...] boost::multi_array_ref<float, 2> xy(data, boost::extents[nx][ny]); xy = 0.; // errors out here Looking through the docs I realized that operator= isn't even mentioned, so perhaps I shouldn't have been surprised. It is rather unfortunate, though, that such a statement isn't allowed. (Unless, of course, I'm doing something wrong, which is completely possible.) Is there any plan to add such functionality in the future, or would it make more sense for us to switch to a different library (blitz++ or something similar)? Thanks, Grant Goodyear -- Grant Goodyear web: http://www.grantgoodyear.org e-mail: grant(a)grantgoodyear.org

2 2

status of boost::signal multi-threading support
by Stephen torri 10 Jan '05

10 Jan '05

What is the state of the multi-threading support for boost::signals? Stephen

4 8

About indirect_iterator
by Jens Theisen 10 Jan '05

10 Jan '05

Hello, I want to use indirect_iterator and noticed that it subscript operator returns a proxy. I found the following explanation in iterator_facade.h: // A proxy return type for operator[], needed to deal with // iterators that may invalidate referents upon destruction. // Consider the temporary iterator in *(a + n) But I still don't understand why a proxy is necessary in some cases. Thank you in advance, Jens

2 1

Writing regular expression
by Asha V.G. 10 Jan '05

10 Jan '05

Hi I want to do a search for a regular expression for '$':Matches the end of the string. e.g.: 'script$' should select vbscript as well as javascript. How can I do this? Regards Asha

2 1

Determining Type and Extracting Data from private class member vector<boos::variant<> >
by Matthew Jankowski 10 Jan '05

10 Jan '05

Hi all, I'm new to Boost and have some questions about how to get data out of a vector<boost::variant<> > container. For this purpose I put together 'class Base' which holds a vector<boost::variant <Base*, DerivedBase*> > Pointers. I wrote a function template to insert pointers, but I have real difficulty extracting pointers. For example, if I insert 3 Base* pointers and 2 DerivedBase* pointers, I need to be able to extract the 3 Base * pointers and the 2 DerivedBase* pointers at a later point in time. To this end, class Base* has another member function 'template< typename C> int numPointer( C * InPointer)' which is intended to count the number of pointers found in the container. template< typename C> int numPointer(C* InPointer) has a few problems: 1) typeid(Pointers[i]) returns the 'variant' typeid when I really need to know the typeid of the ith pointer in 'Pointers'. 2) There must be a better, more elegant (and safe) way to make use of the boost library to accomplish just what I want. int main() { Base * TempBase = new Base(); DerivedBase * TempDeri = new DerivedBase(); TempBase->insert(TempBase); TempBase->insert(TempBase); TempBase->insert(TempDeri); std::cout << "Base:" << TempBase->numPointer(TempBase) << endl; //Expect "Base:2" get "Base:0" because of typeid(). std::cout << "Deri:" << TempBase->numPointer(TempDeri) << endl; //Expect "Deri:1" get "Deri:0" because of typeid(). } class Base { private: vector<boost::variant <Base*, DerivedBase*> > Pointers; public: Base(); virtual ~Base(); template <typename C> void insert( C * inC ) { Pointers.push_back(inC); } template <typename C> int numPointer( C* inC ) { int counter(0); for ( int i(0); i < int(Pointers.size()); i++ ) { cout << "type:" << typeid(inC).name() << endl; cout << "typeP:" << typeid(Pointers[i]).name() << endl; //Will give the id of the container not Pointer[i]. //if( boost::is_same<Pointers[i],typeid(inC).name()>::value ){ //Compilation error if ( typeid(inC).name() == typeid(Pointers[i]).name() ) { counter++; } } return counter; } }; //Base Any advice on how to improve this code and/or make better use of the boost library is fully appreciated. Thanks, Matt

2 1