Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #13194 > unrolled thread

Coding Style Question - Is there any sane reason for doing this?

Back to article view | Back to comp.lang.c++

Contents

  Coding Style Question - Is there any sane reason for doing this? BCFD36 <bcfd36@aol.com> - 2012-01-09 17:11 -0800
    Re: Coding Style Question - Is there any sane reason for doing this? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-10 02:23 +0100
      Re: Coding Style Question - Is there any sane reason for doing this? legalize+jeeves@mail.xmission.com (Richard) - 2012-01-10 06:05 +0000
        Re: Coding Style Question - Is there any sane reason for doing this? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-10 07:12 +0100
          Re: Coding Style Question - Is there any sane reason for doing this? BCFD36 <bcfd36@cruzio.com> - 2012-01-09 22:35 -0800
        Re: Coding Style Question - Is there any sane reason for doing this? Gareth Owen <gwowen@gmail.com> - 2012-01-10 06:58 +0000
      Re: Coding Style Question - Is there any sane reason for doing this? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-10 21:58 +0000
        Re: Coding Style Question - Is there any sane reason for doing this? David Dyer-Bennet <dd-b@dd-b.net> - 2012-01-10 16:46 -0600
        Re: Coding Style Question - Is there any sane reason for doing this? jt@toerring.de (Jens Thoms Toerring) - 2012-01-10 23:41 +0000
          Re: Coding Style Question - Is there any sane reason for doing this? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-11 00:19 +0000
            Re: Coding Style Question - Is there any sane reason for doing this? "MikeWhy" <boat042-nospam@yahoo.com> - 2012-01-10 21:53 -0600
        Re: Coding Style Question - Is there any sane reason for doing this? Juha Nieminen <nospam@thanks.invalid> - 2012-01-11 15:14 +0000
          Re: Coding Style Question - Is there any sane reason for doing this? Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-11 11:46 -0500
    Re: Coding Style Question - Is there any sane reason for doing this? Ian Collins <ian-news@hotmail.com> - 2012-01-10 14:30 +1300
      Re: Coding Style Question - Is there any sane reason for doing this? BCFD36 <bcfd36@cruzio.com> - 2012-01-09 21:32 -0800
        Re: Coding Style Question - Is there any sane reason for doing this? Paavo Helde <myfirstname@osa.pri.ee> - 2012-01-10 01:01 -0600
          Re: Coding Style Question - Is there any sane reason for doing this? BCFD36 <bcfd36@cruzio.com> - 2012-01-09 23:11 -0800
            Re: Coding Style Question - Is there any sane reason for doing this? yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2012-01-11 10:23 +0000
              Re: Coding Style Question - Is there any sane reason for doing this? yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2012-01-11 10:37 +0000
          Re: Coding Style Question - Is there any sane reason for doing this? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-10 00:30 -0800
            Re: Coding Style Question - Is there any sane reason for doing this? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-01-10 16:31 +0100
              Re: Coding Style Question - Is there any sane reason for doing this? scott@slp53.sl.home (Scott Lurndal) - 2012-01-10 17:14 +0000
                Re: Coding Style Question - Is there any sane reason for doing this? Victor Bazarov <v.bazarov@comcast.invalid> - 2012-01-10 15:11 -0500
                  Re: Coding Style Question - Is there any sane reason for doing this? Richard <rgrdev_@gmail.com> - 2012-01-10 21:45 +0100
                    Re: Coding Style Question - Is there any sane reason for doing this? hanukas <jukka@liimatta.org> - 2012-01-11 00:04 -0800
                      Re: Coding Style Question - Is there any sane reason for doing this? hanukas <jukka@liimatta.org> - 2012-01-11 00:15 -0800
                  Re: Coding Style Question - Is there any sane reason for doing this? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-10 21:51 +0000
                  Re: Coding Style Question - Is there any sane reason for doing this? "Bill Davy" <Bill@SynectixLtd.com> - 2012-01-11 08:30 +0000
                    Re: Coding Style Question - Is there any sane reason for doing this? "Fred Zwarts \(KVI\)" <F.Zwarts@KVI.nl> - 2012-01-11 09:40 +0100
                      Re: Coding Style Question - Is there any sane reason for doing this? hanukas <jukka@liimatta.org> - 2012-01-11 06:50 -0800
                  Re: Coding Style Question - Is there any sane reason for doing this? scott@slp53.sl.home (Scott Lurndal) - 2012-01-11 17:28 +0000
                    Re: Coding Style Question - Is there any sane reason for doing this? David Dyer-Bennet <dd-b@dd-b.net> - 2012-01-11 13:28 -0600
              Re: Coding Style Question - Is there any sane reason for doing this? jgk@panix.com (Joe keane) - 2012-01-11 17:51 +0000
              Re: Coding Style Question - Is there any sane reason for doing this? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-12 05:40 -0800
                Re: Coding Style Question - Is there any sane reason for doing this? BCFD36 <bcfd36@cruzio.com> - 2012-01-12 20:42 -0800
            Re: Coding Style Question - Is there any sane reason for doing this? hanukas <jukka@liimatta.org> - 2012-01-10 23:50 -0800

Page 1 of 2  [1] 2  Next page →

#13194 — Coding Style Question - Is there any sane reason for doing this?

I am working on a piece of legacy code that has many, shall we say,
strange things. This one, as J.K. Anderson (classics Prof at UC
Berkeley) used to say, "baffles me". It has the following statement in
the code:

const unsigned int WAKEUP_MASK = (1 << 1) ;

Is there any reason for doing this,  other than to make the code even
more obscure?

D. Scruggs

[toc] | [next] | [standalone]

#13195

On 10.01.2012 02:11, BCFD36 wrote:
> I am working on a piece of legacy code that has many, shall we say,
> strange things. This one, as J.K. Anderson (classics Prof at UC
> Berkeley) used to say, "baffles me". It has the following statement in
> the code:
>
> const unsigned int WAKEUP_MASK = (1<<  1) ;
>
> Is there any reason for doing this,  other than to make the code even
> more obscure?

No, there is no good reason: one should in general reserve ALL UPPERCASE 
identifiers for macros.

But they should be used for macros.

Also, there is no reason for the keyword `int`.

So that's also quite baffling: is the author, like, a compulsive typist 
who just wants to type as much as possible, regardless of lack of meaning?

Anyway, the almost OK part of that code, `1 << 1`, explicitly tells you 
that this is a single bit bitmask, and which bit is set; in the context 
of the rest it's bafflingly clear & communicative. It's generally good 
to be explicit in code, and let the compiler handle the translation to 
machine code, rather than doing it oneself and writing e.g. 0x0002. The 
latter is just a number which the reader then must decompile. However, 
for the general case `1 << n` runs the risk of Undefined Behavior, since 
it is a signed expression. It should be `1u << n`.


Cheers & hth.,

- Alf

[toc] | [prev] | [next] | [standalone]

#13200

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code
<jeg3u2$fen$1@dont-email.me> thusly:

>No, there is no good reason: one should in general reserve ALL UPPERCASE 
>identifiers for macros.
>
>But they should be used for macros.

I've seen people defining constant quantities like this in upper case
because they are used to only being able to define constants with
macros and they've equated the semantic category of "constants" to
"macros" in their mind.

I could go either way about it.

I prefer the advice given in Coding Standard 0: Don't Sweat the Small
Stuff, from "C++ Coding Standards" by Alexandrescue and Sutter.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 version available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

[toc] | [prev] | [next] | [standalone]

#13201

On 10.01.2012 07:05, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> "Alf P. Steinbach"<alf.p.steinbach+usenet@gmail.com>  spake the secret code
> <jeg3u2$fen$1@dont-email.me>  thusly:
>
>> No, there is no good reason: one should in general reserve ALL UPPERCASE
>> identifiers for macros.
>>
>> But they should be used for macros.
>
> I've seen people defining constant quantities like this in upper case
> because they are used to only being able to define constants with
> macros and they've equated the semantic category of "constants" to
> "macros" in their mind.
>
> I could go either way about it.
>
> I prefer the advice given in Coding Standard 0: Don't Sweat the Small
> Stuff, from "C++ Coding Standards" by Alexandrescue and Sutter.

Well, I also like that statement, and have also quoted it many times.

However, I think "small stuff" is mainly stuff that only impacts on the 
feelings of proponents of this scheme and that.

Things that have associated costs such as wasted work time, especially 
for others, are IMHO not that kind of small stuff, to be disregarded. 
Name collisions have such costs. Reduced readability have such costs.


Cheers,

- Alf

[toc] | [prev] | [next] | [standalone]

#13202

On 1/9/12 10:12 PM, Alf P. Steinbach wrote:
> On 10.01.2012 07:05, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> "Alf P. Steinbach"<alf.p.steinbach+usenet@gmail.com> spake the secret
>> code
>> <jeg3u2$fen$1@dont-email.me> thusly:
>>
>>> No, there is no good reason: one should in general reserve ALL UPPERCASE
>>> identifiers for macros.
>>>
>>> But they should be used for macros.
>>
>> I've seen people defining constant quantities like this in upper case
>> because they are used to only being able to define constants with
>> macros and they've equated the semantic category of "constants" to
>> "macros" in their mind.
>>
>> I could go either way about it.
>>
>> I prefer the advice given in Coding Standard 0: Don't Sweat the Small
>> Stuff, from "C++ Coding Standards" by Alexandrescue and Sutter.
>
> Well, I also like that statement, and have also quoted it many times.
>
> However, I think "small stuff" is mainly stuff that only impacts on the
> feelings of proponents of this scheme and that.
>
> Things that have associated costs such as wasted work time, especially
> for others, are IMHO not that kind of small stuff, to be disregarded.
> Name collisions have such costs. Reduced readability have such costs.
>
>
> Cheers,
>
> - Alf

I fully agree. If the original author had just added a comment about 
what this was, it would have been no problem. Obscure with an 
explanation I can handle. Obscure and just sitting there with everything 
else, which also has no explanation, is just wrong.



-- 
Dave Scruggs

[toc] | [prev] | [next] | [standalone]

#13203

legalize+jeeves@mail.xmission.com (Richard) writes:

> I've seen people defining constant quantities like this in upper case

Kernighan & Richie, to name but two.

[toc] | [prev] | [next] | [standalone]

#13221

On Tue, 2012-01-10, Alf P. Steinbach wrote:
> On 10.01.2012 02:11, BCFD36 wrote:
>> I am working on a piece of legacy code that has many, shall we say,
>> strange things. This one, as J.K. Anderson (classics Prof at UC
>> Berkeley) used to say, "baffles me". It has the following statement in
>> the code:
>>
>> const unsigned int WAKEUP_MASK = (1<<  1) ;
...
> Also, there is no reason for the keyword `int`.

Oddly, I've recently met two decent/good programmers who didn't know that
the 'int' in 'unsigned int' is redundant.  One asked me if just writing
'unsigned' was a GCC extension!

I suspect others write 'unsigned int' because they believe verbosity
increases readability.  I remember I did that very early in my career.

/Jorgen

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

[toc] | [prev] | [next] | [standalone]

#13222

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Tue, 2012-01-10, Alf P. Steinbach wrote:
>> On 10.01.2012 02:11, BCFD36 wrote:
>>> I am working on a piece of legacy code that has many, shall we say,
>>> strange things. This one, as J.K. Anderson (classics Prof at UC
>>> Berkeley) used to say, "baffles me". It has the following statement in
>>> the code:
>>>
>>> const unsigned int WAKEUP_MASK = (1<<  1) ;
> ...
>> Also, there is no reason for the keyword `int`.
>
> Oddly, I've recently met two decent/good programmers who didn't know that
> the 'int' in 'unsigned int' is redundant.  One asked me if just writing
> 'unsigned' was a GCC extension!
>
> I suspect others write 'unsigned int' because they believe verbosity
> increases readability.  I remember I did that very early in my career.

I write "unsigned int" because making just "unsigned" work is a clear
mistake in the standard :-). 

-- 
David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

[toc] | [prev] | [next] | [standalone]

#13223

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> On Tue, 2012-01-10, Alf P. Steinbach wrote:
> > On 10.01.2012 02:11, BCFD36 wrote:
> >> I am working on a piece of legacy code that has many, shall we say,
> >> strange things. This one, as J.K. Anderson (classics Prof at UC
> >> Berkeley) used to say, "baffles me". It has the following statement in
> >> the code:
> >>
> >> const unsigned int WAKEUP_MASK = (1<<  1) ;
> ...
> > Also, there is no reason for the keyword `int`.

> Oddly, I've recently met two decent/good programmers who didn't know that
> the 'int' in 'unsigned int' is redundant.  One asked me if just writing
> 'unsigned' was a GCC extension!

> I suspect others write 'unsigned int' because they believe verbosity
> increases readability.  I remember I did that very early in my career.

I use the "unsigned int" form I guess due to some sense of sym-
metry, since I also have to write "unsigned long" and "unsigned
short" (and I wouldn't consider 4 more characters as "verbosity"
and, yes, to me it looks a bit more readable or at least it may
stop me from from getting distracted by wondering "Did I really
mean 'int' or did I perhaps forgot about the 'long' or 'short'?"
when I later read it again).
                               Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#13224

On Tue, 2012-01-10, Jens Thoms Toerring wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>> On Tue, 2012-01-10, Alf P. Steinbach wrote:
>> > On 10.01.2012 02:11, BCFD36 wrote:
>> >> I am working on a piece of legacy code that has many, shall we say,
>> >> strange things. This one, as J.K. Anderson (classics Prof at UC
>> >> Berkeley) used to say, "baffles me". It has the following statement in
>> >> the code:
>> >>
>> >> const unsigned int WAKEUP_MASK = (1<<  1) ;
>> ...
>> > Also, there is no reason for the keyword `int`.
>
>> Oddly, I've recently met two decent/good programmers who didn't know that
>> the 'int' in 'unsigned int' is redundant.  One asked me if just writing
>> 'unsigned' was a GCC extension!
>
>> I suspect others write 'unsigned int' because they believe verbosity
>> increases readability.  I remember I did that very early in my career.
>
> I use the "unsigned int" form I guess due to some sense of sym-
> metry, since I also have to write "unsigned long" and "unsigned
> short" (and I wouldn't consider 4 more characters as "verbosity"

Yes, you're right. I would have cited symmetry reasons back then.

I now think of the symmetry argument as bogus though. 'long' and
'short' are not "siblings" to 'int', just shorthand for 'long int' and
'short int'.

(And now someone will come claiming he always writes 'unsigned long
int' for maximum readability.)

/Jorgen

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

[toc] | [prev] | [next] | [standalone]

#13225

Jorgen Grahn wrote:
> On Tue, 2012-01-10, Jens Thoms Toerring wrote:
>> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>> I suspect others write 'unsigned int' because they believe verbosity
>>> increases readability.  I remember I did that very early in my
>>> career.
>>
>> I use the "unsigned int" form I guess due to some sense of sym-
>> metry, since I also have to write "unsigned long" and "unsigned
>> short" (and I wouldn't consider 4 more characters as "verbosity"
>
> Yes, you're right. I would have cited symmetry reasons back then.
>
> I now think of the symmetry argument as bogus though. 'long' and
> 'short' are not "siblings" to 'int', just shorthand for 'long int' and
> 'short int'.
>
> (And now someone will come claiming he always writes 'unsigned long
> int' for maximum readability.)

For full, well rounded symmetry, you might consider writing 'signed long 
int'.

I'm still stuck on simpler matters, 'uint32_t' for example, where 'unt32_t' 
would seem more symmetric with 'int32_t'.

int32_t ifoo;
unt32_t ufoo;

uint32_t xfoo; // needs a tab rather than space to keep it aligned.

[toc] | [prev] | [next] | [standalone]

#13242

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> I suspect others write 'unsigned int' because they believe verbosity
> increases readability.  I remember I did that very early in my career.

  I have the exact opposite experience: Most noobs believe that verbosity
decreases readability, and thus proceed to write what effectively is
obfuscated C++.

  Unfortunately, even some experienced professionals have this
misconception.

[toc] | [prev] | [next] | [standalone]

#13244

On 1/11/2012 10:14 AM, Juha Nieminen wrote:
> Jorgen Grahn<grahn+nntp@snipabacken.se>  wrote:
>> I suspect others write 'unsigned int' because they believe verbosity
>> increases readability.  I remember I did that very early in my career.
>
>    I have the exact opposite experience: Most noobs believe that verbosity
> decreases readability, and thus proceed to write what effectively is
> obfuscated C++.
>
>    Unfortunately, even some experienced professionals have this
> misconception.

<shrug>

Read quickly:  Raedablity is a mtater of ahbit and is'nt guiedd by eaxct 
precpetpion; itis fzuzy.

You managed to read the line above, didn't you?  It's the same way with 
the source.  'unsigned int' or 'unsigned' doesn't really matter for 
readability.  A quick glance gives all the information one needs. 
However, when it comes to bits and their positions, it's different.  I 
guess, it all comes down to the degree of complexity and one's knack to 
read (comprehend) what others might consider obscure, like hexadecimals 
or octals.

Here is another example.  In our codebase we have tons of flags, most of 
which have symbolic representation.  That representation hasn't changed 
in years.  Yet, I can't read the value 0x29020 (only four bits, mind 
you) and quickly figure out what bits are set.  So, for debugging (and 
only for debugging) I wrote a decoder function that displays the value 
in the symbolic form...  And in the code the value is never written as a 
number.  It's the debugging that presents a problem, AFAIC.

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#13196

On 01/10/12 02:11 PM, BCFD36 wrote:
> I am working on a piece of legacy code that has many, shall we say,
> strange things. This one, as J.K. Anderson (classics Prof at UC
> Berkeley) used to say, "baffles me". It has the following statement in
> the code:
>
> const unsigned int WAKEUP_MASK = (1<<  1) ;
>
> Is there any reason for doing this,  other than to make the code even
> more obscure?

In addition to Alf's comments, the form is quite common especially in 
the embedded or driver world.  Although it is more common to see 
something like

const unsigned wakeupBit    = 1;
const unsigned someOtherBit = 2;

// other bit definitions

const uint32_t wakeupMask = (1u << wakeupBit);

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13199

On 1/9/12 5:30 PM, Ian Collins wrote:
> On 01/10/12 02:11 PM, BCFD36 wrote:
>> I am working on a piece of legacy code that has many, shall we say,
>> strange things. This one, as J.K. Anderson (classics Prof at UC
>> Berkeley) used to say, "baffles me". It has the following statement in
>> the code:
>>
>> const unsigned int WAKEUP_MASK = (1<< 1) ;
>>
>> Is there any reason for doing this, other than to make the code even
>> more obscure?
>
> In addition to Alf's comments, the form is quite common especially in
> the embedded or driver world. Although it is more common to see
> something like
>
> const unsigned wakeupBit = 1;
> const unsigned someOtherBit = 2;
>
> // other bit definitions
>
> const uint32_t wakeupMask = (1u << wakeupBit);
>

Interesting. I didn't know the form is common. I've never seen it 
before, but I don't do much driver work and haven't seen it in the 
embedded work I have done.

Personally, I find it quite obscure and prefer the 0x0002 notation 
myself. But I will have to think on it some more. I can see how you 
could OR together a bunch of these and it be pretty clear which bits are 
set. But I still find it obscure.

Thanks, much. Just for grins, I think I'll run it by the rest of my 
group and see if any of them have seen it before.

-- 
Dave Scruggs

[toc] | [prev] | [next] | [standalone]

#13204

BCFD36 <bcfd36@cruzio.com> wrote in news:jegihu$ri7$1@speranza.aioe.org:

> On 1/9/12 5:30 PM, Ian Collins wrote:
>> On 01/10/12 02:11 PM, BCFD36 wrote:
>>> I am working on a piece of legacy code that has many, shall we say,
>>> strange things. This one, as J.K. Anderson (classics Prof at UC
>>> Berkeley) used to say, "baffles me". It has the following statement 
in
>>> the code:
>>>
>>> const unsigned int WAKEUP_MASK = (1<< 1) ;
>>>
>>> Is there any reason for doing this, other than to make the code even
>>> more obscure?
>>
>> In addition to Alf's comments, the form is quite common especially in
>> the embedded or driver world. Although it is more common to see
>> something like
>>
>> const unsigned wakeupBit = 1;
>> const unsigned someOtherBit = 2;
>>
>> // other bit definitions
>>
>> const uint32_t wakeupMask = (1u << wakeupBit);
>>
> 
> Interesting. I didn't know the form is common. I've never seen it 
> before, but I don't do much driver work and haven't seen it in the 
> embedded work I have done.
> 
> Personally, I find it quite obscure and prefer the 0x0002 notation 
> myself. But I will have to think on it some more. I can see how you 
> could OR together a bunch of these and it be pretty clear which bits 
are 
> set. But I still find it obscure.

The "1<<..." style is better for several reasons, most of which kick in 
when you have larger values than just 0x2:

  - it clearly documents this is a bit mask
  - it clearly documents there is only one bit set
  - it clearly documents which bit it is so one can easily avoid 
collisions with other masks and see which bits are unused

The hexadecimal notation can also do all these things, but requires more 
mental effort from the reader and familiarity with the hexadecimal 
notation in the first place.

Cheers
Paavo

[toc] | [prev] | [next] | [standalone]

#13205

On 1/9/12 11:01 PM, Paavo Helde wrote:
> BCFD36<bcfd36@cruzio.com>  wrote in news:jegihu$ri7$1@speranza.aioe.org:
>
>> On 1/9/12 5:30 PM, Ian Collins wrote:
>>> On 01/10/12 02:11 PM, BCFD36 wrote:
>>>> I am working on a piece of legacy code that has many, shall we say,
>>>> strange things. This one, as J.K. Anderson (classics Prof at UC
>>>> Berkeley) used to say, "baffles me". It has the following statement
> in
>>>> the code:
>>>>
>>>> const unsigned int WAKEUP_MASK = (1<<  1) ;
>>>>
>>>> Is there any reason for doing this, other than to make the code even
>>>> more obscure?
>>>
>>> In addition to Alf's comments, the form is quite common especially in
>>> the embedded or driver world. Although it is more common to see
>>> something like
>>>
>>> const unsigned wakeupBit = 1;
>>> const unsigned someOtherBit = 2;
>>>
>>> // other bit definitions
>>>
>>> const uint32_t wakeupMask = (1u<<  wakeupBit);
>>>
>>
>> Interesting. I didn't know the form is common. I've never seen it
>> before, but I don't do much driver work and haven't seen it in the
>> embedded work I have done.
>>
>> Personally, I find it quite obscure and prefer the 0x0002 notation
>> myself. But I will have to think on it some more. I can see how you
>> could OR together a bunch of these and it be pretty clear which bits
> are
>> set. But I still find it obscure.
>
> The "1<<..." style is better for several reasons, most of which kick in
> when you have larger values than just 0x2:
>
>    - it clearly documents this is a bit mask
>    - it clearly documents there is only one bit set
>    - it clearly documents which bit it is so one can easily avoid
> collisions with other masks and see which bits are unused
>
> The hexadecimal notation can also do all these things, but requires more
> mental effort from the reader and familiarity with the hexadecimal
> notation in the first place.
>
> Cheers
> Paavo
>
>

Only two small quibbles... it was not at all clear to me what this was 
supposed to indicate. Now that I know the secret handshake, it makes 
more sense. And doing it in HEX is no problem at all, at least for me. 
Maybe it is the dinosaur in me.


-- 
Dave Scruggs

[toc] | [prev] | [next] | [standalone]

#13238

In article <jegoav$5te$1@speranza.aioe.org>, BCFD36  <bcfd36@cruzio.com> wrote:
>On 1/9/12 11:01 PM, Paavo Helde wrote:
>> BCFD36<bcfd36@cruzio.com>  wrote in news:jegihu$ri7$1@speranza.aioe.org:
>>
>>> On 1/9/12 5:30 PM, Ian Collins wrote:
>>>> On 01/10/12 02:11 PM, BCFD36 wrote:
>>>>> I am working on a piece of legacy code that has many, shall we say,
>>>>> strange things. This one, as J.K. Anderson (classics Prof at UC
>>>>> Berkeley) used to say, "baffles me". It has the following statement
>> in
>>>>> the code:
>>>>>
>>>>> const unsigned int WAKEUP_MASK = (1<<  1) ;
>>>>>
>>>>> Is there any reason for doing this, other than to make the code even
>>>>> more obscure?
>>>>
>>>> In addition to Alf's comments, the form is quite common especially in
>>>> the embedded or driver world. Although it is more common to see
>>>> something like
>>>>
>>>> const unsigned wakeupBit = 1;
>>>> const unsigned someOtherBit = 2;
>>>>
>>>> // other bit definitions
>>>>
>>>> const uint32_t wakeupMask = (1u<<  wakeupBit);
>>>>
>>>
>>> Interesting. I didn't know the form is common. I've never seen it
>>> before, but I don't do much driver work and haven't seen it in the
>>> embedded work I have done.
>>>
>>> Personally, I find it quite obscure and prefer the 0x0002 notation
>>> myself. But I will have to think on it some more. I can see how you
>>> could OR together a bunch of these and it be pretty clear which bits
>> are
>>> set. But I still find it obscure.
>>
>> The "1<<..." style is better for several reasons, most of which kick in
>> when you have larger values than just 0x2:
>>
>>    - it clearly documents this is a bit mask
>>    - it clearly documents there is only one bit set
>>    - it clearly documents which bit it is so one can easily avoid
>> collisions with other masks and see which bits are unused
>>
>> The hexadecimal notation can also do all these things, but requires more
>> mental effort from the reader and familiarity with the hexadecimal
>> notation in the first place.
>
>Only two small quibbles... it was not at all clear to me what this was 
>supposed to indicate. Now that I know the secret handshake, it makes 
>more sense. And doing it in HEX is no problem at all, at least for me. 
>Maybe it is the dinosaur in me.

0x0002 or 0x0008 is rather trivial and does not cause me to stop.
However, when the bitmask becomes used for multiple things, then I
would say that the following reads trivially while a pure hex based
implementation would force me to stop and start to very carefully
count bits:

const unsigned wakeupBit = 1;
const unsigned someOtherBit = 2;
...
const unsigned superBit = 13;
...
const unsigned hyperBit = 23;
const unsigned gigaBit = 24;
...
const unsigned ultraBit = 29;

const uint32_t theMask = (1u<<  wakeupBit) 
                       & (1u<< someOtherBit)
                       & (1u<< superBit)
                       & (1u<< hyperBit)
                       & (1u<< gigaBit)
                       & (1u<< utraBit) ;

followed elsewhere by:

if( theMask & superBit ) ...


Yannick

[toc] | [prev] | [next] | [standalone]

#13239

In article <jejnve$ff5$1@dont-email.me>,
none) (Yannick Tremblay <yatremblay@bel1lin202.> wrote:
>In article <jegoav$5te$1@speranza.aioe.org>, BCFD36  <bcfd36@cruzio.com> wrote:
>>On 1/9/12 11:01 PM, Paavo Helde wrote:
>>> BCFD36<bcfd36@cruzio.com>  wrote in news:jegihu$ri7$1@speranza.aioe.org:
>>>
>>>> On 1/9/12 5:30 PM, Ian Collins wrote:
>>>>> On 01/10/12 02:11 PM, BCFD36 wrote:
>>>>>> I am working on a piece of legacy code that has many, shall we say,
>>>>>> strange things. This one, as J.K. Anderson (classics Prof at UC
>>>>>> Berkeley) used to say, "baffles me". It has the following statement
>>> in
>>>>>> the code:
>>>>>>
>>>>>> const unsigned int WAKEUP_MASK = (1<<  1) ;
>>>>>>
>>>>>> Is there any reason for doing this, other than to make the code even
>>>>>> more obscure?
>>>>>
>>>>> In addition to Alf's comments, the form is quite common especially in
>>>>> the embedded or driver world. Although it is more common to see
>>>>> something like
>>>>>
>>>>> const unsigned wakeupBit = 1;
>>>>> const unsigned someOtherBit = 2;
>>>>>
>>>>> // other bit definitions
>>>>>
>>>>> const uint32_t wakeupMask = (1u<<  wakeupBit);
>>>>>
>>>>
>>>> Interesting. I didn't know the form is common. I've never seen it
>>>> before, but I don't do much driver work and haven't seen it in the
>>>> embedded work I have done.
>>>>
>>>> Personally, I find it quite obscure and prefer the 0x0002 notation
>>>> myself. But I will have to think on it some more. I can see how you
>>>> could OR together a bunch of these and it be pretty clear which bits
>>> are
>>>> set. But I still find it obscure.
>>>
>>> The "1<<..." style is better for several reasons, most of which kick in
>>> when you have larger values than just 0x2:
>>>
>>>    - it clearly documents this is a bit mask
>>>    - it clearly documents there is only one bit set
>>>    - it clearly documents which bit it is so one can easily avoid
>>> collisions with other masks and see which bits are unused
>>>
>>> The hexadecimal notation can also do all these things, but requires more
>>> mental effort from the reader and familiarity with the hexadecimal
>>> notation in the first place.
>>
>>Only two small quibbles... it was not at all clear to me what this was 
>>supposed to indicate. Now that I know the secret handshake, it makes 
>>more sense. And doing it in HEX is no problem at all, at least for me. 
>>Maybe it is the dinosaur in me.
>
>0x0002 or 0x0008 is rather trivial and does not cause me to stop.
>However, when the bitmask becomes used for multiple things, then I
>would say that the following reads trivially while a pure hex based
>implementation would force me to stop and start to very carefully
>count bits:
>
>const unsigned wakeupBit = 1;
>const unsigned someOtherBit = 2;
>...
>const unsigned superBit = 13;
>...
>const unsigned hyperBit = 23;
>const unsigned gigaBit = 24;
>...
>const unsigned ultraBit = 29;

Arggh!!!  Obviously | not &

>const uint32_t theMask = (1u<<  wakeupBit) 
>                       | (1u<< someOtherBit)
>                       | (1u<< superBit)
>                       | (1u<< hyperBit)
>                       | (1u<< gigaBit)
>                       | (1u<< ultraBit) ;
>
>followed elsewhere by:
>
>if( theMask & superBit ) ...

[toc] | [prev] | [next] | [standalone]

#13206

On Jan 10, 7:01 am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> BCFD36 <bcf...@cruzio.com> wrote innews:jegihu$ri7$1@speranza.aioe.org:
> > On 1/9/12 5:30 PM, Ian Collins wrote:
> >> On 01/10/12 02:11 PM, BCFD36 wrote:

[strange legacy code]

> >>> const unsigned int WAKEUP_MASK = (1<< 1) ;
>
> >>> Is there any reason for doing this, other than to make the code even
> >>> more obscure?

it's quite acommon idiom (the sift that is). I've always thought it a
bit twee. "I'm so cool I can do clever things with bit operators, even
though I don't know hex!".

Perhaps better would be

const unsigned BIT0 = 1;
const unsigned BIT1 = 2;
const unsigned BIT2 = 4;
const unsigned BIT3 = 8;
// etc.

then

const unsigned WAKEUP_MASK = BIT1;

> >> In addition to Alf's comments, the form is quite common especially in
> >> the embedded or driver world. Although it is more common to see
> >> something like
>
> >> const unsigned wakeupBit = 1;
> >> const unsigned someOtherBit = 2;
>
> >> // other bit definitions
>
> >> const uint32_t wakeupMask = (1u << wakeupBit);
>
> > Interesting. I didn't know the form is common. I've never seen it
> > before, but I don't do much driver work and haven't seen it in the
> > embedded work I have done.
>
> > Personally, I find it quite obscure and prefer the 0x0002 notation
> > myself. But I will have to think on it some more. I can see how you
> > could OR together a bunch of these and it be pretty clear which bits
> > are set. But I still find it obscure.
>
> The "1<<..." style is better for several reasons, most of which kick in
> when you have larger values than just 0x2:
>
>   - it clearly documents this is a bit mask

not really

>   - it clearly documents there is only one bit set

sort of

>   - it clearly documents which bit it is so one can easily avoid
> collisions with other masks and see which bits are unused

I submit my named constantrs are clearer

> The hexadecimal notation can also do all these things, but requires more
> mental effort from the reader and familiarity with the hexadecimal
> notation in the first place.

scarey thought. There are people writing device drivers that don't
know hex?

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web