Topic: article: allocators...exceptions...new/delete [reply to: Sat, 12


Author: dhruvbird@gmx.net (Dhruv Matani)
Date: Wed, 16 Jul 2003 16:47:02 +0000 (UTC)
Raw View
On Sat, 12 Jul 2003 09:24:52 -0400, James Kuyper wrote:

>> Yes, in fact, I have the 1996 draft copy.
>
> Get the real standard. There are LOTS of difference between that draft
> and the final version.
>

I will ASA I find someone to sponsor it :-) I wonder if the guys at the
ansi standard organization give any sort of student discount?

[snip]......


>> What is the advantage of using such stateful allocators?
>
> On simple kind of stateful allocator uses a new, distinct memory pool
> each time a new instance of the allocator is created, and shares that
> pool with every instance created by copy construction, copy
> assignment, and conversion. Instances that use different memory pools
> are inequivalent, because they don't have access to each other's
> memory pools.
>

So, basically, it's like per-class allocators.


> ...
>> The problem that I had was that I was assuming that since nothing was
>> mentioned about constructors of allocators throwing, I was assuming
that
>> that requirement was the same as std::allocator, and that was
stopping me
>> from desinging the allocatior properly.
>
> Just read section 20.1.5; don't infer any additional requirements just
> because they apply to the default allocator.

Yes, I've got to stop making stupid assumptions.

Regards,
-Dhruv.



---
[ 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                       ]





Author: Dhruv Matani <dhruvbird@gmx.net>
Date: 16 Jul 2003 17:55:11 GMT
Raw View
On Sat, 12 Jul 2003 07:35:12 +0000, Richard Smith wrote:


[snip]...

> Basically just that if the template argument is required to model the
> concept of an Allocator, then it results in undefined behaviour if the
> template argument is not a model of an Allocator.
>

[snip]...

> OK.  The actual Standard does not have a 17.3.3.6, but it appears to
be an
> older version of the same thing.  I guess that the clause about
exceptions
> has now been weakened to read
>
> | if any replacement function or handler function or destructor
> | operation throws an exception, unless specifically allowed in
> | the applicable Required behavior paragraph.
>
> Functions on allocators are not replacement function (which is a very
> specific term meaning functions like operator new() that are defined
in the
> library but which may also be defined in code).  Nor is it a handler
> function (again, a very specific term meaning functions such as those
passed
> to set_new_handler, set_terminate and set_unexpected).  The destructor
rule
> applies, but I don't think there's ever been any discussion about that
one.
>
>> However, to be truthful, I always used
>> to call them templated copy constructors, now that I know, I'll call
them
>> templated constructors.
>
> Conversion constructors is another term that is sometimes encountered.
>
>> What is the advantage of using such stateful allocators?
>
> You don't have to store the heap in static variables as you have.  You
can
> have multiple heaps for a given type.
>
>

Thanks. :-)


>> >> Yes, but I would want to allow default construction. Nice idea if
I
> want
>> >> to disallow default construction though! It will kind of solve the
>> >> problem, but in a very crude way, where, the user will *have*
> instantiate
>> >> an allocator, and pass it to the ctor.
>> >
>>
>> "There's no reason not to make the default constructor do the
allocation
>> rather than the custom constructor"
>>
>> I didn't quite get you here......
>
> I meant do something like
>
>  class alloc_impl { ... };
>
>  template <class T>
>  class my_allocator {
>    public:
>      my_allocator() : pimpl( new alloc_impl ) {}
>
>    private:
>      boost::shared_ptr<alloc_impl> pimpl;
>  };
>

Ok, this example makes it clear. Thanks again.

Regards,
-Dhruv.








---
[ 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                       ]