November 2004 - Boost - lists.boost.org

Re: GUI Library Proposal for a Proposal
by George van den Driessche 01 Dec '04

01 Dec '04

> Message: 16 > Date: Tue, 9 Nov 2004 09:38:35 -0500 > From: Caleb Epstein <caleb.epstein(a)gmail.com> > Subject: Re: [boost] Re: GUI Library Proposal for a Proposal > To: boost(a)lists.boost.org > Message-ID: <989aceac041109063895d91c0(a)mail.gmail.com> > Content-Type: text/plain; charset="us-ascii" > > On Mon, 8 Nov 2004 19:18:13 -0500, Edward Diener > <eddielee(a)tropicsoft.com> wrote: > > > The one area where C++ is weaker than other languages for design time UI, > > and component, development is in its lack of a general run-time reflection > > mechanism. That is the only area which I see that is holding it back. > > I've been toying with using the properties library Reece Dunn recently > submitted (in the boost-sandbox CVS) for this purpose. I've got > something very sketchy, but it relies on a visitor pattern to "pass" > type information to client code in a manner similar to Boost.Variant. > > I'd prefer a way of storing the type information for each reflectable > class statically, and in a generic way, e.g. something like > std::map<std::string, property>. This would enable the reflection > code could be decoupled from the reflected classes entirely and just > operate on this property meta-data. It would also allow client code > to lookup individual properties (e.g. by name) instead of having to > visit all of them. > > I'm stumped by how to store this information in any sort of container > though, since the properties are of different types. Any thoughts, or > is this madness? The properties are of different types, but the type information for properties will always be of the same type :) So you can generate a property set for your class, that includes the dictionary that maps names to property_type_info structures. Each property_type_info would be automatically generated from the static type of the property. The thing that's bugging me is that all the reflection mechanism is covered by Boost.Python because it relies on the same principles. I *think* the boost-langbinding list seems to know this, since you also need the reflection capabilities in order to support languages that aren't Python. But that list doesn't seem to have much traffic so I haven't much to go on. In order to avoid too many reinvented wheels, I'd like to see Boost.Python split neatly into two stages: (a) Reflect C++ types into C++ objects. Each type for which you provide a reflection map will correspond to exactly one property_set object, which would contain a set of property_type_info objects. (b) Expose the types to Python using the objects created by (a). Once you've made that split, then you can add: (c) Expose the types to Lua using the objects created by (a). (d) Expose the types to <language-of-your-choice> using the objects created by (a). (e) Serialise the types, using results of (a). (f) Bind types to GUI objects, using results of (a). (g) ... you get the point. George

14 42

Using program_options with other options methods
by Allen Bierbaum 30 Nov '04

30 Nov '04

I have recently started using the program_options library, and I find it very useful. Unfortunately I can't seem to figure out how to allow it to work with other option parsers/handlers at the same time. For example, right now I am writing an application that uses a library that has its own set of common options that are process internally. So I end up needing to write code similar to the following: po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("my_opt", po::value<int>(), "set my option") ; po::variables_map vm; po::store(po::parse_command_line(ac, av, desc), vm); po::notify(vm); custom_lib::options opts; opts.process(ac, av); Then when I run this application: ./app --my_opt=10 --liboption=custom The problem is that I get an exception from program_options: error: unknown option --liboption Is there any way to tell the program options parser to ignore options that it does not recognize? If there is no option like this, how can program_options be used with other option parsers? -Allen

5 16

[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