|
You can write an entire C/C++ program on a single line, which is why all those punctuation characters are so important.
|
|
|
|
|
Richard MacCutchan wrote: You can write an entire some C/C++ programs on a single line,
FTFY
Sometimes you cannot:
#define A "Hello world!\n"
int main(int argc, char** argv)
{
printf (A);
return 0;
}
When discussion comes to blanks and line endings I always remember a funny picture from an old book.
Mircea
|
|
|
|
|
Well technically, the #define is not part of the program, is it?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
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.
|
|
|
|
|
*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
|
|
|
|
|
Completely agree.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
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
|
|
|
|
|
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 template in 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
|
|
|
|
|
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
|
|
|
|
|
There exists at least one C/C++ program which can be written in one line.
I try to avoid putting any pre-processor directives in my C/C++ files -- an include can be specified at the command line for the compilers I use.
I somewhat agree that the language of C/C++ and its pre-processor are separate languages. One can create any number of alternative pre-processor languages -- K&R's is just one.
Maybe you haven't used Oracle's PRO*C or RDB's version for embedding SQL in C/C++ programs.
One thing I want in a pre-processor is the ability to tell it which directives to process and which to leave for later. I have had to jump through hoops to get things to work the way I want.
And I do like lots of SPACEs which are not "required":
# include <vcl.h>
# include "Mainwindow.h"
|
|
|
|
|
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 The closest I got was using SQLITE
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
|
|
|
|
|
Nice! You live, you learn.
Mircea
|
|
|
|
|
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
|
|
|
|
|
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<io.h>
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.
Thanks.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
jschell wrote: A C++ compiler is not compliant if it requires a space before the '<'
There ya go. End of discussion. Thanks for pointing that out.
|
|
|
|
|
A sampling of compilers at Compiler Explorer were happy without spaces. Have to admit that it just looks wrong to me. But then I'm an old fogey ...
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
k5054 wrote: Compiler Explorer
Of course that had to exist. So, this is the source code equivalent to VirusTotal...
Very neat. Thanks for that link.
|
|
|
|