Syntax Error
-
I would say that "technically", the preprocesor is part of the language (preprocessor is defined in K&R), hence #define is part of the program. However, I'm not going to start a war here about such minutia, and specially not with such nice people. :)
Mircea
Would you care to discuss tabs v. spaces? :)
The difficult we do right away... ...the impossible takes slightly longer.
-
Would you care to discuss tabs v. spaces? :)
The difficult we do right away... ...the impossible takes slightly longer.
*Python has entered the chat*
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
If it's not, then neither is #include
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Correct. Pre-processor directives are resolved before the code reaches the actual C/C++ compiler. The output of whatever pre-processor(s) you use is the actual code. Or -- as I do -- use a C/C++ pre-processor to resolve directives I put in C# and pass the result to the C# compiler. But you know that.
-
Correct. Pre-processor directives are resolved before the code reaches the actual C/C++ compiler. The output of whatever pre-processor(s) you use is the actual code. Or -- as I do -- use a C/C++ pre-processor to resolve directives I put in C# and pass the result to the C# compiler. But you know that.
I do. I am open to the reasonable disagreement about whether or not the preprocessor is part of the language, even if not part of the compiler itself. I think either position is valid, depending on which rubber ruler you use, and so I'm not really about debating that, but I think that's the question here.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
PIEBALDconsult wrote:
an include can be specified at the command line for the compilers I use
Interesting! I know how to specify an include path but not a file.
PIEBALDconsult wrote:
Maybe you haven't used Oracle's PRO*C or RDB's version for embedding SQL in C/C++ programs.
No, never! I've been fortunate in that respect ;P The closest I got was using SQLITE :D
Mircea
Mircea Neacsu wrote:
but not a file
If I recall correctly, with VAX/DEC/Compaq/HP C the switch is
/FirstInclude. I don't have an installation of Microsoft's C/C++ compiler on this system -- nor Borland's C/C++ or GCC -- but I can try to have a look when I get home. MingW: An example from Implanting Common Code in Unrelated Classes[^] "C:\mingw\bin\cpp" -P -C-include "c:\batfiles\ImplantWarning.h"D__NAME_SPACE__=%3 -D__CLASS_NAME__=%4 -w "%1" "%2" I'm sure I have it for Microsoft's C/C++ compiler (cl.exe) as well. I have probably referred to it in the past. Oh!: Re: c program - C / C++ / MFC Discussion Boards[^] F:\Projects>cl.exe /nologo/FIstdio.h/DSEMI=; nosem.c -
Agreed, but I'm not sure all tokenizers would be happy with the lack of a space, which in this case might be considered as significant as a punctuation character. But then, I suppose when you see something starting with "#include", the next character really should not be part of that token. Especially when it's a reserved character such as < or ", so I suppose the situation is easy enough to detect and allow.
It wouldn't be part of the token in most tokenizer implementations. "include" would be a preproc keyword.** ** or identifier if the tokenizer doesn't distinguish between idents and keywords as is often the case. Most of the time, whitespace is hidden during tokenization before the parser gets to it so the parser wouldn't really care if there was no whitespace unless the developer put in extra effort for it to care.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I do. I am open to the reasonable disagreement about whether or not the preprocessor is part of the language, even if not part of the compiler itself. I think either position is valid, depending on which rubber ruler you use, and so I'm not really about debating that, but I think that's the question here.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Yep, but I think I further irk you by using it for purposes other than its original intent.
-
Mircea Neacsu wrote:
but not a file
If I recall correctly, with VAX/DEC/Compaq/HP C the switch is
/FirstInclude. I don't have an installation of Microsoft's C/C++ compiler on this system -- nor Borland's C/C++ or GCC -- but I can try to have a look when I get home. MingW: An example from Implanting Common Code in Unrelated Classes[^] "C:\mingw\bin\cpp" -P -C-include "c:\batfiles\ImplantWarning.h"D__NAME_SPACE__=%3 -D__CLASS_NAME__=%4 -w "%1" "%2" I'm sure I have it for Microsoft's C/C++ compiler (cl.exe) as well. I have probably referred to it in the past. Oh!: Re: c program - C / C++ / MFC Discussion Boards[^] F:\Projects>cl.exe /nologo/FIstdio.h/DSEMI=; nosem.cNice! You live, you learn.
Mircea
-
Yep, but I think I further irk you by using it for purposes other than its original intent.
I'm actually not really so concerned about that sort of thing or I wouldn't like C++ metaprogramming as much as I do, which is essentially using
templatein ways other than for that which it was designed.Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I do. I am open to the reasonable disagreement about whether or not the preprocessor is part of the language, even if not part of the compiler itself. I think either position is valid, depending on which rubber ruler you use, and so I'm not really about debating that, but I think that's the question here.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Interesting. Is the preprocessor part of the language? What one can state specifically is that is part of the specification. Is there a formal definition of the language outside of the specification? From Stroustrup in the "Annotated C++ Reference Manual" (page 5) "A file is conceptually translated in several phases ... The first phase is preprocessing" So I would guess he would claim it is not C++ without the preprocessor.
-
Agreed, but I'm not sure all tokenizers would be happy with the lack of a space, which in this case might be considered as significant as a punctuation character. But then, I suppose when you see something starting with "#include", the next character really should not be part of that token. Especially when it's a reserved character such as < or ", so I suppose the situation is easy enough to detect and allow.
dandy72 wrote:
Agreed, but I'm not sure all tokenizers would be happy with the lack of a space,
A C++ compiler is not compliant if it requires a space before the '<' The spec defines a preprocessor id as a '#' followed by a 'token' A token (section 2.1) must be one of the following - Identifier - keyword - literal - operator - other separators "...collectively 'white space')...are ignored except as they serve to separate tokens" So in the context of this the following is valid #include But the following would not be since the token in that case would be 'includeio' #includeio.h Keep in mind of course that this doesn't make 'includeio' valid. But just that as far as tokenization goes that is what would happen.
-
dandy72 wrote:
Agreed, but I'm not sure all tokenizers would be happy with the lack of a space,
A C++ compiler is not compliant if it requires a space before the '<' The spec defines a preprocessor id as a '#' followed by a 'token' A token (section 2.1) must be one of the following - Identifier - keyword - literal - operator - other separators "...collectively 'white space')...are ignored except as they serve to separate tokens" So in the context of this the following is valid #include But the following would not be since the token in that case would be 'includeio' #includeio.h Keep in mind of course that this doesn't make 'includeio' valid. But just that as far as tokenization goes that is what would happen.
That was my assumption, but I didn't want to look it up because lazy. :laugh: Thanks.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Interesting. Is the preprocessor part of the language? What one can state specifically is that is part of the specification. Is there a formal definition of the language outside of the specification? From Stroustrup in the "Annotated C++ Reference Manual" (page 5) "A file is conceptually translated in several phases ... The first phase is preprocessing" So I would guess he would claim it is not C++ without the preprocessor.
I tend to agree with this take, but considering the C++ compiler eats postprocessed C++ implementation files (i don't want to get into modules and stuff) and doesn't understand preprocessed C++ I think there's room for a reasonable person to suggest that it's somewhat (for lack of a better term) orthogonal to the language.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
dandy72 wrote:
Agreed, but I'm not sure all tokenizers would be happy with the lack of a space,
A C++ compiler is not compliant if it requires a space before the '<' The spec defines a preprocessor id as a '#' followed by a 'token' A token (section 2.1) must be one of the following - Identifier - keyword - literal - operator - other separators "...collectively 'white space')...are ignored except as they serve to separate tokens" So in the context of this the following is valid #include But the following would not be since the token in that case would be 'includeio' #includeio.h Keep in mind of course that this doesn't make 'includeio' valid. But just that as far as tokenization goes that is what would happen.
