From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-10-18 08:18:44
Pavol Droba wrote:
>>* The default should be copying algorithms, not modifying algorithms!
> In the beginning of the library implementation, the copy versions were default.
> However, than there was a discussion on the list and people demanded, that
> the default should be inplace.
> I don't remember the exact reasons now, but one of them was the similarity
> to the STL. Algorithms there are using the same convention (i.e. copy variant has suffix).
> I don't have any strong preference for either of conventions. But naming is very
> subjective matter, so I would like to hear more votes for the change before I'll
> go and do something.
Of course. I would still vote "yes" if the mayority decides that the
current default is the prefered one..
> As for the "apply". This is not very reasonable, since in the majority algorithms,
> the implementation of copy and inplace version are quite different.
Hm, I don't understand this. Anyway, it was just an idea and it's
probably best to go for the easiest solution and use a different name.
>>* The documentation contains the docs for detail::-stuff. But, well,
>>those are details and probably are only bloat for the documentation.
>>Even worse: People will use them, as they are documented :)
> The library is layered. I assume, that you are refering to the second layer
> (i.e. namespace boost::string_algo). This is not a detail::-stuff. It it
> designed to be used by advanced users. I think, that it could be very usable,
> and I would encourage the users to try it and use it.
No, but I guess I haven't expressed myself clearly. The return values of
some functions are e.g. token_finder exposes the detail::-return type
instead of hiding it:
detail::token_finderF< PredicateT >
token_finder(PredicateT Pred, bool bCompress = true);
I think Peter Dimov provided a good alternative in his documentation in
those situations, where the docs contain something like
'implementation-defined-type' in italics and only say what basic
guarantees, e.g. derived from XYZ, the result type provides instead of
specifying it explicitly.
-- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk