- Boost - lists.preview.boost.org

[BGL] separate mailing list for boost/graph?
by Jeremy Siek 31 Mar '04

31 Mar '04

Hi All, I just received a request for a separate mailing list for development work on boost/graph. I'm curious as to how many people would be interested in such a list. Please send email to *me* if you have a preference for discussing BGL on a separate list or on the main boost list. Cheers, Jeremy _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Student, Indiana University Bloomington Graduating in August 2004 and looking for work C++ Booster (http://www.boost.org) _______________________________________________

1 0

Re: [boost] Re: Formal Review: Indexed Set
by JOAQUIN LOPEZ MU?Z 31 Mar '04

31 Mar '04

----- Mensaje original ----- De: Arkadiy Vertleyb <vertleyb(a)hotmail.com> Fecha: Domingo, Marzo 28, 2004 3:28 pm Asunto: [boost] Re: Formal Review: Indexed Set > Hi Joaquin, > > Sorry for joining this discussion so late, but here are my comments: Hello Arkadiy, thanks for joining in. I was certainly waiting for you to show up. > > - What is your evaluation of the design? > - What is your evaluation of the implementation? > > The code looks clean. One minor question: the index class template's > equal_range method forwards to lower/upper_bound. Is it really > the best you > can achieve here or is it just a temporary shortcut? Well, there's some room for improvement. Pavel touched on this issue some time ago, too. I didn't optimize the code at the time cause (1) this is how other STL implementations do it anyway and (2) the gain is not that much. But consider this QoI detail in my todo list. [...] > - Do you think the library should be accepted as a Boost library? > > Yes, definitely. Definitely thank you :) I'm glad you like the library. Maybe you have still some spare time to take a look at the review notes and state your opinions on best namings and header organization for indexed_set. Once fixed, there's no way back and we'll have to live with whatever cool/ugly names we have settled on. Two more questions: * Have you looked at mpl_index_list? This facility was designed with RTL in mind so as to ease the internal creation of indexed_set instantiations. Useful for your particular needs? * (off-topic) How's the RTL stuff going on? Planning on open some public discussion on its design aspects? I'd certainly love to contibute in that. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

boost-1.31.0 def() and VC7.1.3088 strangeness
by Peter Hornby 31 Mar '04

31 Mar '04

Hi, The boost version is the Version_1_31_0 tag from the CVS repository. The VC version is 7.1.3088. Compiling foo.cpp (attached) results in the error reported in BuildLog.htm (attached). The VC options are also in the BuildLog.htm Uncommenting the line in foo.cpp that that begs you to, results in a clean compile. Has anybody else encountered this sort of weirdness?? I'm getting a lot of related behaviour, but this one is simple. #include <boost/python.hpp> using namespace boost::python; class World { public: World(std::string msg): msg(msg) {} // added constructor void set1(std::string msg) throw(std::exception) { this->msg = msg; } void set2(std::string msg) { this->msg = msg; } private: std::string msg; }; void wrap_World(class_<World> &foobar) { // foobar.def("set2", &World::set2); // OK, uncomment this and the compilation works!! foobar.def("set1", &World::set1); // Error on VC7.1 }

2 3

Boost.Python interpreter reinitialization problem
by Maciej Sobczak 31 Mar '04

31 Mar '04

Hi, We (the shop where I try to promote Boost) are using Boost 1.30.2 and currently the main focus is on interpreter embedding with Boost.Python. I've hit a hard problem with this library. For some reason, I would like to clean up the Python interpreter after performing some coputations with it and possibly reinitialize it later, if there is again a need to do some scripting. In other words, my use of Python interpreter is tightly scoped and there are repetitive calls to Py_Initialize() and Py_Finalize() functions during the lifetime of the application. The problem is that the initialization code that executes inside the BOOST_PYTHON_MODULE block (more specifically: the class_'s "definitions") throws when execituting for a second time: "trying to register to_python_converter for a type which already has a registered to_python_converter" This code is executed as a result of "from mymodule import *" Python command; the second execution is a result of running this command in the interpreter that was already finalized and RE-initialized. Is there a way to re-initialize the module without re-registering the converters? Hacking the Boost.Python library is a valid option, but I would need at least a suggestion where should I go. Thank you very much for your time, -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/

2 1

Re: [boost] Re: Standard C Library and C++ / BOOST
by Reece Dunn 30 Mar '04

30 Mar '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > What about when you use boost::policy::errormsg_storage instead of > > boost::policy::no_errormsg_storage? Doing this allows the following: > > > > typedef boost::errorcheck< boost::policy::error_storage<>, > > boost::policy::errormsg_storage > > > errorcheckmsg; > > > > try > > { > > errorcheckmsg em; > > em( "oops!" ) = -3; // note the special syntax > > } > > catch( errorcheckmsg em ) > > { > > std::cout << "error: " << em.get_msg() << '\n'; > > } > > > > resulting in "error: oops!" being outputted. Using your method, the >message > > string will ont be passed and thus you would get "error: unspecified >error"! > > That is why I implemented it as above. > >I didn't see anything like that in the code you showed. It was >probably in the full implementation, but I was only looking at >what's quoted above. I posted it as a different message (errorcheck) and have been revising it based on comments and suggestions. The full code is attached here. >Anyway, why must either constructor manage the string at this >point? Why wouldn't the generation of the string occur at the >time it is requested? That is, there is no string to copy if >there is no string generated until the get_msg() mf is called. >That mf can create the string (reusing it if already computed, of >course). It depends on what you are using it for. The string for the errno handler *is* generated at get_msg() call-time. The above is based on an example Volodya posted where he put the name of the function he was calling into the code. E.g. // [paraphrased]: if( ::read( fn, ... ) < 0 ) report_error( "read", errno ); becomes ec( "read" ) = ::read( fn, ... ); As another example, you could have a handler that supports windows GetLastError and do something like: try { winerr( "Rectangle" ) = ::Rectangle( hDC, 10, 10, 110, 110 ); winerr( "Ellipse" ) = ::Ellipse( hDC, 10, 10, 110, 110 ); } catch( winapi_errorcheck e ) { std::cout << "error: " << e.get_msg() << " - " << e.error_string() << '\n'; } NOTE: I know that mixing GUI/console does not work -- this is just a usage demonstration. >If you find your approach is still needed, no problem. I just >wanted to be sure you understood what I had implied. No worries. I understood your approach, but I was designing it to be as flexible as possible. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

Building bcp with Jam V2 and como
by Edward Diener 30 Mar '04

30 Mar '04

I attempted to build bcp with Jam V2 and como under Win2k with the latest CVS source and the latest bjam.exe. My como installation is in H:\Utilities\Comeau directory and is already set up to use a back end compiler. I executed: bjam --v2 -sCOMO_PATH=H:\Utilities\Comeau -sTOOLS=como from the boost\tools\bcp directory and received this output indicating an error: "H:/Programming/Version Control/CVS/Home/boost/tools/build/v2/util\order.jam:38:in loaderror: no native rule "add-pair" defined in module "class@order." H:\Programming\Version Control\CVS\Home\boost\tools\build\v2/kernel\modules.jam:259: in import H:/Programming/Version Control/CVS/Home/boost/tools/build/v2/tools\unix.jam:16:in load H:\Programming\Version Control\CVS\Home\boost\tools\build\v2/kernel\modules.jam:259: in import H:/Programming/Version Control/CVS/Home/boost/tools/build/v2/build\toolset.jam:259: in toolset.inherit H:/Programming/Version Control/CVS/Home/boost/tools/build/v2/tools\gcc.jam:19: in load H:\Programming\Version Control\CVS\Home\boost\tools\build\v2/kernel\modules.jam:259: in import..\..\project-root.jam:2: in modules.load H:/Programming/Version Control/CVS/Home/boost/tools/build/v2/build\project-roots.jam:160: in object(project-root-object)(a)1.initialize H:/Programming/Version Control/CVS/Home/boost/tools/build/v2/build\project-roots.jam:52: in project-roots.load H:/Programming/Version Control/CVS/Home/boost/tools/build/v2/build\project.jam:61: in project.load H:/Programming/Version Control/CVS/Home/boost/tools/build/v2\build-system.jam:75: in load H:\Programming\Version Control\CVS\Home\boost\tools\build\v2/kernel\modules.jam:259: in import H:\Programming\Version Control\CVS\Home\boost\tools\build\v2/kernel/bootstrap.jam:120: in boost-build H:\Programming\Version Control\CVS\Home\boost\boost-build.jam:12: in module scope" What am I missing or what did I do wrong ? Finally it would be nice if Boost could distribute some batch files ( or Unix shells ) for each compiler toolset in which all the builder would have to do is to enter the mandatory information, as optional arguments since the environment variable might be already set, for that toolset in order to trigger off the build, rather than have to worry about command line arguments. I know the command line isn't complicated but anything to simplify the end user's or developer's burden in using Boost Build would get my vote. I have no doubt it is an excellent system, but it is a bear to learn, when all one wants is to simply build portions of Boost. I know this sounds lazy but then I am a very lazy programmer in all but programming and documentation where I am just mildly lazy <g> .

4 8

Re: [boost] Re: Standard C Library and C++ / BOOST
by Reece Dunn 30 Mar '04

30 Mar '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > The errorcheck class now has a policy-based implementation, so it would >look > > something like: > > > > template< typename ErrorStorage, typename ErrorMsgStorage > > > class errorcheck: public Storage, public MsgStorage > > { > > private: > > inline errorcheck( const Storage & s, const MsgStorage & ms ): > > Storage( s ), MsgStorage( ms ) > > { > > } > > public: > > inline errorcheck( typename Storage::error_type e ): > > Storage( e ), MsgStorage() > > { > > if( failed()) > > throw( errorcheck< Storage, MsgStorage >( *this, *this >)); > > } > > }; > > > > which, IMHO, is more confusing than the straight throw( *this ), but >does > > not use the copy constructor, relying instead of the fully constructed > > Storage and MsgStorage base classes. > >I wouldn't call it confusing, though I'd expect that you'd need >to document why you couldn't do the more obvious thing. I mean confusing in that you have errorcheck( *this, *this ) so it is harder to see what is going on. I have added a comment line explaining why this is done and would also put this in the docs. >I do have to ask why the private ctor takes a MsgStorage object >to copy since the MsgStorage in this case will be the default >constructed base subobject created in the initializer list of the >throwing ctor. As written, the second argument to that ctor is >useless; the private ctor could default construct its MsgStorage >subobject. >Actually, though, I had this in mind: >template <typename ES, typename MS> >class error_check : public ES, public MS >{ > error_check(typename ES::error_type e, std::nothrow_t) > : ES(e) > { > } > >public: > error_check(typename ES::error_type e) > : ES(e) > { > if (failed()) > { > throw error_check<ES,MS>(e, nothrow); > } > } >}; What about when you use boost::policy::errormsg_storage instead of boost::policy::no_errormsg_storage? Doing this allows the following: typedef boost::errorcheck< boost::policy::error_storage<>, boost::policy::errormsg_storage > errorcheckmsg; try { errorcheckmsg em; em( "oops!" ) = -3; // note the special syntax } catch( errorcheckmsg em ) { std::cout << "error: " << em.get_msg() << '\n'; } resulting in "error: oops!" being outputted. Using your method, the message string will ont be passed and thus you would get "error: unspecified error"! That is why I implemented it as above. >(Note that you used "Storage" where you should have used >"ErrorStorage" in the excerpt above. I just used abbreviations.) That was my bad: ErrorStorage and Storage are the same. Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

2 1

Re: [boost] Re: IndexedSet Review: unified proposal for naming
by JOAQUIN LOPEZ MU?Z 30 Mar '04

30 Mar '04

----- Mensaje original ----- De: Pavel Vozenilek <pavel_vozenilek(a)hotmail.com> Fecha: Martes, Marzo 30, 2004 7:54 pm Asunto: [boost] Re: IndexedSet Review: unified proposal for naming > > "Joaquín Mª López Muñoz" <joaquin(a)tid.es> wrote > > > * Proposal: boost::container::multi_index > > > So far no other library sits in boost::container. > Existing containers probably won't move there > the future (work, compatibility). > Well, I haven't any special desire to move into boost::container, but seems like there's a general consensus that such grand namespaces should begin to emerge. I just have no strong opinion on this, my proposal only meant to collect the feedback gotten from the reviewers. Either way, I think the proposed naming works even without ::container:: Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Any way to speed my use of boost_pp macros?
by Larry Evans 30 Mar '04

30 Mar '04

The file, http://groups.yahoo.com/group/boost/files/managed_ptr/ctor_fwder.zip , shows a simple program using boost/preprocessor macros taking 17secs to execute. If anyone has some suggestions for speeding this up, I'd certainly appreciate it. TIA.

5 14

Re: [boost] Re: Standard C Library and C++ / BOOST
by Reece Dunn 30 Mar '04

30 Mar '04

>From: Rob Stewart <stewart(a)sig.com> >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > So the errorcheck object will be in a half-constructed state. That is, >the > > int will be constructed, but the errorcheck object isn't, therefore the > > int's destructor will be called, but errorcheck's deconstructor will >not. > > > > The solution would therefore be to throw an intermediate object, like >the > > Trules from the C++ Templates book by David Vandervoorde and Nico >Josuttis. > > This would then get around the throwing in a constructor problem. >Why not throw a new errorcheck object using a private ctor that >stores but doesn't check the return value? That would work (I realised an implementation after the post). But this is what I was trying to achieve using the copy constructor (and copy assignment), since that copies the object, but does not throw on failure. The errorcheck class now has a policy-based implementation, so it would look something like: template< typename ErrorStorage, typename ErrorMsgStorage > class errorcheck: public Storage, public MsgStorage { private: inline errorcheck( const Storage & s, const MsgStorage & ms ): Storage( s ), MsgStorage( ms ) { } public: inline errorcheck( typename Storage::error_type e ): Storage( e ), MsgStorage() { if( failed()) throw( errorcheck< Storage, MsgStorage >( *this, *this )); } }; which, IMHO, is more confusing than the straight throw( *this ), but does not use the copy constructor, relying instead of the fully constructed Storage and MsgStorage base classes. Regards, Reece _________________________________________________________________ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess

2 1