[1718627440]

In the general case yes, but "C/C++" became an idiom for the stance, that C and C++ are essentially the same, that C++ is a superset of C or that C++ is just the replacing successor of C and it should be treated as superseded. This is quite wrong and thus there is a lot of rightful intervention to that term. Personally I use "C, C++" when I want to talk about both without claiming, that they are the same language.

[pjmlp]

Nah, that is what pedantic folks without English grammar knowledge keep complaining about, instead of actually discussing better security practices in both languages.

It is a bikeshedding discussion that doesn't help in anything, regarding lack of security in C, or the legions of folks that keep using C data types in C++, including bare bones null terminated strings and plain arrays instead of collection types with bounds checking enabled.

[jb1991]

This has nothing to do with bikeshedding, it is a genuine misunderstanding of these two languages that is propagated in this way. This is not about grammar.

[pjmlp]

Yet those complaining usually make use of plenty C constructs, data types and standard library on their C++ projects, instead of modern C++ practices.

[1718627440]

"C-like" code in C++ still has C++ semantics. "modern C++" is a disputed paradigm, but not necessarily how things should be done. When you write C++, but not "modern C++", that doesn't mean you are writing C. There are also modern features in C. https://floooh.github.io/2019/09/27/modern-c-for-cpp-peeps.h...

[pjmlp]

Null terminated strings with pointer arithmetic instead of std::string and string_view, pointer arithmetic instead of std::span, bare pointer arrays instead of std::array and std::vector, C style casts,...

[1718627440]

Sure, that is all modern C++, but we are talking about C vs. C++, not about C++ vs. modern C++ and we certainly don't want to conflate non-modern C++ with C.

[1718627440]

In my opinion, this is an important issue and not "bikeshedding", but it can be discussed whether the term "C/C++" is always an example of that idea or not. I think it is not, but it is connected enough, that I won't use it to side step the issues.

[pjmlp]

So there will be zero C language constructs, and C standard library functions being called, on your C++ source code?

[1718627440]

I mostly write C, but yes even a simple call to e.g. malloc has different semantics in C++ (you need to cast).

[pjmlp]

Proper C++ should use new, delete, custom allocators, and standard collection types.

Even better, all heap allocations should be done via ownership types.

Calling into malloc () is writing C in C++, and should only be used for backwards compatibility with existing C code.

Additionally there is no requirement on the C++ standard that new and delete call into malloc()/free(), that is usually done as a matter of convenience, as all C++ compilers are also C compilers.

[1718627440]

> Calling into malloc () is writing C in C++, and should only be used for backwards compatibility

And this is exactly the stance I am arguing against. C++ is not the newer version of C. It forked of at some point and is a quite different language now.

One of the reasons I do use malloc for, is for compatibility with C. It is not for backward compatibility, because the C code is newer. In fact I actively change the code, when it needs a rewrite anyway, from C++ to C.

The other reason for using it even when writing C++ is, that new alone doesn't allow to allocate without also calling the constructor. For that I call malloc first and then invoke the constructor with placement new. For deallocating I call the destructor and then free. This also has the additional benefit, that your constructor and deconstructor implementation can fail and you can roll it back.

[bnolsen]

Custom allocators in c++ was never enjoyable nor easy. It introduces more template slop everywhere. That's one thing I really liked about eastl, it did allocators much better. But it wasn't maintained.