- Boost-users - lists.boost.org

MPL to get rid of cumbersome switch
by John Christopher 19 Mar '06

19 Mar '06

Hi; The program belows compiles and works but I'd like to simplify it, maybe using MPL. I spent some fascinating time educating myself on MPL, reading C++ Template Metaprogramming, but I am still at sea... to say the least. Basically the Functor contains a switch statement that is not convenient especially as the number of T classes will increase dramatically. Many thanks for any help on that JCR #include <iostream> #include <vector> #include <boost/mpl/vector.hpp> struct Tbase { Tbase() { std::cout << "Tbase" << std::endl; } }; struct T0 : public Tbase { T0() { std::cout << "T0" << std::endl; } }; struct T1 : public Tbase { T1() { std::cout << "T1" << std::endl; } }; typedef boost::mpl::vector<T0, T1> s; std::vector<Tbase*> vec; struct Functor { void operator()(const int& i) { switch(i) { case 0: vec.push_back(new T0); break; case 1: vec.push_back(new T1); break; } // I'd like to simplify the above swtich statement by writing something like: vec.push_back(new boost::mpl::at<s,i>::type); // but it does not compile and MinGW returns: // error: i cannot appear in a constant expression // error: template argument 2 is invalid. } }; int main (int argc, char ** argv) { std::vector<int> runtimeVec; runtimeVec.push_back(0); runtimeVec.push_back(1); runtimeVec.push_back(0); std::for_each(runtimeVec.begin(), runtimeVec.end(), Functor()); std::cout << vec.size() << std::endl; return 0; }

5 9

Regex Bug in 1.33.1
by Olaf Bachmann 19 Mar '06

19 Mar '06

Hi, there seems to be a bug in version 1.33.1 of boost::regex: boost::regex_replace(std::string("foo"), boost::regex(".*"), "bar") returns "barbar" whereas 1.31.0 returns just "bar" (as I would expect). Any fix or hints out there? Thanks, Olaf

2 1

Help with intrusive_ptr
by Thomas Laguzzi 17 Mar '06

17 Mar '06

Hello, I use intrusive_ptr with a class that holds the refcount and I derive from that class all my other classes. class TObject { public : int refcount ; TObject () { refcount = 0;} } I have defined the intrusive_..._addref and _release to increase and decrease/delete that refcount and everything works good! Anywhay sometimes I need to assign a derived object to another derived object of the same type instrusive_ptr <Derived> A = new Derived; . . . the problem: *A = *Derived(constr parameters). The point is that the refcount is assigned too (and becames 0) How are instrusive_addref and _release supposed to be implemented ? Any quick and clean solution for that ? I cannot write assignment operator for every derived class because... there are a lot of members :) Really thanks! Thomas

2 1

Re: [Boost-users] [Variant]Pointers to using pointers
by Alan M. Carroll 17 Mar '06

17 Mar '06

1 0

Unknown toolset: gcc-stlport
by Phlip 17 Mar '06

17 Mar '06

Boosties: We have a cross-platform solution using GNU g++ and VC7. Both sides use STLport. The documentation says to bond Boost (1.33.1) with STLport with this incantation: ./configure --with-toolset=gcc-stlport It emits: ### Unknown toolset: gcc-stlport ### ### Known toolsets are: acc, borland, cc, como, darwin, gcc, gcc-nocygwin, intel -linux, intel-win32, kcc, kylix, metrowerks, mingw, mipspro, msvc, qcc, sunpro, tru64cxx, vacpp, vc7, vmsdecc with no -stlport anywhere. When we try to wing it with just toolset=gcc, we get error messages. Googling for these reveals others got them too when they did not use the STLport toolset. I have heard that STLport now has an option to bond to Boost. Is that why Boost dropped an option to bond to STLport? If so, why did the same version of Boost like --with-toolset=vc-7_1-stlport? -- Phlip http://www.greencheese.org/ZeekLand <-- NOT a blog!!

1 0

[Variant]Pointers to using pointers
by Conway Allen 17 Mar '06

17 Mar '06

The following, I suppose, produces a memory leak... is there any way to avoid this? Don't use variant with pointers... ? variant<T1*,T2*> vt; vt = new T1; vt = new T2; Thanks, Allen.

1 0

[unit-test] Can'f find boost::unit_test::register_exception_translator
by Gustavo Ribeiro Alves 17 Mar '06

17 Mar '06

I'm trying to register some user exceptions on the unit_test framework so I did the following: #include <boost/test/unit_test.hpp> using boost::unit_test::register_exception_translator; . . . void translate_InvalidInterval(const Interval::InvalidInterval& e) { } void translate_NotIntercept(const Interval::NotIntercept& e) { } interval_test_suite::interval_test_suite() : test_suite ("interval_test_suite") { boost::unit_test::register_exception_translator<Interval::InvalidInterval> (translate_InvalidInterval); boost::unit_test::register_exception_translator< Interval::NotIntercept> (translate_NotIntercept); . . . } I get the following compile error: error: 'boost::unit_test::register_exception_translator' has not been declared I tried to grep all .hpp files on /boost/test to find if some of them have this function. The only one (execution_monitor.hpp) I found has it as part of a class. I was expecting it as a template function in the framework. So, how what do I have to include to make this work?

2 1

signals disconnect based on equivalent slots
by James Burgess 17 Mar '06

17 Mar '06

This works on gcc3.3 and gcc4.0 (OSX) but doesn't compile on vc8.0 I'm wondering whether it should and I've just messed up somewhere installing boost 1.33 or vc8 (VS 2005). I noted that the regression test does not perform this form of disconnect, is that the manual telling me this isn't supported? I get a very similar error if I try a functor (using bind) rather than example below ~ "can't convert to 'const int'". There's some comments in signal_template.hpp that indicate vc 6.0 and 7.0 have problems with this, maybe that #ifdef needs to include vc8? cheers, - James. #include <iostream> #include <boost/signals.hpp> void rfun() { std::cerr << "Hello World\n"; } int _tmain(int argc, char* argv[]) { boost::signal<void()> sig; sig.connect(&rfun); sig.disconnect(&rfun); return 0; } 1>------ Build started: Project: testsignals, Configuration: Debug Win32 ------ 1>Compiling... 1>testsignals.cpp 1>i:\testsignals\testsignals.cpp(19) : error C2664: 'boost::signal0<R,Combiner,Group,GroupCompare,SlotFunction>::disconnect' : cannot convert parameter 1 from 'void (__cdecl *)(void)' to 'const int &' 1> with 1> [ 1> R=void, 1> Combiner=boost::last_value<void>, 1> Group=int, 1> GroupCompare=std::less<int>, 1> SlotFunction=boost::function<void (void)> 1> ] 1> Reason: cannot convert from 'void (__cdecl *)(void)' to 'const int' 1> There is no context in which this conversion is possible

2 1

[optional] mixed (optional<T>, T)-operator== missing by design?
by Marc Mutz 17 Mar '06

17 Mar '06

Hi, In 1.33.1, comparing an optional<T> to it's T fails, since although T implicitly converts to optional<T>, op== being templated, implicit conversions are not considered. Is this by design? If so, what's the rationale for this? I repeatedly find myself in the need to compare an optional<T> member to a passed in T, e.g. in a setT( const T & ), in order to check for a no-op operation and suppress notifications in this case, e.g.: class Foo { boost::optional<T> mT; boost::signal< void(const optional<T>&) > tChangedSignal; void setT( const T & t ) { if ( t == mT ) return; mT = t; tChangedSignal( mT ); // mark cached values dirty, etc, etc... } }; -- Marc Mutz -- marc(a)klaralvdalens-datakonsult.se, mutz(a)kde.org Klarälvdalens Datakonsult AB, Platform-independent software solutions

2 2

Re: [Boost-users] Are Boost.Multi_Index and Boost.Format Planned for64-bitPortability?
by Wu Yinghui, Freddie 17 Mar '06

17 Mar '06

> Hello Freddie, > > As for Boost.MultiIndex, I can confirm the lib does work in 64-bit > environments (for instance, Linux PPC64, Tru64) and must also work > for Win64, although I've never had actual reports about this latter > platform (if you've got access to Win64, you might want to try and > tell back.) With respect to /Wp64 warnings, they are of two > kinds: > > * C4312/C4311, conversions between differently sized types: this > is a case of /Wp64 being too dumb in its analysis of the type > boost::multi_index::detail::uintptr_type; this type is defined with > some metaprogramming machinery to be some integral type > with the same size as void*. So, it is unsigned int in Win32 and > unsigned long long in Win64. But /Wp64 sees it defined as > unsigned int, hence the warning. It is as if you had: > > #ifdef _WIN64 > typedef unsigned int integral_type; > #else > typedef unsigned long long integral_type; > #endif > void *p; > integral_type x=(integral_type)p; > > /Wp64 is not able to see that integral_type will be > defined as unsigned long long in Win64, and emits a C4311. Thanks for your helpful explanation. Since this types of warnings flood the compiler output, which very difficult for us to notice other more valuable warnings. Guess we'll need to figure out some way to "hide" the stupid compiler behaviour? > * Complains about some internal node classes not being > constructable or about their automatic default constructors > being impossible to generate. I don't see what this has to do > with 64-bit portability; in any case, the compiler is right about > the analysis, but not about the consequences: these classes > are in effect never default constructed, their lifetime being > managed through an allocator interface. This is just an > overzealous warning. Hmm... In this case, I guess I'd just try to add some default constructors for these classes without implementing them. That way, I can at least get away with this type of warnings. > So, Boost.MultiIndex must work in Win64, the best way to > check this out is to actually try. I do not have the 64-bit machine with me yet. But I'll report back later once I actually have the chance to try it out. > As for Boost.Format, I cannot say cause I'm not the maintainer, > but in any case it seems to work on other 64-bit environments > as per the regression tests, and potential 64-bit problems > should be easy to tackle. Thanks for your insights! > Joaqu?n M L?pez Mu?oz > Telef?nica, Investigaci?n y Desarrollo > Cheers, Freddie -- Wu Yinghui, Freddie Research & Development Software Engineer Volume Interactions Pte Ltd 1 Kim Seng Promenade, #12-01 Great World City East Tower Singapore 237994 Tel: +65 62226962 (Ext 216) Fax: +65 62226215 Email: yhwu(a)volumeinteractions.com URL: http://www.volumeinteractions.com Important: This message is intended for the recipient(s) addressed above. It contains privileged and confidential information. If you are not the intended recipient, please notify the sender immediately by replying to this message and then delete it from your system. You must not read, copy, use, or disseminate this communication in any form. Thank you.

2 1