std::bitset Question

[MikeCopeland]

Is there a way to, in a single assignment, set multiple values in a
std::bitset? For example, I must use 4 "set" calls to establish several
values, but I'd like to do this with a single call if possible. e.g.

bitset<100> wantedRecs;
wantedRecs.reset(); // establish basic values
wantedRecs.set(1);
wantedRecs.set(2);
wantedRecs.set(3);
wantedRecs.set(8);

Please advise. TIA



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[Paavo Helde]

MikeCopeland <mrc...@cox.net> wrote in
news:MPG.2e875ea3f...@news.eternal-september.org:

> Is there a way to, in a single assignment, set multiple values in
> a
> std::bitset? For example, I must use 4 "set" calls to establish
> several values, but I'd like to do this with a single call if
> possible. e.g.
>
> bitset<100> wantedRecs;
> wantedRecs.reset(); // establish basic values
> wantedRecs.set(1);
> wantedRecs.set(2);
> wantedRecs.set(3);
> wantedRecs.set(8);
>

It appears you can only set all needed values together, e.g.

wantedRecs = std::bitset<100>("100001110");

or

wantedRecs = (1ul<<1) | (1ul<<2) | (1ul<<3) | (1ul<<8);

The latter method can be used only if all the bits you want to set can be
expressed in an unsigned long.

hth
Paavo

[Jorgen Grahn]

On Sat, 2014-09-20, MikeCopeland wrote:
> Is there a way to, in a single assignment, set multiple values in a
> std::bitset? For example, I must use 4 "set" calls to establish several
> values, but I'd like to do this with a single call if possible. e.g.
>
> bitset<100> wantedRecs;
> wantedRecs.reset(); // establish basic values
> wantedRecs.set(1);
> wantedRecs.set(2);
> wantedRecs.set(3);
> wantedRecs.set(8);

wantedRecs |= set_of_1_2_3_and_8;

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Juha Nieminen]

Paavo Helde <myfir...@osa.pri.ee> wrote:
> wantedRecs = (1ul<<1) | (1ul<<2) | (1ul<<3) | (1ul<<8);

How about simply: wantedRecs = 0b100001110;

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Paavo Helde]

Juha Nieminen <nos...@thanks.invalid> wrote in news:lvmbub$vue$1
@adenine.netfront.net:

> Paavo Helde <myfir...@osa.pri.ee> wrote:
>> wantedRecs = (1ul<<1) | (1ul<<2) | (1ul<<3) | (1ul<<8);
>
> How about simply: wantedRecs = 0b100001110;

Yes, that's how it should work in an ideal world. However, the binary
literals appear in the C++14 standard, which is just about to be released.
So it will probably take some years before all major C++ vendors have
upgraded their compilers to support them.

Cheers
Paavo

[Norbert_Paul]

Then how about something like
#define PMBINARY(i) ((i % 10 ? 1ul : 0ul) | ((i/10) % 10 ? 2ul : 0ul) | ((i/100) % 10 ? 4ul : 0ul) | ...etc... )
?
Wouldn't then
PMBINARY(101)
give 5?

> Cheers
> Paavo

Cheers
Norbert

Note. "PM" stands for "Poor man's".

[Paavo Helde]

Norbert_Paul <norbertpau...@yahoo.com> wrote in
news:lvmpsi$743$1...@dont-email.me:

To be honest, this solution looks worse than the problem. It does not
scale up over 9 or 19 bits. It uses a convoluted convention and performs
unneeded calculations. And why is it a macro?

Actually, none of the solutions so far have addressed the main problem in
the OP's code: usage of magic constants. In the real code it should look
something like this instead:

enum FooBarFlag {
featureFoo = (1ul<<1),
featureBar = (1ul<<2),
adjustBaz = (1ul<<3),
// ...
featureQux = (1ul<<8),
// ...
};

FooBarFlag operator|(FooBarFlag a, FooBarFlag b);

// ...

wantedRecs |= (featureFoo | featureBar | adjustBaz | featureQux);

Cheers
Paavo

[Juha Nieminen]

Paavo Helde <myfir...@osa.pri.ee> wrote:
> Yes, that's how it should work in an ideal world. However, the binary
> literals appear in the C++14 standard, which is just about to be released.
> So it will probably take some years before all major C++ vendors have
> upgraded their compilers to support them.

C++14 is already out. Which vendors do not support it?

[Paavo Helde]

Juha Nieminen <nos...@thanks.invalid> wrote in

news:lvos75$l02$1...@adenine.netfront.net:

> C++14 is already out. Which vendors do not support it?

You can guess three times ;-) And yes, that's the one what OP is using
(although I hope he has moved forward from MSVC6 by now).

Cheers, Paavo

[CHIN Dihedral]

Are you joking about the disabled
fake hash table in C++?

Anyway, a file directory
system is not so hard to be developed in the unix-linux part with
a powerful hash table lib and iterators to travel any directory
without the old recursion methods.

[MikeCopeland]

Ahhh, you've been keeping track...that's scary... 8<}}
Yes, after much prompting (pressure) from this group, I have in fact upgraded my compiler...TWICE! I converted to MSVS10, and recently have been using MSVS13.
(I trust that's a bit more "with it", and I hope my problems are more realistic...)

[Paavo Helde]

MikeCopeland <mrc...@cox.net> wrote in
news:MPG.2e8a931db...@news.eternal-september.org:

>> Juha Nieminen <nos...@thanks.invalid> wrote in
>> news:lvos75$l02$1...@adenine.netfront.net:
>>
>> > C++14 is already out. Which vendors do not support it?
>>
>> You can guess three times ;-) And yes, that's the one what OP is
>> using (although I hope he has moved forward from MSVC6 by now).
>
> Ahhh, you've been keeping track...that's scary... 8<}}
> Yes, after much prompting (pressure) from this group, I have in
> fact upgraded my compiler...TWICE! I converted to MSVS10, and
> recently have been using MSVS13. (I trust that's a bit more "with
> it", and I hope my problems are more realistic...)

Good for you! You will hopefully get binary literals with MSVS15 or such!

Cheers
Paavo