for eg,
const PointRange* points = cc.points(ptAligned);
cc.points is a const member function which returns a const pointer to
class PointRange.
This member function (from a different class) needs a const reference
to PointRange.
convolveNearEdge(const PointRange& points,const Kernel& kernel, ...) {}
I am passing it the reference as,
convolveNearEdge(*points,getKernel1(),velocity);
I do not need a null in the function thus a reference. also I make
assure points passed to convolveNearEdge is not null.
My question is, in the process do anywhere copy of the class occures
silently? I have no problem if it copies a pointer. But do not want a
copy of the class even temporarily.
Thus fundamentally , if I have a pointer, say int* x; *x = 10; then
int& y = *x is essentially a reference to the value pointed by x? and
without any overload?
Thanks
Unless there is a conversion from PointRange to something inside the
'convolveNearEdge' function... No, returning a pointer does not need
to make a copy, passing a reference doesn't either.
> I have no problem if it copies a pointer. But do not want a
> copy of the class even temporarily.
You can always put a breakpoint in the copy constructor and see if it
gets hit, you know...
> Thus fundamentally , if I have a pointer, say int* x; *x = 10; then
Ahem... That's a bad idea. 'x' points to nothing and you try to
dereference it...
> int& y = *x is essentially a reference to the value pointed by x? and
> without any overload?
Yes, supposedly. Using 'y' after that is just like using '*x'.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Thanks
Thanks
:-)
Usually
int* x = new int(10);
is preferred over
int* x = new int;
*x = 10;
It would be a good habit to get into...
>>> int& y = *x is essentially a reference to the value pointed by x?
>>> and without any overload?
>>
>> Yes, supposedly. Using 'y' after that is just like using '*x'.
>>
>> V
> Thus i feel that a pointer & reference can be freely interchangable
> without any overhead provided the pointer is pointing to a valid
> object.
Well, yes, that's true. Remember, though, that if you want to use any
overloaded operators, you have to write (*ptr). Kinda ugly. But you
are right, in that case there is only the syntactical difference.
> I usually pass a const / non const reference as it always hold a valid
> object & easier syntax. However I prefer return as pointer over
> reference (const / non const) , when I am not supposed to return
> value, because sometimes I forget to work with the reference, and use
> a copy instead, which do not serve the purpose of returning reference.
Returning a copy does serve its purpose, though. It's not the same as
returning a reference, and not only WRT copying.
> like instead of writing
> test11& t1 = t2.t();
> occationally end up with
> test11 t1 = t2.t();
> :(
> Any suggestion regurding this problem?
"Regurding"?
Anyway, just be careful. If you want to weed out all places where you
initialise an object (instead of a reference), disable the copy c-tor
and the compiler will barf. [of course it will barf on legal copying
as well, and you'll have to deal with that]. After removing all those
unwanted object copy-initialisations, re-enable the copy c-tor (if you
need it, that is).
V
Now,
test22 t2;
test11& t1 = t2.t();
This statement serves purpose, as I want user to "use test11 to use and
modify" not a copy of it. (may be, because I want it, or because it is
big enough not to be copied)
However by mistake if the user writes,
test22 t2;
test11 t1 = t2.t();
He unknowingly gets a copy and modifies it.
The same may be true if I return a const reference.
One method to prevent such mistake is to make the copy ctor private, or
not defined. However that may not be the solution as,
1) test11 may need copy ctor (say, test22 stores a vector<test11>
instead a single one)
2) I am not interested to prevent copy permanently, I just want to warn
about the mistake done "unknowingly"
Two solution so far I can think,
1) return a pointer / const pointer instead of reference/ const
reference.
Yes, as you suggested, if test11 has overloaded operator then direct
use of the class may be writing one more line to convert the pointer to
reference and then use it.
2) marke the copy ctor explicit.
Thus the code
test11 t1 = t2.t(); wont work. One need to write either
test11& t1 = t2.t(); => which is what I wanted usually.
or test11 t1(t2.t()); => which shows user clearly wants a copy.
I am seeking some advice "regarding" this kind of problem.
>
> Anyway, just be careful. If you want to weed out all places where you
> initialise an object (instead of a reference), disable the copy c-tor
> and the compiler will barf. [of course it will barf on legal copying
> as well, and you'll have to deal with that]. After removing all those
> unwanted object copy-initialisations, re-enable the copy c-tor (if you
> need it, that is).
I do it whenever possible. I can not do it when I need one - to -many
or many-to-one composition (association, aggregation) , as I usually
use stl containers for that purpose. However for any one-to-one
association / aggregation that is possible.
Many many thanks for the reply.
Why "unknowingly"? Why don't you trust your user to do the right thing?
> The same may be true if I return a const reference.
Yes. So?
> One method to prevent such mistake is to make the copy ctor private,
> or not defined. However that may not be the solution as,
> 1) test11 may need copy ctor (say, test22 stores a vector<test11>
> instead a single one)
> 2) I am not interested to prevent copy permanently, I just want to
> warn about the mistake done "unknowingly"
> Two solution so far I can think,
> 1) return a pointer / const pointer instead of reference/ const
> reference.
Thinking back, you're trying to prevent the user from doing what maybe
the user wholeheartedly intends. There is no reason. You help the user
to avoid copying by returning a reference. What the user does with it
is not your business any more.
Same with pointers.
> Yes, as you suggested, if test11 has overloaded operator then direct
> use of the class may be writing one more line to convert the pointer
> to reference and then use it.
> 2) marke the copy ctor explicit.
> Thus the code
> test11 t1 = t2.t(); wont work. One need to write either
> test11& t1 = t2.t(); => which is what I wanted usually.
> or test11 t1(t2.t()); => which shows user clearly wants a copy.
> I am seeking some advice "regarding" this kind of problem.
I think you're seeing a problem where there isn't any.
> [..]
Anyway, the whole thing is a matter of taste. I thought about that, as
I checked many programmer do this mistake, and while asked for the
reason the answer was, "I do it all the time!" , "I hadn't checked the
API documentation", "Oh! sorry for the mistake", or even "I don't know
all the details, it is your duty to correct it!".
Surely it is not valid for you as an user (as you are one of the main
trouble shooter in this newsgroup , others are surely Kai-Uwe Bux,
Frederick Gotham, Bart, Rolf Magnus, mlimber). I know that C++ relies
on programer to write a correct program (on contrary Java forces it.
Just for comparison check Java & C++ container model, and iterator
model) , but sometimes the later one is benificial.
Again, it is the question , to whom you are addressing! . "One size
does not fit all." True for program as well as programmer!
Thanks
Yes, that's so. Just like if you ride a bus, you trust the driver to
do the right thing, but you don't have the freedom to stop any time you
want or to go anywhere you want. When you drive yourself, you do have
the freedom, but you have to learn driving, you have to pass the exam,
you have to take more risks than a passenger in a bus...
Freedom doesn't come cheap. "Unknowingly" in this case to me is the
same as "purposely ignoring". Shouldn't be your problem.
> [..]
> Anyway, the whole thing is a matter of taste.
I do not agree. It's not. You give them a sophisticated tool (in the
form of a library with functions returning *references*). They do not
want or do not care to use it to its fullest extend. Who's to blame?
> I thought about that, as
> I checked many programmer do this mistake, and while asked for the
> reason the answer was, [..]
Here is the truth: if you strive to protect the users of your "C++"
library from making those mistakes, you will *inevitably* recreate Java
with all its troubles and problems and niceties and goodness. There is
no free cheese, except in a mouse trap.