- Boost - lists.boost.org

[smart_cast] template functions declared static?
by Caleb Epstein 30 Nov '04

30 Nov '04

The header boost/smart_cast.hpp declares the template functions smart_cast and smart_cast_reference as static. The SunPRO compiler issues a warning for this: "/home/nbde52d/src/boost_1_32_0/boost/smart_cast.hpp", line 264: Warning (Anachronism): "static" is not allowed and is being ignored. "/home/nbde52d/src/boost_1_32_0/boost/smart_cast.hpp", line 292: Warning (Anachronism): "static" is not allowed and is being ignored. Does "static" make any sense here? -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

[css] Wiki-style front page
by Reece Dunn 30 Nov '04

30 Nov '04

Hi All, I have made a few modifications to my Wiki-inspired front page design. It is available here: http://uk.geocities.com/msclrhd/boost/boost2.html Differences include: * background colour fix; * heading alignment and padding fixes; * positioning fix for the main content. The page also contains the Google search along the top of the screen with www.boost.org (now Boost) and lists.boost.org (now Mailing Lists) as a drop-down list instead of radio buttons. In addition to this, it uses several different styles: Simple -- Basic styling, minimal colour, simple menu. Wiki v1 -- "Traditional" Wiki style Wiki v2 -- Alternate menu/link hover scheme Wiki v3 -- Alternate menu/link hover scheme Wiki v4 -- Alternate menu/link hover scheme At the moment it doesn't render correctly in IE because I have different named styles and IE is broken in this respect. Firefox works and allows you to switch between the styles. I am not sure about other browsers. However, I will focus on compatibility once a style has been chosen. Which elements work in each style? Which don't? Regards, Reece

6 8

RE: [boost] Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 30 Nov '04

30 Nov '04

I went ahead and submitted a bug report in the Sourceforge bug tracker for this issue: [ 1075456 ] Boost::thread under Linux crashes after 200 to 400 threads I made it a high priority, since it's a program crash. I attached my program to reproduce the problem, so hopefully the person who fixes this will be able to reproduce the crash pretty easily. -- Tim -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Tim Laplaca Sent: Monday, November 29, 2004 9:29 AM To: boost(a)lists.boost.org Subject: RE: [boost] Thread: Why is my prog aborting after 283 or so threads? Thanks for the link. I'm not sure it applies though; the prog isn't spawning the threads simultaneously, so it shouldn't be taking many resources. I've found that even if I only have one thread spawned at one time (where the previous thread has died out before the new one is spawned) it still aborts at the same place. Over the holiday I pared my program down to just the thread spawning, and on my Mandrake setup at home it dies at the nice even (computer) number of 256 threads. The same pared-down prog dies on my work Fedora Core 3 machine at 405. Under Windows, it doesn't ever seem to die. I'm getting pretty convinced this is a bug in the boost library that manifests itself only under Linux, and not my code. Perhaps resources are not being properly released when the threads are dying out. Since the prog is pretty small, I'll include it here. It spawns a thread every second, and each thread only last one second. #include <iostream> #include <string> #include <stdlib.h> // for multithreading #include <boost/thread/mutex.hpp> #include <boost/thread.hpp> #include <boost/thread/xtime.hpp> #include <boost/bind.hpp> int totalthreads = 0; boost::mutex io_mutex; // iostreams boost::mutex numthreads_mutex; // for changing value of numthreads boost::mutex threadid_mutex; // for manipulating thread_id using namespace std; void threadfunc() { // wait some secs boost::xtime xt; boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 1; boost::thread::sleep(xt); { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << " Thread Exiting. " << std::endl; } } main() { boost::thread_group thrds; boost::xtime xt; int maxthreads=99999; // ******************************** // Main thread-spawning loop for (int i=0; i<=maxthreads; i++) { totalthreads++; { boost::mutex::scoped_lock scoped_lock(io_mutex); std::cout << "MAIN: Thread:" << totalthreads << " being spawned... " << std::endl; } thrds.create_thread( &threadfunc); // wait some seconds boost::xtime_get(&xt, boost::TIME_UTC); xt.sec += 1; boost::thread::sleep(xt); } // end thread-spawning for loop thrds.join_all(); std::cout << "Done." << std::endl; } Here's the Makefile I build it with: lib = /usr/local/lib/libboost_thread-gcc-mt-1_32.so threadtest : threadtest.o g++ $(lib) $(lib2) -o threadtest threadtest.o -ldl -lc -lpthread threadtest.o : threadtest.cpp g++ -Wall threadtest.cpp -I/usr/local/include/boost-1_32 -pthread -c -w -O -o threadtest.o -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Alexander Nasonov Sent: Friday, November 26, 2004 2:07 PM To: boost(a)lists.boost.org Subject: Re: [boost] Thread: Why is my prog aborting after 283 or so threads? Tim Laplaca wrote: > > I wrote a prog that spawns threads (RED HAT Fedora Core 2), and after > spawning 283 or so threads, it stops running and 'Aborted' is printed. Take a look at: http://www.kegel.com/c10k.html#threaded and check your sizes. -- Alexander Nasonov _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

5 6

OT: C++ MT book release delay?
by Christopher D. Russell 30 Nov '04

30 Nov '04

I thought I was going to be able to zip out to Borders today and buy the new Abrahams/Gurtovoy book. But now A-W's website says it's not going to be released until 12-17. Bummer. Cutting it a little close for stocking stuffers aren't they? ;)

1 0

additional test for is_abstract type trait
by Christoph Ludwig 30 Nov '04

30 Nov '04

As I mentioned in previous posts the following code program #include <boost/type_traits/is_abstract.hpp> #include <iostream> template<typename T> struct A { virtual void f() = 0; } int main() { if(boost::is_abstract<A<int> >::value) { std::cout << "A<int> is abstract"; else { std::cout << "A<int> is not abstract"; } } erroneously outputs "A<int> is not abstract" if compiled with gcc 3.4. However, the regression tests report that gcc 3.4 passes the is_abstract test. The reason is that above error is triggered only if A<int> is not instantiated by the compiler; but is_abstract_test.cpp does not test class template specializations at all. This compiler bug cost me quite some time when my application showed strange errors within the boost serialization library. Therefore, I'd like to ensure that boost developers are aware of this issue so similar problems can be avoided in the future. I thus propose to add the attached test file to the type_trait regression tests. The file is based on the existing is_abstract_test.cpp. My contribution is merely that I turned all structs into templates and that I added some extra tests w.r.t. explicit spezialization. I therefore left the copyright statement as I found it in is_abstract_test.cpp. If you add the file to the CVS, I leave it to you whether you add my name there; I don't care much either way. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

5 14

once again: boost.bind namespace conflicts and how to solve them
by Stefan Slapeta 30 Nov '04

30 Nov '04

I wonder if it makes sense to write an additional header for boost.bind (and maybe boost.function) that provides the library interfaces meeting the 'modern' boost requirements, i.e.: a) this header should be placed in the bind subdirectory, e.g. boost/bind/bind.hpp b) this header should introduce a separate namespace 'bind' or 'function' to avoid the well-known namespace clashes with boost::lambda that are _really_ annoying. c) this header should not declare the placeholders in an anomymous namespace. (I don't know what was the intention behind that but it makes it impossible to write 'using boost::_1') Comments? Stefan

5 20

boost-1.32 appears at redhat/rawhide
by Neal D. Becker 30 Nov '04

30 Nov '04

I noticed that boost-1.32 appeared at http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/ I also notice that it includes 2 patches, and only builds a single version of libs. I don't know if that's because it used: -sBUILD=release or because of this patch: Index: tools/build/v1/boost-base.jam =================================================================== RCS file: /cvsroot/boost/boost/tools/build/v1/boost-base.jam,v retrieving revision 1.129 diff -c -p -r1.129 boost-base.jam *** tools/build/v1/boost-base.jam 28 Jan 2004 22:50:17 -0000 1.129 --- tools/build/v1/boost-base.jam 1 Apr 2004 22:48:45 -0000 *************** rule common-variant-tag ( toolset varian *** 2621,2630 **** local version-tag = [ MATCH "^([^.]+).([^.]+)" : $(version-number[1]) ] ; version-tag = $(version-tag:J="_") ; ! tags += $(toolset-tag:J=) ; ! tags += $(thread-tag:J=) ; ! tags += $(runtime-tag:J=) ; ! tags += $(version-tag) ; if $(tags) { --- 2621,2630 ---- local version-tag = [ MATCH "^([^.]+).([^.]+)" : $(version-number[1]) ] ; version-tag = $(version-tag:J="_") ; ! # tags += $(toolset-tag:J=) ; ! # tags += $(thread-tag:J=) ; ! # tags += $(runtime-tag:J=) ; ! # tags += $(version-tag) ; if $(tags) { I'm wondering what this does. I'm not too concerned about just release, without debug, but what about threading single/multi? Did I get only single or only mt? Should I care?

1 0

BOOST_NO_TWO_PHASE_LOOKUP ?
by Robert Ramey 30 Nov '04

30 Nov '04

I don't find anything like BOOST_NO_TWO_PHASE_LOOKUP in config.hpp Is there something like this there that I've missed? If not could it be added? I think this might be useful to me. Robert Ramey

4 5

Boost logo
by Michel André 30 Nov '04

30 Nov '04

What about something really simple. All courier and text and add some color scheme to make the logo distinct. /Michel

3 3

Re: [boost] Re: Re: additional test for is_abstract type trait
by JOAQUIN LOPEZ MU?Z 29 Nov '04

29 Nov '04

Hi Pavel ----- Mensaje original ----- De: Pavel Vozenilek <pavel_vozenilek(a)hotmail.com> Fecha: Lunes, Noviembre 29, 2004 11:39 pm Asunto: [boost] Re: Re: additional test for is_abstract type trait > > "Joaquín Mª López Muñoz" wrote: > > > John, now that you're at is_abstract, I wonder whether you could > > consider adding some workaround in is_abstract.hpp making > > boost::is_abstract return unconditionally false for those compilers > > known not to work for it. > > You can read about the origin of this request at: > > > > http://aspn.activestate.com/ASPN/Mail/Message/boost/2209389 > > > Wouldn't it be better to have macro like > BOOST_NO_XYZ defined for failing compilers instead? > Oh, yes, this is probably more sensible. No matter the final implementation, though, what we need is some direct support from is_abstract.hpp to help the programmer avoid the crashing compilers. Otherwise, the guarding macros, i.e. the actual knowledge about what compilers do support boost::is_abstract, will be duplicated and scattered across the Boost/user source code. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0