Hello. I am trying to find new and exciting ways to optimize (read: shrink down) my current code and want to include an eeprom autorefresh option to cut down on variables. Basically, when I have the AutoRefreshCompile option set, I want it to create the variable "randomvariable". My code is pretty simple:
#define AutoRefreshCompile 1 #if(AutoRefreshCompile==1) { // line x extern signed short randomvariable; } // line y #endif
I am getting errors that read as follows:
VARS.H(x) error C141: syntax error near '{' VARS.H(y) error C141: syntax error near '}'
I'm guessing it is not possible to do this (if I remember correctly, variables have to be declared at the beginning and can't be in the middle of functions/code segments but maybe it's some really simple fix.
I realize this might not work but I figure it's worth a shot. Any suggestions? Thanks!
Yes, of course they do!
The braces are syntactically significant in the 'C' programming language.
eg,
if( condition ) a; b;
is not the same as
if( condition ) { a; b; }
is it?
You need to take care to distinguish between statements and preprocessor directives.
preprocessor directives are easily distinguished by the fact that they begin with a '#'
Braces group a number of statements into a compound statement or block - they have nothing to do with preprocessor directives.
This is standard textbook stuff - nothing specifically to do with Keil.
Heh, of course I know those two are different (in fact, if you look up a couple of posts, it's pretty clear I stated this already). Using brackets is actually not an issue in normal .C files either, which is why I hadn't seen this issue til now. The issue is specific to .H files and I already summarized to Erik where it appears my understanding was incorrect.
While I appreciate your help (particularly your next post, which explains the difference between statements and directives, which it appears is exactly where my understanding is lacking and I plan on doing some more reading on this after this post), sometimes I don't understand your posts. I can't decide whether the intention is to make obvious statements that we both know the answer to, to make me feel stupid, or if you didn't read some of the previous posts.
For the record, if you (or anyone else, really) had told me a few posts ago that my fundamental understanding was in directives vs statements rather than telling me to go find a C book and start reading, it could've saved us all a lot of time. Generic recommendations like "read a book" aren't anywhere near as helpful as saying "you need to read a book about the difference between directives and statements".
I'm not trying to pick on you in particular, I believe you are trying to help. But as someone who does have a decent overall understanding of C but is lacking in specifics (as you and some others were correct to point out), sometimes people just need direction where to look.
All the same, thanks everyone for your help!
you sayed@
I can't decide whether the intention is to make obvious statements that we both know the answer to, to make me feel stupid, or if you didn't read some of the previous posts.
lol. u make me laff m8. his fav is Please read the manual! condescending wonka :)
"Using brackets is actually not an issue in normal .C files ... The issue is specific to .H files"
Incorrect.
".c" and ".h" files are purely a matter of convention (although a convention established over decades of use, so you'd do well to observe it) - they have nothing to do with the language syntax or semantics.
Remember, the compiler sees nothing of ".c" and ".h" files: all it ever sees is the result of the preprocessing of these (or any other) files.
"if you (or anyone else, really) had told me a few posts ago that my fundamental understanding was in directives vs statements rather than telling me to go find a C book and start reading, it could've saved us all a lot of time"
The trouble is, it takes a while to dig-out & realise exactly where it is that your understanding is lacking. Especially via a forum such as this.
Note that I did specifically ask you why you were using braces with #if - I was beginning to suspect that you weren't clear on the difference between #if (as a preprocessor directive) and if (as a language statement).
It's (relatively) easy to see where someone's made a mistake; far harder to discern the reasons why they made that mistake - what it is that they have misunderstood or not understood.
You complain about having "obvious" things pointed out to you but, to most contributors, I guess that it is "obvious" that you don't use braces with #if
"as someone who does have a decent overall understanding of C but is lacking in specifics"
I'm sorry, but it really does appear from your posts (which is all we have to go on), that you don't yet have a "decent overall understanding of C" - there do seem to be some rather large & important gaps in it.
As previously noted, in a forum like this, all we can do is try to spot errors & misunderstanding as they come up - like the issue of ".c" and ".h" files in this post. If we try to guess at things that you might not understand, you tell us it's "obvious".
Hence I really do think that what you need is a decent textbook, and to go through it methodically - not just picking bits here & there as they come up. K&R should be fine - the tutorial part is just over 160 pages.
Or maybe take an "advanced" 'C' course? Or find a mentor/tutor who can help you one-to-one, in person?
After all, this forum is supposed to be about Keil tools - not the details of the 'C' language.
Utter nonsense. You would have saved a lot more time if you had actually properly read a C book. As Andrew said, K&R is only 160 pages. Curly brackets and statements is fundamental stuff. It's rather obvious that you are not into reading books. Apparently, you prefer to dive into coding and sort out problems through forums. That's OK, but don't expect much sympathy from people who gained knowledge the old-fashioned way. And may I say, your way of learning is rather inefficient.
Actually, I said the tutorial part is only about 160 pages - in addition to that, you get another ~110 pages of reference.
For reference, I prefer to use the standard.
www.open-std.org/.../n1124.pdf
Yes, it's a draft of C99. Should be good enough for most needs anyway.
But note that C99 allows declarations anywhere within a block - not just at the start.
I don't think C51 allows this?
http://www.keil.com/product/isoansi.asp
Trying to use C99 features in pre-C99 compilers (like C51) is a not-infrequent source of problems on forums like this...
http://www.keil.com/support/man/docs/c51/c51_xa.htm
Using brackets is actually not an issue in normal .C files either, which is why I hadn't seen this issue til now. The issue is specific to .H files NO!, NO!, NO!
brackets are specific to (a group of) statements and screw up preprocessor directives, whether in a .c or a .h file.
sometimes I don't understand your posts. I can't decide whether the intention is to make obvious statements that we both know the answer to, to make me feel stupid, or if you didn't read some of the previous posts not to make you feel stupid, but it is clear you are confoosed. DO NOT 'hurry up and get going' get this down solidly before you go on. As stated above, you have still some preconceived issues remaining. FORGET what you 'thought' and start from scratch learning this.
if you (or anyone else, really) had told me a few posts ago that my fundamental understanding was in directives vs statements rather than telling me to go find a C book and start reading, it could've saved us all a lot of time. an answer in a post will clear up e.g. a set of misplaced brackets and nothing else. Reading a book will make you get the concept.
Erik
No, that's not true.
If the preprocessor directives, after preprocessing, leave any syntax error, then you'll get diagnostics about those errors.
In this case, the preprocessor directives, after preprocessing, left misplaced braces - so the OP got diagnostics about those misplaced braces.
It's not that the braces in any way "interfered with" or "screwed-up" the preprocessor directives.
It's people like you I don't get. This forum already has plenty of people who add nothing to a technical discussion and only seem to pop in to berate someone for their approach on a subject or their lack of knowledge. Add something to the conversation or go away. There are already too many of you.
That entire last paragraph was unnecessary. You could have just as easily stated your concerns in the way Neil did without judgemental statements but you had to go that extra mile to be an ***.
And you don't know anything about me or my approach.
Andrew, I think I understand a bit better where you're coming from. From my perspective, it was asking a pretty pointed question about what I was trying to achieve but I can see how it would point to a missing fundamental or confusion as to what I do or don't understand.
I HAVE taken classes and I HAVE read books but I will admit, it's been a while and I've been coding primarily Atmel and Visual Studio for the past few years (I'm primarily a hardware engineer and doing a lot more coding than I originally thought I would). I recently have had to take up C for this project and need to do some brushing up, clearly. And unfortunately, there are no "mentors" around. Most of our senior engineers were laid off when the economy went downhill and I've had to take on some software/firmware since we no longer have people that do that. Honest truth, we have more projects than time so it's often easier to ask the experts and be pointed in the right direction. I don't mind being corrected though I definitely don't like the general approach in these forums (the formula looks something like this 1) point out person doesn't have any idea what they were talking about 2) make the person look like an idiot for not knowing this 3) tell them to read a book or stop coding altogether 4) Insert at least one unnecessary statement added to either make yourself look better and/or to make the other person sound like an idiot. See Mike's post below, he seems to have it down).
Thanks for taking the time to clear up the confusion with this. I appreciate the honesty.
... from all that stamping in the floor.
Honest truth, we have more projects than time so it's often easier to ask the experts and be pointed in the right direction you were: "Read about #if... in a C book"
If you really want to be honest, then, if the specific answer to the particular issue in the first post you posted was the best response, then WHY did you come back with more #if ... issues?
If you had read the chapter on #if ..,. etc (which in most books is 3-5 pages) you would have had all these issues solved in, say, 10 minutes, instead of endless discussions in this forum.
if you have specific questions that are not, as this thread, VERY basic C then please come back.
re making the poster feel stupid. Nobody but yourself can make you feel stupid. If you are one of those that promote political correctness, get out of microcontrollers, you will find very few friends among the pros.
Add something to the conversation or go away
what about your last posts that are nothingn but WAAAAAAAAHH. how muct do they "Add to the conversation"