At 10:16 AM 3/1/2003, Alisdair Meredith wrote:
>Greg Colvin wrote:
>
>> Which is why the original releaser<> proposal is not in the standard.
>> There are just too many different kinds of resource, with too many
>> different ways of acquiring and releasing them. So it wasn't clear
>> that any gene
Greg Colvin wrote:
> Which is why the original releaser<> proposal is not in the standard.
> There are just too many different kinds of resource, with too many
> different ways of acquiring and releasing them. So it wasn't clear
> that any general facility could improve on just wrapping each reso
> > *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, jus
"Rozental, Gennadiy" wrote:
>
> > wrap<>/wrapper<>
>
> This is another name for the proxy.
Nah, proxy is wrapper's implementation detail. ;-)
http://www.research.att.com/~bs/wrapper.pdf
regards,
alexander.
___
Unsubscribe & other changes: http:/
> wrap<>/wrapper<>
This is another name for the proxy. And It has the same problem - too
generic.
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>From: "Joel de Guzman" <[EMAIL PROTECTED]>
> > manager
> >
> > Manager of widget. It's kind of implied that what is managed is the
> > resource itself, even though "resource" doesn't say anywhere. This is
> > similar to that you think it's implied that resource means it
> > manages the resource,
On Friday 28 February 2003 09:47 am, Rozental, Gennadiy wrote:
> So. Do we still want to fight about "best" name for non existent component?
What about "raii"? Maybe too specific but I don't recall an example from the
discussions that doesn't follow the principle.
--
Alkis
___
"Rozental, Gennadiy" wrote:
[... 1-6 ...]
> So. Do we still want to fight about "best" name for non existent component?
We don't. The BEST name (number 7 -- what else would you expect from such
magic number) is:
wrap<>/wrapper<>
of course. ;-)
regards,
alexander.
___
At 09:16 AM 2/28/2003, David Abrahams wrote:
>Alisdair Meredith <[EMAIL PROTECTED]> writes:
>
>> Peter Dimov wrote:
>>
>>
>>> It depends on the choice of template parameters, of course. If you go the PB
>>> way, resource<> is definitely a contender:
>>
>> This is definitely the direction I was thin
1. resource
Let me repeat myself: "resource_manager is never(almost) the RESOURCE
itself". It only managing code. This name would be really misleading. Also
managed part is not assumed. FILE is the resource but it is not managed.
2. managed
Name will be very unclear in most cases, cause the nam
Alisdair Meredith <[EMAIL PROTECTED]> writes:
> Peter Dimov wrote:
>
>
>> It depends on the choice of template parameters, of course. If you go the PB
>> way, resource<> is definitely a contender:
>
> This is definitely the direction I was thinking. Otherwise, we get
> shared_resource, scoped_res
Peter Dimov wrote:
> It depends on the choice of template parameters, of course. If you go the PB
> way, resource<> is definitely a contender:
This is definitely the direction I was thinking. Otherwise, we get
shared_resource, scoped_resource, movable_resource, etc and we start
wanting an abbre
David Abrahams wrote:
> Dave Gomboc <[EMAIL PROTECTED]> writes:
>
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 th
At 03:46 AM 2/28/2003, Joel de Guzman wrote:
>Terje Slettebø wrote:
>
>>> 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
Dave Gomboc <[EMAIL PROTECTED]> writes:
>> > 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
Alisdair Meredith wrote:
> Martin Wille wrote:
>
>> Otherwise, I completely agree with Joel's reasoning that
>> "resource" is the best name.
>
> I have mulled it over for a while, and tried to imagine myself coming
> at the issue for the first time, as someone learning C++ rather than
> learning/de
I feel like the ball boy at Wimbledon here,
interfering in a rare old ding-dong of the match of the week
de Guzman v. Slettebø
who seem to be about 40 all so far?
As someone who grew up happily on pointerless language, I don't automatically
think resource when I read pointer or ptr.
How about
Martin Wille wrote:
> Otherwise, I completely agree with Joel's reasoning that
> "resource" is the best name.
I have mulled it over for a while, and tried to imagine myself coming at
the issue for the first time, as someone learning C++ rather than
learning/devising new tricks.
In this case, I f
Joel de Guzman wrote:
> In the Macintosh, for example, the resource manager manages
"all* the resources in an application.
That is a bit misleading. The term "resource" has a special
meaning in the Macintosh world. The resource manager doesn't
manage window pointers or file handles for example.
Ot
Terje Slettebø wrote:
>> 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. What is "managed"? It i
>From: "Joel de Guzman" <[EMAIL PROTECTED]>
> 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 impli
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 cl
>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 wa
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
> its
> > 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 templa
Brian Gray wrote:
> On Thursday, February 27, 2003, at 09:15 AM, David Abrahams wrote:
>> "Sam Partington" <[EMAIL PROTECTED]> writes:
>>
>>> Could it not just be called shared. After all it is merely a more
>>> general
>>> term of shared_ptr. And the type of the resource kind of makes it
>>> im
managed_copy?
How about an abbreviated name?
Like rsrc_mgr? Although, I don't like that abbreviation for resource...
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> -Original Message-
> Behalf Of Alisdair Meredith
> Subject: [boost] Re: resource manager naming
>
> Larry Evans wrote:
>
> > Would the GOF name, proxy, be too non-specific? Policy names
> might provide
> > the specifics (whether it's a pointer o
On Thursday, February 27, 2003, at 09:15 AM, David Abrahams wrote:
"Sam Partington" <[EMAIL PROTECTED]> writes:
Could it not just be called shared. After all it is merely a more
general
term of shared_ptr. And the type of the resource kind of makes it
implicit.
std::auto_ptr is a non-shared re
"Sam Partington" <[EMAIL PROTECTED]> writes:
> Could it not just be called shared. After all it is merely a more general
> term of shared_ptr. And the type of the resource kind of makes it implicit.
std::auto_ptr is a non-shared resource manager.
--
Dave Abrahams
Boost Consulting
www.boost-co
Could it not just be called shared. After all it is merely a more general
term of shared_ptr. And the type of the resource kind of makes it implicit.
e.g.
shared is a shared file. crystal.
Though this doesn't fit at all with non sharing policies.
Sam
Alisdair Meredith wrote:
> Larry Evans w
Larry Evans <[EMAIL PROTECTED]> writes:
> Alisdair Meredith wrote:
>> Phil Nash wrote:
>>
> [snip]
>> Final disorganised point When you think 'pointer' without a
>> context, what concept do you associate first? Resource-manager? Or
>> dereferencable? The very name suggests the latter to me!
Larry Evans wrote:
> Would the GOF name, proxy, be too non-specific? Policy names might provide
> the specifics (whether it's a pointer or a resource).
Proxy, if anything, sends the wrong message to me. The name suggests
'reference', rather then 'owner'
'bookkeeper' is the best I can come up w
Alisdair Meredith wrote:
Phil Nash wrote:
[snip]
Final disorganised point When you think 'pointer' without a
context, what concept do you associate first? Resource-manager? Or
dereferencable? The very name suggests the latter to me! [Which could
be why I have such a hard time with pointers-t
Phil Nash wrote:
> The fact is that most (I would hope) of those that are subscribed to the
> list know what a smart pointer is. Many would also make the extra connection
> between smart POINTERs and general RESOURCE management.
Not sure even here we agree 100%. What is the precise scope of the
Dave Gomboc wrote:
> But those that don't would look for "resource_manager" or "resource_mgr"
> (and might even find "res_mgr"). The smart_ prefix is quite useless in
> this context, there isn't an old resource manager that is being replaced.
The whole resource management idea is quite fraught.
36 matches
Mail list logo
