Re: Reference to void
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! ]