![]() |
|
#1
|
||||
|
||||
conditional compile logicHello all. Could someone clarify this for me? I am a bit confused on the logic behind condidtional compile statements.
Code:
Hmm, now that I post this I think I got it. Well, let me just talk it though anyhow, to make sure. First Example Either WIN32 or __EMX__ must be defined to continue. If that is true __CYGWIN__ must not be defined to compile that block. It would evaluate the same if the WIN32 and __EMX__ were wrapped in parentheses. WIN32 defined CYGWIN not defined == COMPILE EMX defined CYGWIN not define == COMPLE Second Example WIN32 is defined and __CYGWIN__ is not defined or __EMX__ is defined the block will compile. WIN32 defined CYGWIN not defined == COMPILE EMX defined == COMPILE Hmmm, this seems a bit odd to me. I thought they would evaluate to the same thing. Perhaps, since EMX is an OS2 port of gcc EMX would never be defined when CYGWIN was. Oh well, the basics of my question seem to have been answered by the OP. Maybe someone else will find this helpful. Mark __________________
"Opportunity is missed by most people because it comes dressed in overalls and looks like work." --Thomas Alva Edison "Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety." --Benjamin Franklin "A happy person is not a person in a certain set of circumstances, but rather a person with a certain set of attitudes." --Hugh Downs |
||||
|
#2
|
||||
|
||||
Re: conditional compile logicI'll correct that a little bit.
This: CPP / C++ / C Code:
CPP / C++ / C Code:
defined(__EMX__) && !defined(__CYGWIN__) is a separate entity. So, If defined(WIN32) is true, irrespective of the other things, it will compile. And if defined(WIN32) is false, it will compile only if: defined(__EMX__) is true, and defined(__CYGWIN__) must be false. So: Quote:
The second one: CPP / C++ / C Code:
CPP / C++ / C Code:
!defined(__CYGWIN__))|| defined(__EMX__) is a separate entity. So, Quote:
Regards, Paramesh. __________________
Don't walk in front of me, I may not follow. Don't walk behind me, I may not lead. Just walk beside me and be my friend. Last edited by Paramesh : 03-Dec-2005 at 07:49.
Reason: Comment edited
|
|
#3
|
||||
|
||||
Re: conditional compile logicQuote:
Wouldn't be the first time, won't be the last. Your explanation is making my head hurt. This is what I get from it... The || and && are evaluated by order of precedence. In your explanation, && is higher. Something seems odd to me. Based on where I pulled this from (FLTK sources) that should not be true. I guess it's time for some additional testing... Thanks Paramesh, I appreciate the response. Mark __________________
"Opportunity is missed by most people because it comes dressed in overalls and looks like work." --Thomas Alva Edison "Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety." --Benjamin Franklin "A happy person is not a person in a certain set of circumstances, but rather a person with a certain set of attitudes." --Hugh Downs |
|
#4
|
||||
|
||||
Re: conditional compile logicI tested this on Visual C++, and MingW. I dont know why this differs from FLTK sources. But Yes. I think Different compilers have different implementations.
For those who want to know how to test this: Use 1 and 0!!!! Like these: FIRST: CPP / C++ / C Code:
CPP / C++ / C Code:
CPP / C++ / C Code:
SECOND: CPP / C++ / C Code:
CPP / C++ / C Code:
CPP / C++ / C Code:
So, go on and test with whatever options you have!!! Regards, Paramesh. __________________
Don't walk in front of me, I may not follow. Don't walk behind me, I may not lead. Just walk beside me and be my friend. |
|
#5
|
||||
|
||||
Re: conditional compile logicQuote:
According to the Holly Standard, that is true. Of course, I never understood why anyone would use this obfuscated coding style; always use parenthesis, I say (and every Lisp geek is cheering Best regards, Lucian __________________
Please read these Guidelines before posting on the forum "A person who never made a mistake never tried anything new." Einstein |
|
#6
|
||||
|
||||
Re: conditional compile logicThe only reason they do it is so common sources can be used to compile the FLTK library for any of the supported platforms. I first assumed that they would be evaluated from left to right or based on the parentheses. I'm trying some tests now.
__________________
"Opportunity is missed by most people because it comes dressed in overalls and looks like work." --Thomas Alva Edison "Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety." --Benjamin Franklin "A happy person is not a person in a certain set of circumstances, but rather a person with a certain set of attitudes." --Hugh Downs |
|
#7
|
||||
|
||||
Re: conditional compile logicQuote:
Actually, I am not concerned with regular if/etc logic, it is the conditional compile if/endif stuff. So it would make more sense to test with... CPP / C++ / C Code:
Output: Code:
CPP / C++ / C Code:
Output: Code:
CPP / C++ / C Code:
Output: Code:
CPP / C++ / C Code:
Output: Code:
To really beat the dead horse... CPP / C++ / C Code:
Output: Code:
Actally the only other test would be to only define CYGWIN but since it runs under windows that would just be crazy. I can tell you the output would be... Code:
Anyhow, thanks to all for the input, I do believe I have got it. Mark __________________
"Opportunity is missed by most people because it comes dressed in overalls and looks like work." --Thomas Alva Edison "Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety." --Benjamin Franklin "A happy person is not a person in a certain set of circumstances, but rather a person with a certain set of attitudes." --Hugh Downs |
|
#8
|
|||
|
|||
Re: conditional compile logicQuote:
No way!!! First of all: it is true that precedence rules for preprocessor expressions are the same as for C: && has higher precedence that ||. Secondly: The precedence rules are required by the C and C++ standards. Thirdly: The two expressions in the original post are not equal: Lets use a, b, and c for the WIN32, __EMX__, __CYGWIN__ terms, and consider the following expressions: Code:
With parentheses that emphasize the precedence (but don't change the precedence or the results): Code:
In Boolean: The first expression is "a or b and c-bar", and the second is "a and c-bar or b". (Where in boolean algebra "and" has higher precedence than "or".) Now, by Boolean algebra identities (possibly aided by Quine-McKlusky or by Karnaugh maps), or by simply comparing truth tables, we can determine that the two expressions are not equal. There are two cases where they differ: Code:
Want to try for yourself? CPP / C++ / C Code:
Output: Code:
Output columns "1" and "2" are for the un-parenthesized and parenthesized versions of the first expression. Output columns are for the un-parenthesized and parenthesized version of hte second expression. If your compiler gives different results, ask for your money back. Now, if you go back and look at the probable intended results of the two expressions, you may (or may not) see whether they will always do the right thing for the cases of interest, and whether it makes sense to define things like this. Regards, Dave |
|
#9
|
|||
|
|||
Re: conditional compile logicQuote:
I couldn't have said it better! Why would you not use parentheses? Well, I know that was supposed to be a rhetorical question, but I actually have an answer, based on observations of lots and lots (and lots) of C code over the years. The C language is actually rather simple and elegant. One confusion factor is pointers, as every new C programmer knows (as well as some not-so-new ones). The other one is the rather bewildering collection of operators on the built-in data types. Now, to make himself/herself look more important and knowledgable than he/she really is, the C programmer typically shows how far above the common masses he/she is by making notation as obfuscatory as possible. Pointers don't need any additional obfuscation; for most of us they are already black magic (try a 3-D array of pointers to functions that return pointers to functions whose arguments are arrays of structs.) Now there are only two basic built-in data types in C: integer data types and floating point data types. It's pretty hard to make this look hard (although we can create composites of these that are mind-bending), but we can at least confuse the beginner by using an absolute minimum number of keystrokes for each expression. That is, leave off unnecessary parentheses. After all, a real C programmer has the precedence table on page 53 of K&R2 forever entwined with his/her soul, and to use unneccessary parentheses would surely be a sign of weakness. (Sometimes beginners have table 2-1 tattooed on their arms, but then they have to wear long-sleeved shirts for the rest of their lives.) The occasional bug where even experienced programmers carelessly writes a+b<<c, thinking it means a+(b<<c) when actually it means (a+b)<<c is a small price to pay for having established dominion over the great unwashed masses of people-who-wish-they-were-C-programmers-but-are-confused-by-the-examples-they-see. Regards, Dave P.S. Your reference to LISP (Lots of Insipid, Stupid Parentheses or was it Lots of Irritating, Spurious Parentheses?) took me back a few years. Is LISP still the darling of the non-numeric applications gurus (AI and others)? I haven't kept up with the literature lately. |
|
#10
|
|||
|
|||
Re: conditional compile logicQuote:
Actually the concern is whether boolean expressions in preprocessor directives obey the same precedence rules as C language expressions. The answer is yes. Writing a program that shows it with preprocessor directives is more tedious, but you can verify it. (It's more tedious, since preprocessor directives are fixed at compile time. You can #define and #undef identifiers anywhere in your source code, but you can't have a program loop for which an identifier is defined in one pass and undefined in another.) For example here's a program for the first expression of your original post: CPP / C++ / C Code:
Results: Code:
This shows the same results as output column 1 of my previous post. I leave expression number 2 as an exercise for the student (as well as the parenthesized versions of both). Regards, Dave |
Recent GIDBlog
Programming ebook direct download available by crystalattice
| Thread Tools | Search this Thread |
| Rate This Thread | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Steps to create and compile c program in SUSE | batrsau | Computer Software Forum - Linux | 7 | 03-Jun-2007 20:49 |
| FLTK compile help | machinated | FLTK Forum | 8 | 05-Mar-2005 15:52 |
| Can't run any programs I compile, please help | NotReallyHere | C++ Forum | 2 | 29-Dec-2004 16:57 |
| logic problem? | ozzytx | C++ Forum | 3 | 09-Jul-2004 03:23 |
| Can't find logic error | crystalattice | C++ Forum | 2 | 24-May-2004 20:31 |
Network Sites: GIDNetwork · GIDWebHosts · GIDSearch · Learning Journal by J de Silva, The