By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,417 Members | 1,047 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,417 IT Pros & Developers. It's quick & easy.

Thumb rule for passing arguments

P: n/a
Hi all,

I have a single-rooted hierarchy of heap-allocated objects -- call the
root Object. These objects are handled via a smart pointer template
Reference<T>. Basically, Reference<Tis a wrapper around T* with some
extra smarts including reference counting to make memory management
easier. Below, Reference<Objectwill be denoted simply by Ref.

Since you only get your hands on Reference<Tand never on a T (or T*)
directly, my thumb rule has been, at least in the public interface of
the T class, to pass and return by Reference<T(in most cases,
actually Ref). In addition, until now I have used

- return Reference<Tby const value, e.g.

const Reference<TsomeMethod(...);

The const to avoid such perplexing oddities as doing:

someMethod(...) = ...;

My question is now, what would be your thumb-rule for passing
arguments? Two basic choices:

- By value, e.g. someMethod(Reference<TsomeArg).

- By reference, e.g. someMethod(const Reference<T>& someArg)

Since Reference<Tis basically a pointer, I am inclined to
pass-by-value. This has the inconvenience of triggering a call to the
copy-constructor which implies the creation of another object and
fiddling of the reference count of T. On the other hand, there is one
less layer of indirection.

OTOH, looking at some Boost library smart pointer classes, they
usually use the pass-by-reference form.

Do you have any thumb-rule advice? Since I am writing this hierarchy
from scratch and for my own use (for now at least) I tend to value
consistency and doing everything the same way everywhere.

TIA, with my best regards,
G. Rodrigues
Nov 2 '06 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.