Peter Dimov wrote:
Thorsten Ottosen wrote:
"Pavol Droba" <droba@topmail.sk> wrote in message news:20040219074546.GF11201@lenin.felcer.sk... [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.