Printable View
Ok thanks to everyone who helped me figure out how to use makefiles.
Now that i have, i've got an obsession for converting as much of my code into functions as i can!
My question is this:
I use this a lot ( A LOT!)
Is it possible to make this a function such as setupxyz( Some Code Here ); ?Code:for (x = 0; x < number; x++)
{
for (y = 0; y < number; y++)
{
for (z = 0; z < number; z++)
{
//Some code here
}
}
}
Not generally, no. It can be done with advanced techniques such as function pointers. But the best way to do this I believe is to use macros or simply to create a macro in your IDE that pastes that code when you need it.
Oh that sounds cool! It would certainly speed things up a bit! I'm not using an IDE as such, just kate and gcc. How would i go about it? Or is it more to do with the editor?
Basically is there something i can type that gcc will interpret as the above code or do i just set up a macro in kate?
Macros are a feature of the C language:
Will translate into your loop with my_code_here inserted into where you want the code in the loop.Code:#define MyLoop(mycode) \
for (x = 0; x < number; x++) \
{ \
for (y = 0; y < number; y++) \
{ \
for (z = 0; z < number; z++) \
{ \
mycode; \
} \
} \
}
int main()
{
MyLoop(my_code_here);
}
Thats great! Thats gonna save me some time and shorten my program!
Can i put macros in my header file or do they need to be in the main source file?
They can be anywhere you want.
Changed it a little bit so now i can insert code wherever i like :D
AND it works when i stick it in my header file!!Code:#include <stdio.h>
#define setup_xyz(after_x, after_y, after_z) \
for (x = 0; x < number; x++) \
{ \
after_x; \
for (y = 0; y < number; y++) \
{ \
after_y; \
for (z = 0; z < number; z++) \
{ \
after_z; \
} \
} \
}
int main()
{
int number = 3;
int x, y, z;
setup_xyz( printf("\nafter_x"), printf("\nafter_y") , printf("\nafter_z"));
}
This is honestly going to take about 300 lines out of my code!! Thanks A LOT!!
Simon.
It might be my C++ background showing, but I would rather use the core language than resort to the preprocessor if the core language features suffice. In this case I think function pointers may well suffice:
The trade-off is that you have an extra function call (I do not think function pointers are easily or often inlined).Code:#include <stdio.h>
void run_loop();
void foo()
{
printf("Hello world!\n");
}
int main()
{
run_loop(2, foo);
return 0;
}
void run_loop(int number, void (*func)())
{
int x;
for (x = 0; x < number; x++)
{
int y;
for (y = 0; y < number; y++)
{
int z;
for (z = 0; z < number; z++)
{
func();
}
}
}
}
Aside from the preprocessor, the little more advanced method might be function pointers, but it might just make your code into a big mess with lots of functions. Function pointers are basically pointers that point to a function. So inside that little loop, it can call the function you supply, even with parameters, but it might be that you get a lot of functions all around, so I suppose you can use a mix of both methods.
Case you're interested in this, I might show some examples.
I don't even know how to use function pointers! Think i'll stick to macros just now!
I've already started converting my program over to using macros! :D
Macros aren't the safest thing in the world to use and is mainly C, which is why we suggested that you might also use function pointers, because they're very handy too.
I'm not a great fan of macros. Particularly multi-line macros. They make debugging the code horrible - and sooner or later you will be debugging your code, I promise.
If you really want to do things at the outer, middle and inner loop iterations, then you probably should be writing out the whole code. You can always "copy'n'paste" if you have some code that is similar to what you need this time, then strip out stuff and add the new bits [but beware of "copy'n'paste" bugs that sneak in - because you don't check what all the code does, you end up with "extra" or "missing" bits in the code].
--
Mats
Another tip might be to actually write and debug the code you put into the macro first so you don't screw up. The compiler will complain at your macro, but it can't pinpoint exactly what in the macro is wrong because you see one a single line - the macro name.
So use them carefully.
Oh, yes, that's another problem with multi-line macros - the compiler says "error in line 532", which just shows you the macro-line with it's arguments. You don't know at all what is actually wrong in there, unless you start looking at the pre-processed code, and then compile that to get the new line-number.Quote:
Originally Posted by Elysia
--
Mats
so i'd be as well just typing it out each time?
There are a lot of places in my program where i use the above construct. with code sometimes after x or y etc.
Its not bad programming practice to leave them as is?
I sort of thought that if i just typed out the entire program, as is in one source file that it would be considered bad practice?
Multiline macros are very powerful and used correctly, is the right thing because it makes the code more managable. But this particular case sounds like "not the right place".
There are several things to consider when writing code:
1. Readability. The ability for a new reader [or yourself after 4 months] to read the code and understand what it does. Multiline macros make the code harder to read, because you need to understand what's happening in the macro expansion.
2. Debuggability. The ability to understand what goes on inside the macro, when single-stepping the code in a debugger is nearly non-existant [unless you switch to assembler mode, and step through the assembly code - doing that for a three-level nested for-loop macro would NOT be my idea of "easy", and I have done my fair share of debugging in assembler]. Most C debuggers treat one source line as one step, so when you step on a line that contains your multi-line macro, then it will just do ONE step all across the entire macro, not one portion at a time.
3. Portability/extensibility. The ability to change the code to do something slightly different. Again, multiline macros make this very difficult.
4. Performance. Multiline macros make little difference here.
In the end, it's your code, you decide how you solve your problems. But I think you are doing this "because it's hard work typing", rather than because you're concerned about some of the above.
--
Mats
Safest bet, yes. Should you do it? Up to you.Quote:
Originally Posted by AmbliKai
It's bad programming practice to leave your loops intact. If, however, you use similar code after, before and in your loops, you can do the function pointers method, which is much more preffered.Quote:
Originally Posted by AmbliKai
Bad practice? Well, maybe. You usually use different files to separate different parts of the program. Different dialogs might have different files. Different classes might have different files. Yes, I would suggest that you do split your project and code in files since it's also much easier to read and work with rather than one file with 100.000 lines of code.Quote:
Originally Posted by AmbliKai