Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
berkus wrote:Yes, the classic Mac OS 9 did this. Your programs would have a handle to the memory region instead of a pointer, and whenever they need to access this area they would dereference the handle using a library provided function, that returns a pointer and also locks this memory region from moving. You have to call a UnlockHandle(hmem); sort of function later to indicate that you are done with this memory and it can be occasionally moved.
Windows 3 did this too. AFAIK it is still supported by Windows as a dummy. It does make sense when there is no virtual memory and no opaque way to swap memory.
pcmattman wrote:Don't forget placement new - very rarely used...
I object. Use it quite often instead of reinterpret casts over predefined structures in memory. I.e. instead of...
Oh thank you, and +{INF}.
<reinterpret_cast> is among the "warning signs: bad C++ code might be ahead". Like new outside constructors, delete outside destructors, malloc/free, and a couple others.
Thanks for a very well-done example for placement-new.
Every good solution is obvious once you've found it.
pcmattman wrote:Don't forget placement new - very rarely used...
I object. Use it quite often instead of reinterpret casts over predefined structures in memory. I.e. instead of...
Oh thank you, and +{INF}.
<reinterpret_cast> is among the "warning signs: bad C++ code might be ahead". Like new outside constructors, delete outside destructors, malloc/free, and a couple others.
Thanks for a very well-done example for placement-new.
Although I see the use (the constructor is called), for PODs a simple reinterpret_cast seems much clearer. Also: placement new involves an extra function call, while (I believe) reinterpret_cast is just a compile-time check but doesn't change much (or even anything) about the code in question, it is just interpreted differently. I don't think I've ever had to use placement new, so I guess what pcmattman said applies to me.
While I agree that casts should be avoided (isn't that the whole reason why keywords in C++ are so long, like look at reinterpret_cast, the length is an abomination compared to a C cast), I like to see low-level and kernel development one of the places where their use is justified.
When the chance of succeeding is 99%, there is still a 50% chance of that success happening.
Creature wrote:While I agree that casts should be avoided (isn't that the whole reason why keywords in C++ are so long, like look at reinterpret_cast, the length is an abomination compared to a C cast), I like to see low-level and kernel development one of the places where their use is justified.
The reasons for the long C++ cast keywords are twofold:
it makes it explicit what you are casting (static, dynamic, reinterpret, const) instead of using a single syntax for all those uses;
it makes casts grep-able.
Especially the latter can be immensely useful in maintenance work - C casts cannot be grep'ed with reasonable confidence.
Every good solution is obvious once you've found it.
