Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Coding Style Question - Is there any sane reason for doing this?

Reply
Thread Tools

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

 
 
Victor Bazarov
Guest
Posts: n/a
 
      01-10-2012
On 1/10/2012 12:14 PM, Scott Lurndal wrote:
> "Alf P. Steinbach"<(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-10-2012
On Tue, 2012-01-10, Victor Bazarov wrote:
> On 1/10/2012 12:14 PM, Scott Lurndal wrote:
>> "Alf P. Steinbach"<(E-Mail Removed)> 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 .
 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-10-2012
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 .
 
Reply With Quote
 
David Dyer-Bennet
Guest
Posts: n/a
 
      01-10-2012
Jorgen Grahn <(E-Mail Removed)> 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, http://www.velocityreviews.com/forums/(E-Mail Removed); http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info
 
Reply With Quote
 
Jens Thoms Toerring
Guest
Posts: n/a
 
      01-10-2012
Jorgen Grahn <(E-Mail Removed)> 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 ___ (E-Mail Removed)
\__________________________ http://toerring.de
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-11-2012
On Tue, 2012-01-10, Jens Thoms Toerring wrote:
> Jorgen Grahn <(E-Mail Removed)> 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 .
 
Reply With Quote
 
MikeWhy
Guest
Posts: n/a
 
      01-11-2012
Jorgen Grahn wrote:
> On Tue, 2012-01-10, Jens Thoms Toerring wrote:
>> Jorgen Grahn <(E-Mail Removed)> 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.


 
Reply With Quote
 
hanukas
Guest
Posts: n/a
 
      01-11-2012
On Jan 10, 10:30*am, Nick Keighley <(E-Mail Removed)>
wrote:
> On Jan 10, 7:01*am, Paavo Helde <(E-Mail Removed)> wrote:
>
> > BCFD36 <(E-Mail Removed)> wrote innews:jegihu$ri7$(E-Mail Removed):
> > > 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.
 
Reply With Quote
 
hanukas
Guest
Posts: n/a
 
      01-11-2012
On Jan 10, 10:45*pm, Richard <(E-Mail Removed)> wrote:
> Victor Bazarov <(E-Mail Removed)> writes:
> > On 1/10/2012 12:14 PM, Scott Lurndal wrote:
> >> "Alf P. Steinbach"<(E-Mail Removed)> *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 32by 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).
 
Reply With Quote
 
hanukas
Guest
Posts: n/a
 
      01-11-2012
On Jan 11, 10:04*am, hanukas <(E-Mail Removed)> wrote:
> On Jan 10, 10:45*pm, Richard <(E-Mail Removed)> wrote:
>
>
>
>
>
>
>
>
>
> > Victor Bazarov <(E-Mail Removed)> writes:
> > > On 1/10/2012 12:14 PM, Scott Lurndal wrote:
> > >> "Alf P. Steinbach"<(E-Mail Removed)> *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 creatorsof 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. =)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
501 PIX "deny any any" "allow any any" Any Anybody? Networking Student Cisco 4 11-16-2006 10:40 PM
Is there any reason for private virtual functions? Jimmy C++ 3 06-30-2006 12:49 PM
general coding issues - coding style... calmar Python 11 02-21-2006 10:36 AM
is there any reason not to inherit from std::exception __PPS__ C++ 3 11-09-2005 07:50 PM
Is there is any strong reason not to use standard native C++ data types Abhishek Saksena C++ 7 08-10-2005 02:12 PM



Advertisments