删除从STL库获取的对象 [英] Deleting objects obtained from a STL library

问题描述

嘿伙计们。一个新的问题：


我想使用STL库来保存我创建的一堆对象。

实际上，它会保存对象的引用，但是大部分时间都在

点之外。这是一个问题：我希望能够更改

引用（包括删除它们）。有没有办法做到这一点

除了使用指针而不是STL库的引用？我还要

更愿意避免使用const_cast，如果确实可以避免的话。


非常感谢。

解决方案

阿吉拉尔，詹姆斯在新闻中写道：ce ********** @ newsreader.wustl.edu在

comp.lang.c ++中：

嘿伙计们。一个新的问题：

我想使用STL库来保存我创建的一堆对象。
实际上，它会保存对象的引用，但是它旁边是库的引用之外，还有什么方法可以做到这一点吗？我也更愿意避免使用const_cast，如果它确实是可以避免的。

http://www.boost.org/libs/smart_ptr/shared_ptr.htm


并且*不要*使用const_cast，如果你觉得有诱惑回去并且

重新设计，直到* itch *消失。


Rob。

-
http：// www .victim-prime.dsl.pipex.com /

" Aguilar，James" < JF ** @ cec.NOBOTSwustl.edu>在留言中写道

news：ce ********** @ newsreader.wustl.edu ...

嘿伙计们。一个新问题：

我想使用一个STL库来保存我创建的一堆对象。
实际上，它会保存对象的引用，但是它位于<大多数情况下，点。这是一个问题：我希望能够
更改引用（包括删除它们）。有没有办法做到这一点
除了使用指针而不是STL库的引用？我会
也更愿意避免使用const_cast，如果确实可以避免的话。

非常感谢。

我想我可能误解了自己的问题。首先，请澄清

给我的东西：


容器中的对象是否与我以前的对象相同

填充容器？它们是引用那些对象，还是它们是b $ b b这些对象的副本？容器是如何制作副本的？

它们只是原始对象的浅层副本（即所有指针都是相同的，所有其他成员都被完全复制了） ）？


其次，假设我有一个功能。有一种名为Object的类型，我在这里使用
：


Object& fun1（）

{

对象a;

返回a;

}

不合法但


对象fun1（）

{

对象a;

返回a;

}


是。我想我理解为什么。但是，让我问你这个问题：如果对象，这段代码将是无效的吗？是10千字节大小？在第二个例子中实际发生的是'b
是整个对象被复制并返回？
？最后，如果是这样的话，可以通过仅仅传递整数并将所有中型或大型对象分配到

免费商店来避免这种开销吗？


最后，有什么我可以做的参考，我不能用

指针？是否有任何特别不优雅的指针

引用完成得好？例如，我有一个班级，我们要去b $ b有一个向量（它本身就是向量的向量）成员。

但是，有两种方法可以做它。一个是告诉班级所有它是一个指向一个向量的指针，一个是使该向量实际上是该类的一个

成员。我发现使用指向矢量的指针，访问

矢量看起来确实很难看：


（*（* grid）[10]）[25 ] - GT; FOO（）; / *有没有办法让这个看起来更好？
更好？它与第二个

示例相同* /


与


grid [10]相同] [25] .foo（）;


只有第二个使用实际对象或对它们的引用，第一个

使用指针。但是，我在Java（我开始自学C ++之前开始研究的语言）中的经验告诉我，传递

指针比传递对象更有效周围（事件

，需要在

计划的不同部分之间传达大型对象）。我也习惯于从不触及实际的

对象，但始终使用指针。我有这种自然的，内置的对于复制对象的厌恶，除非你在概念上使用它们的副本实际上是

。例如，如果我的怀疑是正确的，并且

第一个例子，其中我传递了一个对象。命名为a是正确的并且

方法是复制a来返回它，我宁愿使用免费商店。

没有理由为什么对象应该有在这样的

例子中构建两次。


我想我的问题是，我应该在哪一方面犯错：使用免费商店

很多并且使用指针很多，或者使用很多引用并且当我从方法中返回大对象时可能需要支付
开销？

< blockquote>阿吉拉尔，詹姆斯 < JF ** @ cec.NOBOTSwustl.edu>在消息中写道

news：ce ********** @ newsreader.wustl.edu ...

Aguilar，James ; < JF ** @ cec.NOBOTSwustl.edu>在消息中写道
新闻：ce ********** @ newsreader.wustl.edu ...

嘿伙计们。一个新问题：

我想使用一个STL库来保存我创建的一堆对象。
实际上，它会保存对象的引用，但是它位于<大多数情况下，点。这是一个问题：我希望能够更改

引用（包括删除它们）。有没有办法做到这一点
除了使用指针而不是STL库的引用？我

更喜欢避免使用const_cast，如果确实可以避免的话。

非常感谢。

我想我可能误解了自己的问题。首先，请为我澄清一下




容器中的对象是否与我使用的对象相同

来填充容器？它们是引用这些对象，还是它们是这些对象的副本？容器如何知道如何制作
副本？它们只是原始对象的浅层副本（即所有指针
是相同的，所有其他成员都被完全复制）？


存储在STL容器中的对象是副本。例如：


MyClass c;

std :: vector< MyClass> v;

v.push_back（c）;


向量现在包含一个从c

复制的MyClass实例（使用复制构造函数）。如果复制构造函数被定义为

" shallow"复制，然后制作的副本是浅的。

其次，假设我有一个功能。有一种名为Object的类型，我在这里使用
：

对象& fun1（）
{
对象a;
返回;
}

不合法但

对象fun1（ ）
{
对象a;
返回;
}
是。我想我理解为什么。但是，让我问你一句：如果对象，这段代码是否效率低下。是10千字节大小？在第二个例子中实际发生的是整个对象是被复制并返回的
？最后，如果是这样的话，通过仅传递整数并将所有中型或大型对象分配给
免费商店，可以避免
的开销吗？


如果没有测量，很难回答有关效率的问题。

是一些合理的指导方针，但通常最好运行一些测试来确定操作的成本。但是，我会说，一个

很少使用动态分配来分配一些东西，因为它更有效率b / b
。我可以看到可能还有其他问题，

就像堆栈空间一样。


此外，您的编译器可能会使用NRVO（命名为return）价值

优化）以避免在某些情况下复制对象，因此如果有副本，很难说

。

最后，有什么我可以做的参考，我不能用
指针吗？有没有什么特别不优雅的指针
引用完成得好？例如，我有一个类，我们之前会有一个向量（它本身就是向量的向量）成员。
但是，有两种方法可以做到这一点。一个是告诉班级它所有的
是一个指向一个向量的指针，一个是让向量实际上是该类的成员。我发现使用指向矢量的指针，访问
，矢量看起来确实很难看：


指针很有用，因为它们的值可能会改变。一个指针，超过

时间，可能指向不同的位置，或者什么都没有（通常用空指针表示

）。但是，参考文献缺乏这种能力，并且当不需要这样的功能时，
使它们变得更简单。另外，

引用不能为空。简单性是为什么引用

而不是指针通常用于将对象传递给函数而没有

创建副本的主要原因。
（*（*网格）[10]）[25] - > FOO（）; / *有没有办法让这个
看起来更好？它与第二个例子相同* /

与

grid [10] [25] .foo（）;

只有第二个使用实际对象或对它们的引用，而
首先使用指针。然而，我在Java（我开始自学C ++之前开始研究的语言）方面的经验告诉我，传递指针比传递对象更有效（在
中）大型对象需要在
程序的不同部分之间进行通信的事件。我也习惯于从不触及实际的对象，但总是使用指针。我有这种自然的，内置的对复制对象的厌恶，除非你实际上在概念上要使用它们的副本
。例如，如果我的怀疑是正确的，并且我将第一个例子传递给了对象。命名为a是正确的，并且
方法是复制a来返回它，我宁愿使用免费商店。
没有理由为什么对象必须在
这样的例子。

我想我的问题是，我应该在哪一方面犯错：使用免费商店很多并且使用指针很多，或者使用很多参考资料并且可能付钱从方法中返回大对象时的开销是什么？

要记住的一件事是当一个对象被动态分配时，

它通常是内存分配本身，是最严重的部分

的磨难。但是，如果对象是一个复杂的大型复杂对象，那么复制它可能是有意义的。这笔费用

通常不以字节数来衡量，而是根据时间和

来执行复制构造函数所需的额外内存（通常是

不难从一个位置复制合理数量的字节到另一个位置。

没有一个，真正的答案。一般来说，C ++程序员避免使用

动态分配，除非它被调用，所以不要动态分配

default在程序中分配对象的方法。如果你这么做，那么C ++程序员就能闻到一英里之外的Java。 ;-)


对于复制成本昂贵的对象，有时可能会实现交换。避免复制它们的方法。例如：


void foo（std :: vector< int>& out）{

std :: vector< int> v（20）;

//填写v

v.swap（out）;

}


std :: vector :: swap方法没有执行昂贵的复制操作，而是用b $ b快速地将向量'的内容与传递的向量交换

（想想内部指针等值交换）。


如果你发现自己传递指向周围物体的指针，可以考虑使用

智能指针，比如提升:: shared_ptr，因为它可以帮助保护你的

代码免受内存泄漏的影响。


-

David Hilsee

Hey guys. A new question:

I want to use an STL libarary to hold a bunch of objects I create.
Actually, it will hold references to the objects, but that''s beside the
point, for the most part. Here''s the question: I want to be able to change
the references (including deleting them). Is there any way to do that
besides using pointers rather than references for the STL library? I''d also
prefer to avoid using const_cast, if it is indeed avoidable.

Thanks much.

解决方案

Aguilar, James wrote in news:ce**********@newsreader.wustl.edu in
comp.lang.c++:

Hey guys. A new question:

I want to use an STL libarary to hold a bunch of objects I create.
Actually, it will hold references to the objects, but that''s beside
the point, for the most part. Here''s the question: I want to be able
to change the references (including deleting them). Is there any way
to do that besides using pointers rather than references for the STL
library? I''d also prefer to avoid using const_cast, if it is indeed
avoidable.

http://www.boost.org/libs/smart_ptr/shared_ptr.htm

And *don''t* use const_cast, if you feel tempted go back and
redesign until the *itch* goes away.

Rob.
--
http://www.victim-prime.dsl.pipex.com/

"Aguilar, James" <jf**@cec.NOBOTSwustl.edu> wrote in message
news:ce**********@newsreader.wustl.edu...

Hey guys. A new question:

I want to use an STL libarary to hold a bunch of objects I create.
Actually, it will hold references to the objects, but that''s beside the
point, for the most part. Here''s the question: I want to be able to change the references (including deleting them). Is there any way to do that
besides using pointers rather than references for the STL library? I''d also prefer to avoid using const_cast, if it is indeed avoidable.

Thanks much.

I think I might have misunderstood my own question. First, please clarify
something for me:

Are the objects in the container the same objects as the ones that I used to
fill the container? Are they references to those objects, or are they
copies of those objects? How did the container know how to make the copies?
Are they just shallow copies of the original objects (i.e. all pointers are
the same, all other members were copied completely)?

Secondly, suppose I have a function. There is a type called Object which I
use here:

Object& fun1()
{
Object a;
return a;
}

is not legal but

Object fun1()
{
Object a;
return a;
}

is. I think I understand why. However, let me ask you this: is this code
going to be inefficient if "Object" is ten kilobytes in size? Is what''s
actually happening in the second example is that the entire object is being
copied and returned? Lastly, if this is so, can this overhead be avoided by
only passing ints and assigning all medium or large sized objects to the
free store?

Lastly, is there anything I can do with references that I can''t do with
pointers? Is there anything that is especially inelegant with pointers that
references accomplish well? For instance, I had a class that we going to
have a vector (that was itself a vector of vectors) member earlier.
However, there are two ways to do it. One is to tell the class that all it
has is a pointer to a vector, and one is to make the vector actually a
member of the class. I found that with a pointer to a vector, accessing the
vector would look ugly indeed:

(*(*grid)[10])[25]->foo(); /*Isn''t there any way to at least make this look
better? It does the same thing as the second
example */

is the same as

grid[10][25].foo();

only the second uses the actual objects or references to them, and the first
uses pointers. However, my experience in Java (which is the language I
began working on before I began teaching myself C++) tells me that passing
pointers around is more efficient than passing objects around (in the event
that large objects need to be communicated between different parts of the
program). I''m also used to the convenience of never touching an actual
object, but always working with pointers. I have this natural, builtin
aversion to copying objects unless you are actually conceptually going to be
using a copy of them. For instance, if my suspicions are correct and the
first example in which I pass out an "Object" named a is correct and the
method is copying a to return it, I would rather use the free store.
There''s no reason why the object should have to be constructed twice in an
example like that.

I guess my question is, on which side should I err: using the free store a
lot and using pointers a lot, or using references a lot and perhaps paying
overhead when I return large objects from methods?

"Aguilar, James" <jf**@cec.NOBOTSwustl.edu> wrote in message
news:ce**********@newsreader.wustl.edu...

"Aguilar, James" <jf**@cec.NOBOTSwustl.edu> wrote in message
news:ce**********@newsreader.wustl.edu...

Hey guys. A new question:

I want to use an STL libarary to hold a bunch of objects I create.
Actually, it will hold references to the objects, but that''s beside the
point, for the most part. Here''s the question: I want to be able to change

the references (including deleting them). Is there any way to do that
besides using pointers rather than references for the STL library? I''d

also

prefer to avoid using const_cast, if it is indeed avoidable.

Thanks much.

I think I might have misunderstood my own question. First, please clarify
something for me:

Are the objects in the container the same objects as the ones that I used

to fill the container? Are they references to those objects, or are they
copies of those objects? How did the container know how to make the copies? Are they just shallow copies of the original objects (i.e. all pointers are the same, all other members were copied completely)?
The objects stored inside an STL container are copies. For example:

MyClass c;
std::vector<MyClass> v;
v.push_back(c);

The vector now contains one instance of MyClass that was copied from c
(using the copy constructor). If the copy constructor is defined as a
"shallow" copy, then the copy made is "shallow".
Secondly, suppose I have a function. There is a type called Object which I use here:

Object& fun1()
{
Object a;
return a;
}

is not legal but

Object fun1()
{
Object a;
return a;
}

is. I think I understand why. However, let me ask you this: is this code
going to be inefficient if "Object" is ten kilobytes in size? Is what''s
actually happening in the second example is that the entire object is being copied and returned? Lastly, if this is so, can this overhead be avoided by only passing ints and assigning all medium or large sized objects to the
free store?
Questions about efficiency are hard to answer without measurements. There
are a few reasonable guidelines, but it''s usually best to run some tests to
determine how expensive an operation is. However, I will say that one
rarely allocates something using dynamic allocation because it is more
efficient that way. I could see how there might be other concerns, though,
like stack space.

Also, it is possible that your compiler would use NRVO (named return value
optimization) to avoid copying objects in certain cases, so it''s hard to say
if there is a copy made or not.
Lastly, is there anything I can do with references that I can''t do with
pointers? Is there anything that is especially inelegant with pointers that references accomplish well? For instance, I had a class that we going to
have a vector (that was itself a vector of vectors) member earlier.
However, there are two ways to do it. One is to tell the class that all it has is a pointer to a vector, and one is to make the vector actually a
member of the class. I found that with a pointer to a vector, accessing the vector would look ugly indeed:
Pointers are useful because their values may change. A single pointer, over
time, may point to different locations, or nothing at all (usually signified
with a null pointer). References, however, lack this ability, and that
makes them simpler when such functionality is not required. Also,
references cannot be null. The simplicity is the main reason why references
and not pointers are usually used to pass an object to a function without
creating a copy.
(*(*grid)[10])[25]->foo(); /*Isn''t there any way to at least make this look better? It does the same thing as the second
example */

is the same as

grid[10][25].foo();

only the second uses the actual objects or references to them, and the first uses pointers. However, my experience in Java (which is the language I
began working on before I began teaching myself C++) tells me that passing
pointers around is more efficient than passing objects around (in the event that large objects need to be communicated between different parts of the
program). I''m also used to the convenience of never touching an actual
object, but always working with pointers. I have this natural, builtin
aversion to copying objects unless you are actually conceptually going to be using a copy of them. For instance, if my suspicions are correct and the
first example in which I pass out an "Object" named a is correct and the
method is copying a to return it, I would rather use the free store.
There''s no reason why the object should have to be constructed twice in an
example like that.

I guess my question is, on which side should I err: using the free store a
lot and using pointers a lot, or using references a lot and perhaps paying
overhead when I return large objects from methods?

One thing to keep in mind is that when an object is dynamically allocated,
it is typically the memory allocation itself that is the most expensive part
of the ordeal. However, if the object is a big, complex object that is
expensive to copy, then it may make sense to avoid copying it. That expense
is not usually measured in terms of bytes, but in terms of the time and
possibly extra memory it takes to execute the copy constructor (It''s usually
not hard to copy a reasonable number of bytes from one location to another).
There is no one, true answer. In general, C++ programmers avoid using
dynamic allocation unless it is called for, so don''t make dynamic allocation
the "default" method for allocation objects in your programs. If you do
that, C++ programmers will be able to smell the Java a mile away. ;-)

For objects that are expensive to copy, it is sometimes possible to
implement a "swap" method to avoid copying them. For example:

void foo(std::vector<int>& out) {
std::vector<int> v(20);
// fill in v
v.swap( out );
}

The std::vector::swap method doesn''t perform an expensive copy operation and
instead quickly exchanges the vector''s contents with the vector passed
(think internal pointer, etc value swapping).

If you do find yourself passing pointers to objects around, consider using
smart pointers, like boost::shared_ptr, because it can help protect your
code from memory leaks.

--
David Hilsee

这篇关于删除从STL库获取的对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！