On Saturday, 21 March 2015 at 00:42:22 UTC, Andrei Alexandrescu wrote:
>
> Are you sure you're not missing the part where D's ++var and var++ generate identical code if the result isn't taken? -- Andrei

No I am not missing it. I think I need to explain why I am doing all of this.

I am currently looking for rules and programming styles that would reduce number of bugs and/or make my program run or at least compile faster. So I read that you should prefer pre increment to post increment. So I investigate and concluded that for the most part it doesn't matter. But that "most if the time" thing bugged me over a month. I investigated more and I was jumping constantly between it matters and it doesn't matter. Every time I jump to it matters the amount of matters shrinks. So now I am on the quest to quantify how much it matters and if it doesnt matter I could say to anybody who repeats it to eat a bowl of dicks.

In C++ world always writing ++var can save some perf when using with overloaded operators. In D world it has no result on resulting binary and the use of these operators is reduced with foreach.

On 3/21/15 9:59 AM, welkam wrote:
> On Saturday, 21 March 2015 at 00:42:22 UTC, Andrei Alexandrescu wrote:
>>
>> Are you sure you're not missing the part where D's ++var and var++
>> generate identical code if the result isn't taken? -- Andrei
>
> No I am not missing it. I think I need to explain why I am doing all of
> this.
>
> I am currently looking for rules and programming styles that would
> reduce number of bugs and/or make my program run or at least compile
> faster. So I read that you should prefer pre increment to post
> increment.

That's only for generic C++ code. At a minimum you're in the wrong forum. Also as I said, using post operations for integrals may be faster, so even in C++ it's not that clear cut.

Andrei

On 3/15/2015 1:45 AM, Jonathan M Davis via Digitalmars-d wrote:
> On Saturday, March 14, 2015 15:35:24 Ali Çehreli via Digitalmars-d wrote:
>> C++ needs a rule like D's, which will never be there.
> Yep. By making it so that you only overload a single operator for both
> versions of increment, we avoid the whole problem in D, similar to how
> having opCmp avoids bugs related to having to define each comparison
> operator individually as is the case in C++.

There's another reason why D specifies some arithmetic identities for overloading arithmetic operators. It's to make abominations like C++ iostreams that overload operators for non-arithmetic tasks much harder to do.

On Saturday, 21 March 2015 at 16:59:05 UTC, welkam wrote:
> In C++ world always writing ++var can save some perf when using with overloaded operators.

Do you have an example?

On Monday, 23 March 2015 at 08:20:59 UTC, Kagamin wrote:
> On Saturday, 21 March 2015 at 16:59:05 UTC, welkam wrote:
>> In C++ world always writing ++var can save some perf when using with overloaded operators.
>
> Do you have an example?

The compiler cannot optimize away calls to external functions (such as operator new, as is my experience) that it cannot inline/see fully (I may be not 100% correct here, but I'm pretty sure it's in the right ballpark).

Here's an example, compare foo() and bar() (note the -O3): http://goo.gl/H9tCaK

Well, things like std::string are not cooperative in this regard. Though, it's copied only to be instantly destructed, theoretically it should be elided if the involved constructors are annotated with sufficient purity or complementary operators. Also the iterator pretends to be copyable, but it can't resume from the point where it was copied, can it?

On Monday, 23 March 2015 at 12:10:32 UTC, Kagamin wrote:
> Well, things like std::string are not cooperative in this regard. Though, it's copied only to be instantly destructed, theoretically it should be elided if the involved constructors are annotated with sufficient purity or complementary operators.


That's why using preincrementation is the preferred default - you simply can't know predict what the user's type will do. And sure, maybe the compiler should optimize it away in this case, but as you can see, the pragmatic solution is to simply avoid this problem entirely.

> Also the iterator pretends to be copyable, but it can't resume from the point where it was copied, can it?
Depends on the iterator type, in this case: no, I don't believe that it can be resumed.