Debugging GDI drawing

GDI debugging

 The other day I had to debug a hard to track drawing bug. The application is built with the MFC framework so it still uses GDI on places to draw custom controls.

 The incorrect drawing artifact was displayed after an invocation of 'DrawText'. This was unexpected since the function only measured the size. It had the flag 'DT_CALCRECT' which does not draw to the screen. Eventually I realized that  GDI batches calls so probably the buggy overdrawing had already taken place before. What was needed:

•  suppress GDI's caching mechanism through 'GdiSetBatchLimit'.
•  use direct drawing; so no memory device context

 With this in place indeed it could be seen that the mistake happened earlier in the code and that the 'DrawText' invocation was merely a flush of the GDI batch.

 Be aware that suppressing  GDI's batch might not always work. When the window where the drawing took place was on the primary monitor the batch mode could be turned off but on the second monitor it still cached its calls.

Watch out for an old VC++ runtime

 VC_redist.x64.exe

 For C/ C++ applications the VC++ runtime needs to be installed on the computer. The other day we experienced crashes when a component developed with a late version of VS2022 was crashing on a fresh installation of Windows 11. It turned out that this Windows 11 still uses an old version of the VC++ runtime which could crash the application (most notably in grabbing a std::mutex lock). After updating the PC with a recent version of 'VC_redist.x64.exe' the problem was solved.

 

ark.intel.com

 

ark.intel.com

 Intel had a wonderful website where one could easily lookup the processor and see what capabilities (e.g. SSE 4.2; AVX; AVX2) it had. In a recent visit it was completely overhauled and they have removed (or hidden) the easy possibility to lookup your processor with one click. Thanks Intel for modernizing their website and destroying a valuable functionality.

Watch out for atan change in Visual Studio 2022 17.14.6

atan

 Recently we updated Visual Studio 2022 17.14.6 and the regression test reported errors. It turned out that atan implementation was changed resulting a different value for debug vs release builts with CPU's having AVX2. One can recreate this with the following values:

    const double ax          = 38.176459921094995;
    const double ay          = 15.964755390006060;
    const double dblRotation =  atan(ay/ax);

 We had to relax the equality checks; even for deterministic calculations.

Careful with std::wfstream

wchar_t file streams

 The std::wfstream is similar to std::fstream except it accepts wchar_t. However it does not write std::wchar_t characters to file. Suppose the following code:

   std::wofstream ofs;
   ofs.open(L"c:\\temp\\1.txt" , std::ios_base::out | std::ios_base::binary) ;
   ofs.write(L"ABC", 3);

 On the Windows platform this writes just single bytes characters to the file. The reason is that the locale bound to the file stream translates wchar_t to char. This can be fixed by using a custom locale which doesn't do this. This translation is quite unexpected behavior since the function prototypes are defined in terms of wchar_t. It is also different compared to the wchar_t string streams: std::wstringstream does write wchar_t strings unaffected.

 This page was inspired by a YouTube comment of me where I stated that the C FILE api is less surprising. Of course there is always a clown who thinks better but probably doesn't know anything about above issue. With C stream I/O FILE and 'fwrite' the bytes are transferred to the file without interpretation and alteration.

FILE wrapper

 Jason Turner goes a lengthy way of wrapping the C FILE api but using a wrapper class would probably be simpler:

class c_file
{
public:
   c_file()
      : m_fp(nullptr)
   {
   }
   
   explicit c_file(const std::filesystem::path& rpth, const char* pszMode)
      : m_fp(fopen(rpth.string().c_str(), pszMode))
   {
   }

   ~c_file()
   {
      if (m_fp)
      {
         fclose(m_fp);
      }
   }

   c_file(const c_file&) = delete;

   c_file(c_file&& rOther) noexcept
      : m_fp(std::exchange(rOther.m_fp, nullptr))
   {
   }

   c_file& operator=(const c_file&) = delete;

   c_file& operator=(c_file&& rOther) noexcept
   {
      std::swap(m_fp, rOther.m_fp);
   }

   explicit operator bool() const
   {
      return m_fp;
   }

   size_t read(void* pBuffer, size_t size, size_t count)
   {
      return fread(pBuffer, size, count, m_fp);
   }

   size_t write(const void* pBuffer, size_t size, size_t count)
   {
      return fwrite(pBuffer, size, count, m_fp);
   }

   // etc.

private:
   FILE*    m_fp;
};

Links

•  C++ Weekly - Ep 482 - Safely Wrapping C APIs

C++ horrible aspects

C++ horrible aspects

 Linus Torvalds described C++ as being a horrible language. While C++ has its dark corners I choose it any day over any other language. Especially compared to C with its major security liabilities. There are some questionable aspects though: 

• 'rvalue' references becoming 'lvalue' references. Not sure who invented this but he or she should be banned from the committee. Super confusing that a type can change.
  
• universal references and perfect forwarding. Again a very confusing idea to reuse the 'rvalue' reference syntax. The reference collapsing rules doesn't make it easier either
  
• two phase lookup. Confusing rule which could have been solved by stating that a template definition is only checked at instantiation time. No more need for 'typename' or making types and member functions (non) dependent since at instantiation time all type and context information is known
• lack of uniformity in STL. For example there is reset and clear. Some algorithm's have _if variants when taking functors; others not.
• functional programming style over object oriented. Why not make the regex functions member functions? It prevents clutter of std namespace. It will probably also help Intellisense to build up its database which is important help in IDE's these days. 
• uniform initialization. Again the committee made a mistake. The issue could be fixed by requiring double braces in case constructor invocation (e.g.std::vector<size_t>{{2}})
• the ranges library has some strange aspects as well as can be seen here. 

Besides these aspects C++ misses out on an extended standard library. Especially compared to .NET or Java where many things are present in their extensive standard library. One need frequent 3th party libraries (e.g. Boost) for basic things. This could have been alleviated if there was a standard package manger like in Python with de facto libraries but again there isn't.

Careful with that initializer_list part 2

initializer_list

 When using Boost.JSON I stumbled upon the following issue:

boost::json::value jv(1);  // creates a number type
boost::json::value jv{1};  // creates an array type

 The JSON value object has constructor definitions something like these:

struct value
{
   value(int);
   value(double);
   value(std::initializer_list<int>);
};

 This gives the following invocations:

value vl1(1);  // invokes value(int) constructor
value vl2{1};  // invokes value(std::initializer_list<int>); constructor

 This is a know issue in C++. A programming language should be unambiguously be interpretable and the C++ had decided that in such case the initializer_list has precedence. Not sure if that's a good solution since the ambiguity may only appear when running under the debugger or at customer site. The ambiguity can be solved by requiring double braces in case there are overloads like this but the all wise C++ committee has decided otherwise. The uniform initialization problem is still not solved.

 Edit: this behavior has now been patched as of Boost 1.86. If the initializer_list has size 1 it's assumed to be a single value type instead of array. Original behavior can be mimicked by using BOOST_JSON_LEGACY_INIT_LIST_BEHAVIOR. Pretty smart trick t.b.h.