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

[Phlip]

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." ?

That's because MACROS SUCK!

Yet sometimes we pay our vendors to provide them.

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?).

Fortunately no, English syntactical rules are a little tighter about
that then the syntax rules we're dealing with here. I think this is
why you see companies come up with those annoying coding guidelines,
so we spend less time busting each others chops over the nasty piece
of code they just wrote and more time actually producing something.

This is why programmers should own tasks and share modules. As programmers
edit modules they should intentionally move them closer to community
agreement.

Coding guidelines are a sick attempt to enforce one benefit of teamwork,
without the other benefits. Like less bugs.

 

[red floyd]

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]

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

;-)

 

[belvis]

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

 

[E. Robert Tisdale]

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

 

[Steven T. Hatton]

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." ?


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


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

 

[Steven T. Hatton]

Nitpick: avoid names that begin with "_".

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

 

[Phlip]

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

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.

 

[red floyd]

red floyd wrote:



pointer to



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]

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

 

[Steven T. Hatton]

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:stream. 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.

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.

 

[belvis]

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