Return-Path: 
 <stdcxx-dev-return-1349-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org
Received: (qmail 81755 invoked from network); 18 May 2006 22:03:47 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 18 May 2006 22:03:47 -0000
Received: (qmail 55272 invoked by uid 500); 18 May 2006 22:03:47 -0000
Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org
Received: (qmail 55221 invoked by uid 500); 18 May 2006 22:03:47 -0000
Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:stdcxx-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:stdcxx-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:stdcxx-dev@incubator.apache.org>
List-Id: <stdcxx-dev.incubator.apache.org>
Reply-To: stdcxx-dev@incubator.apache.org
Delivered-To: mailing list stdcxx-dev@incubator.apache.org
Received: (qmail 55210 invoked by uid 99); 18 May 2006 22:03:47 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 May 2006 15:03:47 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 May 2006 15:03:46 -0700
Received: from bco-exchange.bco.roguewave.com (bco-exchange.bco.roguewave.com
 [172.19.31.48])
	by moroha.quovadx.com (8.13.4/8.13.4) with ESMTP id k4IM2iP6000983
	for <stdcxx-dev@incubator.apache.org>; Thu, 18 May 2006 22:02:44 GMT
Received: from [10.70.3.113] (10.70.3.113 [10.70.3.113]) by
 bco-exchange.bco.roguewave.com with SMTP (Microsoft Exchange Internet Mail
 Service Version 5.5.2657.72)
	id 2YG61HJC; Thu, 18 May 2006 15:59:15 -0600
Message-ID: <446CEF4D.8060305@roguewave.com>
Date: Thu, 18 May 2006 16:03:57 -0600
From: Martin Sebor <sebor@roguewave.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: test for lib.string.swap
References: <4D6A8407B7AC6F4D95B0E55C4E7C4C62043B0182@exmsk.moscow.vdiweb.com>
In-Reply-To: 
 <4D6A8407B7AC6F4D95B0E55C4E7C4C62043B0182@exmsk.moscow.vdiweb.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Anton Pevtsov wrote:
[...]
> Here is another question. We use template class Allocator in the tests,
> and it assumes that code should be valid for std:allocator too.
> But 
> 
> SharedAlloc a;
> Allocator<int> z (&a);
> 
> wll not compile when Allocator is std::allocator. Is there any way to
> use std::allocator and UserAlloc together (at the same time UserAlloc
> objects should be not equal)?

Yeah, that wouldn't work. There are at least two approaches
that I think should work for us.

The first is to unconditionally construct a SharedAlloc object
and set SharedAlloc::instance() to point to it. That way the
default UserAlloc ctor will pick it up.

     template <..., class Allocator>
     void foo () {
         SharedAlloc a;
         // set a as the new global instance
         SharedAlloc* const save = SharedAlloc::instance (&a);
         Allocator z;   // uses a
         // ...
         // restore the original instance
         SharedAlloc::instance (save);
     }

The second is to write a simple allocator adapter template
that would pass the SharedAlloc object to the UserAlloc ctor
but avoid passing it to Allocator:

     template <class charT>
     std::allocator<charT>
     make_alloc (SharedAlloc&, std::allocator<charT>*) {
         return std::allocator<charT>();
     }

     template <class charT, class Types>
     UserAlloc<charT, Types>
     make_alloc (SharedAlloc &shal, UserAlloc<charT, Types>*) {
         return UserAlloc<charT, Types>(&shal);
     }

I suspect the second alternative is what we'll need to verify
that the string ctor creates and stores a copy of the allocator
object passed to it rather than storing some other default
constructed allocator (since the two would be indistinguishable).

Martin