Hey guys, I'm new to arduino...
For some reason, when I input #define into the sketch, when I try to compile, the program tells me something along the lines of #define not actually being an operator.
I'm running Arduino-0018, with a Duenomilanove.
instead of #define, I use int or byte to define a constant. Am I doing something wrong, or does #define only work with older boards?
My Ouiji board is missing some parts, and my crystal ball is cracked.
Vaguely worded questions, with phrases like "something along the lines of #define not actually being an operator", don't get good answers, here.
Am I doing something wrong, or does #define only work with older boards?
#define is part of the C language. It has nothing to do with what board you have. So, yes, you are doing something wrong. What, you ask?
Waving your hands in the air, posting vague questions, leaving out any code, and failing to post specific error messages.
Would you like to try again?
Lol, sorry for the vague question. I've just started with Arduino and don't yet understand much.
What I meant to ask was, in many example codes, the "#define" portion of the code was used. When I use #define in my code, the program does not change the color of the word to indicate that i've used any sort of syntax operator. I am simply wondering, is "#define" an outdated form of code that is no longer necessary, or am I misusing it?
Certain words are color coded to show that the IDE has assigned some significance to the word (i.e. it recognized that it is spelled correctly). Since #define is a pre-processor directive, and means nothing specific to the IDE, it doesn't get color-coded.
#define is not outdated. Whether you are using it incorrectly, or not, is impossible to tell. You have not provided anywhere near enough information.
I hope this general info is helpful.
A #define statement should be on a line by itself.
It does not use an equals sign
It is not terminated with a semicolon
It should be placed at the top of your file
Example:
#define pinGPS 3
The "pre-processor directive" thing PaulS is talking about means wherever the name pinGPS appears in code, the number 3 will be substituted.
Prawnhead.
The "preprocessor" is a most powerful tool in C; it can be helpful to learn a little bit more.
E.g.:
#define SWITCHSTATE digitalRead(switchPin)
#define SQR(X) (X*X)
#define MAX(X,Y) (X<Y?Y:X)
Note: It is considered good practice to write all define-macros in upper case, to avoid confusion when reading the program text, as it need no longer look like correct C.
E.g.:
#define WITHPAR(Y) (1,A,Y,I++);
can be used as:
aRoutine WITHPAR(33)
The preprocessor just expands text, unaware of anything like C syntax.
Prawnhead left out one important piece of info:
A preprocessor directive (incuding #define) MUST begin in column one!
Prawnhead left out one important piece of info:
Actually, the Original Poster left out some important info, as PaulS stated.
The OP didn't show his #define directive or how he tried to use it. He didn't show any code.
A preprocessor directive (incuding #define) MUST begin in column one!
No, it doesn't have to begin in column 1.
As far as Prawnhead's comments:
Depending on how it is going to be used, there are lots of valid ways to write a #define directive:
Of course, it is also possible to write invalid #define directives that have one or more of these little items or to write valid #define directives and then use them improperly, but they are not prohibited by the language.
Bottom line:
To the Original Poster:
How the heck can anyone guess what the problem really is unless we see some code? And, as was previously noted: How about posting the exact error message? Why should we try to guess?
Regards,
Dave
;D
As this seems to escalate into a C manual, I am happy to add this:
That is why many of us software challenged types just LOVE C/C++. It's 'rules' sometimes seem to be as variable as the ones in the bible. 
OK, it get that the preprocessor in not C, but still, just saying... :
Lefty
'rules' sometimes seem to be ... variable
The "rules" are not ambiguous. There are ISO language standards for C and C++. Not all compilers are completely compliant with all of the rules, but, in my experience, there are not very many exceptions as far as the preprocessor is concerned.
In particular, the preprocessor is part of the C and the C++ standard language specifications, and its use is defined therein. That is, there are certain, well-defined, rules about the various forms that #define directives can take and where they can occur in a program.
People's ideas of "good programming practices" sometimes add restrictions and conventions that may make things more readable and consistent to (some of) us mere humans, but the compiler never gets confused.
The driving philosophy of Arduino is to get people up to the point of doing some interesting things with their hardware without going through the agony (and ecstasy) of actually learning a lot of the details of C and C++. It works better for some people than others.
A valuable service of this forum is to let people ask questions and try to get meaningful help without just being told to go read a textbook.
Complicated function-like macros are the bane of anyone (that I have ever known) who has to maintain and debug OPC (Other People's Code).
On the other hand, lines like "#define buttonPin 2" aren't too hard to understand and to use, but people who don't have a lot of experience can't understand why putting a semicolon at the end can (sometimes) create problems when a #define macro is used.
If people look at working examples and make simple changes (like changing the definition of buttonPin to something other than 2), they may be able to lead full, rich, rewarding lives without ever descending into the lowest levels of hell where the real #define macro wogs reside.
Bottom line:
That's why we need to see the actual code instead of having someone tell us that they tried "it" and "it" didn't work and they got an error message "along the lines of..." (This is true, no matter what "it" is.)
Regards,
Dave
Footnote:
The "best" advice, according to some "real" C++ applications programmers that I have known might be not to use #define lines at all, just use a const variable declarations or some such thing for simple macros and to use "inline" functions or, maybe, function templates instead of function-like macros.
However since the #define processor directive is well defined (and not absolutely obsolete) and since some people ask about them, I think that trying to give advice about them is not a disservice to beginners (or not-so-beginners). I do believe that making up a bunch of stuff that has no connection to the real "rules" of the language can be confusing in the abstract.
Hear, hear!