A "should never get here" line in a method [closed] - c

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I find myself writing functions with this line and I always feel a little bad about myself when doing it. Do other people do this? Is it bad practice?
void f()
{
while(true) {
// ...
if(condition)
return;
}
//should not get here
assert(0);
}

Depends on how critical it is that the code never get to that point.
If I have code that absolutely can't be allowed to fail, I frequently put in checks for non-allowable conditions that shouldn't be able to happen.
If it's a case/switch statement, I always put in a default with an error handler even though it should never be able to get there.

Do other people do this? Is it bad practice?
Yes, other coders do this. No, it not not bad practice, just weaker than alternatives.
The reason it is weak is reflected in this question. It draws unnecessary attention to a coding style that has other good alternatives. Why code in a manner that looks wrong? Even if OK here, it encourages reviewers to become nonchalant about seeing other loops without a clear exit - that in itself is not good.
void f() {
while(true) {
// ...
if(condition) {
break;
}
// ...
}
}
If there is a good reason to code in OP's exceptional style, it deserves comments to explain why to not waste time of reviewers, maintainers or anyone reading the code.
void f() {
while(true) {
// ...
if(condition) {
// Clear documentation why the above layout does not work
return;
}
// ...
}
//should not get here
assert(0);
}

Related

Should I put the game logic inside the draw loop? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I'm making a simple game using CSFML and am wondering if I can make my code more efficient.
Right now the code looks like this inside the main function's game loop:
// game logic
for (int i = 0; i <= perf.arramount; i++)
{
UpdateBody(&body[i]);
}
// clear
sfRenderWindow_clear(window.window, window.bg);
// draw
for (int i = 0; i <= perf.arramount; i++)
{
sfRenderWindow_drawRectangleShape(window.window, body[i].rect, NULL);
}
// display
sfRenderWindow_display(window.window);
I was told to do things in the order: logic, clear, draw, display. However, would there be any issues with me putting the logic inside the draw loop like this?
// clear
sfRenderWindow_clear(window.window, window.bg);
// draw
for (int i = 0; i <= perf.arramount; i++)
{
UpdateBody(&body[i]);
sfRenderWindow_drawRectangleShape(window.window, body[i].rect, NULL);
}
// display
sfRenderWindow_display(window.window);
Would it slow down the draw calls or make the code more efficient?
I'm not sure if this specific library may be different from others, so even a general answer is appreciated.
How to structure your game is your design decision.
You will be the first to notice problems with it.
But here is my experience. I learned that in the game logic loop you have calculations which are definitly needed, they also tend to need information on how much time has passed. In the drawing loop you just need to visualise the result of the calculations. As soon as you are going to split into threads, the timing of the need to calculate and to visualise will change. You are likely to want to calculate more often than you draw, while you want to draw always completly (except for more advanced FPS-based level of detail rendering....).
So there are multiple aspects which might make you want to keep those two things apart.
What I did was having a calculation step (which by my design gets real time information as a parameter of elapsed seconds) and a separate drawing step. That way you can have them in one parent loop, but you are free to move them at any point AND you are protecting yourself from confusing those two steps.

C - Passing a single variable instead of an array [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'm facing an issue on a PIC from Microchip but my question is more general. This will help me check if it is an issue from my code or from the debugger of MPLAB X which is sometimes buggy.
So here is my question, let's say I have this function:
int test( int *array )
{
int a = array[0];
return a;
}
Now, if I want to pass an array it's working, there is no issue. But let's say I want to use a single variable instead of the array like this:
int main()
{
while(1)
{
int test_variable_1 = 8;
int test_variable_2 = test( &test_variable_1 );
}
return 0;
}
I did not use an array but for me this should work as expected since the test_variable_1 is like an array of size of one int.
EDIT QUESTION: So, is it possible to pass a single variable like this (using the pointer with &) instead of a real array into an function? Also, is it a good/bad practice?
Thanks in advance and don't hesitate to tell me if I'm unclear.
Have a good day!
Adrien
So, is it possible to pass a single variable like this (using the pointer with &) instead of a real array into an function?
Yes. In fact C doesn't even know that you passed an array. For details, see Do pointers support "array style indexing"?
Also, is it a good/bad practice?
It's fine. Though ideally the function should take the number of items as one of the parameters passed.

Which code style is better in terms of readability and performance? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am wondering which code style is better for
human readability
program performance
Let's imagine we have 2 functions:
// first one
void foo(void) {
if (error)
exit(1);
....
}
// second one
void bar(void) {
if (!error) {
....
}
else
exit(1);
}
Both of them work in the same way in terms of execution, but which code style is preferable?
If I had to choose out of these two only, I'd choose the first one.
Reason:
It's simple. (does not use any operator like !)
It does not need comments to explain what happens inside.
(self-readable code)
It avoids extra pair of { } which makes the code more readable
Both performs nearly the same, I highly doubt there will be a
difference in performance.
Hence, first one is preferable.

Different placement of curly braces [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Sometimes when I look up videos at Youtube for better explanation and usually these people places the curly braces differently.
Note that , I'm new to the coding world.
1st placement.
for(int i=1 ; i < 6 ; i++)
{
//Statements
}
2nd placement
for(int i=1 ; i < 6 ; i++){
//Statements
}
These 2 codes actually functions the same , it just has different placement of the curly braces.
What's the difference of these 2 placements? Why do some others use the 2nd placement instead of the first one? I actually prefer the first one, because its easier to spot errors and looks neat.
1st and 2nd are the same.
The only difference is the coding style.
While you work for a company X they tend to use one coding style just for the sake of consistency. It does not matter if you use the first or second style as long as you are writing it, in the same way, all the time.
It just might confuse other developers who will have to read your code at some point.

Caching is orthogonal to recursion... Explain? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 13 years ago.
Improve this question
Although it's true that some
recursive-nameserver configurations
are (sloppily) referred to as
"caching", e.g., by
RHEL/Fedora/CentOS, that's a really
bad name for that function -- because
caching is orthogonal to recursion.
Theoretically, you could write a
nameserver that does recursive service
but doesn't cache its results. (That
would be a bit perverse, and I don't
know of any.) Conversely, nameserver
packages that cache but know nothing
about how to recurse and instead do
less-helpful alternative iterative
service are common: dnsmasq, pdnsd,
etc. ... ...
Above text source: http://linuxgazette.net/170/lan.html
Please explain what does the author means by "caching is orthogonal to recursion" ?
From Wikipedia's definition of orthogonal:
For example, a car has orthogonal
components and controls (e.g.
accelerating the vehicle does not
influence anything else but the
components involved exclusively with
the acceleration function).
The author is saying that whether a nameserver caches is nothing to do with whether it can recurse.
caching is orthogonal to recursion?
Caching doesn't require/imply recursion.
The term "orthogonal" is meant to be interpreted from a mathematical sense loosely has "the things have nothing in common i.e. separate concepts".
It mean it is one feature is independent with the other one. Or have bothe feature have no influence with the other one. So they can be implemented independantly
in a programming point of view, two orthogonal features
do_work(bool feature1, bool feature2)
{
// do common work
if(feature1)
{ //... do this }
// do common work
if(feature2)
{ // do work }
// do common work
}
or: if they are not orthogonal:
you need to do this: ( and it may have case where you cant combine the two feature.
do_work(bool feature1, bool feature2)
{
if(not feature1 and feature 2)
{ //... do this }
else if(feature1 and not feature2)
{ // do work }
// else impossible or different behavior
// etc..
}

Resources