d****p
发帖数: 685 | 1 #include
#include |
z***9
发帖数: 696 | 2 is boost::shared_ptr a smart pointer?
{
Foo_ptr foo(new Foo(id));
fooMap[id] = foo;
return foo;
}
the foo object deletes itself at the end of the static function, which will
cause the memory (pointed bt new Foo(id)) to be released too. however, the
function will assign a copy of the foo object to fooMap[id] and return a copy of the same object too , both of which contais that pointer (but the memory is no longer available).
edit: guess boost::shared_ptr implements the reference counting, s |
y***d
发帖数: 2330 | 3 memory leak. ~Foo will be called when ref count is zero. But ref count will
never be zero unless ~Foo is called.
【在 d****p 的大作中提到】
: #include
: #include
|
d****p
发帖数: 685 | 4 boost::shared_ptr is a smart pointer which contains a shared_count object
that manages count ref on the raw pointer. So the static function returns a
valid pointer to a valid object (the Foo(id)).
will
copy of the same object too , both of which contais that pointer (but the
memory is no longer available).
statement is not valid.
【在 z***9 的大作中提到】
: is boost::shared_ptr a smart pointer?
: {
: Foo_ptr foo(new Foo(id));
: fooMap[id] = foo;
: return foo;
: }
: the foo object deletes itself at the end of the static function, which will
: cause the memory (pointed bt new Foo(id)) to be released too. however, the
: function will assign a copy of the foo object to fooMap[id] and return a copy of the same object too , both of which contais that pointer (but the memory is no longer available).
: edit: guess boost::shared_ptr implements the reference counting, s
|
d****p
发帖数: 685 | 5 ref count -> 0 and ~Foo() being called are managed by higher level code so
there is no deadlock.
will
【在 y***d 的大作中提到】
: memory leak. ~Foo will be called when ref count is zero. But ref count will
: never be zero unless ~Foo is called.
|
z****e
发帖数: 2024 | 6 class X{
static X* p;
public:
void gen(){
p=new X;
}
~X(){
delete p;
}
};
X* X::p=0;
int main(){
X x;
x.gen();
}
你把~X()放在火上烤啊？
在dtor退出以前，对象就没有鸟。但是，岂不循环delete了？
加一个member fun：
void X::del(){
delete p;
p=0;
}
把dtor里边的delete 去掉。
看起来就是这个样：
class X{
static X* p;
public:
X(){
}
void gen(){
p= new X;
}
void del(){
delete p;
p=0;
}
~X(){
//delete p;
}
};
X* X::p=0; |
z****e
发帖数: 2024 | 7 说清楚一些，就是这道题，重复delete了那个static成员。
确切的说，不是“重复”而是recursivly.
对否？ |
z****e
发帖数: 2024 | 8 等等，
我前面的例子好像还并不是本题的关键。
本题的关键应该在于shared_ptr.
普通指针好像并不会导致问题。 |
d****p
发帖数: 685 | 9 The example you gave is actually another good interview question:
the static point will be deleted more than once if there are multiple objects whose
destructor functions will each try delete the static pointer. And by
assigning it with 0 after deleting is a good technique.
However, this is a different question from mine.
There is no such thing as "recursive deleting" involved in both scenarios.
【在 z****e 的大作中提到】
: 说清楚一些，就是这道题，重复delete了那个static成员。
: 确切的说，不是“重复”而是recursivly.
: 对否？
|
p***o
发帖数: 1252 | 10 主动析构Foo没问题，因为 至少还有一个引用（就是你正在析构的这个），
所以map::erase只析构shared_ptr，不会回到~Foo里面。
但是如果程序结束的时候map不为空而且每个里面的对象只有一个引用
（就是map里这个），那么map析构的时候 可能 会有重入问题，具体取
决于map析构时的行为，就是说如果shared_ptr析构引起Foo析构的时候
key还能在map中找到，那么就会有问题。
【在 z****e 的大作中提到】
: 等等，
: 我前面的例子好像还并不是本题的关键。
: 本题的关键应该在于shared_ptr.
: 普通指针好像并不会导致问题。
|
|
|
d****p
发帖数: 685 | 11 Your answer is basically right - it depends on map implementation.
So it may cause bus error on VS/Windows or GCC/Mac but run fine on Solaris
or GCC/Linux.
What happened is:
1. after exiting main, the static map object is gonna be destructed
2. since one node in the map is a shared pointer of Foo, the shared pointer'
s ref count is decremented (to zero), and ~Foo called.
3. inside ~Foo, the erase tries to re-decrement the shared pointer's ref
count - since it is already 0, no further action (so
【在 p***o 的大作中提到】
: 主动析构Foo没问题，因为 至少还有一个引用（就是你正在析构的这个），
: 所以map::erase只析构shared_ptr，不会回到~Foo里面。
: 但是如果程序结束的时候map不为空而且每个里面的对象只有一个引用
: （就是map里这个），那么map析构的时候 可能 会有重入问题，具体取
: 决于map析构时的行为，就是说如果shared_ptr析构引起Foo析构的时候
: key还能在map中找到，那么就会有问题。
|
z****e
发帖数: 2024 | 12 这面试题是面试谁的？
pointer'
triggered
【在 d****p 的大作中提到】
: Your answer is basically right - it depends on map implementation.
: So it may cause bus error on VS/Windows or GCC/Mac but run fine on Solaris
: or GCC/Linux.
: What happened is:
: 1. after exiting main, the static map object is gonna be destructed
: 2. since one node in the map is a shared pointer of Foo, the shared pointer'
: s ref count is decremented (to zero), and ~Foo called.
: 3. inside ~Foo, the erase tries to re-decrement the shared pointer's ref
: count - since it is already 0, no further action (so
|
d****p
发帖数: 685 | 13 Position for c++ coder with 4+ year experience.
【在 z****e 的大作中提到】
: 这面试题是面试谁的？
:
: pointer'
: triggered
|
X****r
发帖数: 3557 | 14 On an abstract level, it is the circular dependency between Foo
and the map that caused smart pointers to malfunction.
(And this is where Java's GC really makes things easy, no wonder
a Java programmer would make this kind of mistake in C++)
Solaris
pointer'
ref
triggered
【在 d****p 的大作中提到】
: Your answer is basically right - it depends on map implementation.
: So it may cause bus error on VS/Windows or GCC/Mac but run fine on Solaris
: or GCC/Linux.
: What happened is:
: 1. after exiting main, the static map object is gonna be destructed
: 2. since one node in the map is a shared pointer of Foo, the shared pointer'
: s ref count is decremented (to zero), and ~Foo called.
: 3. inside ~Foo, the erase tries to re-decrement the shared pointer's ref
: count - since it is already 0, no further action (so
|
d****p
发帖数: 685 | 15 Agree. C++ coder has to have a very clear idea about object's ownership
while Java GC tries to hide such stuff from Java coder.
【在 X****r 的大作中提到】
: On an abstract level, it is the circular dependency between Foo
: and the map that caused smart pointers to malfunction.
: (And this is where Java's GC really makes things easy, no wonder
: a Java programmer would make this kind of mistake in C++)
:
: Solaris
: pointer'
: ref
: triggered
|
z***9
发帖数: 696 | 16 说实在的，这code作为面试题可以，但是作为个工程项目，确实很垃圾，很多时候，根
本就不需要这么复杂的绕来绕去来定义class，最后连自己都找不着北了 |
d****p
发帖数: 685 | 17 This is just a simplification of the actual code which did make some sense
for the problem it attacked.
In most real projects, the perfect code itself in academic sense does NOT
exist. Even it exists for a short time, it will be distorted sooner or
latter due to changing requirement or change introduced by some other guys
who code in a different way. |
T*******x
发帖数: 8565 | 18 程序这么乱，看都看不懂，肯定有问题。
这么说行不行？:)
【在 d****p 的大作中提到】
: #include
: #include
|
T*******x
发帖数: 8565 | 19 我比较害怕static，一直没太整明白。
【在 d****p 的大作中提到】
: #include
: #include
|
T*******x
发帖数: 8565 | 20 既然都smart pointer了，没什么需要destruct的了吧。
把~Foo()删掉就没问题了吧。
【在 d****p 的大作中提到】
: #include
: #include
|
|
|
d****p
发帖数: 685 | 21 Nope :-)
You can punch the coder's face and yell at him "what crap code you made!"
after you FULLY understand the code.
If you don't understand it, you are not in good position to judge it.
Actually a real coder is expected to handle various code, most of it is OK
and some is pretty bad.
【在 T*******x 的大作中提到】
: 程序这么乱，看都看不懂，肯定有问题。
: 这么说行不行？:)
|
T*******x
发帖数: 8565 | 22 agreed:)
made!"
OK
【在 d****p 的大作中提到】
: Nope :-)
: You can punch the coder's face and yell at him "what crap code you made!"
: after you FULLY understand the code.
: If you don't understand it, you are not in good position to judge it.
: Actually a real coder is expected to handle various code, most of it is OK
: and some is pretty bad.
|
B*******g
发帖数: 1593 | 23 考 我越来越confused了
先问问general map::erase
Erase elements
Removes from the map container either a single element or a range of
elements ([first,last)).
This effectively reduces the container size by the number of elements
removed, calling each element's destructor.
如果我是map map::erase() 不会delete 吧？ 文中的意思是map会析构
A？
～Foo() 运行了几次？
Solaris
pointer'
ref
triggered
【在 d****p 的大作中提到】
: Your answer is basically right - it depends on map implementation.
: So it may cause bus error on VS/Windows or GCC/Mac but run fine on Solaris
: or GCC/Linux.
: What happened is:
: 1. after exiting main, the static map object is gonna be destructed
: 2. since one node in the map is a shared pointer of Foo, the shared pointer'
: s ref count is decremented (to zero), and ~Foo called.
: 3. inside ~Foo, the erase tries to re-decrement the shared pointer's ref
: count - since it is already 0, no further action (so
|
d****p
发帖数: 685 | 24 != >
The first one doesn't call ~T when erasing an element
The second one may call ~T if the ref count goes to zero
析构
【在 B*******g 的大作中提到】
: 考 我越来越confused了
: 先问问general map::erase
: Erase elements
: Removes from the map container either a single element or a range of
: elements ([first,last)).
: This effectively reduces the container size by the number of elements
: removed, calling each element's destructor.
: 如果我是map map::erase() 不会delete 吧？ 文中的意思是map会析构
: A？
: ～Foo() 运行了几次？
|
z****e
发帖数: 2024 | 25 你那个第5点，说是map的node重复delete问题。
如果是的话，map的node每次delete完了，就置0不就完了么？难道map不这么作？
其实就是递归delete的问题啊？？就是map来没来得及把自己那个节点置零，就必须销毁一个正在调用自己dtor的对象。
class D{
public:
~D(){
this->~D();
}
};
你试试？不就这么回事么？哪用你说得那么复杂呢？
比如我那个例子里面，delete置零都没用，因为还没有来得及置零，就必须递归调用同一个dtor了。
大家说说吧。
pointer'
triggered
【在 d****p 的大作中提到】
: Your answer is basically right - it depends on map implementation.
: So it may cause bus error on VS/Windows or GCC/Mac but run fine on Solaris
: or GCC/Linux.
: What happened is:
: 1. after exiting main, the static map object is gonna be destructed
: 2. since one node in the map is a shared pointer of Foo, the shared pointer'
: s ref count is decremented (to zero), and ~Foo called.
: 3. inside ~Foo, the erase tries to re-decrement the shared pointer's ref
: count - since it is already 0, no further action (so
|
l******u
发帖数: 1174 | 26 Agreed. Seems to me the author tried to kill 2 birds with one stone (2 birds
being life-cycle of Foo objects, and map membership of Foo objects), and
got himself/herself in trouble. If it were me, I would write separate code
for managing the map instead of depending on the constructor/destructor of
Foo -- I would write some wrapper code on top of the Foo class to manage the
membership of the Foo objects in the map.
【在 X****r 的大作中提到】
: On an abstract level, it is the circular dependency between Foo
: and the map that caused smart pointers to malfunction.
: (And this is where Java's GC really makes things easy, no wonder
: a Java programmer would make this kind of mistake in C++)
:
: Solaris
: pointer'
: ref
: triggered
|
z****e
发帖数: 2024 | 27 smart pointer 不是 绝对不是 永远不是 pointer！
smart pointer 就一user defined class 对象而已。
pointer 里边只有机器地址，没有dtor。
而smart pointer 有dtor。
析构
【在 B*******g 的大作中提到】
: 考 我越来越confused了
: 先问问general map::erase
: Erase elements
: Removes from the map container either a single element or a range of
: elements ([first,last)).
: This effectively reduces the container size by the number of elements
: removed, calling each element's destructor.
: 如果我是map map::erase() 不会delete 吧？ 文中的意思是map会析构
: A？
: ～Foo() 运行了几次？
|
z****e
发帖数: 2024 | 28 我觉得呀，这个题目就是递归delete问题。
我的第一个例子，是普通指针，递归delete会产生重复delete问题非零指针。（置零无法解决。）
我的第二个例子，是用户类型，递归delete会产生递归析构问题。（同样置零无法解决。）
而你的答案，和我的答案的本质区别，就是，你认为是“重复delete”，但是我认为不是“重复”，而是“递归”。
你说的“重复”，是可以用置零的办法解决的。但是递归呢，就不行。
所以，我觉得我第二个例子，自己调用自己dtor那个，
应该就是你这个题目的答案了吧？
第一个例子的精神思想是对的，但是也不能算全错吧？
所以我觉得我那个第7楼的回答，里边的精神仍然闪闪发光啊！
你当时把我一棒子打死啊！
你给说说看。啊？
最后，当ref=0,Foo被销毁的时候，同一个shared_ptr对象，要以递归形式，两次进入自己的dtor。
你觉得这个说法如何？
【在 d****p 的大作中提到】
: != >
: The first one doesn't call ~T when erasing an element
: The second one may call ~T if the ref count goes to zero
:
: 析构
|
z****e
发帖数: 2024 | 29 俺说的，就是在析构Foo的时候，也就是ref=0,同一个shared_ptr要以递归形式，两次进入自己的dtor。
这两次，都会发现ref=0,然后delete，故而crash？？？
这个题目的报错，好像和如下代码是一样的。
{
type* p=new type();
shared_ptr sp1(p);
shared_ptr sp2(p);
}
【在 p***o 的大作中提到】
: 主动析构Foo没问题，因为 至少还有一个引用（就是你正在析构的这个），
: 所以map::erase只析构shared_ptr，不会回到~Foo里面。
: 但是如果程序结束的时候map不为空而且每个里面的对象只有一个引用
: （就是map里这个），那么map析构的时候 可能 会有重入问题，具体取
: 决于map析构时的行为，就是说如果shared_ptr析构引起Foo析构的时候
: key还能在map中找到，那么就会有问题。
|
p***o
发帖数: 1252 | 30 shared_ptr两次进入自己的dtor没问题，问题是第二次进入的时候ref=-1，
把invariant破坏了，多调了Foo::~Foo()一次。你在那里放个assert就能
发现这个问题。
次进入自己的dtor。
【在 z****e 的大作中提到】
: 俺说的，就是在析构Foo的时候，也就是ref=0,同一个shared_ptr要以递归形式，两次进入自己的dtor。
: 这两次，都会发现ref=0,然后delete，故而crash？？？
: 这个题目的报错，好像和如下代码是一样的。
: {
: type* p=new type();
: shared_ptr sp1(p);
: shared_ptr sp2(p);
: }
|
|
|
z****e
发帖数: 2024 | 31 好，我去看看。
也就是说，还是~Foo（）的问题是吧？
【在 p***o 的大作中提到】
: shared_ptr两次进入自己的dtor没问题，问题是第二次进入的时候ref=-1，
: 把invariant破坏了，多调了Foo::~Foo()一次。你在那里放个assert就能
: 发现这个问题。
:
: 次进入自己的dtor。
|
d****p
发帖数: 685 | 32 check boost shared_ptr source code and you will know how it works.
ref count never goes negative so an object properly managed by shared
pointer will NEVER be deleted more than once.
无法解决。）
决。）
不是“重复”，而是“递归”。
【在 z****e 的大作中提到】
: 我觉得呀，这个题目就是递归delete问题。
: 我的第一个例子，是普通指针，递归delete会产生重复delete问题非零指针。（置零无法解决。）
: 我的第二个例子，是用户类型，递归delete会产生递归析构问题。（同样置零无法解决。）
: 而你的答案，和我的答案的本质区别，就是，你认为是“重复delete”，但是我认为不是“重复”，而是“递归”。
: 你说的“重复”，是可以用置零的办法解决的。但是递归呢，就不行。
: 所以，我觉得我第二个例子，自己调用自己dtor那个，
: 应该就是你这个题目的答案了吧？
: 第一个例子的精神思想是对的，但是也不能算全错吧？
: 所以我觉得我那个第7楼的回答，里边的精神仍然闪闪发光啊！
: 你当时把我一棒子打死啊！
|
d****p
发帖数: 685 | 33 Don't just "see see" at high level - debug it and see the call trace.
【在 z****e 的大作中提到】
: 好，我去看看。
: 也就是说，还是~Foo（）的问题是吧？
|
p***o
发帖数: 1252 | 34 ~Foo()的问题在于它造成了 同一个 shared_ptr对象被析构了两次。
当然不用shared_ptr也可以造成这个错误:
#include |
d****p
发帖数: 685 | 35 你这个例子是典型的shared ptr误用.
both sp1 and sp2 have their internal shared count object and each such
shared count has incremented the ref count to 1
after the current scope goes out, sp2 gets destructed first and its shared
count object decrements the ref count to zero and the p will be deleted.
now sp1 goes out of scope and this repeated again so there is double delete.
次进入自己的dtor。
【在 z****e 的大作中提到】
: 俺说的，就是在析构Foo的时候，也就是ref=0,同一个shared_ptr要以递归形式，两次进入自己的dtor。
: 这两次，都会发现ref=0,然后delete，故而crash？？？
: 这个题目的报错，好像和如下代码是一样的。
: {
: type* p=new type();
: shared_ptr sp1(p);
: shared_ptr sp2(p);
: }
|
d****p
发帖数: 685 | 36 你这个是不折不扣的递归析构.
和原先例子不同.如果对象被shared ptr管理,该对象的席构是被shared ptr接管的,不
是被erase所在的容器控制的.
这个题目如下三种情况是不同的:
std::map< key_type, T* >
std::map< key_type, T >
std::map< key_type, boost::shared_ptr >
【在 p***o 的大作中提到】
: ~Foo()的问题在于它造成了 同一个 shared_ptr对象被析构了两次。
: 当然不用shared_ptr也可以造成这个错误:
: #include
|
p***o
发帖数: 1252 | 37 应该是等价的，我只不过把引用计数简化成0/1了而已。
【在 d****p 的大作中提到】
: 你这个是不折不扣的递归析构.
: 和原先例子不同.如果对象被shared ptr管理,该对象的席构是被shared ptr接管的,不
: 是被erase所在的容器控制的.
: 这个题目如下三种情况是不同的:
: std::map< key_type, T* >
: std::map< key_type, T >
: std::map< key_type, boost::shared_ptr >
|
d****p
发帖数: 685 | 38 Nope.
std::map map destructs T object
std::map map does not destruct T object
std::map > map destructs boost::shared_ptr
which further destructs T* wapped inside when ref count becomes zero
If you debug shared_ptr, you will notice there is usually a px and a pn
px is the raw pinter, in this T* while pn is the shard count object which
basically holds the raw pointer again and ref count.
【在 p***o 的大作中提到】
: 应该是等价的，我只不过把引用计数简化成0/1了而已。
|
z****e
发帖数: 2024 | 39 两位大牛，我有一个极弱问题：
core dump之后回溯，得到如下东东，
这都是神马玩意啊？？？
好像第3帧之前都是系统的事情，
倒数第8帧，看到了亲耐地 shared_ptr，这玩意怎么调试啊？？？
Program received signal SIGABRT, Aborted.
0xb76e5410 in __kernel_vsyscall ()
(gdb) bt
#0 0xb76e5410 in __kernel_vsyscall ()
#1 0xb7487085 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7488a01 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb74bfb7c in ?? () from /lib/tls/i686/cmov/libc.so.6
#4 0xb74c7a85 in ?? () from /lib/tls/i686/cmov/libc.so.6
#5 0xb74cb4f0 in free () from /lib/ |
z****e
发帖数: 2024 | |
|
|
z****e
发帖数: 2024 | 41 而且，令我感到更弱智的事情，是在shared_ptr.hpp里边，居然没看见析构函数？？？ |
p***o
发帖数: 1252 | 42 这么说吧，你的code会crash是因为 多次 进入了 同一个 shared_ptr的dtor。
不用shared_ptr也能复现这个取决于map实现的错误，用了之后让错误更隐蔽。
>
【在 d****p 的大作中提到】
: Nope.
: std::map map destructs T object
: std::map map does not destruct T object
: std::map > map destructs boost::shared_ptr
: which further destructs T* wapped inside when ref count becomes zero
: If you debug shared_ptr, you will notice there is usually a px and a pn
: px is the raw pinter, in this T* while pn is the shard count object which
: basically holds the raw pointer again and ref count.
|
d****p
发帖数: 685 | 43 The #8 is for calling _M_put_node in rb_tree which is called by _M_destroy_
node. #7 is about dealocating the memory for current tree node. That
deallocate function has actually been called before when you erased the same
node from ~Foo(). That's why I said it is the map node (not Foo) being
deleted twice.
Set a breakpint in stl_tree.h line 273 deallocate function and you will
observe it is called twice.
The shared pointer stuff around #8 is about qualifying the map's type
【在 z****e 的大作中提到】
: 两位大牛，我有一个极弱问题：
: core dump之后回溯，得到如下东东，
: 这都是神马玩意啊？？？
: 好像第3帧之前都是系统的事情，
: 倒数第8帧，看到了亲耐地 shared_ptr，这玩意怎么调试啊？？？
: Program received signal SIGABRT, Aborted.
: 0xb76e5410 in __kernel_vsyscall ()
: (gdb) bt
: #0 0xb76e5410 in __kernel_vsyscall ()
: #1 0xb7487085 in raise () from /lib/tls/i686/cmov/libc.so.6
|
c*****e
发帖数: 3226 | 44 hi, could you please elaborate step 5). I understand steps 1-4,
but have no idea about step 5 .why it depends on maps' implementation.
is n't any map node would be deleted?
==============================================================
5. Here is the thing. Depending on specific map's implementation, the
deleted map node which was hosting the shared pointer to Foo would or would
not be deleted. If it is the first case, the node will be deleted twice and
there will be fatal signal indicating tryi
【在 d****p 的大作中提到】
: Your answer is basically right - it depends on map implementation.
: So it may cause bus error on VS/Windows or GCC/Mac but run fine on Solaris
: or GCC/Linux.
: What happened is:
: 1. after exiting main, the static map object is gonna be destructed
: 2. since one node in the map is a shared pointer of Foo, the shared pointer'
: s ref count is decremented (to zero), and ~Foo called.
: 3. inside ~Foo, the erase tries to re-decrement the shared pointer's ref
: count - since it is already 0, no further action (so
|
c*****e
发帖数: 3226 | 45 hi, could you please elaborate step 5). I understand steps 1-4,
but have no idea about step 5 .why it depends on maps' implementation.
is n't any map node would be deleted?
==============================================================
5. Here is the thing. Depending on specific map's implementation, the
deleted map node which was hosting the shared pointer to Foo would or would
not be deleted. If it is the first case, the node will be deleted twice and
there will be fatal signal indicating tryi
【在 d****p 的大作中提到】
: Your answer is basically right - it depends on map implementation.
: So it may cause bus error on VS/Windows or GCC/Mac but run fine on Solaris
: or GCC/Linux.
: What happened is:
: 1. after exiting main, the static map object is gonna be destructed
: 2. since one node in the map is a shared pointer of Foo, the shared pointer'
: s ref count is decremented (to zero), and ~Foo called.
: 3. inside ~Foo, the erase tries to re-decrement the shared pointer's ref
: count - since it is already 0, no further action (so
|
c******n
发帖数: 4965 | 46 regarding ur #5,
web search seems to say that map::erase() SHOULD call destructor,
so the real point of this question is rather uninteresting,
just the difference between destructing container content and removing
the content, which everyone knows. yes the actual behavior is not
defined , so it's bad to expect the interviewee to see this --- in fact
I always assumed that the destructor is NOT called.
I'd rather separate out this question explicitly
Solaris
pointer'
ref
triggered
【在 d****p 的大作中提到】
: Your answer is basically right - it depends on map implementation.
: So it may cause bus error on VS/Windows or GCC/Mac but run fine on Solaris
: or GCC/Linux.
: What happened is:
: 1. after exiting main, the static map object is gonna be destructed
: 2. since one node in the map is a shared pointer of Foo, the shared pointer'
: s ref count is decremented (to zero), and ~Foo called.
: 3. inside ~Foo, the erase tries to re-decrement the shared pointer's ref
: count - since it is already 0, no further action (so
|
z****e
发帖数: 2024 | 47 这些是全凭经验知道的，还是有什么书，手段可以看？
STL的调试有没有方便的方法啊？
比如说，我要是用g++，如果想看stl_tree.h的断点，必须编译我自己的程序的时候也
重新编译STL吧？用上-g选项，不然gdb找不到啊。
same
【在 d****p 的大作中提到】
: The #8 is for calling _M_put_node in rb_tree which is called by _M_destroy_
: node. #7 is about dealocating the memory for current tree node. That
: deallocate function has actually been called before when you erased the same
: node from ~Foo(). That's why I said it is the map node (not Foo) being
: deleted twice.
: Set a breakpint in stl_tree.h line 273 deallocate function and you will
: observe it is called twice.
: The shared pointer stuff around #8 is about qualifying the map's type
|
d****p
发帖数: 685 | 48 这个问题好,非常适用用于面试 :-)
一个类没显示定义析构就真得没有吗?
其成员shared_count的析构被定义,所以编译器会为其产生一个内在的析构.
【在 z****e 的大作中提到】
: 而且，令我感到更弱智的事情，是在shared_ptr.hpp里边，居然没看见析构函数？？？
|
z****e
发帖数: 2024 | 49 when the subobjects or member objects have non-trivial destructor, compiler
will synthesize a destructor. not "内在的"
面试官用词不当。呵呵。
【在 d****p 的大作中提到】
: 这个问题好,非常适用用于面试 :-)
: 一个类没显示定义析构就真得没有吗?
: 其成员shared_count的析构被定义,所以编译器会为其产生一个内在的析构.
|
d****p
发帖数: 685 | 50 Hmmm I think implicit vs explicit is legitimate term describing this case -
a ctor synthesized by compiler is
implicitly defined, from editor program's view. But anyway your answer is
textbook style so is right.
So
technical+++++behavioural
Do you accept this result?
compiler
【在 z****e 的大作中提到】
: when the subobjects or member objects have non-trivial destructor, compiler
: will synthesize a destructor. not "内在的"
: 面试官用词不当。呵呵。
|
|
|
z****e
发帖数: 2024 | 51 wish you can post more high quality "interview questions".
This one is very good. i learn a lot from this one.
-
【在 d****p 的大作中提到】
: Hmmm I think implicit vs explicit is legitimate term describing this case -
: a ctor synthesized by compiler is
: implicitly defined, from editor program's view. But anyway your answer is
: textbook style so is right.
: So
: technical+++++behavioural
: Do you accept this result?
:
: compiler
|
d****p
发帖数: 685 | 52 The interview is not over yet :-)
anything special in the +++++ stuff?
【在 z****e 的大作中提到】
: wish you can post more high quality "interview questions".
: This one is very good. i learn a lot from this one.
:
: -
|
z****e
发帖数: 2024 | 53 what?
a+++++b?
is this well defined behavior?
【在 d****p 的大作中提到】
: The interview is not over yet :-)
: anything special in the +++++ stuff?
|
