Re: allocators...exceptions...new/delete - C++ Language (Moderated)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Re: allocators...exceptions...new/delete
Goto page 1, 2, 3, 4, 5, 6, 7, 8 Next

C++Talk.NET Forum Index -> C++ Language (Moderated)

View previous topic :: View next topic

Author

Message

Ross Ridge
Guest

Posted: Wed Jun 25, 2003 3:13 pm Post subject: Re: allocators...exceptions...new/delete

[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:

Quote:

Not being able to allocate the memory in an allocator is not an illegal
operation. Normally, too, it doesn't occur in the constructor of the
allocator, but when the allocate function is called. And the standard
requires the allocate function to throw bad_alloc if it cannot allocate
the memory.

Dhruv <dhruvbird (AT) gmx (DOT) net> wrote:

Quote:

Yes, but the thing is that I have a link allocator (for single
objects), and it does allocate in the constructor, and since I'm
organizing the nodes as a list, this technique helps me a lot (to have
a node already during construction). However, even then I'm just
allocating space for a single node in the ctor, but that call to
malloc may even fail, and failure to indicate that would lead to
incorrect results later on.

Defer allocation of the single node until the first call to allocate().

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] [email]rridge (AT) csclub (DOT) uwaterloo.ca[/email]
-()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/
db //

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

Richard Smith
Guest

Posted: Fri Jul 04, 2003 5:41 pm Post subject: Re: allocators...exceptions...new/delete

"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote

Quote:

I can't see a requirement in the Standard for allocators' constructors or
copy constructors not to throw. Table 32 only states that deallocate
mustn't throw. This suggests to me that everything else can throw an
exception. This is in keeping with 17.4.3.6/2 which says that operations
may throw unless otherwise specified, which talks about requirements of
template arguments. (Allocators are typically used as template arguments.)
Perhaps you're thinking of the requirement that std::allocator's default and
copy constructors do not throw?

In particular, I would say that if your default constructor needs to
allocate memory and fails, it certainly should indicate this by throwing an
exception. I'm less convinced about a copy constructor that throws --
allocators probably should have handle rather than value semantics and so
would hold onto their internals using something like boost::shared_ptr. If
you really need a copy constructor that throws, make sure you provide an
overload / specialisation of std::swap that does not throw.

Finally, if your STL properly supports stateful allocators (they are not
required to: see 20.1.5/4), and you are prepared to tie yourself to such
STLs, you could make a default constructed allocator always fail to
allocate, and provide a custom constructor that correctly initialises the
object. You would then need to pass a correctly constructed allocator into
STL containers' constructors:

namespace details {
class my_allocator_impl {
public:
void* do_allocate( size_t bytes );
// ...
};
}

template <class T>
class my_allocator {
public:
my_allocator() {}
my_allocator(/* some parameter */)
: pimpl( new details::my_allocator_impl(/*...*/) {}

T* allocate(size_t n, void* hint = 0) {
if (pimpl)
return static_cast<T*>
( pimpl->do_allocate(n * sizeof(T)) );
throw bad_alloc();
}

private:
boost::shared_ptr<details::my_allocator_impl> pimpl;
};

Something like this also allows more code to be moved out-of-line, reducing
dependencies.

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

Ron Natalie
Guest

Posted: Thu Jul 10, 2003 4:40 am Post subject: Re: allocators...exceptions...new/delete

"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote

Quote:

I can't see a requirement in the Standard for allocators' constructors or
copy constructors not to throw.

20.4.1
allocator() throw();
allocator(const allocator&) throw();
template <class U> allocator(const allocator<U>&) throw();
~allocator() throw();

Of course, this is for std::allocator<>()

That only says the default allocator will not throw. It doesn't say that any
allocator used is required not to throw.

Quote:

Table 32 only states that deallocate
mustn't throw.

Where is Table 32?

20.1.5 Allocator Requirements.

Quote:

I have only upto 17.3.4.8, where it says:
3 Any of the functions defined in the C++ Standard library that do not
have an exception-specification may throw implementation-defined
exceptions.33) An implementation may strengthen this implicit excep-
tion-specification by adding an explicit one.34)

Is this what you are talking about?

That and the absence of any requrirement in 20.1.5.

Quote:

Yes.
I'm assuming that whatever holds true for std::allocator<> should hold
true for all other allocators, so that the user can have some sort of
guarantee that whatever allocator he/she uses,

Bad assumption. The general allocator requirements are in 20.1.5. The
fact that the std allocator is better behaved than required doesn't mean
anything.

Quote:

A templated copy ctor that throws, not the normal copy ctor.

There's no such thing as a templated copy constructor.
]

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

Dhruv
Guest

Posted: Fri Jul 11, 2003 12:49 pm Post subject: Re: allocators...exceptions...new/delete

On Tue, 08 Jul 2003 02:32:22 +0000, Dhruv wrote: Just another quick question: Are allocators allowed to be templated around more that one template parameter? I asked this because boost allocators are, so would that make then standard compliant? Also, with such a design, template template parameters would not work, or would they? Reagrds, -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 ]

Dhruv
Guest

Posted: Fri Jul 11, 2003 12:50 pm Post subject: Re: allocators...exceptions...new/delete

On Thu, 10 Jul 2003 04:40:40 +0000, Ron Natalie wrote:

[snip]......

Thanks (for the snipped stuff).

Quote:

A templated copy ctor that throws, not the normal copy ctor.

There's no such thing as a templated copy constructor.

Thanks, I just found that out :-)

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 ]

James Kuyper
Guest

Posted: Sat Jul 12, 2003 8:36 am Post subject: Re: allocators...exceptions...new/delete

"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote

Quote:

On Tue, 08 Jul 2003 02:32:22 +0000, Dhruv wrote:

Just another quick question: Are allocators allowed to be templated around
more that one template parameter?

The standard doesn't specify the number of template parameters. You
can have as many or as few as you wish, so long as the requirements in
20.1.5 are met.

The standard doesn't even require one template parameter. When you
re-bind an allocator, the rebind has to work with arbitrary types, so
that requires at least one templated family of allocators. However, a
given allocator type might work only for one type, and have a rebind
member that connects it to a templeted allocator.

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

Randy Maddox
Guest

Posted: Sat Jul 12, 2003 1:22 pm Post subject: Re: allocators...exceptions...new/delete

"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote

Quote:

On Wed, 09 Jul 2003 19:32:56 -0400, Richard Smith wrote:

[snip]......

Maybe your using a draft copy of the Standard? If so, you really should buy
a real copy -- it's not expensive and contains the definitive answer to
(almost) all questions like this.

Yes, in fact, I have the 1996 draft copy.

No need to work with outdated material. Just go to www.ansi.org and
download a .pdf copy of the current Standard for $18US.

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

Andy Sawyer
Guest

Posted: Sat Jul 12, 2003 1:23 pm Post subject: Re: allocators...exceptions...new/delete

In article <pan.2003.07.10.18.19.19.500436 (AT) gmx (DOT) net>,
on 11 Jul 2003 08:49:35 -0400,
"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote:

Quote:

On Tue, 08 Jul 2003 02:32:22 +0000, Dhruv wrote:

Just another quick question: Are allocators allowed to be templated around
more that one template parameter?

In the case of std::allocator, the answer is clearly no (due to the
template template parameter issue).
For other allocators, however, I see no reason why not - although making
rebind do the right thing might be interesting.

Quote:

Also, with such a design, template template parameters would not work, or
would they?

It rather depends on what you mean...

Regards,
Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
how fast light travels it finds the darkness has always got there first,
and is waiting for it." -- Terry Pratchett, Reaper Man
---
[ 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 ]

Richard Smith
Guest

Posted: Sat Jul 12, 2003 1:24 pm Post subject: Re: allocators...exceptions...new/delete

"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote

Quote:

On Tue, 08 Jul 2003 02:32:22 +0000, Dhruv wrote:

Just another quick question: Are allocators allowed to be templated around
more that one template parameter?

Absolutely. There are requirements on the template parameters of the
allocator. There isn't even a requirement that it be templated, though it's
hard to think how else it could be implemented. Basically, as long as you
can make rebind<> work, you're fine.

Quote:

Also, with such a design, template template parameters would not work, or
would they?

Not sure how you want to use template template parameters.

If you want to do something like

template <class T, template
class my_allocator;

this is fine.

If you want to do

template <class T> class my_allocator;
std::vector< int, my_allocator > v;

it is not OK.

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

James Kuyper
Guest

Posted: Sat Jul 12, 2003 1:24 pm Post subject: Re: allocators...exceptions...new/delete

"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote

Quote:

On Wed, 09 Jul 2003 19:32:56 -0400, Richard Smith wrote:
....
Maybe your using a draft copy of the Standard? If so, you really should buy
a real copy -- it's not expensive and contains the definitive answer to
(almost) all questions like this.

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.

....

Quote:

A stateful allocator (I don't think the Standard uses this term, but it is
used commonly elsewhere) is one that can have internal state. The STL is
not required to support such allocators (there is a get-out clause in
20.1.5/4), but implementations are "encouraged" to do so and increasingly
many do. With a stateless allocator, it is always possible to deallocate
memory with any allocator of the same type as the one that created it. The
std::allocator class is an example of such an allocator. With a stateful
allocator, you must effectively keep a copy of the allocator that allocated
a piece of memory around to deallocate it again. This makes implementing
STL-like containers harder, hence the get-out clause in 20.1.5/4.

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.

....

Quote:

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

Dhruv
Guest

Posted: Thu Jul 17, 2003 5:18 am Post subject: Re: allocators...exceptions...new/delete

On Sat, 12 Jul 2003 09:23:19 -0400, Andy Sawyer wrote:

Quote:

In article <pan.2003.07.10.18.19.19.500436 (AT) gmx (DOT) net>,
on 11 Jul 2003 08:49:35 -0400,
"Dhruv" <dhruvbird (AT) gmx (DOT) net> wrote:

On Tue, 08 Jul 2003 02:32:22 +0000, Dhruv wrote:

Just another quick question: Are allocators allowed to be templated around
more that one template parameter?

In the case of std::allocator, the answer is clearly no (due to the
template template parameter issue).
For other allocators, however, I see no reason why not - although making
rebind do the right thing might be interesting.

Thanks.

Quote:

Also, with such a design, template template parameters would not work, or
would they?

It rather depends on what you mean...

I have replied to Richard Smith saying what I mean. Please have a look at
it and tell me.

Regards,
-Dhruv.

On Sat, 12 Jul 2003 09:23:19 -0400, Andy Sawyer wrote:

Quote:

Thanks.

Quote:

Also, with such a design, template template parameters would not work, or
would they?

It rather depends on what you mean...

I have replied to Richard Smith saying what I mean. Please have a look at
it and tell me.

Regards,
-Dhruv.

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

Markus Mauhart
Guest

Posted: Thu Jul 17, 2003 5:19 am Post subject: Re: allocators...exceptions...new/delete

"Richard Smith" <richard (AT) ex-parrot (DOT) com> wrote ...

Quote:

Personally, I don't think that the copy or conversion (template)
constructors for an Allocator should throw. This is not a requirement
made
by the Standard, merely a rule-of-thumb I've found through experience.
The
reason is that many operations within STL containers, etc. copy and
sometimes convert allocators very frequently, and so this should be
very
efficient.

For the problem of "convert allocators very frequently" I've recently
used an IMHO interesting technique.
The situation is that I create a one-size POOL, size known at compile
time. I want to use this POOL for std::set. I think it is large enough
for set-nodes, and I can verify this at compiletime, but OTOH inside
std::set there are a couple of conversions to alloc<bigger_type>, but
which IMHO is then not used for allocation ... I want to verify this
assumption at compiletime too.
My solution:

DATA ...;
struct tree_node {void* p[4] ;DATA data ;};
POOL pool (sizeof(tree_node));
typedef allocator_fixed <POOL ,e_no_check ,sizeof(tree_node) ,DATA>
ALLOC;
set <DATA ,less my_set;

The e_no_check-argument means "dont perform runtime checks" ... cause
I assume "node-allocation-behaviour" <=> allocate's argument is '1'.
But cause of the size_t template paramter in allocator_fixed, it knows
at compiletime that for T with 'sizeof(T) > t_size' it cannot allocate:

template <class T_POOL ,E_NO_CHECK t_no_check ,size_t t_size ,class
T>
T* allocator_fixed::allocate (size_type x) const throw(bad_alloc)
{
precond_class <sizeof(T) >= 4 || !t_no_check> ::qwe;
//I assume that 'sizeof(T) < 4' is a strong hint to expect 'x !=
1'.
// => x MUST then be checked at runtime.
precond_class <sizeof(T) <= t_size> ::qwe;
ASSERT (chunk_size(*m) >= t_size);
void* res = 0 ;
if (t_no_check || t_size >= x * sizeof(T))
x , res = chunk_alloc (*m) ;
if (res) return (T*) res ;
throw bad_alloc() ;
}

Btw, my main reason to absolutely avoid runtime checks or using 'x' at
runtime here was to make this "set <alloc_fixed " (allmost)
binary indistinguishable from "set
<alloc_full_blown_heap_based_on_POOL>".
So with VC's linker, all set-functions only relying on [de]allocate()
are 'overlayed' with the same functions having different sizeof(T)
or one of the two mentioned allocator's.

Regards,
Markus.

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

James Kuyper
Guest

Posted: Thu Jul 17, 2003 5:19 am Post subject: Re: allocators...exceptions...new/delete

"Richard Smith" <richard (AT) ex-parrot (DOT) com> wrote

...

Quote:

Absolutely. There are requirements on the template parameters of the
allocator. There isn't even a requirement that it be templated, though it's
hard to think how else it could be implemented.

Here's a basic scheme for having a non-templated allocator class:

IntAllocator is a non-template class with a value_type of 'int'.
GenAllocator<class T> is a templated class.
IntAllocator::rebind<U>::other has exactly the same implementation as
GenAllocator<T>::rebind<U>::other. For U==int, they are typedefs for
IntAllocator; otherwise, they are typedefs for GenAllocator<U>.
IntAllocator therefore qualifies as an allocator, and GenAllocator<T>
qualifies as a allocator class for all values of 'T' other than 'int'.

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

Francis Glassborow
Guest

Posted: Thu Jul 17, 2003 5:19 am Post subject: Re: allocators...exceptions...new/delete

In message <8b42afac.0307110927.4628a542 (AT) posting (DOT) google.com>, James
Kuyper <kuyper (AT) wizard (DOT) net> writes

Quote:

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.

And even more now that the C++ Standard incorporates TC1.

--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow ACCU

[ 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 ]
------------ And now a word from our sponsor ---------------------
For a secure high performance FTP using SSL/TLS encryption
upgrade to SurgeFTP
---- See http://netwinsite.com/sponsor/sponsor_surgeftp.htm ----

Dhruv
Guest

Posted: Thu Jul 17, 2003 2:30 pm Post subject: Re: allocators...exceptions...new/delete

On Sat, 12 Jul 2003 09:23:19 -0400, Andy Sawyer wrote:

Quote:

Thanks.

Quote:

Also, with such a design, template template parameters would not work, or
would they?

It rather depends on what you mean...

Display posts from previous:

	C++Talk.NET Forum Index -> C++ Language (Moderated)	All times are GMT Goto page 1, 2, 3, 4, 5, 6, 7, 8 Next
Page 1 of 8

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum