Reference to void
in [C++]
|
From: Gennaro Prota on 29 Oct 2006 17:11 On 29 Oct 2006 10:42:12 -0500, cppmods(a)netlab.cs.rpi.edu wrote: >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). You are right. I read this part of James' post 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. somehow "out of context", i.e. without paying attention to the specific mention of a Lock (I'm quite an abstract kind of guy :-)). In retrospect, were I considering the context or not, the implied difference was fairly obvious, so I guess I earned my nomination for the most stupid c.l.c++.m question of the year :-s -- 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: Gennaro Prota on 29 Oct 2006 23:29 On 26 Oct 2006 13:30:50 -0400, Joshua Lehrer wrote: > >James Kanze wrote: >> > In my mind, it makes sense. All types should be considered to inherit >> > (virtually) from void. >> >> What you're looking for isn't void, it's Object. In Java. >> >> Personally, I've never missed it in C++. >> > >No, what I'm looking for is the ability to bind a temporary to a const >reference to void and take advantage of the C++ rules that temporaries >will remain alive as long as the const reference bound to it. The goal is IMHO reasonable but the means you suggest (binding) takes advantage, so to speak, of a "side effect" of the binding construct (let me pass the terminology abuse). Anonymous automatic objects, as suggested by James, look to me like the right way to go, logically. And they are much less problematic from a language specification point of view. -- 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: Gennaro Prota on 29 Oct 2006 23:28 On 29 Oct 2006 11:03:40 -0500, James Kanze wrote: >> >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. Yep. That should have been obvious, as I said in reply to Michael Walter :-( >[...] > >> 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. Putting everything into a class (sha1_loop) was the first thing that came to my mind. I'm far from sure it is the best arrangement of the code. The goal anyway was to facilitate loop unrolling for the compiler; the sha_1_loop constructor looks (more or less) like this: sha1_loop( word_type( &state )[ 5 ], const word_type( &block )[ 16 ] ) : a( state[0] ), b( state[1] ), c( state[2] ), d( state[3] ), e( state[4] ) { std::copy( ... ); for( int i = 16; i < 80; ++i ) { w[ i ] = rotate_left< 1 >( w[i-3] ^ w[i-8] ^ w[i-14] ^ w[i-f] ); } // main computation loop_core< 0 >(); state[ 0 ] += a; state[ 1 ] += b; state[ 2 ] += c; state[ 3 ] += d; state[ 4 ] += e; } where the loop_core member is declared as template< int i > void loop_core(); and specialized to a no-op for i = 80. The reason why using a class was the first thing that came to mind is that I needed to keep a, b, c, d and e. >[...] > >The const is also obfuscation, since there is really no moment >that the object is const. And I hereby certify that your anti-obfuscation radar is in good shape :-) Actually the const isn't in my code, I added it in the post to avoid a non-relevant difference with the "Lock const( mx )" example (I even thought to put it on the right but I'll confess you... I'm not able to use that convention consistently, so I decided a while ago not to use it at all) -- 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: Gennaro Prota on 29 Oct 2006 23:30 On 27 Oct 2006 10:37:52 -0400, Lucian Radu Teodorescu wrote: >Indeed, this reference to void ideea doesn't help too much. Again, >let's take a piece of code: ><code> > >void f1() >{ > auto& obj = f(); > > // A lot of code folllows... >} > >void f2() >{ > void& obj = f(); > > // A lot of code folllows... >} > ></code> > >If you take the first look in f1() you don't know what happens to the >result of the function call. You may rush to say that obj will be >accessed in the code that follows. But this is not necessarly the >intent. One can only want to extend the scope of the object returned by >function call. In that case I'd want a syntax which didn't involve any name. Something like auto = f(); or similar (the "auto" here isn't to deduce type; it just signals that you want automatic storage duration). -- 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: Gabriel Dos Reis on 30 Oct 2006 00:13
"Greg Herlihy" <greghe(a)pacbell.net> writes: [...] | 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. There is nothing such as "object iRef", because a reference is not an object. -- Gabriel Dos Reis gdr(a)integrable-solutions.net [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |