Not really. \When you pass an object by reference
the reference count increases to include the scope
of the other object, and when you return from the by reference call it decreases.
More than one object might hold a reference to the
same object instance, e.g.
BankAccount class instance 012454 might reference Person class instance DaveP and so might BankAccount class instance 012455 ( I own both those accounts ).
Thus if someone deletes BankAccount 012454 only the reference count to DaveP is decremented. If they delete the 012455 then the reference count is zero and DaveP gets dropped from memory. That is of course if it is not held by another container class that looks after Person instances.
In fact when you start looking at the difference between active ( in memory ) instances vs passivated ( in storage and no longer in memory ) it gives you a neat lead.
Further to this if there are multiple places where the object could need to be removed and it is run time conditional.
say you are in a complex nesting of try/catch blocks and the object instance is allocated somewhere in the mid point.
You could follow the laborious principle that each level of nesting that makes an allocation that the parent nesting is aware of should catch every exception de-allocate and rethrow. However that leads to ridiculously inpenetrable code.
Better to rely on the stack unwind principle. Thus a smart pointer allocated in the mid point would automatically deallocate the memory ( if it is not used elsewhere - an important point when you start getting into using container classes ) during unwind and therefore you do not need to catch rethrow just for deallocation or somehow "inform the parent" of the allocation or WORSE leak because you weren't aware of what will happen during an exception throw.
When might this be important? Well say the midpoint in the try catch not only creates a new bank account but adds it to the container for all bank accounts. This means the reference count is now two. If the bank account is passed to a child scope then the reference count is now three. IF an exception is thrown the reference count is now one and the object does not get deleted. Fine if you want to up front determine what the code is doing you could probably set some flag to indicate that the bank account memory is now owned not by the original scope of the allocator - but that is the point. In complex situations ( which occur 8 times out of 10 ) you start setting flags in order to give a catch block or some other code some indication of how to handle allocations and de-allocations depending on the flow of logic.
Better, more elegant and even easier for the human mind to manage ( and for subsequent program maintainers such as change teams ) if the decision to use auto/smart pointers and reference counting up front.
Note that to implement a good auto pointer ( not the one found by default in later revisions of C++ ) you are best putting the reference counting in some parent "Object" class AND the auto pointer has to be passed "by value" everywhere to force the copy constructor to do its work.
