Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Jul 2006
Offline Last Active Private

Posts I've Made

In Topic: DirectXMath - storing transform matrices

15 June 2016 - 03:19 PM

If you use the "vectorcall" calling convention it should be returned from the function in registers.

In Topic: DirectXMath - storing transform matrices

14 June 2016 - 05:15 PM

The simple option is to override global operator new and call _aligned_malloc (or similar) from it. If you do that you can make every heap allocation 16-byte aligned, with only a few lines of code in one place.

Doing that also means you can do things like putting aligned types in a std::vector.

Note that there's several variants of operator new and delete that you'll need to replace - you want to change the non-throwing variants as well.


Also note that if you compile as x64 instead of x86 then you don't need to do any of that. The standard heap allocation alignment on 64-bit Windows is 16 bytes.

In Topic: whats the "Big O" of this algo?

12 June 2016 - 05:27 AM

For reference, the sort algorithm that the standard library implements as std::sort() is usually https://en.wikipedia.org/wiki/Introsort which has an O(n log n) average and worst case performance, but it could also be something else.


https://en.wikipedia.org/wiki/Sorting_algorithm has a big table comparing performance and memory use of a variety of sort algorithms.

In Topic: Trivially trivial?

10 June 2016 - 05:32 PM

You could set up your own trait called say IsRelocatable<T>, other people have done it that way - https://github.com/facebook/folly/blob/master/folly/docs/Traits.md


I found some discussions at https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/wphImiqfX7Y[1-25] which suggest that some possible implementations of virtual functions aren't compatible with memcpy() but I don't know of any compilers where that's actually true.

In Topic: std::stringstream crash

07 June 2016 - 03:35 PM

That GDB output is showing that something has called strlen(NULL). Firstly, note that GDB shows that ecx is 0 at the time of the crash:


[debug]ecx            0x0    0


Here's some of your disassembly, highlighted to show what happened. You can see that ecx was loaded from the stack as the input parameter to strlen(). I'm thinking that parameter to strlen() probably comes from the "data" variable.


[debug]   0x752d43d3 <+0>:    mov    ecx,DWORD PTR [esp+0x4]
[debug]   0x752d43d7 <+4>:    test   ecx,0x3
[debug]   0x752d43dd <+10>:    je     0x752d43f9 <strlen+38>
[debug]   0x752d43df <+12>:    mov    al,BYTE PTR [ecx]
[debug]   0x752d43e1 <+14>:    add    ecx,0x1
[debug]   0x752d43e4 <+17>:    test   al,al
[debug]   0x752d43e6 <+19>:    je     0x752d4434 <strlen+97>
[debug]   0x752d43e8 <+21>:    test   ecx,0x3
[debug]   0x752d43ee <+27>:    jne    0x752d43df <strlen+12>
[debug]   0x752d43f0 <+29>:    add    eax,0x0
[debug]   0x752d43f3 <+32>:    lea    esp,[esp]
[debug]   0x752d43f6 <+35>:    lea    esp,[esp]
[debug]=> 0x752d43f9 <+38>:    mov    eax,DWORD PTR [ecx]


I can also see you have two threads around:


[debug]> info threads
[debug]  Id   Target Id         Frame
[debug]  2    Thread 65280.0xfab4 0x76fe6bf4 in ntdll!KiFastSystemCallRet () from C:\Windows\SYSTEM32\ntdll.dll
[debug]* 1    Thread 65280.0xf9a4 0x752d43f9 in strlen () from C:\Windows\system32\msvcrt.dll


Given that it looks like "data" is ending up as null, after you've compared it with null, my guess would be that one thread has changed the value of "data" while the other one is using it. If that's the case then that would suggest that "data" is a global variable, or a class member, which is being accessed on more than one thread, and that you're not using appropriate synchronization. Does that make sense?


There could of course be some other reason for the null pointer. I'm guessing somewhat because things like the declaration / definition of "data" isn't available.