News for hackers. Stuff that matters.

A comment on C++ for Games: Performance, Allocations and Data Locality. Parent comment

Re:C++ for Games: Performance, Allocations and Data Locality by Kristine1975 on Monday May 30, 2016 @03:23AM (#11800054)
But since the copy won't be used, the compiler should omit it even for class types, since it can assume the copy constructor has no side-effects (if the copy constructor is not trivial in the first place).
[ Parent | on HN ]
Re:C++ for Games: Performance, Allocations and Data Locality by Someone on Monday May 30, 2016 @05:20AM (#11800422)
I don't see why the compiler is allowed to assume that. For example, the class might collect statistics on #allocations, log them (e.g. for debugging purposes), or the iterator might create new objects (e.g. when the iterator is iterating over a (potentially) infinite sequence that gets created in a database on the fly)

I think the compiler should prove that constructing and destroying the object doesn't have side effects before skipping those steps.

[ Parent | on HN ]
Re:C++ for Games: Performance, Allocations and Data Locality by cynicalkane on Monday May 30, 2016 @09:40AM (#11801265)
If you want your iterator to be fast, its implementation will be in a header file, at which point the C++ compiler can inline and omit the copy entirely.
[ Parent | on HN ]
Re:C++ for Games: Performance, Allocations and Data Locality by Someone on Monday May 30, 2016 @12:52PM (#11802085)
Of course, but that isn't making an assumption, as the OP said the compiler might do.
[ Parent | on HN ]
Re:C++ for Games: Performance, Allocations and Data Locality by adrianN on Monday May 30, 2016 @06:01AM (#11800550)
https://en.wikipedia.org/wiki/Copy_elision

I used to wonder the same thing, but C++ is just weird in that way.

[ Parent | on HN ]
Re:C++ for Games: Performance, Allocations and Data Locality by exprA on Monday May 30, 2016 @09:56AM (#11801358)
That's only partially related to topic at hand. Even in cases where copy elision takes place, and object is still constructed.

However, as was said before, any performant iterators ought to be header-only implementations, and if they have no side effects, I don't see why a compiler might not do away with the copy altogether.

Personally I always use the prefix increment (unless the other behaviour is needed).

[ Parent | on HN ]