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

iterating over a tuple
by Toon Knapen 26 Apr '02

26 Apr '02

I have a list of heterogeneous objects, e.g. struct Foo { Foo(int v) : value_( v ) {} int value() const { return value_ ; } int value_; }; struct Bar { Bar(int v) : value_( v ) {} int value() const { return value_ ; } int value_; }; int main() { Foo foo(3); Bar bar(7); typedef boost::tuple< Foo, Bar > MyTuple ; MyTuple my_tuple( foo, bar ); return 0; } And now I want to have a function that can accumulate the value sof all the objects in the tuple, e.g. (pseudocode since my problem is exacly that I can't figure out how to code this) template < typename TypleType > int accumulate_values(const TupleType& t) { int acc = 0; for(int i = 0 ; i < t.size() ; ++i ) acc += (get< i >( t )).value(); } Can I do this using mpl (mpl looks great but I can't figure out how to do this). thanks, toon

1 0

RE: [Boost-Users] iterating over a tuple
by Aleksey Gurtovoy 26 Apr '02

26 Apr '02

Toon Knapen wrote: > > Hope it's not too complicated :). LL might allow to do > > better on this one. > > Thanks, I'll try it out. Coudl you enlighten me on how to > solve it with the lambda library. I don't see how to iterate over > the different indexes in combination with LL ? Oh, sorry, my last sentence was probably misleading. What I meant is that LL can do a better job on construction of the function object that is passed to tuple's 'accumulate': struct get_value { template< typename T > int operator()(T const& x) const { return x.value(); } }; int sum = accumulate(tuple, 0, _1 + ll::bind(get_value(),_2)); I was also hoping that it could help us to get rid of the ad hoc 'get_value' class, but, thinking about it more, I don't see how :(. HTH, Aleksey

1 0

Redistributing Boost?
by Duane Murphy 26 Apr '02

26 Apr '02

Boost has a reasonably liberal license for use in product both commercial and non-commercial. However I am wondering about redistributing source code. Does the boost license(s?) allow the sources to be redistributed as part of a commercial product? For example, a commericial library or framework that is developed using boost for underlying support and that library is sold in source code form. What are the legalities of distributing boost in this fashion? ...Duane -- "If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy." - James Madison

2 1

boost::thread_specific_ptr problem
by svanechel 26 Apr '02

26 Apr '02

Hi there, I've encountered a curious problem when using thread_specific_ptr. We are developing a Win32 Service and for each thread we need an object that stays alive for as long as the thread runs (except for the main thread). So we created a dll and in its DllMain function we did something like this: boost::thread_specific_ptr<SomeClass> someClass; BOOL WINAPI DllMain( HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved ) { switch ( fdwReason ) { case DLL_THREAD_ATTACH: someClass.reset( new SomeClass ); // Breakpoint 1 case DLL_THREAD_DETACH: someClass.reset(); // Breakpoint 2 } } And now comes the curious bit: If you build this dll and implicitly link it with the exe the exe's startup code hangs in GetModuleFileName (). This is the call stack upto that point _setargv (STDARGV.C) __getmainargs (CRTLIB.C) WinMainCRTStartup (CRTEXE.C) At that point the code hasn't reached Breakpoint 1 yet (it's still in the exe's startup code in the main thread and we are not interested in the main thread) It is not the class we are allocating. We tried it with an empty class and that produced the same result. However, if we stored an object in a TLS slot allocated with the API, everything works. It probably has nothing to do with the exe being a service either, since the same dll with linked to a normal exe had the same problems. To complicate matters even further we reached Breakpoint 1 in a number of runs, but as soon as we left DllMain in those instances the application hanged again. If you break then you see from the call stack that the code is running somewhere in NTDll. Are we using thread_specific_ptr in a way that it wasn't meant to be used, or did we encounter a real problem here? I've used thread_specific_ptr before and had no problems then. PS: We develop under Windows 2000 on a Compaq Evo W6000 dual processor machine, using MSVC 6, SP 5 and the 08/2001 version of the platform SDK. The service can run both under the Local System Account or under an account with absolutely no privileges at all. Sven Van Echelpoel

2 2

operator== in the shared_ptr class
by sashan 25 Apr '02

25 Apr '02

Hi Why does the operator == function in the shared_ptr class compare the pointer values and not what they are pointing to? I'm trying to use the find function (in the stl) and I don't know how to get around this. Here's an example. vector <shared_ptr <SomeClass> > vecStuff; shared_ptr<SomeClass> pkToFind(new SomeClass(x,y,z)); if (find(vecStuff.begin(), vecStuff.end(), pkToFind) != vecStuff.end()) { } This didn't work as expected because the shared_ptr class's operator== function does not use SomeClass's operator == function to do the comparison. Instead it compares the pointer values. I don't understand why they made it like this and I don't think they were dumb enough to overlook this so there must be something I'm missing. Thanks Sashan [Non-text portions of this message have been removed]

2 1

Building Boost 1.27.0 for VC7
by Javier Estrada 25 Apr '02

25 Apr '02

I'd like to build boost for VC7. I've followed several of the threads that detail some of the problems that people has faced and the solutions that have been found. Being the first time that I use boost: -How do I get access to a "free" CVS client that I can use on my machine and some information on how to use it? I'm familiar with SourceSafe on Windows platforms and I'm running Windows 2000 at home, Windows XP in my office. - Is it worth it to build 1.27, or should I wait for a "minor point" (1.27.1??) release or should I download the sources and go from there? It seems that there have been several changes made to 1.27.0 to accomodate VC7. Regards, Javier.

3 3

RE: [Boost-Users] crc
by Arjun Bijanki 25 Apr '02

25 Apr '02

GIE wrote: > I have problem compiling following empty project: [code removed] It looks like you must define BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS. If I define that, it compiles. Arjun Bijanki Microsoft Corporation

3 2

Boost.Threads lib files
by judoka1981 24 Apr '02

24 Apr '02

[Tried sending this through news://gmane.comp.lib.boost.user a few days ago, but it didn't seem to get through anywhere] Hi, I've started experimenting a bit with Boost.Thread, platform is currently WinXP / VC.NET. Just a question on the generated libraries and their names. Wouldn't it be more convenient to put all resulting .lib files in the same directory, and distinguishing between debug/release versions by name, e.g.: libboost_thread.lib // release libboost_thread_d.lib // debug libboost_threadmon.lib // release threadmon ... etc ... and, when the libraries support static linking of the CRT also: libboost_thread_static.lib libboost_thread_static_d.lib As it is now (Boost 1.27.0), it really is a bit awkward to use. Also, why not put all Boost library files in the same directory (e.g. BOOST_ROOT/lib) during build? Sorry if this topic already has been covered, I've been off the Boost lists for some time now. // Johan

2 1

RE: Common build problems (was: Building Boost 1.27.0 for VC7)
by Jim.Hyslop 24 Apr '02

24 Apr '02

I wrote: > I think if we break it down and everyone scans 30 messages > (the number of messages presented on the web interface) we > can go through the archive pretty quickly. I forgot to mention, I will coordinate this effort - if you want to scan some messages in the archive, email me and I'll let you know which messages to scan. -- Jim

1 0

RE: Common build problems (was: Building Boost 1.27.0 for VC7)
by Jim.Hyslop 24 Apr '02

24 Apr '02

Javier Estrada [mailto:ljestrada@hotmail.com] wrote: > I'd like to build boost for VC7. I've followed several of > the threads that > detail some of the problems that people has faced and the > solutions that have been found. It seems to me that we're seeing the same build problems crop up again and again. I have added a page to the Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?CommonBuildPr oblems where we can build up a list of frequently-encountered problems and how to solve them. So far it's just a skeleton, feel free to add to it, everyone :-) It would be nice if we could review the email archive to add the problems to the Wiki. Slogging through all 600+ messages is a bit of a long haul, but I think if we break it down and everyone scans 30 messages (the number of messages presented on the web interface) we can go through the archive pretty quickly. Reviewing the main Boost list, on the other hand... -- Jim

1 0