- Boost - lists.boost.org

Boost Unicode support ideas
by Jeremy Maitin-Shepard 25 Apr '04

25 Apr '04

It seems that Unicode support in Boost (which could lead to Unicode support in the C++ language and standard library) would be quite desirable. The IBM International Components for Unicode (ICU) library (http://oss.software.ibm.com/icu/) is an existing C++ library with what appears to be a Boost-compatible license, which provides all or most of the Unicode support that would be desired in Boost or the C++ standard library, in addition to Unicode-equivalents of libraries already either in the standard library or in Boost, including number/currency formatting, date formatting, message formatting, and a regular expression library. Unfortunately, it does not use C++ exceptions to signal exceptional conditions (but rather it uses an error code return mechanism), it does not follow Boost naming conventions, and although there are some C++-specific facilities, most of the C++ API is the same as the C API, thus resulting in a less-than-optimal C++ interface. Nonetheless, I think Boostifying the ICU library would be quite feasible, whereas attempting to reimplement all of the desired functionality that the ICU library provides would be extremely time consuming, since the collating and other services in the ICU library already support a large number of locales, and the character-set conversion facilities support a large number of character sets. The representation of locales does present an issue that needs to be considered. The existing C++ standard locale facets are not very suitable for a variety of reasons: - The standard facets (and the locale class itself, in that it is a functor for comparing basic_strings) are tied to facilities such as std::basic_string and std::ios_base which are not suitable for Unicode support. - The interface of std::collate<Ch> is not at all suitable for providing all of the functionality desired for Unicode string collation. A suitable Unicode collation facility should at least allow for user-selection of the strength level used (refer to http://www.unicode.org/unicode/reports/tr10/) and would ideally also support customizations as extensive as the ICU library does (refer to http://oss.software.ibm.com/icu/userguide/Collate_ServiceArchitecture.html and http://oss.software.ibm.com/icu/userguide/Collate_Customization.html) - Facilities such as Unicode string collation are heavily data-driven, and it would be inefficient to load the data for facilities that are not used. This could be avoided by using some sort of lazy loading mechanism. It would still be possible to use the standard locale object as a container of an entirely new set of facets, which could be loaded from the data sources based on the name of the locale, and ``injected'' into an existing locale object, by calling some function. It is not clear, however, what advantage this would serve over simply using a thin-wrapper over a locale name to represent a ``locale,'' as is done in the ICU library. -- Jeremy Maitin-Shepard

9 36

Re: [boost] Re: [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

Hi Pavel ----- Mensaje original ----- De: Pavel Vozenilek <pavel_vozenilek(a)hotmail.com> Fecha: Domingo, Abril 25, 2004 10:11 am Asunto: [boost] Re: [multi_index] composite keys: request for advice > > "Joaquin M Lopez Munoz" <joaquin(a)tid.es> wrote: > > > Composite keys can be specified by a new construct > > called composite_key in the following manner: > > > OT question 1: will it be possible to specify calculated > index as part of composite index? I take you mean "calculated key" and "composite key". Yes, it is possible, composite_key does accept any key extractor, it needs not be multi_index::member. > > > OT question 2 (I could had asked already): would it be somehow > possible for calculated index to use user supplied functor > and then sorting sequenced index according this index? > > This would create 'dynamic index', modifiable during runtime. I'm not quite getting you; the following shows how to specifiy the comparison predicate at run time, I don't know if this is what you are asking. typedef multi_index_container< employee, indexed_by< ordered_unique< identity<employee>, boost::function<bool (const employee&)> > > > employee_set; ... bool foo(const employee&); ... employee_set::ctor_args_list cal; cal.get<0>.get<1>=foo; // 2nd argument of the first index employee_set es(cal); Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] regex lib: bug with sets and back ref
by Benzinger, Ralph 25 Apr '04

25 Apr '04

> > The following behavior seems to be a bug: > > > > * regex '([a-c]+)\1' finds 'abcabc' at offset 0 in text 'abcabc' > > That looks correct. > > > * regex '([abc]+)\1' finds 'bcbc' at offset 1 in text 'abcbc' > > That looks correct. > > > * regex '([a-c]+)\1' finds nothing in text 'abcbc' ??? > > It should 'bcbc' if you're calling regex_search and nothing if you're > calling regex_match. Sorry if I wasn't clear enough. All tests use regex_grep. In the last example, however, regex_grep _doesn't_ find "bcbc", even though it should. I would assume it's an issue with regex_compile, as the only difference between (2) and (3) is the way the set is defined. Ralph

2 1

alternative stringstream class
by Samuel Krempp 25 Apr '04

25 Apr '04

I meant to mention this for a while : I've written an alternative stringstream class implementation as part of boost::format, with 2 motivations : a. make boost::format compile on platforms that don't provide std::stringstream (gcc-2.95) b. allow more efficient use of stringstream in the context of boost::format (by adding copy-less access to the stringstream's buffer, and allowing reuse of the buffer) Now it's been there working hand in hand with boost::format for a while, compiling ok on mostly all platforms, but I dont know what to do about this class, if I should leave it there undocumented and unmentionned, or document it, or make it a mini-library, or a detail or whatever. IMO this class might interest some users, as it is more flexible than std::stringstream (allowing more efficient uses in some situations), while it includes the original stringstream's interface, keeps its overall design, and ease-of-use. It lies in boost/format/alt_stringstream.hpp (and _impl.hpp) it depends on the rest of boost::format only due to workaround settings (mainly required by gcc-2.95) alt_stringstream provides the features of std::stringstream, plus : void clear_buffer(); // calls seekpos // 0-copy access : Ch * begin() const std::streamsize size() const std::streamsize cur_size() const // copy buffer to string : string_type cur_str() const // [pbase, pptr[ This cur_str() function differ from the std::stringstream str() function, which returns a copy of [pbase, epptr[, thus unaffected by calls to seekpos, actually preventing buffer-reuse. (alt_stringstream defines functions cur_str() and str(), so it can have the same behaviour as std::stringstream if used with str() ) So, what should I do with this class ? -- Samuel

1 0

Re: [boost] [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- [...] > > composite_key</* as before*> ck; > > ck(record(1,2,3))<=make_tuple(1,2); // yields true > > make_tuple(1,2)<=ck(record(1,2,3)); // yields true > > > > So far, this is all IMHO perfectly consistent, > > but the following design decision is not > > obvious to me: given the previous, what should > > be the result of > > > > ck(record(1,2,3))==make_tuple(1,2); // true or false? > > > > As these two objects are neither greater than the > > other, at least they are *equivalent*, but maybe > > allowing operator== to return true is too much. > > It sounds to me like you have a partial ordering or a strict weak > ordering, but not a total ordering. > http://www.sgi.com/tech/stl/StrictWeakOrdering.html > That is, these two objects: > ck(record(1,2,3)) make_tuple(1,2) > are in the same equivalence class, but they are not equal. My > hunch is > that if you call these two object "k" and "t" (key and tuple), > then you > should have > k < t false > t < k false > t == k does not compile > That's just my quick hunch based on what I've quoted above; I haven't > considered what consequences it has for the library, but that's my > intuitive notion of how tuples as "partial keys" ought to work. > I guess I agree with you, but I wanted to bring this in to the list to gather some opinions. Following your approach, what should we do with k <= t t <= k The options are: a. they hold true b. they do not compile I don't have any strong argument in favor of any option. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [multi_index] composite keys: request for advice
by Dave Gomboc 25 Apr '04

25 Apr '04

[reformatted] > // yields true > composite_key</* as before*> ck; ck(record(1,2,3))<=make_tuple(1,2); > > // yields true > make_tuple(1,2)<=ck(record(1,2,3)); > > So far, this is all IMHO perfectly consistent, > but the following design decision is not > obvious to me: given the previous, what should > be the result of > > ck(record(1,2,3))==make_tuple(1,2); // true or false? > > As these two objects are neither greater than the > other, at least they are *equivalent*, but maybe > allowing operator== to return true is too much. operator== should return false here. The operands are equivalent, but not equal. Dave

1 0

Re: [boost] [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeremy Maitin-Shepard <jbms(a)attbi.com> Fecha: Sábado, Abril 24, 2004 11:13 pm Asunto: Re: [boost] [multi_index] composite keys: request for advice > Joaquin M Lopez Munoz <joaquin(a)tid.es> writes: > > > [snip: composite key system] > > > composite_key</* as before*> ck; > > ck(record(1,2,3))<=make_tuple(1,2); // yields true > > This is not lexicographical order. According to lexicographical > ordering: > > (1, 2) < (1, 2, 3) > I did not claim that composite_key results and tuples are ordered lexicographically. What I said is that, given that a composite_key induces a lexicographical order on the elements of the multi_index_container it is used in, this can be taken advantage of to perform searches where only the first keys are given. For this to work, (1, 2) must be equivalent to (1,2,3) (meaning that !((1, 2)<(1,2,3)) and !((1,2,3)<(1,2)). I don't think there's any flaw with this approach, my doubt is about whether the fact that ck(record(1,2,3))<=make_tuple(1,2) and make_tuple(1,2)<=ck(record(1,2,3)) is reason enough to also make ck(record(1,2,3))==make_tuple(1,2) hold true. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

max elapsed time of boost::timer
by Toon Knapen 24 Apr '04

24 Apr '04

The documentation of boost::timer states that 'The maximum measurable elapsed time may be as low as 596.5 hours (or even less) ...'. Well on many 32bit platforms this would probably even be about 71 hours. Apparantly POSIX requires CLOCKS_PER_SEC to be 10e6, so if clock_t is 32 bit, the maximum of ( clock() / CLOCKS_PER_SEC ) is 4294 seconds. Because accuracy for clock() is generally about 1 sec, using clock() is not very usefull for doing timings of short (in time) events. Even more, for short events, the boost::timer might also influence the timing too much. So clock() is generally interesting for longer timings (from 10 sec onwards). But for long events the clock_t wraps around too fast (as mentioned above). And if you're unlucky that you _start_time = clock() is or a bit smaller than std::numeric_limits< clock_t >::max() (thus near the wrap-around point), directly afterwards the expression 'clock() - start' will result in a negative value. So I would like to suggest for boost::timer to use std::time_t and use std::time(NULL) instead of clock() and use std::difftime to calculate the elapsed time. toon

4 4

A question to preprocessor gurus
by Arkadiy Vertleyb 24 Apr '04

24 Apr '04

Hi all, The MS preprocessor has the __COUNTER__ extension that expands to the next integer every time when used. Can something like this be achieved in a portable manner, maybe with the help of Boost.Preprocessor library? Thanks, Arkadiy

4 7

[circular buffer] Status of Circular Buffer lib
by Jeff Garland 24 Apr '04

24 Apr '04

I'm looking at using circular buffer on a project. With only minor adaptation it does exactly what I need. I know it has been accepted, but isn't yet in CVS. So I have a few questions: 1) Is 3.6 from the files section the latest version? 2) Any showstopper bugs I should be aware of? 3) I'm assuming it works with VC7.1 and gcc 3.x? 4) Looks like my interface needs will be pretty basic: push_back, erase, clear. I assuming review changes won't impact these, correct? 5) Any reason it is NOT ready for prime time? Thx for the great submission! Jeff

2 2