Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

EDIT

Following the suggestions contained in comments and answers I have shortened and partially reformulated the question. This is NOT a C versus C++ question. It is a question regarding C++ best practices and how they can be promoted.

EDIT 2 The number of down-votes suggests to me that the point of the question has not be understood by some. I have changed the formulation to stress the important point even more.

share|improve this question

closed as not constructive by Joris Timmermans, gnat, Walter, Yannis Rizos Apr 3 '12 at 18:09

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
@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 '12 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 '12 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 '12 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 Apr 3 '12 at 8:15
1  
@Giorgio: you would not write things like this if you had to keep a >=100K LOC application alive over several years. I have to, and I am really glad that C++ is as backwards compatible as it is. Using an "old compiler" for old code and a "new one" for new code would lead to so many impractical issues that we evenly could dump our product. –  Doc Brown Apr 3 '12 at 18:06

6 Answers 6

up vote 4 down vote accepted

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.

share|improve this answer
    
"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 '12 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 '12 at 9:02
    
I understand. Dropping compatibility could split the community while the current solution tries to keep it together. –  Giorgio Apr 3 '12 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 '12 at 16:07

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.

share|improve this answer

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
share|improve this answer

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.

share|improve this answer
3  
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 '12 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 '12 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 '12 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 '12 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 '12 at 16:12

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.

share|improve this answer
1  
Can you read the first line of my question carefully, please? And the comments below the question? –  Giorgio Apr 3 '12 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 '12 at 8:25
    
@DeadMG: Nobody? –  Blrfl Apr 3 '12 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 '12 at 15:42
    
@zvrba - Don't worry...I entirely agree with you. –  Ramhound Apr 3 '12 at 16:14

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++.

share|improve this answer
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 '12 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 '12 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 '12 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 '12 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 '12 at 20:34

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