ICT has a rich history of hypes where people thought that this would be a panacea for all problems. These hypes lasted for some time like paradigms in Karl Popper's science philosophy. From the top of my head we had the following hypes in the past:
Since some period I started working with AI tooling. Mostly I use Gemini and Copilot inside Visual Studio. The experience is a bit of mixed feelings about this. Gemini had some good suggestions but failed also many times. Copilot has good code completion suggestions but misses the mark also. Copilot's function name suggestion are very welcome.
On the other hand AI tooling is still full of mistakes. Some examples:
Even worse that sometimes AI tooling can suggest plain bugs. I was implementing a swap of width and height and Copilot's code complete came up with the following code snippet:
// NOTE: incorrect Size sz = ...;
if (sz.GetWidth() < sz.GetHeight())
{
sz.SetWidth(sz.GetHeight());
sz.SetHeight(sz.GetWidth());
}
This doesn't swap but sets the width and height on the old height value.
AI tooling can be helpful but are still not on the level to be trusted blindly. They also now help with limited scope; e.g. code blocks; algorithms and functions. I am not aware if they can help in refactoring and extending architecture spanning solutions.
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' with the flag 'DT_CALCRECT'. This was unexpected since with the flag the function doesn't draw and only measures the size. Eventually I realized that GDI batches invocations so perhaps the buggy overdrawing had already taken place before. What was needed to prove this hypothesis:
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.
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.
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.
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.
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{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. It uses the codecvt of the imbued locale which translated wchar_t to char. The standard C locale does not handle characters above the 255 so it will fail when using other characters than the extended ASCII character set. It will also fail when writing binary data through the write interface. It can be fixed by using a custom locale which leaves wchar_t unaffected. There was a codeproject article on this but it has been retracted.
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 article was inspired by a YouTube comment of me where I stated that the C file stream 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.
Jason Turner goes a lengthy way of wrapping the C file stream 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;
};