>>>>> "David" == David Abrahams <abrahams@mediaone.net> writes:

Hi Dave,

Thanks  for  the  reply.  When  I  tested  an  allocator of  the  type
my_alloc<int,pool>, it didn't seem to  work with the STL vector class.
However, that may have been a bug in my attempt.  My code is currently
in  the middle  of  its second  generation,  and not  testable at  the
moment.   In  checking Stroustrup's  text  further  to  reply to  your
questions,  I found  that the  my_alloc<int,pool> form  is  implied in
section 19.4.3 on page 573 of the 3rd edition.  The standard allocator
definition in section 19.4.1 on page 567 does only have one type as in
my_alloc<int>?   I am  slightly confused  at  the moment  and need  to
examine this further.  But I also wanted to get you an immediate reply
and thank you for your followup.

    >> allocator<int,shared> allocator<int,pooled>
    >> allocator<string,persistent>

    David> How would that be beneficial?

its  beneficial in  the  same  way that  allocator<T>  is better  than
allocator.  It  is easier to  maintain one general coder  version than
many separate specific instances.  So  in theory it would be better to
work with one:

alloc<T>

than with alloc_int, alloc_char, alloc_double, etc.  Plus you can use
alloc<T> for an anticipated type.  So it is better to have:

alloc<T,Memory_Type>

instead of shared_alloc<int>, persistent_alloc<int>, pooled_alloc<int>,
etc.

    >>
    >> but designing multiple allocators seems somewhat less elegant.
    >> Code reuse may impaired.

    David> How?

Its the  same answer as above.   If you use  multiple type parameters,
then only one alloc<T,Memory_Type>  would have to be debugged, instead
of  shared_alloc<int>, persistent_alloc<int>,  pooled_alloc<int>, etc.
Plus handling unanticipated secondary types is more difficult.

The whole point of my line of  questioning is that it would be nice to
get these various allocators incorporated into the STL.

    >> Perhaps it might be easier for users to simply provide types to
    >> the interface as in the first case, as opposed to entirely
    >> separate classes.

    David> Think for a moment how the interface you propose would be
    David> implemented. Would the allocator template itself be able to
    David> take _any_ action at all without consulting its 2nd type
    David> parameter (shared, pooled, persistent...)? I think for real
    David> genericity, the answer is no. That means you've just made
    David> the allocator template an empty shell which just forwards
    David> its arguments to members of the 2nd type parameter. What's
    David> the point?

If  here you  mean,  could there  be  a default  type  for the  second
parameter which  specifies the  type of the  allocator, I  believe the
answer is yes, it could assume a default type.

Maybe, however, I am wrong, and, of course, that it why I'm asking. :)

Thanks again for the thoughts.

marc

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Marc D Bumble wrote:
>
> >>>>> "David" == David Abrahams <abrahams@mediaone.net> writes:
....
>     >> allocator<int,shared> allocator<int,pooled>
>     >> allocator<string,persistent>
>
>     David> How would that be beneficial?
>
> its  beneficial in  the  same  way that  allocator<T>  is better  than
> allocator.  It  is easier to  maintain one general coder  version than
> many separate specific instances.  So  in theory it would be better to

Yes, when you can place some significant amount of code in the template
class. That's not the case with your allocators. You have to specialize
by allocator type before you can attach any specific code to the
template. Therefore, you get no benefit over writing seperate classes
for each allocator type.

>     >> but designing multiple allocators seems somewhat less elegant.
>     >> Code reuse may impaired.
>
>     David> How?
>
> Its the  same answer as above.   If you use  multiple type parameters,
> then only one alloc<T,Memory_Type>  would have to be debugged, instead
> of  shared_alloc<int>, persistent_alloc<int>,  pooled_alloc<int>, etc.
> Plus handling unanticipated secondary types is more difficult.

Why? What body of code could you write that was shared across allocator
types?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>>>>> "James" == James Kuyper <kuyper@wizard.net> writes:

<snipped>

    James> Yes, when you can place some significant amount of code in
    James> the template class. That's not the case with your
    James> allocators. You have to specialize by allocator type before
    James> you can attach any specific code to the
    James> template. Therefore, you get no benefit over writing
    James> seperate classes for each allocator type.

<... more snipped>

    James> Why? What body of code could you write that was shared
    James> across allocator types?

I'm finding  myself writing  bit-vector and page  locking code  which I
believe are just some examples  of shareable code across what could be
multiple allocator types.  Shared  and persistent types could also both
be pooled. It seems to me that there is plenty of opportunity for code
reuse within allocators.

I actually posted the original question before I realized that section
19.4.3  Stroustrup's 3rd edition  actually implies  the concept  of an
allocator with two type parameters:

 1. the contained type (int, char, double, etc.)
 2. the allocator type (persistent, shared, pooled, default)

as in:
 My_alloc<int,persistent>
 My_alloc<int,shared>
 My_alloc<int,default>

I apologize for being stubborn;  however, I really don't understand the
opposition here at all, especially when Stroustrup's 3rd edition seems
to imply what I am suggesting.  Is the lack of a second type parameter
in  allocators simply  an oversight  in the  implementations?   If not,
start listing the reasons.

marc

--

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Marc D Bumble wrote:
>
> >>>>> "James" == James Kuyper <kuyper@wizard.net> writes:
>
> <snipped>
>
>     James> Yes, when you can place some significant amount of code in
>     James> the template class. That's not the case with your
>     James> allocators. You have to specialize by allocator type before
>     James> you can attach any specific code to the
>     James> template. Therefore, you get no benefit over writing
>     James> seperate classes for each allocator type.
>
> <... more snipped>
>
>     James> Why? What body of code could you write that was shared
>     James> across allocator types?
>
> I'm finding  myself writing  bit-vector and page  locking code  which I
> believe are just some examples  of shareable code across what could be
> multiple allocator types.  Shared  and persistent types could also both
> be pooled. It seems to me that there is plenty of opportunity for code
> reuse within allocators.

Possibly, but how could you put that code in the general allocator
class? Your specializations for each allocator type will NOT inherit
code from the generic class template, so your code re-use will have to
be through some other mechanism. That renders the generic template
nearly useless, which brings into question the design choice of using a
generic template.

....
> I apologize for being stubborn;  however, I really don't understand the
> opposition here at all, especially when Stroustrup's 3rd edition seems
> to imply what I am suggesting.  Is the lack of a second type parameter
> in  allocators simply  an oversight  in the  implementations?   If not,
> start listing the reasons.

Infeasibility of placing any useful code in the generic template.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Marc D Bumble wrote:
>
> Is there  an oversight in the allocator  definitions?  Allocators take
> one  template  type parameter.   The  allocator then provides  memory
> having the same type as specified by its single parameter.  And all of
> this works  well.  However,  it might be  beneficial if  the allocator
> also took a second parameter which described the type of the allocator
> itself.  For instance, a user could specify:
>
>    allocator<int,shared>
>    allocator<int,pooled>
>    allocator<string,persistent>

std::allocator<> takes a template type parameter, but the general
allocator requirements in section 20.1.5 make no mention of template
parameters. They don't say that a type parameter is needed, and they
don't prohibit the presence of additional parameters.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi Marc,

"Marc D Bumble" <bumble@isd.net> wrote in message
news:m3wvkj4lva.fsf@cadence.glidepath.org...
>
> Is there  an oversight in the allocator  definitions?  Allocators take
> one  template  type parameter.   The  allocator  then provides  memory
> having the same type as specified by its single parameter.  And all of
> this works  well.  However,  it might be  beneficial if  the allocator
> also took a second parameter which described the type of the allocator
> itself.  For instance, a user could specify:
>
>    allocator<int,shared>
>    allocator<int,pooled>
>    allocator<string,persistent>

How would that be beneficial?

> I realize that the user could just provide different allocators as in:
>
>    shared_allocator<int>
>    pooled_allocator<int>
>    persistent_allocator<persistent>
>
> but designing  multiple allocators seems somewhat  less elegant.  Code
> reuse may  impaired.

How?

> Perhaps it might  be easier for  users to simply
> provide types  to the interface  as in the  first case, as  opposed to
> entirely separate classes.

I don't see how it would be easier... you'd end up writing vector<int,
allocator<int, pooled> > instead of vector<int, pooled_allocator<int> >. You
could always call pooled_allocator simply "pooled". Then you have
vector<int, pooled<int> >. That's easier to type, FWIW.

Think for a moment how the interface you propose would be implemented. Would
the allocator template itself be able to take _any_ action at all without
consulting its 2nd type parameter (shared, pooled, persistent...)? I think
for real genericity, the answer is no. That means you've just made the
allocator template an empty shell which just forwards its arguments to
members of the 2nd type parameter. What's the point?

-Dave

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Is there  an oversight in the allocator  definitions?  Allocators take
one  template  type parameter.   The  allocator  then provides  memory
having the same type as specified by its single parameter.  And all of
this works  well.  However,  it might be  beneficial if  the allocator
also took a second parameter which described the type of the allocator
itself.  For instance, a user could specify:

   allocator<int,shared>
   allocator<int,pooled>
   allocator<string,persistent>

I realize that the user could just provide different allocators as in:

   shared_allocator<int>
   pooled_allocator<int>
   persistent_allocator<persistent>

but designing  multiple allocators seems somewhat  less elegant.  Code
reuse may  impaired.  Perhaps it might  be easier for  users to simply
provide types  to the interface  as in the  first case, as  opposed to
entirely separate classes.

marc
--

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]