Boost logo

Boost :

From: Edward Diener (eddielee_at_[hidden])
Date: 2004-02-19 10:37:19

Peter Dimov wrote:
> Thorsten Ottosen wrote:
>> "Pavol Droba" <droba_at_[hidden]> wrote in message
>> [ambiguity not an issue]
>>> Please give me an example of an algorithm, that can be threated
>>> differently for strings and for containers. If there would be
>>> something like that (I don't see any), than is would make sense to
>>> use different names, rather then just
>>> different namespace. Otherwise, a user can get quite confused.
>> The problem arise if there is, let's say, four versions of a
>> particular algorithm.
>> Two works on iterators and two works on containers and there might be
>> other arguments too. It certainly clashes in
>> the container algos so that we can't have unqualified calls but must
>> use boost::XX and std::XX.
> I'm with Pavol here. One useful guideline is: "Do not overload a
> function if you care which overload would be called." In other words,
> functions with the same name should - roughly - have the same effect.
> They may differ in efficiency, const correctness, and so on, but the
> general effect should be the same.
> In other words, if I write replace(s, x, y), it should always replace
> all occurences of x in s with y and return the result (for example),
> no matter whether it's std::replace, str::replace, or cnt::replace.
> This is a guideline, not a rule. You can break it if you think the end
> result would be better without it. But if followed, it leads to code
> that is more readable and less error-prone.

This was very much the point that I was making also. If one overloads too
many functions with the same name in a single namespace, I believe it
becomes confusing for the end user unless all of them are closely related to
the same objects. That is why I was in favor of sectioning off boost string
and boost container functions in their own boost::algorithm namespaces.

As far as typing in long namespace names, aliases can alway be used.

Finally I believe very strongly in sectioning off code into its own
namespace. It creates much less headaches at the expense of possibly more
typing, but this is a tradeoff I will always take. I believe it leads to
much clearer code.

Boost list run by bdawes at, gregod at, cpdaniel at, john at