A quick c programming survey question

Tim,

We use A and B.

Our embedded code is largely Forth so hiding some bits with a name makes sense. At other times knowing bit relationships takes precedence and that method is used. 'Bits' is a nice concept to discuss, but there are many ways to group and access 'bits' so it seems fair to report that both methods (and perhaps others) have their uses too.

David

inline!? Surely this is what 'b' does except that you hide the complexity

Assuming that you are sure you can do this. I think that here in Europe there is much less of a 'hire the previous guy again' culture (it happens, but it isn't the 'normal' mode). Most external resources are people new to the manager and how can he tell if he can trust the guy (or gal) to 'do the right thing' - except by asking him "what's the best way to..." questions similar to this one at interview :-)

"don't worry" because you know that they will do it right, or because it doesn't matter (as long as it works)?

tim

B.

d) All of the above (including c, for some various values of c), depending on the target.

What planet do you live on, where this comes as a surprise? I would be very surprised if the most popular method was not something like "PORTB |= LEDMASK" or "PORTB &= ~(1

I don't know if (b) refers to what i do when there is no software process cop lurking around...

volatile unsigned char *this_address = 0x0F00 ...

*this_address = 0x23;

So many times i dont even do (a) nor (b)

Yes.

Yes.

Your point?

--
Grant Edwards                   grante             Yow!  Are you still
                                  at               SEXUALLY ACTIVE? Did you
                               visi.com            BRING th' REINFORCEMENTS?

(a) would be nice if the C standard made it practical. So I use (b).

--
Mike Page BEng(Hons) MIEE           www.eclectic-web.co.uk

b.

-- Dan Henry

Never. For two reasons:

1) Bit field "direction" is nondeterministic on non byte size operators and often is a source of problems when porting from one CPU type to another

2) This approach won't work for registers that have different write behavior than read behavior. This generates read/modify/write code when tweaking a single bit or set of bits.

It'll probably be OK if you don't

B)

-->Neil

From "The Practice of Programming" by Kernighan and Pike, p183:

generate voluminous and inefficient code."

Steve

It didn't come as a suprise that people use it.

It comes as a suprise that people would 'recommend' it.

like

I know that I missed it out of the question but there is no 'depending on the target' allowed.

The requirement is for a method that you always use for all platforms and the question is really one of "which is the best compromise".

This will all be clear when I post the summary shortly

tim

This is not 'generic' enough. It works for initialisation of the whole register. It is useless for changing an individual bit.

Um?

tim

so why not just select 'b'?

Read the summary to be posted shortly and you'll see why it is important.

you

REINFORCEMENTS?

Which hits the nail on the head, and was why I asked people not to comment. Though is not a problem, I'd already decided that I'd collated enough answers

tim

and

behavior

see my reply to mike

tim

So why did they provide them then? Or Why did they not remove them (or define them properly) when the stardards were updated.

I know this by the way, it's why I created this survey.

Tim

Ok, so it seems that more people have selected B than A. This slightly surprises me because most of the places that I have worked use 'A' (not on my advice), but then that was why I asked. But as someone has pointed out the experience of the posters to the group is above the average so that should be the reason.

The actual question was an interview question (asked to a colleague). It was a telephone interview so there was little scope for discussion.

Those of you who answered "it depends" have failed (my decision) as the code requirement is one of 'conformity' and 'reusability' from one project to the next (and reusability of the programmer's knowledge from one project to the next).

I suppose those that have answered 'something else' would not have done so in an interview (unless they had already decided that they didn't want the job) and can decide for themselves if they 'passed'. Feel free to disagree with this assumption if you really would argue the point in a telephone interview (which here is a filter into a 'real' interview).

The answer that the interviewer wanted was 'b'. So those people pass (as long as they get the other questions correct!)

My colleague was pissed, as he said 'a', on no more experience than what we do currently. He asked me the question, I instantly said 'b' and when asked why I said "because bits are not portable" (correct answer - been there..., to be avoided big time) which pissed him off even more.

But on reflection perhaps he has a right to be pissed. IME many people don't know that bits are not portable (or perhaps they decide that they don't care), but they still might prefer Option 'b' because:

1) they consider it neater SetBit( &register_name, bit_name ); is a arguably tidier than register_name->bits.bit_name = 1;

2) It can provide error checking missed by some compilers, which don't object if you try to put more bits into the element than it actually has.

3) It can provide a uniform interface with reading bits from locations that are not accessed by a single read such as the register on an I2C device for which the struct method will not work automatically.

(and some, who know bits aren't portable, might still prefer 'a', though god knows why!)

So if the interviewer just wanted to find out if the interviewee knew that bits aren't portable he should have asked using a less roundabout question to establish this and addressed the 'style' issues separately (which I am sure my colleague would have got right).

Anyone care to comment?

tim