«

Hi!
I've been thinking about passing parameteras using references instead
of pointers in order to emphasize that the parameter must be an
object.

Exemple:
void func(Objec& object); //object must be an object

instead of

void func(Object* object); //object can be NULL

I belive that this is a good idea since , in the reference case, it's
clear that NULL is not an option. It's also clear that NULL is an
option when a pointer is expected (stating the obvious ). The code
becomes somewhat more self-documenting.

Any comments on why this could be a bad idea or do you think it's just
a matter of taste?

/H

Mr A wrote:
> Hi!
> I've been thinking about passing parameteras using references instead
> of pointers in order to emphasize that the parameter must be an
> object.
>
> Exemple:
> void func(Objec& object); //object must be an object
>
> instead of
>
> void func(Object* object); //object can be NULL
>
> I belive that this is a good idea since , in the reference case, it's
> clear that NULL is not an option. It's also clear that NULL is an
> option when a pointer is expected (stating the obvious ). The code
> becomes somewhat more self-documenting.
>
> Any comments on why this could be a bad idea or do you think it's just
> a matter of taste?
>
> /H

That is exactly the right way to do it. I'd go so far as to say always
prefer a reference over a pointer unless you have an explicit need for a
pointer (i.e. it needs to be reseated for some reason and/or NULL has a
useful meaning). The reason being pretty much the same that you stated.
References are (for me at least) easier to work with, and there is no
worry of accidentally trying to access an object through a "NULL reference".

-Alan

Mr A wrote:

> Hi!
> I've been thinking about passing parameteras using references instead
> of pointers in order to emphasize that the parameter must be an
> object.
>
> Exemple:
> void func(Objec& object); //object must be an object
>
> instead of
>
> void func(Object* object); //object can be NULL
>
> I belive that this is a good idea since , in the reference case, it's
> clear that NULL is not an option. It's also clear that NULL is an
> option when a pointer is expected (stating the obvious ). The code
> becomes somewhat more self-documenting.
>
> Any comments on why this could be a bad idea or do you think it's just
> a matter of taste?
>
> /H

Unfortunately, there are different vantage points from which we view a
function: declaration, definition and invocation. Each has it's own
exposed and hidden information. It has been argued that passing a pointer
is more explicit, and makes the code easier to read. I tend to agree.

AFAIK, you *can* pass a null to func() in your example, and the compiler
will accept it. Your code will segfault when you do so. If you pass a
pointer, you can check for null, before accessing it. I, therefore,
suggest using a pointer instead of a reference.


--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

Steven T. Hatton wrote:
> Mr A wrote:
>
>>Hi!
>>I've been thinking about passing parameteras using references instead
>>of pointers in order to emphasize that the parameter must be an
>>object.
>>
>>Exemple:
>>void func(Objec& object); //object must be an object
>>
>>instead of
>>
>>void func(Object* object); //object can be NULL
>>
>>I belive that this is a good idea since , in the reference case, it's
>>clear that NULL is not an option. It's also clear that NULL is an
>>option when a pointer is expected (stating the obvious ). The code
>>becomes somewhat more self-documenting.
>>


The above paragraph is correct. Attempting to pass ANYTHING except
a ref to an existing instance of the required type will cause a
compile-time error. Unless there is some specific reason to pass a
pointer, using ref's is usually preferred.


>>Any comments on why this could be a bad idea or do you think it's just
>>a matter of taste?
>>
>>/H
>
> Unfortunately, there are different vantage points from which we view a
> function: declaration, definition and invocation. Each has it's own
> exposed and hidden information. It has been argued that passing a pointer
> is more explicit, and makes the code easier to read. I tend to agree.
>
> AFAIK, you *can* pass a null to func() in your example, and the compiler
> will accept it. Your code will segfault when you do so. If you pass a
> pointer, you can check for null, before accessing it. I, therefore,
> suggest using a pointer instead of a reference.
>
>

If a function takes a ref, then NULL can not be passed.
Attempting to pass NULL causes a compile error.
For example:

#include <iostream>

struct Stuff
{
int a;
double b;
};

void func(Stuff& obj)
{
obj.a = 1;
}

int main()
{
Stuff s;

func(s);
func(0); // causes a compile error

return 0;
}

Larry

Larry I Smith wrote:

> Steven T. Hatton wrote:
>> Mr A wrote:
[...]
>>>I belive that this is a good idea since , in the reference case, it's
>>>clear that NULL is not an option. It's also clear that NULL is an
>>>option when a pointer is expected (stating the obvious ). The code
>>>becomes somewhat more self-documenting.
>>>
>
>
> The above paragraph is correct. Attempting to pass ANYTHING except
> a ref to an existing instance of the required type will cause a
> compile-time error. Unless there is some specific reason to pass a
> pointer, using ref's is usually preferred.

By whom?

>>>Any comments on why this could be a bad idea or do you think it's just
>>>a matter of taste?
>>>
>>>/H
>>
>> Unfortunately, there are different vantage points from which we view a
>> function: declaration, definition and invocation. Each has it's own
>> exposed and hidden information. It has been argued that passing a
>> pointer is more explicit, and makes the code easier to read. I tend to
>> agree.
>>
>> AFAIK, you *can* pass a null to func() in your example, and the compiler
>> will accept it. Your code will segfault when you do so. If you pass a
>> pointer, you can check for null, before accessing it. I, therefore,
>> suggest using a pointer instead of a reference.
>>
>>
>
> If a function takes a ref, then NULL can not be passed.
> Attempting to pass NULL causes a compile error.
> For example:
>
> #include <iostream>
>
> struct Stuff
> {
> int a;
> double b;
> };
>
> void func(Stuff& obj)
> {
> obj.a = 1;
> }
>
> int main()
> {
> Stuff s;
>
> func(s);
> func(0); // causes a compile error
>
> return 0;
> }
>
> Larry

In your example, you are not trying to pass null, you are trying to pass a
literal. That results in the attempt to create a temporary object of type
int and assign it to the non-const reference. This, however, will compile:

#include <string>
std::string func(std::string& s) { return s; }
int main() {
std::string* s(0);
func(*s);
}

I know of two companies who have concluded that passing by reference is, in
general, a bad choice. Trolltech, and SuSE.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

"Steven T. Hatton" <> wrote in message
news:asSdnb1UbeBN80zfRVn-
>
> In your example, you are not trying to pass null, you are trying to
> pass a literal.

He is passing NULL which is the same as 0.

> That results in the attempt to create a temporary
> object of type int and assign it to the non-const reference. This,
> however, will compile:
>
> #include <string>
> std::string func(std::string& s) { return s; }
> int main() {
> std::string* s(0);
> func(*s);
> }

Dereferencing a NULL pointer is undefined behaviour by section 8.3.2/4.
When I run your code, the program crashes.

--
John Carson

"Steven T. Hatton" <> wrote in message
news:asSdnb1UbeBN80zfRVn-
>>>
>>> AFAIK, you *can* pass a null to func() in your example, and the
>>> compiler will accept it. Your code will segfault when you do so.
>>> If you pass a pointer, you can check for null, before accessing it.
>>> I, therefore, suggest using a pointer instead of a reference.

I missed this bit. It seems you are aware of the problem.

--
John Carson

Steven T. Hatton wrote:

> Larry I Smith wrote:
>
>> Steven T. Hatton wrote:
>>> Mr A wrote:
> [...]
>>>>I belive that this is a good idea since , in the reference case, it's
>>>>clear that NULL is not an option. It's also clear that NULL is an
>>>>option when a pointer is expected (stating the obvious ). The code
>>>>becomes somewhat more self-documenting.
>>>>
>>
>>
>> The above paragraph is correct. Attempting to pass ANYTHING except
>> a ref to an existing instance of the required type will cause a
>> compile-time error. Unless there is some specific reason to pass a
>> pointer, using ref's is usually preferred.
>
> By whom?
>
>>>>Any comments on why this could be a bad idea or do you think it's just
>>>>a matter of taste?
>>>>
>>>>/H
>>>
>>> Unfortunately, there are different vantage points from which we view a
>>> function: declaration, definition and invocation. Each has it's own
>>> exposed and hidden information. It has been argued that passing a
>>> pointer is more explicit, and makes the code easier to read. I tend to
>>> agree.
>>>
>>> AFAIK, you *can* pass a null to func() in your example, and the compiler
>>> will accept it. Your code will segfault when you do so. If you pass a
>>> pointer, you can check for null, before accessing it. I, therefore,
>>> suggest using a pointer instead of a reference.
>>>
>>>
>>
>> If a function takes a ref, then NULL can not be passed.
>> Attempting to pass NULL causes a compile error.
>> For example:
>>
>> #include <iostream>
>>
>> struct Stuff
>> {
>> int a;
>> double b;
>> };
>>
>> void func(Stuff& obj)
>> {
>> obj.a = 1;
>> }
>>
>> int main()
>> {
>> Stuff s;
>>
>> func(s);
>> func(0); // causes a compile error
>>
>> return 0;
>> }
>>
>> Larry
>
> In your example, you are not trying to pass null, you are trying to pass a
> literal. That results in the attempt to create a temporary object of type
> int and assign it to the non-const reference. This, however, will
> compile:
>
> #include <string>
> std::string func(std::string& s) { return s; }
> int main() {
> std::string* s(0);
> func(*s);
> }
>
> I know of two companies who have concluded that passing by reference is,
> in
> general, a bad choice. Trolltech, and SuSE.


Obvious exceptions are:

std:stream& print(std:stream& out) const {...}

and when passing a const reference:

int foo(const BigObject& bo){}
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

John Carson wrote:

> "Steven T. Hatton" <> wrote in message
> news:asSdnb1UbeBN80zfRVn-
>>
>> In your example, you are not trying to pass null, you are trying to
>> pass a literal.
>
> He is passing NULL which is the same as 0.

'0', when it appears in your code, is a literal. If the reference were
const, the code /would/ compile.

#include <string>
std::string cfunc(const std::string& s) { return s; }
int main() {
cfunc(0);
}

It still has a problem. The above aborts when executed. That's one better
than a segfault, but not typically what I want from a program.

>> That results in the attempt to create a temporary
>> object of type int and assign it to the non-const reference. This,
>> however, will compile:
>>
>> #include <string>
>> std::string func(std::string& s) { return s; }
>> int main() {
>> std::string* s(0);
>> func(*s);
>> }
>
> Dereferencing a NULL pointer is undefined behaviour by section 8.3.2/4.
> When I run your code, the program crashes.

Yes, it segfaults. That was my point.

--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

Mr A wrote:
> Hi!
> I've been thinking about passing parameteras using references instead
> of pointers in order to emphasize that the parameter must be an
> object.
>
> Exemple:
> void func(Objec& object); //object must be an object
>
> instead of
>
> void func(Object* object); //object can be NULL
>
> I belive that this is a good idea since , in the reference case, it's
> clear that NULL is not an option. It's also clear that NULL is an
> option when a pointer is expected (stating the obvious ). The code
> becomes somewhat more self-documenting.
>
> Any comments on why this could be a bad idea or do you think it's just
> a matter of taste?

That looks like a very good idea to me, and IIRC, the FAQ agrees. IMHO,
it's more than a matter of style; it's also a matter of safety. If a
parameter should never be null, then don't give it the chance.

Kristo