Re: Avoiding C++ Templates In Cipher Implementation

From: André Pönitz (poenitz_at_gmx.net)
Date: 06/11/03 

Date: 11 Jun 2003 09:51:02 GMT

In gnu.g++.help Daniel James <wastebasket@nospam.aaisp.org> wrote:
> You have various template classes (these are classes, not
> functions, right?) that are bound at compile time to
> specializations of the Cipher_RC6 template. What's the
> advantage of doing this over having separate classes called
> Cipher_RC6_128, Cipher_RC6_192, etc.?

Code re-use?

[And you could provide Cipher_RC6<N> which maps to the next better
algorithm etc and other 'cute' tricks]

> Either way, if an application needs to use RC6 with two
> different keylengths (we are talking about keylength, here,
> right?) you end up with two separate instantiations of the code
> in the executable.

Sure. But you have a decent chance that e.g. all loops are of fixed size
and the compiler can do a pretty good job on optimization on that.

> If, instead, you have a class Cipher_RC6 that takes a
> constructor argument (128, 192, etc.) that indicates the
> keylength, there will only be one copy of the code in the
> executable (with conditional branches to cope with the
> different handling of different keylengths).

But you would suddenly need dynamic data structure.

> That represents a considerable saving in program size for a very small
> (probably unmeasurable) increase in execution time.

First of all, I doubt the 'probably unmeasurable' as I've seen profiles of
other applications uniformly suggesting the contrary. Secondly, depending
on your code, execution time may matter.

>> Finally, as far as the argument of correctness goes, I could easily turn
>> the template arguments into run-time arguments, and the structure of the
>> code would hardly change.
>
> No, that's where problems start. If you need to use a cipher whose
> keylength you don't know until runtime you can't make use of the template
> resolution mechanism to select the correct cipher code at compile time
> (obviously).
>
> The following:
>
> int i = getKeyLength(); // from somewhere Cipher_RC6< 32, 20, i >
> cipher;
>
> won't compile, whereas:
>
> int i = getKeyLength(); // from somewhere Cipher_RC6 cipher(i);
>
> will.

And a toplevel

  switch (getKeyLength()) {
    case 128: Cipher_RC6<32, 20, 128>; break;
    case 192: Cipher_RC6<32, 20, 192>; break;
  }

certainly will compile, too.

Andre'

PS: F'up restricted to comp.lang.c++ 

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one.     (T. Jefferson or B. Franklin or both...)

Relevant Pages

  • Re: Avoiding C++ Templates In Cipher Implementation
    ... > specializations of the Cipher_RC6 template. ... No, not just keylength. ... Hmm...not sure if I can agree with the saves in execution time. ... achieved if they are known at compile time. ...
    (sci.crypt)
  • Re: Avoiding C++ Templates In Cipher Implementation
    ... first two template parameters as they're 32 and 20 in all three ... You have various template classes (these are classes, ... different keylengths (we are talking about keylength, here, ... cipher code at compile time. ...
    (sci.crypt)
  • Re: template related question
    ... > Is it possible to disable a method of a template class depending on ... > the typename at compile time? ... of the candidate template arguments. ...
    (comp.lang.cpp)
  • Re: [!! RANT !!] This is a hack at best (C4251)
    ... Micro$oft support for STL and standards in general is absolutely appaling. ... The built DLL exports the symbols, so I am not sure why the compiler issues the warnings. ... The function template is completely ignored and not even exported. ... I hope you can provide a fix as to how to get this to work (i.e. compile ...
    (microsoft.public.dotnet.languages.vc)
  • Re: creaping coupling......
    ... In C++ it would be trivial to break that source code dependency, ... When you compile a .java module, ... In Java and C# it's asserted at compile time. ...
    (comp.object)