Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

C and C++: A Case for Compatibility


August 2002/C and C++: A Case for Compatibility/Sidebar

Benefits of Incompatibility?


C and C++ are closely related, but distinct languages. What benefits are there from keeping them separate? The fundamental argument must be that each could be smaller, simpler, and truer to its own principles if released from the shackles of compatibility. However, despite the popularity of this idea in parts of the C and C++ communities, it is difficult to apply this argument to C and C++ for the following reasons:

  • History (and the need for backwards compatibility) gets in the way of any serious simplification of either language.
  • C++ was specifically designed to serve the same application domains as C, and in essentially the same ways.
  • The future evolution of C and C++ is constrained by the need for compatibility and the importance of the C/C++ community.

For C++ programmers, the benefits of incompatibility are largely hypothetical, beyond the simple advantage of not having to know the incompatible aspects of the C variant and not having to know about the C99 extensions. It is possible to imagine improvements in type safety, but compatibility with current C++ makes significant improvements in that direction difficult. The unchecked nature of arrays is not “just a C problem.” I suspect that the best people arguing for 100-percent type safety can hope for is a dialect (subset) that eliminates unsafe constructs. However, such a subset would not be C++; it would just be a subset of C++ used by the subset of the community that is in a position to benefit from it.

For C programmers, not having to learn C++ is an advantage (as far as ignorance of a closely related language can ever be an advantage). In an environment where all resources can be spent on C, compilers and other tools could be smaller and cheaper to build. In particular, a C compiler front end is inherently smaller and potentially faster than a C++ front end. However, that compile-time advantage is often offset by the need to run more compilations because fewer errors are caught by the compiler. Also, environments where ISO Standard C exists alone are few and not characteristic of C programming environments and communities.

Assuming C/C++ compatibility can be disregarded, designers such as tool builders and the C standards committee benefit from a simpler decision process. In theory, at least, this can translate into advantages for the C-only community. By ignoring C++, C could be extended or modified in a direction deliberately different from C++, eliminating the possibility of C/C++ compatibility and fracturing the C/C++ community. This could possibly benefit some C-only programmers but would impose a burden on the larger C/C++ community. Where C and C++ provide distinct language or library solutions to similar problems, that burden becomes significant.

In theory, at least, and sometimes in practice, the C community values stability more highly than the C++ community. Ignoring C++ for the further evolution of C could therefore be a benefit. However, with C++ standardized and many millions of lines of production code to protect, the attitude to backwards compatibility in the C++ community is approaching that of C. Only by essentially stopping the evolution of C would this benefit become significant.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.