That was not a switch statement learning example, it was a embedded usage example for why learning about switch is important.

It might be sufficient to simply add a comment before default: // TODO: Add meaningful functionality here.

Perhaps making things worse, consider Duff's device. Or maybe don't.

send(to, from, count)
register short *to, *from;
register count;
{
  register n = (count + 7) / 8;
  switch (count % 8) {
  case 0: do { *to = *from++;
  case 7:  *to = *from++;
  case 6:  *to = *from++;
  case 5:  *to = *from++;
  case 4:  *to = *from++;
  case 3:  *to = *from++;
  case 2:  *to = *from++;
  case 1:  *to = *from++;
  } while (--n > 0);
  }
}

 

It might be sufficient to simply add a comment before default: // TODO: Add meaningful functionality here.

Perhaps making things worse, consider Duff's device. Or maybe don't.

send(to, from, count)
register short *to, *from;
register count;
{
  register n = (count + 7) / 8;
  switch (count % 8) {
  case 0: do { *to = *from++;
  case 7:  *to = *from++;
  case 6:  *to = *from++;
  case 5:  *to = *from++;
  case 4:  *to = *from++;
  case 3:  *to = *from++;
  case 2:  *to = *from++;
  case 1:  *to = *from++;
  } while (--n > 0);
  }
}

Cute things like Duff's device using default fall-through is why airplanes fall out of the sky.
http://lkml.iu.edu/hypermail/linux/kernel/0008.2/0171.html

 

Hardware engineers that program believe in simplistic code and hardware redundancy.

Even on the smallest project we include fallback and fail-safes.

 

I'm presently working on a computer science degree. I'm just trying to decide which direction to go. I'm leaning toward the lower end of the stack. It just makes more sense to me for some reason. I'm really thinking about embedded programming, but that is more of a specialized field I think.

If you like the lower level stuff, and you're interested in embedded work, then consider computer engineering. Maybe go talk to a guidance counselor and/or some professors and nail down the differences between the two degrees at your school. With computer engineering, at least as of the time I was in school (1990's), you get both software and hardware design, so you will have a good foundation to work from no matter which way you go. I would expect some lower level stuff in computer science too as those guys come up with a lot of lower level solutions, but it won't have the hardware side of things. For example, my degree is in computer engineering. I worked primarily in software for almost 20 years, then a couple years ago I jumped over and started doing some hardware design, layout and embedded work. I don't think the jump would have been nearly as easy without the electrical side of my degree.

 

I was actually thinking about going into Electrical Engineering degree for the same kind of reasons. with a specialization in embedded. The computer engineering sounds like the same thing sort of. I can ask a counselor about what my school offers in that direction. Thanks for the suggestion.

 

What do you want to learn about C coding?

Start with the following:

• syntax and rules
• data types
• simple statements
• compound statements
• control structures: if-then-else, do-while, while-do, for ( ), switch-case
• global and local variables
• constant declarations
• programming style, indentation, naming conventions

 

Cute things like Duff's device using default fall-through is why airplanes fall out of the sky.
http://lkml.iu.edu/hypermail/linux/kernel/0008.2/0171.html

Perhaps, and I would probably code it up in assembly language if every cycle counted. But I'd argue plains fall out of the sky more for lack of testing. The page you linked describes how processor technology is changing how we approach efficiency in software. And again, the answer includes testing. To see if your unrolled loop is helping, test it, preferably on the real hardware. To see if it is worth the hassle, well that's another problem entirely.

So many years ago, I learned C using the book "C Primer Plus" by Waite et al. It was so long ago I don't remember much of what was in it, but it apparently served me well. And, to repeat what others have said, the only way to become proficient at C (or anything else) is by doing. Sure read a book, study an online resource. But write code. Lots of it. It's the only way IMO.​

 

Perhaps, and I would probably code it up in assembly language if every cycle counted. But I'd argue plains fall out of the sky more for lack of testing. The page you linked describes how processor technology is changing how we approach efficiency in software. And again, the answer includes testing. To see if your unrolled loop is helping, test it, preferably on the real hardware. To see if it is worth the hassle, well that's another problem entirely.

So many years ago, I learned C using the book "C Primer Plus" by Waite et al. It was so long ago I don't remember much of what was in it, but it apparently served me well. And, to repeat what others have said, the only way to become proficient at C (or anything else) is by doing. Sure read a book, study an online resource. But write code. Lots of it. It's the only way IMO.​

I would spec a faster, more powerful processor so I could write safe and clean software. I learned several Pascal based languages before C like Modula-2. This gave me a good platform to see just how careless some C programmers are.

 

Computer and electrical engineering are very similar, with electrical having slightly more focus on the electrical side of things. I worked with several electrical engineers working as software engineers on software projects over the years.

 

Before 3 months I have also the same query regarding embedded C programming and that time some one suggest me one site name where i can see the list of C programming tutorials submitted and voted by the programming community.

Check this - C programming Tutorials