Re: Future of C++ and Boost

From: Gavin Lambert (boost_at_[hidden])
Date: 2022-04-25 23:56:18

On 26/04/2022 07:45, Soronel Haetir wrote:
> On 4/25/22, Hans Dembinski wrote:
>>
>> Why anyone would prefer programming in C over C++ is a mystery to me,
>> though, automatic memory management with std::unique_ptr and friends alone
>> is such a boon. The C++ interface provided by Boost.Python and pybind11 is
>> much easier to use than the original Python C API exactly for that reason.
> 
> One major reason for choosing C is that it provides a much wider
> compatibility window. That is, it is possible to link C-derived object
> files from a much wider set of tools into a single result binary. Even
> setting name mangling aside, C++ ABIs changed so frequently that it is
> generally unsafe to link C++ objects generated by different toolchains
> (often even the same toolchain with different options). C, on the
> other hand, has far fewer pitfalls in this regard.

Another reason that I have sometimes preferred C over C++ is for 
embedded firmware where (a) the compilers or standard libraries for C++ 
are sometimes more fragile [although since most of them have migrated to 
gcc/clang these days, that's usually less of an issue, though some still 
persist with a custom library] and (b) with C code you get pretty much 
exactly what you put in, whereas with C++ there can be a lot more hidden 
code and (sometimes critically) hidden memory allocations and exception 
paths, and there are often places where you need to absolutely guarantee 
that no memory allocation occurs.

While it is certainly possible to use C++ in a fashion that guarantees 
no exceptions and memory allocations, and there are a lot of things that 
are nicer to write with stronger typing and templates, it's a lot easier 
to accidentally write unsafe C++ code than unsafe C code.  (Conversely, 
code that does have dynamic memory allocation is typically safer to 
write in C++.)