4 ms·

C coder here (former pre-C++11 C++ as well). Another point to mention (which I think adds to the conclusion) is that by losing compatibility with the C preproc

C coder here (former pre-C++11 C++ as well). Another point to mention (which I think adds to the conclusion) is that by losing compatibility with the C preprocessor you'd lose compatibility with, well, C. This means breaking of both C++ code that uses C libraries legitimately and "C++" code that's actually C with new/delete (or "the horror" as we put it).

paulddraper 9y ago
True, and the worth remembering. If you did want to do this, you'd run a C processor on the C code first.
DSMan195276 9y ago
I would also add that when you're doing low-level work that requires mixing a bit of assembly and C (Or C++, but I mainly stick to C), being able to access the preprocessor from assembly is really nice. The alternative is redefining tons of stuff so you can use it in your assembly. It's a niche use-case obviously, but it is still a nice use-case regardless and I'd wager you could do this with lots of other languages if you ever had a want/need.
deleted 9y ago
[deleted]
pjmlp 9y ago
> by losing compatibility with the C preprocessor you'd lose compatibility with, well, C. Thankfully C++ no longer needs it to gain market share, it can stand on its own, while cleaning up the warts that caused unsafe code as a means of getting adopted.
- qb45 9y ago
  Ha ha ha, #ifdef __cplusplus extern "C" { #endif I guess you will have to rewrite libc.so and ntdll.dll in C++ first. Or at least fork them and maintain the fork indefinitely.
  - pjmlp 9y ago
    They are already written in C++, pay attention to the news! https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great-c-runtime-crt-refactoring/ https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great... "We have converted most of the CRT sources to compile as C++, enabling us to replace many ugly C idioms with simpler and more advanced C++ constructs. The publicly callable functions are still declared as C functions, of course (extern "C" in C++), so they can still be called from C. But internally we now take full advantage of the C++ language and its many useful features." Note the reference to ugly C idioms. Also all major C compilers are written in C++, including clang and gcc, did you miss that as well?
    - hawski 9y ago
      Seeing "replace ugly C idioms" my first reaction was: "why didn't they use "nice C idioms instead?".
      - pjmlp 9y ago
        Because nice C idioms is an oxymoron.
    - mkup 9y ago
      CRT != ntdll.dll and CRT != kernel32.dll. CRT is an optional component of Windows software, a layer above ntdll and kernel32. Anyone can easily compile a program without C runtime library using /Zl compiler option. In this case, only Win32 and native API functions will be available, but not functions like printf() or strcmp(). So latest versions of CRT could be rewritten in C++, but this has nothing to do with documented OS API or even low-level undocumented native API, which are both still pure C.
      - pjmlp 9y ago
        The compiler switch /kernel was introduced with Visual Studio 2012 (Windows 8). https://msdn.microsoft.com/en-us/library/jj620896(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/jj620896(v=vs.110).... C code is considered legacy by Microsoft with C++ being the official systems programming language, hence why they dropped support for newer C versions, except for what is required by ANSI C++ standard. https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an... Our focus in Visual C++ is on making a world-class C++ compiler Our primary goal is to support "most of C99/C11 that is a subset of ISO C++98/C++11." We do not plan to support ISO C features that are not part of either C90 or ISO C++. Also the future of Windows lies on UWP, and C is certainly not a way of writing UWP APIs, unless one enjoys low level COM Windows 95 style. Finally, the remaining C code is slowly being migrated to C++ https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_coded_in_c_or_assembler/d4g9we9/ https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_code...
evacchi 9y ago
I don't think C++ will ever shrink as a language (i.e., drop features), but we can reduce the learning surface for newcomers by making it simpler, more consistent, and relegating C-isms under the "backwards compatibility"umbrella.
- pjmlp 9y ago
  C++11, C++14 and C++17 have dropped features, now there is even a zombie keywords section on the standard. Meaning of auto, export templates, exception specifications were the biggest ones, there a few minor ones as well.
ericfrederich 9y ago
Maybe dropping compatibility with C is a good thing? All other languages wanting to interface with C seem to be using libffi or something. Currently C++ gets a shortcut, but in the future maybe it could go through an FFI. It'd still be compatible with C from libraries, just not source. Those libraries would have to ship header files free of macros of course.
- devwastaken 9y ago
  I think you're advocating for dropping compatability with a little under half of all c++ projects.
- nachexnachex 9y ago
  I don't see how losing backwards compatibility would be a good thing per se. Even if the preprocessor were considered a problem (which is disputed), it could coexist with a new FFI system that could be implemented. Losing backwards compatibility is usually a price to pay, not an objective. As an example, Python 3k chose to lose partial compatibility to 2.7 in order to change some parts of the language. While the user and maintainer community still debates if the change itself was a good decision (a different discussion IMO...), probably most will agree that the incompatibility bit has been and will be for some time a source of pain.

paulddraper 9y ago

True, and the worth remembering. If you did want to do this, you'd run a C processor on the C code first.

DSMan195276 9y ago

I would also add that when you're doing low-level work that requires mixing a bit of assembly and C (Or C++, but I mainly stick to C), being able to access the preprocessor from assembly is really nice. The alternative is redefining tons of stuff so you can use it in your assembly. It's a niche use-case obviously, but it is still a nice use-case regardless and I'd wager you could do this with lots of other languages if you ever had a want/need.

deleted 9y ago

[deleted]

pjmlp 9y ago

> by losing compatibility with the C preprocessor you'd lose compatibility with, well, C. Thankfully C++ no longer needs it to gain market share, it can stand on its own, while cleaning up the warts that caused unsafe code as a means of getting adopted.

qb45 9y ago
Ha ha ha, #ifdef __cplusplus extern "C" { #endif I guess you will have to rewrite libc.so and ntdll.dll in C++ first. Or at least fork them and maintain the fork indefinitely.
- pjmlp 9y ago
  They are already written in C++, pay attention to the news! https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great-c-runtime-crt-refactoring/ https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great... "We have converted most of the CRT sources to compile as C++, enabling us to replace many ugly C idioms with simpler and more advanced C++ constructs. The publicly callable functions are still declared as C functions, of course (extern "C" in C++), so they can still be called from C. But internally we now take full advantage of the C++ language and its many useful features." Note the reference to ugly C idioms. Also all major C compilers are written in C++, including clang and gcc, did you miss that as well?
  - hawski 9y ago
    Seeing "replace ugly C idioms" my first reaction was: "why didn't they use "nice C idioms instead?".
    - pjmlp 9y ago
      Because nice C idioms is an oxymoron.
  - mkup 9y ago
    CRT != ntdll.dll and CRT != kernel32.dll. CRT is an optional component of Windows software, a layer above ntdll and kernel32. Anyone can easily compile a program without C runtime library using /Zl compiler option. In this case, only Win32 and native API functions will be available, but not functions like printf() or strcmp(). So latest versions of CRT could be rewritten in C++, but this has nothing to do with documented OS API or even low-level undocumented native API, which are both still pure C.
    - pjmlp 9y ago
      The compiler switch /kernel was introduced with Visual Studio 2012 (Windows 8). https://msdn.microsoft.com/en-us/library/jj620896(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/jj620896(v=vs.110).... C code is considered legacy by Microsoft with C++ being the official systems programming language, hence why they dropped support for newer C versions, except for what is required by ANSI C++ standard. https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an... Our focus in Visual C++ is on making a world-class C++ compiler Our primary goal is to support "most of C99/C11 that is a subset of ISO C++98/C++11." We do not plan to support ISO C features that are not part of either C90 or ISO C++. Also the future of Windows lies on UWP, and C is certainly not a way of writing UWP APIs, unless one enjoys low level COM Windows 95 style. Finally, the remaining C code is slowly being migrated to C++ https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_coded_in_c_or_assembler/d4g9we9/ https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_code...

evacchi 9y ago

I don't think C++ will ever shrink as a language (i.e., drop features), but we can reduce the learning surface for newcomers by making it simpler, more consistent, and relegating C-isms under the "backwards compatibility"umbrella.

pjmlp 9y ago
C++11, C++14 and C++17 have dropped features, now there is even a zombie keywords section on the standard. Meaning of auto, export templates, exception specifications were the biggest ones, there a few minor ones as well.

ericfrederich 9y ago

Maybe dropping compatibility with C is a good thing? All other languages wanting to interface with C seem to be using libffi or something. Currently C++ gets a shortcut, but in the future maybe it could go through an FFI. It'd still be compatible with C from libraries, just not source. Those libraries would have to ship header files free of macros of course.

devwastaken 9y ago
I think you're advocating for dropping compatability with a little under half of all c++ projects.
nachexnachex 9y ago
I don't see how losing backwards compatibility would be a good thing per se. Even if the preprocessor were considered a problem (which is disputed), it could coexist with a new FFI system that could be implemented. Losing backwards compatibility is usually a price to pay, not an objective. As an example, Python 3k chose to lose partial compatibility to 2.7 in order to change some parts of the language. While the user and maintainer community still debates if the change itself was a good decision (a different discussion IMO...), probably most will agree that the incompatibility bit has been and will be for some time a source of pain.