C# interview question

[BrilloPad]

No offence, but how do you lot get paid money for programming in a C based language and not know the simple operators? It's a clever question: obviously the intent is to ascertain whether you're the sort of programmer who'd read a book or paid for a course, or whether you're the sort of programmer who really understands what they're doing.

The problem with those sorts of coders is that they will take a simple problem and make it more complex for their own enjoyment.

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? Brian Kernighan

[wurzel]

I had to look it up as well, and I'm an experienced .net developer. I can't think of a practical application for that operand when you have easier access to floating point arithmetic anyway. Even when you're using bitwise operators to encapsulate several Boolean values into a readily-transferable binary number (which is about the only time I get into mucking around with individual bits), the Shift operator doesn't come into play.

Sounds like the sort of meaningless trick question technical interviewers only ever ask when they want to feel clever, or that they think will impress their non-technical boss that is also on the interview panel.

Used to use bit wise operations on a C++ MFC system I worked on years ago that had a lot of screens containing arrays of check boxes. Used to store the check state of the check boxes in an integer & doing all the bitwise comparisons would tell the programme what ones to check on loading the form. The shift operator was in there too but I'll be buggered if I can remember what for....

[acontractor]

Enum

One place I can see it can be used is with enums:

for e.g.
[Flags]
public enum Permission
{
[Description("None")]
None = (0 << 0), //0
[Description("View")]
View = (1 << 0), // 1
[Description("Add")]
Add = (1 << 1), // 2
[Description("Edit")]
Edit = (1 << 2), //4
[Description("View,Add and Edit")]
ViewAddEdit = (View | Add | Edit), // 1 + 2 + 4 = 7
}

[Sysman]

Doing things a certain way just because that's the way you've always done them (and is the only way you know how to do them) can lead to some fairly counter-intuitive solutions and unreadable code.

There's a name for that.

Cargo cult programming

[BrilloPad]

One place I can see it can be used is with enums:

for e.g.
[Flags]
public enum Permission
{
[Description("None")]
None = (0 << 0), //0
[Description("View")]
View = (1 << 0), // 1
[Description("Add")]
Add = (1 << 1), // 2
[Description("Edit")]
Edit = (1 << 2), //4
[Description("View,Add and Edit")]
ViewAddEdit = (View | Add | Edit), // 1 + 2 + 4 = 7
}

But if you don't comment it then its unintelligible to most people. And there is a simple alternative. Which backs my statement that if anyone knows the answer to the question then they are probably not suitable for a coding job.

[NickFitz]

I must admit I'm surprised anybody would not know the bitwise operators: Boolean logic is, after all, quite closely associated with computers

Quick way to multiply by 80:

n = n << 4;
tmp = n;
n = n << 2;
n += tmp;

commonly used (most likely in its assembly language equivalent) to calculate a y-axis offset on something like a CGA card, which in certain graphics modes has 80 bytes per row of the display

(Actually it's slightly more complex than that, as the rows of the display are interlaced in memory, alternate rows being in different segments; dealing with this is left as an exercise for the reader. Hint: y >> 1 may help.)

[acontractor]

But if you don't comment it then its unintelligible to most people. And there is a simple alternative. Which backs my statement that if anyone knows the answer to the question then they are probably not suitable for a coding job.

Not really. The compiler compiles this as a numeric values. So wherever you are using Permission.Add if you press F12 on "Add" and it will show you the Numeric value which is 2 and not 1 << 1. The idea is that you implement some sort of "inheritance" in enum which is not supported for Enum in C#.

[Ketchup]

Having witnessed a police project where the number of characters you could type in a criminal record was 256, because that's the number of holes that were in the punched cards that were used by the ancient system that they were supposed to be updating used to allow, I'm more than happy for people to think outside outdated boxes, ta. Doing things a certain way just because that's the way you've always done them (and is the only way you know how to do them) can lead to some fairly counter-intuitive solutions and unreadable code. The Shift operator is at best a legacy feature in C#.

Remibds me of the only gig i truned down. The system used for numbering the syndicate boxes at Lloyds was limited to 1000 (0-1000), there were a number of broking systems that had this restriction in place, i interviewed for a 3 month gig to rewrite, i explained the project was much longer and didnt think it could be done in 3 months. They offered me the job anyway and i turned it down. I dn't know how long it took exactly, but was well over a year

[Contreras]

Quick way to multiply by 80:

n = n << 4;
tmp = n;
n = n << 2;
n += tmp;

Funnily enough, a decent compiler will produce exactly the same machine code output if you had written:

n *= 80;

I know this because for laughs I did a quick test and the compiler managed to unpick all the hand optimised bit-shift stuff into a single 'mult' instruction.

Even if the target cpu did not support hardware multiplication, I reckon a modern compiler would produce damn near identical code for both instances.

[NickFitz]

Funnily enough, a decent compiler will produce exactly the same machine code output if you had written:

n *= 80;

I know this because for laughs I did a quick test and the compiler managed to unpick all the hand optimised bit-shift stuff into a single 'mult' instruction.

Even if the target cpu did not support hardware multiplication, I reckon a modern compiler would produce damn near identical code for both instances.

I know - it's one of the most common optimisations, because it's such a win

Of course, back in the days when the (machine code) shift-and-add would come up at about 10 cycles and a multiplication took at least 60, it was crucially important to know this stuff. Now, maybe not so much; but it's still worth having an understanding of how things work at a low level, IMHO

I notice that the MSDN C# documentation takes the lazy man's approach of using hex values in their section on using enumerations for bit flags. Pah! say I

Just about on-topic, in that it involves a bit shift, is this technique for optimising division - part 1 of 3, the other two getting even more beautifully weird and wonderful