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

Test of e-mail client - please ignore.
by Brian Allison 06 Feb '06

06 Feb '06

I had, but our mail server munges things, and I'm not always aware of the ways in which they're munged. For better or for worse (and yes, I have a NSHO on the matter :/ ) our system admin functionalities are almost black-boxed from the rest of the geeks here. [I don't mention it for discussion, but for explanation.] Well - it should be taken care of now. If it weren't for some of our rather odd mail message requirements, I'd just use the mail command. ObNostalgia: Oh, for the BITNET days... David Abrahams wrote: >Brian Allison writes: > > > >>The test below this line should be 'quoted'. Hopefully the mail gate won't wreck it. >> >>Brian Allison wrote: >> >> Testing quoting other messages... >> >> > >Try turning off HTML messages in your client. > > >

1 0

[signals] calling delete member on connect?
by Evan Carew 06 Feb '06

06 Feb '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, am I wrong in assuming this shouldn't be happening on my linux box? [gcc 4.0.2][boost 103200] First the test program, then the output: #include <iostream> #include <cstdlib> #include <boost/signals.hpp> using namespace std; using namespace boost; class tst_out{ public: void operator()() const{ cout << "test out data1" << endl;} ~tst_out(){ cout << "Called del for tst_out" << endl;} }; class tst_out2{ public: void operator()() const{ cout << "test out 2" << endl;} ~tst_out2(){ cout << "Called del for tst_out2" << endl;} }; signal<void ()> sig; int main(int argc, char *argv[]) { tst_out tst1; tst_out2 tst2; sig.connect(tst1); sig.connect(tst2); sig(); cout << "exiting program" << endl; return EXIT_SUCCESS; } Now the output: Called del for tst_out Called del for tst_out Called del for tst_out Called del for tst_out Called del for tst_out Called del for tst_out Called del for tst_out Called del for tst_out2 Called del for tst_out2 Called del for tst_out2 Called del for tst_out2 Called del for tst_out2 Called del for tst_out2 Called del for tst_out2 test out data1 test out 2 exiting program Called del for tst_out2 Called del for tst_out Called del for tst_out Called del for tst_out2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD5RS4pxCQXwV2bJARAkBzAJ9mSmfH79X/IaOlmlquUMk9Ww/dAgCdH9xz /BaVLQC9shMvnYxBPMv13DU= =jU/r -----END PGP SIGNATURE-----

2 5

boost python (compiling an extension)
by Themistoklis Bourdenas 06 Feb '06

06 Feb '06

I'm trying to build a simple python extension similar to the one in boost.python tutorial. I really haven't yet understood the process of creating an extension for python using boost. I have to build boost.python either using bjam or loading its .sln in VS (I've used the second method). Then I write some simple code like that in the tutorial exporting a simple function and then what? I guess I have to build a .dll file for python to link to. I'm building a dynamic link library project in VS8 write the appropriate code and that successfully creates a dll file. However when importing my module python returns a runtime error: ImportError: dynamic module does not define init function (inittest_boost) What is the .pyd created in the tutorial? How is it created? I'm trying to avoid bjam as and use just VS project files. Is that possible? PS - I know I should send this message in c++-sig list but for three days now it can not confirm my subscription for some reason.

2 3

[parameters] Runtime enumeration of parameter list
by Neil Hunt 05 Feb '06

05 Feb '06

>From a post about using strings as an indexing mechanism: "David Abrahams" <dave(a)boost-consulting.com> wrote in message news:ubqzqz3sw.fsf@boost-consulting.com... <snip> >> Since all are known at compile time I'm sure it must be easy to do >> this. I'm pretty sure when someone shows me the obvious solution I >> will be very embarrassed, but until then I can do this with a >> std::map at runtime, but not at compile time. > I'm pretty sure the parameter library is a good -- if not perfect -- > match for your problem. Since I've pointed at it twice now, if you're > not embarrassed yet, I'll stop pushing ;-) I too am quite interested in this process of compile time indexing. Let me think out loud (visibly?). Question at the bottom. I have often used this pattern of access for a vector of a known size (contrived example): enum TabIndices { PERSON_TAB, ADDRESS_TAB, EMPLOYER_TAB, TAB_COUNT }; Window windows[TAB_COUNT]; ... display_window( TabIndices tab_index ) { windows[tab_index].display(); for( int i = 0; i < (int)TAB_COUNT; ++i ) { if( i != (int)tab_index ) windows[i].hide(); } } ... display_window( PERSON_TAB ); Let me have go at converting this to use the parameter keyword system for indexing by using an ArgumentPack. BOOST_PARAMETER_KEYWORD(tag, PERSON_WINDOW) BOOST_PARAMETER_KEYWORD(tag, ADDRESS_WINDOW) BOOST_PARAMETER_KEYWORD(tag, EMPLOYER_WINDOW)XXXX windows( ( PERSON_WINDOW = Window(), ADDRESS_WINDOW = Window(), EMPLOYER_WINDOW = Window() ) ); ... template<class keyword> display_window( keyword tab_index) { windows[tab_index].display(); for( YYYY ) { if( *iterator != tab_index ) windows[iterator].hide(); } } ... display_window( PERSON_TAB ); My two immediate problems are how to declare the type of the ArgumentPack that would actually hold the window objects. (XXXX) And secondly, how to iterate over the windows at runtime. (YYYY). I guess the main thrust of the question is "Does the parameters library support runtime enumeration?" or should I be looking at MPL? Neil

4 7

[date_time] How to create a time_zone_ptr from the machine settings?
by Christian Henning 05 Feb '06

05 Feb '06

Hi there, I would like to know how to create a local_date_time object. The only thing I have is a UTC time object. How do I create a time_zone_ptr from the machine settings. Thanks ahead, Christian

2 1

Crossbuild, on linux using mingw32 for win32
by Rafał Maj Raf256 05 Feb '06

05 Feb '06

What is the best way to crossbuild on linux, using mingw32, to win32? I dont see no description about such configuration on http://boost.org/more/getting_started.html mingw executable is: i586-mingw32msvc-g++

2 3

[Review] Fixed strings library
by Hartmut Kaiser 05 Feb '06

05 Feb '06

Hi all, the formal review period of the Fixed strings library written by Reece Dunn ends today. Since there was complete consent with regard to this library among all submitted reviews, it is straight forward for me to make the final decision. The library is rejected and will not be included into Boost at this point in time. The main points listed during review were: - Do we need a fixed_string library at all, is it worth the overhead? - Insufficient/confusing documentation . insufficient description of general design, design rationales and motivations . it says more about implementation details rather then the public interface . missing or insufficient documentation of parts of the library - The overall architecture of the implementation is too complicated and needs to be reworked - Missing interface for construction/interaction with std::string's - Unclear benefit to have the strings truncated to avoid overflows - Missing performance comparison with std::string and other alternatives - Compilation problems with the library as submitted for review Reece already expressed his interest to resubmit the library for review again, after he has been able to address the mention issues. I'ld like to thank Reece for submitting this library and all reviewers for their time they invested in preparing the reviews. Regards Hartmut Review Manager

1 0

Re: [Boost-users] boost::pp application
by Marco Correia 05 Feb '06

05 Feb '06

Thanks! Today I managed to get a little bit further, let me tell you where I am. First I aliased every symbol of the alphabet as an integer. #define A 1 #define B 2 ... Then I guess there are two options: 1) #define NOT_EQ(s,E1,E2) \ BOOST_PP_NOT_EQUAL(E1,E2) #define REMOVE_ALL(Elem,Seq) \ BOOST_PP_SEQ_FILTER(NOT_EQ, Elem, Seq) #define REMOVE_ELEM(s,Seq,Elem) REMOVE_ALL(Elem,Seq)(Elem) #define REMOVE_DUPLICATES(Seq) \ BOOST_PP_SEQ_FOLD_LEFT(REMOVE_ELEM, Seq, Seq) This starts with the full sequence, and for each element, removes all occurences and add it in the end. 2) The other option is similar but instead of starting with the full sequence and remove each element, it starts with an empty sequence and adds each element if it is not already there (kind of insertion sort but without sorting). I think the solution 1) is faster, but I confess it's only an intuition :) Do you see any other way, more efficient than this? Thanks a lot for trying to help! Marco On Friday 03 February 2006 22:48, you wrote: > Hi Marco, > > I just say this post now, so I'll get back to it after I get home from > work. I the pp-lib can help you with this. > > Regards, > Paul Mensonides > > > -----Original Message----- > > From: boost-users-bounces(a)lists.boost.org > > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > > Marco Correia > > > > I would like to ask if there is a way boost::preprocessor may > > be used to solve the following problem: > > > > The problem is to define a macro that expands to the > > concatenation of their arguments, without duplicates. The > > arguments are symbols belonging to a known alphabet. -- Marco Correia <mvc(a)netcabo.pt>

2 2

<cassert> in the boost libraries
by Joerg Ruedenauer 05 Feb '06

05 Feb '06

Hello, we use our own assertion handler and assert macro in our code, defined in a header which gets included at the end of our precompiled header file. Unfortunately, many boost libraries undermine this because they include the cassert header, which redefines the assert macro. Currently we work around this by putting some boost libraries in the precompiled header and including our own assert header again in each source file which includes boost headers, but this is a clumsy and error-prone solution. Boost already nominately provides a solution through BOOST_ENABLE_ASSERT_HANDLER, but it's just not used consequently throughout the libraries. Could the authors of the libraries (or the reviewers) please grep through the code and change the cassert (or assert.h) includes to boost/assert.hpp, and consequently, change assert(...) to BOOST_ASSERT(...)? I've found the inclusion particularly often in the serialization, graph, iostream and random libraries, but also in regex, signals, ptr_container and many other headers. Regards, Joerg Ruedenauer

3 4

Re: [Boost-users] Boost-users Digest, Vol 807, Issue 1
by Drumheller, Michael 05 Feb '06

05 Feb '06

>>> ------------------------------ >>> >>> Message: 9 >>> Date: Sat, 04 Feb 2006 10:30:25 +0000 >>> From: Jim Douglas <jim(a)dramatec.co.uk> >>> Subject: Re: [Boost-users] Getting started with Boost: what did you >>> need to know? >>> To: boost-users(a)lists.boost.org >>> Message-ID: <ds1vo5$ue6$1(a)sea.gmane.org> >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> >>> Drumheller, Michael wrote: >>> > Main stumbling point for me was bjam. It's not so much >>> of a problem for <..snip...> >>> Perhaps people don't complain because most only use bjam it >>> to build the >>> libraries (archives and shared objects) and then (like me) they use >>> 'make' to build the projects that incorporate Boost. I >>> would guess that you are in the minority if you write in-house extensions to >>> the Boost library. Sorry about that, I was being very unclear. I did not mean in-house extensions to the Boost library, I meant C++ extensions to Python, using Boost.Python. The Boost.Python tutorial contains an extremely ominous warning, in a big yellow box, here: <<http://www.boost.org/libs/python/doc/tutorial/doc/html/python/hello.ht ml>>, It says, in so many words, that you're a masochist if you try to build your Boost.Python extensions with anything but bjam. >>> Having said that, I can appreciate that bjam is a *very* >>> powerful tool and has many advantages over make, but I just can't find >>> the time to study the docs enough to make a trial switch. >>> >>> Jim Don't get me wrong, I can't stand the error-prone, undebuggable dinosaur that is make, and I would never advocate it for a new project. I too can appreciate that bjam seems very powerful. And elegant, in its own way. It also seems very fast. But with a monster learning curve. That's not necessarily a downer--you don't get something for nothing, and I actually *like* learning new tools, so I was happy to see the "Abandon hope, all ye who <would use a tool other than bjam>" warning on the gates of Boost.Python (yellow box above), because I thought, well, there's my motivation to learn bjam--maybe bjam will be my new default build tool(!) I read all the documents I could find, but man, it's like learning Turkish or Vietnamese or something. You need a teacher, and there are just zero teachers in my org. Alas, the bjam files in Boost themselves (those that are used to build the Boost libraries) are (or at least seem) *extremely* sohpisticated, and are woefully uncommented--in fact, absolutely *un*commented if you define a comment as something with tutorial value, e.g., "Here is an excellent example of a rule to do such-and-such." Personally, I was unable to get past the knee of the curve given my other commitments. Again, maybe it's just me. I'm curious: How many Boost users out there use bjam as the default build tool for their day-to-day programming? I recall hearing at one time that there was a movement afoot, at one time at least, to switch the Boost build process over to using scons. Any truth to that? Thanks, MD

2 1