October 2004 - Boost - lists.boost.org

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