Pass-by-reference instead of pass-by-pointer = a bad idea?

[Mr A]

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

[red floyd]

Steven T. Hatton wrote:

I have never found a need for a constant pointer, as opposed to a pointer to
constant.

unsigned char volatile *const Pointer_To_Memory_Mapped_Register;
unsigned char volatile long *const Pointer_To_MM_Read_Only_Register;

[Phlip]

red floyd wrote:

I have never found a need for a constant pointer, as opposed to a pointer to constant.

unsigned char volatile *const Pointer_To_Memory_Mapped_Register;
unsigned char volatile long *const Pointer_To_MM_Read_Only_Register;

Ah, but those should be references, because you will never use the pointer
datum itself as a value. You should seat them once and then use them
(volatiley).

;-)

--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand

[belvis]

Steven T. Hatton wrote:

I agree. After this discussion started I began looking at places where
pointers are used, and, indeed, they can 'vanish' from clear sight. I
typically name things that are pointers _something_ptr, (intrusive)
reference counted pointers become _something_rptr and smart pointers become
_something_sptr.

If you're going to rely on naming conventions to convey "may be
modified", then whether you use references or pointers is almost
irrelevant. This makes it possible to decide on reference or pointer
arguments based on what makes more sense for the function in question.

Nitpick: avoid names that begin with "_".

Bob

[Steven T. Hatton]

Phlip wrote:

Shezan Baig wrote:

By using the '#define' macro, you're basically messing with the C++
type system and asking for trouble (in other places as well). Using
this instead:
Did you see the place where I wrote "If anyone finds an an issue with the
example, they'l be qualified to think of a similar one that generates the
same problem." ?

Steven T. Hatton wrote:

That's because MACROS SUCK!

Yet sometimes we pay our vendors to provide them.

I'm considering a funddrive to persuade (bribe) one of the providers of a
library I'm working with to remove his _______ #MACROS.
My example is not the Alpha and Omega of 'const' placement. It merely
shows how const placement can't be called "_only_ a style question".

// t_rptr_ reminds me I plan to keep a handle on the argument.

I hate that kind of comment. There's no way for smart pointers to enforce
'new' (or have the Boosties found one?).

These aren't Boost pointers. They are form OSG. You cannot do a new with
one, but you can do referencing counting on all the objects derived from
osg::Referenced. So as long as you get that first handle, and make sure
you don't get any cycles, you can be sure of no memory leaks (assuming the
platform you're standing on isn't already adrift.)

--
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]

be****@pacbell.net wrote:

Nitpick: avoid names that begin with "_".

BAH! The implementation ain't got no business snoopin' around in my
classes! _foo works great!
--
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

[Phlip]

Steven T. Hatton wrote:

I'm considering a funddrive to persuade (bribe) one of the providers of a
library I'm working with to remove his _______ #MACROS.

Are they actually causing you trouble?

Or are they just easy to spot?

Some chronic design problems are not...

I hate that kind of comment. There's no way for smart pointers to enforce 'new' (or have the Boosties found one?).

These aren't Boost pointers.

I didn't say that. If there were a way to solve the problem "only pass the
output of 'new' into a constructor", then I would expect the Boosties to
find it.

--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand

[E. Robert Tisdale]

Steven T. Hatton wrote:

Clark S. Cox III wrote:

Steven T. Hatton said:

E. Robert Tisdale wrote:

Isn't it "obvious" that, in

std::cout << "i = " << 42 << std::endl;

ostream std::cout is used *thrice*?

Would that be written like this?

using namespace std;
cout.operator<<(cout.operator<<(cout.operator<< (cout,i),42),endl);
No, like this:
cout.operator<<("i = ").operator<<(42).operator<<(endl);

That's what I started to write, and I suspect it will also work.

Sigh!
cat main.cc #include <iostream>

int main(int argc, char* argv[]) {
//std::cout << "i = " << 42 << std::endl;
operator<<(std::cout, "i = ").operator<<(42)
.operator<<(std::endl);
return 0;
}
g++ -Wall -ansi -pedantic -o main main.cc
./main

i = 42

[red floyd]

Phlip wrote:

red floyd wrote:

I have never found a need for a constant pointer, as opposed to a
pointer to
constant.

unsigned char volatile *const Pointer_To_Memory_Mapped_Register;
unsigned char volatile long *const Pointer_To_MM_Read_Only_Register;

Ah, but those should be references, because you will never use the pointer
datum itself as a value. You should seat them once and then use them
(volatiley).

;-)

And how do you seat it, short of using a pointer? How do you make a
reference to it? Remember, the address of memory mapped register is
"magic", the compiler doesn't know about it.

[Phlip]

red floyd wrote:

And how do you seat it, short of using a pointer? How do you make a
reference to it? Remember, the address of memory mapped register is
"magic", the compiler doesn't know about it.

In general, '* const' is always a hint you might need a reference instead.

In this case, Pointer_To_MM_Read_Only_Register might indeed need to be born
NULL, wait a while, then be assigned a memory address.

If not, this works fine, right?

unsigned char volatile long &
Pointer_To_MM_Read_Only_Register =
*reinterpret_cast<unsigned char volatile long *> (0xDEADBEEF);

Fear this!

unsigned char volatile long *const volatile
Pointer_To_MM_Read_Only_Asynchronously_Moving_Regi ster;

--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand

[Steven T. Hatton]

Phlip wrote:

Steven T. Hatton wrote:

I'm considering a funddrive to persuade (bribe) one of the providers of a
library I'm working with to remove his _______ #MACROS.
Are they actually causing you trouble?

Trouble in the sense that they are offensive. They incorporate C-style
protramming in places where C++ constructs and concepts would be more
desirable. For example, they have many error code retrun value calls where
exceptions would be superior (which is basically everywhere there is an
error code retrun value.) They could use templates with some kind of
meta-programming gizmo to make them vanish when the optimization switches
are thrown. They use C-style output fromatting rather than C++
std::ostream. They hold the place of what could be more expressive and
elegant C++ function calls, or objects. The fail to use RAII where it is
appropriate. And they are all around just plain ugly!
Or are they just easy to spot?

The actual application code gets lost in the midst of them.

These aren't Boost pointers.

I didn't say that. If there were a way to solve the problem "only pass the
output of 'new' into a constructor", then I would expect the Boosties to
find it.

That won't always work for these. If I call new in a function where the
osg::ref_ptr<T> t_rptr(new T()); is defined I bump the reference count to
1. The transition from 1 to 0 forces the destructor to be called, so I may
have to fiddle with the reference count if I don't want it destroyed when
the block is exited. If you mean to call new in the constructor of the
object holding the osg::ref_ptr<T>, that has it's own set of problems.
It's probably pretty safe if there's only one parameter, but if there's
more than one there's a potential memory leak. It's just bad style to call
the constructor in a function call argument list. The brief existence of
the raw, un-handled pointer is safer and cleaner than any of the
alternatives.

--
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

[belvis]

Steven T. Hatton wrote:

be****@pacbell.net wrote:

Nitpick: avoid names that begin with "_".

BAH! The implementation ain't got no business snoopin' around in my
classes! _foo works great!

So does foo_, mFoo, m_foo, etc...

To quote one of your other recent posts: MACROS SUCK!

Bob