const or not const, that's the question here! :-)

[Adem24]

The compiler which I have to use in a project doesn't like
the following construct. It says: 'bitset' : invalid template argument.
It means that it wants only a static-like const N as a template argument,
ie. it doesn't accept a const variable that was initialized
from an auto variable (here i), for passing it as a template
argument to bitset<n>.

Is this a compiler limitation or is my code not standard conform?
Can you think of any workaround construct to achieve this
or an alternate functionality with such a compiler?

Of course if I change the line to read for example
const size_t N = 1U << 16;
then it compiles ok. But I need to loop 22 times here...

#include <bitset>
void f()
{
for (size_t i = 1; i <= 22; ++i)
{
const size_t N = 1U << i;
bitset<N> bv;

bv.set(7);
//...
}
}

 

[Kai-Uwe Bux]

The compiler which I have to use in a project doesn't like
the following construct. It says: 'bitset' : invalid template argument.
It means that it wants only a static-like const N as a template argument,
ie. it doesn't accept a const variable that was initialized
from an auto variable (here i), for passing it as a template
argument to bitset<n>.

Is this a compiler limitation or is my code not standard conform?
Can you think of any workaround construct to achieve this
or an alternate functionality with such a compiler?

Of course if I change the line to read for example
const size_t N = 1U << 16;
then it compiles ok. But I need to loop 22 times here...

#include <bitset>
void f()
{
for (size_t i = 1; i <= 22; ++i)
{
const size_t N = 1U << i;
bitset<N> bv;

Your code is wrong. This N is not a compile time constant. Templates only
work with those.

You might want to have a look into dynamic_bitset from boost or

bv.set(7);
//...
}
}

Best

Kai-Uwe Bux

 

[Eric Pruneau]

The compiler which I have to use in a project doesn't like
the following construct. It says: 'bitset' : invalid template argument.
It means that it wants only a static-like const N as a template argument,
ie. it doesn't accept a const variable that was initialized
from an auto variable (here i), for passing it as a template
argument to bitset<n>.

Is this a compiler limitation or is my code not standard conform?
Can you think of any workaround construct to achieve this
or an alternate functionality with such a compiler?

Of course if I change the line to read for example
const size_t N = 1U << 16;
then it compiles ok. But I need to loop 22 times here...

#include <bitset>
void f()
{
for (size_t i = 1; i <= 22; ++i)
{
const size_t N = 1U << i;
bitset<N> bv;

bv.set(7);
//...
}
}

Your code cannot compile. N must be a compile time evaluatable constant. In
your case, N is constant but unknow to the compiler at compile time because
of i.

 

[kwikius]

Your code is wrong. This N is not a compile time constant. Templates only
work with those.

You could probably set this up fairly simply to use compile time recursion.
Use a functor templated on N which calls N-1 and specialize it for zero (or
other way up ) case etc...

regards
Andy Little

 

[Kai-Uwe Bux]

You could probably set this up fairly simply to use compile time
recursion. Use a functor templated on N which calls N-1 and specialize it
for zero (or other way up ) case etc...

Yes one could do that. But why? You end up with some monstrous incantation
that will fill your screen with book size error messages if you get a tiny
detail wrong; and for which gain? The algorithms underlying bitset<N> are
mostly just bit fiddling iterated over a vector of unsigned long (int?)
anyway. I would be rather surprised if it matters performancewise whether
the length of that buffer is fixed at compile time or at run time.

I love templates, I really do; but in a case like this, I think they would
make the code worse (e.g., harder to maintain and change).


Best

Kai-Uwe Bux

 

[kwikius]

Yes one could do that. But why?

Only one way to find out....

<... usual inertia elided ...>

regards
Andy Little

 

[Andy Little]

Only one way to find out....

<... usual inertia elided ...>

Apologies That was a bit fierce, however using compile time loop
unrolling is a useful technique, and the OP was asking why it wasnt
didnt seem possible. I was merely pointing out that it is possible. In
some cases the compiler may do loop unrolling for you, but doing it
explicitly using compile time recursion is one less uncertainty/ layer
of complexity for the optimiser.

Interestingly, looking at std::bitset, Its kind of a weird hybrid
because the length is fixed but many ops are runtime.

As an example one could add a bitset.flip<Pos>() function to accompany
bitset.flip(pos). The first version being again easier to optimise and
all the information re the op is available at compile time unlike the
runtime parameter, and very usefully, the range can be checked at
compile time too, so there is no need of a runtime check and possible
exception, unlike appears to be the case in the runtime flip (which
throws an exception on out of range). The same applies to many (probably
nearly all) ops in bitset AFAICS.

regards
Andy Lttle

 

[Frank Birbacher]

Hi!

You could probably set this up fairly simply to use compile time recursion.
Use a functor templated on N which calls N-1 and specialize it for zero (or
other way up ) case etc...

You could probably fix this fairly simple by using the same size in each
loop:

const size_t maxlen = 22;
bitset<1 << maxlen> bv;
for (size_t i = 1; i <= maxlen; ++i)
{
const size_t N = 1U << i;

bv.set(7);
//...
}

Frank

 

[Bo Persson]

Apologies That was a bit fierce, however using compile time loop
unrolling is a useful technique, and the OP was asking why it wasnt
didnt seem possible. I was merely pointing out that it is possible.
In some cases the compiler may do loop unrolling for you, but doing
it explicitly using compile time recursion is one less uncertainty/
layer of complexity for the optimiser.

Interestingly, looking at std::bitset, Its kind of a weird hybrid
because the length is fixed but many ops are runtime.

As an example one could add a bitset.flip<Pos>() function to
accompany bitset.flip(pos). The first version being again easier
to optimise and all the information re the op is available at
compile time unlike the runtime parameter, and very usefully, the
range can be checked at compile time too, so there is no need of a
runtime check and possible exception, unlike appears to be the case
in the runtime flip (which throws an exception on out of range).
The same applies to many (probably nearly all) ops in bitset AFAICS.

Any decent optimizer can do that anyway, when pos is a compile time
constant. That saves you from modifying the application code when that
condition changes.


Bo Persson