Reference to void
in [C++]
|
From: Michael Walter on 29 Oct 2006 10:42 On Oct 29, 2:15 am, Gennaro Prota <geunnaro_pru...(a)yahoo.com> wrote: > On 28 Oct 2006 11:36:22 -0400, James Kanze wrote: > [...] > > Lock const v( mx ) ; > [...] > Hmm... how would that be different from > > Lock const( mx ); > > ? The Lock objects have potentially different lifetimes. In the former snippet, the Lock object lives until the end of the enclosing scope, whereas in the latter object, the lock is destroyed immediately after construction, defeating its very purpose (which was probably to implement a scoped locking guard a la boost::scoped_lock). Regards, Michael -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 29 Oct 2006 11:04 Francis Glassborow wrote: > In article <1162047140.568184.80310(a)b28g2000cwb.googlegroups.com>, James > Kanze <james.kanze(a)gmail.com> writes > >Yes, but for better or worse, this misnomer has established > >itself. In a similar way, people usually speak of T const* > >as a const pointer, although it is the pointed to that is > >const, and not the pointer. It's probably regrettable, but > >the usage is too well established to change. > No, no, no. The use of const reference is relatively harmless > because there is no real possibility of confusion in C++ where > a reference is not reseatable. However the issue with pointers > is completely different; a const pointer, a pointer to const > and a const pointer to const are different things and must not > be confused as all exist. I agree in theory, but I think realistically, the battle has been lost. -- James Kanze Gabi Software email: kanze.james(a)neuf.fr Conseils en informatique orient?e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34 -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 29 Oct 2006 11:03 Gennaro Prota wrote: > On 28 Oct 2006 11:36:22 -0400, James Kanze wrote: > >It's hypothetical code. Of course, in this case, I don't see > >much point in the void&; what does it buy us over simply: > > Lock const v( mx ) ; > >If instead of Lock, we used a function, and its return value, > >perhaps. But even then, we presumably know the return type, so > >there's no point in not naming it. (In fact, naming it means > >that if I happen to mistype the name, and hit the name of > >another function, which returns a different type, I get an error > >message; declaring it as void is less safe.) > >Interestingly, the example is, IMHO, an argument for anonymous > >variables. Supposing that Lock and mx mean what I think they > >do, he's had to invent a name which will never be used again in > >the function. > Hmm... how would that be different from > Lock const( mx ); > ? That's currently legal syntax; it creates a temporary, whose lifetime ends at the end of the full expression. An anonymous variable would behave exactly like any other variable, including with respect to lifetime, but it wouldn't have a name. The most obvious way of doing this is to use a reserved name, say _. You'd write the declaration with the name, but the compiler wouldn't enter that name in its symbol table, you couldn't use the name to refer to the variable later, but you could define additional variables with the same name in the same scope, e.g. if you needed two locks: Lock const _(mx1) ; Lock const _(mx2) ; The implementation could be something along the lines of the implementation of anonymous namespaces -- each time the compiler sees the name, it generates a new, unique, unnamable name in its place. > FWIW, and to keep your anti-obfuscation radar fit ;-), my SHA-1 > implementation has the following: > const sha1_loop /* loop */ ( state, block ); > Opinions/suggestions/insults? (I know that I could just use a > static function, but I'm not convinced that that is an > improvement) If you want to call a function, call a function. I'm not sure what this buys you -- you get two successive function calls in one statement (construtor and destructor), but I don't see any real advantage in this. Of course, if you are within a template, this structure would make shar1_loop a type parameter, rather than a non-type parameter of type void (*)(...). I suppose that there are cases where that would be an advantage, but even then, I think a classical traits class, with e.g. a static member function loop, would be more readable, so you would write: sha1::loop( state, block ) ; The const is also obfuscation, since there is really no moment that the object is const. (A const object doesn't become const until the constructor has finished, and looses its const-ness as soon as the destructor is invoked. Since all that is ever done with your object is to call the constructor, then the destructor, the object is effectively non-const.) -- James Kanze Gabi Software email: kanze.james(a)neuf.fr Conseils en informatique orient?e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34 -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Gennaro Prota on 29 Oct 2006 11:07 On 28 Oct 2006 21:33:35 -0400, Frederick Gotham wrote: >James Kanze: >> It's probably regrettable, but the usage is >> too well established to change. > > >I'm not afraid to go against the grain when it comes to well-established >wrongs. I'm absolutely with you. Analogously for "class template"/"template class" and "function template"/"template function". Another couple of couples of expressions often used without care. -- Gennaro Prota (To mail me, please remove any 'u' from the provided address) -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Greg Herlihy on 29 Oct 2006 17:09
Frederick Gotham wrote: > James Kanze: > > > Yes, but for better or worse, this misnomer has established > > itself. In a similar way, people usually speak of T const* as a > > const pointer, although it is the pointed to that is const, and > > not the pointer. > > > Not me. I always speak of either a "const pointer" or a "pointer to const". > > > > It's probably regrettable, but the usage is > > too well established to change. > > > I'm not afraid to go against the grain when it comes to well-established > wrongs. A const reference is no misnomer: int i; const int& iRef = i; iRef is clearly a "const reference" - and not a "reference to const" because the object iRef refers to, i, is not const. The const attribute in this example is purely an invention of - and applies only to - the iRef reference variable - thereby making iRef a const reference. Greg -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |