assignment-operator | 易学教程

Short hand assignment operator, +=, True Meaning?

阅读更多关于 Short hand assignment operator, +=, True Meaning?

问题 I learnt that i+=2 is the short-hand of i=i+2 . But now am doubting it. For the following code, the above knowledge holds no good: byte b=0; b=b+2; //Error:Required byte, Found int The above code is justifiable, as 2 is int type and the expression returns int value. But, the following code runs fine: byte b=0; b+=2; //b stores 2 after += operation This is forcing me to doubt that the += short-hand operator is somewhat more than I know. Please enlighten me. 回答1: When in doubt, you can always

boost::optional not letting me reassign const value types

阅读更多关于 boost::optional not letting me reassign const value types

问题 It seems to me there should be four variants of boost::optional optional<Foo> => holds a mutable Foo and can be reassigned after initialization optional<Foo const> const => holds a const Foo and can't be reassigned after initialization optional<Foo> const => (should?) hold a mutable Foo but can't be reassigned after initialization optional<Foo const> => (should?) hold a const Foo and can be reassigned after initialization The first 2 cases work as expected. But the optional<Foo> const

c++: cast operator vs. assign operator vs. conversion constructor priority

阅读更多关于 c++: cast operator vs. assign operator vs. conversion constructor priority

问题 Let's have this code: Test1 t1; Test2 t2; t1 = t2; I believe there are three (or more?) ways how to implement t1 = t2 to overload assign operator in Test1 to overload type cast operator in Test2 to create Test1(const Test2&) conversion constructor According to my GCC testing, this is the priority of what is used: assign operator conversion constructor and type cast operator (ambiguous) const conversion constructor and const type cast operator (ambiguous) Please help me understand why this

Is chained assignment in C/C++ undefined behavior?

阅读更多关于 Is chained assignment in C/C++ undefined behavior?

问题 Ignoring the types of variables, is expression like a=b=c has defined behavior in both C and C++? If so, can any one give me official evidence, like quotes from the standard, please? P.S. I searched the chained assignment but everything I got is associativity, but I didn't find any text about that in the C99 standard. Maybe I did it wrong? hoping anyone can help me. 回答1: From the C++ Standard 5.17 Assignment and compound assignment operators [expr.ass] 1 The assignment operator (=) and the

Should I use lvalue reference qualifiers for assignment operators?

阅读更多关于 Should I use lvalue reference qualifiers for assignment operators?

问题 Recently, I have followed a discussion about assignments to expressions in C++ as shown in the following example: string s1, s2, s3; (s1 + s2) = s3; With C++11 it is possible to restrict the assignment operator to lvalue references (on the left side). When declaring the assignment operators as follow, the compiler Clang rejects the code with an error message due to incompatible types. auto operator=(const string& rhs) & -> string&; auto operator=(string&& rhs) & -> string&; I haven't seen

Scala multiple assignment to existing variable

阅读更多关于 Scala multiple assignment to existing variable

问题 I can do something like def f(): Tuple2[String, Long] = ... val (a, b) = f() What about if the variables are already existing? I'm running the same sets of data over filters and I don't want to chain them (long names and such). This is what I tried, but it complains about expecting ; instead of = on the last line: var a = ...initialization for this data var b = ...some other init (a, b) = g(a, b) // error: expected ';' but found '=' Is there a way to avoid an intermediary tuple? 回答1: As Alex

What was the reason for Swift assignment evaluation to void?

阅读更多关于 What was the reason for Swift assignment evaluation to void?

问题 This question is about HISTORY (not your current opinions on the matter). While reading post about dropping support for increment/decrement operators for Swift I read such text "Swift already deviates from C in that the =, += and other assignment-like operations returns Void (for a number of reasons)". So at some time in the past developers consciously decided to evaluate assignments to void for some reasons. And I am looking for those historical (now) reasons. Pretty much as this thread is

issue with assignment operator inside printf()

阅读更多关于 issue with assignment operator inside printf()

问题 Here is the code int main() { int x=15; printf("%d %d %d %d",x=1,x<20,x*1,x>10); return 0; } And output is 1 1 1 1 I was expecting 1 1 15 1 as output, x*1 equals to 15 but here x*1 is 1 , Why ? Using assignment operator or modifying value inside printf() results in undefined behaviour ? 回答1: Your code produces undefined behavior. Function argument evaluations are not sequenced relative to each other. Which means that modifying access to x in x=1 is not sequenced with relation to other

How does an equal to expression work in a printf placeholder? [duplicate]

阅读更多关于 How does an equal to expression work in a printf placeholder? [duplicate]

问题 This question already has answers here : Why are these constructs using pre and post-increment undefined behavior? (14 answers) Closed last year . I have the following code snippet: main( ) { int k = 35 ; printf ( "\n%d %d %d", k == 35, k = 50, k > 40 ) ; } which produces the following output 0 50 0 I'm not sure I understand how the first value of the printf comes to 0 . When the value of k is compared with 35 , it should ideally return (and thus print) 1, but how is it printing zero? The

issue with assignment operator inside printf()

阅读更多关于 issue with assignment operator inside printf()

Here is the code int main() { int x=15; printf("%d %d %d %d",x=1,x<20,x*1,x>10); return 0; } And output is 1 1 1 1 I was expecting 1 1 15 1 as output, x*1 equals to 15 but here x*1 is 1 , Why ? Using assignment operator or modifying value inside printf() results in undefined behaviour ? Your code produces undefined behavior. Function argument evaluations are not sequenced relative to each other. Which means that modifying access to x in x=1 is not sequenced with relation to other accesses, like the one in x*1 . The behavior is undefined. Once again, it is undefined not because you "used