5 ms·

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 th

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 1y ago
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.
- 1718627440 1y ago
  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 1y ago
    So there will be zero C language constructs, and C standard library functions being called, on your C++ source code?
    - 1718627440 1y ago
      I mostly write C, but yes even a simple call to e.g. malloc has different semantics in C++ (you need to cast).
      - pjmlp 1y ago
        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.
        deleted 1y ago
        [deleted]
        1718627440 1y ago
        > 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.
        pjmlp 1y ago
        So it would fail to compile when configuring static analysis to build on error when using C with C++ compiler. Finally, people like to argue between C and C++ when it convenient to do so, yet the compiler language switches to use C extensions in C++ mode keep being used across many projects.
        1718627440 1y ago
        > So it would fail to compile when configuring static analysis to build on error when using C with C++ compiler. What do you mean? I don't think I can follow you. > yet the compiler language switches to use C extensions in C++ mode keep being used across many projects. When you use compiler extensions, that just happen to be both available in C and C++, I wouldn't say you are writing C in C++, I mean the extension isn't standard C either. Code written in C++ has different semantics, even when it is word-for-word the same as C code. They ARE different languages.
- jb1991 1y ago
  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 1y ago
    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 1y ago
      "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.html https://floooh.github.io/2019/09/27/modern-c-for-cpp-peeps.h...
      - pjmlp 1y ago
        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 1y ago
        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.

pjmlp 1y ago

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.

1718627440 1y ago
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 1y ago
  So there will be zero C language constructs, and C standard library functions being called, on your C++ source code?
  - 1718627440 1y ago
    I mostly write C, but yes even a simple call to e.g. malloc has different semantics in C++ (you need to cast).
    - pjmlp 1y ago
      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.
      - deleted 1y ago
        [deleted]
      - 1718627440 1y ago
        > 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.
        pjmlp 1y ago
        So it would fail to compile when configuring static analysis to build on error when using C with C++ compiler. Finally, people like to argue between C and C++ when it convenient to do so, yet the compiler language switches to use C extensions in C++ mode keep being used across many projects.
        1718627440 1y ago
        > So it would fail to compile when configuring static analysis to build on error when using C with C++ compiler. What do you mean? I don't think I can follow you. > yet the compiler language switches to use C extensions in C++ mode keep being used across many projects. When you use compiler extensions, that just happen to be both available in C and C++, I wouldn't say you are writing C in C++, I mean the extension isn't standard C either. Code written in C++ has different semantics, even when it is word-for-word the same as C code. They ARE different languages.
jb1991 1y ago
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 1y ago
  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 1y ago
    "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.html https://floooh.github.io/2019/09/27/modern-c-for-cpp-peeps.h...
    - pjmlp 1y ago
      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 1y ago
        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.