On Sep 7, 2008, at 10:20 AM, Paul Pedriana wrote:
I agree that a union is most portable, but there are two problems with it:
- The C++ Standard (section 9.5 p1) disallows union members that have ctors, dtors, or assignment operators. This includes the case whereby the class is the only non-POD of the union.
- It would create an instance of type T. Thus an empty Vector would construct an instance of T, resizing it would overwrite the instance of T, and on destruction it would destruct the T.
Oliver also pointed out the constructor / destructor issue, so yeah, this wouldn't work. We could use double to force 8-byte alignment but that might be wasteful for vector types where wider alignment is not required. - Maciej
Paul
On Sep 4, 2008, at 1:20 AM, Paul Pedriana wrote:
Well the proposed solution in <https://bugs.webkit.org/show_bug.cgi?id=16925> doesn't work, as VC ++ doesn't accept that syntax. And the solutions in <https://bugs.webkit.org/show_bug.cgi?id=19775> whereby a uint32_t or uint64_t buffer are made don't work for larger types and use more memory than necessary. They might be useful as a fallback for compilers that don't support alignment directives, though the primary implementations of every compiler that I work with (GCC, VC++, CodeWarrior, EDG, SN, IBM) support it.
The buffer should definitely remain char to avoid strict aliasing problems. However, I think the most portable way to ensure alignment is to union the buffer with a one-element array of the template parameter type T.
- Maciej
I'll make a patch and attach it to <https://bugs.webkit.org/show_bug.cgi?id=16925>, if that's OK.
Paul
On Sep 4, 2008, at 2:05 AM, Paul Pedriana wrote:
I see that JavaScriptCore/wtf/Vector.h has this:
// FIXME: Nothing guarantees this buffer is appropriately aligned to hold objects of type T. char m_inlineBuffer[m_inlineBufferSize];
We have a bug for this: <https://bugs.webkit.org/show_bug.cgi?id=16925>. Also, <https://bugs.webkit.org/show_bug.cgi?id=19775>.
There are several patches and suggestions in these bugs, which wait for someone to submit them as clean patches.
- WBR, Alexey Proskuryakov
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev