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 2 of 2 — ← Prev page 1 [2]

#13211

On 10.01.2012 09:30, Nick Keighley wrote:
>
> scarey thought. There are people writing device drivers that don't
> know hex?

Why not use octal? Saves you typing an "x". After all, the creators of C 
were quite happy with octal for expressing low level bit patterns.


Cheers,

- Alf

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

#13214

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>On 10.01.2012 09:30, Nick Keighley wrote:
>>
>> scarey thought. There are people writing device drivers that don't
>> know hex?
>
>Why not use octal? Saves you typing an "x". After all, the creators of C 
>were quite happy with octal for expressing low level bit patterns.
>
>

Assuming you're not having us on, you can't evenly divide 8, 16, or 32 by three.

Octal made sense in the 12-bit and 36-bit worlds from which the creators of C
hailed.

scott

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

#13217

On 1/10/2012 12:14 PM, Scott Lurndal wrote:
> "Alf P. Steinbach"<alf.p.steinbach+usenet@gmail.com>  writes:
>> On 10.01.2012 09:30, Nick Keighley wrote:
>>>
>>> scarey thought. There are people writing device drivers that don't
>>> know hex?
>>
>> Why not use octal? Saves you typing an "x". After all, the creators of C
>> were quite happy with octal for expressing low level bit patterns.
>>
>>
>
> Assuming you're not having us on, you can't evenly divide 8, 16, or 32 by three.
>
> Octal made sense in the 12-bit and 36-bit worlds from which the creators of C
> hailed.

Are you saying that 040 is more difficult to read than 0x20?  Just 
checking...

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

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

#13218

Victor Bazarov <v.bazarov@comcast.invalid> writes:

> On 1/10/2012 12:14 PM, Scott Lurndal wrote:
>> "Alf P. Steinbach"<alf.p.steinbach+usenet@gmail.com>  writes:
>>> On 10.01.2012 09:30, Nick Keighley wrote:
>>>>
>>>> scarey thought. There are people writing device drivers that don't
>>>> know hex?
>>>
>>> Why not use octal? Saves you typing an "x". After all, the creators of C
>>> were quite happy with octal for expressing low level bit patterns.
>>>
>>>
>>
>> Assuming you're not having us on, you can't evenly divide 8, 16, or 32 by three.
>>
>> Octal made sense in the 12-bit and 36-bit worlds from which the creators of C
>> hailed.
>
> Are you saying that 040 is more difficult to read than 0x20?  Just checking...

It is.

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

#13230

On Jan 10, 10:45 pm, Richard <rgrd...@gmail.com> wrote:
> Victor Bazarov <v.baza...@comcast.invalid> writes:
> > On 1/10/2012 12:14 PM, Scott Lurndal wrote:
> >> "Alf P. Steinbach"<alf.p.steinbach+use...@gmail.com>  writes:
> >>> On 10.01.2012 09:30, Nick Keighley wrote:
>
> >>>> scarey thought. There are people writing device drivers that don't
> >>>> know hex?
>
> >>> Why not use octal? Saves you typing an "x". After all, the creators of C
> >>> were quite happy with octal for expressing low level bit patterns.
>
> >> Assuming you're not having us on, you can't evenly divide 8, 16, or 32 by three.
>
> >> Octal made sense in the 12-bit and 36-bit worlds from which the creators of C
> >> hailed.
>
> > Are you saying that 040 is more difficult to read than 0x20?  Just checking...
>
> It is.

It's a question of point of view, as usual; in my mind I see those as:

0x20 = 0010 0000
040 = 000 100 000

It's just a different # of bits grouped together, big deal. But that
doesn't change anything. The idea of (1L << N) isn't to be readable
anyway (in the context of embedded driver work) so arguing which form
is more readable is missing the point.

So what is the point? The point is painless translation of
specification into usable header in finite time. Each field has mask
and offset, these are used through everywhere else. This comes from
digital circuit logic design languages like VHDL, SystemC, Catapult.
The idea is painless interaction between those and C/C++ (C mostly).

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

#13232

On Jan 11, 10:04 am, hanukas <ju...@liimatta.org> wrote:
> On Jan 10, 10:45 pm, Richard <rgrd...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > Victor Bazarov <v.baza...@comcast.invalid> writes:
> > > On 1/10/2012 12:14 PM, Scott Lurndal wrote:
> > >> "Alf P. Steinbach"<alf.p.steinbach+use...@gmail.com>  writes:
> > >>> On 10.01.2012 09:30, Nick Keighley wrote:
>
> > >>>> scarey thought. There are people writing device drivers that don't
> > >>>> know hex?
>
> > >>> Why not use octal? Saves you typing an "x". After all, the creators of C
> > >>> were quite happy with octal for expressing low level bit patterns.
>
> > >> Assuming you're not having us on, you can't evenly divide 8, 16, or 32 by three.
>
> > >> Octal made sense in the 12-bit and 36-bit worlds from which the creators of C
> > >> hailed.
>
> > > Are you saying that 040 is more difficult to read than 0x20?  Just checking...
>
> > It is.
>
> It's a question of point of view, as usual; in my mind I see those as:
>
> 0x20 = 0010 0000
> 040 = 000 100 000
>
> It's just a different # of bits grouped together, big deal. But that
> doesn't change anything. The idea of (1L << N) isn't to be readable
> anyway (in the context of embedded driver work) so arguing which form
> is more readable is missing the point.
>
> So what is the point? The point is painless translation of
> specification into usable header in finite time. Each field has mask
> and offset, these are used through everywhere else. This comes from
> digital circuit logic design languages like VHDL, SystemC, Catapult.
> The idea is painless interaction between those and C/C++ (C mostly).

For the record, none of the proposed approaches are used anyway.

(1 << 4) // nope
(1U << 4) // naah
(1L << 4) // uh-huh..

Here's how it's done:

(0xf << 12) // zero-based mask shifted to correct position

Or more concrete:

SOME_REGISTER_FIELD_MASK   (0xff << 16)
SOME_REGISTER_FIELD_OFFSET 16
SOME_REGISTER_FIELD_SIZE   8

Usually this is not done by hand. The HLL description of logic is
translated into C header and we always get all of these; mask, offset,
size. It's up to the driver author to use the appropriate fields where
needed.

When we type these by hand, we follow the same convention for
consistency. =)

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

#13220

On Tue, 2012-01-10, Victor Bazarov wrote:
> On 1/10/2012 12:14 PM, Scott Lurndal wrote:
>> "Alf P. Steinbach"<alf.p.steinbach+usenet@gmail.com>  writes:
>>> On 10.01.2012 09:30, Nick Keighley wrote:
>>>>
>>>> scarey thought. There are people writing device drivers that don't
>>>> know hex?
>>>
>>> Why not use octal? Saves you typing an "x". After all, the creators of C
>>> were quite happy with octal for expressing low level bit patterns.
>>>
>>>
>>
>> Assuming you're not having us on, you can't evenly divide 8, 16, or 32 by three.
>>
>> Octal made sense in the 12-bit and 36-bit worlds from which the creators of C
>> hailed.
>
> Are you saying that 040 is more difficult to read than 0x20?  Just 
> checking...

Perhaps both Alf and you are joking and my humor center is out of
operation, but anyway:

I learned programming 20 years ago, and never found any reason to
learn to read octal, other than in the very limited field of Unix file
protection bits. It takes practice, and very, very few people get that
practice these days.

/Jorgen

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

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

#13231

"Victor Bazarov" <v.bazarov@comcast.invalid> wrote in message 
news:jei61r$onp$1@dont-email.me...
> On 1/10/2012 12:14 PM, Scott Lurndal wrote:
>> "Alf P. Steinbach"<alf.p.steinbach+usenet@gmail.com>  writes:
>>> On 10.01.2012 09:30, Nick Keighley wrote:
>>>>
>>>> scarey thought. There are people writing device drivers that don't
>>>> know hex?
>>>
>>> Why not use octal? Saves you typing an "x". After all, the creators of C
>>> were quite happy with octal for expressing low level bit patterns.
>>>
>>>
>>
>> Assuming you're not having us on, you can't evenly divide 8, 16, or 32 by 
>> three.
>>
>> Octal made sense in the 12-bit and 36-bit worlds from which the creators 
>> of C
>> hailed.
>
> Are you saying that 040 is more difficult to read than 0x20?  Just 
> checking...
>
> V
> -- 
> I do not respond to top-posted replies, please don't ask


O40 loks like a number, but is not. 

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

#13233

"Bill Davy"  wrote in message news:9n4vksFqm3U1@mid.individual.net...
>
>"Victor Bazarov" <v.bazarov@comcast.invalid> wrote in message 
>news:jei61r$onp$1@dont-email.me...
>> On 1/10/2012 12:14 PM, Scott Lurndal wrote:
>>> "Alf P. Steinbach"<alf.p.steinbach+usenet@gmail.com>  writes:
>>>> On 10.01.2012 09:30, Nick Keighley wrote:
>>>>>
>>>>> scarey thought. There are people writing device drivers that don't
>>>>> know hex?
>>>>
>>>> Why not use octal? Saves you typing an "x". After all, the creators of 
>>>> C
>>>> were quite happy with octal for expressing low level bit patterns.
>>>>
>>>>
>>>
>>> Assuming you're not having us on, you can't evenly divide 8, 16, or 32 
>>> by three.
>>>
>>> Octal made sense in the 12-bit and 36-bit worlds from which the creators 
>>> of C
>>> hailed.
>>
>> Are you saying that 040 is more difficult to read than 0x20?  Just 
>> checking...
>>
>> V
>> -- 
>> I do not respond to top-posted replies, please don't ask
>
>
>O40 loks like a number, but is not.

Ox20 looks like a number, but it is not. l00 looks like a number, but it is 
not. What is your point? 

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

#13241

On Jan 11, 10:40 am, "Fred Zwarts \(KVI\)" <F.Zwa...@KVI.nl> wrote:
> "Bill Davy"  wrote in messagenews:9n4vksFqm3U1@mid.individual.net...
>
> >"Victor Bazarov" <v.baza...@comcast.invalid> wrote in message
> >news:jei61r$onp$1@dont-email.me...
> >> On 1/10/2012 12:14 PM, Scott Lurndal wrote:
> >>> "Alf P. Steinbach"<alf.p.steinbach+use...@gmail.com>  writes:
> >>>> On 10.01.2012 09:30, Nick Keighley wrote:
>
> >>>>> scarey thought. There are people writing device drivers that don't
> >>>>> know hex?
>
> >>>> Why not use octal? Saves you typing an "x". After all, the creators of
> >>>> C
> >>>> were quite happy with octal for expressing low level bit patterns.
>
> >>> Assuming you're not having us on, you can't evenly divide 8, 16, or 32
> >>> by three.
>
> >>> Octal made sense in the 12-bit and 36-bit worlds from which the creators
> >>> of C
> >>> hailed.
>
> >> Are you saying that 040 is more difficult to read than 0x20?  Just
> >> checking...
>
> >> V
> >> --
> >> I do not respond to top-posted replies, please don't ask
>
> >O40 loks like a number, but is not.
>
> Ox20 looks like a number, but it is not. l00 looks like a number, but it is
> not. What is your point?

I guess he meant base-10 decimal number? The leading zero is the tip-
off for C/C++ programmers that it's octal.

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

#13247

Victor Bazarov <v.bazarov@comcast.invalid> writes:
>On 1/10/2012 12:14 PM, Scott Lurndal wrote:
>> "Alf P. Steinbach"<alf.p.steinbach+usenet@gmail.com>  writes:
>>> On 10.01.2012 09:30, Nick Keighley wrote:
>>>>
>>>> scarey thought. There are people writing device drivers that don't
>>>> know hex?
>>>
>>> Why not use octal? Saves you typing an "x". After all, the creators of C
>>> were quite happy with octal for expressing low level bit patterns.
>>>
>>>
>>
>> Assuming you're not having us on, you can't evenly divide 8, 16, or 32 by three.
>>
>> Octal made sense in the 12-bit and 36-bit worlds from which the creators of C
>> hailed.
>
>Are you saying that 040 is more difficult to read than 0x20?  Just 
>checking...
>
>V

No, I'm saying that I can look at 0x12345678 and visually determine which
bits are set in which bytes.   It's much more complicated for 02215053170.

On the other hand, when I was writing PAL-D code for the pdp8, 4 digit octal
numbers worked just fine due to the 12-bit word.

scott

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

#13254

scott@slp53.sl.home (Scott Lurndal) writes:

> Victor Bazarov <v.bazarov@comcast.invalid> writes:
>>On 1/10/2012 12:14 PM, Scott Lurndal wrote:
>>> "Alf P. Steinbach"<alf.p.steinbach+usenet@gmail.com>  writes:
>>>> On 10.01.2012 09:30, Nick Keighley wrote:
>>>>>
>>>>> scarey thought. There are people writing device drivers that don't
>>>>> know hex?
>>>>
>>>> Why not use octal? Saves you typing an "x". After all, the creators of C
>>>> were quite happy with octal for expressing low level bit patterns.
>>>>
>>>>
>>>
>>> Assuming you're not having us on, you can't evenly divide 8, 16, or 32 by three.
>>>
>>> Octal made sense in the 12-bit and 36-bit worlds from which the creators of C
>>> hailed.
>>
>>Are you saying that 040 is more difficult to read than 0x20?  Just 
>>checking...
>
> No, I'm saying that I can look at 0x12345678 and visually determine which
> bits are set in which bytes.   It's much more complicated for 02215053170.

Whereas for me it's the opposite. 

But wait -- what you have memorized, to decode the hex, is a superset of
what I know to decode the octal.  How, then, can it be "much more
complicated" to decode the octal?  It involves decoding more digits, so
I can't argue against "slightly more work" or something like that.  But
the principles are identical, and the tables needed in memory are a
subset of the hex tables. 

> On the other hand, when I was writing PAL-D code for the pdp8, 4 digit octal
> numbers worked just fine due to the 12-bit word.

Yep, that's where I learned to do octal.  Actually toggling in the RIM
loader is where I learned to do octal.

-- 
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]

#13249

In article <jehllm$hot$1@dont-email.me>,
Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote:
>Why not use octal? Saves you typing an "x". After all, the creators of C 
>were quite happy with octal for expressing low level bit patterns.

'we don't do that'

Virtually all computers now have eight-bit bytes.  It is a common data
type, what the other data types are made of, and probably the unit of
address.  It's so much nicer when the radix bits are a fraction of this.

Dump sone memory in words then interpret it in bytes, or vice versa.

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

#13274

On Jan 10, 3:31 pm, "Alf P. Steinbach" <alf.p.steinbach
+use...@gmail.com> wrote:
> On 10.01.2012 09:30, Nick Keighley wrote:

> > scarey thought. There are people writing device drivers that don't
> > know hex?
>
> Why not use octal? Saves you typing an "x". After all, the creators of C
> were quite happy with octal for expressing low level bit patterns.

I've used both in the past. Hex is more compact and fits better to 8,
16 and 32 bit quantities. But i suspect you know this.

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

#13317

On 1/12/12 5:40 AM, Nick Keighley wrote:
> On Jan 10, 3:31 pm, "Alf P. Steinbach"<alf.p.steinbach
> +use...@gmail.com>  wrote:
>> On 10.01.2012 09:30, Nick Keighley wrote:
>
>>> scarey thought. There are people writing device drivers that don't
>>> know hex?
>>
>> Why not use octal? Saves you typing an "x". After all, the creators of C
>> were quite happy with octal for expressing low level bit patterns.
>
> I've used both in the past. Hex is more compact and fits better to 8,
> 16 and 32 bit quantities. But i suspect you know this.

Never try to play Blackjack when you have been working in octal for 3 
years. It can mess with the math. Balancing a checkbook can get a little 
dicey too.



-- 
Dave Scruggs

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

#13229

On Jan 10, 10:30 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> 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?

Sure we do know hex. But we are translating System/Catapult code and
specification into C/C++ header, that is the simplest way to do it.
Let's say we have a 5 bit field at offset 20. Sure we can juggle the
masks in our heads nibble-at-time and get the right answer 99.9% of
the time. But with this approach we do it in fraction of the time and
get it right 99.999% of the time.

We don't really care what that header looks like, what we do care
about is that RB_BLOCK_CLOCK_GATE_MASK has the right value on it. We
don't think in terms of "we are too cool to get our jobs done on
time", you know? What would doing this thing ass-backwards prove? That
we know hex? You are serious, though? Scary.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web