On Jul 20, 5:37 am, Jorgen Grahn <grahn+n...@[EMAIL PROTECTED]
> wrote:
> On Tue, 8 Jul 2008 20:28:28 CST, Tony Delroy
<tony_in_da...@[EMAIL PROTECTED]
> wrote:
> > On Jul 3, 5:27 pm, "Jim Langston" <tazmas...@[EMAIL PROTECTED]
> wrote:
> >> "Martin T." <0xCDCDC...@[EMAIL PROTECTED]
> wrote in message
> >> > When writing new C++ code, what is the point of passing any (input)
> >> > parameter by value when passing by const reference will just work
as
> >> > well? (Even and especially PODs, I would not do it with a complex
type
> >> > anyway.)
> >> > (Given that in 90% of the code you will never want to modify the
> >> > parameter anyway.)
>
> > typedef int File_Handle;
>
> > void fn(File_Handle fh); // (A) OR
> > void fn(const File_Handle& fh); // (B) OR
> > void fn(Traits<File_Handle>::Const_Param fh); // (C) ??
>
> > I would argue that (A) presents a maintenance issue - particularly if
> > the typedef is provided by a library header. Consider a change to a
> > "class File_Handler" in which copy construction and/or destruction
> > have unwanted side effects (e.g. badly implemented RAII), or some
> > large data is added (cache, buffer, ...?). The client code (A) might
> > keep compiling but not run as intended.
>
> Good point, but unfortunate example. The word "handle" in
> "File_Handle" is intended to signal to the user "see this as some kind
> of pointer or reference to a File". I think most people would expect
> to be able to handle it as if it was a void *, or an index into some
> array not available to the programmer.
>
> /Jorgen
Quite so, and in general real IT references to "file handles" serve
this purpose with respect to OS-managed data. Still, consider
possible layering of convenience functions over this abstraction: a
programmer might want to "enrich" these handles with a class to, for
example, open a file and store the file handle, ensure the file handle
was closed in the destructor, sup****t OO-style operations etc.. The
merits can be argued, but experience shows such cl***** do often get
written, and it's not unlikely the class would be named after the
handle abstraction it wraps. You obviously understand the issues, but
for the benefit of others: the danger in this case is only some
unintended file opens and closes and tem****ary use of an additional O/
S file handle resource (of which there are typically limited numbers),
but in some cases (e.g. when locks are involved), worse things like
deadlocks could occur....
Tony
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
