C/C++: string redemption

Het concept van string (oftewel char*) is een enorm drama in C/C++.
Redenen:
1) char (byte) is niet genoeg om UTF-8 strings te bevatten.
2) als je strings wilt samenvoegen, dan moet je eerst vantevoren gokken hoeveel characters je nodig hebt. Meestal komt het uit op een (te) ruime allocatie, bijvoorbeeld char[255], terwijl je er bijvoorbeeld maar 60 nodig hebt. Die ruimte wordt gereserveerd op de stack en die loopt sneller vol. Dus echt hardcore string crunching kun je op die manier niet doen, want dan krijg je een stackoverflow.
3) als er geen \0 aan het einde van de string staat, dan heb je een bufferoverrun te pakken. Een manier die hackers gebruiken om toegang tot je geheugen te krijgen.
4) beperkte C string library functions, waardoor bijvoorbeeld Howard Chu terecht klaagt over coderegels zoals: strcat(strcat(strcat(strcpy(buf, "This "),"is "),"a long "),"string.");

De beste vervangende string library voor C die ik gevonden heb is The Better String Library.

Sound Libraries

Als je een geluid wilt afspelen in je SDL 2 game, heb je verschillende optie's:
1) Gebruik de SDL_Mixer die bij SDL2 wordt geleverd. Maar een pitch of snelheid van een sample kun je niet aanpassen.
2) Gebruik https://github.com/RandyGaul/cute_headers. Daarmee kun je de pitch van een sample aanpassen, maar weer niet de speed.
3) Gebruik http://sol.gfxile.net/soloud/quickstart.html. Deze library gebruik ik, omdat je de speed van een sample kunt aanpassen en het heeft een goede interface met OpenMPT, zodat je amiga modules kunt afspelen.

Low level x64 optimalisatie

In een game heb ik een innerloop die 5.9ms duurt met o.a. de volgende instructie's:

cvtsi2ss xmm4, rcx
cvtsi2ss xmm5, r11
divss xmm4, xmm5

Breid ik de loop uit met het ophalen van een precalculated value, dan verwacht ik dat de innerloop langer duurt dan 5.9ms:

cvtsi2ss xmm4, rcx
cvtsi2ss xmm5, r11
divss xmm4, xmm5
movss xmm4, real4 ptr [rcx*4+r10]  ; precalculated value in xmm4

Maar de innerloop duurt nu nog maar 4.1ms!

Dit betekent dat de processor zelf doorheeft dat xmm4 na de divss instructie opnieuw wordt gevuld, dus skipt hij de divss instructie. Slim!

Zowel in SSE(x64 SIMD) als normale x64 blijkt een DIV zeer traag te zijn. In dit geval zorgt de enkele DIVSS-instructie voor 1.8ms vertraging in m'n innerloop. Precalculation is dus de moeite waard.
Aangezien je in SSE floating point berekeningen niet shift kunt gebruiken voor een deling, moet je erg opletten wat je doet.