post-increment

C/C++ post-increment/-decrement and function call [duplicate]

雨燕双飞 提交于 2019-12-06 09:32:20
问题 This question already has answers here : Closed 6 years ago . Possible Duplicate: Undefined Behavior and Sequence Points I am using microsoft visual c++. Look at the following example: int n = 5; char *str = new char[32]; strcpy(str, "hello world"); memcpy(&str[n], &str[n+1], 6+n--); printf(str); // output is "hell world" So unexpectadly my compiler produces code that first decrements n and then executes memcpy. The following source will do what i expected to happen: int n = 5; char *str =

C++ OutputIterator post-increment requirements

我是研究僧i 提交于 2019-12-05 20:12:15
问题 C++ requires that an OutputIterator type X support expressions of the form r++ , where r is an instance of X . This postfix increment must be semantically equivalent to: (*) { X tmp = r; ++r; return tmp; } and must return a type that is convertible to X const& . In C++11, see 24.2.4 (this is not new, however). In the same section, it says Algorithms on output iterators should never attempt to pass through the same iterator twice. They should be single pass algorithms. Given (*), above, say I

The assignment to variable has no effect?

喜欢而已 提交于 2019-12-05 06:32:45
When I do this: count = ++count; Why do i get the warning - The assignment to variable count has no effect ? This means that count is incremented and then assigned to itself or something else ? Is it the same as just ++count ? What happens in count = count++; ? Why don't I get a warning for this ? count++ and ++count are both short for count=count+1 . The assignment is built in, so there's no point to assigning it again. The difference between count++ (also knows as postfix ) and ++count (also known as prefix ) is that ++count will happen before the rest of the line, and count++ will happen

Puzzling behaviour of == after postincrementation [duplicate]

别说谁变了你拦得住时间么 提交于 2019-12-05 03:36:22
This question already has answers here : Integer wrapper objects share the same instances only within the value 127? [duplicate] (5 answers) Closed 6 years ago . Someone postulated in some forum thread that many people and even experienced Java Developers wouldn't understand the following peace of Java Code. Integer i1 = 127; Integer i2 = 127; System.out.println(i1++ == i2++); System.out.println(i1 == i2); As a person with some interest in Java I gave it my thoughts and came to the following result. System.out.println(i1++ == i2++); // True, since we first check for equality and increment both

C/C++ post-increment/-decrement and function call [duplicate]

天涯浪子 提交于 2019-12-04 17:04:24
This question already has answers here : Closed 6 years ago . Possible Duplicate: Undefined Behavior and Sequence Points I am using microsoft visual c++. Look at the following example: int n = 5; char *str = new char[32]; strcpy(str, "hello world"); memcpy(&str[n], &str[n+1], 6+n--); printf(str); // output is "hell world" So unexpectadly my compiler produces code that first decrements n and then executes memcpy. The following source will do what i expected to happen: int n = 5; char *str = new char[32]; strcpy(str, "hello world"); memcpy(&str[n], &str[n+1], 6+n); n--; printf(str); // output is

C++ OutputIterator post-increment requirements

Deadly 提交于 2019-12-04 02:39:38
C++ requires that an OutputIterator type X support expressions of the form r++ , where r is an instance of X . This postfix increment must be semantically equivalent to: (*) { X tmp = r; ++r; return tmp; } and must return a type that is convertible to X const& . In C++11, see 24.2.4 (this is not new, however). In the same section, it says Algorithms on output iterators should never attempt to pass through the same iterator twice. They should be single pass algorithms. Given (*), above, say I copy the return value like X a(r++); Suppose r was dereferencable before incrementing, but was not

How is *it++ valid for output iterators?

会有一股神秘感。 提交于 2019-12-04 01:09:54
In example code, I often see code such as *it++ for output iterators. The expression *it++ makes a copy of it , increments it , and then returns the copy which is finally dereferenced. As I understand it, making a copy of an output iterator invalidates the source. But then the increment of it that is performed after creating the copy would be illegal, right? Is my understanding of output iterators flawed? The expression *it++ does not (have to) make a copy of it, does not increment it, etc. This expression is valid only for convenience, as it follows the usual semantics. Only operator= does

What are the historical reasons C languages have pre-increments and post-increments?

时光毁灭记忆、已成空白 提交于 2019-12-03 17:15:16
问题 (Note: I am not asking about the definitions of pre-increment vs. post-increment, or how they are used in C/C++. Therefore, I do not think this is a duplicate question.) Developers of C (Dennis Ritchie et al) created increment and decrement operators for very good reasons. What I don't understand is why they decided to create the distinction of pre- vs post- increments/decrements? My sense is that these operators were far more useful when C was being developed than today. Most C/C++

Understanding more about i++ and i=i+1

試著忘記壹切 提交于 2019-12-03 12:09:17
I was wondering if there is difference between the two forms of increment. Some of the links says i++ is faster that i=i+1; Also as one of the person my observation is also the same for assembly code. please check the image where both the assembly code are same for i++ and i=i+1 - There is another link that says that it used to be true previously that increment operator was faster than addition and assignment, but now compilers optimize i++ and i=i+1 the same. Is there any official document/paper which we can refer to confirm what is exactly right ? (I usually go with credit's and number of

Is the behavior of return x++; defined?

别说谁变了你拦得住时间么 提交于 2019-12-03 09:45:34
If I have for example a class with instance method and variables class Foo { ... int x; int bar() { return x++; } }; Is the behavior of returning a post-incremented variable defined? Yes, it's equivalent to: int bar() { int temp = x; ++x; return temp; } Yes it is ... it will return the x's value before incrementing it and after that the value of x will be + 1 ... if it matters. Yes. In postincrement (x++) the value of x is evaluated (returned in your case) before 1 is added. In preincrement (++x) the value of x is evaluated after 1 is added. Edit : You can compare the definition of pre and