«

Oliver S. wrote:
> > Actually, there is nothing wrong with the union of the buffer and the
> > pointer to the next free buffer. ...
>
> That's not the in-conformance I thought about. Look at is_yours in the
> base-class and you can find this in-conformance which might offense some
> religious C++ers.

I'm not sure I follow that; in what sense is it non-conformant? I'm
sure it will be obvious two minutes after I post this message, but
right now it isn't.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html ]

Oliver S. wrote:
> > Actually, there is nothing wrong with the union of the buffer and the
> > pointer to the next free buffer. ...
>
> That's not the in-conformance I thought about. Look at is_yours in the
> base-class and you can find this in-conformance which might offense some
> religious C++ers.

I'm not sure why is_yours() compares the pointer against the pointer to
the buffer. Comparing it against the first item in the buffer's array
would certainly be a valid test:

template<typename T>
inline
bool lallocator_buffer_if<T>::is_yours( T *pt )
{
return pt >= &at[0] and pt < &m_pbhBufferEnd->at[0];
}

> > Memory pools work best for constant sized memory allocations ...
>
> Mine does work equally good for everything up to the limit for a buffer.

Using fixed sized memory blocks to speed up variably-sized allocations
has two principal shortcomings: oversized allocations see no benefit,
while undersized allocations waste memory.

> > An even more effective optimization would to add a fixed-sized character
> > buffer data member to the string class itself.
>
> Maybe, but this wouldn't be a genral-purpose-string anymore because
> every string would carry around a buffer that might not be used.

The string with an internal character buffer would still be general
purpose - oversized strings would continue to allocate their character
buffer dynamically. An unused internal character buffer wastes no more
memory than the memory wasted by deallocated a fixed-sized buffer.
After all, deallocated buffers are never really "freed" (that is,
returned to the general memory pool where it can be used to fulfill any
subsequent memory allocation request). Rather freed buffers are held in
reserve just in case a future string allocation could use it. A string
with an internal buffer on the other hand, returns the buffer to the
general purpose memory pool (or the stack) upon its destruction.

A further advantage that an internal character buffer has over external
storage is that it adds no meaningful delay when constructing or
copying a string object. The entire internal character buffer does not
need to be initialized or copied with the string, just the portion that
contains the string's characters.

Greg


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html ]

> I'm not sure I follow that; in what sense is it non-conformant? I'm
> sure it will be obvious two minutes after I post this message, but
> right now it isn't.

I assume the data for the buffers to be placed after the data of the
base-class; this might not be true for theoretical C++-implementations.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]

>> lallocator_buffer<char, 5, 128> lbc;
>> lallostring lsTest( lallocator<char>( &lbc ) );

> Oh, this is just common error you have declared function.

Ok, these seem to have priority over variable-definitions.

> This class needs default constructor for rebind purposes.

I won't supply a default-constructor because I want the STL-classes used with
my lallocator<T> to work with the pools attached to the allocator-objects. The
allocator-objects usually stored internally in the STL-container-classes are
typically rebind'ed versions of the supplied allocator-type to allow for the
allocators supplied to the constructor of the stl-container to be of a dif-
ferent type. These allocator-objects are created through a copy-constructor
I supply. As the major STL-implementations are prepared for stateful alloca-
tors as far as possible, this works.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]

"Oliver S." wrote:
> > I'm not sure I follow that; in what sense is it non-conformant? I'm
> > sure it will be obvious two minutes after I post this message, but
> > right now it isn't.
>
> I assume the data for the buffers to be placed after the data of the
> base-class; this might not be true for theoretical C++-implementations.

OK - I can see the issue now. I hadn't noticed that assumption. You're
right - Section 10 paragraph 3 indicates that you can't rely on such an
assumption. You could remove that assumption by using a pointer to the
entire derived object, converted to void*, rather than a pointer to the
base class sub-object.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]

Oliver S. wrote:
> > This class needs default constructor for rebind purposes.
>
> I won't supply a default-constructor because I want the STL-classes used with
> my lallocator<T> to work with the pools attached to the allocator-objects. The
> allocator-objects usually stored internally in the STL-container-classes are
> typically rebind'ed versions of the supplied allocator-type to allow for the
> allocators supplied to the constructor of the stl-container to be of a dif-
> ferent type. These allocator-objects are created through a copy-constructor
> I supply.

How? On gcc 3.4.3 and 3.4.2 string requires default constructor in
allocator because it probably have some internal data structure?
Since rebinded allocator have different type then one passed in
constructor string doesn't even try to use copy constructor?
That creates big problem because string can do something like this:
//......
~string()
{
buf->alloc.deallocate(ptr->buf);
typename Allocator<T>::rebind<MyStruct>:ther alloc;
alloc.deallocate(ptr); // my example will crash in this case
}
it would be great if string have to use:
typename Allocator<T>::rebind<MyStruct>:ther alloc(buff->alloc);
but it does not, I guess, at least gcc string.

Greetings, Bane.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]

Branimir Maksimovic wrote:
> Oliver S. wrote:
> > > This class needs default constructor for rebind purposes.
> >
> > I won't supply a default-constructor because I want the STL-classes used with
> > my lallocator<T> to work with the pools attached to the allocator-objects. The
> > allocator-objects usually stored internally in the STL-container-classes are
> > typically rebind'ed versions of the supplied allocator-type to allow for the
> > allocators supplied to the constructor of the stl-container to be of a dif-
> > ferent type. These allocator-objects are created through a copy-constructor
> > I supply.
>
> How? On gcc 3.4.3 and 3.4.2 string requires default constructor in
> allocator because it probably have some internal data structure?
> Since rebinded allocator have different type then one passed in
> constructor string doesn't even try to use copy constructor?

Section 21.3.1 says that "In all basic_string constructors, a copy of
the Allocator argument is used for any memory allocation performed by
the constructor or member functions during the lifetime of the object."
Section 21.3 says the same thing about standard containers.

Granted, many of the requirements imposed on strings and containers can
be satisfied by non-member operator overloads, and those are permitted
to make use of the fact that the allocator type is required to have a
default constructor.

An implementation is allowed to assume that all instances of the
allocator type are equivalent, which means that the default constructed
allocator can be assumed to be equivalent to a copy constructed one.
However, the standard encourages implementors to avoid relying upon
that assumption.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]

> Granted, many of the requirements imposed on strings and containers can
> be satisfied by non-member operator overloads, and those are permitted
> to make use of the fact that the allocator type is required to have a
> default constructor.

Ok, but this isn't really a cosntraint for me because of the following
reason: "Global" string operators are usually slow because they generate
unnecessary temporary objects. And why should someone use a performance
-enhancing allocator primarily designed for container objects placed on
the stack *and* use global operators on strings using these allocators?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]

"Oliver S." wrote:
> > Granted, many of the requirements imposed on strings and containers can
> > be satisfied by non-member operator overloads, and those are permitted
> > to make use of the fact that the allocator type is required to have a
> > default constructor.
>
> Ok, but this isn't really a cosntraint for me because of the following
> reason: "Global" string operators are usually slow because they generate
> unnecessary temporary objects. And why should someone use a performance
> -enhancing allocator primarily designed for container objects placed on
> the stack *and* use global operators on strings using these allocators?

The most likely reason for doing something like that is because the
string/container class that they are instantiating with your
performance-enhancing allocator was written by someone with other
objectives.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]

> The most likely reason for doing something like that is because
> the string/container class that they are instantiating with your
> performance-enhancing allocator was written by someone with other
> objectives.


Why should someone not see this objective when the only
purpose of my allocator is to enhance the performance.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html ]