April 2004 - Boost - lists.boost.org

Date-Time documentation link
by Edward Diener 07 Apr '04

07 Apr '04

In the Date-Time library documentation for 1.31, the link from Class day_clock takes me to the Construction From Clock section of the class Date. Is that correct ? I was expecting to be taken to documentation for class day_clock's constructors and member functions. Is this a way of saying that day_clock has only a default constructor and the member functions local_day() and universal_day() ?

2 3

Re: Tokenizer doc problems/confusion (?)
by David Abrahams 07 Apr '04

07 Apr '04

"John R. Bandela" <jbandela(a)ufl.edu> writes: > Thanks for the e-mail. > > The problem the char_separators not giving you the correct words and > counts is a bug. It was caused by the latest changes to > token_functions to speed up tokenizing non-input iterators. The > version in the boost 1.31 should work (it is the one prior to the > changes). I have also just fixed it in the CVS. Thanks! All the docs still show char_delimiters_separator as the default, though. > Having char_delimiters_separator as the default tokenizing function > was unintentional (ie it never got changed). OK. > As to simplifying the interface, I would really like to hear your ideas. 1. Allow "boost::use_default" for any of the template parameters 2. Supply a templated 1-argument ctor that constructs the start iterator from the argument and default constructs the end iterator then I could write: boost::tokenizer< boost::use_default, std::istreambuf_iterator<char> > t(std::cin); > As to why char_delimiters_separator was deprecated, char_delimiters ^^^^^^^^^^^^^^^ What's that? It's not in the doc. Do you mean char_separator? > was supposed to be a replacement for it, doing everything it did, > but providing the user with more control in dealing with empty > tokens. However, as you have brought up, it also has the unfortunate > problem that in its default construction of returning punctuation as > well as words and thus is not as simple to use. Why not just change that. > Perhaps the solution would be making a separate words_delimiter that > is hard-wired to return only words (ie characters separated by > either a space or a punctuation mark) and making that the default. That'd be OK with me. > As to why the mention of std::isspace and ispunct, I needed a default > behavior when the user does not want to provide all the space and > punctuation (it can be a somewhat long string). I also did not what to > hard-code it as a string so I used those functions instead. That doesn't demystify things for me. If you have an internal way to use functions to determine kept and dropped, why don't you give me a way to supply functions, too? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 4

Problem with integer_traits and gcc on Mac OS X
by Marshall Clow 07 Apr '04

07 Apr '04

One of the regression tests for MacOS X is failing - in particular, it is reporting that boost::integer_traits<wchar_t>::min = -2147483648 boost::integer_traits<wchar_t>::max = 2147483647 but boost::integer_traits<wchar_t>:: const_min = 0 boost::integer_traits<wchar_t>:: const_max = 2147483647 [ FWIW, this is gcc 3.3 ] Nothing in the code is jumping out at me. Any suggestions for fixing this? -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> I want a machine that thinks I'm more important than it is, and acts like it. -- Eric Herrmann

1 0

RE: [boost] Generic non-derivable base class
by Reece Dunn 07 Apr '04

07 Apr '04

Matthew Vogt wrote: >The following simple base class implements the mechanism as dicussed on >Stroustrup's FAQ page, and encapsulates the virtual inheritance so that the >class can be non-virtually inherited, removing the most obvious chance of >implementation error. >Will this code work on multiple platforms? I have only tested on gcc 3.2... >[snip] Why can't you do: namespace boost { template< class T > struct nonderivable; namespace detail { template< class T > class nonderivable_base { friend T; friend class nonderivable< T >; nonderivable_base() { } nonderivable_base( const nonderivable_base & ) { } }; } template< class T > struct nonderivable: public virtual detail::nonderivable_base< T > { }; } This *will* work with MS VC 6-7.1 and Borland 5.5.1. I haven't tested on GCC or other compilers, but it should work. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

2 1

Unicode string
by Vladimir Prus 07 Apr '04

07 Apr '04

Miro Jurisic wrote: > On the other hand, in order to manipulate a Unicode string without > violating constraints on well-formedness, you have to consider the string > as a sequence of abstract characters (unless, of course, you constrain > yourself to string transformations which operate on code point sequences > yet guarantee that strings remain well-formed; there are few such > transformations -- concatenation is one of them under certain constraints). [snip] > capital letter C; combining caron; lowercase letter e > > it contains two abstract characters, but three UCS4 code points; therefore, > removing the first character from that string means removing the first two > code points of three. Removing just the first code point would leave you > with a combining caron followed by a lowercase letter e, which is not a > well-formed Unicode string. Hi Miro, so the point is that when using string-as-code-point-container, even searching and removing a character/substring might get invalid string? E.g. even looking for string 'foo' you theoretically can find string 'foo' followed by composing character, and removing just 'foo' will be invalid? > basic_string is not the abstraction you are looking for, but it's also the > only one that is readily available in STL/boost today. It may serve as a > good starting point (questionable, IMNSHO), but it should most definitely > not be treated as the right thing to use for Unicode in the long term. I wonder what's the right abstraction then? Is it necessary to have a class to represent abstract character, with all composing characters? - Volodya

3 5

RE: [boost] Re: Numeric conversions lib comments
by Rozental, Gennadiy 07 Apr '04

07 Apr '04

> > In most part proposed design looks reasonable. I have only > one major > > IMO concern. > > > > Issue: (Major) Why traits are template parameter of > converter? I've > > expressed my opinion in the matter before: Traits - as name suggest > > could not be policy. IOW should not be template parameters. > Traits are > > type specific and an ability to supply them independently to the > > primary type in most cases leads to invalid/too complicated design. > > Traits are not only template parameters of public > converter class > > but many other classes. IMO all of them should use S and T > as template > > parameters instead. > > > I have to disagree. > Traits are used as policies in too many designs, including > the STL itself, and I don't see a problem with that. I agree I don't say I like it either. Major issue with basic_string design IMO is that char_traits is template parameter > that traits classes are type specific, but they are used as > policies precisely because of that: if the user of a > parametrized facility wants a different treatment for a given > type, she can't change *the* traits for the type, all she can > do is pass in a different traits as a policy. Here is how I see it. Trait is something type specific, IOW specific to type, IOW uniquely defined by type. If you could provide trait along with the type as a template parameter, that mean you could change it independently from the type, IOW you could define different value for trait still using the same type. For example if you have component C defined like: template<typename T, typename Trait> struct C { ... }; You could instantiate it like C<MyT,TraitValue1> or C<MyT,TraitValue2>. So as you could see trait value is not uniquely defined by the type. Proper design would be to have trait stand alone class, like this: template<typename T> struct Trait { value = ... }; template<typename T> struct C { here we are using Trait<T>::value, where we used to use Trait. }; Now if the user needs to define trait value (or change from using default value provided by most traits designs), she just need to define explicit/partial specialization for this type or types family. On the other hand policy is something that is orthogonal to the primary type (actually in policy based design there may not be any primary type, but just an orthogonal policies), IOW you could use different policies in conjunction with the same type. And natural place for the policy is along with type in component definition among the template parameters. > If this were > not a policy, users would be stuck with the definition of the > default traits class. I agree that this opens a window to all > sort of problems in case a user plugs in an invalid traits, > but I think that should not constitute a reason for fixing > the traits into the converter. As always, "trust the programmer" So again Trait is not a Policy and let's not mix them > > 4. converter<>::convert converts only rvalue. Why? > > IMO we need second operation that works with lvalues. > What if I want > > to convert int& into char&? > This requires the target lvalue as a parameter instead of a > return value. It could be done yes, but I don't see the > reason. Why would want to do that? For example for [de]serialization solutions. What is in your opinion is problem domain for numeric conversion? Gennadiy.

11 50

RE: [boost] regex lib: regex_grep w/ match_posix broken?
by Benzinger, Ralph 07 Apr '04

07 Apr '04

> > Is it just me or does regex_grep return overlapping matches > > when using the match_posix flag? More specifically, grepping regex > > "a+" over text "-aaa-" will find matches "aaa", "aa", and "a" at > > offsets 1, 2, and 3, respectively. > > Yep, there's a fix going into cvs now, the patch is: > > Index: perl_matcher_common.hpp > < search_base = position = (*m_presult)[0].second; > > search_base = position = m_result[0].second; John, Thanks for the quick response. This works almost :-), but now the regex_grep misses consecutive matches: grepping regex "aaa" over "-aaaaaa-" will find only one match "aaa" at offset 1, but not the one at offset 4. Grepping over "-aaa-aaa-" works, though. Ralph

1 0

Re: [boost] [BGL] Tarjan's offline LCA algorithm.
by Cromwell Enage 07 Apr '04

07 Apr '04

No, my brother reclaimed the old computer :~ Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

1 0

regex lib: regex_grep w/ match_posix broken?
by Benzinger, Ralph 07 Apr '04

07 Apr '04

Hello, Is it just me or does regex_grep return overlapping matches when using the match_posix flag? More specifically, grepping regex "a+" over text "-aaa-" will find matches "aaa", "aa", and "a" at offsets 1, 2, and 3, respectively. This does not happen using the match_perl flag. I've confirmed this on NT and Linux platforms. The problem seems to be somewhere near perl_matcher::match_all_states(), where the inner if(!(this->*proc)()) statement is entered multiple times and thus indirectly sets (*m_presult)[0].second to an incorrect value, leading to an incorrect restart point. I know that regex_grep is deprecated, but I still prefer it over the iterator approach. Any ideas or comments? Thanks, Ralph

2 1

regex doc issue
by David Abrahams 07 Apr '04

07 Apr '04

On the match_results doc page, there's a broken link to #m12. Should be #m13? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1