Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-03-21 16:18:19


"Daniel James" <daniel_at_[hidden]> wrote in message
news:d1napl$8pu$1_at_sea.gmane.org...
Peter Dimov wrote:
> Thorsten Ottosen wrote:
>
>> 3. consider if the primary template should not take 1 range parameter
>> and call hash_range;
>> unordered containers can then be explicitly overloaded when they
>> become available.
>> this would also have the great effect that subranges like
>> sub_range<string> "just works"
>> by default
>
>
> I don't remember this being discussed during the review, could you
> please explain it in more detail? Do you mean that hash_value should
> have a primary template that assumes that its argument is a range?

yes.

| If
> so, I strongly oppose it. Ranges aren't special from the point of view
> of hash_value, they shouldn't monopolize the primary template.

why should anything *special* monopolize the primary template? Why not
something
*general*?

| The
> proper way to make hash_value work with sub_range<T>, as with any other
> type, is for sub_range to define a hash_value overload as an inline
> friend or in its namespace.

|I think Thorsten is referring in part to some off list emails, and in
|part to when I wrote (about removing the includes for all the standard
|containers):
|
|> Another possible solution is to just use Boost.Range on anything that
'looks' like a container. But this will break on unordered containers (as
equivalent containers can have different |sequences).
|
|I forgot to mention that there's no way to tell what 'looks' like a
|container at all. Joaquín replied:
|
|> Too broad IMHO.
|
|So, I think we all rejected the idea. It would be nice if there was a
|way to do something like that, but there isn't.

that Joachin don't like the idea is ok, it's just not an arguemnt in favor of
much.

What are the obstacles? The unordered containers can define their
own version.

Btw, would you please describe why the unordered containers would "break"?

-Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk