Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have a code. like this:
int functionA (){
Foo(**,**,**);
return 0;
}
Foo() is a huge function(more than 10,000 lines). Which I don't understand all.Foo function includes some multi-thread code.
The problem now is, if I have "return" code right after Foo, Foo can be run correctly.
If I insert some other code (even a really simple cout code) between Foo() and "return". The Foo function will act weird(partly not run correctly).
I debugged this thing for 3 days. Nothing found.
If I insert some other code (even a really simple cout code) between Foo() and "return". The Foo function will act weird(partly not run correctly).
Sounds like Foo is corrupting the stack in some way. You'll probably find that declaring redundant variables (and hence changing the contents of the stack) "fixes" the problem.
I'd look for a tool that finds memory problems in your code. If you don't have such a tool, look really carefully at all the usages of allocated memory.
Related
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.
The community is reviewing whether to reopen this question as of 1 year ago.
Improve this question
I am slowly writing an emulator for a gameboy using C++, I am currently working on the CPU side of things. I have written a generic function that takes any two registers of the CPU and returns as a Word data type. As it is necessary to access individual registers and also a combination of registers.
const Word get_word(Byte *registerOne, Byte *registerTwo)
{
return ((*registerOne << 8) | *registerTwo);
};
calling this function gets tedious as you have to specify each register
get_word(&this->registers.h, &this->registers.l)
My question is if it okay to define a macro like so
#define get_HL() get_word(&this->registers.h, &this->registers.l)
since now I can call it using
get_HL()
The reason why I want to do it like this since I don't want to create more private/public functions that just perform function calls.
I have tried compiling and it seems to work as it should since its just a pre-processor macro but I am not sure of the design implication
EDIT:
Okay I mean there are glaring flaws with this and you should just make a function, just as much work to make a function or write a macro.
const Word get_HL() { return this->get_word(&this->h, &this->l); };
Let this be a post for people who had the same idea and hopefully stop making the same mistake
No, this isn't OK in my opinion. It hides what arguments you're passing into the function, and macros don't respect scopes and as such are highly susceptible to name conflicts. This seems like an ideal use case for a non-static member function.
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 had an interesting question. I have:
char buf[100]
And I decided to try using close(buf)
Code compiled, the program works. But is there any point in using close() like this?
Thank you.
Assuming "close" is the function from posix, most likely nothing will happen but it's also possible stuff could break badly.
Arrays in c and c++ decay to pointers, close takes an int. Implicitly converting a pointer to an int is not allowed by the c++ spec but some compilers allow it anyway (doing some testing it looks like modern g++ only allows it if -fpermissive is specified).
Most likely the integer that results from said conversion will be large, file descripters are usually small, so most likely close will just return a bad file descriptor error and do nothing but if it does happen to match a file descriptor then things could get interesing.....
It should not compile. The compiler should emit warnings.
The behaviour is undefined
No, there is no point in using close on a char array
There is also no meaning in doing that. What would you want to achieve?
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 8 years ago.
Improve this question
Is it better, from complexity eye of view, to call a function and return its value to another function
a = foo();
bar (a);
Or to make a nested call?
bar(foo());
Indeed, I am making this millions of times.
If it depends on something else, please mention it.
You should go for clarity - the compiler should optimize the temporary away. But if it's critical, benchmark and look at the assembly code.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Edit: I was only asking for a clarification on what my professor was requiring of me, I now understand what this requirement is saying and I believe that this has been thoroughly answered.
I have a project that i have to do for my c++ class and this is a requirement of the project.
Except for the print menu function, all user defined
functions(functions written by the programmer) must be called from
main. No user defined functions other than the print menu function can
be called from other user defined functions.
It is a strange requirement. During your homework you might write some functions. Or you might not, and your main() will be one unreadable big pile of lines that only you can read and understand, on a good day.
But, you can decide to pretify your code by moving some code from main() to some newly introduced functions. One function to read all data from input, one function to do something with that data, one function to write result to output. Such kind of things.
The requirement demands that all functions must be called only in main(). You must not call any function from any other function except main().
I guess this requirement makes it easy for the teacher to read your code.
That means you cannot nest functions, like this function definition
void A(){
int B();
}
then you are only able to call your functions from main()
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Just curious about how the return type of a function will have an effect on the program in C++. For example, the following three functions will do the same stuff but have different return types:
void myfun();
int myfun();
bool myfun();
Suppose void myfun() will be enough for my purpose as there is no need to return a value. However, I may still consider to use int myfun() as with the evolution of the development it is possible that this function need to return a value. So, if I use int myfun() rather than void myfun(), what kind of cost I will expect?
Absolutely bugger all. That's about equivalent to the cost of changing it. Don't give it a return value just because it might someday later need one. Keep it strictly to what you know you need.
a very slight cost indeed to allocate memory to store the return value on the stack..
but for general SW design - refactoring it not a bad word! design and write your code to be simple... the thumb rule is Simple is Better. if you don't need an int return value - don't define it. if you'll need one in the future - refactor your code!