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:
constexpr double ax = 38.176459921094995;
constexpr double ay = 15.964755390006060;
const double dRotation = std::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;
};
Linus Torvalds described C++ as being a horrible language. C++ has its dark corners but I would choose it any day over any other language. This includes also Linus favorite C with its minimal support and security liabilities. Granted though there are many questionable aspects in C++:
Besides these aspects C++ misses out on an extended standard library. Compared to .NET or Java the C++ standard library is thin. One frequently need 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.
Despite all these issues I still prefer C++. One can decide to use what one is comfortable with and one needs. The exception mechanism is a topic of debate and many (embedded) environments choose not to use it. IMHO the constructor / destructor model is the most important aspect of C++. This alone gives the safety improvements over C through resource management and controlled access to raw buffers. Generic programming makes the STL possible which is another major reason to prefer C++ over C.
Linus Torvalds is a technical gifted person but his comments give the impression that he a hasn't a clue about C++. In the meantime some large applications and libraries (e.g. GCC; OpenCV) have made the shift and they never will go back to C. OpenCV code base is cleaned up with the move to C++: the manual and clumsy CvMemStorage and CvSeq are not needed anymore in C++. The Linux kernel could have benefited from the extra facilities C++ offers but the guy is stubborn as hell.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.
C++20 has added the the ranges library. Basically it works on ranges instead of iterators but added some subtle constraints to some algorithms. For example consider the lower_bound algorithm:
#include <algorithm>
#include <utility>
using IntPair = std::pair<int, int>;
IntPair a[1];
auto it = std::lower_bound(std::cbegin(a), std::cend(a), 1, [](const IntPair& r, int n) { return r.first < n; });
The lower_bound function only expects an asymmetric functor implementing the order between container and search element. To spare on typing out the begin and end iterator one could think to use the ranges library:
auto it = std::ranges::lower_bound(a, 1, [](const IntPair& r, int n) { return r.first < n; });
This gives though a ton of mystic error messages on VStudio:
1>error C2672: 'operator __surrogate_func': no matching overloaded function found
1>error C7602: 'std::ranges::_Lower_bound_fn::operator ()': the associated constraints are not satisfied
1>message : see declaration of 'std::ranges::_Lower_bound_fn::operator ()'
It turns out that the ranges variant expect a functor with all less combinations defined:
struct OpLess
{
bool operator() (const int n1, int n2) const { return n1 < n2; };
bool operator() (const IntPair& r1, const IntPair& r2) const { return r1.first < r2.first; };
bool operator() (const IntPair& r, int n) const { return r.first < n; };
bool operator() (int n, const IntPair& r) const { return n < r.first; };
};
auto it = std::ranges::lower_bound(a, 1, OpLess{});
Side note: concepts supposed to give more clearer error messages but are cryptic as well.