One of the uses of ... is to denote variadic entities in C and C++.
What is its name?
Is it classified as an operator or something else when used that way?
Any other details regarding ...?
Edit: I know the purpose of .... I am asking about its name and classification, which I hope, is similar in C and C++.
It is one of the punctuators.
6.4.6 Punctuators
Syntax punctuator:
one of [ ] ( ) { } . ->
++ -- & * + - ~ !
/ % << >> < > <= >= == != ^ | && ||
? : ; ...
= *= /= %= += -= <<= >>= &= ^= |=
, # ##
<: :> <% %> %: %:%:
In the function declaration it is called the ellipsis.
Ellipsis is also used by some compiler C language extensions.
Example - gcc switch/case range extension
const char *test(unsigned num)
{
switch(num)
{
case 0 ... 9:
return "the value is in the 0 to 9 range";
case 10 ... 99:
return "the value is in the 10 to 99 range";
default:
return "out of tested range";
}
}
https://godbolt.org/z/YBLma-
The ... is referred to as an ellipsis both in English and in the C standard.
One of the uses of ... is to denote variadic entities in C and C++.`
Yes, In layman's terms ... can be thought of as denoting more than one or multiples (as in pseudo-code punctuation we sometimes use multiple dots to resemble different types) of a use case, for which if we consider variadics (being multiple in the sense of 'varying' arguments/parameters) in C++, it would refer to a variable number of arguments for functions or templates.
What is its name?
Ellipsis
Is it classified as an operator or something else when used in that way?
No, it's definitely not an operator as it allows you to pass any number of arguments, not operate on them.
Any other details regarding ...?
As far as I know -
Its a special specifier;
The ellipsis always comes last in the argument list;
As far as its usage is concerned, its only used when you want to remove the limits on the number of parameters for a template/function or when you require to have an extensible number of parameters for expansion. (i.e. it provides parameter pack expansion in a variadic class template or function template) In practice we mostly require a fixed set of known parameters, so it isn't applicable to most cases;
It can be used with sizeof operator, as it's classified as a pack expansion as well.
Edit: I know the purpose of ... I am asking about its name and classification, which I hope, is similar in both C and C++.
The name is same, but usage may vary for C++ and C.
Am only familiar with its use in the former language. (I remember having a HackerRank problem on Variadics, covering its utility.)
The sequence of three full stops ... is called an ellipsis in both C and C++
In C++, the ellipsis helps initialize and expand different kinds of packs.
A parameter pack - when there is an ellipsis between the type and the identifier
Type ... identifier
A pack expansion - consists of a pattern and an ellipsis
pattern...
Related
Here is a very simple C++ application I made with QtCreator :
int main(int argc, char *argv[])
{
int a = 1;
int b = 2;
if (a < 1 or b > 3)
{
return 1;
}
return 0;
}
To me, this is not valid C++, as the keyword or is not a reserved keyword.
But if I compile and run it, it works fine without any warnings ! The exit code is 0 and if I change b = 4, the exit code is 1 !
I'm not including anything to make sure there is no hidden define.
This is really strange to me. Is this something Qt is defining ? I didn't find anything in the documentation regarding that.
According to Wikipedia:
C++ defines keywords to act as aliases
for a number of symbols that function
as operators: and (&&), bitand (&),
and_eq (&=), or (||), bitor (|), or_eq
(|=), xor (^), xor_eq (^=), not (!),
not_eq (!=), compl (~).
As MadKeithV points out, these replacements came from C's iso646.h, and were included in ISO C++ as operator keywords. The Wikipedia article for iso646.h says that the reason for these keywords was indeed for international and other non-QWERTY keyboards that might not have had easy access to the symbols.
or is a C++ keyword, and you're allowed to use it instead of ||. There is no magic.
The same goes for and and most other logical operators. It's generally best to stick to the commonly known names though, to avoid confusion like this. If you use or, someone will wonder "why does this compile" ;)
iso646.h defines a number of operator alternatives - it's part of the C++ standard.
Why are they called "primary"? In the order of evaluence they are the first?
C++03 standard defines the expression in chapter 5 (Note 1):
An expression is a sequence of operators and operands that specifies a computation.
Then the 5.1 "Primary expressions" defines the list of primary expressions:
(1) primary-expression:
literal
this
( expression )
id-expression
My main question is in connection the third point:
( expression )
So, according to the standard, every expression with brackets are primary expressions and they are calculated firstly. It looks logical, and gives an exact explanation of the behavior of brackets in C++ expressions (precedence).
So this means that for example
(variable + 10)
is a primary expression.
var = (variable + 10) * 3
and according to my theory, it looks logic, BUT from other sources I know
(variable + 10)
is NOT a primary expression, but WHY? I don't understand, however the standard defines the (expression) as a primary expression.
Please, help me because I can't. Thank you very much, and sorry for my bad English.
Hi.
C++ expressions can be complex, which is to say they can be made up of nested expressions, combined through the use of operators, and those nested expressions may in turn be complex.
If you decompose a complex expression into ever smaller units, at some point you'll be left with units that are atomic in the sense that they cannot be decomposed further. Those are primary expressions; they include identifiers, literals, the keyword this, and lambda expressions.
However, it is true that there is one non-atomic construct that the C++ Standard defines as primary: Expressions enclosed in round brackets (aka parentheses). So the (variable + 10) example you give is a primary expression (and so are the sub-expressions variable (which is an identifier), and 10 (which is a literal).
I believe the Standard lists them as primary expressions because they play the some role as truly atomic expressions when it comes to the order of evaluation: Anything within the brackets must be evaluated before the value of the backeted expressions can enter into evaluations with other expressions: In (5+10)*a, the value of 5+10 must be evaluated before it can enter into the evaluation of *a. [Note that this does not mean 5+10 is evaluated before the expression a is evaluated. It only means that 5+10 must be evaluated before the multiplication itself can be evaluated.]
So, bracketed sub-expressions, in this sense, act as if they were atomic.
And I guess this is why the Standard doesn't use the term "atomic expressions" for this concept. They act as if they were atomic, but at least the bracketed variety is not actually atomic. "Primary" seems, to me, to be a good choice of words.
The term primary-expression is an element of the language grammar. They could equally have been called foobar-expression , it's just a name that doesn't have any deeper meaning.
A primary-expression is not necessarily atomic, evaluated first, top-level, more important than other expressions , or anything like that . And all expressions are "building blocks" because any expression can be added to to form a larger expression.
The definition was already given in the question so I won't repeat it here.
(variable + 10) is a primary-expression, your "other sources" are wrong. Here is another example of primary-expression:
([]{
int n, t1 = 0, t2 = 1, nextTerm = 0;
cout << "Enter the number of terms: ";
cin >> n;
cout << "Fibonacci Series: ";
for (int i = 1; i <= n; ++i)
{
// Prints the first two terms.
if(i == 1)
{
cout << " " << t1;
continue;
}
if(i == 2)
{
cout << t2 << " ";
continue;
}
nextTerm = t1 + t2;
t1 = t2;
t2 = nextTerm;
cout << nextTerm << " ";
}
return 0;
}())
(this calls a lambda function and parenthesizes the result; code borrowed from : here).
Also, the question flirts with a common misconception about precedence and order of evaluation. The standard doesn't mention "precedence" at all. A precedence table is a way of presenting the rules of the the language grammar in a way that is easier to read.
It refers to the way that operands are grouped with operators, not the order in which subexpressions are executed. In the case of f() + ([]{int n, t1 = 0, t2 = 1, nextTerm = 0; cout << "Enter the number of terms: ";.... etc. etc. , the f() may or may not be called before the lambda is called. The parentheses around the lambda do not cause it to be evaluated first.
I've recently (only on SO actually) run into uses of the C/C++ comma operator. From what I can tell, it creates a sequence point on the line between the left and right hand side operators so that you have a predictable (defined) order of evaluation.
I'm a little confused about why this would be provided in the language as it seems like a patch that can be applied to code that shouldn't work in the first place. I find it hard to imagine a place it could be used that wasn't overly complex (and in need of refactoring).
Can someone explain the purpose of this language feature and where it may be used in real code (within reason), if ever?
It can be useful in the condition of while() loops:
while (update_thing(&foo), foo != 0) {
/* ... */
}
This avoids having to duplicate the update_thing() line while still maintaining the exit condition within the while() controlling expression, where you expect to find it. It also plays nicely with continue;.
It's also useful in writing complex macros that evaluate to a value.
The comma operator just separates expressions, so you can do multiple things instead of just one where only a single expression is required. It lets you do things like
(x) (y)
for (int i = 0, j = 0; ...; ++i, ++j)
Note that x is not the comma operator but y is.
You really don't have to think about it. It has some more arcane uses, but I don't believe they're ever absolutely necessary, so they're just curiosities.
Within for loop constructs it can make sense. Though I generally find them harder to read in this instance.
It's also really handy for angering your coworkers and people on SO.
bool guess() {
return true, false;
}
Playing Devil's Advocate, it might be reasonable to reverse the question:
Is it good practice to always use the semi-colon terminator?
Some points:
Replacing most semi-colons with commas would immediately make the structure of most C and C++ code clearer, and would eliminate some common errors.
This is more in the flavor of functional programming as opposed to imperative.
Javascript's 'automatic semicolon insertion' is one of its controversial syntactic features.
Whether this practice would increase 'common errors' is unknown, because nobody does this.
But of course if you did do this, you would likely annoy your fellow programmers, and become a pariah on SO.
Edit: See AndreyT's excellent 2009 answer to Uses of C comma operator. And Joel 2008 also talks a bit about the two parallel syntactic categories in C#/C/C++.
As a simple example, the structure of while (foo) a, b, c; is clear, but while (foo) a; b; c; is misleading in the absence of indentation or braces, or both.
Edit #2: As AndreyT states:
[The] C language (as well as C++) is historically a mix of two completely different programming styles, which one can refer to as "statement programming" and "expression programming".
But his assertion that "in practice statement programming produces much more readable code" [emphasis added] is patently false. Using his example, in your opinion, which of the following two lines is more readable?
a = rand(), ++a, b = rand(), c = a + b / 2, d = a < c - 5 ? a : b;
a = rand(); ++a; b = rand(); c = a + b / 2; if (a < c - 5) d = a; else d = b;
Answer: They are both unreadable. It is the white space which gives the readability--hurray for Python!. The first is shorter. But the semi-colon version does have more pixels of black space, or green space if you have a Hazeltine terminal--which may be the real issue here?
Everyone is saying that it is often used in a for loop, and that's true. However, I find it's more useful in the condition statement of the for loop. For example:
for (int x; x=get_x(), x!=sentinel; )
{
// use x
}
Rewriting this without the comma operator would require doing at least one of a few things that I'm not entirely comfortable with, such as declaring x outside the scope where it's used, or special casing the first call to get_x().
I'm also plotting ways I can utilize it with C++11 constexpr functions, since I guess they can only consist of single statements.
I think the only common example is the for loop:
for (int i = 0, j = 3; i < 10 ; ++i, ++j)
As mentioned in the c-faq:
Once in a while, you find yourself in a situation in which C expects a
single expression, but you have two things you want to say. The most
common (and in fact the only common) example is in a for loop,
specifically the first and third controlling expressions.
The only reasonable use I can think of is in the for construct
for (int count=0, bit=1; count<10; count=count+1, bit=bit<<1)
{
...
}
as it allows increment of multiple variables at the same time, still keeping the for construct structure (easy to read and understand for a trained eye).
In other cases I agree it's sort of a bad hack...
I also use the comma operator to glue together related operations:
void superclass::insert(item i) {
add(i), numInQ++, numLeft--;
}
The comma operator is useful for putting sequence in places where you can't insert a block of code. As pointed out this is handy in writing compact and readable loops. Additionally, it is useful in macro definitions. The following macro increments the number of warnings and if a boolean variable is set will also show the warning.
#define WARN if (++nwarnings, show_warnings) std::cerr
So that you may write (example 1):
if (warning_condition)
WARN << "some warning message.\n";
The comma operator is effectively a poor mans lambda function.
Though posted a few months after C++11 was ratified, I don't see any answers here pertaining to constexpr functions. This answer to a not-entirely-related question references a discussion on the comma operator and its usefulness in constant expressions, where the new constexpr keyword was mentioned specifically.
While C++14 did relax some of the restrictions on constexpr functions, it's still useful to note that the comma operator can grant you predictably ordered operations within a constexpr function, such as (from the aforementioned discussion):
template<typename T>
constexpr T my_array<T>::at(size_type n)
{
return (n < size() || throw "n too large"), (*this)[n];
}
Or even something like:
constexpr MyConstexprObject& operator+=(int value)
{
return (m_value += value), *this;
}
Whether this is useful is entirely up to the implementation, but these are just two quick examples of how the comma operator might be applied in a constexpr function.
Here is a very simple C++ application I made with QtCreator :
int main(int argc, char *argv[])
{
int a = 1;
int b = 2;
if (a < 1 or b > 3)
{
return 1;
}
return 0;
}
To me, this is not valid C++, as the keyword or is not a reserved keyword.
But if I compile and run it, it works fine without any warnings ! The exit code is 0 and if I change b = 4, the exit code is 1 !
I'm not including anything to make sure there is no hidden define.
This is really strange to me. Is this something Qt is defining ? I didn't find anything in the documentation regarding that.
According to Wikipedia:
C++ defines keywords to act as aliases
for a number of symbols that function
as operators: and (&&), bitand (&),
and_eq (&=), or (||), bitor (|), or_eq
(|=), xor (^), xor_eq (^=), not (!),
not_eq (!=), compl (~).
As MadKeithV points out, these replacements came from C's iso646.h, and were included in ISO C++ as operator keywords. The Wikipedia article for iso646.h says that the reason for these keywords was indeed for international and other non-QWERTY keyboards that might not have had easy access to the symbols.
or is a C++ keyword, and you're allowed to use it instead of ||. There is no magic.
The same goes for and and most other logical operators. It's generally best to stick to the commonly known names though, to avoid confusion like this. If you use or, someone will wonder "why does this compile" ;)
iso646.h defines a number of operator alternatives - it's part of the C++ standard.
Is there any reason not to use the bitwise operators &, |, and ^ for "bool" values in C++?
I sometimes run into situations where I want exactly one of two conditions to be true (XOR), so I just throw the ^ operator into a conditional expression. I also sometimes want all parts of a condition to be evaluated whether the result is true or not (rather than short-circuiting), so I use & and |. I also need to accumulate Boolean values sometimes, and &= and |= can be quite useful.
I've gotten a few raised eyebrows when doing this, but the code is still meaningful and cleaner than it would be otherwise. Is there any reason NOT to use these for bools? Are there any modern compilers that give bad results for this?
|| and && are boolean operators and the built-in ones are guaranteed to return either true or false. Nothing else.
|, & and ^ are bitwise operators. When the domain of numbers you operate on is just 1 and 0, then they are exactly the same, but in cases where your booleans are not strictly 1 and 0 – as is the case with the C language – you may end up with some behavior you didn't want. For instance:
BOOL two = 2;
BOOL one = 1;
BOOL and = two & one; //and = 0
BOOL cand = two && one; //cand = 1
In C++, however, the bool type is guaranteed to be only either a true or a false (which convert implicitly to respectively 1 and 0), so it's less of a worry from this stance, but the fact that people aren't used to seeing such things in code makes a good argument for not doing it. Just say b = b && x and be done with it.
Two main reasons. In short, consider carefully; there could be a good reason for it, but if there is be VERY explicit in your comments because it can be brittle and, as you say yourself, people aren't generally used to seeing code like this.
Bitwise xor != Logical xor (except for 0 and 1)
Firstly, if you are operating on values other than false and true (or 0 and 1, as integers), the ^ operator can introduce behavior not equivalent to a logical xor. For example:
int one = 1;
int two = 2;
// bitwise xor
if (one ^ two)
{
// executes because expression = 3 and any non-zero integer evaluates to true
}
// logical xor; more correctly would be coded as
// if (bool(one) != bool(two))
// but spelled out to be explicit in the context of the problem
if ((one && !two) || (!one && two))
{
// does not execute b/c expression = ((true && false) || (false && true))
// which evaluates to false
}
Credit to user #Patrick for expressing this first.
Order of operations
Second, |, &, and ^, as bitwise operators, do not short-circuit. In addition, multiple bitwise operators chained together in a single statement -- even with explicit parentheses -- can be reordered by optimizing compilers, because all 3 operations are normally commutative. This is important if the order of the operations matters.
In other words
bool result = true;
result = result && a() && b();
// will not call a() if result false, will not call b() if result or a() false
will not always give the same result (or end state) as
bool result = true;
result &= (a() & b());
// a() and b() both will be called, but not necessarily in that order in an
// optimizing compiler
This is especially important because you may not control methods a() and b(), or somebody else may come along and change them later not understanding the dependency, and cause a nasty (and often release-build only) bug.
The raised eyebrows should tell you enough to stop doing it. You don't write the code for the compiler, you write it for your fellow programmers first and then for the compiler. Even if the compilers work, surprising other people is not what you want - bitwise operators are for bit operations not for bools.
I suppose you also eat apples with a fork? It works but it surprises people so it's better not to do it.
I think
a != b
is what you want
Disadvantages of the bitlevel operators.
You ask:
“Is there any reason not to use the bitwise operators &, |, and ^ for "bool" values in C++? ”
Yes, the logical operators, that is the built-in high level boolean operators !, && and ||, offer the following advantages:
Guaranteed conversion of arguments to bool, i.e. to 0 and 1 ordinal value.
Guaranteed short circuit evaluation where expression evaluation stops as soon as the final result is known.
This can be interpreted as a tree-value logic, with True, False and Indeterminate.
Readable textual equivalents not, and and or, even if I don't use them myself.
As reader Antimony notes in a comment also the bitlevel operators have alternative tokens, namely bitand, bitor, xor and compl, but in my opinion these are less readable than and, or and not.
Simply put, each such advantage of the high level operators is a disadvantage of the bitlevel operators.
In particular, since the bitwise operators lack argument conversion to 0/1 you get e.g. 1 & 2 → 0, while 1 && 2 → true. Also ^, bitwise exclusive or, can misbehave in this way. Regarded as boolean values 1 and 2 are the same, namely true, but regarded as bitpatterns they're different.
How to express logical either/or in C++.
You then provide a bit of background for the question,
“I sometimes run into situations where I want exactly one of two conditions to be true (XOR), so I just throw the ^ operator into a conditional expression.”
Well, the bitwise operators have higher precedence than the logical operators. This means in particular that in a mixed expression such as
a && b ^ c
you get the perhaps unexpected result a && (b ^ c).
Instead write just
(a && b) != c
expressing more concisely what you mean.
For the multiple argument either/or there is no C++ operator that does the job. For example, if you write a ^ b ^ c than that is not an expression that says “either a, b or c is true“. Instead it says, “An odd number of a, b and c are true“, which might be 1 of them or all 3…
To express the general either/or when a, b and c are of type bool, just write
(a + b + c) == 1
or, with non-bool arguments, convert them to bool:
(!!a + !!b + !!c) == 1
Using &= to accumulate boolean results.
You further elaborate,
“I also need to accumulate Boolean values sometimes, and &= and |=? can be quite useful.”
Well, this corresponds to checking whether respectively all or any condition is satisfied, and de Morgan’s law tells you how to go from one to the other. I.e. you only need one of them. You could in principle use *= as a &&=-operator (for as good old George Boole discovered, logical AND can very easily be expressed as multiplication), but I think that that would perplex and perhaps mislead maintainers of the code.
Consider also:
struct Bool
{
bool value;
void operator&=( bool const v ) { value = value && v; }
operator bool() const { return value; }
};
#include <iostream>
int main()
{
using namespace std;
Bool a = {true};
a &= true || false;
a &= 1234;
cout << boolalpha << a << endl;
bool b = {true};
b &= true || false;
b &= 1234;
cout << boolalpha << b << endl;
}
Output with Visual C++ 11.0 and g++ 4.7.1:
true
false
The reason for the difference in results is that the bitlevel &= does not provide a conversion to bool of its right hand side argument.
So, which of these results do you desire for your use of &=?
If the former, true, then better define an operator (e.g. as above) or named function, or use an explicit conversion of the right hand side expression, or write the update in full.
Contrary to Patrick's answer, C++ has no ^^ operator for performing a short-circuiting exclusive or. If you think about it for a second, having a ^^ operator wouldn't make sense anyway: with exclusive or, the result always depends on both operands. However, Patrick's warning about non-bool "Boolean" types holds equally well when comparing 1 & 2 to 1 && 2. One classic example of this is the Windows GetMessage() function, which returns a tri-state BOOL: nonzero, 0, or -1.
Using & instead of && and | instead of || is not an uncommon typo, so if you are deliberately doing it, it deserves a comment saying why.
Patrick made good points, and I'm not going to repeat them. However might I suggest reducing 'if' statements to readable english wherever possible by using well-named boolean vars.For example, and this is using boolean operators but you could equally use bitwise and name the bools appropriately:
bool onlyAIsTrue = (a && !b); // you could use bitwise XOR here
bool onlyBIsTrue = (b && !a); // and not need this second line
if (onlyAIsTrue || onlyBIsTrue)
{
.. stuff ..
}
You might think that using a boolean seems unnecessary, but it helps with two main things:
Your code is easier to understand because the intermediate boolean for the 'if' condition makes the intention of the condition more explicit.
If you are using non-standard or unexpected code, such as bitwise operators on boolean values, people can much more easily see why you've done this.
EDIT: You didnt explicitly say you wanted the conditionals for 'if' statements (although this seems most likely), that was my assumption. But my suggestion of an intermediate boolean value still stands.
Using bitwise operations for bool helps save unnecessary branch prediction logic by the processor, resulting from a 'cmp' instruction brought in by logical operations.
Replacing the logical with bitwise operations (where all operands are bool) generates more efficient code offering the same result. The efficiency ideally should outweigh all the short-circuit benefits that can be leveraged in the ordering using logical operations.
This can make code a bit un-readable albeit the programmer should comment it with reasons why it was done so.
IIRC, many C++ compilers will warn when attempting to cast the result of a bitwise operation as a bool. You would have to use a type cast to make the compiler happy.
Using a bitwise operation in an if expression would serve the same criticism, though perhaps not by the compiler. Any non-zero value is considered true, so something like "if (7 & 3)" will be true. This behavior may be acceptable in Perl, but C/C++ are very explicit languages. I think the Spock eyebrow is due diligence. :) I would append "== 0" or "!= 0" to make it perfectly clear what your objective was.
But anyway, it sounds like a personal preference. I would run the code through lint or similar tool and see if it also thinks it's an unwise strategy. Personally, it reads like a coding mistake.