+- Hack Forums (https://hackforums.net)
+-- Forum: Tech (https://hackforums.net/forumdisplay.php?fid=444)
+--- Forum: Coding (https://hackforums.net/forumdisplay.php?fid=151)
+---- Forum: Software Development (https://hackforums.net/forumdisplay.php?fid=118)
+---- Thread: [C] Help with #define (/showthread.php?tid=5464905)
Pages: Pages
1
2
Help with #define - SGUdyr - Nov 15, 2016
Picked up C recently, had a little problem with #define
I wanted to calculate circle's circumference, and I wanted to use #define to define Pi's value.
Code
#include <stdio.h>
int main()
{
int r; float C;
#define Pi 3.14
printf("r: ");
scanf("%d", r);
C=(2*r)*Pi;
printf("%f", C);
getch();
}Program obviously crashes when I enter r, so what to do here? Ty 🤝
* - Yuuki - Nov 15, 2016
![[Image: 0xsTYtJ.png]](https://i.imgur.com/0xsTYtJ.png)
Seems to be working fine when I compile it (with some changes).
Can you try using my changes and see if it works? The problem may not be related to #define, but rather your scanf()
* - SGUdyr - Nov 15, 2016
My bad, forgot the & in &r.
Appreciate it.
* - Sajuuk - Nov 15, 2016
I don't know if anyone else has been told this, but according to my professors "C-style variable declarations, where they're all at the top of the code right below where the main function opens, make the code harder to read and makes it more difficult to trace errors back to their variables". I have a hard time understanding how that reference is even valid, as most compilers throw the line and variable name in which the error occured (as well as the character in the line where the error begins).
As an alternative, we are instructed to initialize the variable right before it is to be used in the first function that uses it. I never have done that, and most likely will never do such a thing, it just seems ridiculous even when dealing with larger projects. The developer will know what variables initialize to what when he chooses to initialize them. Arithmetic operations later on in the program are a whole different story, but I don't know if I can relate this concept to defining preprocessor macros. I've never seen anyone define any keyword within the main function. I'm not sure if a keyword defined within a function acts the same as keywords up at the top with the include macros, or if it is limited to that function in which it was defined.
* - Hash G. - Nov 15, 2016
Well I know you don't have this problem anymore, but just a general recommendation:
Always always put #define in a .h file and if you can't, put#define at the top of your .c file.
Macro's names always in uppercase, so it should be PI instead of Pi.
* - Sajuuk - Nov 15, 2016
(Nov 15, 2016 05:18 PM)Hash G. Wrote: Well I know you don't have this problem anymore, but just a general recommendation:
Always always put #define in a .h file and if you can't, put#define at the top of your .c file.
Macro's names always in uppercase, so it should be PI instead of Pi.
I'd only say put defines in a header when a header is actually needed, which in most if not all large projects there will be at least one if not numerous custom headers. And yes, terms that are #define'd are constants, so (technically speaking) they should be uppercase.
* - RDCA - Nov 15, 2016
Quote:Always always put #define in a .h file and if you can't, put#define at the top of your .c file.
Eh, this isn't something you should say always about.
* - Sajuuk - Nov 15, 2016
(Nov 15, 2016 08:36 PM)RDCA Wrote: Eh, this isn't something you should say always about.
With smaller projects it's fine so long as you're gonna end up using the same defines in one program. However when there are a massive number of #define's required to compile such an app, not to mention the individual files you might be subjected to split the entire source into, in those cases it is essential to define everything in a separate header.
* - RDCA - Nov 15, 2016
(Nov 15, 2016 08:45 PM)Sajuuk Wrote: With smaller projects it's fine so long as you're gonna end up using the same defines in one program. However when there are a massive number of #define's required to compile such an app, not to mention the individual files you might be subjected to split the entire source into, in those cases it is essential to define everything in a separate header.
How big a project is doesn't really affect whether you should put something in a header file or not.
* - Sajuuk - Nov 15, 2016
(Nov 15, 2016 08:52 PM)RDCA Wrote: How big a project is doesn't really affect whether you should put something in a header file or not.
"As big of a project" by what's supposed to be in headers. Definitions, universal includes, etc. I didn't mean to imply that I might be using the entire project's size, source code and all, when saying that. Just standard header stuff. How the fuck did all of this pop out of me noting a #define within his main function??
* - 0xDEAD10CC - Nov 15, 2016
system() does not come from the <Windows.h> header either -- nobody mentioned this. It comes from the <stdlib.h> header (<cstdlib>), and calling system("pause") is undefined behavior. There are better platform-independent ways of waiting for user-input to synchronously halt execution. Therefore, the <Windows.h> header here is redundant.
* - Sajuuk - Nov 15, 2016
(Nov 15, 2016 10:40 PM)0xDEAD10CC Wrote: system() does not come from the <Windows.h> header either -- nobody mentioned this. It comes from the <stdlib.h> header (<cstdlib>), and calling system("pause") is undefined behavior. There are better platform-independent ways of waiting for user-input to synchronously halt execution. Therefore, the <Windows.h> header here is redundant.
I actually had to scroll back up to find the screenshot that actually had a system() call. Yuuki's code ran either because he compiled it with a different source (other than the one shown) before he took the screen or because his copy of <windows.h> includes <stdlib.h> for some reason (which makes no sense at all). Or, if not one of those two, he did include <stdlib.h> but the screenshot cut it off.
* - Infinity. - Nov 16, 2016
(Nov 15, 2016 02:46 PM)Yuuki Wrote:
Seems to be working fine when I compile it (with some changes).
Can you try using my changes and see if it works? The problem may not be related to #define, but rather your scanf()
Only MSVC picks up 'scanf' and doesn't accept it.
Codeblocks still accepts scanf. If the problem was scanf then OP wouldn't be able to compile the problem given that he is using VS.
(Nov 15, 2016 05:18 PM)Hash G. Wrote: Well I know you don't have this problem anymore, but just a general recommendation:
Always always put #define in a .h file and if you can't, put#define at the top of your .c file.
Only if you do #pragma once for your includes. I maybe wrong though.
* - 0xDEAD10CC - Nov 16, 2016
(Nov 16, 2016 03:41 AM)Infinity. Wrote: Only MSVC picks up 'scanf' and doesn't accept it.
Codeblocks still accepts scanf. If the problem was scanf then OP wouldn't be able to compile the problem given that he is using VS.
Only if you do #pragma once for your includes. I maybe wrong though.
What are you talking about?? :S
VS does "accept" scanf(), it has nothing to do with the IDE or the compiler really, just that Microsoft's compiler will provide warnings about those functions unless you disable them. This doesn't mean that it won't compile. Don't spread around lies like this...
And #pragma once also has nothing to do with #define's.
* - Infinity. - Nov 16, 2016
(Nov 16, 2016 11:04 AM)0xDEAD10CC Wrote: What are you talking about?? :S
VS does "accept" scanf(), it has nothing to do with the IDE or the compiler really, just that Microsoft's compiler will provide warnings about those functions unless you disable them. This doesn't mean that it won't compile. Don't spread around lies like this...
And #pragma once also has nothing to do with #define's.
oops sorry, yes it gives warning, i wasn't aware that you can disable them, i don't know much about VS, I am new. Show me that it compiles without disabling warnings.