A quick c programming survey question

Having had the misfortune of doing the task I can assure you that this change is a bitch without the macros.

Reply to
tim
Loading thread data ...

to

I must disagree. The syntax is horrid.

But they could have been implemented better.

Standard changes take a long time to implement. Some fundamental items have been changed before and there just has to be a sensible process for doing it. It is not an in-soluable problem to discourage the use of 'bits' in the future whilst continuing to compile legacy code. Having said that, defining them better would be my choice.

tim

Reply to
tim

I'm about half in agreement with you (it wasn't me who originally phrased the question).

For the other half, the fact that this was an interview situation was relevant. It doesn't seem unreasonable to me for the interviewer to assume that the interviewee can work out for themselves that portability of code (and ideas) might be an important thing to convey.

But, in making my question as concise as possible I decided to leave this information out. With hindsight this was a mistake and for that I apologise.

tim

Reply to
tim

As I pointed out in my comment, a very large number of people with which I (have) work(ed) don't know this. Quite why this I do not know.

tim

Reply to
tim

From personal experience I find this a hard thing to do during a telephone interview. You don't get the necessary feed-back if the guy hasn't understood your idea. I leave discussion of ideas to real interviews

Perhaps, as I know of no-one that's got the job I can't tell

But at least you have a chance of knowing the answer that they want :-)

I'm inclined to agree with you. As I got 'all' of the questions correct he suggested that I should go for the Job, but I decided that it didn't sound like me.

tim

Reply to
tim

Not my experience. I've had to port very large projects from CPU to CPU over the years. The code tends to last longer than the availablity of the processors ;).

Re bitfields: if they're being used as efficient boolean storage, alignment etc is irrelevant. This is probably why they're in the standard. For control of hardware, they're "highly non-portable" (as I've already quoted from Brian Kernighan), but as has been noted, some compilers provide (non-standard) workarounds. I agree with the comment re hardware interfacing belonging at the driver layer - quite often I have a totally different port implementation in changing CPUs, let alone bits - so it's an environment issue which will inevitably be revisited.

Steve

formatting link
formatting link

Reply to
Steve at fivetrees

Although you have a valid point on portability here, I would never make it paramount for the decision of bitfields/no-bitfields. It is simply not worth the trouble to stick to one technique when another would have served you better in the context.

If the assignment shows up only few times, it is your responsibility to guard it with asserts, if it is used heavily then good design requires you to put it in a function (or redesign) anyway - so IMHO there is no point in argueing for one or the other. There are, however two drawbacks to the function solution (there are others to the bitfields, of course): when macro-izing such functions, I often see the '&' to the argument left out, so the line fails to communicate (like "setBit(PortA,7)") that one of the arguments is effectively changed in the operation (yes, I see this as a problem, you have two different semantics in your C program, which is dangerous and ugly and whatnot), and secondly, you will fail on volatile bits which can hit you if your compiler is good at inlining and optimizing and lazy at reporting warnings.

You show me how you pack the semantics and pre-/postconditions of effectively a multi-threading/task-switching functionality into such a harmless and unsuspicious call like getBit() and I will rethink my programming paradigmas ;)

regards, Mark

Reply to
Mark Piffer

C was used for many years before the first standard was created. Different implementors made different choices about how to implement bit fields. Since the purpose of the C standard was 'to codify existing practice' it could not specify bit orders without breaking existing code, and therefore it didn't.

The standard for bitfields is non-portable because the C-code for bitfields is non-portable because the standard for bitfields is non-portable because ....

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

Because manholes are round. :)

--
Grant Edwards                   grante             Yow!  Mr and Mrs PED, can I
                                  at               borrow 26.7% of the RAYON
 Click to see the full signature
Reply to
Grant Edwards

I guess that is in the eye of the beholder. While I'm not asserting that it is the best possible way, I don't find it repugnant, either. Feel free to not use bitfields. You can even choose another language or design and implement your own if you feel that strongly about it.

Years ago I used a Pascal compiler which implemented packed records to achieve the same thing as bitfields. The fields were specified as a range of values, rather than the number of bits. The compiler allocated the minimum number of bits needed for the range, including whether to allocate a sign bit. I used them successfully for memory-mapped I/O registers. Better? Not significantly.

Do you mean the language could have been designed better, or implemented better in a particular compiler? As far as the latter, yes, I have seen poorly implemented bitfield code generation. That's the fault of the compiler implementor, not the language. As far as the language design, possibly, but almost anything can be improved in hindsight. At this point, it's moot for C syntax.

You can now stop using bitfields in your own code without any outside mandate. If you want to force others to do without, you might have an uphill fight. ;-) The best course for an existing language, I think, is to impose your own coding standards while maintaining most of the language features for compatibility.

Thad

Reply to
Thad Smith

I don't get the choice. As I freelancer I often turn up on a project after someone has already 'designed' this solution. Getting it changed is impossible. (it's hard enough stopping some people declaring everything global - sorry current gripe)

yes.

As I've already said, I seen some pretty nifty code generation.

I still subscribe to the 'conformity' rule, unless it doesn't actually work.

Where the he benefits are over-whelming, it's easy. It is however very hard to counter the "it's already done" answer.

Agreed. If only there were an automated way of enforcing, for example: "no use of the comma operator (except in for control loops)"

tim

Reply to
tim

Not where I live, they're not.

tim

can I

RAYON

the

Reply to
tim

I've read this three times and I think my reply is:

I wasn't suggesting that they should be bundled into the same routine, just that the parameter list should be the same.

tim

Reply to
tim

I'd probably take it one step further:

#define sbit(bit,port) port |= (1

Reply to
Ulf Samuelsson

B
--
"Just machines that make big decisions
 programmed by fellas with compassion and vision."
 Click to see the full signature
Reply to
Bob Stephens

Ah, that's where you're wrong. Microsoft has changed the value of 'round'.

--
Grant Edwards                   grante             Yow!  HAIR TONICS, please!!
                                  at               
 Click to see the full signature
Reply to
Grant Edwards

Are you referring to the declaration syntax or how to use it ?

What is the problem with syntax like

if (uart->TxEmpty) ......

The declaration only occurs once, but there are usually a lot of cases when the fields are referenced.

It is unrealistic to assume that you could write a program and everything you would have to do is to transfer it to _any_ other system and compile it. Someone is always going to make a bizarre hardware architecture, which would break your idealistic ideas. Thus it is a better idea to isolate the potentially unportable parts into the data declarations (and possibly even into separate access routines).

My guess that one reason for not allowing any bit number definitions in the bit field declarations, is that various architectures quite different numbering systems are used. For 16 bit architectures, you might find (for MSB .. LSB) at least 15..0, 16..1, 0..15 and 1..16. In addition in formats like 0..xx or 1..xx, the bit number of LSB is different depending on if we are talking about bytes, words or long words.

Since you would have to use the absolute number at least in the declaration part, what would uart.5 refer to (or uart[5]) if the native bit numbering was some of the more bizarre kind as above.

Paul

Reply to
Paul Keinanen

depending

I'm certainly curious about what you're looking for! I wonder how much it relates to real-world embedded programming, where there is always a great deal of target-dependant variation in programming methods, or to some ideal world in which the lowest common denominator of all targets is good enough (and thus you end up with an Arm processor controlling a light switch...)

Reply to
David Brown

PCLint

formatting link
can do this.

If I add a comma operator to my current project code, I get the following warning:

xxxxx.c 120 Note 960: Violates MISRA Required Rule 42, comma operator used outside of 'for' expression

Andy

Reply to
Andy Sinclair

That makes a lot of difference ...

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.