写一个建构子
Foo(ICallback* callback)
: mCallback(callback){ assert(mCallback); }
被问说那为什么你mCallback不用reference 然后Foo就开成（ICallback&)就好
我不想这样改
但我没有强力的说法比较出哪一种比较好或是合理
我的看法
用ref, caller势必要*ptr 做dereference才能传进来
虽然说reference 可以当作non null去操作
但有心要传*null也不是不行.
开reference 给别人传，比起pointer更有机会caller不小心传入local variable
以上都可以用一句话“哪有人会这样写”来否定用pointer存.
而用reference 可以给人一种 必定要想办法生出一个物件才能呼叫的感觉...
实在想不到哪个时候 用reference
才是合理的写法.
反而我自己是很少看过member 用reference去存...
不知道大家在design上会有什么考量
谢谢

我觉得你把物件变量的内存控管交出去就开始错了要嘛写member function把生member variable的部分封装起来给使用者call 要嘛丢进来的东西你自己再new一块做copy

我觉得smart pointer唯一解

没有说明Foo跟ICallBack的生命周期跟拥有权没办法回答你的看法那段的理由我觉得还蛮弱的 我会默认用ref不用ref的理由, class需要被copy

生命周期都比这class本身久， 我知道理由很弱，但我很难描述我不想用ref的理由，总觉得不够弹性

阿对还有smart pointer这个解 我老了QQ

std::function 选我正解好吗

你要考虑callback生命周期 用reference传入的话其实有很高的机率会发生人为错误pointer除非耍蠢 很不自然的传一个local variable的pointer进来 不然基本上不太会出包 但ref机率高得多另外 smart pointer是通用解没错...

我的习惯是如果会改变外部状态就用指标，使用但是不会去改变外部就用ref(常常搭配const来保证不会修改)还需要担心生命周期的情况就都用std::shared_ptr处理

ref比较好,B(A&),如果正确依照物件生命周期设计,干净的程式结构会是B先结束,之后才是A结束,用pointer会变成语法上少了限制,随便写都会产生cyclic dependency的问题,造成物件生命周期结束这块非常难写,然后系统资源没释放完,浪费工程师的生命在找问题,最后跟你说解决的办法是定期reset整台机器…简单讲B(A&)很自然就从语法上让你设计出遵循着RAII的程式结构

从语法层级探讨很没意义，高兴怎样就怎样啊，真非要用reference 还有 reference_wrapper 可以活用。正确来讲还是要从生命周期去探讨，用更高阶抽象的概念来说就是 aggregation 跟 composition 的差异。如果对这两个名词陌生，可能要去补足一下 OOAD 的知识。身为一名工程师，设计图之类的当然要会画，然后按图施工，今天会有这种问题跑出来就是因为你没图。

reference 不能直接更换绑定对象