Re: using const & in function prototypes
Doug Harrison [MVP] wrote:
Now, I would naturally assume that this would be a transparent
difference in OP codes and that the end result is the same.
Where is this presumption flawed?
Did you compile with or without optimizing? It can definitely make a
difference here. The code emitted for the second function is quite literal
and goes through the extra level of indirection implicit to using a
reference. The optimizer can remove that indirection in many cases. That
said, small types like DWORD should be passed by value instead of const
reference, and funcX would be preferred.
In this case Doug, the isolated test code was compiled under debug
with all optimization off. I have yet got to a point of testing
release code with the VC6 "porting" to VC8.
Over the years, as I reviewed, changed, fixed, cleaned up the
predominately original pure C code, I was getting into a "habit" of
using const & for objects and also small types if for anything else,
"force" a compiler syntax cleanup.
In my porting from VC6 to VC8 for this particular ISAM/B-TREE class
library, one of the long time planned design changes was to make it a
64 bit file I/O library, e.g., utilize the high parts of the file
positions of SetFilePointer and its Win32 API "friends" sisters functions.
So I have a new SS64LIB.H/CPP wrapper utility library:
#ifndef __SS64LIB_H
#define __SS64LIB_H
#ifndef _WINDOWS_
#include <windows.h>
#endif
//#define SUPPORT_FILEIO_64BIT
#ifdef SUPPORT_FILEIO_64BIT
# define TINT INT64
# define TWORD QWORD
# define TFILESIZE INT64
#else
# define TINT DWORD
# define TWORD DWORD
# define TFILESIZE DWORD
#endif
TINT ssFileSeek(HANDLE hf, TINT distance, WORD MoveMethod);
TINT ssFileEnd(HANDLE hf);
TINT ssFilePos(HANDLE hf);
BOOL ssFileRewind(HANDLE hf);
BOOL ssFileLock(HANDLE hf, TINT Offset, TINT nBytes);
BOOL ssFileUnlock(HANDLE hf, TINT Offset, TINT nBytes);
TFILESIZE ssFileSize(HANDLE hf);
#endif // __SS64LIB_H
and the btree class library was changed accordingly, where for
example, from:
BOOL TIndexFile::AddKeys(DWORD ref);
void TIndexFile::Read(DWORD index, TIndexPage &page)
it would be changed to
include "ss64lib.h"
...
BOOL TIndexFile::AddKeys(const TINT &ref);
void TIndexFile::Read(const TINT &index, TIndexPage &page)
So I was testing for functional compatibility with the preprocessing
SUPPORT_FILEIO_64BIT undefined.
The difference in code was the prototyping as described. The very few
type casting warnings in the function block code the compiler picked
up, was also cleaned up appropriately.
With trial & error, I just found the one function that causes the
incompatibility.
void TIndexFile::Read(const TINT &index, TIndexPage &page)
{
ReadPartPage(index, &page.Header, 0, sizeof(page.Header));
ReadPartPage(index, page.KeyData, sizeof(page.Header), KeyDataSize);
}
and ReadPagePage is part of another inherited class:
BOOL TDataFile::ReadPartPage(const TINT &index,
void *data,
const DWORD & offset,
DWORD size)
{
if (index == 0 || index >= ssFileSize(f)) {
return FALSE;
}
TINT n = ReadAt(SeekPos(index, offset), data, size);
if (n < size) {
return FALSE;
}
return TRUE;
}
Changing the TIndexFile::Read() to back to its original prototype
(removing the const &):
void TIndexFile::Read(TINT index, TIndexPage &page)
resolved it.
I just noticed the type conflict with DWORD size and TINT n. That
should be a TINT n. Don't know if that should case anything. I would
expect the SUPPORT_FILEIO_64BIT compile would pick that type case
difference.
I'm going to see now how the SeekPos() member function might be
affecting this:
TINT TDataFile::SeekPos(const TINT & index, const DWORD & offset)
{
return index*PageSize + offset;
}
I guess overall, if this was compiled for the INT64 casting
(SUPPORT_FILEIO_64BIT defined), it probably would work because it
wouldn't be a simple type? I guess I will cross that bridge soon
enough. :-)
--