[allocator.concept]智能指针澄清 [英] [allocator.concept] smart pointer clarifications

查看:89
本文介绍了[allocator.concept]智能指针澄清的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前正在写一个非常稳定的智能指针我决定支持分配器完成,因为当容器使用相同的池时它增加了
的效率是共享的。我被告知

新标准正在最终确定,我希望在其他任何事情之前可以应用次要但重要的

更改。


要快速概述本主题的当前状态,您将在与分配器成员函数(n2641)相关的最新文本下面找到

。我们

看到那里没有在

allocate()返回的指针类型与deallocate()和destroy()所期望的指针类型之间的区别。

这是一个很大的问题,因为如果要使用智能

指针,这个逻辑就没有意义了。智能指针是其对象的所有者,并且
绝不会放弃对其对象的外部访问。我们需要

这些函数使用

1)不同的指针类型来自allocate返回的那个()

2)make参数(指针) )作为非const引用传递


后者是必须更改智能指针本身

或指向原始指针的对象使用。我们可以在这里看到我的

人员实现,我想提出以下

函数签名:


template< typename T>

class shifted_allocator

{

public:

typedef shift< T value_type;

typedef shifted_ptr< T指针;

typedef shifted_ptr< const T const_pointer;


value_type * allocate(size_type s,const void * = 0);

void deallocate(指针& p,size_type);

void construct(value_type * p,const T& x);

void destroy(pointer& p);

...

};


**分配器成员函数**

1)

指针X :: allocate(size_type n);

指针X :: allocate(size_type n,const_generic_pointer提示);


效果:为value_type类型的n个对象分配内存,但不构造

对象。 [脚注:a.allocate是一种分配单个T类型对象的有效方法,即使sizeof(T)

很小。也就是说,没有必要让容器维持自己的

免费列表。 - 结束脚注]可选参数p可以


返回:指向已分配内存的指针。 [注意:如果n == 0,则返回

值未指定。如果n 1,则在

分配器概念之外确定程序获得对第二个及后续分配对象的访问权的方式。请参阅下面的RandomAccessAllocator,了解一种常见的
方法。 - 结束注释]


抛出:分配可能会引发一个适当的异常。


备注:提示的使用未指定,但打算用作援助当地

如果实施如此需要。 [注意:在容器成员函数中,相邻元素的

地址通常是传递提示

参数的好选择。 - 结束说明]


2)

void X :: deallocate(指针p,size_type n);


前提条件:在此调用之前,p指向的区域中的所有n个value_type对象都应该被销毁。 n应匹配传递给分配的值

获取此内存。 [注意:p不应该是单数。 - 结束说明]


抛出:不抛出异常。


3)

void X :: destroy (指针p);


效果:在p处调用对象上的析构函数但不释放它。


问候,

-Phil


-

[见 http://www.gotw.ca/resources/clcm.htm 有关的信息]

[comp.lang.c ++ .moderated。第一次海报:做到这一点! ]

I am currently writting a smart pointer which is reasonnably stable and I
decided supporting allocators for completion because of its increase in
efficiency when the same pool used by containers is shared. I was told the
new standards are being finalized and I am hoping minor but important
changes could be applied before anything else.

To give a quick overview on the current status of this topic, you will find
below the latest text relating to allocator member functions (n2641). We
see over there there are no dictinction between the pointer type returned by
allocate() and the pointer type expected by deallocate() and destroy().
This is a big problem because this logic doesn''t make sense anymore if smart
pointers are to be used. Smart pointers are owners of their objects and
aren''t in no way going to give away external access to its object. We need
these functions to use
1) distinct pointer type from the one returned by allocate()
2) make the parameter (pointer) passed as a non-const reference

The latter is necessary to make changes to either the smart pointer itself
or the object pointed to in case raw pointer are used. We can see my
personnal implementation here and I would like to propose the following
function signatures:

template <typename T>
class shifted_allocator
{
public:
typedef shifted<T value_type;
typedef shifted_ptr<T pointer;
typedef shifted_ptr<const T const_pointer;

value_type * allocate(size_type s, const void * = 0);
void deallocate(pointer & p, size_type);
void construct(value_type * p, const T & x);
void destroy(pointer & p);
...
};

** Allocator member functions **
1)
pointer X::allocate(size_type n);
pointer X::allocate(size_type n, const_generic_pointer hint);

Effects: Memory is allocated for n objects of type value_type but the
objects are not constructed. [Footnote: It is intended that a.allocate be an
efficient means of allocating a single object of type T, even when sizeof(T)
is small. That is, there is no need for a container to maintain its own
"free list". - end footnote] The optional argument, p, may

Returns: A pointer to the allocated memory. [Note: If n == 0, the return
value is unspecified. If n 1, the means by which a program gains access to
the second and subsequent allocated objects is determined outside of the
Allocator concept. See RandomAccessAllocator, below, for one common
approach. - end note]

Throws: allocate may raise an appropriate exception.

Remark: The use of hint is unspecified, but intended as an aid to locality
if an implementation so desires. [ Note: In a container member function, the
address of an adjacent element is often a good choice to pass for the hint
argument. - end note ]

2)
void X::deallocate(pointer p, size_type n);

Preconditions: All n value_type objects in the area pointed to by p shall be
destroyed prior to this call. n shall match the value passed to allocate to
obtain this memory. [Note: p shall not be singular. - end note]

Throws: Does not throw exceptions.

3)
void X::destroy(pointer p);

Effects: Calls the destructor on the object at p but does not deallocate it.

Regards,
-Phil

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

推荐答案

8月18日,7:28 * pm,Phil Bouchard < p ... @ fornux.comwrote:
On Aug 18, 7:28*pm, "Phil Bouchard" <p...@fornux.comwrote:

我正在写一个非常稳定的智能指针我决定支持
分配器完成,因为当共享容器使用的相同池时,它的效率增加了
。 *我被告知

新标准正在最终确定,我希望在其他任何事情之前可以应用次要但重要的

更改。


要快速概述本主题的当前状态,您将在与分配器成员函数(n2641)相关的最新文本下面找到

。 *我们

看到那里返回的指针类型与
allocate()和deallocate()和destroy()所期望的指针类型之间没有区别。

这是一个很大的问题,因为如果要使用智能

指针,这个逻辑就没有意义了。 *智能指针是其对象的所有者,并且

绝不会放弃对其对象的外部访问。 *我们需要这些函数使用



1)与allocate()返回的指针类型不同的指针类型

2)制作参数(指针)作为非const引用传递


后者是必要的,以更改智能指针本身

或原始情况下指向的对象指针被使用。 *我们可以在这里看到我的

人员实现,我想提出以下

功能签名:


模板< typename T>

* * class shifted_allocator

* * {

* * public:

* * * * typedef shift< T * * * * * * * value_type;

* * * * typedef shifted_ptr< T * * * * *指针;

* * * * typedef shifted_ptr< ; const T * * const_pointer;


* * * * value_type * allocate(size_type s,const void * = 0);

* * * * void deallocate(pointer& p,size_type);

* * * * void construct(value_type * p,const T& x);

* * * * void destroy (指针& p);

* * * * ...

* *};
I am currently writting a smart pointer which is reasonnably stable and I
decided supporting allocators for completion because of its increase in
efficiency when the same pool used by containers is shared. *I was toldthe
new standards are being finalized and I am hoping minor but important
changes could be applied before anything else.

To give a quick overview on the current status of this topic, you will find
below the latest text relating to allocator member functions (n2641). *We
see over there there are no dictinction between the pointer type returnedby
allocate() and the pointer type expected by deallocate() and destroy().
This is a big problem because this logic doesn''t make sense anymore if smart
pointers are to be used. *Smart pointers are owners of their objects and
aren''t in no way going to give away external access to its object. *We need
these functions to use
1) distinct pointer type from the one returned by allocate()
2) make the parameter (pointer) passed as a non-const reference

The latter is necessary to make changes to either the smart pointer itself
or the object pointed to in case raw pointer are used. *We can see my
personnal implementation here and I would like to propose the following
function signatures:

template <typename T>
* * class shifted_allocator
* * {
* * public:
* * * * typedef shifted<T* * * * * * *value_type;
* * * * typedef shifted_ptr<T* * * * *pointer;
* * * * typedef shifted_ptr<const T* *const_pointer;

* * * * value_type * allocate(size_type s, const void * = 0);
* * * * void deallocate(pointer & p, size_type);
* * * * void construct(value_type * p, const T & x);
* * * * void destroy(pointer & p);
* * * * ...
* * };



[snip]


也许我错过了什么。智能指针通常在分配后接管

所有权,例如:


tr1 :: shared_ptr< intspi1(new int(42));

tr1 :: shared_ptr< intspi2(FactoryFunction());


shared_ptr'的删除器可以告诉它如何做一些特别的发布

程序,例如:


tr1 :: shared_ptr< FILEfile(fopen(" some.txt"," r"),& fclose);

为什么分配器需要知道智能指针?


干杯! --M

[snip]

Perhaps I''m missing something. Smart pointers generally take over
ownership AFTER allocation, e.g.:

tr1::shared_ptr<intspi1( new int(42) );
tr1::shared_ptr<intspi2( FactoryFunction() );

A shared_ptr''s deleter can tell it how to do some special release
procedure, e.g.:

tr1::shared_ptr<FILEfile( fopen( "some.txt", "r" ), &fclose );

Why do allocators need to become aware of smart pointers?

Cheers! --M




" mlimber" < ml ***** @ gmail.com写信息

新闻:e8 ************************* ********* @ x35g2000 hsb.googlegroups.com ...

[...]

"mlimber" <ml*****@gmail.comwrote in message
news:e8**********************************@x35g2000 hsb.googlegroups.com...

[...]

也许我错过了什么。智能指针通常在分配后接管

所有权,例如:


tr1 :: shared_ptr< intspi1(new int(42));

tr1 :: shared_ptr< intspi2(FactoryFunction());


shared_ptr'的删除器可以告诉它如何做一些特别的发布

程序,例如:


tr1 :: shared_ptr< FILEfile(fopen(" some.txt"," r"),& fclose);

为什么分配器需要知道智能指针?


干杯! --M
Perhaps I''m missing something. Smart pointers generally take over
ownership AFTER allocation, e.g.:

tr1::shared_ptr<intspi1( new int(42) );
tr1::shared_ptr<intspi2( FactoryFunction() );

A shared_ptr''s deleter can tell it how to do some special release
procedure, e.g.:

tr1::shared_ptr<FILEfile( fopen( "some.txt", "r" ), &fclose );

Why do allocators need to become aware of smart pointers?

Cheers! --M



好​​吧,定义一个分配器的想法是集中在一个

类实例中与内存管理相关的一切。如果必须在容器和智能
指针本身之间明确共享

分配器,那么这个想法就变得毫无意义了。分配器应该是

,负责所有类型的解除分配,包括智能指针。

-Phil

Well the idea of having of defining an allocator is to centralized in one
class instanciation everything related to memory management. If the
allocator have to be explicitly shared between the container and the smart
pointer itself then the idea becomes pointless. The allocator should be
responsible for all types of deallocations, including smart pointers.
-Phil


8月20,4:26 * am,Phil Bouchard < p ... @ fornux.comwrote:
On Aug 20, 4:26*am, "Phil Bouchard" <p...@fornux.comwrote:

" mlimber" < mlim ... @ gmail.com写信息


新闻:e8 *********************** *********** @ x35g2000 hsb.googlegroups.com ...

[...]
"mlimber" <mlim...@gmail.comwrote in message

news:e8**********************************@x35g2000 hsb.googlegroups.com...

[...]

也许我错过了什么。智能指针通常在分配后接管

所有权,例如:
Perhaps I''m missing something. Smart pointers generally take over
ownership AFTER allocation, e.g.:


* tr1 :: shared_ptr< intspi1(new int( 42));

* tr1 :: shared_ptr< intspi2(FactoryFunction());
*tr1::shared_ptr<intspi1( new int(42) );
*tr1::shared_ptr<intspi2( FactoryFunction() );


shared_ptr'的删除器可以告诉它如何做一些特殊的发布

程序,例如:
A shared_ptr''s deleter can tell it how to do some special release
procedure, e.g.:


* tr1 :: shared_ptr< FILEfile(fopen(" some.txt"," r"),& fclose);
*tr1::shared_ptr<FILEfile( fopen( "some.txt", "r" ), &fclose );


为什么分配器需要知道智能指针?
Why do allocators need to become aware of smart pointers?



好​​吧,定义一个分配器的想法是集中在一个

类实例中与内存管理相关的一切。 *如果必须在容器和智能
指针之间明确共享

分配器,那么这个想法就变得毫无意义了。 *分配器应该是

,负责所有类型的解除分配,包括智能指针。


Well the idea of having of defining an allocator is to centralized in one
class instanciation everything related to memory management. *If the
allocator have to be explicitly shared between the container and the smart
pointer itself then the idea becomes pointless. *The allocator should be
responsible for all types of deallocations, including smart pointers.



我仍​​然没有得到它。假设您正在设计std :: vector,其中
有一个allocator模板参数。用户 -

定义的类或智能指针(只要它具有值语义)无关紧要。

鉴于此代码:


class C {* / ... * /};

// ...

std :: vector< Cv1(10) ;

std :: vector< std :: tr1 :: shared_ptr< C v2(10);


在引擎盖下,后两行中的每一行都将使用向量'

(默认)分配器为

包含类型的10个实例获取内存,然后使用placement-new来构造

内存中的实例。 (注意,在这个

点,所有shared_ptr'的指针都是空的。)为什么分配器关心它是在制作C还是

shared_ptr< C>?


干杯! --M

I still don''t get it. Let''s say you''re designing std::vector, which
has an allocator template parameter. It doesn''t matter if the user-
defined class or a smart pointer (as long as it has value semantics).
Given this code:

class C { */...*/ };
// ...
std::vector<Cv1( 10 );
std::vector< std::tr1::shared_ptr<C v2( 10 );

Under the hood, each of the latter two lines will use vector''s
(default) allocator to grab memory for the 10 instances of the
contained type and then placement-new to construct the instances in
that memory. (Note that all the shared_ptr''s pointees are null at this
point.) Why does the allocator care if it''s making a C or a
shared_ptr<C>?

Cheers! --M


这篇关于[allocator.concept]智能指针澄清的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆