The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,509 other followers

Archive for the ‘C’ Category

gdbgui – browser based debugger for C, C++, go, rust, Fortran. Modern gdb frontend.

Posted by jpluimers on 2019/03/05

[WayBack] gdbgui – browser based debugger for C, C++, go, rust, Fortran. Modern gdb frontend.: gdbgui (gnu debugger graphical user interface)

Via: [WayBack] Browser-based debugger for C, C++, go, rust, and more – written in Python with Flask. https://github.com/cs01/gdbgui Easy installation via PyPI: pip i… – Joe C. Hecht – Google+

–jeroen

Posted in C, C++, Debugging, Development, Fortran, GDB, Go (golang), Python, Scripting, Software Development | Leave a Comment »

performance – Why is this C++ code faster than my hand-written assembly for testing the Collatz conjecture? – Stack Overflow

Posted by jpluimers on 2019/02/28

Geek pr0n at [WayBackperformance – Why is this C++ code faster than my hand-written assembly for testing the Collatz conjecture? – Stack Overflow

Via: [WayBack] Very nice #Geekpr0n “Why is C++ faster than my hand-written assembly code?” The comments are of high quality i… – Jan Wildeboer – Google+

–jeroen

Posted in Assembly Language, C, C++, Development, Software Development, x64, x86 | Leave a Comment »

cdecl: C gibberish ↔ English

Posted by jpluimers on 2019/02/20

Cool site if I ever need to decipher C declarations again: [WayBackcdecl: C gibberish ↔ English.

You can even store the C code as a URL.

via:

–jeroen

Posted in C, Delphi, Development, Software Development | 2 Comments »

Fast inverse square root – Wikipedia

Posted by jpluimers on 2019/01/24

Cult code via [WayBack] Fast inverse square root – Wikipedia part of [WayBack] Quake-III-Arena/blob/master/code/game/q_math.c:

float Q_rsqrt( float number )
{
    long i;
    float x2, y;
    const float threehalfs = 1.5F;

    x2 = number * 0.5F;
    y  = number;
    i  = * ( long * ) &y;                       // evil floating point bit level hacking
    i  = 0x5f3759df - ( i >> 1 );               // what the fuck? 
    y  = * ( float * ) &i;
    y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
// y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

    return y;
}

It is a really fast way to approximate the square root for 32-bit IEEE754 calculations having origins around 1986:

  • [WayBackSymplectic Spacewar » Cleve’s Corner: Cleve Moler on Mathematics and Computing:

    Cleve Moler replied on June 27th, 2012 9:35 pm UTC :

    Jotaf — Thanks very much for your comment, and for reminding me about the fast inverse square root hack. I didn’t realize that the trick had attained a kind of cult status in the graphics community. The trick uses bit-fiddling integer operations on a floating point number to get a good starting approximation for Newton’s iteration. The Wikipedia article that you link to describes the trick in great detail, and also links to an article by Rys Sommefeldt about its origins. Sommefeldt goes back to the late ’80s and to me and my colleague Greg Walsh at Ardent Computer. I actually learned about trick from code written by Velvel Kahan and K.C. Ng at Berkeley around 1986. Here is a link to their description, in comments at the end of the fdlibm code for sqrt. http://www.netlib.org/fdlibm/e_sqrt.c . — Cleve

  • [WayBack] http://www.netlib.org/fdlibm/e_sqrt.c 

By now there is also a constant for 64-bit IEEE754 calculations 0x5fe6ec85e7de30da by [WayBack] 2003 research from Chris Lomont who also found a better 32-bit constant 0x5f375a86.

Note you need to be careful with boundary values like zero and infinity. This holds for approximations in general: [WayBackperformance – Why is SSE scalar sqrt(x) slower than rsqrt(x) * x? – Stack Overflow

–jeroen

Posted in Algorithms, C, Development, History, Software Development | Leave a Comment »

UTF-8 support for single byte character sets is beta in Windows and likely breaks a lot of applications not expecting this (via Unicode in Microsoft Windows: UTF-8 – Wikipedia)

Posted by jpluimers on 2018/12/04

Uh-oh: [WayBack] Unicode in Microsoft Windows: UTF-8 – Wikipedia:

Microsoft Windows has a code page designated for UTF-8code page 65001. Prior to Windows 10 insider build 17035 (November 2017),[7] it was impossible to set the locale code page to 65001, leaving this code page only available for:

  • Explicit conversion functions such as MultiByteToWideChar
  • The Win32 console command chcp 65001 to translate stdin/out between UTF-8 and UTF-16.

This means that “narrow” functions, in particular fopen, cannot be called with UTF-8 strings, and in fact there is no way to open all possible files using fopen no matter what the locale is set to and/or what bytes are put in the string, as none of the available locales can produce all possible UTF-16 characters.

On all modern non-Windows platforms, the string passed to fopen is effectively UTF-8. This produces an incompatibility between other platforms and Windows. The normal work-around is to add Windows-specific code to convert UTF-8 to UTF-16 using MultiByteToWideChar and call the “wide” function.[8] Conversion is also needed even for Windows-specific api such as SetWindowText since many applications inherently have to use UTF-8 due to its use in file formats, internet protocols, and its ability to interoperate with raw arrays of bytes.

There were proposals to add new API to portable libraries such as Boost to do the necessary conversion, by adding new functions for opening and renaming files. These functions would pass filenames through unchanged on Unix, but translate them to UTF-16 on Windows.[9] This would allow code to be “portable”, but required just as many code changes as calling the wide functions.

With insider build 17035 and the April 2018 update (nominal build 17134) for Windows 10, a “Beta: Use Unicode UTF-8 for worldwide language support” checkbox appeared for setting the locale code page to UTF-8.[a] This allows for calling “narrow” functions, including fopen and SetWindowTextA, with UTF-8 strings. Microsoft claims this option might break some functions (a possible example is _mbsrev[10]) as they were written to assume multibyte encodings used no more than 2 bytes per character, thus until now code pages with more bytes such as GB 18030 (cp54936) and UTF-8 could not be set as the locale.[11]


  1. Jump up^ [WayBack“UTF-8 in Windows”Stack Overflow. Retrieved July 1, 2011.
  2. Jump up^ [WayBack“Boost.Nowide”.
  3. Jump up^ [WayBackhttps://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/strrev-wcsrev-mbsrev-mbsrev-l
  4. Jump up^ [WayBack“Code Page Identifiers (Windows)”msdn.microsoft.com.

Via [WayBack] Microsoft Windows Beta UTF-8 support for Ansi API could break things. Wiki Article of the Change… – Tommi Prami – Google+

Related, as handling encoding is hard, especially if it is changed or not your default:

–jeroen

Posted in .NET, C, C++, Delphi, Development, Power User, Software Development, Windows, Windows 10 | 2 Comments »

 
%d bloggers like this: