Terje Slettebų wrote:
>> From: "Joel de Guzman" <[EMAIL PROTECTED]>
>
>> Dave Gomboc wrote:
>>>>> So then reverse resource_manager and get managed_resource<>, or
>>>>> just managed<>.
>>>>
>>>> Why not just resource<>? Management is implied anyway; that's the
>>>> reason for the existence of the class.
>>>
>>> *laugh* I was thinking exactly the opposite. To me, the resource
>>> itself
>>> is clear from the template parameter -- it's the management that
>>> needs to
>>> be indicated.
>>>
>>> +1 for managed<>.
>>
>> What template parameter? That's not a part of the name.
>> Template parameters, just like function arguments are never
>> a part of the name. You do not need to read the header file
>> to get the essence. The name itself should indicate the function
>> of the class without looking elsewhere.
>>
>> managed<>? What is managed? ... answer: take a look at
>> the template parameter and you'll see what I mean. I'm
>> sorry, that doesn't make sense.
>
> managed<lock>
> managed<widget,shared> // Smart pointer
>
> resource<lock>
> resource<widget,shared> // Smart pointer
>
> When the template is in use (unless it uses a default template
> argument),
> the template argument will be part of the signature, and therefore
> show what is managed. Therefore, I think managed<> makes sense, too.
>
> IIUC, your argument can be used for e.g. std::pair, too. std::pair<>
> of
> what? Answer: That depends on the template arguments.
No, a pair is always a pair regardless of what the composed types are:
pair<T1, T2> // a pair comprised of T1 and T2
You don't need to know the template parameters to know that it
is a *pair*. That's the big difference. The template parameter is an abstract
concept. Detached from the parameters, it is still a pair. The same does not
hold for managed<T>. What is "managed"? It is not even a noun without the
qualifiers.
managed<widget> // does this *manage* the actual rendering into the window?
Gotcha! No it doesn't! OTOH:
resource<widget> // ah yes, widget is a resource. we want to manage the resource
--
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
