Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Very likely as the others said this is an alignment issue. Now there are a few ways you can fix it, and test it.</p> <p>The easiest is to use malloc, or new, to allocate the buffer on the heap. Malloc guarantees that the returned pointer will be suitable for alignment of the largest native data type. On Intel 64-bit chips that will mean it is aligned to a 128-bit double.</p> <pre><code>char * buffer = malloc( n * sizeof(int) ); int * at = (int*)buffer + ndx; </code></pre> <p>It looks like your original <code>+n</code> was also wrong. The way you did it was to offset the char ptr, so by 1 byte, rather than the int ptr, by 4 bytes. This could also explain the slowdown if you were copying the integers. This is because you may have inadvertently been using integers that overlap the same memory location.</p> <p>If you must use stack allocation, and it does come up, you can also align that. <em>There is a boost function that does this I believe as well</em></p> <pre><code>char cbuffer[1024+sizeof(int)]; int * ibuffer = (cbuffer / sizeof(int) + 1) * sizeof(int); </code></pre> <p>Then <code>ibuffer</code> will be integer aligned. The actual pointer value may not be the same as for cbuffer, but in some cases it may be (depends on the stack at the time of the call). The second line is simple math on the pointer to ensure it is a multiple of sizeof(int), which means it is int aligned.</p> <p><em>new: Can somebody confirm if <code>new char[x]</code> also guarantees alignment as does <code>malloc</code>?</em></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload