Re: [boost] Re: String algorithm library
Hi On Mon, Nov 18, 2002 at 07:20:58PM -0500, Beman Dawes wrote: At 03:25 AM 11/18/2002, Pavol Droba wrote: What I want to do in the future is to change default signature of trim to something like you're proposing. There will be a variant with predicate and a set of standard predicates. This way the locale stuff will be moved out to the predicate and will not confuse you any more, I hope :) Please post the signatures when you think they are stable. I think I understand what you are planning, but it would be better to actually see it. There is new version of the lib in the sandbox. Now it contains predicate variants of all trim functions. I have also provided few default predicated to use. They are in string_funct.hpp header and can be accessed via following helper functions. if_isclassified( Type, Locale ) if_isspace( Locale ) if_isfrom( Seq ) all of them return instance to specific functor. isclassified was suggested by Genny Prota, isspace is just instantiation if isclassified with std::ctype_base::space as the type. isfrom functor lets you specify a range over set of elements you want to trim-out. I have used the same naming scheme as in standard, so all variants which accept predicate have _if suffix. A have left original variants ( those without suffix ) and they are mapping to isspace functor. Cheers, Pavol ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: String algorithm library
- Original Message - From: James Curran/MVP [EMAIL PROTECTED] While there is a certain elegance to the names, I'd have to vote against those. It's not immediately obvious from the names trim/trimmed which one is inplace and which isn't. well, I would say it is. verbs in the imperative donote mutation, adjectives denote copy. Further, in the matter of lower_cased/to_lower_case, if you guess wrong, the other one isn't nearby in an alphabetic listing of functions. remove or add to_ from one of them? regards Thorsten, AAU ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: String algorithm library
On Mon, Nov 18, 2002 at 06:14:01PM +0100, Thorsten Ottosen wrote: - Original Message - From: James Curran/MVP [EMAIL PROTECTED] While there is a certain elegance to the names, I'd have to vote against those. It's not immediately obvious from the names trim/trimmed which one is inplace and which isn't. well, I would say it is. verbs in the imperative donote mutation, adjectives denote copy. Further, in the matter of lower_cased/to_lower_case, if you guess wrong, the other one isn't nearby in an alphabetic listing of functions. remove or add to_ from one of them? I have already changed names to to_lower and to_lower_copy. This way it conform with STL algorithm nameing-rules. IMO it's not the most beautiful way, but at least it is standard .. Pavol ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: String algorithm library
At 03:25 AM 11/18/2002, Pavol Droba wrote: What I want to do in the future is to change default signature of trim to something like you're proposing. There will be a variant with predicate and a set of standard predicates. This way the locale stuff will be moved out to the predicate and will not confuse you any more, I hope :) Please post the signatures when you think they are stable. I think I understand what you are planning, but it would be better to actually see it. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: String algorithm library
On Mon, Nov 18, 2002 at 06:52:53PM +0100, Gennaro Prota wrote:
On Mon, 18 Nov 2002 09:25:38 +0100, Pavol Droba [EMAIL PROTECTED]
wrote:
You are probably right that some ideas are confusing without explanation.
In fact the reason why I was perplexed is that everybody seems to
focus on minor issues like the names of the templates, while the
design should be addressed first IMHO. That's odd because people here
are not likely to let errors easily pass.
Thanks for comments. I appreciate them very much. This is very first version of the
library and I'm willing to change it to more usable way. Actually I'm already working
on some changes.
[snip]
What I want to do in the future is to change default signature of trim to something
like you're proposing. There will be a variant with predicate and a set of standard
predicates. This way the locale stuff will be moved out to the predicate and will
not confuse you any more, I hope :)
Well, I'm confused by definition :-) Anyhow I think what you are
proposing is actually an algorithm library. It provides
*generalizations* of typical string algorithms. As I hinted at, trim()
can be seen as an algorithm that removes the elements that satisfy a
given predicate from the beginning of any sequence.
You are right, I want to provide string algorithm
library, not just a bunch of functions to manipulate with strings.
Algorithms can be used anywhere they fit.
Now, it's a matter
of how much information you need and how you want to provide it. From
the perspective of generic programming the choice I find natural is a
pair of iterators and a predicate. To do the same job with spaces
you need ctype, but that's easily solved with an appropriate
functor:
// WARNING: completely untested!!!
//
template std::ctype_base::mask Type, class charT = char
class is_classified_as : public std::unary_functioncharT, bool
{
std::ctypecharT const m_ctype;
public:
// ctor from a ctype
is_classified_as (std::ctypecharT ct) : m_ctype(ct) {}
// ctor from a locale (for convenience)
is_classified_as (std::locale const loc = std::locale())
: m_ctype(std::use_facet std::ctypecharT (loc)) {}
bool operator() (charT c) const { return m_ctype.is(Type, c);}
};
this one I haven't though of. Looks interesting
What I would see is a bunch of trim variants accepting a predicate
and, separately, a bunch of string-specific versions like e.g:
template typename StringT
StringT trim_left(StringT const str,
std::locale const loc = std::locale())
{
typename StringT::const_iterator it
= std::find_if(
str.begin(),
str.end(),
std::not1 (is_classified_asstd::ctype_base::space())
);
return StringT(it, str.end());
}
Don't stop too much on the details though, because that's just to
explain the idea.
As for the functor stuff. Internaly the trim functions are implemented
exactly the way you are proposing. There is isspaceF functor which is
called by transformation function.
Anyway I'm currently changing interface to support user defined predicates.
Library will contain a set of default predicates and shortcuts to use them.
Any ideas about what functors to include are welcome.
(BTW if there's interest in a collection of functors like the one
above for integration with STL algorithms as well I'm willing to
volunteer)
Regards,
Pavol
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: String algorithm library
On Mon, Nov 18, 2002 at 07:20:58PM -0500, Beman Dawes wrote: At 03:25 AM 11/18/2002, Pavol Droba wrote: What I want to do in the future is to change default signature of trim to something like you're proposing. There will be a variant with predicate and a set of standard predicates. This way the locale stuff will be moved out to the predicate and will not confuse you any more, I hope :) Please post the signatures when you think they are stable. I think I understand what you are planning, but it would be better to actually see it. Implementation will be in the sandbox soon, I'll post the note on the list when they will be ready. Regards, Pavol ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: String algorithm library
On Sun, Nov 17, 2002 at 05:36:35PM +0100, Gennaro Prota wrote: Hi Pavol, I haven't been following this thread so please forgive me if I'm just pointing out something stupid, or problems that you already know. I had a quick glance at the library and I'm a little confused at what is its scope. For instance the is space generalization makes in fact functions like trim() and the like generic algorithms that remove a given element (or its equivalents) from the beginning and the end of a sequence. At this point either you make clear that the library isn't specifically a string library or that isspaceF is actually a generic functor that can test whatever charT you like (and change its name at least). You are probably right that some ideas are confusing without explanation. It should all go into documentation, but there no such a thing right now, because of very preliminary version of the lib. Idea of the string lib is to provide a set of string related algorithms, but not necessary working only with basic_string. So you can use most of the algorithms on any compatible sequence. It makes it easy for instance to compine basic_stringchar with vectorint in one function call. This makes sense for example if you are trying to call som C-style API for which vector is much better variant then basic_string. Trimming: Iterator trim_begin( Iterator InBegin, Iterator InEnd, const std::locale Loc=std::locale() ) Seq ltrim( const Seq Input, const std::locale Loc=std::locale() ) Seq ltrim_in( Seq Input, const std::locale Loc=std::locale() ) Seq rtrim( const Seq Input, const std::locale Loc=std::locale() ) Seq rtrim_in( Seq Input, const std::locale Loc=std::locale() ) Seq trim( const Seq Input, const std::locale Loc=std::locale() ) Seq trim_in( Seq Input, const std::locale Loc=std::locale() ) This is in accordance with my confusion :-) What has a locale to do with a generic sequence? If I imagine a generalized trim function (say, a function that removes all the odd numbers from the beginning and the end of a vectorint) I imagine, type requirements about the iterators etc. aside, signatures like: template typename Iterator, typename Elem Iterator trim (Iterator start, Iterator end, Elem const ); template typename Iterator, typename Pred Iterator trim (Iterator start, Iterator end, Pred pred); It seems that either the design is seriously flawed or (more likely) I'm missing something. I have already a plan for changing this. The reason for locale paramter is that most obvious scenario for using trim it to remove spaces. And term space is locale specific. Locales are not working above a generic sequence, but with every single element, so if you try vectorchar everything is perfectly correct. What I want to do in the future is to change default signature of trim to something like you're proposing. There will be a variant with predicate and a set of standard predicates. This way the locale stuff will be moved out to the predicate and will not confuse you any more, I hope :) Regard, Pavol ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
