I was thinking about what I was
going to talk about at this
conference as a key note speaker.
And I looked at the program,
and decided that there
was an awful lot of nice,
good, detail stuff.
Language things, library stuff and
such, so I shouldn't do that.
So, I am trying to talk about
something more general,
bigger ideas, and so
I'm talking about the evolution.
And I'm trying to look back and
see why on earth does this happen?
I mean C++ has been declared dead
at least ten times every year,
for the last about 35, right?
So, let's look at it and
why it didn't die in the crib,
or after that.
And then, I'm going to look a little
bit about standardization and
see what are the opportunities and
the dangers now.
And then, I'm going to try and
answer the question,
where are we going?
Where should we be going?
How can we sustain what we have been
doing so far and make it better?
And then,
this gets too philosophical, right?
Then I have some concrete stuff
about what we can do today, and
that's how I'm going to end.
But first we start with philosophy.
There's a couple of philosophers,
and there's a tension between ideas,
and principles, and practicalities.
And this has been going on for
at least 2,500 years and
it hasn't stopped yet.
But this is one of the tensions
that we're going to talk about.
And I am not going to give you long
lists of features, other people will
be doing this, you don't have to, if
that's what you want you'll get it.
And I can't give you really cool
stuff, go to the people at ship
libraries and such, and talk to
some of the compile inventors.
Cool stuff is shipping, it's
just not what I'm talking about.
And then, again, going back,
why did C++ succeed?
What can we do?
And I've heard many theories,
my least favorite is being lucky.
How do you stay lucky for 35 years?
It takes hard work.
And furthermore, yeah,
one thing to point out,
when I talk about C++,
I'm taking a very C++ centric view.
I could give a totally different
talk about the industry, and
where C++ fit, and
all of that kind of stuff.
That's not what I'm doing,
I'm very C++ centric.
If you want to criticize me for
it, fine, but
remember I know that too, and
this is just lack of time.
Okay, so let's look at philosophers.
Here's a good,
dream no little dreams.
In other words,
what are we really trying to do?
What's a big picture?
What is the thing that sustains us,
sustains C++ over decades,
as opposed to days,
weeks, months, years?
Basically, my aim, and
I hope many other aims are,
simply to do things much better.
And to do things much better
in software development you
have to think differently, you have
to construct your code differently.
Just doing what we've always done,
but
slightly better,
it's not going to get us there.
It's going to get us the next
project shipped, it's going to get
us to the next year, but it's not
going to sustain the language and
the community for decades.
So, I would like type and resource
safe, without any adjectives or
other worries.
I want the code, I have to read,
to be simpler and
clearer, easier to understand.
This is important,
I mean that's what you spent
most of our time doing it.
You should be looking at
code that isn't finished or
has bugs in it, and clarity,
simplicity is really,
really valid and the language
in the libraries can help there.
That's what we want to do.
And of course this C++ has to be as
fast as faster, than anything else.
If you want slow code,
you can get it,
there's benefits sometimes
to have slow code.
You can have tools that allow
you to write it sooner and such.
But anyway, as fast and
simpler than anything else, and
it has to be good
at modern hardware.
One of the strengths of C++,
as I'll repeat a few times here,
is it actually has mapped
really nicely to hardware.
Hardware is getting weirder.
There are more pipelines,
there's more forms of concurrency,
there's more strangeness inside
the compilers and optimizers.
C++ is supposed to be
good at that stuff,
let's keep it being
good at that stuff.
And then, compile times, nobody
really like long compile times,
let's get much faster about this.
And remember, in these things
I'm not talking percent.
If you give me 10%
I'll be very unhappy,
if you give me ten times,
I'll get happy.
But that's not easy,
here we have an expert on
difficulties, Niccolò Machiavelli,
the famous historian of the Roman
Republic, patriot, and politician.
There's nothing more
difficult to carry out, nor
more doubtful of success,
no more dangerous to handle,
than to initiate a new
order of things.
In other words, don't rock the boat,
it's dangerous for you.
Don't try and make things that
are really new, don't try and
make things that
are significantly different.
And if you look at this,
and of course that
is what I'm trying to do, it's also
what Machiavelli was trying to do.
He wrote a book trying to
convince people to do it, and
people convinced that he was wrong
because he explains things the way
they were, as opposed to the things
that people pretended they were.
I quoted that in the third edition,
and here's a continuation,
the problem is it's dangerous
because you make enemies of
everybody who loves status quo.
And people who would like
something new tend to be lukewarm,
because it isn't there yet.
They can't use it on
their next project,
they can't use it next year, and
so there's an imbalance here.
And so, my conclusion is,
developers love minor changes
that helps with current problems.
And they don't really,
people had a vested interest in
the status quo stronger, okay.
Then also remember,
the best is the enemy of the good.
We can't just sit around and
wait for perfection.
No, that doesn't get us to
perfection, for starters,
we don't learn anything.
There's no feedback loops
in trying to perfect,
you have to move further.
So, we're going to talk a little bit
about what concrete practical steps
we can take now,
that's the last quarter of the talk.
And then, of course,
we can't do it alone, and
I'll point out that a lot
of people have helped.
There's just a few names there,
if I had put everybody who needed
thanks on this slide, I would
have to use an 8 point font, and
you couldn't have
seen a single name.
There's always these tradeoffs.
Okay, let's look at C++,
here's a graph,
some of the numbers are real,
but it's hard to get numbers.
In particular, the bottom and
the top and
some of the flex points are real.
What I had to do is some
interpellation, especially around
the 2002 plus minus column,
the rest is pretty good.
So let's see, I mean,
we had a commercial released in 85.
That's a long time ago,
why did we have exponential growth?
I measured it as doubling
every 7.5 months for
11 years, and then I couldn't
count that high anymore.
Numbers got too big,
my sources were not good enough, and
then obviously,
there was a slowdown.
And we've got a really
serious slowdown just
after 2000, and then it resumed.
I mean, we have pretty good
numbers for the last three, four,
five years, and there's no
doubt we're on an upward curve.
So, if I can explain this slide,
I can actually
get some guidance about what
we should do to sustain it.
What people would like,
what would actually help people, so
let's go back to the roots.
Where does C++ come from?
Some of you may have seen this
slide, the past doesn't change
very often, and so there are two
sources of C++'s strength.
The bottomline there starts with,
try and
squeeze every cycle,
every bite out of the hardware.
It starts with assembler,
David Wheeler there
is one of first people who
claimed to have built a compiler.
He certainly wrote the very first
program on a slow program computer.
And he was my thesis advisor, so
he gave me a lot of information.
BCPL, C we know about that, and.
The problem is,
that most of the time we're not
actually manipulating hardware.
Some of us are, and C and C++ is
good at it, should be good at it,
it's designed to be.
But there's another line of
thought here which is abstraction.
Back us there, and
his team invented Fortran, which was
the most significant improvement in
programming sofa,
they lifted the language from
the hardware up to something that
was more suitable for humans.
Very particular kinds of humans,
engineers and scientists, but
they had a language that then could
be mapped to different computers,
and you can get portability and
all kinds of good things.
They didn't mean to, they just meant
to give a language that would be
good for scientists and engineers.
But once scientists and
engineers have got it,
everybody wanted one too.
So, you've got 200 more
languages that specialize for
different things, Cobol for
business people and such.
And now, he had a filthy mess.
200 languages, and
they couldn't talk together.
You want to gather some data?
You put it on a record.
Cobol's really good at that.
Then you want to run some
statistical analysis on it?
Fortran is really good at that.
Fortran doesn't speak to Cobol.
And there's many particular
solutions to that kind of problems.
But the general solution
came with and Simula.
Object oriented programming.
Basically, instead of giving people
an abstraction that's suitable for
a particular kind of user,
you have a generalization, so
that you can build your own types.
Your own class hierarchies,
if you have related types.
And that's a brilliant idea.
And so, when I had a problem at Bell
Labs, I said, why can't I have both?
I want to use every ounce
of the hardware, but
I want to abstract away from it when
I don't have to be bothered with it.
And that's the true root of C++, and
the first feature coming into it
was classes, with constructors and
destructors, and things like that.
And a lot of things come from there.
So, there are the two
intellectual roots of C++,
which I suggest it's
a good idea to stick to.
So, C++ in two lines.
Not 1300 or 1400 pages, but
if you really want to get the basic
of it, that's where it is.
Direct map to hardware came
originally from C, and for future,
we need facilities for dealing with
the hardware that's now coming out.
We can't just program
against a 1990s computers,
which is what we do when you
misuse a current computer, and
we need zero-overhead abstraction.
We need to abstract, but
I don't want to pay for it.
Simula showed us
the value of abstraction.
Where I came in is I
wanted it at no cost.
And that's where you get,
you get this from classes, you get
an inheritance, you get a generic
programming with templates and such,
and for the future, I want type and
resource safety with concepts,
modules, and
better concurrency support.
So, that's C++ in two lines, and
let's get a little bit concrete.
You have to choose your level of
distraction when you deal with C++.
Here's a very trivial
symbol example.
I want to read some
strings into a lecture.
I can do it on the top,
I can do it at the bottom.
There wasn't room for
the all flow checks, so sorry.
I'm having two slides on,
two examples on one slide.
To give an example,
I would prefer the top, and
I'll prefer the top to run at
least as fast as the bottom.
For many, many application areas,
that is possible.
So, you can start with what you can
do, and then you can improve it.
And the aim should be that
the higher level, the clearer,
the type safe thing where you
don't have to worry too much
about the overflow and
things like that.
The distinction is fluid,
you have a choice, but
I would like to push people
toward a more elegant solution.
You also have to ask what matters.
A lot of the things we talk about
don't actually matter
in the big picture.
For software development,
first of all, that's what matters,
not who can have the cutest
little example in an article.
What actually matters for
actually building things?
Stability, important.
There's a lot of 20 year
old code out there, and
evolution, there's a lot of new
problems coming on, we must do that.
We have tool chains,
we have teaching and learning.
There's lots of people, I get mail
every week from people asking
questions that relates
only to Turbo C++ 4.0.
This is sad.
We have to improve teaching and
learning.
I always mention that, and
it's really hard, there's so
much inertia out there.
There has to be
a technical community,
none of us write
a program in isolation.
We depend on the advice of others,
the support of others,
the tools from others,
the ideas from others.
We have to build that community,
this conferences is part of that.
I want concise expression of ideas.
I actually want to be able to
read your code and vice versa.
If it's a mess of bits and
bytes, often I can't.
Coherent language,
complete language,
compact data structures that
are out of date, lots of libraries.
These are the things that
are important, as opposed to
language technique, or little
details that also has to be right,
but they have to support this.
And one of the important
thing to make note is that
there at the bottom,
a language must be good enough for
everything you're
doing in your project.
If it totally fails at one thing,
it totally fails.
So, being the world's best at one or
two things is not sufficient.
You have to be really good at some
things, preferably lots of things,
but you mustn't
totally fail anywhere.
So, that's good.
And it's really hard to do
because you don't know what's
important to people.
There's far too many people to know
what they want and what they need.
I mean, we got 4.4,
4.5 million C++ programmers I mean,
even if I was a mind reader,
I couldn't read that many minds.
So, this is difficult.
But don't get obsessed with details.
There are times to be obsessed with
details when you finish one little
corner of a project.
But sometimes,
you have to look at the picture.
So, a language needs good
fundamental features.
That's important.
And a good language is not
just a set of good features.
You have to have them fit together,
and all framework has to be
comprehensible and effective.
You have to be able to use language
features in a combination.
You have to be able to
have real compilers,
generate good code from them,
and things like that.
And 90% of the work
of getting something new into
a language is integration.
People always come, they sent
this email, put this into C++,
it's cool.
Even if it is cool, even if I agree.
Well, the first 10% is
to write the proposal.
And the next 90% is to figure
out where it was wrong, and
why it didn't fit in, and
get everything to work together.
But the discussions tend to
be an individual feature,
especially until they
can't be tried out
until they can be seen in context
of the standard, or of a tutorial.
We need to spend more time
looking at individual problems,
individual features in the context
in which they are used.
I mean, this kind of design issues.
So, let's look.
I tried to articulate rules
of thumb, I've done that
several times,
in the design evolution of C++.
But here's a list I found from 2003.
Stability and compatibility,
yep, you want new features, but
you don't want me
to break your code.
Libraries are good,
because we can deploy them today,
rather than waiting until all of
your compilers have been updated.
There are many project for
which you can't get away from,
say Gcc4.3, and it doesn't matter
what the standout committee does to
improve the language, if you still
have to use a ten year old compiler.
So, we really have to help people
getting off those compilers.
But we have to make sure
what libraries is one of
the things that helps us.
Generality, the point
is we have hardware.
We have extraction.
We need over generalities,
rather than language features to
solve these particular problems.
And support those experts and
novices.
I've been going on like this for
a long time.
I gave a keynote here called
make simple things simple.
And experts tend to want
really important, clever,
highly performing,
sometimes specialize things.
Think about the poor novices,
think about yourself,
who's a novice, doing
the other 90% of what you're doing
when you can't do your speciality.
Great libraries help,
they increase type safety,
improve performance, and ability
to work directly with hardware.
Fit into the real world.
[BLANK AUDIO] Academic
papers are nice, but
you really want to help
people building real systems.
And again there,
change the way people think.
That is where the order of
magnitude improvements are lurking.
Okay, and
this has been going on forever.
Let's see, simple things simple.
In the dark ages we
wrote a loop like that.
Declare a variable, then give
a start condition, a maximum and
then increment.
That's fine, except sometimes
you misuse the loop variable.
So found a way.
Just take a loop variable
into the loop things, so
we can see where it is,
if you don't need the value
afterwards, of course.
And in 2011 made
another improvement.
Why actually mention
the loop variable?
I just want to go through that
contain on arrays or something, for
when I want to do that,
which is 90% of the time, we can
just write the range for loop.
So basically the assumption here is,
the 2011 thing does
90% of the cases,
the 83 thing does 90% of
the rest of the cases, and
then you are back to being able
to do absolutely everything,
including all the bugs
you don't like.
So hence, the last line there, which
shows that if you can do anything,
you probably will.
Those are real bugs
found in real programs.
So when we go on about
the language and
think about what to do,
how to improve it,
there's a lot of design
decisions that should be made.
They're only a few of the design
decisions that are really key,
I tried to list them, there's
still a lot of them there, but
you start from the beginning,
you add things on it,
based on experience and all of that.
Let's see,
the key things here is what
kind of programming is being
enabled by language features?
A language feature in
isolation is boring,
could be seen as intellectually
interesting, but
I think it's fundamentally boring
and it's fundamentally useless.
If you only had a loop.
So we started in the beginning.
The ropes of C++ is in the building
of the user defined data types.
Constructors, destructors,
the weight structures and
classes are the same.
I decided on C compatibility for
good and bad.
We've got macros there, that
includes trying to get rid of them
ever since, but
it was a decent start.
It allowed me to support
a user after six months.
It's not a ten year project.
The language is a mighty
10 year project, but
getting useful result is not.
About 84, 85,
we could support object oriented
programming as well as anybody else.
And sort of modern C++ is about 88,
89 when start of standardization.
With the exceptions and
templates, we can do RAII,
we can do a bit of
generic programming.
And we had to figure out what
generic programming really was.
The STL helped.
Metaprogramming comes along later,
it's still too complicated,
but we'll deal with that.
And now, what are we doing?
I'm hoping to see the type and
resource safety soon.
That is, a new collection
of language features,
that in combination deliver
this kind of type and
resource safety,
without loss of performance.
I have not forgotten this hardware,
and
we are getting better support for
functional programming.
We'll see, I put it out at
beyond 2020 or thereabouts.
Notice that the main decisions
comes sort of, in clusters.
There's one in the early 80's.
And, things are happening
up till 88.
And, then it takes
some time to learn.
Things gelled in 11 again, around
generic programming, and such.
And, we're not there yet,
for other things.
So basically,
one of the things I look at here,
see, major changes comes in bursts.
You need significant features,
and then you need polishing,
integration and then you can
go from an idea to actually
a deployed new way of writing code,
a better way of writing code.
And they come in bursts and
it takes time to get there and
then it happens.
And most changes aren't major,
I mean minor changes
can support status quo, but you're
still writing code the same old way.
Minor changes can be useful ,they
can be very comforting, and
some minor changes are of course,
necessary to support the major ones.
But if you want to get
to the next level,
if you want to get
to the next stage,
if you want to make significant
improvements, not 10%, not 40%.
We can argue about two times and
three times but usually I think,
let's get some factors in there.
10 is a very nice factor and
I'll take two.
But if we want to do that, then we
have, then we need major changes.
And we need major changes because
we're not in the middle ages.
Things are changing all the time.
Our problems change, we change, and
so the language has to keep up.
And major change is unsettling,
that is well-known.
If somebody comes with a radical new
feature, a radical new way of doing
things, even if it can
co-exist with existing code,
which it always can in C++,
it is still unsettling.
You have to learn new things.
You just thought you
knew everything.
You may very well have known
everything about the world as it was
five years ago.
It's not good enough, so
we need to make changes and
we have to make decisions.
There are close to infinite number
of directions you could go in.
We can't go in all of them.
We can't focus the language if
we don't make decisions about
going roughly that way as
opposed to go roughly that way.
And, that's hard to do.
So, here is another view of this.
I think early C++
finished about 88 or 89.
And those are commercial release.
And it took people maybe
a decade more to actually figure
out how to use this, to deploy this,
to support this, to get libraries,
compilers, analysis tools,
the works.
And after that there was a slowing,
there was a feature drought.
We didn't get anything significantly
new during this period of time.
A lot of work stabilized.
STL sort of saved us
from really fossilizing.
There was a lot of work to be done,
and
the alternative to
C++ was improving.
I think we actually
didn't do enough,
C++ doesn't have a sugar daddy
that can give us marketing and
the research dollars and
development dollars.
The standard's committee was
working hard on stabilizing things,
so we were losing traction and
C++ is dead was very
popular in the press.
But then it always is,
but it worked.
So I was thinking now, why didn't
this send us into a death spiral?
Because you can see,
I'm complaining,
but the numbers are going up.
I mean,they're still going up by
hundreds of thousands in this area.
And I'm complaining?
Most people wouldn't complain
if they only got another hundred
thousand users.
Anyway, I think there
was a drop later, but
the thing that saved us was
the CPUs stopped getting faster.
You couldn't just
ignore performance.
You couldn't really
ignore the CRO head and
the CRO head abstraction anymore.
You couldn't ignore the weirdness
of the hardware anymore.
And that is what I think helped C++.
And then 11 came along, C++ 11,
which supported features that have
been developed and integrated and
understood in the previous decade,
and we are on an upturn again.
And so I would really love to know
what's happening to that curve.
Are we going into
another stabling out,
leveling out, and downtrend, or are
we going to carry on for a while?
I hope we are going to
go carry on for a while,
but we have to get
some things right.
We're not going to maintain
that curve by doing nothing.
We're not going to maintain that
curve by doing nothing, we're not
going to maintain that curve by
doing only tiny things, okay.
So, an apology.
We need great libraries!
The standard is now more than
50% of the standard library.
I can't talk about it, just like I
can't talk about the industry in
general, because I don't have time.
I can't talk about libraries.
So, apologies, go and see the talks
about libraries at this conference,
right?
Okay, great libraries.
So, that's it.
So go back.
Let's see,
what can we do that is significant?
And how can we avoid it becoming
an intellectual exercise that
never ends?
That's back to the philosophers,
whoops.
So when you ask people
what's a good extension,
if you talk to people about
extensions, what is useful,
what is needed, what should be done,
you get two very distinct answers.
Here is the semi-caricatured
developer's point of view.
I really want something that
helps me with my next project or
my current project.
I want a very specific problem
solved because this is
what's bothering me, this is what
I'm spending all my time on.
And really, I don't have
time to go and read a book.
I don't have time to read
an article, I'm busy, busy, busy.
Don't tell me anything I
don't already understand,
just give me a better tool for
doing it.
And make it isolated, so
I don't have to rethink and
recheck everything else.
And don't break anything,
mustn't break anything, this is bad.
And it should be in my
compiler tomorrow, thank you.
That, I hear that often.
And there's a picture of sort
of a typical developer that's so
busy looking at his current problem
that he can't see the forest for
the trees.
This kind of input,
this kind of experience,
it's genuine experience.
We've all have been there, right?
It's real, but it's misleading.
Very often, people who go on about
that lax experience with long term
planning, or at least, they've never
seen the results of their planning.
Aims can very often
be set by others.
That is, people are trying to
finish this project that they have
no say in.
And they're spending 90% of things
that probably nobody should spend
time on, because some bozo
didn't define the problem right.
And you're gonna have very short
term evaluation of consequences.
That is,
did the product ship on time or not?
That's the proof of the pudding.
From the view of
a programming language and
the development of programming
styles, that is not a good criteria.
Deliver on time, focus on
the details, and don't screw up.
Very important not to screw up.
If you have a mortgage,
don't screw up.
Okay, but this is not the way
we can design a language.
There's the other extreme here,
there's the typical designer,
spouting theoretical something or
other.
And basically,
we need to help the user community
over the next decade as such.
And we have to address
fundamental problems because
that's where the fundamental
improvements are.
Change the way people think.
I keep going on about that
because it's important.
Make the language more regular,
therefore easier to use.
Be theoretical sound,
theory is a lousy guide for
what to do, but it's an excellent
guide for how to do it.
Once you have decided what you do,
you have to be sound.
And improve the reputation
of the language.
It's not enough that you can
do things in a corner, and
nobody hears about it.
Again, the theory and the literature
can be very misleading.
Just as misleading as
the environment of the developer
can be the environment
of the designer.
There's a lot of focus on novelty,
if it isn't new,
it can't be published.
Who said that what can help
us most has to be new?
Most things were invented a long
time ago, and we have to revise
them, we have to engineer them to be
useful, that's not often seen there.
There's a real focus
on being clever.
You have to solve
complicated problems.
If you have a simple problem and you
solve it, you don't get much credit,
even if that simple problem is
something that is the right royal
pain in the neck to
a few million people.
And focus on the amount of features,
again, has to be clever.
And quite often, if you look at the
literature, and you look at theory,
I think it basically
disdains every programmers.
We should do things this
complete new way, and
just rewrite all your own code, and
if the programmers are more than 32,
they should be fired anyway, because
they don't understand anything.
There's some kind of attitude there.
Obviously, my conclusion
is that we need both,
we need to somehow combine
the everyday developer experience
with a design perspective
that spans years and decades.
And that's a lot of ands there.
And you have to keep a lot of them
in your heads at the same time.
You have to balance, and
this is seriously hard.
The C++ community is enormous.
It's so easy to be parochial.
All of my friends do things
this way, it must be good.
All of my friends have this problem,
it must be solved.
All of my friends like this
solution, we must choose it.
Okay, how many friends we got,
1,000?
That's not 1%.
It's about a percent of a percent.
How many of us talk to 1,000 people
regularly about serious things?
It's really easy to be parochial,
to see only
what's going on just around you,
or read the same magazine.
And get the same kind of stuff
that some journalist thought was
important.
And we have to work within
the current C++ implementation and
infrastructure because we
have to consider transition.
And then of course again,
we have to get it right, but
then we have to be able
to teach it right, so
that people don't
write 1984 style C++.
Some of us have been there and
done that,
some of us do not want to go back,
we can do better now.
Okay, more examples, I distinguish
between major features and
minor features.
Major features are ones that have
potential for major improvements,
and minor ones are comforting and
can help a little bit.
So basically, a major is change
the way we think about code.
And you can have combinations
that are really,
really powerful and interesting.
I'm not saying you don't
need any minor features,
that would be ridiculous.
But the driver should
be the major features.
So, we have little separators,
digit separators in C++ 11,
it's very nice.
Okay, we've also got auto.
It's sort of borderline major minor.
If you just use it to
initialize a variable and so
they don't have to say double for
that x, it's minor.
If you use it to eliminate OR
typing in generic code,
it's getting close to significant
about how you write code.
And if you get concepts,
you can actually make a major,
major difference.
People always underestimate concepts
when they haven't tried them.
And so there's this range of things.
And one of the problems is that
people will spend as much time on
the little separators as they will
spend on thinking about concepts.
As a matter of fact, they might
think more about it because it's so
much easier to think about
how do you separate digits.
Do you use an underscore or
a dash, should we use white space?
So easy,
everybody can have an opinion.
Everybody can have
an opinion on concepts, too.
But it actually takes time
to have an educated opinion.
So it's hard to discuss that.
There's isolated versus
pervasive impact.
We're getting in C++ 17,
inline keyword for variables, and
this is very nice, from a language
technical point of view feature.
No new keywords,
new grammar impacts, no type system
impacts, no impact, and no code.
And best of all,
it makes it trivial for
you trying to reduce global
variables in headers.
Some people think that's
a good thing, I don't.
The last thing I need
is a new way for
you to sneak global variables
into my concurrent code.
But you are going to get it.
And I've read articles that it's
really good for you, so be my guest.
Another feature that I was trying to
get into C++ is connects to genetic
programming and such is I want to
be able to call a function with
a functional syntax or the member
syntax, no impact on old code.
And it eliminates the need for
duplicate functions, have you seen
begin and end or x.begin,
which one do you want to use, why?
Forwarding functions, there is
a lot of forwarding functions and
binders and such, be eliminated.
Here's forwarding
function that I found and
shrunk to something
that fitted on a slide.
Basically, it calls foo bar
with a functional syntax.
I should have used the other
syntax in there, foo.bar.
But basically, it can simplify
the way you write code and
the way you design libraries.
This one went down in flames
Because it was too different,
new, and therefore dangerous.
You might get the wrong function
as if you couldn't get the wrong
function today.
Okay, let's see,
one thing we have to remember is
every extension does some harm.
There's people that think that
you can just get new things and
then everything will be happy.
No, you need implementation,
tool, and learning.
That takes time, effort, resources.
It outdates learning material, and
learning material and compilers
in libraries tend to last longer
than you'd think, like decades.
Remember that Turbo C++
compiler I get questions about?
That was 20 years ago.
It's still bothering people today.
And you can have a poor
benefit cost ratio.
That is, you can have
a feature that helps me.
It helps all of my friends.
I can demonstrate it
helps 100,000 people.
How can you say it's not good?
Let's see,
100,000 divided by 4.5 million.
This could be that you are imposing
a burden on the other 90% or
more of the users,
that doesn't give them any benefit.
And it may delay new features that
are necessary for other people.
It can distract from good
implementation of new features.
It can distract from
the optimization of existing code,
of porting to other machines,
things like that.
There's no free lunch here.
And you may actually get
features that makes it harder to
move in a direction you'd
like to move to in a future.
Like I want better concurrency, and
if you want global variables,
they get in the way of each other.
Okay, now we also have to
remember that if we want
absolutely 100% portability or
compatibility,
back to the dark ages,
we have some problems.
Sometimes, we have to break it,
if so, break it loudly.
This is static_assert, good stuff.
If you feed that into an old
compiler it'll tell you it's not
compiling that dialect of C++.
Well, use an up to date compiler.
Fix the old compiler or
use a compatibility switch.
There will always be a backward
compatibility switch
in the compiler.
You don't like them, you shouldn't
like them, but it's a solution.
There's a little change there in the
meaning of auto coming up in C++ 17,
unless the committee
changes it mind.
This will break some very rare
code that think that y is
an initializer list,
instead of an integer.
Most of that code,
it could be a silent change, but
how will you use that y
without getting an error.
If you think it's
an initializer list, and
the compiler thinks it's an integer.
Yeah, there's code,
you can construct it.
I don't think there's
very much of it.
So basically, we have to break
code sometimes to get modern
code looking better, working better.
Try to break it loudly, and
if not hope it breaks often.
Okay, I think we need a direction.
That's a major point here.
We can't just go in all directions.
We need principles, consistency,
coherence, completeness,
interoperability, zero overhead,
good.
It's hard to do,
harder than it sounds.
And we need a process to help
us follow those principles.
It's really hard with lots
of individual decisions.
A standards committee for
a new standard has to make thousands
of individual decisions, and
they can't sit around looking
at philosophy all the time.
But it would be nice if
there was some guidance, and
you need concrete examples.
People are amazingly good
at misunderstanding text,
especially on general principals and
such, so we need something.
So, creating and maintaining
a direction is quite difficult.
Most people want a smaller
language with more features.
This is hard.
It is actually possible to get the
effect through generalization, so
that there's fewer
rules you have to know.
Because things work more in general,
but it's hard.
People want stability,
100% compatibility and
with significant improvements.
Except for the people that just want
to break the whole thing and go and
do a revolution.
For those, go and
do your revolution elsewhere.
This is an old language.
It's going to be a much older
language in the next 40 years.
And it's going to be quite good,
and we can't break the code.
It's our code.
It was written by our colleagues and
our friends, and it's still be
written by our colleagues and
friends for the next decade or two.
Whoa, this is good trick.
And so we want stability and
some directions
are mutually incompatible.
We can't both go that way and
that way, and keep things small.
We have to make sure these
things combine somehow.
And the standards
committee has no money,
no resources beyond the volunteers
that do all the work, and
have to pay for
the privilege of doing all the work.
And the more features we add
the harder it is to integrate,
so the amount of work increases.
And then of course there are people
who disagree on fundamental
philosophies.
Do you want implicit
things in language?
Do you want a very explicit
syntax for everything?
Do you want it simple so
that you may only handle
90% of the cases like
the range-for loop?
Or do you want everything to
be fully comprehensive like
the original C for loop?
Then there's aesthetics, people
disagree about what looks good.
And then there's always a discussion
about should we do things in
the library or in the language.
And I think C++ is a victim
of its own success.
Everybody wants to help.
The standards committee is
bigger than it ever way,
more active than ever was, and
I think the individual technical
expertise of people in the committee
is higher than it ever was.
But it's really hard to be coherent.
A lot of people come with totally
different background, and
doesn't appreciate that other
people have different backgrounds,
different concerns.
And a lot people have
not internalized
the C++ process,
where the language is going and why.
And then of course there's
people who's been there for
a long time, spend all the time
trying to rehash what we should
have done ten years ago.
Well that was ten years ago.
We can't do much about it today.
And so we have a long series of
separate decisions quite often
done by people who hasn't been in
the room with the other decisions.
And it's hard to be coherent.
And sometimes people come in
the last minute and says,
we can't do this, this is horrible.
And says, we've discussed it for
three years.
Well I wasn't there,
why didn't you tell me?
Well, we did tell you, but
it drowned in the details,
the mass of information.
There's more than 100 papers coming
for every standards meeting.
Not everybody can eat,
read all of those and understand it,
and contribute.
This is hard, and but now it's not
really designed by a committee,
it's designed by committees.
There are subcommittees.
There's people that
never actually spent
time discussing
the features together.
This is very difficult.
Anyway, we should
thank the committee.
It's done a good job over the years.
There is a very tired
committee down at the bottom,
just after voting out C++14.
I think they might be voting
up the top slide there.
And the final thing is where people
do a lot of the real work which is
in the working groups, and
notice all the computers there.
Everybody is sitting there
doing their various things
in communicating with their friends
in other countries and such.
If you go into a room in
the standards committee,
you see 15 people sitting
around the table.
There's probably 30 people in
the room, because they communicate.
Okay, one of the examples here,
why should complex
be in the library and
and not in the language?
Why should a range-for be mostly in
the language and not in the library?
There's a whole set of decisions
there that actually are not that
hard to do.
Sorry, not that easy to do.
This is a discussion that you can
have for every single feature.
C++ is powerful enough that most
things can be done in a library and
especially if you put
in a few intrinsics.
When you do that, you can sometimes
deploy it early, which is good.
And you increase the compile time,
this can be very bad, so
we need to deal with that.
Here's a simplification thing
showing how things work
over the years.
So in 98 or thereabouts we
started using things like pair.
And we have to say a pair
of what and initialize it.
With 11, we say make pair, and
it'll deduce the right types.
And we can use auto, so
that we don't have to sit and
repeat ourselves so much.
And in 17,
we will be able to have the template
documents deduced
from the initializer.
Cool stuff, so, progress happens
at the smart more level.
This is the kind of simplification
that where we'll help people.
It'll also confuse people
who read old code and
can't understand what the new code
is doing or get used to the new code
and get confused about what
the old code is doing.
You can't actually have
changed without some cost.
A direction, I think we should
talk more about the future.
It would be nice if people
agreed on a list of things we
would like to see in
five to ten years.
And it would be nice if people had
an agreement about roughly what we
would like for an extender
in the three year horizon.
We are not having those discussions,
we are not having those
lists that's bad.
Most people don't articulate
their aims, I do but
often people fall asleep and
don't read them.
And we should be
explicit about this,
we should be articulate about it.
We can't spend all our time
discussing the details.
And that's what I feel what we do,
and
furthermore, the last one
is very controversial.
I want to integrate things early.
I want to see it in the standup
document together with the other
things, so that we know that
things work together or not.
Lot of people want to delay
things until they're perfect.
Remember Voltaire?
Best is the enemy of the good.
So some philosophy.
We will make errors,
in language design,
like in program design and such.
So let's get them made.
I'm for early integration,
I'm for moving ahead.
We know we are going to
make mistakes anyways, so
let's get used to it.
And we should maximize
our successes,
we shouldn't just minimize failures.
Of course we don't want failures,
but we are going to make mistakes
anyway, so
let's make them and fix them.
Any change carries risk,
including not doing anything.
And we have to be confident.
I think we're getting too nervous
that we might make mistakes.
Forgetting, one,
we do make mistakes, and
two, in the past, most of
the time we were able to fix it.
Before it was shipped, or
before it was significantly
impacting the community.
Look, if your library writer or
compiler writer,
it hurts them to back up something.
It hurts when something breaks but
that's life, and
it, if we have to move on,
we have to take some chances.
And one thing people do a lot, is to
confuse familiarity with simplicity.
If it looks the way I'm used to it,
it's simple,
is many people's definition.
No it's not, it's familiar.
It may be simple You have to go for
simplicity especially
on major things.
So, a problem we have is that we
can't actually explain what C++ is.
And if we can't
characterize what C++ is,
how can we explain
what it should become.
We have to have some kind
of agreement what it is.
I have my suggestions,
it's a language for defining and
using light weight abstractions.
It's aimed primarily at
software infrastructure and
resource constrained applications.
We have long papers
explaining what that means.
Who is the language for?
Meaning it is not for people
who want to do a quick webpage.
It's, I use the phrase
serious programmers
in the first edition of
the C++ programming language.
It's actually the first
sentence of the first edition.
I use serious,
I edited out professional
slightly early because I realized
some of the amateurs were better.
But people it takes the act
of generating good code,
or writing good code, or
maintaining code that's serious.
And that's what C++ is for.
It's less for casual programmers,
unfortunately.
There's a lot of those, they do
real good C++ at times, but only
if the serious ones get there tools
and libraries in such in place.
And what would make
the language better?
We have to specify what
it means to be better.
You've seen some suggestions in
this talk and in writings but
we have to be specific
to make forward.
And so, we can't please everybody
we'll maintain the direct map to
hardware, the zero-overhead
abstraction.
Language is primarily industrial.
We'll never get it pretty enough for
every professor to like it for
teaching freshman.
I've taught freshman,
to thousands of them, can be done.
It's not even that hard but
you have to do it right.
What primarily C++ is
there because we can build
good systems for people.
And then it rewards
good programmers.
If you are a good programmer you
shouldn't be stopped from doing
good stuff.
We should make it simpler for
a good programmer to do good
stuff in areas we don't know.
In application areas we don't know.
In application domains
we have never heard of.
It's good.
It would be really nice if we
had a buzz word for saying this.
I don't, I'm sorry.
And everytime I've tried to find
out good words I've learned why
I shouldn't be in marketing.
>> [LAUGH]
>> Now, let's try and
look ahead a little bit.
My high-level aims was
first C++17 and beyond.
Now they're just for C++.
Let's not put a specific
time scale on this.
Improve support for
large-scale dependable software.
Support higher-level concurrency.
Everything is getting concurrent,
so let's support it well.
Simplify the core language use,
you can't simplify the core
language that can break your code.
We can simplify it's use, ranges
also when things like that can
simplify range for also things like
that can simplify your code and then
we have to address the major sources
of errors that can be through tools.
It can be through coding guidelines
It can be through language
features and libraries.
Preserve the fundamental strength.
C++ has to remain C++.
If you want something that's
fundamentally different from C++,
go get it.
C++ is not for everything and
for everybody, we know that.
But don't abandon the past.
Don't get stuck in the past and
awards more feature creep because
there's so much stuff there.
So there was my top ten list for
17 as presented I think
in February last year.
And I was very optimistic.
I thought we were
going to get concepts.
I thought modules were so far
advanced that It would be a stretch.
Goldberg might be able to get it.
There was a range library.
It was marginally, might get it.
Uniform syntax, code things,
the shipping networking,
it's been shipping, contracts,
yeah, stretch goal.
SIMD vector and parallel
algorithms that is going well.
Library, vocabulary type,
optional variance string span span,
yeah it's going in a magic stack
array type because stacks are really
useful things and it would be nice
to have proper arrays on them.
And, well, I learned the hard way
it's hard to make predictions.
Especially about the future.
We only got the two things that are
pointed to there and only partially.
And all the rest is postponed.
That's sad about that.
Here's what you actually get and
here's a list.
And the problem is that all of that
basically is in the minor category.
A lot of minor improvements can add
up to something significant if we,
well Most of these will help
somebody in some way so
there's something for everyone here.
I can't imagine any C++ programmer
that will not have at least some
relief from pain in C++17,
that will not be able to write
some piece of their
code better in C++17.
So what I'm concerned about is that
we are not moving fast enough and
we're focusing on too small things.
And let's see a library features,
well,
it's not a library talk so
I'm not going to go into that.
We're finally getting
the file systems and
parallelism kind of stuff.
Okay, so what do I think now
after the last year or so?
For C++20, and
hopefully available before 20,
I would like everything C++17, and
I would like my C++17 list because
it still reflects the way I think
the language ought to be going.
And operator dot,
I want smart references, finally.
They were about the first extension
proposed at the first meet,
second meeting of the C++ standards
committee back in the dark ages.
I think we finally
know how to do it.
Before comparisons, it was
rejected by the standards group.
I think they got it wrong.
And, beyond that, there
are things we need to look into.
We could use a packet manager.
We could use a standardized
representation of C++ source code
that we could use for tool building.
IPR is something that Gabriel Dos
Reis and I did a few years ago.
It's a general representation
of a language for
the superset of C++, fully typed,
minimal in all possible ways.
It would be lovely if we would
get something like that.
There's work on static reflection.
I would like to see that come in.
I've been experimenting with
functional programming style
pattern matching.
So we could finally get safe
use of unions and such,
part of this idea of making things
simpler and making them safer.
And high levels of concurrency
support, I'm not going to be
specific there but I don't want
to fiddle with new texts and
worrying about data raisers and
such.
We can do better.
And then I feel that we
are diluting the effort.
We have 100,
200 people in committee.
We have 1,000 people in
the community that contributes.
If we don't watch out,
we'll get nothing because
we are all over the place.
And if you look at this list,
I did not expect I'd get
everything in 17, but
I expected I'll get something,
and this is not much.
If this has been a project, whether
we have a project management and
such, we would have shipped
a couple of the major things and
you would have been busy learning
about it and upgrading your code.
As it is now, it's harder.
It's lack of focus that does it.
So, what do we do now?
We'd have to get ready.
Upgrade to C++14 if
you haven't already.
Lots of places have upgraded to 11.
It's easier to upgrade
from 11 to 14.
This is good.
If you're still stuck in '98, either
mindset or compilers, upgrade.
It's the best of getting ready for
the future,
is at least get to the present.
Furthermore, your
code will run faster.
If you compile with a modern
compiler, you will be able to
run faster because you'll
target modern architectures,
instead of using the backward
compatibility features of your CPUs.
Upgrading from an old compiler is
a good way of finding bugs and
to run faster.
And try out the TSs.
I mean you can get concepts.
Ranges are there to download news.
The networking library has been in
production use, in many places, for
the last five years.
It's great.
Coroutines are shipping,
mostly by Microsoft but
I hear there's a Clang
implementation also.
Try them, you can do some
really cool pipelining very,
very fast, and you can do it today.
Modules, they're coming.
There's talks about them
at this conference.
This is good.
And then I'm still working on the
core guidelines that we announced
last year.
They've improved.
I'll get to that.
Improve them and
improve tool support.
So let's go over concepts.
So technical specification,
it's shipping GCC 6.1.
The most important thing
about concept is that you
can improve your specification
of your generic code and
you can get simpler generic code,
like you can do overloading
based on concepts
rather than writing an.
And you can get better error
messages and, by the way,
compiles faster than
the alternatives.
And so basically I want to see code
that says I want to sort
anything that's sortable.
And so,
if I sort a vector it's sortable.
What does sortable mean?
Definition is over there somewhere.
It is a sequence that
is random access
with elements you can
compare with less than.
Okay, translate that into C++.
It's four lines and you're done.
By the way,
you cannot sort the list.
Why not?
The standard says so.
It says that the list is not
a random access sequence.
And so the error messages will tell
you that it's not sortable, and
it will tell you that it is
not random accessible and
it's not random accessible because
it doesn't have soft grade plus.
There's been some discussions about
the quality of the error messages.
Some people want more,
some people want less.
I've forgotten what
they're shipping in 6.1.
It used to be that
there was a switch, so
that you can say how
much you wanted.
I always wanted less, and
a certain who wrote that
compiler always wanted more.
It seems that people these days out
in the community usually wants more.
They'll get over that.
Once you learn to use the concepts
and know the concepts,
you'll want less.
I want that switch back.
Concept design can be
used in the comments.
You can actually design
your code around concepts.
You could actually
design your code and
test it out on the Microsoft
compiler commented out.
No, sorry, not the Microsoft,
the clue compiler, and
then port it to whichever
compiler you're using.
Just put a comments in place.
And when the other compilers
catch up, take the comments away.
And you can use the concepts
from the ranges, TS.
There's a good set.
You don't have to
start from scratch.
Then we are going to get modules.
Almost certainly.
And this is the way
we write code today.
We include some files and
then we use them.
And there's some data I
got from Gabriel Dos Reis.
There is 176 bytes of text that you
wrote to get this little example.
It becomes 400 plus kilobyte GCC,
just over a megabyte with Clang,
or Visual C++.
Now, our compilers are very,
very clever to actually ever get
finished with all of that text.
And that was only one file.
You're going to include
that stuff 100 times and
it's going to be bigger.
We are simply going to radically
decrease the amount of data
processed by the compiler.
This ought to give significant
improvements in compile time.
I don't have any
numbers unfortunately.
To use it,
you need better code hygiene.
If you have undisciplined
macro usage,
you're not going to get that much
advantage, because if you have old
code, and you demand your compiler
does the old way of doing things,
you're going to get
the old performance.
So some cleanup would be necessary,
but once you've worked this in,
get code hygiene,
get fast compilation you just import
the libraries and
then you use them to write a module.
It's not rocket science,
you can introduce it gradually.
Have some stuff that usually
includes on the macros,
have some stuffs
that encapsulate it,
have some stuff that
doesn't use it any more.
And, basically,
it's based on two keywords.
One for getting things in, and one
for saying you want to get it out.
There's lots of details, of course.
There's at least three talks
at this conference that'll
tell you about the details, so
I'm not going to do it here.
I'm just going to say
we have to hope for
simpler code that compiles faster.
And if you compile it with things
like concepts, it gets even faster,
it gets better error messages,
and cleaner code.
We're working on a contract,
it's simply a proposal now,
we're working about it,
it's sort of assert on steroids.
And it's selectively enabled
at runtime, so you can say
preconditions, expect latter
thing if the queue is not full.
Post conditions, it make sure
that once you have push something
on to the queue it's
no longer empty and
you can have assertions
in your code.
So, that simply standardizes
what a lot of people are doing
with special code on macros and
such.
And there will be three
levels of contracts you
can argue whether it should be two,
three, or four.
Currently it is three.
Basically audit,
which is big expensive tech checks,
default, which is
relatively cheap check,
checks relatively to
the algorithm that's being done.
And action, which is basically
not checked at compile time.
You can write things like that.
And we're going to get something
called structured binding.
This was voted into C++ 17.
It's coming in compilers right now.
We'll probably be told this week
whether it is shipping in Clang.
I think it either is or is close.
Basically it can give local
names to struct members, so
when you call something like
a map insert that returns a pair,
you can break out the pair.
The one is an iterator and the other
one is a success indicator.
And so you can write code like that.
One of the things it does,
is work nicely with the range for
loop things.
So you can go through the map and
for each element break out the key
and the value and do things with it.
Very nice, very nice stuff.
And then the kicker here is that
we design things to
work in combination.
If we didn't do that every
feature would bloat by itself.
And there would be tremendous
overlap in the language.
There's already enough overlap
between the features
in the language.
But these things can work together,
so I want to write that code.
I import, I O-stream, namespace,
I have a map printer, I
write some code, it has concepts in
it, it has structure bindings in it.
I can't do it.
Modules are shipping by Microsoft,
concepts are shipping by GCC,
and structured bindings
are shipping in Clang.
I will be really happy
when I can get all three
in all three compilers,
because I happen to work in a place
that uses all three compilers.
I'm an optimist, people can tell me,
will I get it next year?
I hope so.
Okay, again, thanks.
We couldn't do it
without a lot of people.
I shouldn't have said that,
I myself am up there, I shouldn't.
Okay, that guy there,
I'm not thanking.
But the others I'm thanking.
>> [LAUGH]
>> Okay,
they've all done hard work to
get us to where we are today.
And again, if I put in everybody
in the font will be too small for
you to see it, so I just picked
a few that did something.
Until now, the other thing we can
do is we can work on guidelines for
how to write modern C++.
How to clean up the old code.
I gave the keynote
last year on that.
If you haven't seen it you can.
But basically, we want to
guide people towards a better,
more effective, more efficient,
better style of code.
Develop the style and we're aiming
at type and resource safe C++,
no leaks, no memory corruption,
no garbage collector.
No limit of expressability,
no performance degradation, and
in strict ISO C++, tool enforced.
I'd hoped to be able to say I could
do this at scale, today, I can't.
It's not at scale yet.
But, there's a lot there, there's
a lot that wasn't there last year.
So progress is being made.
There's the links to the guidelines,
they are links to the support
library we're using.
And we can use all
the help we can get.
And the aesthetic analysis
tool support that has started,
you can actually get something
out of a few of them.
I just wanted more.
So the status is
we've got 423 rules.
Which is, of course,
too many rules because people can't
remember 423 rules,
can't even count that high.
On the other hand, the idea is that
the tools will help you find where
you made a mistake and dump you to
the right place in the rules so
that you can read what was the rule
that you are not supposed to break.
Why is it a good rule?
Examples, and
what can you do instead?
And some of that is in place.
There's beginning industrial use.
Usually an organization subsets and
super-sets to fit
their specific needs.
That's good, that's expected.
It said so
in the introduction even last year.
And there's some starting use
in teaching commercially and
in academia.
So after a year I
guess I shouldn't be,
I'm impatient, and
I wish there was more.
But maybe I shouldn't be.
The fact that one year later it's
getting into academic curricula
is pretty good.
We wanted better tool support.
I thought it would be better.
Well, apologies, things happen.
We're working on it, and
if any of you are tool builders,
I encourage you to think about it,
look at the guidelines, content,
the guideline's editors.
You can find us on the GitHub and
I'm one of them.
So not too hard to find.
Herb Sata is the other
main name on the paper.
And expect more.
And again, thanks.
We have,
I don't know how many contributors.
Twelve squared.
And lots of issues.
I hear about translations into
Russian, Portuguese, and Korean.
I can't read those languages,
so I don't know how up to date
they are or how good they are,
but somebody is trying.
Our general approach to just about
anything is sort of the cocktail of
approaches.
We use low level stuff, like in the
GSL, the guideline support library.
There's an owner annotation
that means nothing.
It's an alias.
But it tells you it's an owner.
So static analysers and humans can
understand that you're supposed to
delete that thing when
you're finished with it.
At the higher level,
where things are better,
you have abstractions
that represent ownership.
Vectors, unique pointers,
map, shared pointers, and
stuff like that.
And we have support for
optional range checking.
We go one level up.
Span, string_span, not_null,
you can express things directly and
you can either have
the code check it.
These libraries functions
will actually do checking, or
you could have the equivalent
done statically.
And then we have rule support.
There are somethings that just don't
do it or just do it this way and
you don't get into trouble.
That helps and we work.
The idea is the applications
are built on the abstractions and
then you can verify them.
As oppose to fiddling around with
low level stuff all the time.
But sometimes you need
the low-level stuff.
Herb will talk a bit about
that in the last keynote.
There's an outline of the
guidelines, there's a lot of them.
The supporting sections, a lot of
them are horribly incomplete, but
not all of them.
Some of them actually have teeth.
And some of them actually have
checking that supports them.
Here's an example.
Do not pass an array
as a single pointer.
This is an example of one of
the rules where we have looked into
seeing where the bugs are.
And people passing a pointer or
peer pointers and
an integer that's supposed to
tell how many limits there are.
This is a bug source.
It is a major bug source.
Furthermore, it's a source of and
other kinds of stuff.
And so the rule is there,
it's easily checkable, and
there's an alternative.
You can't just say,
people, don't do that.
I mean, what do we think it is,
kindergarten?
You have to give
an alternative that is valid,
applicable, and equally fast.
And span in the GSL is
an example of that.
There's an example of
how to get burned.
Somebody thought it was a bright
idea to have an array of
elements of a derived class, and
then pass that to a function
that took a base class.
There's a double implicit
conversion going on there.
First it converts
the array to a pointer,
then it converts the pointer
through derive to
the pointer to Base and
boom if you subscript that stuff.
Again, don't do it.
The tool will catch it for you.
I mean you could say I
would never do that.
Well I'll tell you some
people do that sometimes.
Bugs are very often done by people
who hasn't been burned yet.
And it would be really nice to help
them, and that's what we can do.
So that's the sort of structure.
There's some exceptions if you
pass zero terminated strings.
That's fine.
An enforcement, I believe
this actually is available in
the implementation by Neil Macintosh
in the Microsoft compiler.
And here's the example
I gave earlier.
You can use concepts today.
And the recommendation
is use concepts for
all of your classes today.
And, if you don't use a compiler
that understand concepts,
put comments in front of them.
I had a comment just this
week about this rule, and
says you didn't mean
policy types of something?
And I said give me an example.
And the answer came back says,
I tried to write it down and
I realized that I
needed these concepts.
People who hasn't tried this stuff.
Under estimated, and if you dont
want us to start from scratch go to
the ranges TS and find a good
set of starting concepts.
It'll teach you some
good manners and
it'll help you get started by
specifying the code better.
Always initialize an object.
I mean, we should do that but
there's a lot of clever stuff
where people say,
I don't want to initialize it yet.
And then they forget.
Or they write a complicated if
something is something initialize it
this way, initialize it that way or
else you divide that way.
Okay, you get it wrong sometimes.
It gets too clever.
If you don't want
a thing initialized yet,
don't declare it yet.
If you have a complicated
initializer,
there's ways of doing it.
Like if you ever have
initialized a variable,
a variable with a lambda that did
some conditional stuff on it.
You can do better.
A rule like that gives you
suggestions for how to do better.
Don't just say don't do it,
say why you don't do it, and
what you can do instead.
And there's a lot of related talks.
This is sort of my reason for
not giving a language feature talk,
apart from
feeling that sometimes you have
to talk about bigger pictures.
There's a lot of talk
at this conference.
You want to know more about modules?
There's modules talk.
You want to know more
about guidelines?
There's guideline talks.
Code teams.
It's here.
Parallel algorithms,
which I mentioned, they're here.
And this is, undoubtedly,
not all the related talks.
In some sense every talk at
this conference is related,
but in a stronger sense
it's available there.
And so.
And here's some kind of summary.
C++ is successful.
We have to build on what
made it successful.
To sustain the success and
to sustain the many applications
that we depend on everyday.
And We have to focus on
significant changes.
We mustn't just spend all
of our time on details.
First you decide where you go.
First you decide what is major.
And then you can agonize about the
details, not the other way around.
And we can't wait for the comedian,
the compiler writers
to finish everything.
We actually have to catch up
with what's available now.
We have to experiment.
Experimentation shows how
we can use new features.
It may even show you how new
features can be improved
while they're still in
the design and decision stage.
And the TS's, especially in
the libraries, can be used.
Some of them are in
production use now.
I don't recommend all of them,
for production use.
But there's no need to wait.
There's a lot of stuff that can
be done by us this afternoon.
This is not just future stuff.
Yes, those philosophers
on the first slide,
but some of it is really concrete.
And try the guidelines.
If you tried it after last year,
you found it was incomplete.
You try it now, it's still
incomplete but it's better.
Significantly better
than it was last year.
And, yep.
By the way,
that picture's not of stars,
it's a program that
pretends to generate stars.
So, in case you wonder.
And so,
I think I have plenty of time for
questions now Thank you.
[APPLAUSE]
I don't know,
do we have a system with
microphones and such? Yes.
Please use the microphones if
you're asking questions.
>> How much can modules help
with template heavy code?
>> How much can modules
do a template heavy code?
Quite a lot,
because you can break
templates down into
something like the IPR, I mentioned
the internal program representation.
So you'll basically build a typed,
abstract dag.
Not in the ST but,
something more advanced like that.
And then a lot of the template
work has been done once.
And so, only the final
instantiation will be done once
per set of template arguments
as it was meant to be done.
So go and ask the people
that are doing modules,
especially people that do both
modules and concepts like Rays.
He's down there with a hat.
He's the right person to ask,
but modules plus templates,
especially modules plus
templates with concepts,
is a very very potent mix.
Both for compile time,
and for correctness.
I want those faster compiles,
significantly faster
compiles to find more bugs.
It's easier to compile faster, you
just postpone everything's runtime.
[LAUGH]
That's not what I want.
>> Thank you.
>> So, you seemed sort of frustrated
with the pace of the 17 standard,
that we didn't get a lot of
the features that you wanted.
And you showed the graph of
where it went real fast up and
then flattened and then went fast up
again and your worried, seemingly.
It feels like you are worried
about it flattening again and
you want to try and forestall that.
>> But i wonder if you can give some
historical context as to, when we
were in the flat portion back
in 2005, 2008, did it feel flat?
What was the committee
doing at that time,
that was before a lot of our times?
>> Okay, this is a very complicated
question to answer because
it spans decades and, well, millions
of people ,and language features,
and industrial connections and
everything.
But yes I"m very impatient and yes
if I'd been dictator of the world
you would have had more features
today and people in the committee
that didn't think this was the right
thing will tell you I'm wrong.
And I'll tell them they are wrong
and that's how we discuss things.
>> [LAUGH]
>> Hopefully we're still
friends after that.
At the time, yeah 2002 +/- 3.
It did feel as if things
were not going as well as it should.
The committee was under the false
assumption that you couldn't discuss
new language features for
five years.
We actually believe there
was an ISO rule for that.
There was some kind of IS rules
says you couldn't vote them in and
change the standard but
we were wrong.
We were also very tired after
the effort of delivering 98.
And I think we screwed up.
And then fortunately the CPU
stopped getting faster and
a few other things, and
we sort of recovered.
And like Stephanoff did us a real
good favor by the SGL which
created a certain amount of
excitement when we needed it badly.
So Hit on that before the standard,
but of course,
after the standard is when
you get it available.
So, yes, I think we could do better.
And yes I think we
can do things faster.
I don't think any total
disasters have happened.
And I, just trying to give my
contribution to what we can do and
why we should do it.
And next year and the year after, we
will know more and have high hopes.
A lot of these things are shipping,
that I've been talking about.
>> So, C++ has this rich history of
features following this pipeline
from third-party libraries
into the standard library and
even into the language itself,
for instance,
move semantics were in boost
before they were in the language.
But the path to language is much
rockier because the APIs for
extending compilers aren't really
there, thus you often have these
really dirty tricks that people
do inside of metaprogramming or
inside of all these other things.
And it takes a lot longer to get
things into the language because
of that, and that's really
cuz the APIs aren't there.
Is this something that the standards
committee should be concerned with,
or is that something that's on your
mind, should those be standardized,
and why or why not?
>> Let me just ask a counter
question before I Try to answer.
You said APIs?
>> Well, standardized APIs.
I mean I can't write a new compiler
extension that will work with
Microsoft and
will work with Clang and-
>> Okay,
I was just trying to make
sure it's right thing.
That is a very hard question.
Traditionally, platform
vendors have insisted
they can do things
on their platform.
And compiler vendors are very
keen of not breaking
their current user basis code.
Furthermore, there's been a concern
that if we standardized an ABI,
like the Itanium ABI, and
said everybody had to use it,
we would limit experimentation and
performance.
So, this has been close to
the third rail in discussions and
the standards committee, and
there has been people who
simply wouldn't discuss this.
And I don't have high hopes for
this.
If we could get a group of people
together to arrange
greater interoperability.
You would have to have for
starters Clang, GNU,
Micrsoft, Intel, and
a few others to sit down and agree.
And I don't think it'll be
the standards committee that
can do that.
For starters,
they wouldn't want 100 people
involved in the sign
of a standard API.
Furthermore different hardware
has different things.
So you probably could not
standardize across architectures.
And if you can't standardize
across architectures, how can you
standardize across architectures
that are still changing?
So it's a really,
really sticky problem,
and since I've failed to
make progress in that area
repeatedly, I'm not going
to make any promises.
Complain to your compiler vendor,
>> [LAUGH]
>> Encourage them to do something,
maybe not perfect, maybe there
could be a compatibility suite or
a conversion mechanism in place or
something,
but don't rely on the standards
committee to doing that.
>> I would like to comment a little
bit on the list that you have for
C++ 20 and beyond, and
the weirdness of hardware.
Because I didn't quite make
the connection between
how we're gonna support this
weirder hardware, as you mentioned.
>> The main thing that was
missing on that list was specific
things about improved
concurrency control.
That's, I think, we need higher
level concurrency models.
We may need some work in cache
awareness, I don't know.
Somebody may look into that.
And we may see some work
in the standard library,
for say,
flat containers of various sorts.
For using, cash is better.
I just didn't want to
go into details there.
And I think a lot of
it is a library issue,
which is the main reason I
didn't go deeper into it.
Libraries with intrinsics.
>> In your growth chart,
I think there were maybe two hidden
things that you didn't point out.
That were, maybe there is growth
of the communication web and
being able to get access to a lot of
information, and perhaps maybe some
key individuals who have helped
project the language forward,
over the last couple of years?
I mean, notable people who
are at this conference.
What are the ways to,
do you think those are actual
factors in the growth of language,
and if they are, how do you capture
that and make it go forward?
>> I didn't quite understand,
could you.
>> So the idea being if there was
sort of a lull in the growth of
language and then it sort of
took up, was that due to,
maybe there are things on the list
that you didn't talk about,
that I can find information easier.
I'm able to use learn about how
to use a language better than
maybe 2000 and
did that help with the language?
>> Yeah.
>> And also
now we've got a lot
of people helping.
>> It's a complicated issue.
The exhaustion of
the committee members were
important, so
was the draining of the community
by organizations like Sun that was
taking the best compiler writers and
putting them on Java.
And so was the fact that
we had never managed to create
a center for the C++ community.
We don't have a central website,
we don't have a central library
exchange, and things like that.
We're trying now.
The C++ foundation is part of
an attempt to deal with this.
And then finally there was
libraries that was missing,
notably a GUI library.
There's no standard for it,
which we couldn't get, because there
was at least five organizations
that was members of the standards
committee that was of the opinion
that their GUI was the best.
And we could not move
without insulting
more than half of the committee And
that's not the way you move.
There was all the things, we're
finally getting a networking library
but why don't we have
a web access library?
It's 10 years late and,
Well this happened.
It was ten years ago.
The question we have to ask
is what can we do today.
And we're moving too slowly for
my taste.
I would have liked the SU
library to be shipped with 17.
As it is, it's production quality
and used, so use it anyway.
>> Hi, actually you answered a part
of my question by talking about
concurrency and cash awareness.
But my question was more like, you
started by saying that C++ has to be
true to its two code principles of
one, staying closer to the hardware,
and second is, providing minimal
obstructions on top of it.
It's just my opinion that as
we are going to C++ 17 and 20,
I think the focus has more been on
providing those extractions better,
whereas the focus is less on
being closer to the hardware.
And almost to an extent that,
there has been a perception that,
people say that if you are really
focused towards speed, you see.
So what's your opinion
on that focus?
>> There's a lot of
impressions out there.
And very often they are wrong.
I think there is a part
of the community and
part of the standards community that
is very interested in performance.
In my day job, I sometimes deal with
both high volume data and
ultra low latency data.
I can count nanoseconds now,
I didn't used to be able to.
And it's certainly not forgotten.
Whether we popularize and
spread the word well
enough is another matter,
and also whether the ideas
that come forward
are general enough to
work with everybody.
They'll certainly work with,
for instance,
integrating FTAs and
CPUs and GPUs on the same
On the same chip, and
we're aware of that.
There's at least one
cross industry group that
are looking into issues like that,
that we know about.
But I suspect that we're still
waiting for some proposals for
how to do that,
some people are talking about it.
I think it's more an impression,
an image issue, than it is real.
But anything we can do to get
more known that we're working in
those fields is probably good.
I think there are talks
at this conference that relates
to better use of hardware.
I suggest you look into
it on the schedule.
>> Could you maybe say a couple
words about the role of Boost in
the past, and then particularly
what you envision is a role for
organizations like
that in the future,
as far as contributing
to this effort?
>> Boost has made an excellent, and
important contribution to
modern C++ in general,
and to the stand in particular.
They've tried out a lot of ideas.
I would say only a few of them
have any chance of getting into
The Standard, which, I think is fine
because The Standard is what has to
be shipped to everybody everywhere.
And it has to work together.
Boost is doing a good job, but
they shouldn't expect more than say,
a 10% success rate,
if entry into the standard
is the measure of success.
I don't think it should be.
I think usage should be.
The other thing is that sometimes,
I think,
Boost over designs, and
becomes a bit expert friendly.
And if I would make some
suggestions to Boost,
nothing I haven't done all ready
repeatedly, and actually once at
BoostCon, focus a little
bit more on simple use.
Focus a little bit
more on packaging.
I would like to have sort of a
novice's package of Boost stuff for
the essentials, and
then the package, and
then the experts only package.
And I would not have to want to know
everything that an expert needs to
know to be a novice user,
examples like that.
But I think Boost is
one organization.
It is not the only organization,
I wish there was more and
I wish there was more code there and
I wish people would use it more.
Without it we would be sunk.
>> Thank you.
I might say I think you way
underestimate your abilities as
a marketer.
>> Sorry, I am over.
I'm being interrupted here.
Sorry about it, there is
a session for committee tonight.
So if you've got committee
questions, you go to that.
And otherwise catch
me in the corridors.
That was a hard interrupt.
Sorry.
Thank you.
>> [APPLAUSE]
