Re: using const & in function prototypes
On Thu, 06 Nov 2008 19:40:00 -0500, Tommy <tommy767@gmail.com> wrote:
I think I am zooming on the "why" this is happening which is what I
need to continue and not leave this hanging with an non-understood
gremlin.
One of the functions is a recursive b-tree analyzer which is what I am
using for testing. The recursive VerifyPage() is calling Read(). Its
the only function it is calling as it traverses the tree calling
VerifyPage() for each left and right page.
The solution was to remove the &, keeping const was ok. So maybe what
& did was keep a local scope value persistent or something along those
lines.
Make sense?
I dunno. :) For the most part, the parameter types DWORD and const DWORD&
accept the same arguments.[*] It's only when you get to DWORD& (emphasis on
the non-constness) that things become different. There is a rule forbidding
the binding of temporary values to non-const references, which means that
you can't bind, say, an int to one, because that would require a conversion
to DWORD, creating a temporary, nor can you bind the result of a function
that returns a DWORD, because that value is also a temporary. Of course,
you wouldn't be able to bind a const DWORD to it, either.
[*] Interesting aside: DWORD and const DWORD are the same type for the
purposes of operator overloading. That is, this is forbidden and will cause
an error:
void f(DWORD x) {}
void f(const DWORD x) {}
Because of this, you can declare the function as:
void f(DWORD x);
and then define it as:
void f(const DWORD x) {}
and that way, your function parameters can be made const. This should be
done a lot more than it is.
BOOL TIndexFile::Verify(int &count)
{
TCriticalSectionGrabber grab(Mutex);
ReadRoot();
return VerifyPage(Root, count);
}
BOOL TIndexFile::VerifyPage(const TIndexPage &page, int &count)
{
...
for (DWORD i = 0; i <= page.Header.KeyCount; i++) {
TIndexPage tpage(KeyLen);
if (!page.Header.Child[i]) {
return FALSE;
}
Read(page.Header.Child[i], tpage);
if (tpage.Header.ParentIndex != page.Header.ThisIndex) {
return FALSE;
}
if (!VerifyPage(tpage, count)) {
return FALSE;
}
}
...
return TRUE;
}
When the Read() prototype uses const DWORD & for parameter 1, it
doesn't Verify. Incidentally, as a matter of state info, it failed at
recursive level 2.
Changing it to const DWORD or just DWORD, resolve it.
There is no clobbering, so I like to know why.
Based on what I wrote above, I don't get it, either. I would need to see
the Read function, which I don't think you've presented. Assuming the code
is correct, it could be compiler bug, but why it would wait for you to
recurse twice before appearing, I couldn't tell you.
Off hand, I would think that const & is more efficient, but it might
not apply here because of the recursive nature of VerifyPage().
For something like DWORD and really all the built-in types (DWORD is just
unsigned int), it's more efficient to pass by value than reference.
--
Doug Harrison
Visual C++ MVP