handle/reference?

[Bonj]

Specifically, is there any difference between usin

void MyFunction(const HANDLE myhandle

an

void MyFunction(const HANDLE& myhandleref

??
is the latter likely to cause problems (such as I have experienced with HANDLE pointers used in this way

[Carl Daniel [VC++ MVP]]

Bonj wrote:

Specifically, is there any difference between using

void MyFunction(const HANDLE myhandle)

and

void MyFunction(const HANDLE& myhandleref)

???
is the latter likely to cause problems (such as I have experienced
with HANDLE pointers used in this way)

Any function will cause problems when used incorrectly. Reference and
pointers are no exception. If you pass a handle by reference, you're
letting the called function change the handle value. If you pass it by
const reference or const, you're inhibiting such changes.

HANDLEs are value types - they should generally be passed by value, not
const, not reference, not pointer. Treat them as you would an int. Passing
them by reference just slows the code down, since you're adding a level of
indirection. Passing them by const value is pointless since changes within
the function can't "escape" anyway.

void MyFunction(HANDLE mh)

-cd

[Bonj]

Right, thanks very muc
It's the 'level of indirection' thing I'm failing to consider when designing the code structure, but that's cleared it up

[Arnold the Aardvark]

> HANDLEs are value types - they should generally be passed by value, not

const, not reference, not pointer. Treat them as you would an int.
Passing them by reference just slows the code down, since you're adding a
level of indirection.
To clarify what you've said:

It rather depends on how expensive it is to copy the object
you are passing, since you are in fact passing a copy. HANDLE is
likely to be pretty small - an int or similar - I can't remember.
In general, passing a const reference to a larger object is more
efficient.
Passing them by const value is pointless since changes
within the function can't "escape" anyway.

Indeed. Because they are copies.
Arnold the Aardvark
http://www.codeproject.com/cpp/garbage_collect.asp

[Hendrik Schober]

Carl Daniel [VC++ MVP] <cp*****************************@mvps.org.nospam > wrote:

[...] Passing them by const value is pointless [...]
Except that it might prevent bugs
within the function.
-cd

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Carl Daniel [VC++ MVP]]

Hendrik Schober wrote:

Carl Daniel [VC++ MVP]
<cp*****************************@mvps.org.nospam > wrote:

[...] Passing them by const value is pointless [...]

Except that it might prevent bugs
within the function.

Sure. It'll make it illegal to assign to or otherwise modify the parameter,
so if you accidentally wrote the formal parameter name instead of some other
name on the left side of an assignment (etc), then the compiler would flag
it as an error. Still, I've never seen a coding guideline that suggested
that function parameters be const value types, but there's surely someone
out there using them that way for that reason.

-cd

[Doug Harrison [MVP]]

Carl Daniel [VC++ MVP] wrote:

Sure. It'll make it illegal to assign to or otherwise modify the parameter,
so if you accidentally wrote the formal parameter name instead of some other
name on the left side of an assignment (etc), then the compiler would flag
it as an error. Still, I've never seen a coding guideline that suggested
that function parameters be const value types, but there's surely someone
out there using them that way for that reason.

I don't do it myself, but it's crossed my mind once or twice. :) I think
it's more justifiable than many guidelines that are commonly recommended. I
mean, if I have a local variable that I initialize in its declaration, and
that variable is never thereafter modified, I like to declare it const. It
seems odd that function parameters don't rate the same treatment, but no one
teaches it, and it seems odd and strangely wordy to practice it. That said,
it's merely an implementation detail to the function caller. It can be
hidden, since these declarations can be used interchangeably:

void f(int); // In header
void f(const int); // In source

--
Doug Harrison
Microsoft MVP - Visual C++

[Hendrik Schober]

Doug Harrison [MVP] <ds*@mvps.org> wrote:

[...]
I don't do it myself, but it's crossed my mind once or twice. :)
I have done it for a while. I stopped for
the reason given below.
I think
it's more justifiable than many guidelines that are commonly recommended. I
mean, if I have a local variable that I initialize in its declaration, and
that variable is never thereafter modified, I like to declare it const.
Good. It's not only me. :)
I wonder why this is done by so few. For
me it does catch errors at compile-time
that would go unnoticed otherwise.
It
seems odd that function parameters don't rate the same treatment, but no one
teaches it, and it seems odd and strangely wordy to practice it. That said,
it's merely an implementation detail to the function caller. It can be
hidden, since these declarations can be used interchangeably:

void f(int); // In header
void f(const int); // In source

Are you sure? I stopped doing this because I
found myself changing headers when suddenly
I needed some parameter to not to be 'const'.
And I considered changing headers because of
something that's an implementation detail a
bad thing.

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Doug Harrison [MVP]]

Hendrik Schober wrote:

these declarations can be used interchangeably:

void f(int); // In header
void f(const int); // In source

Are you sure?

Yep, they declare the same function.

--
Doug Harrison
Microsoft MVP - Visual C++

[Hendrik Schober]

Doug Harrison [MVP] <ds*@mvps.org> wrote:

Hendrik Schober wrote:

these declarations can be used interchangeably:

void f(int); // In header
void f(const int); // In source

Are you sure?

Yep, they declare the same function.

Dang, I didn't know that!
However, I think this would confuse
people. So I won't use it.

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Carl Daniel [VC++ MVP]]

Hendrik Schober wrote:

Doug Harrison [MVP] <ds*@mvps.org> wrote:

Yep, they declare the same function.

Dang, I didn't know that!
However, I think this would confuse
people. So I won't use it.

FYI 8.3.5/3:

All declarations for a function with a given parameter list shall agree
exactly both in the type of the value returned and in the number and type of
parameters; the presence or absence of the ellipsis is considered part of
the function type.
....
After producing the list of parameter types, several transformations take
place upon these types to determine the function type. Any cv-qualifier
modifying a parameter type is deleted. [Example: the type void(*)(const int)
becomes void(*)(int) -end example] Such cv-qualifiers affect only the
definition of the parameter within the body of the function; they do not
affect the function type.

-cd

[Hendrik Schober]

Carl Daniel [VC++ MVP] <cp*****************************@mvps.org.nospam > wrote:

[...]
FYI 8.3.5/3:

All declarations for a function with a given parameter list shall agree
exactly both in the type of the value returned and in the number and type of
parameters; the presence or absence of the ellipsis is considered part of
the function type.
...
After producing the list of parameter types, several transformations take
place upon these types to determine the function type. Any cv-qualifier
modifying a parameter type is deleted. [Example: the type void(*)(const int)
becomes void(*)(int) -end example] Such cv-qualifiers affect only the
definition of the parameter within the body of the function; they do not
affect the function type.
Mhmm.
In general, I don't pay much attention
to this legal stuff -- it goes far over
my head anyway. However, now that you
cited this: How does this say anything
about when it is reference or pointer
types?
There cv qualifier _are_ important.
-cd

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

[Carl Daniel [VC++ MVP]]

Hendrik Schober wrote:

Carl Daniel [VC++ MVP]
<cp*****************************@mvps.org.nospam > wrote:

[...]
FYI 8.3.5/3:

All declarations for a function with a given parameter list shall
agree exactly both in the type of the value returned and in the
number and type of parameters; the presence or absence of the
ellipsis is considered part of the function type.
...
After producing the list of parameter types, several transformations
take place upon these types to determine the function type. Any
cv-qualifier modifying a parameter type is deleted. [Example: the
type void(*)(const int) becomes void(*)(int) -end example] Such
cv-qualifiers affect only the definition of the parameter within the
body of the function; they do not affect the function type.

Mhmm.
In general, I don't pay much attention
to this legal stuff -- it goes far over
my head anyway. However, now that you
cited this: How does this say anything
about when it is reference or pointer
types?
There cv qualifier _are_ important.

There the cv-qualifiers are not top level.

int const - top level CV
const int& - not top level CV (applies to int, not int&)
int * const - top level CV
const int * - not top level CV (applies to int, not int*)

Where the standard speaks of "cv-qualifiers modifying a parameter type" they
mean top-level cv-qualifiers. The 'const' in 'const int &' is modifying a
type that's embedded inside the type of the parameter, so the rule doesn't
apply.

-cd

[Hendrik Schober]

Carl Daniel [VC++ MVP] <cp*****************************@mvps.org.nospam > wrote:

[...]
int const - top level CV
const int& - not top level CV (applies to int, not int&)
int * const - top level CV
const int * - not top level CV (applies to int, not int*)

Where the standard speaks of "cv-qualifiers modifying a parameter type" they
mean top-level cv-qualifiers. The 'const' in 'const int &' is modifying a
type that's embedded inside the type of the parameter, so the rule doesn't
apply.
I see. Thanks.
-cd

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers