C++ Logo

liaison

Advanced search

Re: [wg14/wg21 liaison] Designated initializers in C++ and C

From: Niall Douglas <s_sourceforge_at_[hidden]>
Date: Thu, 13 Aug 2020 15:02:24 +0100
On 13/08/2020 14:19, Bjarne Stroustrup via Liaison wrote:

> People talk about C's "separate identity" and (as above) C "has
> different use cases, and serves a different group of users" from C++. I
> have never seen C's separate identity clearly articulated, nor have I
> seen articulation of fundamental reasons for there being separate use
> cases. Such articulation might simplify the discussions about which
> incompatibilities are deliberate and essential and which are accidental.

With respect, I think you are looking at C all wrong. You're thinking in
terms of one programming language amongst many to be compared against
other programming languages as equals.

However no language is equal to C: C is the bedrock which anchors all
other programming languages. It defines the lingua franca for all
programming languages everywhere - if you want Python to talk to Rust,
it does so via C. It defines what CPUs are and do, and increasingly GPUs
as well. This is because it defines what memory is, how it is to be
addressed, how success and failure are to be communicated, what a basic
block is and how logic describes dispatch amongst those. If, for
example, C changes the definition of a pointer, that change affects
every C speaking and C implemented programming language everywhere. It
also affects all CPUs and GPUs to be designed. C is enormously,
terrifyingly, powerful and important.


I completely agree that this didn't used to be the case. For a decade or
two after C other programming languages could define their own rules, do
their own thing, define their own abstract machines. However, when CPU
designers started to design hardware around a C-like abstract machine,
the ground shifted: today's new programming languages start out a priori
assuming a C foundation, and then embrace or reject from there. LLVM is
utterly embedded into a C assuming abtract machine - every language
implemented using LLVM therefore is so as well. This has caused
originally non-C-orientated languages such as Erlang or Haskell to have
become ever more C-flavoured over time. Their adherents don't like this
at all, but if they want the LLVM shiny new toys, that's the price of
admission.

I hate to put this so bluntly, but "C has won" the contest of "what
ought all software assume about the hardware, and hardware about the
software". In this, it has been enormously and tremendously successful,
and much of C++'s initial and ongoing success is due to C source
compatibility.


So what then about the future? Me personally, I'd like C to become like
the POSIX of all other programming languages: standardisation of the
portable common aspects of all programming languages, CPUs, and GPUs.

To that end, those parts of C++ which are extremely useful to all other
programming languages ought to be merged from C++ into C. Same goes for
Rust, Erlang, Haskell, whatever.

And I don't think C should become a working group of WG21. If anything,
I think WG21 ought to become a working subgroup of WG14. That's how
important C is, and could become very much more so, if properly
resourced and placed in the correct exalted position it ought to be in,
for the global industry's benefit.

I appreciate that my opinion above will be shared by nobody else here.
And probably considered ridiculous by many. Still, I dream, and I would
urge WG14 to have the ambition to recast their future role into a more,
not less, ambitious standardisation proposition.

Niall

Received on 2020-08-13 09:05:51