This question already has answers here:
When were the 'and' and 'or' alternative tokens introduced in C++?
(8 answers)
Closed 8 years ago.
I'm translating a C++ function I wrote some time ago into python when I noticed that my C++ code contains the following lines:
if(MIsScaledOut()) {
if(DataType()==UnknownDataType or DataType()==h)
Descriptor = Descriptor + DataTypeString() + "OverM";
There's an or in there! This was probably because I previously translated from python, and forgot to switch to ||.
This code compiles in various OSes, with various compilers, and I've never seen a problem with it. Is this standard, or have I just gotten lucky so far, and this is something I should worry about?
After remembering the right word to google, I now see that it is listed as a C++ keyword, along with various similar keywords like and that I'd never seen (noticed?) before in C++. The reason these exist is because there are encodings that don't have some of the required punctuation characters used by the traditional operator spellings: {, }, [, ], #, \, ^, |, ~.
As #mafso points out, the alternative "spelled out" versions can be used in C by including the <iso646.h> header, which defines them as macros.
The question of which this has been marked duplicate also points out the existence of digraphs and trigraphs, which can be used to substitute for the missing characters. (That question also says "everybody knows about" them. Obviously, I did not...)
Related
This question already has answers here:
Unicode Identifiers and Source Code in C++11?
(5 answers)
Closed 2 years ago.
So far I knew that in C++ identifiers can only contain letters of English ABC, numbers and underscores, but I am reading the standard and cppreference.com, and they write that unicode characters and special characters can be used as well. Is it true? Or is it true for some compilers only?
https://timsong-cpp.github.io/cppwp/lex.name
https://en.cppreference.com/w/cpp/language/identifiers
According to translation phase 1, the compiler can map each "character" in a source file to either a character in the basic source character set, or to an escaped Unicode character.
How this mapping is performed, or how the escaped Unicode character is handled, is implementation defined. I.e. it's up to the compiler implementation to handle Unicode characters or not. Some do, some don't. You must read the documentation for your compiler to learn what it does. And if you use Unicode characters in your source, you need to be aware of that they might not work reliably (or at all) if the source is used by other compilers.
In summary. If you want to write portable code, then only use the basic source character set.
This question already has answers here:
Is it okay to use "and", "or" etc. instead of "&&", "||"?
(9 answers)
Are "not, and, or, not_eq.." part of the C++ standard? (And why might they be used or avoided in code?)
(5 answers)
Closed 5 years ago.
I saw alternative operators (like and, or, not etc.) when browsing cppreference.
They are alternatives to "normal" operators like &&, ||, ! etc.
I examined the assembly for code that uses && and and. Both versions generated the same assembly.
Code :
#include <iostream>
int n = 1;
int main()
{
// if(n > 0 && n < 5)
if(n > 0 and n < 5)
{
std::cout << "n is small and positive\n";
}
}
So my questions are:
What is the difference between the && and and operators?
Where and when do I use and over &&?
If there is no difference, then why does C++ introduce alternative operators (like and, or, not etc.)?
What is the difference between the && and and operators?
There is none1. The "alternative" aspect of these operators means that they can be used to construct the exact same expressions from a semantic perspective.
Where and when do I use and over &&?
This is largely a matter of preference. I'm too used to && to not use it, but can understand if someone finds and more readable.
why does C++ introduce alternative operators?
C++ was designed to be available on a variety of character sets and platforms. Trigraphs, like Bathsheba pointed out, are another example of such a feature. If a character set would not allow && to be written (say, because it simply didn't have the & character) then one can still get by with the alternative representation. Nowadays, it's largely moot.
1 Actually, upon further thinking, my answer to your first question can be refined. There is a slight lack of equivalence, pertaining to how tokens are parsed. && doesn't require a space to be parsed as a separate token, while and does. That means:
void foo(bool b1, bool b2) {
if(b1&&b2) { // Well formed
}
if(b1andb2) { // ill formed, needs spaces around `and`
}
}
and, or, not, &c. are examples of the alternative operators.
For the full list see http://en.cppreference.com/w/cpp/language/operator_alternative; the opening paragraph is a raison d'etre:
C++ (and C) source code may be written in any non-ASCII 7-bit
character set that includes the ISO 646:1983 invariant character set.
However, several C++ operators and punctuators require characters that
are outside of the ISO 646 codeset: {, }, [, ], #, \, ^, |, ~. To be
able to use character encodings where some or all of these symbols do
not exist (such as the German DIN 66003), C++ defines the following
alternatives composed of ISO 646 compatible characters.
If I were you I'd shy away from using them, much in the same way as you ought to shy away from using digraphs and trigraphs, even if the latter make for interview fun.
Trigraphs for example are explicitly discontinued from C++17. You might see and &c. being dropped in future standards too.
This question already has answers here:
Is it "bad practice" to use tab characters in string literals?
(2 answers)
Closed 7 years ago.
I just tried compiling some C++ code that used the literal Tab character (as in I pressed the TAB key on my keyboard) inside a string. And, to my surprise, it compiled fine. In retrospect I guess that makes sense, since it's a character just like any other.
cout << "Tab: [TAB]";
Before now I've always used \t to define tabs in strings.
cout << "Tab: [\t]";
Obviously code using literal TABs in strings would suffer greatly in readability, but is there a technical reason to use \t other than convention?
but is there a technical reason to use \t other than convention?
Sure there are technical reasonings. Using
cout << "Tab: [\t]";
would work independently of the target systems actual character encoding.
The source file could use a different encoding as the target system does, e.g. UTF8 for source, but EBCDIC at the target system.
'\t' will always be translated to the correct character code though, thus the code is portable.
Also as mentioned in merlin2011's comment many IDE's will just replace TAB with a specific number of spaces.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What does the word “literal” mean?
Often when reading literature about C++, I encounter the word "literal". It is a bit unclear to me what exactly this term means in C++.
A literal is some data that's presented directly in the code, rather than indirectly through a variable or function call.
Here are some examples, one per line:
42
128
3.1415
'a'
"hello world"
The data constituting a literal cannot be modified by a program, but it may be copied into a variable for further use:
int a = 42; // creates variable `a` with the same value as the literal `42`
This concept is by no means unique to C++.
The term "literal" comes from the fact that you've written data literally into your program, i.e. exactly as written, not "hidden" behind a variable name.
Wikipedia gives you quickly this about literals.
In your C or C++ source code, Things like 1234, nullptr (in recent C++), "abcd" are literals.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
The written versions of the logical operators.
I notice that C++ define keyword and, or, not, xor, and_eq, or_eq, not_eq and xor_eq as an alternative to &&, ||, !, ^, &=, |=, != and |=. and they're rarely used! What's wrong? Are they not portable?
They come from C AFAIR from times when it was not known what special symbols are on the keyboard. So to have portable language they were defined so anyone can use C even if they used keyboard with no &, |, or ^ (etc.).
Nowadays when QWERTY is a standard (with AZWERTY & co. as variations) it is no longer an issue.
PS. And of course for obfuscation code competitions ;)