Jump to content

  • Log In with Google      Sign In   
  • Create Account

Erik Rufelt

Member Since 17 Apr 2002
Offline Last Active Today, 03:16 PM

Posts I've Made

In Topic: Lowest Apple device to target and what market share?

Today, 01:57 PM

iPhone 4s / iPad 2 is probably a good target. iPhone 4 / iPad 1 have significantly lower performance, single core and worse GPU, but not many people still use them so I wouldn't worry about it, though if you can test on one that would be a good idea, might work. iPad 2's were sold up until quite recently as a low-end model too.. though I think they were slightly upgraded compared to the first variant.

Found this with Google for example that shows some performance measurements: http://28byteslater.com/2012/12/30/relative-iphoneipad-performance/

In Topic: Efficient way to erase an element from std::vector

Today, 06:44 AM


Wouldn't it be enough to test for std::is_trivially_copyable? Requiring the whole more restrictive POD-property seems unnecessary.

Yep. I forgot that C++'s definition of POD is now stupidly restrictive. I usually use "POD" to mean "memcpy-safe", which apparently C++ calls "trivially copyable" now sad.png



I would even say is_trivially_destructible. Though I'm not entirely sure on that one, and actually for performance-reasons I don't think it can even be determined from such traits, as it would depend on their internals. But for the general complexity it's interesting.


As far as I see it, swap is always better than copy/assign (whether or not trivially) when there are parts of the object that need to be destructed, as otherwise any non-trivial original contents of [index] would be destructed before replaced with their new values from back(), and then back() would be destructed at some point (though it could of course at times be optimized out to a copy in the assignment, but worst-case).

When swapping out the objects internals, no potential extra destruction can take place.


However, there is another case where swap is worse, which is when there is no destructor so the object removed at back() never needs to be destructed. At that time it is completely unnecessary to swap the contents instead of just copying them (if copying would be faster, which may or may not be the case of course). For a trivially copyable object it's obvious, one memcpy instead of swapping.


What I was originally wondering was whether there is any chance the compiler can assume that the pop_back() means the memory at back() is undefined and therefore optimize away the swap and replace with a memcpy when appropriate. If destruction of an object means that the contents of the memory that object occupied is undefined afterwards it could theoretically.. and perhaps even realistically in simple inlined cases like this. I'm not sure that is actually a rule though?

In Topic: Efficient way to erase an element from std::vector

Today, 02:16 AM

Out of curiosity, does anyone know if there is any chance the swap can be optimized to a move when the items don't have destructors?

I guess that could be difficult unless the memory in the vector is actually shrunk..

Not that it should really matter, but for large POD types it seems unnecessary to exchange the memory instead of just copying.

In Topic: Impossible to Detect Window Starting Unfocused? (Windows)

25 January 2015 - 12:37 PM

It also wouldn't cause any serious issues with full-screen applications


The window still receives those messages, even if it is a fullscreen borderless window.

In Topic: Impossible to Detect Window Starting Unfocused? (Windows)

25 January 2015 - 12:17 PM

I think this is just some sort of bug in Windows that's always been there.. or perhaps there's some strange reason for it. The "local app system" or whatever the part of Windows deals with window focus probably considers the window to have focus, whereas the higher level system that determines if to send the input to the app or thread at all knows that it shouldn't send it there.

You can use WM_NCACTIVATE and check wParam to know if the window title-bar will be drawn active or inactive, which should be enough to know if you're active..