handle/reference?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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
 
Bonj said:
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)
Click to expand...

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
 
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
 
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.
Click to expand...

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.
Click to expand...

Indeed. Because they are copies.


Arnold the Aardvark
http://www.codeproject.com/cpp/garbage_collect.asp
 
Carl Daniel said:
[...] Passing them by const value is pointless [...]
Click to expand...

Except that it might prevent bugs
within the function.
-cd
Click to expand...

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers
 
Hendrik said:
Carl Daniel [VC++ MVP]
[...] Passing them by const value is pointless [...]
Click to expand...

Except that it might prevent bugs
within the function.
Click to expand...

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
 
Carl said:
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.
Click to expand...

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 said:
[...]
I don't do it myself, but it's crossed my mind once or twice. :)
Click to expand...

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.
Click to expand...

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
Click to expand...


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

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers
 
Doug Harrison said:
Yep, they declare the same function.
Click to expand...


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

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers
 
Hendrik said:
Dang, I didn't know that!
However, I think this would confuse
people. So I won't use it.
Click to expand...

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
 
Carl Daniel said:
[...]
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.
Click to expand...

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
Click to expand...

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers
 
Hendrik said:
Carl Daniel [VC++ MVP]
[...]
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.
Click to expand...

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.
Click to expand...

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
 
Carl Daniel said:
[...]
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.
Click to expand...

I see. Thanks.
-cd
Click to expand...

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

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