May 2004 - Boost - lists.preview.boost.org

RE: [boost] Re: static sized strings
by Reece Dunn 01 Jun '04

01 Jun '04

John Nagle wrote: > I've done some cleanup on my version of fixed_string at > http://www.animats.com/source >[snip] > We're approaching convergence on this. We are both working on variations of the same idea. As such, I have fixed several errors in my code making it operate better as a basic_string interface and have seperated the safe_string.hpp file into the appropriate headers (fsstring.hpp for string.h, fsstdio.hpp for stdio.h and fswchar.hpp for wchar.h). I have also posted BoostBook format documentation to the libs section. However, we are still no closer to deciding which implementation to choose. We can either: [1] Choose one implementation and drop the other (possibly collaborate); [2] Continue both and put them against each other to see which is better; [3] Drop both and develop one together from scratch. Option [3] is not viable, since a lot of the hard work has already been done (size issues, etc.). I would like the implementation we use to be mine and I'm sure John feels the same way about his. I am also getting to the stage where I am considering putting mine up for review (once I get the tests written). What do other people think? Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

Re: [boost] Re: [prereview request][fsm]
by eegg＠comcast.net 01 Jun '04

01 Jun '04

--- Rob Stewart <stewart(a)sig.com> wrote: > From: "E. Gladyshev" <eegg(a)comcast.net> > > From: "Rob Stewart" <stewart(a)sig.com> > > > From: "E. Gladyshev" <eegg(a)comcast.net> > > > > From: "Rob Stewart" <stewart(a)sig.com> > > [...] > > 1. Some platforms pose non-C++ exceptions as normal C++ exception. > > You don't always want those platfrom specific exceptions trigger > > a whole bunch of stuff in your program. > > The only platform I know of that does that is Windows/MSVC It makes it pretty common, doesn't it. :) > you can handle structured exceptions specially. Perhaps it > means that boost::fsm needs to provide a means to install an > exception handler for those exceptions not already recognized by > the library: > > try { throw; } > catch (...) { boost::fsm::detail::handle_exception(); } > > void boost::fsm::detail::handle_exception() > { > try { throw; } > catch (type1 const &) { ... }; > catch (type2 const &) { ... }; > catch (type3 const &) { ... }; > catch (...) { user_handler(); } > } > where user_handler is a pointer to function that's initialized to > std::unexpected() and can be overridden by the library user. Adding user_handler() doesn't stop stack unwinding. I think you are missing the point. The issue is not in how to process SEH exceptions (or any other unhandled exception) the issue is in how not to trigger stack unwinding (for all exceptions) and still be able discriminate user exception types generically in FSM. Your solution doesn't solve this problem. > > It may also be that SEH can be configured to intervene before a > C++ exception is generated by the RTL so those never become C++ > exceptions that can muck up the works. It is not trivial... but it is out of the FSM topic. > > 2. Your design assumes that all possible exceptions are known > > and you handle them. So any unhandled exception is a bug. > > Not quite. What I was showing would rethrow any unknown > exception, leaving to clients to determine how to handle it. > > > It is not safe to trigger stack unwinding in a buggy environment. > > If you say so. Every application and platform with which I work > is buggy and yet I manage to use exceptions and stack unwinding > works. What do you mean by "stack unwinding works". Do you mean that even if the exception is caused by a bug, stack unwinding didn't make things worse or less safer? Well, it's a long shot... [...] > This is just another case of things not being as pretty > as one might like but that doesn't mean stack unwinding is > faulty. Sorry, who said that stack unwinding is faulty? Eugene

5 8

Re: [boost] [Serialization] Errors when compiling using GCC 3.4
by Robert Ramey 01 Jun '04

01 Jun '04

Allen Yao wrote: > I just updated my gcc from 3.3.3 to 3.4, and found that the > serialization17 and serialization18 cannot compile. There are many error > messages, some of them seem to caused by lack of "typename", others are > very strange, for example, about using boost::noncopyable. > Does someone try serialization library on GCC 3.4? Can it be compiled? > I suspect I am missing something. Otherwise, I would like to try to "fix" > the "bugs" myself. Hmmm, I just checked. I'm currently using gcc 3.3.1 ? Should I upgrade to gcc 3.4.? I seem to recall information on the list that suggested it would be better to wait a little bit. If upgrading is a good thing - now is a good time for me to do it as I'm just finalizing all the changes for next version and just starting the "torture test torture" procedure of reconciliation of compiler quirks. Robert Ramey

4 5

[Formal review request] policy_ptr
by David B. Held 01 Jun '04

01 Jun '04

I am formally requesting that policy_ptr be added to the review queue. The version to be reviewed is different from the version currently in the sandbox, but will be available long before the current queue is exhausted. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004

3 3

Boost Software License & GPL
by Alex Vinokur 01 Jun '04

01 Jun '04

<QUOTE from http://www.boost.org/more/lib_guide.htm#License> License requirements The preferred way to meet the license requirements is to use the Boost Software License. See license information. If for any reason you do not intend to use the Boost Software License, please discuss the issues on the Boost developers mailing list first. </QUOTE> I am thinking of submission some software to Boost. However I put this software in several sites under GPL. Boost requires Boost Software License. How to solve this problem? -- Alex Vinokur mailto:alexvn@connect.to http://mathforum.org/library/view/10978.html

3 3

bjam - adding includes
by John Torjo 31 May '04

31 May '04

Hi all, Is there a way to add an <include> to bjam, by specifying it on command line? In particular, I'm trying to build a non-boost library, which needs boost ;) Therefore, I need to specify the path where boost headers are. Since I want to distribute this library, I don't think that adding an <include> in the jamfile, specifying where my boost is installed is the way to go ;) So, is it possible? If so, how? Thanks. Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

3 2

[multi_index] Volunteer to help porting to VC7.0?
by Joaquín Mª López Muñoz 31 May '04

31 May '04

Regression tests for VC7.0 show a recurrent problem throughout the library with a specific facility in boost/multi_index/detail/allocator.hpp. My hunch is that this should be easy to fix, but it is not productive to try variations on the main CVS and wait for the regression tests outputs. Anyone with VC7.0 volunteering to help with porting of Boost.MultiIndex to VC7.0? If so please contact me and I'll provide you with all the relevant info and some suggestions of things to try. I think this souldn't be to hard to fix. Thanx in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Volunteer for a little test in MSVC 7.0?
by JOAQUIN LOPEZ MU?Z 31 May '04

31 May '04

I'm trying to make Boost.MultiIndex work for MSVC 7.0 an the regression tests show some weird results. I'm suspicious this can be related with a similar problem in MSVC 6.0 having to do with pointers to members being used as template prams. Would any kind soul with access to MSVC 7.0 run the following test and report the result? TIA Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ****************** struct pair { int x,y; pair(int x_,int y_):x(x_),y(y_){} }; template<int pair::* PtrToPairMember> struct foo { int bar(pair& p){return p.*PtrToPairMember;} }; int main() { pair p(0,1); foo<&pair::x> fx; foo<&pair::y> fy; if(fx.bar(p)!=0||fy.bar(p)!=1)return -1; return 0; } *****************

5 5

Metrowerks: member template specialization problem
by Vladimir Prus 31 May '04

31 May '04

I get the following error from metrowerks: http://tinyurl.com/2z6st It seems that given: template<> bool basic_config_file_iterator<wchar_t>::getline(std::string& s); template<class charT> bool basic_config_file_iterator<charT>::getline(std::string& s) { return std::getline(*is, s); } Metrowerks decides to use the second, unspecialized version, even for basic_config_file_iterator<wchar_t>, and this surely fails to compile. Anybody knows what could be the reason? The entire header which causes the error can be found at: http://tinyurl.com/2rapj Thanks in advance, Volodya

3 6

[Formal review result] Collection Traits Library
by Hartmut Kaiser 30 May '04

30 May '04

Hi all, after working through the pile of mails submitted for the review of the Collection Traits Library from Thorsten Ottosen, it is obvious, that it is ACCEPTED to Boost. All of the reviewes voted YES to include the library. Congratulations Thorsten! Most of the issues brought up during the review (mainly documentation nitpicks) were resolved already by Thorsten (or Thorsten agreed to fix them). Here are the open ones: 1) There were some discussions, whether the library should be renamed and/or incorporated with other ongoing efforts. There was no definitive consensus, how to achieve this. But the discussions showed that it seems to be good, if the collection traits library could be integrated with other libraries, existing and currently developed, to make it a part of a future Boost.Range library. I'm sure, that we'll see a lot of corresponding discussions in the future. 2) The strong requirement that end() should have constant complexity rules out the integration of C-strings into the library. Additionally special threatment of char[] arrays is needed, so they behave in the same way as their char* conterparts. The problem, that end(char[]) pointed to the byte after the '\0' was corrected already. Regards Hartmut Review Manager

2 1