From -1339617697074827523
X-Google-Thread: f78e5,99f1efda99846e15
X-Google-Attributes: gidf78e5,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: g2news1.google.com!news2.google.com!proxad.net!proxad.net!194.159.246.34.MISMATCH!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull
From: tom_usenet@hotmail.com (tom_usenet)
Newsgroups: comp.std.c++
Subject: Re: Custom allocator for vector
Date: Wed, 18 Aug 2004 05:34:36 GMT
Organization: [posted via Easynet UK]
Lines: 67
Sender: mail2news@demon.net
Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++)
Message-ID: <5bp3i05gbil94hkm6je61ehubm3jv2om5d@4ax.com>
References: <2ns6efF45gptU1@uni-berlin.de>
NNTP-Posting-Host: news.news.demon.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: news.demon.co.uk 1092807281 2831 158.152.254.254 (18 Aug 2004 05:34:41 GMT)
X-Complaints-To: abuse@demon.net
NNTP-Posting-Date: Wed, 18 Aug 2004 05:34:41 +0000 (UTC)
X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov)
X-Spam-Checker-Version: SpamAssassin 2.60-mulga_r1 (1.212-2003-09-23-exp) on 
	mulga.cs.mu.OZ.AU
X-Spam-Status: No, hits=-2.9 required=5.2 tests=AWL,BAYES_00,
	FORGED_HOTMAIL_RCVD2 autolearn=ham version=2.60-mulga_r1
X-Path: comp-std-cpp-robomod!not-for-mail
X-Received: (from fjh@localhost)
	by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i7I5YaHQ008759;
	Wed, 18 Aug 2004 15:34:36 +1000 (EST)
X-Spam-Level: 
X-Delivered-To: std-c++@ucar.edu
X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f
X-Newsreader: Forte Free Agent 2.0/32.652
X-Newsgroups: comp.std.c++
Xref: g2news1.google.com comp.std.c++:1781

On Tue, 10 Aug 2004 17:18:53 GMT, alexvn@big-foot.com ("Alex Vinokur")
wrote:

>Different compilers produce quite different behavior with the same custom allocator.
>
>Here is the Nicolai M. Josuttis' allocator code sample (for vector) with cosmetic changes added by me to profile the executable:
>http://groups.google.com/groups?threadm=2nrba8F3sq7sU1%40uni-berlin.de
>
>Here are run log files for the following compilers
>* GNU g++ : http://groups.google.com/groups?selm=2nrb31F3q19kU1%40uni-berlin.de
>* Microsoft C++ : http://groups.google.com/groups?selm=2nrbdaF3orecU1%40uni-berlin.de
>* Borland C++ : http://groups.google.com/groups?selm=2nrbe9F3ta94U1%40uni-berlin.de
>
>We can see that
>* GNU g++ 3.3.1 doesn't invoke construct() and destroy();
>* Microsoft C++ 13.00 and Borland C++ 5.5.1 do invoke construct() and destroy().

Unless your allocator is using a special type of pointer, I don't
think an allocator should care whether construct() and destroy() are
called or not, since the effects of those functions must be just to do
a placement new and explicit destructor call.

For example, an obvious optimization for POD types is not to call the
destroy function at all.

>We can see also that behavior of Microsoft C++ 13.00 and Borland C++ 5.5.1 is quite different;
>for instance, Borland C++ allocates memory for 256 elements, Microsoft C++ allocates memory for small number of elements.

Yes, the minimum size of the vector is likely to be different
according to the choices made by different vendors. This is a good
thing; it has taken a long time for Dinkumware to settle on their
current allocation scheme, and there's no way the standard would have
got it right back in '96 or so.

However, it might be worth revisiting the container requirements in
C++0x, since so much more is known about them than was known when the
STL was a fresh new library. For example, more explicit control on how
deque and vector allocate memory might be useful.

>So, behavior of a custom allocator is significantly compiler-dependent.
>The question is what can one achieve using a _custom_ allocator?

You can allocate memory using a different technique than just using
::operator new. With better implementations like Dinkumware's (and
probably that of GCC 3.5), you can use custom pointer types (such as
an offset into shared memory).

>The more specific question: do we need construct() and destroy() indeed? For instance, g++ doesn't use them.

We do need them for special pointer types, yes. e.g. a pointer might
be an int (for an offset), in which case new((void*)anint) T(val) is
just not going to work; the allocator will need something like:

void myallocator::construct(pointer p, const_reference value)
{
  T* ptr = base_address + p;
  new ((void*)ptr) value_type(value);
}

Tom

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