5

As far as I understand it is a wide-spread opinion within the C++ community that certain features of C++ (including some features inherited directly from C), while still usable in themselves, do not fit well with the most recent C++ best practices. For example, I read a comment on this site stating that new / delete should be avoided altogether in favor of smart pointers.

In view of this, I often wonder why backward compatibility with C and earlier C++ features is still important: to my knowledge there is no 100% compatibility, but most of C and C++ are contained in C++11 as a subset.

So, maybe it would be possible / make sense to drop earlier C++ features (e.g. the mentioned new / delete) from a future C++ standard so that it is impossible to use them in new code.

Existing code could still be maintained using the appropriate compiler. Interoperability between legacy and new code would be supported through separate compilation. One could continue to use the earlier standard or adopt the more recent one, only mixing the two would not be possible: a developer /team would have to clearly choose which programming style they want to use. The most flexible solution would be to have compiler options to switch on and off certain features (e.g. no new / delete allowed).

Would this be a viable strategy for encouraging the adoption of modern C++ practices? Are there technical problems (e.g. compiling existing templates, ABI compatibility) that make such a change too difficult or even impossible?

Improve this question
25
  • 3
    @Giorgio: and not to forget: what you suggest has already been tried with some success - non-backwards compatible compilers exist, they are called compilers for Java, C#, D, Go etc. In all those cases language designers had removed obsolete and "bad practice" features from the language.
    – Doc Brown
    Apr 3, 2012 at 6:45
  • 1
    I do not understand the downvote: I would appreciate suggestions as to how I can improve my question. BTW: this is NOT a C++ against C question, shall I make it clear in the main text of the question?
    – Giorgio
    Apr 3, 2012 at 7:19
  • 1
    @jk, harald: To make it more precise, I do not want to state that C is obsolete in itself (and this is not the topic of this question) but maybe some of its features are obsolete as a subset of C++. But I am quite open about this too.
    – Giorgio
    Apr 3, 2012 at 7:21
  • 4
    I think people downvoting the question should reread it carefully. It is an interesting question about the relationship between c and c++. @Giorgio you should rework your question by making it shorter and clearer, and avoid puting C is an obsolete language as your first bullet point. It is the first thing people will read and they will stop there.
    – Simon Bergot
    Apr 3, 2012 at 8:15
  • 1
    "...wide-spread opinion within the C++ community that:" "C is an obsolete language ..." Is there in the world a developer who uses a lot of C++ who doesn't under why C++ is compatible with most of C? Bjorn explains why this is in his seminal book. " new and delete should be replaced by smart pointer primitives" What gave you that idea? New and delete are core operators in C++. Without them it wouldn't be C++. Smart pointers are handy wrappers around new and delete, they are not replacements for them. Perhaps you've been hanging around too many Java programers, ;)
    – Jim In Texas
    Apr 3, 2012 at 16:19

6 Answers 6

Reset to default
5

If I understand correctly your position (from the question and the comments under VJovic's answer), you'd have preferred instead of a mostly compatible C++11, a new language based (I'll call it NC++) on C++03 but source incompatible with it but linkable with it.

Here are some points to consider:

  • it isn't possible to implement C++11 using existing C++03 ABI (compilers providers don't guarantee that linking code compiled in C++03 mode and in C++11 will works), and it is a safe guess that it would be the same for NC++. So you'd have to have new C++03 compilers targeting the NC++ ABI as well as NC++ compiler to have your idea implemented.

  • you have the same problem with the standard library. You'd need a new implementation of the C++03 library able to be interoperable with your NC++ library.

  • the transition from C to C++ can be smooth as C is mostly a C++ subset. When the C code takes advantage of C99 features not present in C++, the transition is less smooth. Notably shared headers have to be coded in the common subset of C++ and C which isn't natural if you want to take advantage of C99. In your case, shared headers will have to be coded in the common subset of C++03 and NC++, which I fear will be impractical if your goal in NC++ is to take advantage of the possibility to break source code compatibility to have a "cleaner" language.

Improve this answer
4
  • "A new language based (I'll call it NC++) on C++03 but source incompatible with it but linkable with it" Yes, that's what I had in mind. My idea is that such a language would be more suitable for promoting the current C++ best practices. I was wondering whether it would be practically feasible.
    – Giorgio
    Apr 3, 2012 at 8:56
  • @Giorgio, I've pointed out some technical difficulties. There are others (for once, neither the implementation providers nor the standardization committee desire to impose their view of stylistic issues; they consider that the C++ community is wide and varied enough that doing so would get the opposition of a significant portion of it).
    – AProgrammer
    Apr 3, 2012 at 9:02
  • I understand. Dropping compatibility could split the community while the current solution tries to keep it together.
    – Giorgio
    Apr 3, 2012 at 9:12
  • @Giorgio - It doesn't "try" to keep it together it does. By making sure code written 20 years ago still works even if the C++11 compiler is used it means code the works simply does. Besides it takes a much longer time for the compilers to support everything the language specifications say it should support. There are many features that even TODAY that exst in C++ 03 and likely the revision before that still are not supported.
    – Ramhound
    Apr 3, 2012 at 16:07
6

Bjarne Stroustrup wanted to build a useful language based on C because it was

  1. Already popular within s/w community
  2. Supported low level programming as well as some high level features
  3. Lots of code was already written in C

There was no plans to have aggressive marketing budget to make C++ popular on its own as an individual language.
Instead of reinventing the wheel and introducing new syntax, Stroustrup chosen to build the new language on existing base itself (Like C was developed based on earlier language).

C++ is not fully backward compatible with C, wherever it's needed it has drawn a line. e.g.

  • unsafe implicit typecasting is not allowed C++
  • inline, enum and const were introduced with C++ and later adopted by C
Improve this answer
5

Are there conceptual reasons or technical problems (e.g. compiling existing templates) that make such a change undesirable or even impossible?

Some features are deprecated, and you get a warning (with appropriate error checking level), and if you enable option that turns warnings into errors, you get the desired effect.

Now imagine when lots of features would be removed, or changed drastically. That would make lots of programs not compiling. For large projects that is unacceptable. Who would go over 300kLOC-2MLOC code to fix all failures?

With backward compability, upgrading the compiler is much simpler. You still have to fix some code, but number of failures is acceptable.

To your edit :

How you compile/link your application, depends on the build system.

If you use makefiles, it is fairly simple (not so simple in complex systems), to add new rules to build separate libraries. c code would be compiled using gcc, c++ code using specific version of g++, and new c++11 code compiled (again) with possible different g++ version, into separate shared libraries. The final application would then link to those libraries. Off course, you have to make sure that all compilers are using the same ABI.

Improve this answer
17
  • 4
    Who would go over 300kLOC-2MLOC code to fix all failures? Not that it was fun, but I've done those types of changes.
    – justin
    Apr 3, 2012 at 7:01
  • One could imagine that some features are deprecated for a while (like 5 years) and then are dropped altogether. Anyway, I was suggesting that one uses an old compiler for legacy code and the new compiler for new code.
    – Giorgio
    Apr 3, 2012 at 7:10
  • 1
    @VJovic I'd go along with the changes… if I agreed with them. As an example - Bjarne wanted to remove C casts when C++ casts were introduced. That's a change I have made over a large codebase (happily, in retrospect). Unfortunately, I can't say I would agree with any/all changes. Superseding features certainly would be a pain to manage across multiple compilers/platforms.
    – justin
    Apr 3, 2012 at 7:33
  • 3
    @Giorgo, most production code live a LOT longer than 5 years. Most business cases do not warrant upgrading if the compiler is not backward compatible.
    – user1249
    Apr 3, 2012 at 8:26
  • 2
    @Giorgio - Why would somebody stop using code after only 5 years if it still works? Unless there is a reason to change it, it should remain the same, it sounds like you are part of this new breed of programmer who doesn't see the worth of proven leagcy code.
    – Ramhound
    Apr 3, 2012 at 16:12
4

You would effectively be talking about defining an entire new language- which is what's already happening with the numerous proposed C++ replacements over the years. I think that it's telling that none of them have actually succeeded in replacing C++.

Improve this answer
10
  • 1
    I was not thinking about developing a successor to C++ that should replace C++. Rather, I was thinking about keeping the current C++ semantics and syntax and removing features that are no longer considered good practices or do not add any extra functionality. E.g. removing the struct keyword, discouraging macros in favour of constants and const expr, and so on.
    – Giorgio
    Apr 3, 2012 at 13:18
  • @Giorgio - There being support for those features adds no additional overhead to your program once you compile it. What do you care if it takes longer to compile?
    – Ramhound
    Apr 3, 2012 at 16:13
  • @Giorgio: Removing all the redundant C features, and adding some of the new toys we could have if we didn't have to have them, would be equivalent to defining a new language.
    – DeadMG
    Apr 3, 2012 at 17:10
  • @Ramhound: My problem is that I work in a project with more than 40 developers. Some use C-like style, some 1990-C++ style, some use more modern C++ style, and some are moving to C++11. Our code is like a bazaar and having written coding guidelines does not seem to help.
    – Giorgio
    Apr 3, 2012 at 17:43
  • 1
    @Giorgio: The Standard will never, ever, drop backwards compatibility in significant ways. The only way to achieve this is to migrate to a new language. Your problem is irrelevant to this fact.
    – DeadMG
    Apr 3, 2012 at 20:34
1

Both of your premises are wrong. Smart pointers are a performance-hit, and C is far from obsolete: Windows and UNIX system calls are defined in terms of C. In fact, just about every OS in wide use today, except Symbian, uses C interfaces. So if you want to have a language that supports system-level programming, you can't get away from new, delete, raw pointers and all of the things that you dogmatically believe are bad.

Improve this answer
7
  • 1
    Can you read the first line of my question carefully, please? And the comments below the question?
    – Giorgio
    Apr 3, 2012 at 8:17
  • 3
    Smart pointers are not a performance hit when used appropriately at all. And C is obsolete- for a start, the fact that people use C interfaces but nobody actually calls them from C doesn't make C not obsolete, and secondly, they're binary interfaces defined by the OS. They're simply natively expressed from C, but you hardly have to be using C to use them, so what makes them "C" interfaces escapes me.
    – DeadMG
    Apr 3, 2012 at 8:25
  • @DeadMG: Nobody?
    – Blrfl
    Apr 3, 2012 at 9:59
  • 1
    @DeadMG PostgreSQL, Linux/*BSD kernels, ghostscript, and a bunch of other software being actively developed in C. Obsolete? Right. And "appropriately" is exactly the problem with smart pointers. Memory management is not a problem either, if raw pointers are used appropriately. Point being?
    – zvrba
    Apr 3, 2012 at 15:42
  • @zvrba - Don't worry...I entirely agree with you.
    – Ramhound
    Apr 3, 2012 at 16:14
0

I think Bjarne's view as of late has been that C and C++ should have been unified as a single language. I think that this could imply that his view is that C++ should be a replacement for C, and as such compatibility with C is important in such view.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.