 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Ross Ridge
Guest
|
 Posted: Fri Jul 04, 2003 8:53 pm Post subject: Re: allocators...exceptions...new/delete |
 |
|
Ross Ridge wrote:
| Quote: | Defer allocation of the single node until the first call to allocate().
|
Dhruv <dhruvbird (AT) gmx (DOT) net> wrote:
| Quote: | If I do that, then for every call to allocate(), I will have to check for
the head pointer being valid, and that would be a terrible price to pay.
|
I have a hard time imagining how this could be significant compared
to the cost of doing the allocate.
| Quote: | Even if I defer the throwing of the exception in the allocate function,
then also, I'll have to do some sort of error checking every time it is
called.
|
Your allocate function is already required by the standard to throw an
exception if it can't allocate the requested memory. You have to do
this checking anyways, so this doesn't change anything.
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 //
---
[ 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 ]
|
|
| Back to top |
|
 |
Dhruv
Guest
|
| Posted: Mon Jul 07, 2003 8:07 am Post subject: Re: allocators...exceptions...new/delete |
|
|
On Fri, 04 Jul 2003 20:53:32 +0000, Ross Ridge wrote:
| Quote: | Ross Ridge wrote:
Defer allocation of the single node until the first call to allocate().
Dhruv <dhruvbird (AT) gmx (DOT) net> wrote:
If I do that, then for every call to allocate(), I will have to check for
the head pointer being valid, and that would be a terrible price to pay.
I have a hard time imagining how this could be significant compared
to the cost of doing the allocate.
|
I'll have to try it out then  I'll add the code, as you said, and time
it again.
| Quote: | Even if I defer the throwing of the exception in the allocate function,
then also, I'll have to do some sort of error checking every time it is
called.
Your allocate function is already required by the standard to throw an
exception if it can't allocate the requested memory. You have to do
this checking anyways, so this doesn't change anything.
|
I think you have got me wrong here. I think I'll post a link to the code
here: http://www.geocities.com/dhruvbird/nstl0.2.zip
The file to be looking out for is list_alloc.hpp
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 ]
|
|
| Back to top |
|
|
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 ]
|
|
| Back to top |
|
|
Ron Natalie
Guest
|
| Posted: Fri Jul 11, 2003 1:39 am Post subject: Re: allocators...exceptions...new/delete |
|
|
""Dhruv"" <dhruvbird (AT) gmx (DOT) net> wrote
| Quote: | On Tue, 24 Jun 2003 03:39:30 +0000, Andy Sawyer wrote:
So, this means that now, new int[0] can fail? So, what, will it throw
std::bad_alloc()?
|
Yes and yes.
| Quote: | Also, is the 2nd part trying to say this:?
Suppose you have something like this:
int *pint = new int[0];
delete pint;
pint = new int[0];
Meaning that pint now can (could) hold the same value that it held before
the call to delete?
Precisely. The return of new is always unique from any currently undeleted |
new return (even if when it's a zero sized array).
Since there is almost always some overhead associated with keeping track of even
a zero sized allocation to guarantee uniqueness, it's possible that failure to allocate
this overhead internally might throw bad_alloc.
A common (but perhaps not optimal way) of handling this is just to set the size to 1 if
it is zero in the 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 ]
|
|
| Back to top |
|
|
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 ]
|
|
| Back to top |
|
|
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 ]
|
|
| Back to top |
|
|
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 ]
|
|
| Back to top |
|
|
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 ]
|
|
| Back to top |
|
|
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 ]
|
|
| Back to top |
|
|
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 ]
|
|
| Back to top |
|
|
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 ]
|
|
| Back to top |
|
|
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: | 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.
[ 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 ]
|
|
| Back to top |
|
|
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 ]
|
|
| Back to top |
|
|
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 ]
|
|
| Back to top |
|
|
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 ----
|
|
| Back to top |
|
|
|
|
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
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
