- Boost - lists.preview.boost.org

RE: RE: [boost] Library Proposal: database (boost::db)
by Brian Braatz 22 Oct '04

22 Oct '04

Sorry to anyone who was interested in the doc I said I was going to write up (had a few work things that delayed be for a few days). I got up very early this morning and finished it off. I did a write up on the issues I have run into trying to use multi_index dynamically and issues in general for supporting DB frameworks in boost. I have placed it in the boost files section http://groups.yahoo.com/group/boost/files/BoostTable/ BTW- IT BARELY fit- it would appear there is not any more room on that area for files. I also was not able to re-download it - (or anything else for that matter from that area)- it looks like the yahoo file servers may be temporatily at lunch. If you have difficulty getting to this or would like me to mail it to you, please send me private mail and I will send to you directly. Thanks Brian Braatz brianb(a)rmtg.com > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Brian Braatz > Sent: Tuesday, October 19, 2004 6:30 AM > To: boost(a)lists.boost.org > Subject: RE: RE: [boost] Library Proposal: database (boost::db) > > > (sorry been away from mail over the last 3 days)- I wanted to respond > that > > JOAQUIN LOPEZ MU?Z Writes: > > "> If you'd care to sketch what kind of dynamic multi_index > > you have in mind (from the user point of view) maybe we > > can come out with some solid design to implement > > in future releases of the lib. My intention is to stay > > away from relational stuff, but I'll go for a dynamic > > container if it can be made general purpose." > > I *very* much want to take you up on this- tonight (about 12 hours from > now) I will write something up and show you what I did. > > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org [mailto:boost- > bounces(a)lists.boost.org] > > On Behalf Of JOAQUIN LOPEZ MU?Z > > Sent: Friday, October 15, 2004 12:06 PM > > To: boost(a)lists.boost.org > > Subject: Re: RE: [boost] Library Proposal: database (boost::db) > > > > Hi Brian, > > > > ----- Mensaje original ----- > > De: Brian Braatz <brianb(a)rmtg.com> > > Fecha: Viernes, Octubre 15, 2004 6:56 pm > > Asunto: RE: [boost] Library Proposal: database (boost::db) > > > > [...] > > > > > > I am currently going down this exact path and wanted to share what > > > I ran > > > into: > > > > > > 1- Boost does not have a 2dim "Table<>" - i.e. a Recordset > > > 2- Boost.multi_index only works with concrete structures > > > I would love it if I could use that to make a dynamic Table\ > > > recordset > > > > What do you mean by concrete structures? > > > > > 3- I have had to build my own Table<> by internally using > > > boost.multiindex > > > > Do you mean, you have actually built a Table<> class > > using Boost.MultiIndex? > > > > > > [...] > > > > > I believe boost is missing a "recordset" analolgy and I would hope > > > thatwhatever is created is not "struct only" like > > > boost.multi_index. (don't > > > get me wrong I LOVE the multi_index - it just doesn't work > > > dynamically) > > > > Well, in the past I thought about what a > > dynamic_multi_index_container (with run-time specification > > of indices) could look like: the implementation internals > > are not hard to solve with the same framework as > > Boost.MultiIndex, it is the interface that I don't have a > > clear idea about. Also, I don't envision a clear usage > > scenario for this, and there are RTTI-like issues > > involved as well (what should get<N>() return?) > > > > If you'd care to sketch what kind of dynamic multi_index > > you have in mind (from the user point of view) maybe we > > can come out with some solid design to implement > > in future releases of the lib. My intention is to stay > > away from relational stuff, but I'll go for a dynamic > > container if it can be made general purpose. > > > > On another topic, have you considered Arkadiy's > > RTL as another source of ideas/synergies? Seems like > > Arkady sort of diverted to his BOOST_TYPEOF facility, > > so I don't know what the current status of the lib is. > > > > Joaquín M López Muñoz > > Telefónica, Investigación y Desarrollo

1 0

[serialization] BOOST_CLASS_IMPLEMENTATION and partial template specalization
by Vyacheslav E. Andrejev 22 Oct '04

22 Oct '04

Hello, Using BOOST_CLASS_IMPLEMENTATION there is no way to assign specific serialization implementation to any specialization of some template class. Suppose we have template class template <class Params> class LaserPointSerializationExpression { ... }; And we want that any specialization of this class should be object_serializable. Simple use of BOOST_CLASS_IMPLEMENTATION(LaserPointSerializationExpression, boost::serialization::object_serializable); will give us the following code namespace boost { namespace serialization { template <> struct implementation_level<LaserPointSerializationExpression > { typedef mpl::integral_c_tag tag; typedef mpl::int_< boost::serialization::object_serializable > type; static const int value = implementation_level::type::value; }; } } which obviously will fail to compile. The correct code is namespace boost { namespace serialization { template <class Params> struct implementation_level<asda::lpfio::LaserPointSerializationExpression<Params> > { typedef mpl::integral_c_tag tag; typedef mpl::int_< boost::serialization::object_serializable > type; static const int value = implementation_level::type::value; }; } } But there's no macro such as BOOST_CLASS_IMPLEMENTATION to generate it. So I think there should be special version of BOOST_CLASS_IMPLEMENTATION that allows to generate implementation_level for any specialization of some template. -- ______________________________ Vyacheslav E. Andrejev System Architect, Excelsior, LLC E-mail: vandrejev(a)excelsior-usa.com ICQ: 7152604

2 1

Math functions for Stastistics- feedback from TR2 proposal
by Paul A Bristow 22 Oct '04

22 Oct '04

Sadly I was not able to attend The Redmond meeting to present proposals myself, but Alisdair Meredith gave the following feedback: "I mentioned I would like feedback for stats functions, at least as a rough indicator on how to proceed. Unfortunately feedback was overwhelmingly negative. It is seen as a lot of work for a small audience with minimal commercial incentive. Bill Plauger went so far as to say given the chance again, he would not have taken on the current math functions and once bitten, twice shy. If this is to stand any chance of consideration, we need a cast iron case proving: i/ market demand ii/ reasonable implementability It is too early to be drawing the exhaustive list of functions. One approach suggested was that if we got an implementation into Boost, and there is feedback of widespread adoption, then there would be incentive to revisit the issue." I find this response rather baffling considering the importance of these functions for even the most basic statistics. I can only conclude that they are under the common delusion that computer systems are only responsible for reproducing the data input and does not extend to deriving information to justify action. As a very simple example, if you make several measurements on two things, whether racing driver lap times, pipe diameters, share prices, accident rate, ore yield, or pollutant levels, you need some of these statistics functions to be able to judge the probability that one is different from the other. So I am now asking for your views on if it is worth producing a Boost library version based on the existing Cephes implementation by Steven Moshier who has kindly agreed to make it available under the Boost licence terms. It would be a modest effort to rename the existing Cephes C double functions, and provide the C++ templates to use them. This would be a 'proof-of-concept' implementation, with some minimal testing (the original code has been quite well tested). But there would be a lot more tedious work to produce a full implementation including all three builtin floating-point formats, and perhaps the existing high precision UDT Floating point as well. I am sure you will understand I would not want to put a lot of effort into this, only to have it rejected by Boosters. Please let me have your views on if and how to progress this topic. Paul Slightly updated versions of my TR2 proposal are at http://www.hetp.u-net.com/public/math_stats_functions_tr2_v2.doc http://www.hetp.u-net.com/public/math_stats_functions_tr2_v2.pdf Powerpoint presentation of short bullet points used in my presentation to the UK C++ panel. http://www.hetp.u-net.com/public/Math%20functions%20for%20C%20and%20C++%20St andard.ppt and a text version http://www.hetp.u-net.com/public/Math%20functions%20for%20C%20and%20C++%20St andard.txt Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

5 4

Possible bug in thread/tss.cpp
by Baptiste Lepilleur 22 Oct '04

22 Oct '04

I think there is a bug related to the fact that global static variable initialization order is undefined. tls_data is a global variable which is initialized indirectly by tss::init(). thread_specific_ptr<> instance usually also global static variable and call tss::init() in their constructor. Both being global static variable, their initialization order is unspecified, and error may occurs if thread_specific_ptr<> is initialized before tls_data. Questions: wouldn't it be possible to get ride of the tls_data memory leak, by using a by value tls_data static data instead of a pointer, and calling pthread_key_delete() to ensure callback are no longer called ? Baptiste.

1 0

get original argv string(s) for program option?
by Jonathan Graehl 22 Oct '04

22 Oct '04

Is it possible to index from option name to the original argv string(s) supplied by the user? It doesn't seem possible to do this with vm["option"].as<string>() since: 1. *template*<*typename* T> *const* T & as() *const*; If stored value if of type T, returns that value. Otherwise, throws boost::bad_any_cast exception. Now that I think of it, because options can come from environment vars and config files as well, the original string won't necessarily be lying around in memory, but would have to be copied somewhere. What would be nice is if variable_value could (yes, at some cost to those who don't use it) store the original string(s) automatically? The vector<option> from command_line_parser isn't convenient to use (since it can't be indexed by option name, but would have to be searched.

2 1

RE: [boost] Re: Any interest in adding unicode support to boost?
by Glen Knowles 22 Oct '04

22 Oct '04

> From: Eric Niebler > Erik Wien wrote: > > "Miro Jurisic" <macdev(a)meeroh.org> wrote in message news:macdev- > > > >>I am not sure I buy this. I think that if you want to have > unchecked > >>Unicode data, you should use a vector<char*_t>. Unicode > strings have > >>well-defined invariants with respect to canonicalization and > >>well-formedness, and I think that the a Unicode string abstraction > >>should enforce those invariants. > >> > >>Having intermediate states that are invalid and a final > state that is > >>valid is not a feature, it's a bug. It's a silent failure > that I want > >>to know about. > > > > > > Amen. ;) > > > > No fair bringing religion into this. ;-) I'll repeat what I > said before > -- this would be an unfortunate design, and you'll hear about it from > your users. If you force people to do their bit twiddling in > vector<char*_t>, then you impose an extra allocation and a > copy to get > it into a unicode::string, and most people won't bother. If it imposes a copy I certainly won't use it. What I'm interested in are functions to compare utf* encoded arrays and create sort keys from those same arrays. In truth, all I need are unicode aware versions of strcoll, strxfrm, and strlwr that don't require locking a mutex around the global locale in my multithreaded code. But other things such as substring and regex matching would also be welcome. I'm sure its already been discussed adnausem, but the fact that atof, ostringstream ctor/dtor, printf, tolower, etc all may mutex around access of a global locale has forced me to strip them out of quite a bit of code. In my tests this was fine on a uniprocessor, marginal on a dual, but on a quad or better it was the single biggest bottleneck. I almost always want to treat strings as char arrays. Most operations are simply copying/moving or checking to see if the string is in a set or hash. If I need to do a lot of locale aware comparisons I'm going to generate sort keys first. Glen

1 0

[graph] adjacency_list::operator=()
by David M. Jones 21 Oct '04

21 Oct '04

Hello all, If I have an adjacency_list g and I call g = g; all of the vertices and edges of g are removed. This is not what I would expect; I would expect that this operation would not change g. 1. Is this the desired behavior? (It seems different than what other types do.) 2. Is this issue old news? (I couldn't find it on the mailing list archives but it may well be there.) Thanks, David

4 4

RE: [boost] Re: Any interest in adding unicode support to boost?
by Stefan Seefeld 20 Oct '04

20 Oct '04

> From: Peter Dimov [mailto:pdimov@mmltd.net] > Sent: October 20, 2004 15:52 > To paraphrase, unnecessary parameterization is the root of most evil > nowadays. Parameters are a liability, not an asset. I'd sign that any day ! However, the primary goal behind my XML wrapper library (which, by the way, I already discussed here on the boost list to see whether there was enough interest into a general purpose C++ API for dealing with XML...) was to define an API, and to provide a sample implementation as a proof-of-concept. The fact that this particular implementation I'v been using is based on utf-8 should be transparent (though accessible). Regards, Stefan

2 1

RE: [boost] Re: Any interest in adding unicode support to boost?
by Stefan Seefeld 20 Oct '04

20 Oct '04

> From: Erik Wien [mailto:wien@start.no] > Sent: October 20, 2004 14:37 > > - Why would the user want to change the encoding? Especially between > > UTF-16 and UTF-32? > > Well... Different people have different needs. If you are > mostly using ASCII > characters, and require small size, UTF-8 would fit your > bill. If you need > the best general performance on most operations, use UTF-16. > If you need > fast iteration over code points and size doesn't matter, use UTF-32. another argument is legacy / compatibility. I'v written an XML library in C++ that essentially wraps a C library (libxml2 for the insiders), and so I'd like to avoid unnecessary string copies when passing data around. While the inside uses utf-8, I want to make the wrapper API adaptive to user-side unicode APIs. Thus the unicode type has become a template parameter, and conversion is being done by a trait class. Regards, Stefan

2 1

Re: [boost] http://www.boost.org/libs/utility/iterator_adaptors.htm
by JOAQUIN LOPEZ MU?Z 20 Oct '04

20 Oct '04

This is corrected in RC_1_32 (the link forwards to Boost.Iterator docs, which is (if I'm not wrong) preferred to old iterator adaptors.) ----- Mensaje original ----- De: "Neal D. Becker" <ndbecker2(a)verizon.net> Fecha: Miércoles, Octubre 20, 2004 7:26 pm Asunto: [boost] http://www.boost.org/libs/utility/iterator_adaptors.htm > Bad link on http://www.boost.org/libs/utility -> iterator_adaptors.htm > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

http://www.boost.org/libs/utility/iterator_adaptors.htm
by Neal D. Becker 20 Oct '04

20 Oct '04

Bad link on http://www.boost.org/libs/utility -> iterator_adaptors.htm

1 0

[thread] static builds for bcc32
by Russell Hind 20 Oct '04

20 Oct '04

The latest boost thread builds static libs for bcc32 on win32, but when I link, my app is still looking for the dynamic lib even if I'm set to use static libs? Can the static thread lib be used with bcc32? If not can it be disabled from the build so people aren't tempted to use try and use it? Thanks Russell

2 2

Re: RE: [boost] Library Proposal: database (boost::db)
by JOAQUIN LOPEZ MU?Z 20 Oct '04

20 Oct '04

Hi Brian, ----- Mensaje original ----- De: Brian Braatz <brianb(a)rmtg.com> Fecha: Viernes, Octubre 15, 2004 6:56 pm Asunto: RE: [boost] Library Proposal: database (boost::db) [...] > > I am currently going down this exact path and wanted to share what > I ran > into: > > 1- Boost does not have a 2dim "Table<>" - i.e. a Recordset > 2- Boost.multi_index only works with concrete structures > I would love it if I could use that to make a dynamic Table\ > recordset What do you mean by concrete structures? > 3- I have had to build my own Table<> by internally using > boost.multiindex Do you mean, you have actually built a Table<> class using Boost.MultiIndex? [...] > I believe boost is missing a "recordset" analolgy and I would hope > thatwhatever is created is not "struct only" like > boost.multi_index. (don't > get me wrong I LOVE the multi_index - it just doesn't work > dynamically) Well, in the past I thought about what a dynamic_multi_index_container (with run-time specification of indices) could look like: the implementation internals are not hard to solve with the same framework as Boost.MultiIndex, it is the interface that I don't have a clear idea about. Also, I don't envision a clear usage scenario for this, and there are RTTI-like issues involved as well (what should get<N>() return?) If you'd care to sketch what kind of dynamic multi_index you have in mind (from the user point of view) maybe we can come out with some solid design to implement in future releases of the lib. My intention is to stay away from relational stuff, but I'll go for a dynamic container if it can be made general purpose. On another topic, have you considered Arkadiy's RTL as another source of ideas/synergies? Seems like Arkady sort of diverted to his BOOST_TYPEOF facility, so I don't know what the current status of the lib is. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

8 17

ATTN: Branch for release is scheduled for tonight
by Aleksey Gurtovoy 20 Oct '04

20 Oct '04

I'll post another notice right before the branching, and yet another one when it's complete. -- Aleksey Gurtovoy MetaCommunications Engineering

8 10

Sprit-1.6 and latest boost
by Russell Hind 20 Oct '04

20 Oct '04

Because bcc32 can't deal with spirit-1.8, to use spirit and boost 1.31, I've replaced spirit.hpp and the spirit directory in boost with the 1.6 distribution. This doesn't work with the latest boost code, it looks like the errors are due to the changes mpl that were mentioned. Are there any plans to update spirit 1.6 to work with latest boost so those of us with older compilers can use the two together? Thanks Russell

3 9

Boost 1.31.0 just announced on freshmeat??
by Neal D. Becker 20 Oct '04

20 Oct '04

What's this? http://freshmeat.net/projects/boost/?branch_id=3248&release_id=176309

2 1

RE: [boost] Re: Any interest in adding unicode support to boost?
by Stefan Seefeld 20 Oct '04

20 Oct '04

> From: Robert Ramey [mailto:ramey@rrsd.com] > Sent: October 19, 2004 12:19 > So I always presumed that there was a "unicode" locale that > implemented this > as well all other required information. Now that I think > about it I realize > that it was only a presumption that I never really checked. > Now I wonder > what facitlities do most libraries do provide for unicode > facets. I know > there are ansi functions for translating between multi-byte and wide > character strings. I've used these functions and they did > what I expected > them to do. I presumed they worked in accordance with the currently > selected locale and its related facets. If the > basic_string<wchar_t>::operator<(...) isn't doing "the right > thing" wouldn't > it be just a bug in the implementation of the standard > library rather than a > candidate for a boost library? The unicode standard is rather young, compared to the C++ standard library. It seems the original authors of std::locale and std::basic_string just prepared for some expected flexibility. That doesn't mean all the complexities of today's unicode could fit into that. Just look at the size requirements alone compared to 'wchar_t'... Regards, Stefan

2 1

ATTN: Branch for release completed
by Aleksey Gurtovoy 20 Oct '04

20 Oct '04

Per our standard conventions, the branch tag is "RC_1_32_0", and the main trunk state from which the branch was performed is tagged as "merged_to_RC_1_32_0". Please see http://www.boost.org/more/release_procedures.htm#Developers for a detailed procedure for merging fixes between the branch and the main trunk. To regression runners using "regression.py" driver: to switch the tests to run on the branch, you need to specify the branch name in the script's command line using the '--tag': python regression.py --tag=RC_1_32_0 ... -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

ATTN: Branch for release starts in 10 minutes
by Aleksey Gurtovoy 20 Oct '04

20 Oct '04

Please do not check in anything into the main trunk until further notice. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re:Re: [boost] Re: serialization - build shared libs
by Robert Ramey 20 Oct '04

20 Oct '04

Martin Ecker wrote: >Neal Becker wrote: >> Is this perhaps a MS-windows specific problem? I did build a shared lib >> (using scons, I haven't learned jam yet), and AFAICT it is working, on >> Linux. >I'm pretty sure you will also run into problems with shared objects >under Linux. The problem is that certain global variables (e.g. for >the type registry) are defined as static member variables in header >files. Under Windows, if two different DLLs include this header file, >you will get two different copies of that static member variable - one >in each DLL - although there should only be one. Maybe the linker >under Linux is smart enough to resolve such issues. >Have you tried to serialize a class defined in one shared object > (which is registered in the type registry via BOOST_CLASS_EXPORT) from >code in another shared object? That's when you might run into >problems. You definitely will under Windows. >You might also run into problems when you dynamically (i.e. explicitly >in your code via dlopen) load a shared object, which contains classes >that use BOOST_CLASS_EXPORT to register themselves. Again, under >Windows you definitely will. I think there is a little confusion here about what it means to build the serialization library as a Shared Library or DLL. a) if you mean creating libraries which contain exactly the same functionality as libboost_serialiation.lib and libboost_wseralization.lib then there should be no problem as far as I know. Note that you might have problems if you loading/unloading the shared libraries multiple times under program control. I'm not sure. I haven't tested this and have left it for latter. Mainly this is because it should use the ABI autolink to be line with other boost libraries and work better for users. b) if you creating DLLS which instantiate serialization templates for specific classes - then you most likely have problems. There are still some issues pending. Martin has jumped ahead and addressed these issues for his application and most of his additions will likely eventually find their way into the serialization library in some form. Robert Ramey

4 16

[fsm] New release
by Andreas Huber 19 Oct '04

19 Oct '04

Dear Boosters I've finally managed to address the main issues that were raised in the last discussion on boost::fsm (exit() and BOOST_FSM_RELAX_TRANSITION_CONTEXT). Code and documentation should now be reasonably close to what will undergo the formal review. The only thing that is still lacking are proper tests, which I'll try to implement in the next few weeks. The .zip can be found here: http://boost-sandbox.sf.net/fsm.zip The docs are also available online: http://boost-sandbox.sf.net/libs/fsm As always: Feedback is highly welcome. Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

RE: [boost] Re: Any interest in adding unicode support to boost?
by Bennett, Patrick 19 Oct '04

19 Oct '04

> On Behalf Of Erik Wien > Sent: Tuesday, October 19, 2004 11:09 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Any interest in adding unicode support to boost? > > ----- Original Message ----- > From: "Patrick Bennett" <patrick.bennett(a)inin.com> > > > Erik, be sure to take a look at IBM's open-source ICU library: > > http://oss.software.ibm.com/icu/ > > I have looked at the ICU library, and it's a very good unicode > implementation, but the goal of my project will be to create a library > that is in a form that could be standardized in boost, and from what > have seen/read, ICU is not really suited for that. [Bennett, Patrick] Agreed. I just wanted to make sure you took a look at it, minimally, as a guide or reference, as it is quite extensive. > If the ICU licence is boost compatible, it would be possible to base an > implementation on ICU however, but that will be determined if the project > is approved by my college. [Bennett, Patrick] If it matters, ICU's license is about as simple as it gets.

1 0

david_abraham's lock in CVS
by Russell Hind 19 Oct '04

19 Oct '04

Trying to check out CVS: and am getting cvs checkout: [08:31:45] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/v2/test/dependency-test/src1 For more than half an hour. How long to these take to expire? Thanks Russell

2 1

patch to build boost on dragonflybsd
by Patrick Mauritz 19 Oct '04

19 Oct '04

the attached patch makes it possible to build boost on dragonflybsd with gcc3.4. the change in boost/python/detail/config.hpp is necessary as dfly doesn't provide the gcc-patched headers that "fix" offsetof(). if defined(freebsd)&&!defined(dragonfly) is in there as dfly sometimes defines both of them. after this patch, everything except boost::serialize (which complains about lack of wchar_t) should build. patrick mauritz

2 1

RE: RE: [boost] Library Proposal: database (boost::db)
by Brian Braatz 19 Oct '04

19 Oct '04

(sorry been away from mail over the last 3 days)- I wanted to respond that JOAQUIN LOPEZ MU?Z Writes: "> If you'd care to sketch what kind of dynamic multi_index > you have in mind (from the user point of view) maybe we > can come out with some solid design to implement > in future releases of the lib. My intention is to stay > away from relational stuff, but I'll go for a dynamic > container if it can be made general purpose." I *very* much want to take you up on this- tonight (about 12 hours from now) I will write something up and show you what I did. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of JOAQUIN LOPEZ MU?Z > Sent: Friday, October 15, 2004 12:06 PM > To: boost(a)lists.boost.org > Subject: Re: RE: [boost] Library Proposal: database (boost::db) > > Hi Brian, > > ----- Mensaje original ----- > De: Brian Braatz <brianb(a)rmtg.com> > Fecha: Viernes, Octubre 15, 2004 6:56 pm > Asunto: RE: [boost] Library Proposal: database (boost::db) > > [...] > > > > I am currently going down this exact path and wanted to share what > > I ran > > into: > > > > 1- Boost does not have a 2dim "Table<>" - i.e. a Recordset > > 2- Boost.multi_index only works with concrete structures > > I would love it if I could use that to make a dynamic Table\ > > recordset > > What do you mean by concrete structures? > > > 3- I have had to build my own Table<> by internally using > > boost.multiindex > > Do you mean, you have actually built a Table<> class > using Boost.MultiIndex? > > > [...] > > > I believe boost is missing a "recordset" analolgy and I would hope > > thatwhatever is created is not "struct only" like > > boost.multi_index. (don't > > get me wrong I LOVE the multi_index - it just doesn't work > > dynamically) > > Well, in the past I thought about what a > dynamic_multi_index_container (with run-time specification > of indices) could look like: the implementation internals > are not hard to solve with the same framework as > Boost.MultiIndex, it is the interface that I don't have a > clear idea about. Also, I don't envision a clear usage > scenario for this, and there are RTTI-like issues > involved as well (what should get<N>() return?) > > If you'd care to sketch what kind of dynamic multi_index > you have in mind (from the user point of view) maybe we > can come out with some solid design to implement > in future releases of the lib. My intention is to stay > away from relational stuff, but I'll go for a dynamic > container if it can be made general purpose. > > On another topic, have you considered Arkadiy's > RTL as another source of ideas/synergies? Seems like > Arkady sort of diverted to his BOOST_TYPEOF facility, > so I don't know what the current status of the lib is. > > Joaquín M López Muñoz > Telefónica, Investigación y Desarrollo >

1 0

RE: [boost] Re: Library Proposal: database (boost::db)
by Brian Braatz 19 Oct '04

19 Oct '04

That's cool. Thank you. Tito/Anyone It would appear that I am working on something similar (though closer to the MYSQL++ model). I am working on a wrapper over ODBC in this vein. I invite again anyone to send me private mail if this discussion gets off topic boost wise. Motivations: 1- We *need* a db layer in boost 2- I *need* to make some modifications in some existing code for a project I am working on- this may or may not be appropriate for boost- i.e. if I can do this and also somehow help a boost db along- then great > On Behalf Of Maciej Sobczak > Sent: Friday, October 15, 2004 11:51 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Library Proposal: database (boost::db) > Hi, > > Brian Braatz wrote: > > > At the end of the day- I believe that a balance between "recordset"-ish > > model of MYSQL++ and the power of OTL would be a good combination. > > > > A library is not useful if it is too hard to get up to speed on OR too > > terribly different from what people are used to. > > Just to stirr up a little bit: > > http://www.msobczak.com/prog/soci/ > > This library aims at simple usage patterns, where intuitive and almost > "embedded" syntax at at premium. A very different approach from those > you discuss, but in fact complementary and can be merged with other > approaches. > > (the code is to be modified a little bit, but what is available at the > moment works fine with Visual C++ 7.1 and g++ 3.2) > > -- > Maciej Sobczak : http://www.msobczak.com/ > Programming : http://www.msobczak.com/prog/

1 0

[Formal review request] const_string
by Maxim Yegorushkin 19 Oct '04

19 Oct '04

Recent postings showed interest in an immutable string facility [*]. Its interface and implementation has now reached a stable state (I hope). I am formally requesting that const_string be added to the review queue. The documentation can be found here: http://conststring.sf.net/ (it's not in a final state, but I'm going to extend it while it stays in the queue) [*] http://aspn.activestate.com/ASPN/Mail/Message/boost/2180929 -- Maxim Yegorushkin

6 12

[serialization] warnings while building Boost.Serialization
by Christoph Ludwig 19 Oct '04

19 Oct '04

Hi, when building Boost.Serialization my compiler (gcc 3.4.2 on i686-pc-linux-gnu) issues some warnings. They are no big deal for me, but I think they can (and should) easiliy be avoided. * In wchar_from_mb.hpp, line 107, we have for(int i = 0; i++ < MB_CUR_MAX;){ //... On my system, MB_CUR_MAX evaluates to an expression of type size_t, whence the compiler warns about a comparison between signed and unsigned. I don't know which type MB_CUR_MAX is supposed to have according to the relevant standards, but I think it is safe to assume that the value of MB_CUR_MAX will always fit into a signed int. I therefore propose to change above line into: for(int i = 0; i++ < int(MB_CUR_MAX);){ //... * In basic_xml_archive, line 38, I get a warning about a potentially uninitialized variable msg: virtual const char *what( ) const throw( ) { const char *msg; switch(code){ case xml_archive_parsing_error: msg = "unrecognized XML syntax"; break; case xml_archive_tag_mismatch: msg = "XML start/end tag mismatch"; break; default: archive_exception::what(); // (*) } return msg; } I think the compiler caught a genuine mistake and the line marked (*) should read msg = archive_exception::what(); Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

1 1

[signals]
by Roland Schwarz 19 Oct '04

19 Oct '04

I wonder if it is possible to use the signal library to do interprocess/(synchronized)interthread calls. Would it be easily possible to extend it into this aerea if not already possible? Am I considering the wrong library? If yes, could anyone please suggest a better approach? Thanks, Roland

6 7

RE: [boost] Re: Library Proposal: database (boost::db)
by Brian Braatz 19 Oct '04

19 Oct '04

> On Behalf Of Michael van der Westhuizen > >> > >>Can you compae it with Database Template Library > >>http://dtemplatelib.sourceforge.net/index.htm > >>? > > > > > > Just an FYI here- I recently evaluated the DTL and it uses RTTI > > internally- > > Thoughts on OTL? > > http://otl.sourceforge.net/ > > I've used it a few times, and it's extremely capable. > > Michael Thanks for the link- that is very interesting. It looks like I can get what I need from it. IN rough comparison, it looks like the MYSQL++ library may be a bit more "normal" looking to DB developers who are used to disconnected recordsets, but it looks like the OTL libraries have far greater power. At the end of the day- I believe that a balance between "recordset"-ish model of MYSQL++ and the power of OTL would be a good combination. A library is not useful if it is too hard to get up to speed on OR too terribly different from what people are used to.

5 5

Serialization - building shared libs
by Neal Becker 19 Oct '04

19 Oct '04

I brought up the topic that int the current cvs serialization libs are only built static, not shared. The reason for this is that the library uses this construct: ,----[ /home/nbecker/stuff/A.hpp ] | // {{{ struct A | | struct A { | int i; | A() { i = 1; } | static const A instance; | }; | | // }}} | | extern const A A::instance = A(); `---- If this is included into 2 shared libraries, will A::instance be shared? I have tested this on Linux. If you dlopen 2 different shared libs, it will work correctly, if you set the flags RTLD_NOW|RTLD_GLOBAL. Since this will work correctly on some systems, I would like to see this supported. It is impossible to use serialization with boost::python without shared libs.

2 1

RE: [boost] Object Pool
by Abdullah Sowayan 18 Oct '04

18 Oct '04

Please ignore my prior question. I finally understood the whole process. Abdul -----Original Message----- From: Abdullah Sowayan Sent: Monday, October 18, 2004 11:53 AM To: boost(a)lists.boost.org Subject: [boost] Object Pool I am trying to use the Object Pool library. In the documentation I came across the following (html table): t.construct(???) ElementType * ElementType must have a constructor matching ???; the number of parameters given must not exceed what is supported through pool_construct <http://www.boost.org/libs/pool/doc/implementation/pool_construct.html> Allocates and initializes an object of type ElementType. If out of memory, returns 0. Amortized O(1). 1) What is "???" referring to? 2) What is I have the following class class A { public: A(int i, std::string s); ... }; How can I create a pool of As? Note that there isn't a constructor A::A( ) that takes nothing. How can I say that the pool for instance would initialize all objects to A::A(1, "Howdy") Thanks, Abdul _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re:Re: [boost] Sprit-1.6 and latest boost
by Robert Ramey 18 Oct '04

18 Oct '04

Joel de Guzman wrote: > And thank you too for fixing all apply_if's and stuff in all spirit > related libraries in the boost CVS. And thanks for doing the same for the serialization library! Robert Ramey

1 0

Object Pool
by Abdullah Sowayan 18 Oct '04

18 Oct '04

I am trying to use the Object Pool library. In the documentation I came across the following (html table): t.construct(???) ElementType * ElementType must have a constructor matching ???; the number of parameters given must not exceed what is supported through pool_construct <http://www.boost.org/libs/pool/doc/implementation/pool_construct.html> Allocates and initializes an object of type ElementType. If out of memory, returns 0. Amortized O(1). 1) What is "???" referring to? 2) What is I have the following class class A { public: A(int i, std::string s); ... }; How can I create a pool of As? Note that there isn't a constructor A::A( ) that takes nothing. How can I say that the pool for instance would initialize all objects to A::A(1, "Howdy") Thanks, Abdul

1 0

boost::shared_ptr interface
by David M. Jones 18 Oct '04

18 Oct '04

I ran into a situation (see my "smart list" post on the boost users group) where I wanted to create a custom allocator whose pointer typedef is boost::shared_ptr. In other words, the code would look something like: template <typename T> class my_allocator { public: typedef boost::shared_ptr<T> pointer; }; The problem with doing this is that boost::shared_ptr<T> does not have the same "interface" as the equalivalent raw pointer type T*. (I use the term interface in the generic programming/template sense; not in the object oriented sense.) One example is that there is no operator= on boost::shared_ptr that takes a raw pointer; instead reset() must be used. Here are my questions: (1) What advantage does this change of interface serve that makes it worth breaking potential operations such as that above? (2) Does anyone have ideas on how to get around this problem? I toyed with the idea of writing a class that derives from boost::shared_ptr and has the interface that I desire -- anybody have thoughts on this? Thanks, David M. Jones

3 4

explicit shared_ptr(weak_ptr<Y> const & r);
by John Torjo 18 Oct '04

18 Oct '04

Hi Peter, Just a thought: perhaps this constructor: explicit shared_ptr(weak_ptr<Y> const & r); should be private, and the only way to create a shared_ptr from a weak_ptr is: shared_ptr<T> val = weak->lock(); This way, the shared_ptr public constructors will never throw. Users will not make mistakes like this: shared_ptr<T> val = weak; I'm saying this, because I just made this mistake a few hours ago... After a while, the shared_ptr<> constructor started to throw at me ;) Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html

2 4

Re:[boost] Re: Re: Re: RTL status -"help wanted".
by Robert Ramey 18 Oct '04

18 Oct '04

FWIW - I love this idea !!!! I had forgotten about but when back and refreshed my memory. 1) its got nothing to do with being a wrapper to access a traditional database. That might be worthy project but this project isn't it. c) its all compile time. That means the the schemas can't be changed dynamically. This is inherent in the design. So its not a universal replacement for anything. However, I believe the time is now for such a library. Let me explain. Commmon use case. I am a freelance software developer. It often occurs that a customer has a situation which maps directly to a set of database schemas. The easiest way I've found to accomplish ths is (please - don't laugh) is to make a database in MS Access and write a VB program which peeks and pokes at it via ADO or something similar. This approach has the following features. a) Its simple to build and prototype the database. b) Its simple to fixit up when something changes. c) It eliminates a whole bunch of programming required to maintain data d) it eliminates a whole bunch of programming to query data. Just insert and test the query in Access. When it works, invoke the name of the query from VB - very easy. e) It depends on MS implementation of ADO which is very quirky in my opinion. f) It uses VB which will drive a real programmer crazy. g) Its all run time - no compile time optimization. h) Its all run time - no compile time checking. VB delays checking everything to the last possible moment - like when I'm home in bed. i) Its easy to make a nice UI that customer's love j) one doesn't have to worry about the size of things like history logs etc as its all handled by the DB. k) the data is accessible by other tools - basically and SQL query. So there is a class of applications which a) don't require that the schema changes after compilation b) need fast response c) use datasets of bounded size. Examples might be: a) address/contact manager for a palm computer/cell phone b) web database to support sales of tickets to grateful dead concerts as soon as they are announced. c) many small business databases - a years accounting. So I think this is interesting for what it is. I'm concerned that it might get bogged down by concerns that it isn't something else. In my view this sometimes occurs to boost proposals. I just looked over the documentation and I like what I see. Its no clear what's missing - of course I didn't try to use it. I think you might get more response to your request for help if. a) the directory structure and documentation looked more like a boost library so that one could just paste it into his boost tree. b) it was clear what's working and what's not. Maybe this should be reflected in the directory structure. c) If it was divided into working / not working. d) if the working subset was immediately useful. E.g. transactions could be postponed. It looks like you've focused on adding all the features before finishing off the basics ( documentation, examples, tests, etc.) This makes it hard for users to become addicted to your library which is what you need to get more help. The best way to get help is to get people using (part of) your library. When they need some feature, you can pressure them to create it and add a test. Machines and applications are now being made that can really benefit from the RTL library. Robert Ramey

3 2

Re:[boost] Sprit-1.6 and latest boost
by Robert Ramey 17 Oct '04

17 Oct '04

> Because bcc32 can't deal with spirit-1.8, to use spirit and boost 1.31, > I've replaced spirit.hpp and the spirit directory in boost with the 1.6 > distribution. > This doesn't work with the latest boost code, it looks like the errors are > due to the changes mpl that were mentioned. > Are there any plans to update spirit 1.6 to work with latest boost so > those of us with older compilers can use the two together? A very good question that I would also like to know the answer to. For the serialization library, all I had to do was to remove a superfluous "#include <boost/mpl/apply_if.hpp>" from one the spirit 1.6 header. This may or may not address your particular situation. I suspect that the serialization library is the only code in boost that depends on spirit so this may be all you need. More generally, as things stand now, anyone who downloads boost 1.32 and spirit 1.6.x in hopes of using the serialization library with his bcb, gcc 2.95, or msvc 6.x compiler will be disappointed to find that libraries won't build. I would like to see this rectified by an update to the spirit 1.6.x package. Could I encourage someone who has the proper access, authorization and understanding of what's involved to do this? Robert Ramey

1 0

Re: [boost] Sprit-1.6 and latest boost
by JOAQUIN LOPEZ MU?Z 17 Oct '04

17 Oct '04

----- Mensaje original ----- De: Russell Hind <rh_gmane(a)mac.com> Fecha: Domingo, Octubre 17, 2004 5:31 pm Asunto: [boost] Sprit-1.6 and latest boost > Because bcc32 can't deal with spirit-1.8, to use spirit and boost > 1.31, > I've replaced spirit.hpp and the spirit directory in boost with > the 1.6 > distribution. > > This doesn't work with the latest boost code, it looks like the > errors > are due to the changes mpl that were mentioned. > > Are there any plans to update spirit 1.6 to work with latest boost > so > those of us with older compilers can use the two together? > This has been discussed in connection with Boost.Serialization, which relies in Spirit 1.6 for older compilers. Apparently, all it takes to make Spirit 1.6 work under Boost 1.32 is to replace apply_if with eval_if. >From what the mailing list tell us, the fix was on the verge of being applied, but I guess it wasn't after all: http://lists.boost.org/MailArchives/boost/msg71227.php HTH Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Trial history file; CSS problem
by Daryle Walker 17 Oct '04

17 Oct '04

[I sent something like this on Saturday, but no one responded. So I'm resending in case it got rejected.] Instead of a mail attachment, the file is now in the Sandbox. Look under its "BOOST_ROOT/more/version_history.html" and pretend it's at the same relative spot in the main CVS. I'm surprised that a full-blown version history file wasn't added a long time ago. I raided the CVS history of the main "index.htm" file for the details. Any ancient-timers know the history of 1.11.0 and earlier? The header looks funny; I was wondering how to replicate the current look by mutating what's given with CSS. (I was thinking of the headers seen at <http://www.mozilla.org>.) I processed what I wrote through HTML-Tidy, adding indentation and line wrap. I kept getting weird spacing with the function descriptions at the Spirit section of 1.30.1 and the Lambda block-quote at 1.28.0. I worked-around the problem by undoing the line-breaks Tidy added at those points. After being bewildered for a long while about the weird spacing, I saw the problem when looking in the CSS file: CODE { FONT-FAMILY: Courier; white-space: pre; } This last (non-brace) line says that multiple white-space characters are _not_ collapsed into a single space. This lets CODE acts as an in-line variant of PRE, but it violates what CODE usually does! I need the default space-collapsing behavior of CODE. If no one can give me a justification for that attribute, I'm going to erase it. Even if you can justify it, do this instead: CODE.my_special { FONT-FAMILY: Courier; white-space: pre; } Then call it like so: Blah blah, please <code class="my_special">keep all of my spaces</code> blah blah. That way people who need the default space-collapsing attribute of CODE don't get screwed. (Right now it's optimizing the [IMO] <1% wacky case and forcing extra work to get the usual semantics [that should take 99+% of the cases].) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 3

Re: [boost] Re: [tuple] attempt to fix a BCB regression, and a plea for help
by JOAQUIN LOPEZ MU?Z 17 Oct '04

17 Oct '04

----- Mensaje original ----- De: Tobias Schwinger <tschwinger(a)neoscientists.org> Fecha: Domingo, Octubre 17, 2004 1:01 pm Asunto: [boost] Re: [tuple] attempt to fix a BCB regression,and a plea for help > JOAQUIN LOPEZ MU?Z wrote: > > Umm... This got me thinking, maybe the whole BCB-specific > > patch is just overkill, and it only takes to avoid > > the add_const<> construct. > > The attached file does just this, i.e. it relies on > > the default implementation for element<>, using > > plain const-qualifying instead of add_const<> for > > BCB. Would you be so kind to give it a try? Thanks in > > advance. > > > > This new version compiles fine with BCC 5.6.4 but does not compile > with > BCC 5.5.1 (and versions below this, according to Boost.Config). > > The patch is the difference from the file attached to the post I > reply > to (and not the first file you sent) and makes it work again. > > It uses the previous workaround in case > BOOST_NO_CV_SPECIALIZATIONS is set. > Another check for BCB within this block could be made in order to > use > 'add_const' for compilers where it works fine (I omitted it, for now). > > > Here's my (still fuzzy) problem analysis: > > 1. The "BCC <= 5.5.1 - problem" is that for these versions of BCC > cv-specializations don't work. > > 2. The "add_const - problem" could have something todo with the > fact > that for BCC 'type const' and 'const type' can be different types. > [ see the note regarding the '__BORLANDC__' - block in > 'is_const.hpp' ] As I understand it, the comment you refer to has to do with cv-qualifying references --not our problem now, I think. > I am not sure if and how this affects template argument > substitution, > but I changed > > typename T::head_type const > > to > > const typename T::head_type > > , just in case... > My only objection to your patch is that the problem with add_const is attributed to BOOST_BCB_PARTIAL_SPECIALIZATION_BUG Do you have any reason to think so? I'd prefer to have that part guarded by a simple __BORLANDC__ workaround, given our current (lack of) knowledge about what's causing the problem. If no one complains, I'll commit this stuff to the CVS tomorrow. Thanks everyboydy for your help. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

[preliminary submission] Is there any interest in an algebraic vector class?
by Debian User 17 Oct '04

17 Oct '04

Hi @, I've uploaded the initial version of the algebraic vector class as proposed in comp.lang.c++.moderated. It has been renamed to Euclidean vector class as a result of the discussions so far. Is there any interest here? Comments are welcome. The library is not yet in the boost name space and not yet under the boost licence. That's of course going to change if it eventually should be accepted. Andreas

2 1

Re: [boost] Re: [tuple] attempt to fix a BCB regression, and a plea for help
by JOAQUIN LOPEZ MU?Z 17 Oct '04

17 Oct '04

Hi Tobias, ----- Mensaje original ----- De: Tobias Schwinger <tschwinger(a)neoscientists.org> Fecha: Sábado, Octubre 16, 2004 10:24 pm Asunto: [boost] Re: [tuple] attempt to fix a BCB regression,and a plea for help > > Hi, > > the patch makes tupe_test_bench.cpp compile successfully on BCB > 5.5.1 > and 5.6.4. This is great news! Thanks for investigating. > > I have to add the disclaimer that it is an intuitive guess and may > not > be a real solution. I gave it a try, that's all ;+). > The code looked good before I touched it and I have honestly no > idea why > my adjustments make BCB behave again (for both changes)... > Umm... This got me thinking, maybe the whole BCB-specific patch is just overkill, and it only takes to avoid the add_const<> construct. The attached file does just this, i.e. it relies on the default implementation for element<>, using plain const-qualifying instead of add_const<> for BCB. Would you be so kind to give it a try? Thanks in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[boost] [tuple] attempt to fix a BCB regression, and a plea for help
by JOAQUIN LOPEZ MU?Z 17 Oct '04

17 Oct '04

Hello, A couple of days ago I prompted about the status of a supposed regression on tuple_test_bench (http://tinyurl.com/62plc) The attached file (to be replacing boost/tuple/detail/tuple_basic.hpp) is an (unsuccesful) attempt to fix the problem, which is related to the inability of BCB to cope with element<N,T> being specialized for T a const tuple type. AFAICS, the attached file should work (I've checked the workaround with other compilers), but BCB still doesn't like. Lacking the necessary BCB skills and tools, I'd appreciate if someone can take a look at it and, hopefully, turn it into a valid workaround for Borland. The relevant part is guarded by a "#if defined(__BORLANDC__)" directive. There are 14 regressions left in the main trunk, and if we all pull a little together, the long awaited Boost 1.32 release could be make real very soon. Thanks for the help. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 4

[Graph] New algorithms on graph_devel_1_33_0 branch
by Doug Gregor 16 Oct '04

16 Oct '04

I've just checked in some new graph algorithms that have been contributed to the BGL. They're on the branch graph_devel_1_33_0 until we've branched off the 1.32.0 release, at which point they will go into the trunk. The interesting algorithms are: - A* search, from Kristopher Beevers and Jufeng Peng - Floyd-Warshall all-pairs shortest paths, from Lauren Foutz and Scott Hill - Fruchterman-Reingold force-directed layout, from Doug Gregor The first two algorithms came out of David Musser's Generic Programming class at RPI. Consider that a challenge for any one else teaching courses in Generic Programming now or in the future: you know who you are :) I'll also be moving (sequential) code from the Parallel BGL project into CVS as soon as it becomes ready, and will batch up messages to list announcing the additions. All of the code has been written or reviewed by me, so you know where to direct comments and complaints :) Doug

2 2

Re: [boost] StringAlgo - (was: boost::tokenizer )
by Dirk Gregorius 16 Oct '04

16 Oct '04

Hi there, > I'm not very good at explaining the things in short, but I'll try. thanks for the explanation. I think I got it and it was not as bad as you maybe think. To come back to the initial problem of string tokenizing. I am trying to implement the finder in terms of ForwardIteratorT. Here is what I think I am expecting to do - also actually I am not very sure about it. I justed started to read M. Austern's book and I am quite new to concepts, requirements and so on. So here is what I did so far: struct comment_finder { template<typename ForwardIteratorT> boost::iterator_range<ForwardIteratorT> operator()( ForwardIteratorT Begin, ForwardIteratorT End ) { ForwardIteratorT first, last; while ( Begin != End ) { first = Begin; if ( *Begin++ == '/' && *Begin == '/' ) { last = first; while ( *last++ != '\n' ) { // FAILURE: Return an empty range if ( last == End ) return boost::make_range( ??, ?? ); // return an empty range - HOW? } // SUCCESS: Return the range return boost::make_range( first, last + 1 ); } } return boost::make_range( ??, ?? ); // return an empty range - HOW? } }; Is this the way I have to implement the finder or can it be implemented using some facilities in your library? This implementation is quite low-level, so I am wondering if this is correct. Secondly, for the case this is correct, how should I return an empty range or what shall I return if didn't find a matching range? What are the following steps? Do I have to split two time times or how do I erase the comments out of the string? Will the final token iterator be only of ForwardIteratorT or will be of the type of the conatiner that is holding the tokens. ( e.g. for a vector it would be a randow access iterator? ) Sorry for the inconvinience and thanks for the help so far. -Dirk

2 1

RE: [boost] Library Proposal: database (boost::db)
by Brian Braatz 16 Oct '04

16 Oct '04

> -----Original Message----- > On Behalf Of Jonathan Wakely > On Fri, Oct 15, 2004 at 10:56:58AM -0600, Brian Braatz wrote: > > > As a user I would like to see something along the lines of DTL \ Mysql++ > > > > http://dev.mysql.com/doc/plusplus/en/index.html > > As a user, maybe - but as a developer I wouldn't touch MySQL++ with > a ten foot pole. > > I'm the current maintainer of mysqlcppapi, which was forked from MySQL++ > to fix the most glaring errors, but I'd even hesitate to recommend > that! It is a vast improvement, but is still far from the quality I'd > expect from a Boost library. > > jon > [Brian Braatz] Please allow me to clarify; I am referring to the INTERFACE presented to the programmer. I had pretty good success taking people from a MS ADO world and using MYSql++. >From your web page: " Here are the major changes: All objects are classes with constructors and destructors, so all data is initialized. Reference-counting is used to allow sharing of the various object instances and underlying connections, avoiding segfaults or complicated memory management. All classes are in the mysqlcppapi namespace There is now no public member data. Many methods have been un-inlined, allowing a much clearer file structure. The 'custom' and stored query interfaces have been removed because they made excessive use of preprocessor macros and perl-generated code. Exceptions are no longer optional - they are part of the design. The fields classes have been completely replaced. " http://mysqlcppapi.sourceforge.net/ Excellent. The work you have done, I would agree with. What I am talking about is the basic interface of being able to do: (from the mysql examples) #include <iostream> #include <iomanip> #include <sqlplus.hh> int main() { Connection con("mysql_cpp_data"); // The full format for the Connection constructor is // Connection(cchar *db, cchar *host="", // cchar *user="", cchar *passwd="") // You may need to specify some of them if the database is not on // the local machine or you database username is not the same as your // login name, etc.. Query query = con.query(); // This creates a query object that is bound to con. query << "select * from stock"; // You can write to the query object like you would any other ostrem Result res = query.store(); // Query::store() executes the query and returns the results cout << "Query: " << query.preview() << endl; // Query::preview() simply returns a string with the current query // string in it. cout << "Records Found: " << res.size() << endl << endl; Row row; cout.setf(ios::left); cout << setw(17) << "Item" << setw(4) << "Num" << setw(7) << "Weight" << setw(7) << "Price" << "Date" << endl << endl; Result::iterator i; // The Result class has a read-only Random Access Iterator for (i = res.begin(); i != res.end(); i++) { row = *i; cout << setw(17) << row[0] << setw(4) << row[1] << setw(7) << row["weight"] // you can use either the index number or column name when // retrieving the colume data as demonstrated above. << setw(7) << row[3] << row[4] << endl; } return 0; } I like the fact that I have a table\recordset style structure (Result) I like the fact that it is iterator friendly I like the fact that the code above would be understandable from a person coming from an MS ADO world (which would lead to more adoption of the library)

2 1

file modes in boost cvs
by Neal Becker 16 Oct '04

16 Oct '04

I noticed that in boost cvs files seem to have random modes. Many sources show up as executable when checked out of cvs onto my Linux box. Hopefully this will be fixed before release.

4 3

boost::tokenizer
by Dirk Gregorius 16 Oct '04

16 Oct '04

Hi, I like to break a file into tokens for processing. The file contains comments which are introduced by "//", "#" and ";". Can I setup the tokenizer directly such that the comments are skipped? If no, what would you suggest to erase the comments from my string before processing? Here is what I do right now: // CODE ifstream is( "file.txt" ); string file, line; file.reserve( 2 * 1024 * 1024 ); while ( getline( is, line ) ) { TrimHead( line ); if ( line[0] != '/' && line[1] != '/' ) file.append( line + "\n" ); // Need to append "\n" again to get the right tokens - not very nice } typedef tokenizer<char_separator<char> > Tokenizer; char_separator<char> sep(" \t\n"); Tokenizer tokens( file, sep ); // END CODE Another idea was to the following: // CODE ifstream is( "file.txt" ); string line( ( istreambuf_iterator<char>( is ) ), istreambuf_iterator<char>() ); EraseComments( line ); // END CODE Any help is appreciated. -Dirk

3 2

Re:Re: [boost] Proposal for cleanup of INT64 macros
by Robert Ramey 16 Oct '04

16 Oct '04

> There seems to be a lot of confusion about these macros, so let me try and > give you the full lowdown: > BOOST_NO_INT64 > Indicates that boost::int64_t and boost_uint64_t do not exist in > boost/cstdint.hpp. It's a defect macro because these types are documented > as existing; it doesn't indicate a defect in the compiler, although if > we're being picky, neither these types nor *any* of the exact width types > in boost/cstdint.hpp are required to be supported by C99. If you need a > 64-bit integer type then this macro is the one to check (and then use > [u]int64_t). > Note these macros should only be used when overloading/specialising > for all intrinsic types, such usage should probably be infequent IMO. This is exactly my problem with polymorphic_(i/o)archive.hpp. Its an interface class that redirects save/load for all intrinsic types to the implementation in a derived class. Among the intrinsic types considered is long and int64 (long long is not considered - the name suggested a compiler dependent kludge). Currently I use BOOST_NO_INT64 but now I see that this fails on at least one machine where apparently int64 is a typedef or macro for long. In this environment I get a compile error because a rather than a function overload I get a compiler error with function redefinition. Before, I had a homemade BOOST_NO_INTRINSIC_INT64_T which seemed to work. What is the best thing to do in this situation? > The macros BOOST_NO_INTRINSIC_INT64_T and BOOST_NO_INTRINSIC_UINT64_T > appear to have been removed, so no cleanup necessary :-) :-( It seems that this is just what I need. I didn't realize it existed as I just depended on the information in the documentation and didn't look at the config.hpp file. Robert Ramey

2 1

Proposal for cleanup of INT64 macros
by Markus Schöpflin 16 Oct '04

16 Oct '04

Hello, currently we have a number of macros in boost which deal with whether INT64 support is available of not and in what form it is available. To my knowledge these are (in no particular order): - BOOST_NO_INTRINSIC_INT64_T, - BOOST_NO_INTRINSIC_UINT64_T, - BOOST_NO_INT64, - BOOST_HAS_MS_INT64, and - BOOST_NO_INTEGRAL_INT64_T. I propose to change these as follows. - BOOST_HAS_INT64_T - BOOST_HAS_INTEGRAL_INT64_T - BOOST_HAS_INTRINSIC_INT_64_T - BOOST_HAS_MS_INT64_T Where the following would hold: BOOST_HAS_INTRINSIC_INT_64_T => BOOST_HAS_INTEGRAL_INT64_T => BOOST_HAS_INT64_T. (I don't know where BOOST_HAS_MS_INT64_T would fit in above but I'm sure some MS expert will know.) The reasons for this proposal are: 1. I think the BOOST_NO_.. macros are misnamed. They don't describe a defect (INT64 support isn't mandated by the standard) but rather an extension. Therefore they should be named BOOST_HAS_... 2. Most uses of the above macros are #ifndef(BOOST_NO_INT64) or #ifndef(BOOST_NO_INTEGRAL_INT64_T) or the like. This double negation makes the use harder to understand than neccessary. 3. I think it is safe to assume that when an intrinsic INT64 type is available, the UINT64 type will be intrinsic, too. 4. If one currently wants to know wheter an integral INT64 type is available, the correct way to check is #if !(defined(BOOST_NO_INT64)) && !(defined(BOOST_NO_INTEGRAL_INT64_T)). This would be facilitated to #ifdef BOOST_HAS_INTEGRAL_INT64_T . Is there any interest in this proposal? Any comments and thoughts are welcome. Markus

3 9

Re:[boost] Re: Proposal for cleanup of INT64 macros
by Robert Ramey 15 Oct '04

15 Oct '04

>Tobias Schwinger wrote: >> Markus Schvpflin wrote: >> >>> currently we have a number of macros in boost which deal with whether >>> INT64 support is available of not and in what form it is available. >>> >>> To my knowledge these are (in no particular order): >>> >>> - BOOST_NO_INTRINSIC_INT64_T, >>> - BOOST_NO_INTRINSIC_UINT64_T, >>> - BOOST_NO_INT64, >>> - BOOST_HAS_MS_INT64, and >>> - BOOST_NO_INTEGRAL_INT64_T. >> >> What version of boost are you referring to ?? >> >> <snip> >> $ find /cvs/boost/boost/config -type f |xargs grep INTRINSIC |grep 64 >> $ # whoops - no 'INTRINSIC' and '64' at the same line in any config >> file $ # current state of the Boost main-CVS (head revision) <snap> >> >> Wishful thinking ? Well, I would like it, too ;+). >It was used in "boost/archive/polymorphic_[io]archive.hpp" but was removed >yesterday. Honestly. :-) LOL - I removed it yesterday. The cited file needs to know if int64 is an intrinsic type or a synonym for some other type - e.g. long on a 64 bit machine or ?. If it is, it will generate a compile error when the cited file is compiled. I would like to avoid this. For my purposes, if it were defined as a synonym for long long it would be ok so the above macros don't quite give me what I need in this instance. I'm still undecided what to do about this. I suppose the above proposal would work for me. I would use #if ! defined(BOOST_NO_INT64) && ! defined(BOOST_NO_INTRINSIC_INT64_T) virtual void load(int64_t & t) = 0; #endif >> I propose to change these as follows. >> >> - BOOST_HAS_INT64_T >> - BOOST_HAS_INTEGRAL_INT64_T >> - BOOST_HAS_INTRINSIC_INT_64_T >> - BOOST_HAS_MS_INT64_T >> I prefer sticking to the BOOST_NO... syntax. Yes it implies double negatives in some cases - but it means I don't have to remember which is negative and which is positive logic. (Foolish) consistency is a virtue Here. Robert Ramey

2 1

StringAlgo - (was: boost::tokenizer )
by Dirk Gregorius 15 Oct '04

15 Oct '04

> Boost.Tokenizer is currently not the only option for this > kind of job. There is also splitting facility incorporated > in the StringAlgo library. Thanks for the hint. This is something I really was looking for. When do you think will this code be in the official release ( I will download it now anyway )? > Note, that you will need to load whole file into a string before > processing, since all these facilities need at lease a forward > iterator, so streambuf_iterator is not sufficient. This is exactly what I do. ifstream is( "file.txt" ); string file_string( ( istreambuf_iterator<char>( is ) ), istreambuf_iterator<char>() ); This reads in the whole file into file_string in one step. A question regarding your design of this library. In your help file I read: "The library interface functions and classes are defined in namespace boost::algorithm, and they are lifted into namespace boost via using declaration" I try to use also more namespaces in my code. boost makes heavy use of namespaces as far as I can say this. Is it common style to have the implementation "deeper" in nested namespaces and "lift up" the interface again to the first level? How is this done? So you must use using declarations in the header files if I understand that correctly - which is a "NoNo" in a lot of books. I once used nested namespaces in my code, but found it very inconvinient to use, so I rewrote it, although it was logical very well grouped together. Can you give any design considerations / hints if I want to do the same? I found it very hard to find any discussions/papers regarding the proper use of namespaces. For me it seems as if namespace are only understood as facility to avoid nameclashes. In my opinion they also make the code more understandable and also allow some kind of abstraction by grouping logical dependent entities together. Best regards, -Dirk

2 1

RE: [boost] Re: Library Proposal: database (boost::db)
by Brian Braatz 15 Oct '04

15 Oct '04

> > "Tito Villalobos" wrote: > > > I have been working on a library for database programming. It currently > > wraps only ODBC API,... > > > Can you compae it with Database Template Library > http://dtemplatelib.sourceforge.net/index.htm > ? Just an FYI here- I recently evaluated the DTL and it uses RTTI internally-

3 2

RE: [boost] Library Proposal: database (boost::db)
by Brian Braatz 15 Oct '04

15 Oct '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jeff Garland > >...snip code... > > The one concern I have is that many db applications require runtime schema > discovery as well as data returns -- so I think the compile time approach > is > limited to a particular class of applications that can be fully specified > at > compile time. DTL has dynamic views and integrates well with STL > collections, > so at some level they are setting the standard on this currently. Another > interesting area of exploration for this would be integration with > boost.multi_index. > > > Would there be any interest in including this in boost? > > Yes, we really need a standard well thought out approach to accessing > databases in C++. > > Jeff I am currently going down this exact path and wanted to share what I ran into: 1- Boost does not have a 2dim "Table<>" - i.e. a Recordset 2- Boost.multi_index only works with concrete structures I would love it if I could use that to make a dynamic Table\ recordset 3- I have had to build my own Table<> by internally using boost.multiindex 4- Dtl is nice, however the thing that kicked me away from it is that it requires RTTI. This is a fact not clear in the documentation. It would be more than possible to do something along the lines of DRL and use boost.variant instead of having to resort to RTTI I believe boost is missing a "recordset" analolgy and I would hope that whatever is created is not "struct only" like boost.multi_index. (don't get me wrong I LOVE the multi_index - it just doesn't work dynamically) As a user I would like to see something along the lines of DTL \ Mysql++ http://dev.mysql.com/doc/plusplus/en/index.html It also sounds like you are thinking along the same lines (and we are working on similar things). I am more than happy to compare notes with you, either on this list or one -on-one if it is not-boost relevant, Thanks Brian Braatz

2 1

Re: [boost] Re: [multi_index] problem with gcc 3.4.2 for CompaqTru64UNIX
by JOAQUIN LOPEZ MU?Z 15 Oct '04

15 Oct '04

----- Mensaje original ----- De: Markus Schöpflin <markus.schoepflin(a)comsoft.de> Fecha: Viernes, Octubre 15, 2004 5:32 pm Asunto: [boost] Re: [multi_index] problem with gcc 3.4.2 for Compaq Tru64UNIX > Joaquín Mª López Muñoz wrote: > > > Markus Schöpflin ha escrito: > > >>The exact compiler switch removed was "-g". I will try to find > out whether > >>there is perhaps an updated assembler available which fixes the > problem. > > Please keep me informed if you make any progress. Thank you again. > > More on this... > > It's really not the fault of the system assembler that the file > cannot be > assembled by gcc in debug mode but the fault of mips-tfile which > is an > executable (first needed for MIPS, now only in use for Tru64, > hence the > name) which comes with gcc and is used to put the debug symbols > from the > assembler source into the object file _after_ the system assembler > has > created the object file. > > The length of the debug symbols mips-tfile can handle is limited > to 32768 > bytes. :-( There are some defines in the source code of mips- > tfile.c > (namely PAGE_SIZE and PAGE_USIZE) which look like they could be > used to > change that limitation but I'm not sure what else depends on these > constants. > I thought you might be interested in these findings. > They are very interesting indeed! Thank you for your efforts in clearing this out. Currently, this is what I wrote about the issue in the Boost.MultiIndex docs: http://tinyurl.com/43bfy I'll try to rewrite it according to your explanations. (If you feel like providing this paragraph to me, or even changing the doc in the CVS yourself, be my guest; I'm no Unix expert and much of this babble sounds like Greek to me.) As for the source code of mips-tfile.c, do you know if it is under control of the GCC folks? If so, maybe we can file a request that this issue be addressed in GCC 3.4.x. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Re: [multi_index] problem with gcc 3.4.2 for Compaq Tru64UNIX
by JOAQUIN LOPEZ MU?Z 15 Oct '04

15 Oct '04

----- Mensaje original ----- De: Markus Schöpflin <markus.schoepflin(a)comsoft.de> Fecha: Viernes, Octubre 8, 2004 5:04 pm Asunto: [boost] Re: [multi_index] problem with gcc 3.4.2 for Compaq Tru64 UNIX > Markus Schöpflin wrote: > > > Joaquín Mª López Muñoz wrote: > > > >> mips-tfile, /tmp//cctFjnCI.s:10965 string too big (35326 bytes) > >> line:? #.stabs?"and_<boost::mpl::not_<boost::is_same<boost::mpl: > >> [very long expression] > > > > A quick google search indicates that this is a problem with gcc > on alpha > > when compiling with debug symbols. A possible workaround might > be to use > > -gstabs instead of -g, I'll try it ASAP. > > I did some experiments and the only way to compile these files it > to > disable debug symbols completely. I have done that on the toolset > for gcc > used for the regression runs, I hope it helps to clean up some of > the errors. > Hi Markus, I see that the failures are gone, thank you! Would you be so kind as to explain to me which compiler options you touched to make this work? I'd like to add that information on the "Compiler specifics" section of Boost.MultiIndex docs. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

[filesystem] file size
by Stefan Slapeta 15 Oct '04

15 Oct '04

Is there any rationale behind the lack of a function that returns the file size of a directory entry? (or do I miss something?) Stefan

2 1

[Boost-bugs] [ boost-Bugs-1047775 ] object_protocol.hpp - setitem: void func cant return a value
by SourceForge.net 15 Oct '04

15 Oct '04

Bugs item #1047775, was opened at 2004-10-15 06:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1047775&group_… Category: Python Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: David Abrahams (david_abrahams) Summary: object_protocol.hpp - setitem: void func cant return a value Initial Comment: boost/python/object_protocol.hpp: template <class Key, class Value> void setitem(object const& target, Key const& key, Value const& value) { return setitem(target, object(key), object(value)); } won't compile on Tru64 Unix C++6.2 because of the return statement in a void function. Regards, Dario Cimafonte ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1047775&group_… ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

type_traits::is_polymorphic
by Richard Smith 15 Oct '04

15 Oct '04

Is there any chance that the virtual function boost::detail::is_polymorphic_imp1<T>::d2::foo defined in boost/type_traits/is_polymorphic.hpp could be renamed to have a name less likely to cause conflicts? I appreciate that the unique struct prevents this function from overriding any virtual functions in the base class, but it still has the potential to hide base class functions, which, at suitable warning levels in many compilers, causes a lengthy warning to be emitted. Although foo is unlikely to be a common function name in production code (well, good production code, anyway), it is the sort of name that is frequently found within unit tests and so forth. (For example, the name ``foo'' is used 2657 times in the gcc testsuite.) Cheers, Richard Smith

3 3

extending boost::io
by Israel Fdez. Cabrera 14 Oct '04

14 Oct '04

Hi, I'm working with the boost's IOStream library adding compression/decompression methods others than zip, gzip and bzip2. I'm working too adding support to OLE Compound Documents to the same library, I'd like to "extract" a containt OLE Document using boost::io stream interface. The problem is I'm not sure how to "return or extract" more than one document or compressed file from a stream. All boost examples boost::io::copy() a whole stream to another but not just part of it. I'll appreciate any help, best regards and thank you for such a helpful library Israel

3 7

[tuple] regression with borland-5_6_4
by Joaquín Mª López Muñoz 14 Oct '04

14 Oct '04

Hi, I've noted that tuple_test_bench is marked as a regression for BCB 564: http://tinyurl.com/62plc However, in the the following page listing Boost 1.31 issues, this test seems to appear as a failure: http://tinyurl.com/6j68r The problem seems to be related with BCB having a hard time with specializations on const types. So my questions are: 1. Is this really a regression or an expected failure as it seems to be present back in Boost 1.31? 2. Scanning the list, some folks claim that the problem goes away with BCB 5.6.4, yet what we have have does not indicate so. Anyone knows the status of this problem wrt to the version of the Borland compiler? 3. tuple already has an alternative implementation for those compilers without PTS, driven by BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION (line 26 of boost/tuple/tuple.hpp). Could someone with local access to the Borland compiler try to apply the alternative implementation by replacing that line with the following? #if defined(BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION)|| defined(BOOST_BCB_PARTIAL_SPECIALIZATION_BUG) (I don't know if BOOST_BCB_PARTIAL_SPECIALIZATION_BUG really relates to this particular problem, but its name fits perfectly well.) Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

BLL on a vector of tuples
by Brian Riis 14 Oct '04

14 Oct '04

Hi list, I have a situation where I need to find a tuple from a vector based on the value of one of the tuple's values. vector<tuple<string, int, int> > v; Basically I need the last int, and all I'm supplied is the first int. I thought of using lambda expressions for this, and dug into the documentation for that (so, this is my first real experience with BLL...and any lambda expressions for that matter). After some experimentation, I ended up with something akin to this. typedef boost::tuple<std::string, int, int> myTuple; std::vector<myTuple> v; ... using namespace boost::lambda; int id = <the value for the first int, that I need to find> std::vector<myTuple>::iterator iter = std::find_if(v.begin(), v.end(), (bind(&myTuple::get<1>, _1) == id)); My compiler (MinGW-3.4.2) gives me an error message on that last line: "error: cannot resolve overloaded function `get' based on conversion to type `SOCKET'" I'm sure it's trying to tell me where I've messed up, but I can really see it. (no doubt it's due to lack of experience with BLL, or lack of intelligence; quite possibly both :)) Am I totally out to sea here? If so, I'd be joyous if someone would light a beacon for me! :) TIA -- /Brian Riis

2 2

TR1 library extensions in libstdc++ - SmartPtr
by Jonathan Wakely 14 Oct '04

14 Oct '04

Hi, The libstdc++ developers are starting to implement the library extensions from TR1, including Boost-like smart ptrs, regex etc. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf I have volunteered to look into modifying the Boost smart pointers to match the TR1 specs and the libstdc++ coding standards. I realise I can modify the files and include them under the terms of the Boost licence, but the last Boost code to be used in libstdc++ (the concept checks) were licensed under the GPL. I believe that was something Jeremy Siek (as copyright holder) allowed specially: http://gcc.gnu.org/ml/libstdc++/2001-04/msg00050.html Would the SmartPtr authors (Peter, Greg, Beman, Daniel, Howard, Multi Media Ltd ...) consider allowing modified versions of shared_ptr.hpp, weak_ptr.hpp, shared_count.hpp and (maybe) checked_delete.hpp to be included in the GCC sources? It would probably require licensing them as GPL, which is where I imagine some people might have reservations. That wouldn't affect the copies in the Boost tree, of course. Allowing this would greatly speed up the process of adding TR1 features to libstdc++ and tracking the draft TR as it evolves. I am prepared to rewrite the smart pointers without using Boost code if necessary, but would obviously prefer not to, when the Boost implementations are the reference ones that were used for the TR1. I eagerly await responses, as whether I have to rewrite the classes or not will have quite an impact on my free time :-) jon -- "The following story is true. By which I mean false. It's all lies. But they're entertaining lies. And in the end, isn't that the real truth. The answer, is no." - Leonard Nimoy, in "The Simpsons"

9 23

bug in boost/date/time/date_parsing.hpp - wrong wchar_t -> char conversion
by Vyacheslav E. Andrejev 14 Oct '04

14 Oct '04

Hi there, I've found wrong usage of std::stringstream::narrow in date_parsing.hpp template<class date_type, class iterator_type> inline date_type from_stream_type(iterator_type& beg, iterator_type& end, wchar_t) { std::stringstream ss(""); while(beg != end) { ss << ss.narrow(*beg++, 'X'); // 'X' will cause exception to be thrown } return parse_date<date_type>(ss.str()); } In the code above ss.narrow does nothing, because the argument of narrow function already has type char, not wchar_t at all. I think, that the right code should be like this: template<class date_type, class iterator_type> inline date_type from_stream_type(iterator_type& beg, iterator_type& end, wchar_t) { std::stringstream ss(""); while(beg != end) { ss << std::use_facet<std::ctype<wchar_t> >(std::locale()).narrow(*beg++, 'X'); } return parse_date<date_type>(ss.str()); } -- ______________________________ Vyacheslav E. Andrejev System Architect, Excelsior, LLC E-mail: vandrejev(a)excelsior-usa.com ICQ: 7152604

1 0

bug in boost/date_time/time_system_split.hpp - wrong static_cast
by Vyacheslav E. Andrejev 14 Oct '04

14 Oct '04

Hi there I've found a minor bug in time_system_split.hpp. In the following code date_duration_type day_overflow(static_cast<int_type>(doff)); int_type is __int64 if BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG is on. But date_duration_type contructor expects int_adaptor<long> instead. So static_cast is useless here. I think, that right code should look like this: date_duration_type day_overflow(static_cast<date_duration_type::duration_rep_type>(doff)); Proposed patch's attached to this post. -- ______________________________ Vyacheslav E. Andrejev System Architect Excelsior, LLC E-mail: vandrejev(a)excelsior-usa.com ICQ: 7152604

1 0

Redmond Meeting
by Jonathan Turkanis 14 Oct '04

14 Oct '04

Hi All, I'd post this to comp.std.c++ but I'll be traveling soon and hope to get an answer faster here. I'll be in the Seattle area next week and hope to attend the standard committee meeting as a 'technical expert' (no giggling please). I don't see anything on the boost site (http://www.boost.org/more/cpp_committee_meetings.html) or the C++ Standard Committee site about registering advance for meetings. May I assume that it is not necessary? Jonathan

2 1

mpl apply_if.hpp question
by Robert Ramey 14 Oct '04

14 Oct '04

Would someone have a fit if something like this were added to boost/mpl ? Robert Ramey //-------------------------------------------------------------------------- --- // boost/mpl/apply_if.hpp header file // See http://www.boost.org for updates, documentation, and revision history. //-------------------------------------------------------------------------- --- // // Copyright (c) 2004 // Robert Ramey // // Permission to use, copy, modify, distribute and sell this software // and its documentation for any purpose is hereby granted without fee, // provided that the above copyright notice appears in all copies and // that both the copyright notice and this permission notice appear in // supporting documentation. No representations are made about the // suitability of this software for any purpose. It is provided "as is" // without express or implied warranty. // apply_if is deprecated. Use eval_if instead. This is only included // to support older code like spirit 1.6 #ifndef BOOST_MPL_APPLY_IF_HPP_INCLUDED #define BOOST_MPL_APPLY_IF_HPP_INCLUDED #include "boost/mpl/eval_if.hpp" namespace boost { namespace mpl { template< typename C , typename F1 , typename F2 > struct apply_if { typedef BOOST_DEDUCED_TYPENAME eval_if<C,F1,F2>::type type; }; // (almost) copy & paste in order to save one more // recursively nested template instantiation to user template< bool C , typename F1 , typename F2 > struct apply_if_c { typedef BOOST_DEDUCED_TYPENAME eval_if_c<C,F1,F2>::type type; }; } // namespace mpl } // namespace boost #endif // BOOST_MPL_APPLY_IF_HPP_INCLUDED

6 17

Proposed specialization of algorithm/minmax_element
by Robert Minsk 13 Oct '04

13 Oct '04

I would like to propose to specialize algorithm/minmax_element for random access iterators. The inner loop for a random access iterator would have one less compare and does not have the "potential_min" special case. I have included a sample implementation without all the support functions. template <typename RandomAccessIter, typename Compare> std::pair<RandomAccessIter, RandomAccessIter> basic_minmax_element(RandomAccessIter first, RandomAccessIter last, Compare comp, std::random_access_iterator_tag) { if (first == last) return std::make_pair(first, first); RandomAccessIter min(first), max(first), second(first + 1); // Even or odd number of elements if (std::distance(first, last) & 0x01) { // Odd - swap the first and second so first will equal last somewhere down // the line std::swap(first, second); } else { // Even - so treat first pair separately (only one comparison for first two // elements) if (comp(first, second)) max = second; else min = second; first += 2; } // Each element by pairs, with at most 3 comparison per pair while (first != last) { second += 2; if (comp(first, second)) { if (comp(first, min)) min = first; if (comp(max, second)) max = second; } else { if (comp(second, min)) min = second; if (comp(max, first)) max = first; } first += 2; } return std::make_pair(min, max); } template <typename Iter> std::pair<Iter, Iter> minmax_element(Iter first, Iter last) { typedef typename std::iterator_traits<Iter>::iterator_category IterType; return detail::basic_minmax_element(first, last, detail::less_over_iter<Iter>(), IterType()); } template <typename Iter, class _BinaryPred> std::pair<Iter, Iter> minmax_element(Iter first, Iter last, _BinaryPred comp) { typedef typename std::iterator_traits<Iter>::iterator_category IterType; return detail::basic_minmax_element(first, last, detail::binary_pred_over_iter<Iter, _BinaryPred>(comp), IterType()); }

1 0

Mpl Set
by Jaap Suter 13 Oct '04

13 Oct '04

Hi, I noticed that there is a boost/mpl/set directory with some files in them (CVS from circa one week ago). Is this work-in-progress or can I actually start using it in some way? Do you need any help in writing these? I'm in dire need for a compile time set. Regards, Jaap Suter

3 3

New Library Proposals
by Lemings, Eric B. 13 Oct '04

13 Oct '04

Hi, I'd like to solicit interest in the following brief proposals for inclusion in the Boost library. cla (Command-Line Arguments) - A generic C++ framework for parsing command-line arguments. The library design would be based on the popt (http://www.rpm.org/dark_corners/popt/) library. uom (Units Of Measure) - A generic C++ framework for arithmetic calculations and conversions between different units of measure. The library design would be based on The Units Of Measure Library (http://tuoml.sourceforge.net/) Questions and comments welcomed. Thanks, Eric.

7 6

[array] bug, interface change and more
by Joao Abecasis 13 Oct '04

13 Oct '04

Hi all! 1) I want to report that array::at throws range_error when it should throw out_of_range to comply to Sequence requirements. After I decided to report this issue I learned that Nicolai Josuttis maintains a parallel version boost/array.hpp on his website that corrects this and has a few other changes. Namely, an overload for 0-sized arrays was added and c_array has been renamed to data. I believe these changes were made after discussion for proposed inclusion in TR1. 2) Now I'm wondering if c_array should be renamed to data before the next release, to avoid having to change the interface later. 3) Could get<Index> functions be added to array, in order to mimick tuple? There are probably other things that can be done to make boost::array behave like a tuple. I think array could also be considered for inclusion in fusion. 4) On a side note, I wrote an initialized_array class that is very much like array but provides the constructors (and thus cannot provide aggregate initialization syntax): * default element construction * default array construction (boost::array provides this) * initialized_array<T, N>(T const & val) // elements initialized to val * initialized_array<T, N>(T const (&vals)[ N2 ]) // elements initialized with array. If N2 < N remaining elements are default constructed * initialized_array<T, N>(InputIterator start, InputIterator finish) // similar to previous but with iterators Exception behaviour is the same as for arrays (accomplished with a linear hierarchy of base classes) and each element is initialized exactly once (except with default array construction). Is there any interest in this class? br, João Abecasis

2 1

signals: vc7.1 warning in named_slot_map.hpp
by Eric Niebler 13 Oct '04

13 Oct '04

This is actually an error for me since I have "warnings as errors" turned on. For the Dinkumware lib, type_info::operator== and operator!= return int instead of bool. This causes problems with the any_bridge_compare class in named_slot_map.hpp template<typename Compare, typename Key> class any_bridge_compare { ... bool operator()(const any& k1, const any& k2) const { if (k1.type() == typeid(front_type)) return k2.type() != typeid(front_type); -------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This results in warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning) I recommend changing the line in question to: return !(k2.type() == typeid(front_type)); -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

Need more Boost.Build files for CodeWarrior?
by Daryle Walker 13 Oct '04

13 Oct '04

I noticed that there are *.jam files for CodeWarrior 8.3, 9.2, and 9.3. I also noticed that there are separate *.jam files for the Linux and Windows-32 versions of Intel's compiler. But CodeWarrior also comes for multiple platforms (Windows and Mac). Shouldn't the CodeWarrior *.jam files be split up as well? (Unless we're certain that CW reacts exactly the same way for the two platforms.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

Re: [boost] Re: [Poll] New look-n-feel for Boost documentation
by brangdon＠cix.compulink.co.uk 13 Oct '04

13 Oct '04

In-Reply-To: <415CBB84.1050608(a)boost-consulting.com> joel(a)boost-consulting.com (Joel) wrote (abridged): > <http://tinyurl.com/5emyz> > > Serif or sans serif? > For continuous reading in print, serif fonts are generally more > readable than sans serif. However, on the web, the opposite is true. > Serifs are tiny, subtle strokes which, on screen in a small size, > become a rather crude series of little square bitmaps. Their absence > makes the font more readable. On my 1280x1024 desktop machine, the serif on the middle bar of my default Times New Roman 'F' is drawn with 12 pixels and 4 different colours. Maybe the studies you cite were done before anti-aliasing was common? Regardless, I think it should be up to the user. -- Dave Harris, Nottingham, UK

3 2

[scoped_ptr] Invalid example in the documentation.
by Jurko Gospodneti� 13 Oct '04

13 Oct '04

Hi all. The example at the bottom of http://www.boost.org/libs/smart_ptr/scoped_ptr.htm specifies void as the return type for main() which is not valid C++. Could someone please fix this? Thanks, Jurko Gospodnetiæ

1 0

[filesystem] Failures on FAT32
by Stefan Slapeta 12 Oct '04

12 Oct '04

Hi all, there are two failures reported for the intel-win32-8.1 toolset (both in operations_test): http://tinyurl.com/5dbla After some investigation I've found out now that the tests fail only because they are run on a FAT32 disk! It was just coincidence that the failures popped up in the Intel 8.1 tests (...and it's quite amusing to say that we would need another toolset dimension for the filesystem :) ) Anyway, here some analysis (the second failure seems to be a general design problem!): First failure: operations_test.cpp(287): test time_diff >= 0.0 && time_diff < 60.0 failed --> the actual difference is -2! Second failure: std::exception: boost::filesystem::last_write_time ("wrong parameter") last_write_time contains this code: ::utimbuf buf; buf.actime = std::time_t(); ^^^^^^^^^^^^^ buf.modtime = new_time; This means that the last access (!) time is set to 1970-01-01-... when the last write time is changed by this call! IMO that's absolutely incorrect because it's a side effect which I'm sure the user wouldn't expect to happen! Furthermore - a nice coincidence again - it seems not to be allowed to set this early access time for FAT32. I didn't investigate too much, but what I can say for sure is that it works to set an access time of this year, but not for 1970 (-> results in an error "wrong parameter"). Stefan

3 5

as_sequence<R(T0,T1)> ?
by Alexander Nasonov 12 Oct '04

12 Oct '04

I have one addition to '[type_traits] "member_function_pointer_traits" ?' thread started long time ago (29 Jul 2004) by Tobias Schwinger. Is it makes sense to modify as_sequence to convert function type into a sequence? Eg: as_sequence<R (T0,T1)> ---> vector<R,T0,T1> as_sequence<R(*)(T0,T1)> ---> vector<R,T0,T1> as_sequence<R(&)(T0,T1)> ---> vector<R,T0,T1> as_sequence<R(C::*)(T0,T1)> ---> vector<R,C,T0,T1> -- Alexander Nasonov

5 16

Boost.Build V2 link on top-level page?
by Vladimir Prus 12 Oct '04

12 Oct '04

Are there any objection to my adding Boost.Build V2 link (http://boost.org/boost-build2) to the top-level "index.htm", under "Official branch sites", using the patch below? - Volodya

2 3

Review of Daryle Walker's "More IO" library begins today, August 21, 2004.
by tom brinkman 12 Oct '04

12 Oct '04

The review of Daryle Walker's "More IO" library begins today, August 21, 2004. Download: http://groups.yahoo.com/group/boost/files/more_io_4.zip [or] http://boost-sandbox.sourceforge.net/more_io_4.zip Description: Provides a multitude of I/O-oriented extensions. Some are extra manipulators; variants of "std::endl", a resetting manipulator, and a configurable manipulator. The library includes a set of base class templates for wrapping a new stream-buffer type around a stream class. Changes from the last interim version (called "more_io_3b.zip"): * split the manipulator header into several headers * refined the license statements in some already-affected files Changes from the first formal review (called "more_io.zip"): * refined the interface and implementation of array-streams and stream-buffer wrappers (including a wrapping example) * added the null-stream, value-stream, and pointer-stream headers * added generalizations to the new-line and skip-line manipulators * added the non-oriented 'reset' and 'form' manipulators * split the manipulator header into several headers * changed the license statements Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And finally, every review should answer this question: Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. For information about submitting a Formal Review, see http://www.boost.org/more/formal_review_process.htm The Review manager is: Tom Brinkman reportbase(a)yahoo.com

9 56

matching algorithm
by Gunnar W. Klau 12 Oct '04

12 Oct '04

Hello, does anybody know whether there's an implementation to compute (maximum weight) matchings in general graphs? Thanks for any help, --gunnar--

2 1

Re: [boost] Re: [review] Formal review of
by brangdon＠cix.compulink.co.uk 12 Oct '04

12 Oct '04

In-Reply-To: <loom.20041011T172801-139(a)post.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > If there is no null in the tree, then why test for it? The test is to prevent moving a null dog to the tree. > I suspect having null is reasonable, but I explicitly requested to see > the code. There is no real code; the example was invented to illustrate the importance of post-conditions. Which is another way of putting what it says in the .pdf file you referenced: the Null Object pattern is not universally applicable. The point is general and not about the specific code. Are you claiming that Null Object is, in fact, applicable in every situation? If not, just imagine I picked an example where you agree its not applicable. If, on the other hand, you believe no such example is possible, then you surprise me. Regardless I don't think further discussion is appropriate here, because it is not crucial to the Smart Container proposal. As I said in my original message: ... this is no more an argument against ptr_vector<Dog> than it is against std::vector<Dog>. In saying that I was supporting your proposed library. Given that ptr_vector<T> behaves more like vector<T> than vector<T*>, the restriction on NULLs is logical and reasonable. -- Dave Harris, Nottingham, UK

1 0

[lambda] cw83-release vs. cw83-debug failures...
by Rene Rivera 12 Oct '04

12 Oct '04

I became a bit curious as to why two Lambda tests fail in the only release configuration for CW8.3, but don't fail in the debug tests. As seen in: http://www.meta-comm.com/engineering/boost-regression/developer/lambda.html And the really strange part is the lack of information from Boost.Test about it. It only outputs: Run output [2004-10-11 02:46:48 UTC]: **** no errors detected EXIT STATUS: 1 Which seems like a rather contradictory statement from the test system I don't really know what is going on here. But I've narrowed it down to some strange interaction when the "--" and "++" pre-ops are used. If I make the following changes the tests pass... Index: bind_tests_advanced.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/lambda/test/bind_tests_advanced.cpp,v retrieving revision 1.8 diff -u -r1.8 bind_tests_advanced.cpp --- bind_tests_advanced.cpp 27 Jul 2004 03:43:33 -0000 1.8 +++ bind_tests_advanced.cpp 12 Oct 2004 03:02:38 -0000 @@ -110,7 +110,7 @@ int i = 1; BOOST_TEST(unlambda(_1 + _2)(i, i) == 2); - BOOST_TEST(unlambda(++var(i))() == 2); + { bool t = unlambda(++var(i))() == 2; BOOST_TEST(t); } BOOST_TEST(call_with_100(_1 + 1) == 101); Index: operator_tests_simple.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/lambda/test/operator_tests_simple.cpp,v retrieving revision 1.8 diff -u -r1.8 operator_tests_simple.cpp --- operator_tests_simple.cpp 27 Jul 2004 03:43:33 -0000 1.8 +++ operator_tests_simple.cpp 12 Oct 2004 03:02:38 -0000 @@ -175,11 +175,11 @@ BOOST_TEST(i == -1); i = 0; - BOOST_TEST((++_1)(i) == 1); + { bool t = (++_1)(i) == 1; BOOST_TEST(t); } BOOST_TEST(i == 1); i = 0; - BOOST_TEST((--_1)(i) == -1); + { bool t = (--_1)(i) == -1; BOOST_TEST(t); } BOOST_TEST(i == -1); i = 0; =================================================================== Any ideas, clues, etc. ?? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

[ANN] Boost testing mailing list
by Misha Bergal 12 Oct '04

12 Oct '04

The boost-testing mailing list is now operational: The setup, procedures and tools necessary for running Boost regression tests are discussed on this list. The list main participants are regression runners - people who run Boost tests on a variety of compilers and platforms, and the maintainers of tools for collecting and processing test results. Important: questions relevant to a wider audience, including questions about Boost.Test framework or test results for a particular library, should be posted to main development list. You can subscribe to the list at http://lists.boost.org/mailman/listinfo.cgi/boost-testing. -- Misha Bergal MetaCommunications Engineering

3 4

filesystem::is_directory return true when exception is disabled and this directory does't exist
by Liao Weijie 12 Oct '04

12 Oct '04

// the snip of code in filesystem::is_directory begin--- DWORD attributes = ::GetFileAttributesA( ph.native_directory_string().c_str() ); if ( attributes == 0xFFFFFFFF ) boost::throw_exception( filesystem_error( "boost::filesystem::is_directory", ph, fs::detail::system_error_code() ) ); return (attributes & FILE_ATTRIBUTE_DIRECTORY) != 0; //-------------------------------------------------------end-- When GetFileAttributesA failed but the exception is disabled, the (attributes & FILE_ATTRIBUTE_DIRECTORY) will always be true. Is it a bug?

4 4

Suggestion for multi_array query information
by Anders Edin 11 Oct '04

11 Oct '04

Hello, I have a short suggestion about the interface for multi_array. It is possible to query a multi_array<T,N> for information about the storage: // queries ... const size_type* shape() const; const index* strides() const; const index* index_bases() const; ... It appears multi_array uses a boost::array internally to store this information, and uses the data() method to return a pointer in the above methods. Wouldn't it be better to return a reference to the array directly: // queries ... const array<size_type, N>& shape() const; const array<index, N>& strides() const; const array<index, N>& index_bases() const; ... With this interface the information about the number of elements of shapes and strides is not lost during the query. -- Anders Edin, Sidec Technologies AB Fogdevreten 2A, 171 77 Stockholm, Sweden Phone: +46850884525, Fax: +46850884522

2 1

Boost.String Algorithms patch
by Daniel Schlyder 11 Oct '04

11 Oct '04

The attached patch fixes invalid #include in boost/algorithm/string_regex.hpp and unused parameter warnings in boost/algorithm/string/formatter.hpp boost/algorithm/string/detail/find_format.hpp -- Daniel Schlyder http://bitblaze.com/

2 1

MPL - mpl::sequence to std::sequence
by Jaap Suter 11 Oct '04

11 Oct '04

Hi, what is the easiest way to convert an mpl::sequence to an std::sequence? I'm using such conversions a lot when unit-testing meta-code. I just wrote two versions of algorithms, a compile-time and the runtime one, and then compare their outputs. I recall hearing something about mpl::for_each having defined an operator () for runtime purposes, but the details don't seem to be documented anywhere. I came up with the attached code, of which the "to_compile_time" might actually be of general interest. It's a function that converts a runtime integer to a compile time integer. Code-generation-wise it's a horror and it could be more generic, but it gets the job done for me. I'd like to hear if there are more elegant solutions for this though, as it seems like too much code. Thanks, Jaap Suter

5 11

Preprocessor headers docs
by Aleksey Gurtovoy 11 Oct '04

11 Oct '04

Paul, Are these (from http://tinyurl.com/4hp7d) automatically generated: libs/preprocessor/doc/headers/arithmetic.hpp.html: filename contains more than one dot character ('.') libs/preprocessor/doc/headers/arithmetic/add.hpp.html: filename contains more than one dot character ('.') libs/preprocessor/doc/headers/arithmetic/dec.hpp.html: filename contains more than one dot character ('.') libs/preprocessor/doc/headers/arithmetic/div.hpp.html: filename contains more than one dot character ('.') libs/preprocessor/doc/headers/arithmetic/inc.hpp.html: filename contains more than one dot character ('.') libs/preprocessor/doc/headers/arithmetic/mod.hpp.html: filename contains more than one dot character ('.') libs/preprocessor/doc/headers/arithmetic/mul.hpp.html: filename contains more than one dot character ('.') libs/preprocessor/doc/headers/arithmetic/sub.hpp.html: filename contains more than one dot character ('.') ... ? If so, can we adopt a convention that doesn't involve multiple dots [1] and re-generate them? [1] E.g. "libs/preprocessor/doc/headers/arithmetic/add_hpp.html", or even, since these are in their own subdirectory anyway ("headers"), plain "libs/preprocessor/doc/headers/arithmetic/add.html". -- Aleksey Gurtovoy MetaCommunications Engineering

1 1

uBLAS results for vc7.1 too good to be true?
by Bronek Kozicki 11 Oct '04

11 Oct '04

http://www.meta-comm.com/engineering/boost-regression/developer/numeric-ubl… (http://tinyurl.com/3vmlv ) Almost all results for vc7.1 are marked "unexpected success". I think this compiler is around for enough long time to mark these results as "just expected" success? B.

3 2

[ross@biostat.ucsf.edu: Re: Formal Review of the Smart Containers library]
by Pavol Droba 11 Oct '04

11 Oct '04

Hi, this is the review from Ross Boylan. He is not subscribed to the list, but his review is very insightful, so I'm forwarding it here. Regards, Pavol ----- Forwarded message from Ross Boylan <ross(a)biostat.ucsf.edu> ----- Date: Tue, 05 Oct 2004 17:19:03 -0700 From: Ross Boylan <ross(a)biostat.ucsf.edu> Subject: Re: Formal Review of the Smart Containers library To: Pavol Droba <droba(a)topmail.sk>, boost(a)lists.boost.org Cc: ross(a)biostat.ucsf.edu X-Mailer: Ximian Evolution 1.4.6 [I am not subscribed to the boost developers' list, so I'm not sure if this message will appear there.] My review is from a non-expert user perspective. Overall, I think the library should be accepted, though I have some suggested tweaks and improvements. I am also unable to get a program using the library to compile, and that definitely should be fixed if I haven't made a silly mistake. There is one substantive area (incompatibility with some standard algorithms) that is a bit worrisome to me, and merits thought by someone wiser. I used the library (ptr_vector, ptr_set, ptr_map, including nested ptr_maps) in a pre-release form in my application. There were some minor compilation issues with that version, which I worked around, and which I assume Thorsten has fixed. My main motivations for using the library were that I was looking for a way to hide the implementation decision of whether I had containers of objects or pointers, and I had objects that were not copyable (and would have been expensive to copy). Even at that early stage, I found the documentation quite complete and extensive. The library was easy to use, and it worked. COMPILATION TROUBLES I got the version of the code in the review notice, and adjusted my code to use it (some directory names changed). I got a raft of errors, attached. I spent about 15 minutes looking into the first one, and have no immediate explanation for it. I verified that my boost 1.31 libraries have a remove_pointer.hpp file under type_traits. g++ (GCC) 3.3.4 (Debian 1:3.3.4-7) boost 1.31.0-7 Under Debian GNU/Linux. The packages on the system are mostly at the "testing" level, which is slated to become the next release when it's fully cooked. STANDARD REVIEW QUESTIONS I have not studied the design and implementation in any detail, and so have no comments on them. Actually, some of my comments on the documentation really bear on the design. My major concern is that some algorithms are not safe to use on these containers. It is not clear to me that the average user can tell exactly which algorithms there are. If the latter is true, and there is any way to remedy it, it would be very good to do so. I think if this risky area is properly documented, it will be an acceptable risk. I favor a design with maximum compatibility with existing standard containers; it seems to me that has been achieved. The documentation is extensive and quite good. I have many comments, which I will give below. The only point I consider really significant is that some of the reference material is a bit hard to navigate (I actually found the earlier version I looked at a bit clearer in this regard). The library seems quite useful to me, though I'm biased since I needed it :) But it seems to me the features of the library are of pretty broad interest, and they address issues likely to be handled with ad-hoc, partial hacks without the library. I think the current introduction could give more emphasis two significant advantages of the library. First, it can do things that aren't easily done at all with other methods, such as smart pointers. Second, it is conceptually very simple, and provides a very nice abstraction. (Both of these things are discussed early on; this is just a question of emphasis). I did try to use the library, both an earlier version and the current review version. See results discussed at the top of this note. I've spent around a day, maybe more, using the library, studying the docs, and writing this review. As noted at the outset, I only went into the implementation details when I needed to figure out how something worked or debug a problem. Offsetting this signficant amout of time is my non-expertise in these matters! I am fairly knowledgeable as a consumer of standard library containers. I am not so knowledgeable about writing template libraries. I usually proceed in blissful ignorance of the exception safety issues that concerned the author. As noted at the start, I think overall the library should be accepted, after assuring the compilation issues are worked out. You might consider some of the documentation issues. I would also recommend those with greater expertise consider the implications and possible solutions to the breakage of some standard algorithms. DETAILED DOCUMENTATION COMMENTS Here are my comments while reading through the documentation, including answers to some of the issues raised for reviewers in the documentation. I have prefaced individual points with *, and ** for more important ones. file:/usr/local/src/boost/boost/libs/smart_container/doc/smart_container.html *The date at the top lacks a year. * Might be useful to break this page into several distinct pages. * At the very beginning, it might be worth saying that the containers of smart pointers don't work at all if the objects are not Assignable or Copy Constructible. This is mentioned a few paragraphs down, but someone reading the description quickly might think the only benefit of the library is that it offers a more optimal solution to some problems. In fact, it lets you do things you couldn't otherwise do (easily). In case you can't tell, this was a major reason I used the library. * Reference to polymorphic class problem is puzzling in two ways. First, the section on the problem does not seem to state the problem directly (apparently it is how to ensure proper clean up of objects when we refer to them with pointers to a base class; perhaps it is also the fact that one can't have a list of such types directly, but need to use pointers). I had not heard of the problem and it doesn't seem like such a problem. Second, it's not clear to me what smart containers add to this particular problem, given that smart pointers are available. It is true that this library does offer one solution to the problem (if I have understood it correctly). Perhaps if the introduction that now says "In this respect the library is intended to solve the so-called polymorphic class problem." said "The library also offers a solution to the so-called polymorphic class problem." It would be clearer. * Calling this the "smart container" library and then using names like "ptr_xxx" seems an invitation to confusion. "smart_xxx" would be more natural. At this point, it may be too much trouble and possibility for error to change the names, even if you agree with this point. * In the first example, in English the sound of a cow is usually rendered as "Moooh!". * Still in that example, the use of "stable" got me thinking about stable vs unstable. In particular a "stable_type" is not a polymorphic type. I wasn't actually confused, and probably no one else will be, but it did generate a little cognitive interference. You might use "barn" instead of "stable". * do we want the tricky algorithms implemented as members? Not clear to me if to_remove in example 8 is supposed to be something in the container, or if it just needs to be equivalent (I assume the latter, by analogy with existing stuff in the standard library). Will incorrect semantics or errors result from naive use of the corresponding non-member operators? Apparently so, according to later discussion. ** I found it a bit difficult to find reference information. First, the material requires a fair number of clicks to reach. Second, it was not clear to me where to look for information that was not in a given entry. There are several reasons for this. The "see also" heading mixes material you must look at (base classes and pseudo-base classes such as reversible_smart_container) and classes that are simply related (e.g. ptr_vector and ptr_array). So it took me awhile to find the definition for auto_type used in, e.g., ptr_array. If you could distinguish inheritance relations from others, that would be good. I'm sure part of the problem is that some of the material is only a conceptual inheritance, but still it would be useful to know that, for example, ptr_vector has the protocols of ptr_sequence_adapter, which in turn has the protocols of reversible_smart_container. Also, there are notations like "Exception safety: strong guarantee". A link or further explanation would be useful for those who aren't familiar with these terms. * The first FAQ item probably saved me a lot of grief. ** The unsafe mutating algorithms, in the FAQ now, probably deserves more prominence, in a discussion (in the main documentation) of what algorithms are appropriate to use with these containers. This item makes me nervous. First, it sounds as if only an implementor of a library would know which algorithms actually moved things around by swapping. This leaves the average user unsure of which algorithms are safe. Second, it seems like asking for trouble for it to be so easy to cause problems. * FAQ on inserting member function overloading for pointer and reference. Reviewer Q: do we want this behavior? I would say definitely, as it reduces the chances for user error. * Acknowledgements: perhaps "crappy" lacks the elevated tone we seek? And, though I assume it's a good-natured jest, some might take it the wrong way. Review Issues: 4. Is the indirected predicates the right solution? It was exactly what I was looking for, so I'm inclined to say yes :) 5. Should SmartContainer::auto_type expose itself as a move_ptr? Probably; the current name seems derived from the way it's implemented (auto_ptr, I assume). But if it has auto_ptr semantics, and it's important for the user to be aware of those, it's probably best to leave it as is. 6. Should iterator range versions of assign() and insert be replaced by an Boost.Range version? Ie, should we have template< class SinglePassRange > void insert( const Range& r ); instead of template< class InputIterator > void insert( InputIterator f, InputIterator l ); ?? The more this class can behave like any std::container, the better. So I'd lean toward leaving it as is. However, if the Boost.Range thing is compatible (I'm not familar with it), this argument loses force. 7. Should we remove rbegin()/rend()? Boost.Range makes these unnecessary. Same as 6. 8. Should we add const_begin()/const_end() etc to the classes. Again, Boost.Range means we don't need to define them. As these are not in the standard, I don't think adding them is important. In fact, one could argue that adding things not in other containers may confuse users, if they think that learning the interface for one container class gives them protocols they can transfer to others. In plainer language, if this library provided const_begin, people might assume std::vector did as well. 9. Should we add iterators for traversing the keys of a map? This would mean we could say map::key_iterator b = m.begin(), e = m.end(); copy( b, e, some_where ); That would be useful. 10. should transfer() return iterator or iterator/bool pair like erase()/insert() do. I vote for returning an iterator to the start of the inserted sequence, and throwing exceptions if things go wrong. 11. should a templated map::insert() be defined: template< class Convertible2Key > void insert( Convertible2Key&, T* r ); ? This would allow usage like m.insert( "foo", new Foo ); Probably not. It might create unintended conversions, and it's probably better to leave it the client if they want this kind of behavior. 12. should we provide member algorithms for unsafe standard algorithms like unique() and remove? Yes. 13. Is the shared_ptr idea described in future directions a good idea? I'm not sure I grasp the concept well enough to comment, but it seems to me it kind of muddies the waters. That is, shared pointers are a different kind of ownership concept than this library, and I suspect it will be cleaner to keep them separate. I mean, mostly, cleaner for users. -- Ross Boylan wk: (415) 502-4031 530 Parnassus Avenue (Library) rm 115-4 ross(a)biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 476-9856 University of California, San Francisco San Francisco, CA 94143-0840 hm: (415) 550-1062 make[1]: Entering directory `/home/ross/peter/R/mspath/src/debugTest' g++ -I /home/ross/peter/R/mspath/src -I/usr/lib/R/include -MMD -MF /home/ross/peter/R/mspath/src/depends/Path.d -MP -g -O0 -c -o Path.o /home/ross/peter/R/mspath/src/trueSrc/Path.cc g++ -I /home/ross/peter/R/mspath/src -I/usr/lib/R/include -MMD -MF /home/ross/peter/R/mspath/src/depends/PathGenerator.d -MP -g -O0 -c -o PathGenerator.o /home/ross/peter/R/mspath/src/trueSrc/PathGenerator.cc g++ -I /home/ross/peter/R/mspath/src -I/usr/lib/R/include -MMD -MF /home/ross/peter/R/mspath/src/depends/SimpleRecorder.d -MP -g -O0 -c -o SimpleRecorder.o /home/ross/peter/R/mspath/src/trueSrc/SimpleRecorder.cc g++ -I /home/ross/peter/R/mspath/src -I/usr/lib/R/include -MMD -MF /home/ross/peter/R/mspath/src/depends/SuccessorGenerator.d -MP -g -O0 -c -o SuccessorGenerator.o /home/ross/peter/R/mspath/src/trueSrc/SuccessorGenerator.cc g++ -I /home/ross/peter/R/mspath/src -I/usr/lib/R/include -MMD -MF /home/ross/peter/R/mspath/src/depends/StateTimeClassifier.d -MP -g -O0 -c -o StateTimeClassifier.o /home/ross/peter/R/mspath/src/trueSrc/StateTimeClassifier.cc g++ -I /home/ross/peter/R/mspath/src -I/usr/lib/R/include -MMD -MF /home/ross/peter/R/mspath/src/depends/TestRecorder.d -MP -g -O0 -c -o TestRecorder.o /home/ross/peter/R/mspath/src/trueSrc/TestRecorder.cc In file included from /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set.hpp:23, from /home/ross/peter/R/mspath/src/trueSrc/TestRecorder.h:11, from /home/ross/peter/R/mspath/src/trueSrc/TestRecorder.cc:6: /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:22: error: parse error before `<' token /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:25: error: ISO C++ forbids declaration of `value_type' with no type /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:25: error: parse error before `;' token /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp: In member function `void boost::ptr_set_adapter<Set, CloneManager>::transfer(typename PtrContainer::iterator, PtrContainer&)': /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:252: error: parse error before `;' token In file included from /home/ross/peter/R/mspath/src/trueSrc/TestRecorder.cc:6: /home/ross/peter/R/mspath/src/boost/smart_container/detail/associative_smart_container.hpp: At global scope: /home/ross/peter/R/mspath/src/boost/smart_container/detail/associative_smart_container.hpp: In instantiation of `boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>': mspath.web:4864: instantiated from `boost::ptr_set_adapter_base<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>' mspath.web:4864: instantiated from `boost::ptr_set_adapter<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>' mspath.web:4864: instantiated from `boost::ptr_set<mspath::Path, boost::ptr_less<mspath::Path>, boost::heap_clone_manager>' mspath.web:4864: instantiated from here /home/ross/peter/R/mspath/src/boost/smart_container/detail/associative_smart_container.hpp:39: error: no type named `key_type' in `struct boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >' /home/ross/peter/R/mspath/src/boost/smart_container/detail/associative_smart_container.hpp:102: error: no type named `key_type' in `struct boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp: In instantiation of `boost::ptr_set_adapter_base<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>': mspath.web:4864: instantiated from `boost::ptr_set_adapter<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>' mspath.web:4864: instantiated from `boost::ptr_set<mspath::Path, boost::ptr_less<mspath::Path>, boost::heap_clone_manager>' mspath.web:4864: instantiated from here /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:61: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:84: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:90: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:96: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:101: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:107: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:113: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:119: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:125: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:133: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:141: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:150: error: no type named `key_type' in `class boost::detail::associative_smart_container<boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp: In instantiation of `boost::ptr_set_adapter<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>': mspath.web:4864: instantiated from `boost::ptr_set<mspath::Path, boost::ptr_less<mspath::Path>, boost::heap_clone_manager>' mspath.web:4864: instantiated from here /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:180: error: no type named `key_type' in `class boost::ptr_set_adapter_base<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:223: error: no type named `key_type' in `class boost::ptr_set_adapter_base<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>' /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:228: error: no type named `key_type' in `class boost::ptr_set_adapter_base<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, boost::heap_clone_manager>' mspath.web: In member function `virtual boost::indirect_iterator<std::_Rb_tree_iterator<mspath::Path*, mspath::Path* const&, mspath::Path* const*>, boost::use_default, boost::use_default, boost::use_default, boost::use_default> mspath::TestRecorder::PathSet::insertUnique(mspath::Path*)': mspath.web:5319: error: no matching function for call to ` mspath::TestRecorder::PathSet::insert(mspath::Path* const&)' /home/ross/peter/R/mspath/src/boost/smart_container/detail/reversible_smart_container.hpp:449: error: candidates are: void boost::detail::reversible_smart_container<Config, CloneManager>::insert(typename Config::iterator, typename Config::container_type::size_type, typename Config::value_type&) [with Config = boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, CloneManager = boost::heap_clone_manager] /home/ross/peter/R/mspath/src/boost/smart_container/detail/reversible_smart_container.hpp:444: error: typename Config::iterator boost::detail::reversible_smart_container<Config, CloneManager>::insert(typename Config::iterator, typename Config::value_type&) [with Config = boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, CloneManager = boost::heap_clone_manager] /home/ross/peter/R/mspath/src/boost/smart_container/detail/reversible_smart_container.hpp:432: error: typename Config::iterator boost::detail::reversible_smart_container<Config, CloneManager>::insert(typename Config::iterator, typename Config::value_type*) [with Config = boost::set_config<std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> > >, CloneManager = boost::heap_clone_manager] mspath.web: In member function `virtual void mspath::TestRecorder::PathSet::transferUnique(boost::indirect_iterator<std::_Rb_tree_iterator<mspath::Path*, mspath::Path* const&, mspath::Path* const*>, boost::use_default, boost::use_default, boost::use_default, boost::use_default>, mspath::TestRecorder::PathSet&)': mspath.web:5332: error: no matching function for call to `find(mspath::Path&)' mspath.web: In member function `virtual void mspath::TestRecorder::goodPath(const mspath::Path&)': mspath.web:5287: error: `find' undeclared (first use this function) mspath.web:5287: error: (Each undeclared identifier is reported only once for each function it appears in.) /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp: In member function `void boost::ptr_set_adapter<Set, CloneManager>::transfer(typename PtrContainer::iterator, PtrContainer&) [with PtrContainer = mspath::TestRecorder::PathSet, Set = std::set<mspath::Path*, boost::ptr_less<mspath::Path>, std::allocator<mspath::Path*> >, CloneManager = boost::heap_clone_manager]': mspath.web:5335: instantiated from here /home/ross/peter/R/mspath/src/boost/smart_container/ptr_set_adapter.hpp:254: error: ` p' undeclared (first use this function) dî@: In function `_InputIter std::find(_InputIter, _InputIter, const _Tp&) [with _InputIter = __gnu_cxx::__normal_iterator<const mspath::TestRecorder::GeneratorState*, std::vector<mspath::TestRecorder::GeneratorState, std::allocator<mspath::TestRecorder::GeneratorState> > >, _Tp = mspath::TestRecorder::GeneratorState]': mspath.web:5414: instantiated from here dî@:256: error: `<declaration error>' is not a function, /usr/include/c++/3.3/bits/stl_algo.h:293: error: conflict with ` template<class _InputIter, class _Tp> _InputIter std::find(_InputIter, _InputIter, const _Tp&)' /usr/include/c++/3.3/bits/stl_algo.h:298: error: in call to `find' make[1]: *** [TestRecorder.o] Error 1 make[1]: Leaving directory `/home/ross/peter/R/mspath/src/debugTest' make: *** [test] Error 2 ----- End forwarded message -----

8 12

Boost.Python tutorial files (Was: *Attention*: ISO 9660/names with multiple dots)
by Aleksey Gurtovoy 11 Oct '04

11 Oct '04

Joel writes: > David Abrahams wrote: > > The Boost.Python tutorial files you cite are generated with > > QuickBook. Joel, these babies are yours. > > Actually, these are BoostBook babies. I already noted the long > filename problems in the boost-docs list a few weks ago. Rene > Rivera added on top of my post the multiple dot issue. I > don't know BoostBook enough to fix it. No solutions were > suggested, yet. Doug? Anyone? The BoostBook part is taken care of now, see http://article.gmane.org/gmane.comp.lib.boost.documentation/661. Let me know if there is anything that still keeps us from fixing this. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re: [boost] Re: Re: [review] Formal review of
by brangdon＠cix.compulink.co.uk 11 Oct '04

11 Oct '04

In-Reply-To: <ck8s5t$p2p$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > could you post your real code along with reasons for putting a null > into the tree and maybe some comments about the density of null's in > the tree. There is no reason to put a null in the tree. The density of nulls in the tree should be zero. The code needs to be surrounded by a test, equivalent to: if (pDog != 0) { pDog->walk_to( pTree ); assert( pDog->location() == pTree ); // ... more code assuming the dog's location. } My point is that using null_object does not enable you to avoid the "if" statement. And further, having a walk_to() member which is valid for some Dog subclasses and not others, is not really an improvement. -- Dave Harris, Nottingham, UK

2 1

ATTN: Regression runners: Versioned toolsets renaming
by Aleksey Gurtovoy 11 Oct '04

11 Oct '04

The following renaming just took place in the CVS: como-win32-4.3.3-vc7.1-tools.jam -> como-4_3_3-vc7-tools.jam como-win32-4.3.3-vc7-tools.jam -> como-4_3_3-vc7_1-tools.jam borland-5.5.1-tools.jam -> borland-5_5_1-tools.jam borland-5.6.4-tools.jam -> borland-5_6_4-tools.jam cw-8.3-tools.jam -> cw-8_3-tools.jam cw-9.2-tools.jam -> cw-9_2-tools.jam cw-9.3-tools.jam -> cw-9_3-tools.jam intel-win32-7.1-vc6-stlport-4.5.3-tools.jam -> iw-7_1-vc6-stlp-4_5_3-tools.jam intel-win32-7.1-vc6-tools.jam -> iw-7_1-vc6-tools.jam intel-win32-8.0-tools.jam -> intel-win32-8_0-tools.jam intel-win32-8.1-tools.jam -> intel-win32-8_1-tools.jam mingw-3.3.1-tools.jam -> mingw-3_3_1-tools.jam mingw-3.4.1-tools.jam -> mingw-3_4_1-tools.jam mingw-3.4.2-tools.jam -> mingw-3_4_2-tools.jam vc7.1-stlport-tools.jam -> vc-7_1-stlport-tools.jam vc7.1-tools.jam -> vc-7_1-tools.jam vc8.0-tools.jam -> vc-8_0-tools.jam vc8.0-x86_amd64-tools.jam -> vc-8_0-x86_amd64-tools.jam If you are running regressions with any of these toolsets, please adjust your scripts to use the new names. "boost-base.jam", docs, and failures markup files has been updated accordingly. Note that the latter will cause a temporary disturbance in the regression reports; things should return back to normal as soon as all runners upload updated results. -- Aleksey Gurtovoy MetaCommunications Engineering

7 10

Re: [boost] [review] Formal review of the Smart Container library
by brangdon＠cix.compulink.co.uk 11 Oct '04

11 Oct '04

In-Reply-To: <97E47D90-1A3F-11D9-BF1C-003065D18932(a)twcny.rr.com> hinnant(a)twcny.rr.com (Howard Hinnant) wrote (abridged): > > The second is a container of values which may be polymorphic. It > > would be a more-or-less drop-in replacement for vector<T>. It > > would not allow nulls, and the syntax would be like > > v.begin()->method(). Although it would probably use pointers > > behind the scenes, that would be an implementation > > detail not revealed by its interface. > > I.e. a vector<T&> ? That might be a reasonable syntax, yes. -- Dave Harris, Nottingham, UK

1 0

boost-Testing mailing list
by David Abrahams 11 Oct '04

11 Oct '04

I've lost track of who wanted this mailing list, but I now have the admin password. Someone else should volunteer to administrate the list, so contact me privately and we can go from there. Regards, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

3 4

Re: [boost] [review] Formal review of the Smart Container library
by brangdon＠cix.compulink.co.uk 11 Oct '04

11 Oct '04

In-Reply-To: <797960166.20041007113153(a)topmail.sk> droba(a)topmail.sk (Pavol Droba) wrote (abridged): > Formal review of the Smart Containers library from Thorsten Ottosen > has been extended until Saturday, October 7th 2004). Goody. Here are my comments. > * What is your evaluation of the design? I felt it was a bit muddled in its objectives. For example, it presents itself as a "container of pointers to heap-allocated objects", but then does not use pointer-like syntax or support NULL pointers. It offers both begin() and ptr_begin(). I feel there are really two kinds of container here. The first is a container of pointers which takes ownership of the objects it points to. This would be a more-or-less drop-in replacement for vector<T*>. It would allow nulls, and syntax like (*v.begin())->method(). The second is a container of values which may be polymorphic. It would be a more-or-less drop-in replacement for vector<T>. It would not allow nulls, and the syntax would be like v.begin()->method(). Although it would probably use pointers behind the scenes, that would be an implementation detail not revealed by its interface. The present submission has tried to combine these two kinds of container. I believe they would be better kept separate and given different names. I'd suggest "owning_vector" and "poly_vector", or similar, since the one is about ownership of pointers and the other is about solving the polymorphic value problem. Incidently, I also dislike the library calling itself "smart" because that word is too vague. Smart in what way? I am bothered by the libraries interaction with std algorithms. For example, std::remove_if<> doesn't work with the container's iterators. That makes it, at best, a low-level library that needs to be managed carefully. > * What is your evaluation of the potential usefulness of the > library? Why not use vector<shared_ptr<T> > instead? That provides a simple out-of-the-box solution without the problems with std algorithms. The present library claims performance benefits, but if I need those I'd write my own wrapper for vector<T *> which did exactly what I needed and no more. A library which made that easier might be useful to me, but I don't think the present submission is that library. The library also claims better syntax, but for me that benefit is negligible. So I don't believe I will ever use this library. > * What is your evaluation of the implementation? > * What is your evaluation of the documentation? > * Did you try to use the library? With what compiler? Did you > have any problems? > * How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? > * Are you knowledgeable about the problem domain? I have not looked at the implementation or attempted to use the library. I read the documentation, got confused, got unconfused via this list, and then decided it was not for me. Maybe half an hour of effort. I don't expect my opinion to carry much weight. I use std containers, and have often written wrappers for containers of raw pointers. > * Do you think the library should be accepted as a Boost library? No. I strongly object to the library with its present naming. If it were renamed along the "poly_vector" lines, I would probably be neutral. -- Dave Harris, Nottingham, UK

4 3

[BGL] dag_shortest_paths broken?
by Vladimir Prus 11 Oct '04

11 Oct '04

Hello, it appears that the dag_shortest_paths algorithm is broken. The attached program tries to find the longest path by changing inf/comparison operators. The graph is 0 -----> 1 ------> 2 ^ | 3 ----------/ The edge weights are 1 for 0->1 and 1->2 and 2 for 3->1 and I'm searching for the longest path starting from '0'. The final result for '2' is 0x7FFFFFFF, while I'd expect to get '2'. The problem is two-fold. First, the algorithm runs topological sort on the graph, and process the vertices in topological order -- which include the '3' vertex. That vertex is not reachable from '0', so it should not be included in the search at all. The second problem is that the distance to that vertex is set to -inf. When combining that distance with edge weight, due to a bug we get +inf. Here's the code: template <class T> struct closed_plus { // std::abs just isn't portable :( template <class X> inline X my_abs(const X& x) const { return x < 0 ? -x : x; } T operator()(const T& a, const T& b) const { using namespace std; T inf = (numeric_limits<T>::max)(); if (b > 0 && my_abs(inf - a) < b) return inf; return a + b; } }; When 'a' is -inf (as is for '3') inf - a overflows and gives -1, and when b is greater than 1, "inf" is returned. I think that the right solution is to change the algorithm so that it does not traverse the vertices not reachable from the start one. Besides fixing my problem, this will also speed up the algorithm. For example, if you have a forest and call dag_shortest_path on the root of just one tree, the algorithm will travese all trees, setting pretty useless values for all of them. I would like to commit the attached patch. All tests still pass on gcc when it's applied. Comments? - Volodya

2 1

[spirit] documentation typo correction
by Jurko Gospodneti� 11 Oct '04

11 Oct '04

Hi In 'http://www.boost.org/libs/spirit/doc/functional.html' 'It is obvious that the authors of STL knows and practices FP.' should read 'It is obvious that the authors of STL know and practice FP'. HTH, Jurko

2 1

Re: [boost] Re: [review] Formal review of the Smart Container library
by brangdon＠cix.compulink.co.uk 10 Oct '04

10 Oct '04

In-Reply-To: <ck8rf2$njl$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > At some point it was discussed to have a new policy that decided the > indirection of the reference type. I feel the kinds of container are so different that it isn't appropriate to have a user-level policy which turns one into the other. It might make sense for them to share some common implementation, though. > It create much attention. Indeed. My biggest problem was understanding what the library was, other than a grab-bag of features. The access syntax, for example - I sometimes felt it was a stand alone feature - that it would make just as much sense to have a vector<shared_ptr<T> > or vector<T*> that used the v.begin()->method() syntax, rather than something which flowed out of the specific intent of ptr_vector<T>. I suppose a policy approach might be appropriate if the same policy could be applied to all 3 kinds of vector. However, I am not keen on having 2 syntaxes for doing the same thing in the first place. I'm happy to use pointer syntax for things which are pointers. > smart in the same way smart pointers are smart. It should give the > impression of exception-safety and resource ownership. "Smart" suggests neither of those things to me. > | I am bothered by the libraries interaction with std algorithms. For > | example, std::remove_if<> doesn't work with the container's iterators. > | That makes it, at best, a low-level library that needs to be managed > | carefully. > > Ok, what do you suggest we do instead? I don't know. > | The present library claims performance benefits, but if I need those > | I'd write my own wrapper for vector<T *> which did exactly what I > | needed and no more. > > Could you enumerate what exactly you need and maybe tell why > if a library suported more than you needed, but you didn't use that > extra stuff, it would still be a bad thing? Exactly what I need depends on circumstances. For example, I don't always need to let client code enumerate the container's contents. A container which allow that would need to be wrapped by a class which hid those members, because I don't like my classes to publish more interface than they need to. > Would an unindirected interface be enough? > (eg, you can determine to disable cloning etc). I'm not sure what you mean. > Did you ever forget to implement a wrapper function > with the right exception-safety? I don't believe I've ever had a problem in that area. -- Dave Harris, Nottingham, UK

1 0

Nonconforming filenames in "libs/serialization"
by Aleksey Gurtovoy 10 Oct '04

10 Oct '04

Robert, According to http://tinyurl.com/5abnh, there are still a few nonconforming filenames in the serialization library that need to be fixed: libs/serialization/test/test_polymorphic_archive_data.hpp: filename > 31 chars libs/serialization/vc6ide/demo_portable_binary_archive.dsp: filename > 31 chars libs/serialization/vc7ide/test_derived_class_ptr..vcproj: filename contains more than one dot character ('.') libs/serialization/vc7ide/test_level_class_info_load.vcproj: filename > 31 chars libs/serialization/vc7ide/test_multiplel_ptrs..vcproj: filename contains more than one dot character ('.') Could you please take care of these? TIA, -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Boost 1_31 - Problem with Lambda, UnNamed namespaces VC7.1
by Brian Braatz 10 Oct '04

10 Oct '04

I have searched the list archive and have not found anything on this subject. I have what looks like to be an issue with MSVC7.1 and unnamed namespaces (the _1 _2 and _3 are in unnamed namespaces in boost::lambda) See below: #include <boost/bind.hpp> #include <boost/Lambda/lambda.hpp> // adding my code to the boost::lambda namespace // below works fine namespace boost { namespace lambda { void MyFunction() { using namespace std; list<int> v; v.push_back(1); v.push_back(2); v.push_back(3); v.push_back(4); v.push_back(5); // Line below works for_each(v.begin(), v.end(), std::cout << _1 << ' '); } } } // Now global namespace void MyFunction() { using namespace std; using namespace boost; using namespace boost::lambda; list<int> v; v.push_back(1); v.push_back(2); v.push_back(3); v.push_back(4); v.push_back(5); // Line below fails with a "error C2872: '_1' : ambiguous symbol" for_each(v.begin(), v.end(), std::cout << _1 << ' '); // This line DOES work for_each(v.begin(), v.end(), std::cout << boost::lambda::_1 << ' '); } Has anyone else run into this? Also- I do not have the current CVS tree handy (I am using 1.31), is this a problem on 1.32? If it is workedaround in some fashion, I can just qualify every _1 and _2 until 1.32 comes out. Thanks for any help or suggestions Brian Braatz

4 5

Re: MPL - mpl::sequence to std::sequence
by Jaap Suter 10 Oct '04

10 Oct '04

>Yeah, I guess Aleksey and Dave have been busy with >the forthcoming MPL book, but as I understand >from list postings, the MPL docs will be updated in >Boost 1.32, and mpl::for_each is one of the more useful >components. Since it's not documented, I learned how it >works from Aleksey. The following works with your code: Thanks! A lot better than my code :).

1 0

RE: [boost] Re: Boost 1_31 - Problem with Lambda, UnNamed namespaces VC7.1
by Brian Braatz 10 Oct '04

10 Oct '04

> "Brian Braatz" <brianb(a)rmtg.com> writes: > > > I have searched the list archive and have not found anything on this > > subject. > > > > I have what looks like to be an issue with MSVC7.1 and unnamed > > namespaces > > (the _1 _2 and _3 are in unnamed namespaces in boost::lambda) > David Abrahams Writes: > Don't you mean in Boost.Bind? [Brian Braatz] Yes, sorry, my mistake.

1 0

[Boost-bugs] [ boost-Bugs-1043616 ] boost::rational documentation typos(?)
by SourceForge.net 10 Oct '04

10 Oct '04

Bugs item #1043616, was opened at 2004-10-09 08:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1043616&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost::rational documentation typos(?) Initial Comment: <http://www.boost.org/libs/rational/ rational.html#Integer%20Type%20Requirements> states: "I must be an integer-like type, that is the following expressions must be valid for any two values n and m of type I, with the "expected" semantics. [...] n / m (must truncate, and n/m must be positive if n and m are positive)" I doubt that that is what boost::rational requires. int n = 1; int m = 3; int n_over_m = n/m; if( n_over_m > 0) { std::cout << "all OK\n"; } else { std::cout << "Can't use 'int' as base type for boost::rational\n"; } <http://www.boost.org/libs/rational/rational.html#Constructors> states: "Rationals can be constructed from a pair (numerator, denominator) of integers, or a single integer" I think that the documentation should read: "Rationals can be constructed from a pair (numerator, denominator) of I's, or a single I" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1043616&group_… ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

3 5

[Boost-bugs] [ boost-Bugs-1043942 ] boost::serialization - strings with '&' character included
by SourceForge.net 10 Oct '04

10 Oct '04

Bugs item #1043942, was opened at 2004-10-10 04:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1043942&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost::serialization - strings with '&' character included Initial Comment: The issue is related to xml serialization only. I am trying to serialize strings with & character included. When I am trying to deserialize such a string, everything after '&' just disappeared. Also I noticed that serializer doesn't convert '&' to xml entity '&'. I guess it should. However it converts from amp entity when deserializing. Even if I convert '&' to xml entity manually, the problem still occur. As I found debugging the source code, the problem happens because of wrong spirit rule in basic_xml_grammar.ipp file: CharData = (*(anychar_p - chset_p(L"&<"))) [ append_string< StringType, BOOST_DEDUCED_TYPENAME std::basic_string<CharType>::const_iterator >(rv.contents) ] ; when I deleted '&' I was able to deserialize strings with '&' at least. I do not know how it can affect other aspects of deserialization. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1043942&group_… ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

true64cxx regresion reports
by Fernando Cacciola 10 Oct '04

10 Oct '04

Hi, While adding failure markups, I noticed that the Optional library is shown as failing with true64cxx. However, looking at the error I can see that it is using an older version of the library (one which indeed is defective) I'm also seeing similar results for this toolset and the Numeric Conversion Library Can anyone fix this? TIA Fernando Cacciola SciSoft

4 7

The Concept Traits Library: naming - opinions sought
by Terje Slettebø 09 Oct '04

09 Oct '04

Hi all. In the operator/concept traits library (now renamed Concept Traits Library) that I posted about a while ago, there were, as Tobias Schwinger pointed out in a mail, several filenames that were longer than then Boost 31 character maximum. I was aware of this, but didn't know how stringent this requirement was (7 of 37 standard concept traits have more than 31 characters, the maximum being 37 characters). However, as I understand, it's not just platforms, but also things like media (such as CDs) that may impose this limit, making it more serious. The library will be put in a CVS at the http://www.neoscientists.org/ server, and we're not sure how to deal with the maximum filename length. The current directory structure is, e.g.: #include <boost/concept_traits/std/is_default_constructible.hpp> #include <boost/concept_traits/std/is_random_access_container.hpp> #include <boost/concept_traits/std/is_random_access_iterator.hpp> #include <boost/concept_traits/std/is_generator.hpp> Tobias suggested the following (the "model" part is still not decided, and may be considered separately): #include <boost/concept_traits/model/std/constructbility/default.hpp> #include <boost/concept_traits/model/std/container/random_access.hpp> #include <boost/concept_traits/model/std/iterator/random_access.hpp> #include <boost/concept_traits/model/std/function/generator.hpp> The traits would still retain their names, so <boost/concept_traits/model/std/iterator/random_access.hpp> would have is_random_access_iterator<T>. To consider the issue, we looked at Boost's type_traits, where all the traits are in the same directory, as well as libraries like MPL, where it appears to move to <boost/mpl/arithmetic/plus.hpp> (from <boost/mpl/plus.hpp>) - at least, the "arithmetic" directory is there. The same goes for PP-lib. However, in the case of CTL, the components would then have a different name than the source file, so I felt like getting some more opinions on the subject. What do you think? Opinions on whether or not "model" should be included in the path is also welcome. Bear in mind in that case that the "concept_traits" directory will also contain the "operator" (for the operator traits) and "utility" (for components to define new traits), so "model" might more clearly separate out that these are the concept traits, themselves. Also, what is the opinion on singular/plural? Boost's type_traits is plural (and this is quite similar to them), but there are otherwise mostly singular names in Boost (and the library requirements states that libraries should usually be singular). Regards, Terje

6 11

Re: [boost] Re: [review] Formal review of
by brangdon＠cix.compulink.co.uk 09 Oct '04

09 Oct '04

In-Reply-To: <ck6la2$kki$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > Conclusion: disallowing 0 will not only lead to simpler, safer > programs, but it will probably also boost performance. The null object pattern can only be used if all the object's member functions have trivial post-conditions. If instead I have code like: dog.walk_to( pTree ); assert( dog.location() == pTree ); // ... more code assuming the dog's location. then it is not going to work with a null_dog. If people use it anyway there will be tears before bedtime. Of course, this is no more an argument against ptr_vector<Dog> than it is against std::vector<Dog>. I think the problem here is the name. "ptr_vector" sounds so much like a vector of pointers that people expect null pointers to be supported. There is a gap between what those people want and what ptr_vector supplies. The null object pattern is not a solution here. It just papers over the crack. -- Dave Harris, Nottingham, UK

2 1

shared_object
by Andy Little 09 Oct '04

09 Oct '04

Hi, Any interest in a shared_object? In this case its the object that is shared, not the pointer.... Nah... too obvious ;-) regards Andy Little

3 5

Trial history file; error in Boost CSS file
by Daryle Walker 09 Oct '04

09 Oct '04

I'm surprised that a full-blown version history file wasn't added a long time ago. I raided the CVS history of the main "index.htm" file for the details. Any ancient-timers know the history of 1.11.0 and earlier? Pretend that the file is at 'BOOST_ROOT/more/version_history.html'. The header looks funny; I was wondering how to replicate the current look by mutating what's given with CSS. (I was thinking of the headers seen at <http://www.mozilla.org>.) I processed what I wrote through HTML-Tidy, adding indentation and line wrap. I kept getting weird spacing with the function descriptions at the Spirit section of 1.30.1 and the Lambda block-quote at 1.28.0. I worked-around the problem by undoing the line-breaks Tidy added at those points. The problem is in the CSS file: CODE { FONT-FAMILY: Courier; white-space: pre; } This last (non-brace) line says that multiple white-space characters are _not_ collapsed into a single space. This lets CODE acts as an in-line variant of PRE, but it violates what CODE usually does! I need the default space-collapsing behavior of CODE. If no one can give me a justification for that attribute, I'm going to erase it. Even if you can justify it, do this instead: CODE.my_special { FONT-FAMILY: Courier; white-space: pre; } Then call it like so: Blah blah, please <code class="my_special">keep all of my spaces</code> blah blah. That way people who need the default space-collapsing attribute of CODE (like me) don't get screwed. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[review] Formal review of the Smart Container library starts today
by Pavol Droba 08 Oct '04

08 Oct '04

Hi all, The review of the Smart Container library, written by Thorsten Ottosen starts today (September 26th, 2004) and runs for 10 days (until October 5th, 2004). The latest version of the library can be found at http://boost-sandbox.sourceforge.net/smart_container.zip or http://groups.yahoo.com/group/boost/files/pointer%20container/smart_contain… The package contains all you need to sucessfuly use the library with the Boost version 1.31 or later, however library tests require the latest Boost.Test, that is available from the main Boost CVS. What does the library provide? The library documentation states: >>>>>>>>>>>>>>>> Whenever a programmer wants to have a container of pointers to heap-allocated objects, there is usually only one exception-safe way: to make a container of smart pointers like boost::shared_ptr. This approach is suboptimal if 1. the stored objects are not shared, but owned exclusively, or 2. the overhead implied by smart pointers is inappropriate This library therefore provides standard-like containers that are for storing heap-allocated or cloned objects (or in case of a map, the mapped object must be a heap-allocated or cloned object). For each of the standard containers there is a smart container equivalent that takes ownership of the objects in an exception safe manner. In this respect the library is intended to solve the so-called polymorphic class problem. The advantages of smart containers are 1. Exception-safe and fool proof pointer storage and manipulation. 2. Notational convenience compared to the use of containers of pointers. 3. Can be used for types that are neither Assignable nor Copy Constructible. 4. No memory-overhead as containers of smart pointers can have (see 11 and 12). 5. Usually faster than using containers of smart pointers (see 11 and 12). 6. The interface is slightly changed towards the domain of pointers instead of relying on the normal value-based interface. For example, now it is possible for pop_back() to return the removed element. The disadvantages are 1. Less flexible than containers of smart pointers <<<<<<<<<<<<<<< As an example of how the new containers look like, consider that <code> typedef boost::shared_ptr<Foo> foo_ptr; std::vector<foo_ptr> vec; vec.push_back( foo_ptr( new Foo ) ); (*vec.begin())->bar(); </code> now becomes <code> boost::ptr_vector<Foo> vec; vec.push_back( new Foo ); vec.begin()->bar(); </code> In your reviews, please include the answers for the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Also, in the documentation you will find questions from the submitter to the reviewer; whenever you feel you have something to contribute on these issues, please don't hessitate to include that in your review. Thank you, Pavol Droba, review manager for the Smart Containers library.

13 57

people page
by Fernando Cacciola 08 Oct '04

08 Oct '04

Hi, Should mantainers of released libraries (like me) add themselves to the people page, or we need to be explicitely invited for this? And in that case, should we upload ourselves the photos or should we send them to one of the moderators instead? TIA Fernando Cacciola SciSoft

4 7

Re: Removing dots from toolset names
by Aleksey Gurtovoy 08 Oct '04

08 Oct '04

Jürgen Hunold writes: > Hi ! Hi Jürgen, > > On Tuesday 05 October 2004 15:10, Aleksey Gurtovoy wrote: > > Hi All, > > > > As you probably already know, we also need to take care of these: > > Why ? Can someone point me to the rationale for this ? The original rationale was "to ensure file and directory names are relatively portable": http://www.boost.org/more/lib_guide.htm#Directory_structure. Beman might be able to clarify whether ISO 9660/Level 2 requirements in particular were one of the motivating factors back then or not, but currently those are the primary driving force for getting Boost codebase to conform to these rules: We want to be able to put a Boost distribution on a CD in the unpacked form, and for that CD to be readable on the maximum number of platforms. > Where can I find out which platforms have which limits ? WWW :). Here, for instance -- http://www.zplace.com/crashtips/filename.html. > > > intel-win32-7.1-vc6-stlport-4.5.3-tools.jam: filename > 31 chars, filename > > contains more than one dot character ('.') intel-win32-7.1-vc6-tools.jam: > > Some of these toolsets exist in current 1.31.0 with _more_ than one dot. > Take vc7.1-stlport-tools.jam for example. Sure. The requirements weren't strictly inforced until now. > > > I suggest we either replace the dots with underscores, or get rid of them > > completely (besides the last one, of course), i.e. either: > > > > borland-5_5_1-tools.jam > > borland-5_6_4-tools.jam > > como-win32-4_3_3-vc7-tools.jam > > -1 > > > borland-551-tools.jam > > borland-564-tools.jam > > como-win32-433-vc7-tools.jam > > ... > > Preferences? > > +1 Thanks! > > > [I also know that there is more to this than just renaming of the files; > > any help with the whole matter would be greatly appreciated.] > > Just one curious question: > AFAIK, all of the platforms these toolsets are _for_ support both filenames > with more than 31 characters and more than one dot. > I just wonder if we should break and repair the whole V1 build system when > the offending toolsets are for platforms which don't _have_ these limits. The changes are not that drastic, but it's a reasonable question to ask. Ignoring the fact that we already have nonconforming names fixing which requires some work, IMO all the current requirements except 31-character limit are not hindering us in any significant way, are easy to satisfy, and in general have a good cost/benefit ratio. I don't feel strongly about maximum length of 31, in particular since MacOS 9 is pretty much dead, and we _are_ somewhat restrained by the limit. Being able to read a Boost CD on, let's say, Linux versions released before 1999 is definitely going to be appreciated by _somebody_, but there is a certain cost to that, and personally I'm starting to feel that may be it's not worth it. But then, as a release manager who has to take care of this issue, I'm biased. > > Just my .02€, developing on linux and win32. Thanks, they are appreciated. -- Aleksey Gurtovoy MetaCommunications Engineering

3 3

Re: Removing dots from toolset namesHo
by Aleksey Gurtovoy 08 Oct '04

08 Oct '04

Jürgen Hunold writes: > On Wednesday 06 October 2004 17:35, Aleksey Gurtovoy wrote: > > The changes are not that drastic, but it's a reasonable question to > > ask. Ignoring the fact that we already have nonconforming names > > fixing which requires some work, IMO all the current requirements > > except 31-character limit are not hindering us in any significant > > way, are easy to satisfy, and in general have a good cost/benefit > > ratio. > > > > I don't feel strongly about maximum length of 31, in particular since > > MacOS 9 is pretty much dead, and we _are_ somewhat restrained by the > > limit. Being able to read a Boost CD on, let's say, Linux versions > > released before 1999 is definitely going to be appreciated by > > _somebody_, but there is a certain cost to that, and personally I'm > > starting to feel that may be it's not worth it. But then, as a > > release manager who has to take care of this issue, I'm biased. > > I've got this impression, too. > > My old PPC-6100-Mac is rotting in a corner ... ;-((( > > I don't want to spoil the release, but did you take a look at the > BoostBook generated docs ? > At least BBv2 generates files like > "bbv2.reference.buildprocess.alternatives.html" Yep, I'm aware of the issue. Or, rather, I was aware. It's taken care of now -- http://article.gmane.org/gmane.comp.lib.boost.documentation/661. > This will not work when someone tries to ship pre-built documentation on > pure ISO-9660 CD, either. > And I thought that a release tarball should contain a pre-built > documentation because no-one can be expected to install all the > necessary components to build it. Yep, it should and it will. > Do you/we want to change this, too ? > And have *lots* of cryptic, human-unreadable file names ? Well, the name length is still partly an issue, but certainly not to the extent it was before the subdirectories fix. And even the overly long names don't necessarily have to be turned into cryptic ids. For instance, something like "static_local_time_adjustor.html" doesn't have to become "id413791.html"; it can be "static_local_time_adjust00.html", or "static_local_time_00.html", or something else along these lines. Having said that, I'm going to repeat myself -- while I think all other requirements are worth sticking to, I don't feel strongly about keeping the 31-character limit. But now that we have not that many names to fix, it's tempting to go with it to the end at least for this release. > When we discuss this further, we should do it on Boost-Mailing-List Transferred; Cc'd to jamboost. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re:Re: [boost] [serialization] test_level_class_info_load*...
by Robert Ramey 08 Oct '04

08 Oct '04

< .... Thank for a very clear and concise explanation to something that is just about impossible to understand. >The solution I suggested before does the dependency: ><directory>test_*_load_*.test --> <->test_*_save_*.test >Which make that last line of the DAG above: >test --> *.test -> *.run -> *.exe, *.obj, etc -> *_load_*.test directory >-> *_save_*.test >Make sense? More or less. If I understand this correctly, then on a second run if the directory is already created, the desired dependency won't be enforces. That is the following scenario won't work a) test_..._save builds but fails at runtime. This creates all directory structures for test...save. b) test...._load will build and run but will fail because test...save failed to create an temporary file that test...load needs. >PS. If you are sure you are only going to have run tests. You could do >things like: >local test-part-2 = [ test-bsl-run_files test_class_info_load ] ; >local >test-part-1 = [ test-bsl-run_files test_class_info_save ] ; >DEPENDS $(test->part-2:S=.run) : $(test-part-1:S=.run) ; Actually I think this latter is more a kin to what is required. The dependency is that test..save must be executed successfully to create the appropriate output file to test the run of the corresponding test...load. Even if the test..save fails to build or run, it is valuable to build (though not run) to check for compilation and linkage errors) Your explanation has motivated to spend a little time with this. Robert Ramey

1 0

Re: [boost] Re: [multi_index] problem with gcc 3.4.2 for Compaq Tru64UNIX
by JOAQUIN LOPEZ MU?Z 08 Oct '04

08 Oct '04

----- Mensaje original ----- De: Markus Schöpflin <markus.schoepflin(a)comsoft.de> Fecha: Viernes, Octubre 8, 2004 5:04 pm Asunto: [boost] Re: [multi_index] problem with gcc 3.4.2 for Compaq Tru64 UNIX > Markus Schöpflin wrote: > > > Joaquín Mª López Muñoz wrote: > > > >> mips-tfile, /tmp//cctFjnCI.s:10965 string too big (35326 bytes) > >> line:? #.stabs?"and_<boost::mpl::not_<boost::is_same<boost::mpl: > >> [very long expression] > > > > A quick google search indicates that this is a problem with gcc > on alpha > > when compiling with debug symbols. A possible workaround might > be to use > > -gstabs instead of -g, I'll try it ASAP. > > I did some experiments and the only way to compile these files it > to > disable debug symbols completely. I have done that on the toolset > for gcc > used for the regression runs, I hope it helps to clean up some of > the errors. > Thanks for your help! Indeed, Boost.MultiIndex generates horribly long symbol names, it's a pita when trying to decode compiler errors (comparatively, regular STL errors are even pleasant to deal with). I'll have to think some way to shorten them in future releases. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[multi_index] problem with gcc 3.4.2 for Compaq Tru64 UNIX
by Joaquín Mª López Muñoz 08 Oct '04

08 Oct '04

Seems like some multi_index tests are failing due to lack of resources or something like that, for COMSOFT reports. http://tinyurl.com/66t2h mips-tfile, /tmp//cctFjnCI.s:10965 string too big (35326 bytes) line:? #.stabs?"and_<boost::mpl::not_<boost::is_same<boost::mpl: [very long expression] Anyone has an idea what this could be about? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

Problematic inclusion of "pthread.h".
by Markus Schöpflin 08 Oct '04

08 Oct '04

When compiling the smart pointer tests with gcc 3.4.2 on Tru64, two tests fail with an error message. (See http://tinyurl.com/4jngu ) As far as I can see, the shared pointer implementation at some point includes the "pthread.h" system header file but gcc on Tru64 requires that -pthread must be specified on the command line when including this header file. When running this test with gcc 3.4.2 on Linux the file "pthread.h" is also included but gcc doesn't require the addition of -pthread in the command line on this platform. This leads to the question whether it is ok to include "pthread.h" without specifying -pthread on the command line. Does anyone know an answer to this? Markus

5 26

Re: uBLAS broken on MSVC 6.5
by Michael Stevens 08 Oct '04

08 Oct '04

Alekskey, > Seems like some recent changes brought MSVC to its knees -- > http://tinyurl.com/3vmlv. Fix is already committed. Tomorrow we should be all green again. My plan is for this release is to get maximum compatibility with the older compilers. In particular VC6.5 7.0, GCC 2.95, Intel 7.0, and CV8.3 Then after this release I can drop many of the multitude of workaround necessary for these. With regard to Code Warrior I was hoping to develop a fix for the debug mode compilation errors show up on you metacomm test. I didn't come up with anything satisfactory however. Do you have any idea why there is such a large difference between your cw-8.3 and the RSI's cw-8.3-release tests? I can only see the command line options in the failing build. The only option I can see which could be of relevance is the '-iso-template on'. If you are both using stock versions of the build system this same option should be set for the release build as well. Thanks for you interest (and hard work), Michael

2 2

Re: Re: [boost] [serialization] test_level_class_info_load*...
by Robert Ramey 08 Oct '04

08 Oct '04

>First, you need to "fix" your Jamfile to return the test targets: >... OK >=================================================================== >Having that working, lets you define the tests so that they depend on >each other (indirectly). For example: >=================================================================== >local test-suite-serialization-part-1 = > [ test-bsl-run_files test_array ] > [ test-bsl-run_files test_binary ] >; >local test-suite-serialization-part-2 = > [ test-bsl-run_files test_contained_class ] > [ test-bsl-run_files test_cyclic_ptrs ] >; >test-suite serialization : > $(test-suite-serialization-part-1) > $(test-suite-serialization-part-2) >; >DEPENDS $(gLOCATE($(test-suite-serialization-part-2):G=directory-grist) > : $(test-suite-serialization-part-1) >; Now - out of curiosity, most of the rule are of the form: rule test-bsl-run_polymorphic_archive ( test-name : sources * ) which suggests to me that I could just use: test-suite serialization : [ test-bsl-run_files test_level_class_info_load test_level_class_info_save ] Which would make ...load dependant on ...save. Or this is this answered by the following: >That last DEPENDS makes the directory for the part 2 depend on the >completion of part 1. You may ask why the directory and not the test >itself? Strangely it's because to properly chain the tests you need to >make the earliest step of the second test depend on the latest part of >the next test. And directories are the only sure thing that you can know >a test needs first. Robert Ramey

2 1

using boostbook on Windows
by Wieger Wesselink 07 Oct '04

07 Oct '04

I tried to use boostbook with native Windows, and ran into a few problems. There were two things that took me several hours to figure out. May be this could be added to the installation notes? 1) Apparently the order of the 'using boostbook' and 'using doxygen' declarations in user-config.jam matters; I did it wrong at first, and the resulting errors were incomprehensible to me: warning: Doxygen initialization: Boost.Build stylesheets not found 2) I needed to empty the bin.v2 directory to make it work. This was something I hadn't thought about, and again the error messages were quite incomprehensible. Finally, the generation of PDF doesn't work because of a problem with the jam files. It seems that fop.sh is called instead of fop.bat. Perhaps someone could have a look at this? ...found 20 targets... ...updating 1 target... fop ..\..\..\bin.v2\tools\boostbook\doc\gcc\debug\boostbook.pdf 'JAVA_HOME' is not recognized as an internal or external command, operable program or batch file. JAVA_HOME=D:/java/jdk1.5.0 D:/cpp/boostbook/fop-0.20.5/fop.sh ..\..\..\bin.v2\tools\boostbook\doc\gcc\debug\boostbook.fo ..\..\..\bin.v2\tools\boostbook\doc\gcc\debug\boostbook.pdf ...failed fop ..\..\..\bin.v2\tools\boostbook\doc\gcc\debug\boostbook.pdf... ...failed updating 1 target... If I run this from the command line with fop.bat, the file boostbook.pdf is successfully created. I have used the following settings: --- user-config.jam --- using xsltproc ; using boostbook : d:/cpp/boostbook/docbook-xsl-1.66.1 : d:/cpp/boostbook/docbook-xml-4.2 ; using doxygen ; using fop : D:/cpp/boostbook/fop-0.20.5 : D:/java/jdk1.5.0 ; Regards, Wieger -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

1 0

Fixing broken links
by Aleksey Gurtovoy 07 Oct '04

07 Oct '04

It would be appreciated if the maintainers of the following libraries took care of the corresponding issues listed in http://www.meta-comm.com/engineering/boost/links.html: algorithm build date_time iterator numeric/conversion optional program_options python range serialization test thread TIA, -- Aleksey Gurtovoy MetaCommunications Engineering

6 5

Latest cvs causes segfault on gcc version 3.4.2 20041003 (Red Hat 3.4.2-4)
by Neal D. Becker 07 Oct '04

07 Oct '04

This is current gcc for Linux/FC3T2. (Fedora core 3 test 2) /usr/local/src/boost.cvs/libs/python/build/../src/tuple.cpp: In constructor `boost::python::detail::tuple_base::tuple_base(const boost::python::api::object&)': /usr/local/src/boost.cvs/libs/python/build/../src/tuple.cpp:21: internal compiler error: Segmentation fault Bug report filed.

4 6

Re: [boost] Re: The Smart Container library
by brangdon＠cix.compulink.co.uk 07 Oct '04

07 Oct '04

In-Reply-To: <cjbuc0$csa$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > It has never been the intention to support a path of "upgrade". The > semantics are very different from vector<shared_ptr<T> > and > ptr_vector<T>. The semantics are closer to vector<T> when it comes > to "copying". OK, thanks. It sounds like the library isn't really doing what I expect or want. To the point where I question whether "ptr_vector" is a good name for it, since it does not behave like a vector of pointers. Maybe something like "poly_vector" would better reflect the intent. I think I've missed the end of the review period now - they just whizz past, don't they? - but that probably doesn't matter because all I can really say is that I don't think I am a prospective user of the library. I might have been interested in a container which took ownership of the things pointed-to, but was otherwise a simple container of pointers. -- Dave Harris, Nottingham, UK

1 0

Re: [boost] Re: [Poll] New look-n-feel for Boost documentation
by brangdon＠cix.compulink.co.uk 07 Oct '04

07 Oct '04

In-Reply-To: <cjpj7l$9c2$2(a)sea.gmane.org> dheld(a)codelogicconsulting.com (David B. Held) wrote (abridged): > > I had a quick look from my mobile phone, and it worked > > reasonable well. > > Is this an important use case? I can't remember a single time where > I said to myself: "It would be really handy to look up some Boost > documentation from my phone right now." I'm a bit of a web purist. I think it should be viewable from anywhere unless there's a good reason not to be. Partly because there's so much variety in clients. Anyway, even if we do all have huge hi-res desk-top monitors available, screen real estate is precious. A good web-site should cope gracefully with small browser windows. -- Dave Harris, Nottingham, UK

1 0

[serialization] CVS doesn't build with gcc 3.4.2
by Christoph Ludwig 07 Oct '04

07 Oct '04

Since the last CVS update I cannot build libboost_wserialization anymore (gcc 3.4.2 on i686-pc-linux-gnu). I get errors like the following: gcc-C++-action bin/boost/libs/serialization/build/libboost_wserialization.a/gcc/debug/text_wiarchive.o /home/cludwig/C++/boost_CVS_SF/boost/archive/text_wiarchive.hpp: In member function `Archive& boost::archive::detail::interface_iarchive<Archive>::operator>>(T&) [with T = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Archive = boost::archive::text_wiarchive]': [...] /home/cludwig/C++/boost_CVS_SF/boost/archive/text_wiarchive.hpp:61: error: `template<class T> void boost::archive::text_wiarchive_impl::load_override(T&, int) [with T = T, Archive = boost::archive::text_wiarchive]' is protected /home/cludwig/C++/boost_CVS_SF/boost/archive/detail/interface_iarchive.hpp:83: error: within this context The complete build log (presumably easier to read since not crumbled by the mail client) is available at <URL:http://tinyurl.com/6bsgv>. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

2 2

Re:[boost] Fixing broken links
by Robert Ramey 07 Oct '04

07 Oct '04

Aleksey Gurtovoy wrote: >It would be appreciated if the maintainers of the following libraries took >care of the corresponding issues listed in >http://www.meta-comm.com/engineering/boost/links.html: ... > serialization ... The links in question are both commented out with  . Perhaps the link checker might be persuaded to skip html comments? Robert Ramey

1 0

uBLAS broken on MSVC 6.5
by Aleksey Gurtovoy 07 Oct '04

07 Oct '04

Seems like some recent changes brought MSVC to its knees -- http://tinyurl.com/3vmlv. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re: [ross@biostat.ucsf.edu: Re: Formal Review of the SmartContainers library]
by Ross Boylan 06 Oct '04

06 Oct '04

I've snipped parts I'm not commenting on further. On Wed, Oct 06, 2004 at 01:39:55PM +0200, Thorsten Ottosen wrote: > > | I am also unable to get a program using the library to > |compile, and that definitely should be fixed if I haven't made a silly > |mistake. > > ok, did you use the review version or the older? If you send me the code, I > can take a look at it. Review version. I just sent my code in a separate (off-list) email. > > | My main motivations for using the > | library were that I was looking for a way to hide the implementation > | decision of whether I had containers of objects or pointers, and I had > | objects that were not copyable (and would have been expensive to copy). > | Even at that early stage, I found the documentation quite complete and > | extensive. > > well, it's not quite finish yet, but I'm glad I'm on the right track. I realize now I might have been able to get away with smart pointers, as I don't think they usually copy the objects they point to. But perhaps they would have gagged on the lack of copy c'tors? At any rate, the library under review was more straight-forward. And I did want to hide whether I was using objects or pointers to them; again, this library uniquely meets that need. > > | The library was easy to use, and it worked. > > ok, good to hear. > > |COMPILATION TROUBLES > | > |I got the version of the code in the review notice, and adjusted my code > |to use it (some directory names changed). I got a raft of errors, > |attached. > > this is of course unfortunate. I would like to know if you can actually > compile > the test files that comes with the library. > . I assume that I can't, as the notice said they didn't work with the release version of boost. I'm using 1.31. > > |STANDARD REVIEW QUESTIONS > | > |documentation really bear on the design. My major concern is that some > |algorithms are not safe to use on these containers. It is not clear to > |me that the average user can tell exactly which algorithms there are. > |If the latter is true, and there is any way to remedy it, it would be > |very good to do so. I think if this risky area is properly documented, > |it will be an acceptable risk. > > yeah, one thing that I have discussed with Pavol is to check for these errors > in > a debug mode. I will be able to check such violations at the next member > function access. For example: > > ptr_vector<T> vec; > std::remove_if( vec.ptr_begin(), vec.ptr_end(), something() ); > ... > vec.foo(); // this one triggers a debug check for all foo() That's a neat solution. Of course, it still requires the user to run a build in debug mode. > > | I favor a design with maximum > |compatibility with existing standard containers; it seems to me that has > |been achieved. > > ok, I guess you value that we can say eg push_back( T() ). I agree that we > should be > able to so for container<T> compatibility. > > | The documentation is extensive and quite good. I have many comments, > | which I will give below. The only point I consider really significant > | is that some of the reference material is a bit hard to navigate (I > | actually found the earlier version I looked at a bit clearer in this > | regard). > > yes, that will be fixed (one problem is of course there is so much > documentation). > I will probably use Jonathan T.'s java script tree-view, so users see a list > of sections of the docs in a left frame It would be nice to have a non-java version as well, as that is slightly problematic on some systems. For example, I could make java work with my current browser, but I haven't gone to the trouble. In terms of the documentation design, there are at least 3 use cases: 1) someone seeking initial familiarity with the library 2) someone who wants to know about a particular container 3) someone trying to decide which exact container to use, when they are already familiar with the library in general terms. I was mostly thinking of 2) in my comments. If you're very smart, you can think of all 3! For 2), one needs an easy way to get to the container in question, and then an easy way to see what it inherits. > |I've spent around a day, maybe more, using the library, studying the > |docs, and writing this review. As noted at the outset, I only went into > |the implementation details when I needed to figure out how something > |worked or debug a problem. Offsetting this signficant amout of time is > |my non-expertise in these matters! > > wow, that is quite a long time :-) Thanks for your effort.! You're welcome. I figured it was the least I could do in return for your effort. > > |DETAILED DOCUMENTATION COMMENTS > > [When I snip, it doesn't mean I will ignore your comments, but take it into > serious consideration when > working further on the docs and documentation] > > |* Reference to polymorphic class problem is puzzling in two ways. > |First, the section on the problem does not seem to state the problem > |directly (apparently it is how to ensure proper clean up of objects > |when we refer to them with pointers to a base class; perhaps it is > |also the fact that one can't have a list of such types directly, but > |need to use pointers). I had not heard of the problem and it doesn't > |seem like such a problem. > > I think I experienced the problem before I heard about it. > > http://pages.cpsc.ucalgary.ca/~kremer/STL/1024x768/ref2.html > http://www.oonumerics.org/tmpw00/kuehl.html Thanks; those are good references. > I should provide these references and improve the discription. > > | Second, it's not clear to me what smart > |containers add to this particular problem, given that smart pointers > |are available. > > I have used container< shared_ptr<T> > extensively and I still felt that > it didn't feel good. All the syntax is different with indirection all over the > place Good point. > and something as simple as vec.push_back( new Foo ) expanding into > vec.push_back( shared_ptr<Foo>( new Foo ) ) > and different cast styles etc. > > I usually can take such syntax, but I worked and do work with people that are > just plain confused by all that syntactic > overhead. For them, I think the smart pinter interface is part of the problem. > > |* Calling this the "smart container" library and then using names like > |"ptr_xxx" seems an invitation to confusion. "smart_xxx" would be more > |natural. At this point, it may be too much trouble and possibility > |for error to change the names, even if you agree with this point. > > Nothing is too late, but I don't agree on these names. Do you agree that having the containers in the "smart container" library called "ptr_xxx" is a bit confusing? > > |** I found it a bit difficult to find reference information. First, > |the material requires a fair number of clicks to reach. Second, it > |was not clear to me where to look for information that was not in a > |given entry. There are several reasons for this. > | > |The "see also" heading mixes material you must look at (base classes and > |pseudo-base classes such as reversible_smart_container) and classes that > |are simply related (e.g. ptr_vector and ptr_array). So it took me > |awhile to find the definition for auto_type used in, e.g., ptr_array. > > ok, I guess I should seperate "see also" and "alternatives". How about "inherits from" or "protocol from" instead of "see also"? > |** The unsafe mutating algorithms, in the FAQ now, probably deserves > |more prominence, in a discussion (in the main documentation) of what > |algorithms are appropriate to use with these containers. This item > |makes me nervous. First, it sounds as if only an implementor of a > |library would know which algorithms actually moved things around by > |swapping. This leaves the average user unsure of which algorithms are > |safe. Second, it seems like asking for trouble for it to be so easy > |to cause problems. > > yeah, if there is one rule in C++, then it must be "if you don't know what you > are doing, don't do it" :-) > > I promise you that I will expand this discussion to include a list of safe and > unsafe standard algorithms > and that debug builds will catch other errors. Can the safe and unsafe algorithms be know a priori, without knowing the implementation of the library? > > |4. Is the indirected predicates the right solution? > |It was exactly what I was looking for, so I'm inclined to say yes :) > > ok, I'm very close to saying that we only need one class, say > indirected_fun<Fun>, > which could replace all of these functions. Would you consider such a class > harder to use? Eg, > > instead of > > ptr_set< T, ptr_greater<T> > > > you had to write > > ptr_set< T, indirected_fun< std::greater<T> > > That's fine. I thought if I set ptr_set<T> I automatically got the indirected comparison. Would that be the case under either approach? Or have I forgotten how it works? > |9. Should we add iterators for traversing the keys of a map? This would > |mean we could say > | > |map::key_iterator b = m.begin(), e = m.end(); > |copy( b, e, some_where ); > | > |That would be useful. > > I asked John Torjo to provide > > copy( map_keys( m ), some_where ) > > in his range library. I think that would be a more generic solution. It would be good to mention that in the docs of this library. > > |13. Is the shared_ptr idea described in future directions a good idea? > |I'm not sure I grasp the concept well enough to comment, but it seems > |to me it kind of muddies the waters. That is, shared pointers are a > |different kind of ownership concept than this library, and I suspect > |it will be cleaner to keep them separate. I mean, mostly, cleaner for > |users. > > ok, noted. > > Let me explain what kind of flexibility we might achieve if this was possible. > > 1. once you discover that you want to observe pointers in the container, you > currently > would use a bald pointer hoping all goes well and the element is not > removed; if ptr_container<shared_ptr<T>> was > posible, you could just change a typedef to switch between safe/unsafe Ah, I think I get it. You share the pointer, but you still get the benefits of automatic indirection. > > 2. you get the indirected interface instead of the normal interface > > 3. you might switch between deep clone and shallow clone semantics of > shared_ptr's just by changing a typedef > to use a different clone_manager. > Yes, that probably would be worthwhile. One other point: in material you snipped, I advocated returning an iterator and throwing an exception if something goes wrong. As you pointed out in earlier correspondence, this actually goes against the standard library model, which doesn't throw exceptions in similar circumstances. Since, in general, compatibility is good, that's a mark against that approach. In this situation, my personal urge for convenience outweighs it, but you certainly shouldn't break compatibility without a conscious judgement.

2 1

[iostreams] Review Results -- Iostreams Accepted
by Jeff Garland 06 Oct '04

06 Oct '04

Jonathan Turkanis's Iostreams library has been accepted into boost. Final vote tally from reviewers was: 14 accepts 1 reject 1 abstain There were many issues brought up and resolved during the review. I won't even attempt to repeat all those here. There were also many interesting suggestions about enhanced approaches. Most reviewers recommended acceptance regardless of the resolution of these, so I leave it to Jonathan's capable hands to deal with those. Some issues that need to be resolved: 1) Overlap with current io and more io library Recommendation: Move the library to a new directory (iostreams) and document any overlap with other io libraries. Rationale: While there is overlap, iostreams is taking a somewhat new approach that departs a bit the approach of the I/O library. Both approaches have merit and rather than trying to combine them prematurely it would be better to have both available and see which approach is better in practice. Since there was some discussion about the library name during the review, but no conclusive conclusion I'm going to leave the directory name as an issue for open discussion on the list. 2) Memory-Mapped Library At the moment the portable memory-mapped library is an implementation detail of Iostreams. It would be best if this library could be brought out of detail and made a standalone library that could be used independently of Iostreams. We need a volunteer to take this on (sounds like Jonathan will help with this). 3) zip/bzip2 library components The library source currently contains headers for zlib and bzip2. These headers should be removed from the source tree since they will complicate boost licensing. They should be replaced with instructions on how to obtain these libraries and how to configure bjam to find the headers and libraries. Since these libraries are already widely distributed they are often already installed on a platform. 4) 'piping' interface There was some support for adopting a 'pipe like' interface as originally implemented by JC van Winkel in another library, eg: filter_stream out(tee(std::cout) | encode | gzip | file("some file")); While this interface is not required for adoption, Jonathan has already implemented and will provide this interface. 5) Resource concept naming There was a long discussion of the naming of the concept Resource -- should it be Device, etc. Final resolution of this issue needs to be discussed and adopted. 6) Presidential filter example While many of us see the humor in this, there was at least one objection to introducing 'political comedy' into boost. Overall, the example should be renamed and reformulated since in a few years no one will get the joke anyway. Sorry to go politically correct here, but boost needs to be above the fray. I'd like to thank the reviewers for their time and many thoughtful reviews. And finally thanks to Jonathan for an excellent library! Jeff

10 31

threads documentation caught in infinite loop
by Eric Niebler 06 Oct '04

06 Oct '04

From the threads release_notes page (http://tinyurl.com/6rrck) clicking next takes you to the threads glossary (http://tinyurl.com/66kq2) and clicking next from that page takes you to the threads design page (http://tinyurl.com/4huct) way back at the beginning of the threads doc. An infinite loop! -- Eric Niebler Boost Consulting www.boost-consulting.com

1 0

Renaming "c++boost.gif"
by Aleksey Gurtovoy 06 Oct '04

06 Oct '04

I'm planning on doing a massive search & replace throught the docs concerned with renaming "c++boost.gif" to "boost_logo.gif" (the former is not a valid ISO 9660/Level 2 name). Please speak up soon if you have any objections/concerns! -- Aleksey Gurtovoy MetaCommunications Engineering

15 34

Typo in time duration documentation
by Robert Zeh 06 Oct '04

06 Oct '04

The example for the duration_from_string has a small typo. It reads: time_duration duration_from_string(const std::string&) From delimited string. std::string ts("23:59:59.000"); time_duraton td(duration_from_string(ts)) The type time_duraton should be time_duration. In the current CVS, it looks like the typo is in boost/libs/date_time/xmldoc/time_duration.xml around line 160. Robert Zeh http://home.earthlink.net/~rzeh

2 1

Minimal test - unnecessarily hard to compile
by Alan Stokes 06 Oct '04

06 Oct '04

I've just tried to start using the minimal test facility. Unfortunately it fails to compile, and there's no way I can fix that without radically changing my build configuration. My code has #include "boost/test/minimal.hpp" in it; my include path includes a directory which has a boost directory within it containing all the boost headers, so this works fine. But minimal.hpp includes the line #include <libs/test/src/execution_monitor.cpp> which fails to compile - because my include path doesn't have a directory with the boost libs directory in it. And nor should it. This is unfortunate, and arguably a violation of the header policy (libs as a sub-directory name is highly likely to clash with other libraries, unlike boost). Header files should not be including implementation files. This is especially the case with the minimal test facility, whose whole point is to be usable without requiring linking with implementation files. Changing to textual inclusion of implementation files is not a great improvement. Could the necessary implementation detail not be moved into some header files, which can then be included as necessary by both the cpp files and minimal.hpp? (Note that this is not a new issue - see also http://lists.boost.org/MailArchives/boost/msg05435.php) - Alan

5 5

RFC: Extending boost::escaped_list_separator<> with an empty_token_policy.
by Eddy L O Jansson 06 Oct '04

06 Oct '04

Boost / Tokenizer / Escaped List Separator - empty_token_policy patch What? This url[0]/archive[1] contains a trivial patch to Boost 1.31.0 which extends the default escaped_list_separator<> tokenizer function with an optional empty_token_policy. In addition, a patch to update the documentation to reflect this change as well as a new example program demonstrating its use, is included also. The patch implements the safe default of boost::keep_empty_tokens such that a patched version of this library behaves exactly as the old one, unless specifically instructed not to. This is done by setting empty_tokens to boost::drop_empty_tokens in the constructor. Why? This gives you the usual benefits of "Escaped List Separator" -- the ability to specify and use escape and quote characters -- but without the downside of always having to deal with empty tokens by hand. This simplifies client code. The "empty tokens" policy is already available in the less sexy char_separator<> implementation, I simply brought it forward to escaped_list_separator<> too. Why not? It might be redundant. I might have fubared the implementation. Where? [0] http://klopper.net/~eddy/src/boost-tokenizer/ [1] http://gazonk.org/~eloj/files/temp/eloj-boost-tokenizer-policy-patch.rar -- "IBM clearly did contribute a lot of the Unix-related information into Linux. We just don't know what it is." -- Kevin McBride, legal mastermind. Eddy L O Jansson | http://gazonk.org/~eloj

1 0

[Boost-bugs] [ boost-Support Requests-1041059 ] Building Boost on mac os10
by SourceForge.net 05 Oct '04

05 Oct '04

Support Requests item #1041059, was opened at 2004-10-05 15:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1041059&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Building Boost on mac os10 Initial Comment: My name is Justin Heisler and i'm trying to build boost on my mac. I seem to have problems when I try the actual bjam -sTOOL=darwin command. It runs everything fine except fails on 6 targets. It says something about the -shared command not being recongized. Is there any way I can get help or work arounds? Thanks Justin heislerj(a)purdue.edu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1041059&group_… ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Status of Boost.Python docs?
by Christoph Ludwig 05 Oct '04

05 Oct '04

Hi, I tried to become acquainted with Boost.Python. But even the examples in the documentation won't compile. The examples leave the impression as if they are untested because they contain quite obvious errors. For instance, from libs/python/doc/v2/operators.html (current CVS): [...] struct number : boost::integer_arithmetic<number> { number(long x_) : x(x_) {} operator long() const { return x; } number& operator+=(number const& rhs) { x += rhs } number& operator-=(number const& rhs); { x -= rhs } number& operator*=(number const& rhs) { x *= rhs } number& operator/=(number const& rhs); { x /= rhs } number& operator%=(number const& rhs); { x %= rhs } long x; }; [...] There are spurious semicolons after the argument list of operators -=, /=, and %=. On the other hand, there are semicolons missing in the bodies of the in-place operators... OK, it was no problem to fix this. But if run on the complete operators example, the compiler (gcc 3.4.2 on 686-pc-linux-gnu) chokes nevertheless. And this time I can't make much sense out of the error messages. (In case someone is interested, the compiler output is online at <URL:http://tinyurl.com/5u3rr>.) The regression test table at <URL:http://boost.sourceforge.net/regression-logs/cs-Linux.html> shows a runtime failure of the operators test for gcc 3.4.2. So the corresponding C++ module could be compiled, in contrast to the example from the docs. The user-level report at the meta-comm site <URL:http://tinyurl.com/4ebxv> (last updated on Aug 11) shows that the operators test passed with gcc 3.4.1. Since the regression tests show some problems with gcc 3.4.2, I can't be completey sure whether the errors I see are due to a compiler / platform problem or to a erroneous example. Since the example contained errors that had nothing to do with Boost.Python and the compiler and since examples from the tutorial also failed I suspect the latter. Can someone explain how this particular example needs to be changed so it can be compiled? Will the examples in the docs be checked before the upcoming release? Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

3 5

re: size_t*size_t is not size_t
by Michael Stevens 05 Oct '04

05 Oct '04

On Tuesday 05 October 2004 15:19, Kasper Peeters <kasper.peeters(a)aei.mpg.de wrote: > I need to handle extremely large sparse matrices, of approximately > half a million square elements (with, typically, on the order of 5 > million non-zero entries). > > The following, however, fails on a machine where std::size_t is 4 > bytes long: > > #include <boost/numeric/ublas/matrix_sparse.hpp> > > int main () { > using namespace boost::numeric::ublas; > sparse_matrix<double> m(400000, 400000); > } I assume this is uBLAS from Boost 1.31.0 If that is the case the short answer is that you need a more recent uBLAS. The current Boost CVS HEAD will do. These overflow problem have been fix for a few months. Longer answer. Don't forget that uBLAS has several sparse format to choose from. You may find coordinate_matrix or compress_matrix more suitable then sparse_matrix. Your problem is very large and to get efficient solutions you may need to exploit any structure it has! > It fails with > > Assertion failed in file > boost/numeric/ublas/functional.hpp at line 1345: The overflow test BOOST_UBLAS_CHECK ((size1 * size2) / size1 == size2, bad_size ()); is quite amusing. It actually checks if the calculation has not already overflowed, with a small chance of a false positive. Michael -- ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

RE: [boost] Re: Graph broken for vc7.1 after 1.31?
by Christian Wahlgren 05 Oct '04

05 Oct '04

Hi again, I still can't compile the graph library after the last change on the 29:th of Sept. Strangely I see regression tests been run on vc7.1 since then and I wonder how that could be possible? http://www.meta-comm.com/engineering/boost-regression/developer/graph.html Regards, Christian -----Original Message----- From: Christian Wahlgren on behalf of Christian Wahlgren Sent: Thu 2004-09-30 09:06 To: boost(a)lists.boost.org Cc: Subject: RE: [boost] Re: Graph broken for vc7.1 after 1.31? Hi, Perhaps my fault - It wasn't that easy to just define YY_NO_UNISTD_H to make graph compile with vc7.1. The problem is that two non-ANSI C functions is called: b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0; A little documentation search on Win32 gives: <io.h> int _isatty(int); <stdio.h> int _fileno(FILE*); As for how to solve these non-portable stuff with perhaps some BOOST defines, I think you all know better than I do. Kindest Regards, Christian -----Original Message----- From: Doug Gregor [mailto:dgregor@cs.indiana.edu] Sent: Wed 2004-09-29 17:45 To: boost(a)lists.boost.org Cc: Subject: Re: [boost] Re: Graph broken for vc7.1 after 1.31? On Sep 29, 2004, at 9:25 AM, Vladimir Prus wrote: >> Were you able to check it on VC 7.1? > > No. I'd appreciate if you could try there. I'll try to do so later. > >>>> We'll deprecate it in 1.32.0 (when, hopefully, we will >>>> have a new GraphViz parser that works well) and remove it >>>> afterwards. >>> >>> How the new parser will be implemented? >> >> Spirit. > > Is it written yet? Would be interesting to see. I think the parser is written but the semantic actions are not, so it isn't functional yet. We're trying to unify on some kind of system for dynamic properties, so that we can deal with reading in arbitrary vertex/node attributes. I have a GraphML parser that handles dynamic properties, which hopefully will also work well in the new GraphViz parser. If I get some time post-1.32.0 (hah!), we'll try to get all those bits in. >> Granted, they've dropped support for older, broken compilers, >> so someone will still be getting hurt by this. > > Right. OTOH, I start to wonder if BGL should drop support for old > compilers > as well. (borland and vc6 are marked unusable already). There seem to > be a > lot of workaround inside BGL which means even reading the code hard. We promised to keep the parts of the BGL needed for the Python lib in working order. But I've marked borland and vc6 unusable because they've never really been usable and are a huge maintenance burden. Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

[1.32 Release] Fixing long filenames (continued)
by Aleksey Gurtovoy 05 Oct '04

05 Oct '04

First of all, thanks to everybody who responded to my original request. Things are looking better now, but we still have some way to go -- http://www.meta-comm.com/engineering/boost/long_names.html. I'm reciting the issues below with some comments/requests. archive ------- boost/archive/polymorphic_binary_wiarchive.hpp: filename > 31 chars boost/archive/polymorphic_binary_woarchive.hpp: filename > 31 chars Robert, could you please fix these? build ----- tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam: filename > 31 chars tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam: filename > 31 chars I'll take care of these two myself, but somebody from the Boost.Build camp needs to look/comment on these: tools/build/v2/test/railsys/libx/include/libx/test_libx.h: file's directory depth exceeds 8 levels tools/build/v2/test/startup/boost-root/tools/build/boost-build.jam: file's directory depth exceeds 8 levels tools/build/v2/test/startup/boost-root/tools/build/bootstrap.jam: file's directory depth exceeds 8 levels mpl --- libs/mpl/doc/ref/Extensible_Associative_Sequence.html: filename > 31 chars libs/mpl/doc/ref/Reference/BOOST_MPL_AUX_LAMBDA_SUPPORT.html: filename > 31 chars Obviously my department. property_map ------------ libs/property_map/const_associative_property_map.html: filename > 31 chars I can take care of it, but wouldn't mind delegating it either. Anybody? serialization ------------- libs/serialization/example/demo_portable_binary_archive.cpp: filename > 31 chars libs/serialization/test/test_demo_fast_binary_archive.cpp: filename > 31 chars libs/serialization/test/test_demo_portable_binary_archive.cpp: filename > 31 chars libs/serialization/test/test_polymorphic_archive_data.cpp: filename > 31 chars libs/serialization/test/test_polymorphic_archive_data.hpp: filename > 31 chars libs/serialization/vc6ide/demo_portable_binary_archive.dsp: filename > 31 chars libs/serialization/vc7ide/demo_portable_binary_archive.vcproj: filename > 31 chars libs/serialization/vc7ide/test_level_class_info_load.vcproj: filename > 31 chars libs/serialization/vc7ide/test_level_class_info_save.vcproj: filename > 31 chars libs/serialization/vc7ide/test_level_not_serializable.vcproj: filename > 31 chars libs/serialization/vc7ide/test_simple_derived_class.vcproj: filename > 31 chars Robert, again, this is your domain. spirit ------ libs/spirit/phoenix/doc/lazy_construction_and_conversions.html: filename > 31 chars Joel, Hartmut? test ---- libs/test/build/msvc71_proj/ifstream_line_iterator_test.vcproj: filename > 31 chars libs/test/build/msvc71_proj/test_case_template_example.vcproj: filename > 31 chars libs/test/doc/components/test_tools/reference/BOOST_CHECK_EQUAL_COLLECTIONS.html: filename > 31 chars libs/test/doc/components/unit_test_framework/components/test_case/abstract_interface.html: file path is > 100 chars libs/test/doc/components/unit_test_framework/components/test_case/auto_register_facility.html: file path is > 100 chars libs/test/doc/components/unit_test_framework/components/test_case/boost_function_test_case.html: file path is > 100 chars libs/test/doc/components/unit_test_framework/components/test_case/function_test_case.html: file path is > 100 chars libs/test/doc/components/unit_test_framework/components/test_case/parameterized_boost_function_test_case.html: file path is > 100 chars, filename > 31 chars libs/test/doc/components/unit_test_framework/components/test_case/parameterized_class_test_case.html: file path is > 100 chars, filename > 31 chars libs/test/doc/components/unit_test_framework/components/test_case/parameterized_function_test_case.html: file path is > 100 chars, filename > 31 chars libs/test/doc/components/unit_test_framework/components/test_case/test_case_template.html: file path is > 100 chars libs/test/doc/components/unit_test_framework/components/test_log/custom_log_formatter.html: file path is > 100 chars libs/test/test/test_files/errors_handling_test.pattern.gcc: filename > 31 chars Gennady, I realize this can be a bit of pain, but could you please take care of this? utility ------- libs/utility/enable_if_dummy_arg_disambiguation.cpp: filename > 31 chars libs/utility/enable_if_namespace_disambiguation.cpp: filename > 31 chars libs/utility/enable_if_partial_specializations.cpp: filename > 31 chars I'll deal with these myself. -- Aleksey Gurtovoy MetaCommunications Engineering

4 6

RE: [boost] RE: Re: Graph broken for vc7.1 after 1.31?
by Christian Wahlgren 05 Oct '04

05 Oct '04

Hi Vladimir, Thanks, it compiles now. Regression tests - yes, I see that now that the graphviz utility part isn't tested. Whish list: Since the graphviz utility code is part of the library it should preferably be tested also? Regards, Christian -----Original Message----- From: Vladimir Prus [mailto:ghost@cs.msu.su] Sent: Tue 2004-10-05 11:54 To: boost(a)lists.boost.org Cc: Subject: [boost] RE: Re: Graph broken for vc7.1 after 1.31? Hi Christian, > I still can't compile the graph library after the last change on the 29:th > of Sept. I've removed the calls to 'isatty', let me know if it works now. > Strangely I see regression tests been run on vc7.1 since then and > I wonder how that could be possible? > > http://www.meta-comm.com/engineering/boost-regression/developer/graph.html Because the regression tests do not build the graphviz parser? - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: JavaScript index?
by Jonathan Turkanis 05 Oct '04

05 Oct '04

"David Abrahams" <dave(a)boost-consulting.com> wrote in message news:uvfdwx3pm.fsf@boost-consulting.com... > > As long as we're tweaking the BoostBook look-and-feel, I'd like to > know the status of the "portable JavaScript index tree" project we > were discussing recently. I've even forgotten who was working on it > (shame on me). That would be me. :-) The docs are here: http://tinyurl.com/6tdvy. It's essentially finished, except for two points: 1. If it's integrated into Boost.Book, the documentation can be self-synchronizing, eliminating most need for the [link to this page] button. I think Reece Dunne did some work in this direction. 2. I'm planning to write a perl script which will make documentation writtenwith the tree control self-synchronizing even if it's not generated by Boost.Book. To understand what I mean by synchronization, see http://tinyurl.com/49hwe. Also note that the docs look better when the boost logo appears directly over the table of contents, as it does here: http://tinyurl.com/3p79x. Best Regards, Jonathan

9 22

size_t*size_t is not size_t
by Kasper Peeters 05 Oct '04

05 Oct '04

Hi, I need to handle extremely large sparse matrices, of approximately half a million square elements (with, typically, on the order of 5 million non-zero entries). The following, however, fails on a machine where std::size_t is 4 bytes long: #include <boost/numeric/ublas/matrix_sparse.hpp> int main () { using namespace boost::numeric::ublas; sparse_matrix<double> m(400000, 400000); } It fails with Assertion failed in file boost/numeric/ublas/functional.hpp at line 1345: (size1 * size2) / size1 == size2 Obviously, while both size1 and size2 fit in a 4-byte integer, the product does not, the calculation overflows, and this check fails. Can this problem be circumvented without modifying boost? Kasper

1 0

[test] problem in boost/test/detail/class_properties.hpp?
by Joaquín Mª López Muñoz 05 Oct '04

05 Oct '04

A recent update in boost/test/detail/class_properties.hpp replaces line 163: #ifndef __IBMCPP__ with #if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) I guess this is an error, since the checks are just the opposite. BTW, this change seems to be producing many regressions in Visual Age, all of them reported for boost/test/test_tools.hpp. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[multi_index] volunteer needed for small test with VC 7.0
by Joaquín Mª López Muñoz 04 Oct '04

04 Oct '04

Hi, recent changes in the CVS result in failures in Boost.MultiIndex for MSVC 7.0, see for instance: http://tinyurl.com/5nqv7 The problem seems to be ETI-related, and maybe I can apply the same patch already in effect for MSVC 6.0. If anyone with local access to MSVC 7.0 could help me try this, I'd be eternally grateful: * Update the CVS (the whole tree, please) * Change line 35 of boost/multi_index/detail/node_type.hpp #if BOOST_WORKAROUND(BOOST_MSVC,<1300) to #if BOOST_WORKAROUND(BOOST_MSVC,<1310) (note the change in VC version) * Change line 36 of boost/multi_index/detail/base_type.hpp #if BOOST_WORKAROUND(BOOST_MSVC,<1300) to #if BOOST_WORKAROUND(BOOST_MSVC,<1310) * run the tests for multi_index and report the results. Thank you very much in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

re: [Thread] The last step
by Michael Stevens 04 Oct '04

04 Oct '04

On Friday 01 October 2004 15:32, "Aleksey Gurtovoy" <agurtovoy(a)meta-comm.com> wrote: > You can probably guess what I'm about to ask -- can we do something > about Intel 8.0/Linux failures? Looking at the output below (from > http://tinyurl.com/6mnzn) it seems to me that the test was attempted > to be linked against *both* GCC and Intel runtimes: I think the problem is that the compiler is running on a platform where the version of glibc is unsupported (too recent). I have come across the same problem myself. After much research I found the only workaround was to rename strol in the compilers libcprts.a This is a big hack but gets things compiling. I have a already manipulated libcprts.a but it is 1M. I can post it to whoever needs it however. Michael

3 3

RE: [boost] Proper threading (Was: Formal review of "Output Forma tters" library beginstoday )
by Rozental, Gennadiy 04 Oct '04

04 Oct '04

> Rozental, Gennadiy wrote: > > Hi, > > > > I would like to start with resolution. I vote NOT to accept this > > submission. > > Gentlemen, may I ask that you use mailers which preserve > correct threading? In > particular, in review of the outfmt library, each message > from Reece, Robert > and Gennadiy is completely unrelated to the thread, missing > the "References" > and "In-reply-to" headers. > > This makes follow the thread a nightmare. Even web-based > mailers nowdays > support proper threading. What do you do to break it? I use Outlook. In some cases it preserve "threading". In some not. Gennadiy.

9 12

Re: [review] Formal review of the Smart Container library starts today]
by Pavol Droba 04 Oct '04

04 Oct '04

Hi, First of all, I'd like to thank Thorsten for bringing up this library. It implements a very common programming pattern that is currently missing in STL or Boost. > * What is your evaluation of the design? I find the design sufficient and reasonable for the purpose of the library. There is only one important issue, that I find problematic (I have already mentioned it in the other mail). The issue is about the direct write access to the contained pointers, via the ptr_iterator. Using this interface, all invariants of the underlying container can be broken. It is not even possible to validate the problem. Therefor I suggest to remove it, unless it can be fixed. Still this access can be usefull from time to time, but I simply don't think, that it is worth the problems, it can bring. Documentation is not very clear about the problems. It merely notes, that algorithms like std::remove should not be used with the ptr_iterator. There is no explanation which algorithms are 'safe' and why are the others unsafe. After small analysis I have found out that there is actualy a very narrow set of algorithms that can be used (I have explained this in detail in the other mail). All these algorithms can be provided as member functions (similary like current remove and unique algorithms) or can be reimplemented with a help of swap_element(size_type, size_type) function (or something similar). Other small issues: * CloneManager::operator(). I don't like this notation. I would prefer something more explicit. I see no clear connection between this operator and the operation it provides. Also I don't understand the asymetry between CloneManager::clone function and operator(). Former is static, while the later is member function. Why? * I would like to see explicit allocator specification for underlying container. There were good reasons to provide it in the STL and from the same reasons I'd like to see it here. * Current implementation is restricted to non-null values. Still I think, that null support could be useful. Few functions for checking like is_null(index) and iterator.is_null() could handle do job. > * What is your evaluation of the implementation? I find the implementation good enough to be included in the boost. > * What is your evaluation of the documentation? Documentation is sufficient for the understanding the library, but there are several posibilities for improvements. First, I agree with point that was already mentioned here, that several small examples are better a long one. Introductory example is too long to be easily comprehended in the first reading. There is lot of rules and guideling that are explained only in a few sentences. Some of them would greatly benefit from a small example and others (like the one about 'safe' algorithms) are very underspecified. I would presonaly prefer several smaller hyperlinked files to a one long document. Although it is easier to print it, I found it harder to read it in the browser. > * What is your evaluation of the potential usefulness of the library? I think, that the library is very usefull. As I said it implements very common pattern, that is not sufficiently solved otherwise. > * Did you try to use the library? With what compiler? Did you have any problems? I have not compiled the library. > * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Few hours of reading the documentation and code and thinking about the possible issues. Also I spend some time in discussion with the author. > * Are you knowledgeable about the problem domain? This library deals with a common problem. I consider myself knowledgeable in this domain. > * Do you think the library should be accepted as a Boost library? > Be sure to say this explicitly so that your other comments don't obscure your > overall opinion. Yes, I do think that the library should be ACCEPTED as a Boost library. However I would like to see the issues I have described to be solved, or at least explained in the documentation in the sufficient detail. Here are my answers for some questions asked in the documentation: > 1. The reference type, SmartContainer::reference is indirected. This has the unfortunate consequence that eg. > we cannot use eg. ptr_vector with std::stack. The question is if its worth adding another policy just to achieve this. Considering the library purpose, I think, that the current state is sufficient. > 2. Is the ptr_array class worth the trouble? I would like to see it. Especialy if the null-value can be supported. > 3. The clone manager effective removes allocators from the container template parameter interface. > Can people who want to use allocators still do what they want? Yes, I'd like to see it there. > 5. Should SmartContainer::auto_type expose itself as a move_ptr? Unless the move_ptr would became a self-contained utility, possibly as another library, I think it should stay like this. > 6. Should iterator range versions of assign() and insert be replaced by an Boost.Range version? Ie, should we have > template< class SinglePassRange > > void insert( const Range& r ); > > instead of > > template< class InputIterator > > void insert( InputIterator f, InputIterator l ); Boost.Range is already a part of boost. I think that the later interface is obsolete now. > 10. should transfer() return iterator or iterator/bool pair like erase()/insert() do. For map, transfer has similar semantics to insert. I think, that interfaces should be similar as well. > 12. should we provide member algorithms for unsafe standard algorithms like unique() and remove? Eithter provide them as member function, or provide a means for standalone implementation. In any case it is wise to provide some functional variant. Best Regards, Pavol

2 6

vc8.0 toolset (bjam)
by John Torjo 04 Oct '04

04 Oct '04

Hi all, I finally installed vc8 beta. It seems that vc8-tools.jam has the path to the binary MSVC tools wrong: It is: VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio .NET Whidbey\\VC7" ; But I think it should be: VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio 8\\VC" ; At least that's what's needed on my machine... As a side note, I got a lot of warnings: cl : Command line warning D9035 : option 'GX' has been deprecated and will be re moved in a future release cl : Command line warning D9036 : use 'EHsc' instead of 'GX' Best, John -- John Torjo -- john(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)

9 20

Yet another ScopeGuard
by Konstantin Echenko 04 Oct '04

04 Oct '04

Hi All. Some time ago Maxim Yegorushkin suggested use boost/bind to implement lazy ScopeGuard. I evolved this parasitic idea and reused a lot of code from boost/bind by preprocessing to implement make_guard binders. The ScopeGuard can be used as usual: scope_guard g = make_guard( func, args ); What do you think about it? Is it possible to "legalize" such approach? ========= #ifndef SCOPE_GUARD_HPP_INCLUDED #define SCOPE_GUARD_HPP_INCLUDED // scope_guard.hpp #include <boost/bind.hpp> //////////////////////////////////////////////////////////////////////////////////////////////// namespace boost { //////////////////////////////////////////////////////////////////////////////////////////////// namespace _bi { //////////////////////////////////////////////////////////////////////////////////////////////// class scope_guard_base { public: void dismiss() const { do_rollback_ = false; } protected: scope_guard_base(const scope_guard_base& other) : do_rollback_(other.do_rollback_) { other.dismiss(); } scope_guard_base() : do_rollback_(true) {} mutable bool do_rollback_; }; //////////////////////////////////////////////////////////////////////////////////////////////// template<class R, class F, class A> class scope_guard_impl : public scope_guard_base { public: scope_guard_impl(F f, A const& a) : rollback_(f, a) {} ~scope_guard_impl() { if(do_rollback_) rollback_(); } private: bind_t<R,F,A> rollback_; }; //////////////////////////////////////////////////////////////////////////////////////////////// } // namespace _bi //////////////////////////////////////////////////////////////////////////////////////////////// typedef _bi::scope_guard_base const& scope_guard; //////////////////////////////////////////////////////////////////////////////////////////////// // create make_guard() definitions by preprocessing boost::bind() sources #undef BOOST_BIND // it seems like authors forgot about it #define BOOST_BIND make_guard #define bind_t scope_guard_impl //////////////////////////////////////////////////////////////////////////////////////////////// // quotation from boost/bind.hpp // Copyright (c) 2001, 2002 Peter Dimov and Multi Media Ltd. // Copyright (c) 2001 David Abrahams // function pointers #define BOOST_BIND_CC #define BOOST_BIND_ST #include <boost/bind/bind_cc.hpp> #undef BOOST_BIND_CC #undef BOOST_BIND_ST #ifdef BOOST_BIND_ENABLE_STDCALL #define BOOST_BIND_CC __stdcall #define BOOST_BIND_ST #include <boost/bind/bind_cc.hpp> #undef BOOST_BIND_CC #undef BOOST_BIND_ST #endif #ifdef BOOST_BIND_ENABLE_FASTCALL #define BOOST_BIND_CC __fastcall #define BOOST_BIND_ST #include <boost/bind/bind_cc.hpp> #undef BOOST_BIND_CC #undef BOOST_BIND_ST #endif #ifdef BOOST_BIND_ENABLE_PASCAL #define BOOST_BIND_ST pascal #define BOOST_BIND_CC #include <boost/bind/bind_cc.hpp> #undef BOOST_BIND_ST #undef BOOST_BIND_CC #endif // member function pointers #define BOOST_BIND_MF_NAME(X) X #define BOOST_BIND_MF_CC #include <boost/bind/bind_mf_cc.hpp> #undef BOOST_BIND_MF_NAME #undef BOOST_BIND_MF_CC #ifdef BOOST_MEM_FN_ENABLE_STDCALL #define BOOST_BIND_MF_NAME(X) X##_stdcall #define BOOST_BIND_MF_CC __stdcall #include <boost/bind/bind_mf_cc.hpp> #undef BOOST_BIND_MF_NAME #undef BOOST_BIND_MF_CC #endif #ifdef BOOST_MEM_FN_ENABLE_FASTCALL #define BOOST_BIND_MF_NAME(X) X##_fastcall #define BOOST_BIND_MF_CC __fastcall #include <boost/bind/bind_mf_cc.hpp> #undef BOOST_BIND_MF_NAME #undef BOOST_BIND_MF_CC #endif // end quotation boost/bind.hpp /////////////////////////////////////////////////////////////// #undef BOOST_BIND #undef bind_t //////////////////////////////////////////////////////////////////////////////////////////////// } // namespace boost //////////////////////////////////////////////////////////////////////////////////////////////// #endif // #ifndef SCOPE_GUARD_HPP_INCLUDED ============= Regards, Konstantin Echenko

5 9

Re: [ublas] Intel 8.1 failures
by Michael Stevens 04 Oct '04

04 Oct '04

Stefan wrote: > I've marked them as expected. Anyway, it's not clear to me why they > don't occur on Intel 8.0. It is because the test harness specifically avoids using std::complex for intel-windows 8.0 and earlier! 8.0 is also buggy. I know this is confusing, but without this special case to avoid link failures I cannot see if there are any runtime errors. This is more important to me then this annoying corner case. At the current pace Intel will never fix this bug! So I will probably extend the condition to 8.1 and remove the markups. For now I would rather the failures show up for the Intel compiler people to see!! Michael

1 0

Re: ublas / cw 8.3
by Michael Stevens 04 Oct '04

04 Oct '04

Stefan wrote: > Anyway, as I could see in cvs, Micheal has now removed the markup. Results are in now. You can see cw-8.3-release has no problems. cw-8.3 has the old compile time errors. I not sure if there is a good reason if this is because the two are subtly different compiler versions or incidental compiler options. The compiler options are available for the failing run but not the pass runs. Unless a cw-8.3 guru see an obvious problem has a quick fix then I will look into modifying the source to avoid this compiler confusion. The error is always at the point of the following or similar instantiations indexing_matrix_assign (functor1_type::template make_debug_functor<typename matrix<value_type, row_major>::reference, value_type> (), cm, e, row_major_tag ()); I believe the 'template make_debug_functor<..> ()' is the source of the problem. This could be replaced by a static member template which deduces which functor type to return. Michael

1 0

RE: [boost] Re: Long toolset names
by Stefan Seefeld 04 Oct '04

04 Oct '04

> From: Tony Juricic [mailto:tonygeek@yahoo.com] > Sent: October 1, 2004 11:10 > As far as MS VS IDE is concerned, build directory names like "debug > runtime-static threading-multi" (with the space character) > would make life > easier than directory tree like the current > "...debug/runtime-static/threading-multi" because the string "debug > runtime-static threading-multi" can become > $(ConfigurationName) macro in > IDE. I'd strongly suggest not to use spaces in file / directory names, as that makes life unnecessarily hard for users of command-line tools. But I agree that collapsing some option sets into single directory names would be quite convenient. Regards, Stefan

5 4

Long toolset names
by Aleksey Gurtovoy 04 Oct '04

04 Oct '04

What should we do about the following Boost.Build toolsets which filename's length exceeds 31 characters: tools/build/v1/como-win32-4.3.3-vc7.1-tools.jam tools/build/v1/intel-win32-7.1-vc6-stlport-4.5.3-tools.jam ? -- Aleksey Gurtovoy MetaCommunications Engineering

7 12

New Linux regressions
by Aleksey Gurtovoy 04 Oct '04

04 Oct '04

We seem to have an alarming number of new regression with two Linux toolsets, "gcc-2.95.3-stlport-4.5.3-linux" and "intel-8.0-linux" -- http://tinyurl.com/5p5ru. Intel looks particularly bad, due to what seems to be a problem with system headers: /opt/intel_cc_80/include/c++/functional(132): error: identifier "_Tq" is undefined ?bool operator()(const _Ty& _Left, const _Tq& _Right) const ? ^ detected during instantiation of class "std::less<_Ty> [with _Ty=boost::detail::sp_counted_base *]" at line 432 of "/boost/head-regression/boost/boost/detail/shared_count.hpp" compilation aborted for /boost/head-regression/boost/libs/test/build/../src/test_tools.cpp (code 2) . /opt/intel_cc_80/bin/iccvars.sh icpc -c -w1 -DBOOST_TEST_NO_AUTO_LINK=1 -g -O0 -I"../bin/boost/libs/test/build" -I"/boost/head-regression/boost" -o "../bin/boost/libs/test/build/libboost_test_exec_monitor.a/intel-8.0-linux/debug/test_tools.o" "/boost/head-regression/boost/libs/test/build/../src/test_tools.cpp" The problems with GCC/STLPort are different: the linker cannot find a number of different _STL:: symbols that supposedly should be present in the library: Linker output [2004-10-02 04:30:36 UTC]: ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x501): In function `boost::execution_monitor::execute(bool, int)': /boost/head-regression/boost/libs/test/src/execution_monitor.cpp:245: undefined reference to `_STL::domain_error type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x5c5):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:247: undefined reference to `_STL::invalid_argument type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x691):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:249: undefined reference to `_STL::length_error type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x765):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:251: undefined reference to `_STL::out_of_range type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x841):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:253: undefined reference to `_STL::range_error type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x915):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:255: undefined reference to `_STL::overflow_error type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x9f1):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:257: undefined reference to `_STL::underflow_error type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0xac5):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:259: undefined reference to `_STL::logic_error type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0xba1):/boost/head-regression/boost/libs/test/src/execution_monitor.cpp:261: undefined reference to `_STL::runtime_error type_info function' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x18d9): In function `main': /boost/head-regression/boost/boost/test/minimal.hpp:135: undefined reference to `_STL::cerr' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x1959):/boost/head-regression/boost/boost/test/minimal.hpp:141: undefined reference to `_STL::cout' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x1b2f):/boost/head-regression/boost/boost/test/minimal.hpp:130: undefined reference to `_STL::cerr' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x1cba): In function `__static_initialization_and_destruction_0': /usr/local/gcc-2.95.3/stlport-4.5.3/include/stlport/locale:145: undefined reference to `_STL::ios_base::_Loc_init::_Loc_init(void)' ../bin/boost/libs/dynamic_bitset/dyn_bitset_unit_tests1.test/gcc-2.95.3-stlport-4.5.3-linux/debug/dyn_bitset_unit_tests1.o(.text+0x1cca): In function `__static_initialization_and_destruction_0': /usr/local/gcc-2.95.3/stlport-4.5.3/include/stlport/iostream:71: undefined reference to `_STL::ios_base::Init::Init(void)' ... It might be a problem with the toolset, but it's hard to say without seeing the linker's command line. Martin, would it be possible for you to modify your regression driver to always run with "-d2" flag? In any case, any help on timely resolution of the above issues would be highly appreciated. -- Aleksey Gurtovoy MetaCommunications Engineering

3 2

[ublas] Intel 8.1 failures
by Stefan Slapeta 04 Oct '04

04 Oct '04

An old Intel failure popped up here. I don't know why this doesn't occur on 8.0 anymore! A workaround is not using the shared runtime. Thoughts? Stefan

3 3

re: ublas / cw 8.3
by Michael Stevens 04 Oct '04

04 Oct '04

Stefan, > Is there a particular reason why ublas is marked unusable for cw 8.3? > > Stefan > It used to give a lot of nasty template errors of the form: # 678: :, value_type> (), cm, e, row_major_tag ()); # Error: ^ # illegal template argument dependent expression I say 'used to' because the results are now hidden behind the grey 'n/a'. I doubt there is much that can be done however. If you have better information and the compiler we could take a look! Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

4 5

Re:[boost] Re:Re: Output formatters: different approaches
by Robert Ramey 04 Oct '04

04 Oct '04

http://lists.boost.org/MailArchives/boost/msg71956.php Message: 2 Date: Fri, 01 Oct 2004 10:54:02 +0400 From: Vladimir Prus <ghost(a)cs.msu.su> Subject: Vladimir Prus wrote: >Robert, can I first of all ask you to use a mailer, or a news reader, which >preserves threading? Recently experiments have shown that Mozilla >Thunderbird, for example, works fine both with emails and with NTTP >gateway, and it's free. You can also try some other clients, but please do >something about the issue. Hmmm - I've been trying to configure my MS Outlook to do this and its driving me crazy. >>> The idea of the library, as I see it, is to provide object >>> serialization, > but >>> - without the overhead serialization library has >>> - with extra layout tweaks > >>Yes, it would be nice. > > For objects of the type being discussed, (i.e. no pointers, no class > versioning, no memory tracking of duplicates, etc) the serialization > library has no extra runtime overhead. >Basically, I want every call I define to have a 'dump' >method which can be called from debugger. So, I need output facilities >available in every translation unit. >> If function output formatters is helpful for making output more easily >> presentable, fine. Though G. Rozenthal's, experiment makes me doubt this. >Which experiment? I was referring to Rozenthals post: http://lists.boost.org/MailArchives/boost/msg71956.php [On the other hand, if output formatters is to be an alternative implementation of the functionality in the serialization library ] >> I believe the demos and documentation in the serialization package show >> that it to be much, much easier to use than the proposed library for this >> purpose. >Robert, while I agree that serialization is immensely useful, the point you >make above is a bit skewed. Which example in the serialization library >shows how to change start/end delimiter of a vector? That's what the xml_archive does for name-value pairs. The same method could be used for any user defined types. Robert Ramey

3 4

RE: [boost] Re: Call for Volunteers: the Synopsis project
by Stefan Seefeld 04 Oct '04

04 Oct '04

> From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: September 30, 2004 08:21 > Stefan has recently been trying to get compile-time constants from > sizeof() into the parser. As he knows, this is going to mean handling > such things as template instantiation and overload resolution. This > is a great opportunity to learn more about how C++ works and to create > a compiler platform that's actually usable by C++ programmers for > prototyping new features -- one of the major obstacles in C++ > standardization is that the source for the only open-source C++ > compiler has a steep learning curve. I should mention that the design of the C++ parser allows to manipulate the generated parse tree in-memory and write it out into a file again in a non-lossy way, i.e. it could indeed be used as a source-to-source compiler. Regards, Stefan

3 2

BGL: BCBuilderX compiler error
by Kaled Ahmed 04 Oct '04

04 Oct '04

The following snippet from the BGL User Guide and Reference Manual, gives an error using Borland CBX: template <typename Graph, typename TransDelayMap, typename VertexNameMap> void print_trans_delay( typename graph_traits<Graph>::edge_descriptor e, const Graph& g,TransDelayMAp delay_map, VertexNameMap name_map) { std::cout << "trans_delay(" << get(name_map, source(e,g)) << "," << get(name_map, target(e,g)) << ")= " << get(delay_map, e); } The error is: "untitled.cpp": E2449 Size of 'print_trans_delay' is unknown or zero at line 27 Please advise. --------------------------------- Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage!

2 1

New multi_index failures (--> mpl??)
by Stefan Slapeta 04 Oct '04

04 Oct '04

http://tinyurl.com/4nrt9 Aleksey, could this be a side effect of the last mpl fix for boost.test? Stefan

3 2

Some questions on boost threads
by Parameswaran, Vinod 04 Oct '04

04 Oct '04

Hello list, My name is P. Vinod and I am currently debugging an application that was initially written using single thread but later ported to multithreads. The threading has been done using Boost library functions. I am new to Boost library and would like to clarify some of my doubts with you. Please reply to vparameswaran(a)fcg.com I have been studying William Kempf's documentation on Boost threads (http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/threads .html) and all my questions are based on the references therein: 1. <begin quote> The template thread_specific_ptr <http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/class.b oost.thread_specific_ptr.html> is useful in the following cases: * An interface was originally written assuming a single thread of control and it is being ported to a multithreaded environment. <end quote> Is there any other way by which you could port a single threaded interface to multithreaded interface using Boost threads? My debugging approach will be based on your answer to this question. 2. Does anyone have some examples of scenarios wherein each of these classes could be used (would even appreciate reference to relevant docs., if any): a. barrier b. condition c. thread_group d. thread_specific_ptr 3. Assumption: In the case of a condition object, ONLY THE FOLLOWING METHODS could be used to specify the wait condition: a. template<typename ScopedLock, typename Pred> void wait(ScopedLock& lock, Pred pred); b. template<typename ScopedLock> bool timed_wait(ScopedLock& lock, const bool::xtime& xt); c. template<typename ScopedLock, typename Pred>bool timed_wait(ScopedLock lock, Pred pred); Is this correct? 4. <begin quote> A thread object has an associated state which is either "joinable" or "non-joinable". <end quote> Is this state indicated using a type or is merely implied by whether the default or the parameterized constructor is called for the creation of the thread object? 5. Could anyone give examples of the use of void join() and void yield()? (Would even appreciate reference to relevant docs., if any) 6. <begin quote> Template thread_specific_ptr stores a pointer to an object obtained via new on a thread-by-thread basis and calls delete on the contained pointer when the thread terminates. Each thread initially stores the null pointer in each thread_specific_ptr instance. <end quote> Does each thread create its own 'object' referred to here and modify its thread_specific_ptr class by invoking void reset(T* p=0) ? 7. <begin quote> The template thread_specific_ptr is useful in the following cases: * Each thread of control invokes sequences of methods that share data that must be logically accessed through a globally visible access point, but are physically unique for each thread, instead of being explicitly passed. <end quote> <begin quote> Template thread_specific_ptr stores a pointer to an object obtained via new on a thread-by-thread basis and calls delete on the contained pointer when the thread terminates. Each thread initially stores the null pointer in each thread_specific_ptr instance. <end quote> >From the above statements, I could draw the inference that the thread_specific_ptr object stores the data that is shared amongst the various methods invoked from within a thread; however this data is not shared amongst threads and is unique for each thread. <begin quote> thread_specific_ptr construct/copy/destruct 1. thread_specific_ptr(); Requires: The expression delete get() is well formed. Effects: A thread-specific data key is allocated and visible to all threads in the process. Upon creation, the value NULL will be associated with the new key in all active threads. <end quote> <begin quote> 1. ~thread_specific_ptr(); ..... For this reason you should not destroy a thread_specific_ptr <http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/thread_ specific_ptr.html> object until you are certain there are no threads running that have made use of its thread specific storage. <end quote> The above statements seem to contradict the previous quotes, in that a thread-specific data key is visible to all the threads in the process and thread-specific storage is shared amongst multiple threads. Could anyone dispel the apparent ambiguity here? Also, what is the concept of "data key"? Gratefully appreciate your time and advice on the above. Vinod

1 0

White cells in regression tables?
by David Abrahams 04 Oct '04

04 Oct '04

I posted this yesterday, but got no reply. Can anyone explain the vast number of white cells in the Boost.Python regression log? In particular, the tests noted below don't look like they're reported correctly in the log. ------ Due to what appears to be an MPL problem, neither libs/python/test/polymorphism.cpp nor libs/python/test/polymorphism2.cpp are compiling on vc6. This fact is reflected only strangely by the posted regression log, as white cells. ------ -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

4 7

*Attention*: ISO 9660/names with multiple dots
by Aleksey Gurtovoy 04 Oct '04

04 Oct '04

Gentelmen, Apparently, ISO 9660, including Levels 2 and 3, does not allow names containing more than one dot character (see, for instance, http://www.gnscd.com/iso.htm) The requirement has always been present in our file/directory naming guidelines -- http://www.boost.org/more/lib_guide.htm#Directory_structure, but was never checked/inforced. As the result, currently we have quite a number of files (249!) that will have to be renamed before we can put them on an ISO 9660 CD -- see http://www.meta-comm.com/engineering/boost/names_with_dots.html. Note that this doesn't include BoostBook-generated documentation (since it is not in the current CVS), which uses multiple dots convention for the generated HTMLs all over the place. It's not going to be terribly hard to fix all these issues, but I wanted to bring this to everyone's attention to make sure that there is a consensus that this is a right thing to do, and that the benefits are worth the trouble. -- Aleksey Gurtovoy MetaCommunications Engineering

3 2

[Poll] New look-n-feel for Boost documentation
by Eric Niebler 03 Oct '04

03 Oct '04

Joel de Guzman and I, with the help of many smart folks on the boost-docs list[*], have been working on improving the look-n-feel of Boost's documentation. We're ready to commit the new style, but wanted to check here first. Volodya was good enough to put up a copy of Boost's docs with the new style applied. You can preview them here: http://zigzag.lvk.cs.msu.su/~ghost/boost_docs/ Please say whether you like the new style or not. If not, be specific about why. If you are the author of Boost documentation, please have a look at your docs in the new style and see if anything is out of place. [*] Thanks to Doug Gregor, Vladimir Prus, Dave Abrahams, Reece Dunn, Jeff Garland, Rene Rivera and others for their valuable feedback regarding the new style. -- Eric Niebler Boost Consulting www.boost-consulting.com

22 52

Order of entries in the Bibliography section?
by Joaquín Mª López Muñoz 03 Oct '04

03 Oct '04

I've noticed entries do not follow any definite order. Print publications are more or less sorted by year, but other sections are seemingly listed at random. I propose the following: * Inside each section, sort lexicographically by year and author, for instance online mentions would get like this [Burnap02] [Curran02] [Siek02b] [Casad03] [Lischner03] [Stein04] * Add this policy in the "How to update this page" section. If people are happy with this, I volunteer to do the changes. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 9

Re: [boost] [Poll] New look-n-feel for Boost documentation
by brangdon＠cix.compulink.co.uk 03 Oct '04

03 Oct '04

In-Reply-To: <e094f9eb040930020665f195c5(a)mail.gmail.com> rogiervd(a)gmail.com (Rogier van Dalen) wrote (abridged): > I'd suggest either not overriding the browser's font settings > for paragraph text, or using a serif font. I feel the same. I find the text a bit too big. It's a bit like reading a children's large-print book. I'd also prefer it not to override my colour settings. My default background is not white. Overall I think it looks better. I had a quick look from my mobile phone, and it worked reasonable well. (You might want to try that yourself, if you haven't already.) -- Dave Harris, Nottingham, UK

2 1

RE: [boost] Re: [shared_ptr] Interlocked* - possible bug?
by Ben Hutchings 03 Oct '04

03 Oct '04

Peter Dimov <pdimov(a)mmltd.net> wrote: > Alexander Terekhov wrote: > > Peter Dimov wrote: <snip> > >> The observable behavior is > >> > >> write volatile @a 1 > > > > nop > > > >> read volatile @a x > > > > nop > > > >> write volatile @a x-1 > > > > nop > > > >> exit(x-1) > > > > push 0 > > call _exit > > > >> > >> in the first case, and > > > > Happy now (debugger notwithstanding)? > > No. A conforming compiler is not allowed to do that. > > > C'mon, volatile is brain-dead. > > Nobody's arguing otherwise. ;-) But a nop it isn't. I think Alexander is arguing that without a clear definition of what it means for a memory access to be "observable", the fact that volatile memory accesses are "observable behaviour" doesn't prevent them from being optimised away under the as-if rule. I expect most implementations treat "observable" as "observable by a software or hardware debugger", but of course the standard doesn't and can't say that.

3 4

[type_traits] alignment_of_test problem in Intel Linux
by Joaquín Mª López Muñoz 03 Oct '04

03 Oct '04

The problem (see for instance http://tinyurl.com/4j87e) seems to be a trivial confusion with the digraph <: I guess all it takes to fix this is to rewrite line 35 in alignment_of_test.cpp #define ALIGNOF(x) align_calc<x>::get() as #define ALIGNOF(x) align_calc< x>::get() (note the extra blank). OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 5

Re:[boost] [serialization] test_level_class_info_load*...
by Robert Ramey 03 Oct '04

03 Oct '04

Stefan Slapeta >...is marked as expected failure for all toolsets! Is this really intended? >(What does us tell a test that is expected to fail everywhere?) This is marked with the ref note - "fails intermittently" - the failure is an result of the fact I haven't been able to make Jamfile run tests in a particular sequene. I could remove the markup - but that would leave several failures as expected when in fact I know what they are. Robert Ramey

3 2

[Boost-bugs] [ boost-Support Requests-1039338 ] Visual C++ "Language Extensions" support
by SourceForge.net 03 Oct '04

03 Oct '04

Support Requests item #1039338, was opened at 2004-10-03 02:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1039338&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Visual C++ "Language Extensions" support Initial Comment: The following compiles under Visual C++ .Net with "Language Extensions" enabled, but it fails otherwise: #include <boost/token_iterator.hpp> int main() { return 0; } The received errors are: d:\Programming\boost\boost\detail\iterator.hpp(174) : error C2061: syntax error : identifier 'value_type' d:\Programming\boost\boost\mpl\aux_\preprocessed\msvc70\or.hpp(27) : error C2970: 'boost::mpl::aux::or_impl' : template argument 'C_' : invalid use of non-integral-constant static variable 'value' as non-type argument (and 4 more similar to the last one) How can I fix this? Any help will be appreciated. Hector C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1039338&group_… ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

lexical_cast to self
by Maxim Yegorushkin 03 Oct '04

03 Oct '04

In generic code lexical_cast<> is sometimes used as a cast to the same type. I would like to shortcut this rather then going all the way by writing it to a stream and reading back. In my code I use the following workaround: template<class U, class T> inline typename boost::disable_if<boost::is_same<T, U>, U>::type lexical_cast(T const& t) { return boost::lexical_cast(t); } template<class T> inline T const& lexical_cast(T const& t) { return t; } Does it make any sense to put it in lexical_cast.hpp? -- Maxim Yegorushkin

7 12

Constrained genericity at last? (any interest in an operator traits/concept traits library?)
by Terje Slettebø 03 Oct '04

03 Oct '04

Colleagues: Are you tired of long and incomprehensible error messages when using STL, MPL, or some other modern template library? So am I! Up to now, we've had the Boost Concept Check Library, but unfortunately, you may still get long error messages with it (in the case of Intel C++ 6.0 and STLPort, pages and pages long, although the cause of the error is usually more clear, due to words like "concept_check", "function_requires", etc. showing up in the error message), and you can't overload on concepts, i.e. having several overloaded functions taking different kinds of iterators (such as std::advance). However, the invention of enable_if [HJW03] [JWL03] (now part of Boost) opened the door to overloading based on arbitrary properties of types. Now, what we needed was techniques for detecting type properties, which could be used to create "concept type traits". Using this, we could have done, e.g. for std::sort: template<class Iterator> typename enable_if<is_random_access_iterator<Iterator> >::type sort(Iterator begin, Iterator end) { // ... } Besides enable_if, there have also been other discoveries paving the way for constrained genericity (programming with concepts) in the later years. One of them being isAddable [KJSMA03], which could detect if there exists a "+" operator for the values "a" and "b" in "a + b", and gives a true/false result. The operator could be built-in, member function, or free function; it didn't matter. Other work on type property introspection in C++ has been done by other people, notably Paul Mensonides, with techniques for detecting member types, (non-static) member variables and functions, static member variables and functions, etc., using SFINAE to great effect. The original isAddable required exact overload match - no conversion on the arguments was allowed, so int + int gave true, but int + double gave false, even though 1 + 1.0 is well-formed - but using a modified version, it's possible to allow the normal promotions/conversions on the arguments, as well, letting int + double give true. In contrast, the other mentioned detection techniques requires an exact signature match, so these two ways complement each other: The exact match way may be used where the promotions/conversions way can't be used, and vice versa. Last spring (after the introduction of enable_if and isAddable) I realised that we now for the first time had discovered or invented all the components needed for a decent implementation of constrained genericity (or programming with concepts) in the current C++ language (as shown with the code example above)! I therefore started on a library of type traits for detecting the components required for concept checking, which meant detecting such things as operators, constructors (to the degree it's possible), etc. The modified isAddable is a key technique used in this "operator traits" part of the library. When this was complete, I continued with the "concept traits" part of the library, where the aim was to make type traits for all the C++ standard concepts, as well as all the Boost.MPL concepts (for the reasons that MPL is widely known and used, it's part of Boost, it could help a lot with better error messages in such metaprogramming libraries, and as an example of implementing non C++ standard concepts). I was about halfway done with the library last summer, and then I got a new job, where I became very busy, so unfortunately I couldn't continue with it at that time. However, a while ago, I've resumed work on the library, and it's now complete. Besides the mentioned enable_if, isAddable, and the introspection techniques, MPL is a core component of the library. Its lazy evaluation logical operators are indispensible for many of the concept traits, particularly the more complex ones. I couldn't have done it without any of you. Thank you. MPL is also used in the unit tests, generating the test matrix on the fly, testing each trait in a list against a list of types, and comparing the result against a table. The total number of tests generated is several thousand. Other approaches ------------------------- About a year ago, there have been proposals/discussion papers for adding support for concepts to the C++ language (see N1510, N1522 and N1536 at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/) Using this, the above example could have been written as: template<RandomAccessIterator Iterator> void sort(Iterator begin, Iterator end) { // ... } This would also ease implementation of such concept overloading, because it would include the concept of concept refinement and "best match". Using the enable_if solution is a match or no match situation: either a function or class template matches, or it doesn't. Thus, if you want to implement std::advance as several overloaded functions using enable_if, you have to do something like this: template<class Iterator,class Distance> typename enable_if< mpl::and_< mpl::or_< is_input_iterator<Iterator>, is_output_iterator<Iterator> >, mpl::not_< is_bidirectional_iterator<Iterator> > > >::type advance(Iterator i,Distance d) { while(d--!=0) ++i; } The above function template is called if Iterator is either an InputIterator or OutputIterator, but not BidirectionalIterator (or "higher"). I.e. you have to manually exclude the next higher concept in the hierarchy, since BidirectionalIterator is also an InputIterator and OutputIterator (but should then call another overloaded function, not this one). If you also have a std::advance overload for BidirectionalIterator, you would otherwise get an error about ambiguity for the overloads (as they both would match), when called with a BidirectionalIterator. Nevertheless, the operator traits/concept traits library is something that can be used _now_, and which may give us more experience with programming with concepts. If the traits are used with libraries like STL or MPL, it has the potential to give drastically better diagnostics, and thereby making them easier to use. In addition, overloading on concepts is possible. A few of the traits (is_assignable, is_default_constructible and is_copy_constructible) rely on BCCL as a "last resort" when used for user-defined types, as there is no known way of detecting these for user-defined types. The library, including documentation, examples and tests may be found at (http://home.broadpark.no/~terjesl/operator_concept_traits.zip) (Yahoo Files is full, could we perhaps remove some of the stuff there that is now part of Boost?). Here's the synopsis from the documentation: Synopsis ------------- The library contains: - 46 operator type traits, covering all the overloadable (and therefore detectable) operators, as well as detection of default constructor, copy constructor and assignment operator. - 37 C++ standard concepts type traits, covering all the concepts of the C++ standard. - 19 Boost.MPL concepts type traits, covering all the documented concepts of Boost.MPL. - Facilities for defining your own concept type traits. - A complete set of unit tests. - Example programs, demonstrating its use. ------------- Some components may duplicate existing parts of Boost (such as MPL's has_xxx.hpp for member type detection, and mpl::is_sequence), and in other cases, the library includes functionality that may better belong in existing Boost libraries (type traits and MPL), and in those known cases, it's noted in the documentation. An aim is of course to syncronise the libraries, so that duplication is avoided. There may also be other components in the library that duplicate parts of MPL (or other parts of Boost) not noted here, and I'm all ears hearing about that, so that duplication may be eliminated. The operator traits/concept traits is essentially an extension to the Boost type traits library, but due to its specialisation (detecting operators, and generic concepts), as well as its size, it may be better to have as one or more separate components. Compatibility The library has been tested on Intel C++ 7.1, MSVC 7.1 and g++ 3.2. All tests pass on Intel C++ 7.1 and MSVC 7.1. For g++ 3.2, the operator traits tests pass, but most of the concept traits fails (either at compile time, or give wrong result). I intend to work to make the library work for g++ 3.2, as well. Bibliography [HJW03] Howard Hinnant, Jaakko Järvi and Jeremiah Willcock, Function Overloading Based on Arbitrary Properties of Types (http://www.cuj.com/articles/2003/0306/) 2003 [JWL03] Jaakko Järvi, Jeremiah Willcock, Andrew Lumsdaine, boost::enable_if, 2003 [KJSMA03] Dietmar Kuehl, Jaakko Jarvi, Jeremy Siek, Mat Marcus and Dave Abrahams, isAddable (ACCU Conference 2003 slides) (Regarding the salutation, I couldn't help doing a "Mat Marcus" here (http://article.gmane.org/gmane.comp.lib.boost.devel/42877) ;) not at least since Mat is also one of the people behind isAddable, a key technique of this library) Regards, Terje P.S. For those who may be wondering where I've been all this time, the reason was the mentioned new job, which lead to me being away from more or less the C++ community for about a year, until a few months ago. P.P.S. I've also seen the last days there have been discussion on the Boost list on similar facilities (the "Proposal for 'is_dereferenceable' and other templatemetafunctions" thread started by Alex Chovanec). is_dereferenceable<T> is similar to this library's has_dereference_op<T> (in the operator traits part), except that the latter doesn't test for lvalue, etc. Moreover, some of the other existing functionality may work better than the corresponding ones in this library (like MPL's has_xxx.hpp, which, from the comments in the header file is able to detect reference member types, something this library can't), so maybe we could cooperate? P.P.P.S From libraries in the Boost Sandbox, it appears that it's ok, even common, for libraries that are not part of Boost to still use the Boost logo in the documentation. Therefore, that is done in this case, as well. I also hope John Maddock doesn't mind that I used the same kind of tables for these traits, and general style, as for the Boost type traits library. Feedback on this library is very welcome.

11 48

boost::threads' exceptions patch
by Rodolfo Schulz de Lima 03 Oct '04

03 Oct '04

Hi, I've been using boost::threads for some time now and found it to be very useful and elegant in design. The only problem I see is when it throws an exception. No information about the error is fed to the exception constructor, and all we have is a 'boost::thread_resource_error' or a 'boost::lock_error' in std::exception::what, not very helpful. Since boost::thread_exception has a constructor that accepts an error code, I've managed to patch some files and fed (where appropriate) the error code to the exception constructor so that we can have an idea of what is the cause of the exception when we catch it. Not being fully satisfied with the results (we never are), I went a little further and decided to make thread_exception inherit from std::runtime_error, and pass to its constructor an informative message about the exception. This way std::exception::what will show not only the exception class name, but also the reason of the error (if we have an error core). I've modified the other exception classes accordingly. The last thing I did was to remove thread_argument_error since we could use std::argument_error instead. In fact, this class is never used, and in the only place that it would be used, std::argument_error is used. I'd appreciate any comments about those changes... Regards, rod IMPORTANT NOTE: I've just changed the PTHREADS implementation... I do not have good background on winthreads and mptasks, so I count on anyone who knows those systems to update their implementation... // Patch follows Index: boost/thread/exceptions.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/thread/exceptions.hpp,v retrieving revision 1.14 diff -u -r1.14 exceptions.hpp --- boost/thread/exceptions.hpp 8 Sep 2004 15:57:03 -0000 1.14 +++ boost/thread/exceptions.hpp 2 Oct 2004 23:51:50 -0000 @@ -25,11 +25,11 @@ namespace boost { -class BOOST_THREAD_DECL thread_exception : public std::exception +class BOOST_THREAD_DECL thread_exception : public std::runtime_error { protected: thread_exception(); - thread_exception(int sys_err_code); + thread_exception(std::string message, int sys_err_code=0); public: ~thread_exception() throw(); @@ -48,8 +48,6 @@ lock_error(); lock_error(int sys_err_code); ~lock_error() throw(); - - virtual const char* what() const throw(); }; class BOOST_THREAD_DECL thread_resource_error : public thread_exception @@ -58,8 +56,6 @@ thread_resource_error(); thread_resource_error(int sys_err_code); ~thread_resource_error() throw(); - - virtual const char* what() const throw(); }; class BOOST_THREAD_DECL unsupported_thread_option : public thread_exception @@ -68,18 +64,6 @@ unsupported_thread_option(); unsupported_thread_option(int sys_err_code); ~unsupported_thread_option() throw(); - - virtual const char* what() const throw(); -}; - -class BOOST_THREAD_DECL invalid_thread_argument : public thread_exception -{ -public: - invalid_thread_argument(); - invalid_thread_argument(int sys_err_code); - ~invalid_thread_argument() throw(); - - virtual const char* what() const throw(); }; class BOOST_THREAD_DECL thread_permission_error : public thread_exception @@ -88,8 +72,6 @@ thread_permission_error(); thread_permission_error(int sys_err_code); ~thread_permission_error() throw(); - - virtual const char* what() const throw(); }; } // namespace boost Index: libs/thread/src/condition.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/condition.cpp,v retrieving revision 1.20 diff -u -r1.20 condition.cpp --- libs/thread/src/condition.cpp 17 Jul 2004 04:33:59 -0000 1.20 +++ libs/thread/src/condition.cpp 2 Oct 2004 23:51:58 -0000 @@ -340,7 +340,7 @@ int res = 0; res = pthread_cond_init(&m_condition, 0); if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); } condition_impl::~condition_impl() Index: libs/thread/src/exceptions.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/exceptions.cpp,v retrieving revision 1.10 diff -u -r1.10 exceptions.cpp --- libs/thread/src/exceptions.cpp 8 Sep 2004 15:56:33 -0000 1.10 +++ libs/thread/src/exceptions.cpp 2 Oct 2004 23:51:58 -0000 @@ -69,12 +69,15 @@ namespace boost { thread_exception::thread_exception() - : m_sys_err(0) + : runtime_error("boost;:thread_exception") + , m_sys_err(0) { } -thread_exception::thread_exception(int sys_err_code) - : m_sys_err(sys_err_code) +thread_exception::thread_exception(std::string message, int sys_err_code) + : std::runtime_error(message+(sys_err_code==0 + ? "" : (": "+system_message(m_sys_err)).c_str())) + , m_sys_err(sys_err_code) { } @@ -89,17 +92,16 @@ const char* thread_exception::message() const { - if (m_sys_err != 0) - return system_message(m_sys_err).c_str(); return what(); } lock_error::lock_error() + : thread_exception("boost::lock_error") { } lock_error::lock_error(int sys_err_code) - : thread_exception(sys_err_code) + : thread_exception("boost::lock_error",sys_err_code) { } @@ -107,17 +109,13 @@ { } -const char* lock_error::what() const throw() -{ - return "boost::lock_error"; -} - -thread_resource_error::thread_resource_error() +thread_resource_error::thread_resource_error() + : thread_exception("boost::thread_resource_error") { } thread_resource_error::thread_resource_error(int sys_err_code) - : thread_exception(sys_err_code) + : thread_exception("boost::thread_resource_error",sys_err_code) { } @@ -125,17 +123,13 @@ { } -const char* thread_resource_error::what() const throw() -{ - return "boost::thread_resource_error"; -} - unsupported_thread_option::unsupported_thread_option() + : thread_exception("boost::unsupported_thread_option") { } unsupported_thread_option::unsupported_thread_option(int sys_err_code) - : thread_exception(sys_err_code) + : thread_exception("boost::unsupported_thread_option",sys_err_code) { } @@ -143,35 +137,13 @@ { } -const char* unsupported_thread_option::what() const throw() -{ - return "boost::unsupported_thread_option"; -} - -invalid_thread_argument::invalid_thread_argument() -{ -} - -invalid_thread_argument::invalid_thread_argument(int sys_err_code) - : thread_exception(sys_err_code) -{ -} - -invalid_thread_argument::~invalid_thread_argument() throw() -{ -} - -const char* invalid_thread_argument::what() const throw() -{ - return "boost::invalid_thread_argument"; -} - thread_permission_error::thread_permission_error() + : thread_exception("boost::thread_permission_error") { } thread_permission_error::thread_permission_error(int sys_err_code) - : thread_exception(sys_err_code) + : thread_exception("boost::thread_permission_error",sys_err_code) { } @@ -179,9 +151,4 @@ { } -const char* thread_permission_error::what() const throw() -{ - return "boost::thread_permission_error"; -} - } // namespace boost Index: libs/thread/src/mutex.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/mutex.cpp,v retrieving revision 1.19 diff -u -r1.19 mutex.cpp --- libs/thread/src/mutex.cpp 29 Jul 2004 14:25:30 -0000 1.19 +++ libs/thread/src/mutex.cpp 2 Oct 2004 23:51:58 -0000 @@ -201,7 +201,7 @@ int res = 0; res = pthread_mutex_init(&m_mutex, 0); if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); } mutex::~mutex() @@ -215,7 +215,7 @@ { int res = 0; res = pthread_mutex_lock(&m_mutex); - if (res == EDEADLK) throw lock_error(); + if (res == EDEADLK) throw lock_error(res); assert(res == 0); } @@ -223,7 +223,7 @@ { int res = 0; res = pthread_mutex_unlock(&m_mutex); - if (res == EPERM) throw lock_error(); + if (res == EPERM) throw lock_error(res); assert(res == 0); } @@ -241,7 +241,7 @@ int res = 0; res = pthread_mutex_init(&m_mutex, 0); if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); } try_mutex::~try_mutex() @@ -255,7 +255,7 @@ { int res = 0; res = pthread_mutex_lock(&m_mutex); - if (res == EDEADLK) throw lock_error(); + if (res == EDEADLK) throw lock_error(res); assert(res == 0); } @@ -263,7 +263,7 @@ { int res = 0; res = pthread_mutex_trylock(&m_mutex); - if (res == EDEADLK) throw lock_error(); + if (res == EDEADLK) throw lock_error(res); assert(res == 0 || res == EBUSY); return res == 0; } @@ -272,7 +272,7 @@ { int res = 0; res = pthread_mutex_unlock(&m_mutex); - if (res == EPERM) throw lock_error(); + if (res == EPERM) throw lock_error(res); assert(res == 0); } @@ -291,13 +291,13 @@ int res = 0; res = pthread_mutex_init(&m_mutex, 0); if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); res = pthread_cond_init(&m_condition, 0); if (res != 0) { pthread_mutex_destroy(&m_mutex); - throw thread_resource_error(); + throw thread_resource_error(res); } } Index: libs/thread/src/recursive_mutex.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/recursive_mutex.cpp,v retrieving revision 1.22 diff -u -r1.22 recursive_mutex.cpp --- libs/thread/src/recursive_mutex.cpp 16 Sep 2004 17:49:16 -0000 1.22 +++ libs/thread/src/recursive_mutex.cpp 2 Oct 2004 23:52:00 -0000 @@ -300,14 +300,14 @@ assert(res == 0); } if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); # if !defined(BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE) res = pthread_cond_init(&m_unlocked, 0); if (res != 0) { pthread_mutex_destroy(&m_mutex); - throw thread_resource_error(); + throw thread_resource_error(res); } # endif } @@ -377,7 +377,7 @@ { res = pthread_mutex_unlock(&m_mutex); assert(res == 0); - throw lock_error(); + throw lock_error(res); } if (--m_count == 0) @@ -456,14 +456,14 @@ assert(res == 0); } if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); # if !defined(BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE) res = pthread_cond_init(&m_unlocked, 0); if (res != 0) { pthread_mutex_destroy(&m_mutex); - throw thread_resource_error(); + throw thread_resource_error(res); } # endif } @@ -577,7 +577,7 @@ { res = pthread_mutex_unlock(&m_mutex); assert(res == 0); - throw lock_error(); + throw lock_error(res); } if (--m_count == 0) @@ -641,13 +641,13 @@ int res = 0; res = pthread_mutex_init(&m_mutex, 0); if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); res = pthread_cond_init(&m_unlocked, 0); if (res != 0) { pthread_mutex_destroy(&m_mutex); - throw thread_resource_error(); + throw thread_resource_error(res); } } @@ -764,7 +764,7 @@ { res = pthread_mutex_unlock(&m_mutex); assert(res == 0); - throw lock_error(); + throw lock_error(res); } if (--m_count == 0) Index: libs/thread/src/thread.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/thread.cpp,v retrieving revision 1.18 diff -u -r1.18 thread.cpp --- libs/thread/src/thread.cpp 5 Aug 2004 17:31:14 -0000 1.18 +++ libs/thread/src/thread.cpp 2 Oct 2004 23:52:00 -0000 @@ -160,7 +160,7 @@ int res = 0; res = pthread_create(&m_thread, 0, &thread_proxy, &param); if (res != 0) - throw thread_resource_error(); + throw thread_resource_error(res); #elif defined(BOOST_HAS_MPTASKS) threads::mac::detail::thread_init(); threads::mac::detail::create_singletons();

1 0

Re: como results?
by Aleksey Gurtovoy 03 Oct '04

03 Oct '04

Hi Bronek, > I have not stopped running regression tests on Comeau compiler; why > its results are no longer displayed on > http://www.meta-comm.com/engineering/boost-regression/developer/summary__re… They are in the reports, but because "como-win32-4.3.3-vc7.1" toolset is not marked as "required" in "status/explicit-failures-markup.xml", they are visible in the full view (http://www.meta-comm.com/engineering/boost-regression/developer/summary.html) but not the release view. The links at the top/bottom of each page allow you to switch between two. Currently, the toolset is marked as "required" if either of the following holds: 1) The compiler/configuration is known to be widely used, and/or the majority of Boost developers is committed to supporting it. The current versions of MSVC, Intel, GCC and CodeWarrior all fall into this category. or 2) The compiler/configuration is not widely used, but there are one or more Boost delevopers who consider it important enough to be included in the release criteria, and therefore volunteer to run regression tests for it, fix/mark up its failures, and generally take responsibility for driving things towards the release at reasonable speed. "intel-win32-7.1-vc6-stlport-4.5.3" is one such example. The only reason Comeau hasn't been marked as "required" so far is that it's unclear to me what its position is in regard to these two criteria. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

RFI: RMI in C++
by Francis ANDRE 03 Oct '04

03 Oct '04

Hi Listers I am looking for a good C++ package that implements something quite close to Java RMI (NO Corba/IIOP please!) , I have looked at the WWW, and the boost.org but I did not found any serious answer except the article of A Batov in the "C/C++ Users Journal" http://www.cuj.com/documents/s=8206/cujweb0304batov/ Now that the serialization library is part of boost, could this be a item to add the the wishlist at boost.org??? Regards FA

6 11

Python/Linux markup
by Aleksey Gurtovoy 02 Oct '04

02 Oct '04

Should we mark Boost.Python as unusable with gcc 2.95.3/Intel 7.1-8.0 on Linux? The number of failures for these looks unhealthy -- http://tinyurl.com/5z3hy. -- Aleksey Gurtovoy MetaCommunications Engineering

4 19

basic_cstring_test/vacpp failure
by Gennadiy Rozental 02 Oct '04

02 Oct '04

This test fails in MPL "/home/tk/boost_regression/boost/boost/mpl/joint_view.hpp", line 57.48: 1540-0416 (S) "begin" cannot be declared because its name has already been used. "/home/tk/boost_regression/boost/boost/mpl/joint_view.hpp", line 46.13: 1540-0426 (I) The name "begin" is used on line 46 of "/home/tk/boost_regression/boost/boost/mpl/joint_view.hpp". Any chance for it to be fixed? Gennadiy.

2 1

[serialization] test_level_class_info_load*...
by Stefan Slapeta 02 Oct '04

02 Oct '04

...is marked as expected failure for all toolsets! Is this really intended? (What does us tell a test that is expected to fail everywhere?) Stefan

1 0

Detecting gcc-3.3-darwin regression build
by Michael Stevens 02 Oct '04

02 Oct '04

Dear all, Does anyone know what Boost.Build toolset is used to build these tests? I need to force an ABI version and I was assuming it was the 'darwin' toolset. However <darwin><*><cxxflags>"-fabi-version=0" is not triggering. Thanks, Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

3 2

[Test] Current failures
by Aleksey Gurtovoy 02 Oct '04

02 Oct '04

Gennadiy, Could you please take a look at/comment on the current Boost.Test failures as per http://tinyurl.com/5wojs? Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

5 18

test_case_template_test / borland-5.6.4
by Gennadiy Rozental 02 Oct '04

02 Oct '04

This fails due to what seems to be some compiler bug with MPL. That this test does is run following test case : template<typename Number> void test0( Number* = 0 ) { BOOST_CHECK_EQUAL( 2, Number::value ); } with all elements of following list: typedef boost::mpl::list_c<int,2,2,2,2,2,2,2> only_2; I expect 0 errors, borland produce 7, meaning that all of the comparisons fail. Any suggestions, Gennadiy.

1 0

Bad links on the web site
by Ben Hutchings 02 Oct '04

02 Oct '04

On <http://www.boost.org/more/links.htm>: "C++ Standards Committee" links to the old committee home page. This works now because of a redirection, but will presumably stop working after a while. "ANSI Store" links to the 1998 standard which is no longer available (online at least). Ben.

2 1

boost-lite
by Andy Little 02 Oct '04

02 Oct '04

Hows about a boost-lite distro? What to include? Specifically only stuff that is a candidate for standardisation. If there is anything that is 'indispensible' but not a candidate, then one should ask why. Ideally Headers only, nothing that requires separate compilation, or bjam. And under (say ) 1MB absolute max. (exclude Docs. These can be pointed via url) Just a thought .... regards Andy Little

2 1

[hash containers in files section]
by Thorsten Ottosen 02 Oct '04

02 Oct '04

Hi Jeremy, I've been working a little with your hash containers. They should definitely be fast-track reviewed! A small problem: std::distance( m.begin(), m.end() ) != m.size() after I have filled the container (more than 100k elements). Could it be due to some caching thing? best regards Thorsten

3 2

Some questions on Boost Threads
by Parameswaran, Vinod 02 Oct '04

02 Oct '04

Hello list, My name is P. Vinod and I am currently debugging an application that was initially written using single thread but later ported to multithreads. The threading has been done using Boost library functions. I am new to Boost library and would like to clarify some of my doubts with you. Please reply to vparameswaran(a)fcg.com I have been studying William Kempf's documentation on Boost threads (http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/threads .html) and all my questions are based on the references therein: 1. <begin quote> The template thread_specific_ptr <http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/class.b oost.thread_specific_ptr.html> is useful in the following cases: * An interface was originally written assuming a single thread of control and it is being ported to a multithreaded environment. <end quote> Is there any other way by which you could port a single threaded interface to multithreaded interface using Boost threads? My debugging approach will be based on your answer to this question. 2. Does anyone have some examples of scenarios wherein each of these classes could be used (would even appreciate reference to relevant docs., if any): a. barrier b. condition c. thread_group d. thread_specific_ptr 3. Assumption: In the case of a condition object, ONLY THE FOLLOWING METHODS could be used to specify the wait condition: a. template<typename ScopedLock, typename Pred> void wait(ScopedLock& lock, Pred pred); b. template<typename ScopedLock> bool timed_wait(ScopedLock& lock, const bool::xtime& xt); c. template<typename ScopedLock, typename Pred>bool timed_wait(ScopedLock lock, Pred pred); Is this correct? 4. <begin quote> A thread object has an associated state which is either "joinable" or "non-joinable". <end quote> Is this state indicated using a type or is merely implied by whether the default or the parameterized constructor is called for the creation of the thread object? 5. Could anyone give examples of the use of void join() and void yield()? (Would even appreciate reference to relevant docs., if any) 6. <begin quote> Template thread_specific_ptr stores a pointer to an object obtained via new on a thread-by-thread basis and calls delete on the contained pointer when the thread terminates. Each thread initially stores the null pointer in each thread_specific_ptr instance. <end quote> Does each thread create its own 'object' referred to here and modify its thread_specific_ptr class by invoking void reset(T* p=0) ? 7. <begin quote> The template thread_specific_ptr is useful in the following cases: * Each thread of control invokes sequences of methods that share data that must be logically accessed through a globally visible access point, but are physically unique for each thread, instead of being explicitly passed. <end quote> <begin quote> Template thread_specific_ptr stores a pointer to an object obtained via new on a thread-by-thread basis and calls delete on the contained pointer when the thread terminates. Each thread initially stores the null pointer in each thread_specific_ptr instance. <end quote> >From the above statements, I could draw the inference that the thread_specific_ptr object stores the data that is shared amongst the various methods invoked from within a thread; however this data is not shared amongst threads and is unique for each thread. <begin quote> thread_specific_ptr construct/copy/destruct 1. thread_specific_ptr(); Requires: The expression delete get() is well formed. Effects: A thread-specific data key is allocated and visible to all threads in the process. Upon creation, the value NULL will be associated with the new key in all active threads. <end quote> <begin quote> 1. ~thread_specific_ptr(); ..... For this reason you should not destroy a thread_specific_ptr <http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/thread_ specific_ptr.html> object until you are certain there are no threads running that have made use of its thread specific storage. <end quote> The above statements seem to contradict the previous quotes, in that a thread-specific data key is visible to all the threads in the process and thread-specific storage is shared amongst multiple threads. Could anyone dispel the apparent ambiguity here? Also, what is the concept of "data key"? Gratefully appreciate your time and advice on the above. Vinod

2 1

Re:[boost] [Serialization] Remaining failures markup
by Robert Ramey 01 Oct '04

01 Oct '04

Aleksey Gurtovoy wrote: >Robert, >Pending msvc-stlport issue aside, I commented this accordingly. >the serialization library reports show >quite a few failures with other toolsets, in particular: > cw-9.3 > borland-5.6.4 > cw-8.3 > msvc > vc7 >I'm sure you've well aware of these; what I'd like to ask you is to >comment on them in the "explicit-failures-markup.xml" in the similar >way you commented on "*_warchive" tests, so that a) the library users >are not scared away by all these yellow cells, and b) the release >manager and everybody else besides the author have a simple way of >telling whether the library is in the OK state or not. I've been looking at this for a while procrastinated doing anything until I was sure what to do. So far this has been an effective strategy. Many times failures just disappeared as arcane tooI set issues were resolved. I still have some doubts about how to handle the remaining cases. Metrowerks compilers (cw*) seem to suffer from over-zealous optimization that eliminates static variables not referred to explicitly by name. Other compilers do this as well, but I've managed to workaround this in various ways. Cw* is the last hold out on this issue. I had hoped someone who is interested in this can test it might be motivated to look into it but it seems that there isn't enough interest. Unless I hear otherwise, I'll mark these tests as "expected". I would love to see this fixed - but for this Metrowerks would have an almost perfect showing. I do think its very high quality product that handles platforms that others don't. Its pains me that the serialization library test don't reflect this. A number of these (msvc, vc7, borland) have been determined to be manifestations of compiler deficiencies so I will mark them so. Some the borland test don't fail on my own test setup - so for me they are indeed "unexpected failures" - I think leaving this yellow is the correct characterization. That leaves a number of miscellaneous failures which really aren't understood or explained. Personally I would like to leave these as they are as to mey they really are "unexpected failures". I realize that some might be dissuaded from using the library because of this - but I think that's better than having someone use the library and not have it meet expectations. Robert Ramey

3 2

ulas / cw 8.3
by Stefan Slapeta 01 Oct '04

01 Oct '04

Is there a particular reason why ublas is marked unusable for cw 8.3? Stefan

1 0

[review] Formal review of the Smart Container library - 5 days left reminder
by Pavol Droba 01 Oct '04

01 Oct '04

Hi All, This the the reminder, that there are only 5 days left for the Smart Containers review. Please post your reviews if you find this library interesting. Best Regards, Pavol Droba Following is the copy of the invitation message: The review of the Smart Container library, written by Thorsten Ottosen starts today (September 26th, 2004) and runs for 10 days (until October 5th, 2004). The latest version of the library can be found at http://boost-sandbox.sourceforge.net/smart_container.zip or http://groups.yahoo.com/group/boost/files/pointer%20container/smart_contain… The package contains all you need to sucessfuly use the library with the Boost version 1.31 or later, however library tests require the latest Boost.Test, that is available from the main Boost CVS. What does the library provide? The library documentation states: >>>>>>>>>>>>>>>> Whenever a programmer wants to have a container of pointers to heap-allocated objects, there is usually only one exception-safe way: to make a container of smart pointers like boost::shared_ptr. This approach is suboptimal if 1. the stored objects are not shared, but owned exclusively, or 2. the overhead implied by smart pointers is inappropriate This library therefore provides standard-like containers that are for storing heap-allocated or cloned objects (or in case of a map, the mapped object must be a heap-allocated or cloned object). For each of the standard containers there is a smart container equivalent that takes ownership of the objects in an exception safe manner. In this respect the library is intended to solve the so-called polymorphic class problem. The advantages of smart containers are 1. Exception-safe and fool proof pointer storage and manipulation. 2. Notational convenience compared to the use of containers of pointers. 3. Can be used for types that are neither Assignable nor Copy Constructible. 4. No memory-overhead as containers of smart pointers can have (see 11 and 12). 5. Usually faster than using containers of smart pointers (see 11 and 12). 6. The interface is slightly changed towards the domain of pointers instead of relying on the normal value-based interface. For example, now it is possible for pop_back() to return the removed element. The disadvantages are 1. Less flexible than containers of smart pointers <<<<<<<<<<<<<<< As an example of how the new containers look like, consider that <code> typedef boost::shared_ptr<Foo> foo_ptr; std::vector<foo_ptr> vec; vec.push_back( foo_ptr( new Foo ) ); (*vec.begin())->bar(); </code> now becomes <code> boost::ptr_vector<Foo> vec; vec.push_back( new Foo ); vec.begin()->bar(); </code> In your reviews, please include the answers for the following questions: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Also, in the documentation you will find questions from the submitter to the reviewer; whenever you feel you have something to contribute on these issues, please don't hessitate to include that in your review. Thank you, Pavol Droba, review manager for the Smart Containers library.

1 0

RE: [boost] Re: Re: Long toolset names
by Stefan Seefeld 01 Oct '04

01 Oct '04

> From: Tony Juricic [mailto:tonygeek@yahoo.com] > Sent: October 1, 2004 12:03 > Even MS IDE has problems in some cases (very inconsistent) when space > characters are present but I thought that in most Wintel and also UNIX > command tools these issues are easily solved with adding quotes? well, that sounds simpler as it is. It's all those little details such as one shell eating quotes, another passing them through when called in a nested way that makes it really hairy. It's a can of worms that can easily be avoided by not using spaces in file names. Regards, Stefan

1 0

White spaces in regression
by Victor A. Wagner Jr. 01 Oct '04

01 Oct '04

As part of my script before I run any of the regression code, I delete all the *.xml files from the results directory. This is done because if there is a _severe_ crash while running the regressions, the *.xml files will still exist when things are "collected". I've been told that it is the responsibility of process_jam_log to create these, BUT: C:\Projects\boost\tools\regression\build>C:\Projects\boost\tools\build\jam_src\bin.ntx86\bjam.exe -sTOOLS=vc7.1 ...found 481 targets... Traceback (most recent call last): File "regression.py", line 712, in ? commands[ command ]( **accept_args( args ) ) File "regression.py", line 356, in setup build_if_needed( process_jam_log, pjl_toolset, toolsets ) File "regression.py", line 288, in build_if_needed raise 'Failed to find "%s" after build.' % tool[ 'build_path' ] Failed to find "C:\Projects\boost\bin\boost\tools\regression\build\process_jam_log.exe\vc7.1\release\process_jam_log.exe" after build. the reason it cannot find it there is because somehow it got built here instead: C:\Projects\boost\bin\boost\tools\regression\build\process_jam_log.exe\vc7.1\release\threading-multi\process_jam_log.exe I don't know if actually finding the correct version will solve the white space problem, but this clearly isn't correct. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

[Signals] New regressions
by Aleksey Gurtovoy 01 Oct '04

01 Oct '04

Doug, It seems that your last checkin broke things on a number of platforms -- see http://tinyurl.com/69npt. -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Compilation problem with boost on SunCC (Forte 6.2 & 8)
by Puverle, Tomas (IT) 01 Oct '04

01 Oct '04

Please find attached a small program and a the resulting compilation errors on SunCC. This occurs in iterator_facade.hpp, operator != (), calling to interator_core_access::equal. I have tracked this down to the following problem: f(mpl::true_); f(mpl::false_); f(is_convertible<>()); //will not work is_convertible<> derives from mpl::bool<>, however it seems that a bug in the compiler prevents it from converting to mpl::true_/mpl::false_ in the above scenario (and in the program attached) A workaround for this is to change it to the following: f(mpl::true_); f(mpl::false_); f(mpl::bool_<is_convertible<>::value>()); Presumably this will be present in other places but this is the only one our developers have hit so far. Thanks, Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

1 0

1.32 Status?
by Brian Braatz 01 Oct '04

01 Oct '04

I am anxiously awaiting 1.32 as there are features there that I need. I am holding off though on using them until that is officially released. My question is - is there a target timeframe as to when 1.32 looks like it will be ready. My Suggestion would be that the website (boost.org) have a place on the front page that has the current rough timeframe for when 1.32 may be ready. Thanks Brian Braatz

3 3

[Thread] The last step
by Aleksey Gurtovoy 01 Oct '04

01 Oct '04

Gentlemen, Seems like we've just cleared up Boost.Thread failures/regressions on all but one required toolset! See http://tinyurl.com/6h56q. Congratulations on the great job to everyone involved. You can probably guess what I'm about to ask -- can we do something about Intel 8.0/Linux failures? Looking at the output below (from http://tinyurl.com/6mnzn) it seems to me that the test was attempted to be linked against *both* GCC and Intel runtimes: /usr/lib/libc.a(strtol.o)(.text+0x50): In function `strtol': ^^^^^^^^^^^^^^^^^^^^^^^^^ : multiple definition of `strtol' /opt/intel_cc_80/lib/libcprts.a(strtol.o)(.text+0xea): first defined here ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ld: Warning: size of symbol `strtol' changed from 24 in /opt/intel_cc_80/lib/libcprts.a(strtol.o) to 73 in icc -g -openmp -static -o "../bin/boost/libs/thread/test/test_barrier_lib.test/ intel-8.0-linux/debug/runtime-link-static/threading-multi/test_barrier_lib" -L../bin/boost/libs/thread/build/libboost_thread.a/intel-8.0-linux/debug/runtime-link-static/threading-multi -L../bin/boost/libs/test/build/libboost_unit_test_framework.a/intel-8.0-linux/debug/runtime-link-static/threading-multi "../bin/boost/libs/thread/test/test_barrier_lib.test/intel-8.0-linux/debug/runtime-link-static/threading-multi/test_barrier.o" "../bin/boost/libs/thread/test/test_barrier_lib.test/intel-8.0-linux/debug/runtime-link-static/threading-multi/tss_null.o" ../bin/boost/libs/thread/build/libboost_thread.a/intel-8.0-linux/debug/runtime-link-static/threading-multi/libboost_thread-intel80-m t-sd-1_32.a ../bin/boost/libs/test/build/libboost_unit_test_framework.a/intel-8.0-linux/debug/runtime-link-static/threading-multi/libboost_unit_ test_framework.a ../bin/boost/libs/thread/build/libboost_thread.a/intel-8.0-linux/debug/runtime-link-static/threading-multi/libboost_thread-intel80-m t-sd-1_32.a ../bin/boost/libs/test/build/libboost_unit_test_framework.a/intel-8.0-linux/debug/runtime-link-static/threading-multi/libboost_unit_ test_framework.a -lrt Could somebody comment further/take a deeper look at this? -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

RE: [boost] Re: [shared_ptr] Interlocked* - possible bug?
by Ben Hutchings 01 Oct '04

01 Oct '04

Alexander Terekhov <terekhov(a)web.de> wrote: > Ben Hutchings wrote: > [...] > > If atomic_read > > returns 0 that means the use count has dropped to 0 [*] and can > > never increase again, so it must be the latest version. Otherwise > > weak_ptr makes a second test that is properly protected. So it can > > never use an old value. > > > > [*] I think this is right but I'm not certain that it can't return a > > 0 that the processor read during creation of an object that > > uses enable_shared_from_this. > > What makes you uncertain? Simply not having thought enough about it. Now that I have done, I realise that it's impossible for a thread to use a weak_ptr to an object without either (1) constructing a shared_ptr to it, setting the use count to be non-zero, or (2) synchronising with another thread that constructs the shared_ptr and/or weak_ptr, which should provide an appropriate memory barrier that will prevent the use of any invalid pre-fetched value of the memory containing the use count. > > Having said all that, I feel the naming of functions may give a > > false sense of generality and encapsulation when they actually > > only work in the way they are being used currently. > > You mean that > > bool expired() { > return lock(); > } > > is better? Not really. I will expand in my mail to Peter Dimov.

3 17

Re:Re: [boost] Output formatters: different approaches
by Robert Ramey 01 Oct '04

01 Oct '04

>Vladimir Prus wrote: >> During the review of the output formatters library, there were suggested >> several alternative approaches. For example, Gennadiy thinks the library is >> too complicated, and Hartmut suggests creating a library dual to Spirit -- >> which would be extra powerfull. > >> That's not all. Independently, I've talked with Vaclav Blazek, who's the >> author of the Teng text template engine (http://teng.sourceforge.net/) which >> is also a similiar domain -- it's too about formatting objects. >I will try to take a look at it next week. >> >> It would be great if we had some common foundation, so that I could output >> ptr_vector<Function> using both a simple formatter, or a flexible one, or >> even some template engine. > > >> 2. A mechanism to iterate over elements of composite type. After some though, >> I believe that the mechanism should be boost::serializaton. >This sounds nice, but I don't know how achievable it is. >Basically, when writing a composite type, you might want to write things >in-between. Like, for a pair, you might want to write: > [first, second] >or ><<first | second>> > (where first and second are the members of the pair) >Same goes for each composite type. >I'm not very familiar with boost::serialize - still it is something to >think about ;) The serialization library provides formatting/recovery for all composite types with no special effort by the programmer. This is usually suitable for the type of output file being used. In cases where it isn't, the output/input can be overloaded on a type by type basis. In practice few have found it necessary or valuable to do this. >> The idea of the library, as I see it, is to provide object serialization, but >> - without the overhead serialization library has >> - with extra layout tweaks >Yes, it would be nice. For objects of the type being discussed, (i.e. no pointers, no class versioning, no memory tracking of duplicates, etc) the serialization library has no extra runtime overhead. I would be very surprised if the serialization library did not result in smaller and faster code than the libraries being discussed. >> I don't see why it's necessary to reinvent the object traversal code which is >> already in boost::serialization. For example, boost::serialization support >> scoped_ptr. It would not make sense to add separate support for scoped_ptr in >> outfmt. The serialization library has all that and much, much more. >I would need to delve further into boost::serialize to have an oppoinion >- and the unfortunate thing is that I won't have any available time soon :( Too bad, it would have consumed much less time than has been already spent on this topic If function output formatters is helpful for making output more easily presentable, fine. Though G. Rozenthal's, experiment makes me doubt this. If the purpose is to save and restore the state of some assortment of class instances - it's the same as the serialization system and should evaluated as an alternative with a full blown comparison. I believe the demos and documentation in the serialization package show that it to be much, much easier to use than the proposed library for this purpose. Robert Ramey

3 2

Thread VC 7.1 failures (Bronek Kozicki)
by Stefan Slapeta 01 Oct '04

01 Oct '04

Any idea why some tests fail in this environment? They do all pass on my machine and appearantly also on Victor's. Stefan

4 4

Python/GCC 3.4.1/Linux failures
by Aleksey Gurtovoy 01 Oct '04

01 Oct '04

There are a few of them, see http://tinyurl.com/5z3hy. What we are going to do about it? -- Aleksey Gurtovoy MetaCommunications Engineering

5 13