0:00

Episode 365 of CppCast

0:02

with guest Bjarne Stroustrup recorded 11th

0:04

of July 2023.

0:07

This episode is sponsored by JetBrains,

0:10

smart IDEs to help with C++. And

0:13

Sona, the home of clean code.

0:30

In this episode, we talk about the upcoming

0:32

boost release and other news from the

0:34

C++ world.

0:39

Then we are joined by Bjarne Stroustrup. Bjarne

0:45

talks to us about modules, concepts and safety

0:47

and security in C++. Welcome

0:59

to episode 365 of CppCast, the

1:01

first podcast for C++ developers by C++ developers.

1:05

I'm your host, Timo Dummle. Joined

1:08

by my co-host, Phil Nash.

1:09

Phil, how are you doing today? I'm

1:11

all right, Timo. How are you doing? Oh, yeah, not

1:13

too bad. I had a last week off.

1:16

So we went to the

1:18

summer cottage. It's called the Mökki. That's like

1:20

the thing that all the Finnish people do. It's

1:22

kind of in the countryside, no internet,

1:24

by the lake. That

1:27

was very pleasant. This week, I'm back. So

1:30

yeah, doing pretty well, feeling reasonably relaxed.

1:32

How about you, Phil?

1:33

I'm jealous. I was

1:35

working last week, but I was taking it a little bit

1:37

easier. I think I've fully recovered now from

1:39

C++ on C, so back

1:42

on track, ready to face the world, I think.

1:45

All

1:45

right. So you're actually going on vacation as

1:47

well soon, right, Phil?

1:49

Yeah, in about three weeks. So

1:51

in fact, I'm going to be away for three weeks,

1:54

which

1:54

means we're going to have to

1:56

cover two of the episodes.

1:58

So we're going to have a couple of guests.

1:59

And we're not going to tell you

2:02

who they are until the time just to

2:04

leave a little bit of mystery around it. Yeah, but

2:06

yeah, I'm very excited. You're

2:08

going to have some really cool guest co-hosts. So

2:10

you can look forward to that.

2:12

All right. So at the top of every

2:15

episode, I like to read a piece of feedback.

2:17

This week, we actually don't have any new feedback

2:19

because we released the last episode only four days

2:21

before we were recording this one.

2:23

And that's because next week I'll be in Toronto and

2:25

Canada for the C++ CPP North conference.

2:29

And we kind of have to finish all the editing before

2:31

I go there. So we only had a few days

2:33

before recording, kind of publishing the last one and

2:35

recording this one. So we

2:37

didn't get any feedback in that short amount

2:39

of time yet. But yeah,

2:42

I hope that we're going to get some.

2:45

Yes, good opportunity just to remind people

2:47

that it's nice to get some feedback, especially

2:49

to read out on the show. So if you've got anything

2:52

to say to us, do let us know on any

2:54

of the channels that we mentioned. So yes, we'd

2:56

like to hear your thoughts about the show and you can always reach

2:58

out to us on Twitter or Mastodon or

3:01

email us at feedback at CPPcast.com.

3:04

Joining us today is Bjarne Struestrup.

3:07

Bjarne Struestrup is the designer and original implementer

3:09

of C++, as well as the author of the C++

3:12

Programming Language, a tour of C++ and

3:14

many popular and academic publications.

3:17

He's a professor of computer science in Columbia University

3:20

in New York City, a member of the US

3:22

National Academy of Engineering, and an IEEE

3:24

ACM and CHM fellow. His

3:26

research interests include distributed systems,

3:29

design, programming techniques, software

3:31

development tools, and programming languages. To

3:33

make C++ a stable and up-to-date

3:36

base for real-world software development, he has been a

3:38

leading figure with the ISO C++ standards

3:40

effort for more than 30 years. He holds

3:43

a master's in mathematics from Aarhus University,

3:45

where he's an honorary professor in the computer science

3:47

department, and a PhD in computer science

3:49

from Cambridge University,

3:51

where he is an honorary fellow of Churchill College.

3:54

Bjarne, welcome to the show. Thank

3:56

you very much. It's

3:58

good to be here. Again. So

4:03

it's usually at this point in the show that I'll pick

4:05

on something in the bio and ask a question, but I

4:07

think it's been a stress drop. I don't really have

4:09

anything to say. So I think we should just

4:11

get straight into the material. Well,

4:14

one thing that I'll say is that last time you've

4:16

been on the show, Bjarne, is actually over six

4:18

years ago. It was, I think, in May 2017. A

4:20

long

4:21

time. So overdue, long

4:23

time. Thank you so much for joining us again. We really

4:26

appreciate that. I mean, C++ is

4:28

long lived and still growing.

4:30

Yes, I don't think we're going to talk about that. Yes,

4:33

you will. So Bjarne, we'll get more into your work in just

4:35

a few minutes, but we have a couple of news articles

4:37

to talk about first. So feel free to

4:39

comment on any of those if you like.

4:41

So the first one I have is there's

4:43

a bunch of new C++ conference videos. So

4:46

if you like watching

4:47

conference talks on YouTube for free,

4:49

there's more stuff now for you. So C++

4:52

Now, which

4:54

is the conference that happened in May, just a couple of months

4:56

ago,

4:57

just released the first five videos on

4:59

their YouTube channel for free.

5:01

And the remaining videos from that conference

5:04

will be released over the next couple of months.

5:06

And then videos from ACCU 2023, which

5:09

is a conference in the UK that happened in April,

5:11

also started appearing on YouTube. So they're

5:13

kind of coming out one after the other. So I imagine

5:15

that over the course of the next few

5:17

weeks,

5:19

all that content is going to be available

5:21

as well. So there's lots of material.

5:24

Have fun watching it.

5:25

I think there's some really, really great talks in there. I've been to

5:27

both conferences and

5:29

there's some really good content there. So I'm very

5:31

happy that

5:32

everybody gets to access it for free. Obviously,

5:34

we'll put the links to those in the show notes.

5:36

All right. The second news item I have is

5:39

JetBrains is running a developer ecosystem

5:41

survey again this year, just like every year.

5:44

So it's the seventh time they're doing this. And

5:47

the survey to explore the current state of the software

5:49

development industry takes about 25 minutes

5:52

to complete. And everybody who completes

5:54

the survey with meaningful answers will have the chance

5:56

to win a prize of their choice, which

5:59

is either a matter of time or MacBook Pro 16

6:01

inch or an Nvidia GeForce RTX 4090 graphics

6:04

card,

6:04

or an iPhone 14 Pro or a Samsung Galaxy

6:07

or a $300 Amazon certificate

6:09

or a JetBrains All Products Pack.

6:12

So answer

6:14

the survey, choose which price

6:16

you prefer and then good luck. And

6:19

the results of the survey as always will be published

6:22

publicly, so they will be available for free.

6:24

And it's one of, I think, three surveys

6:27

that are going on regularly as the JetBrains one. That's

6:29

the one where meeting C++ and that's the one that

6:31

the C++

6:33

Foundation runs. And

6:35

yeah, I think all three of those are kind of, it's really

6:38

good and important to have like a snapshot of where

6:40

the community is.

6:42

So yeah, I encourage you to support,

6:44

to put that effort and answer the survey. It's kind

6:46

of fun. Yeah.

6:48

And as I said before, those of us that

6:50

do work in tooling,

6:52

we do monitor these surveys to sort

6:54

of give us an idea of

6:56

the pulse of the community and

6:58

what things are needed, what

7:00

things are being used. It's really useful.

7:02

All right. And the last news item I have for today

7:04

is about the upcoming Boost release. So

7:07

Boost is going to release their version 1.83

7:09

at some point, I think in the near future.

7:12

There is no release date as far as I can see,

7:14

but that's going to be the last release that

7:17

is going to support C++ 03.

7:19

And the reason I'm talking about this now, even though there

7:22

is no big announcement that it's out

7:24

or anything like that, is because I

7:26

noticed that there was a blog post about a particular

7:29

new feature in that upcoming Boost release,

7:31

which is Boost unordered,

7:34

which is now providing a new container,

7:36

Boost concurrent flatmap.

7:38

And there is a big detailed blog post

7:40

about how it all works.

7:42

So it's an associative container. It's kind

7:44

of based on Boost unordered flatmap, but

7:46

it's thread safe and it's suitable for high

7:49

load parallel scenarios.

7:52

And yes, it is ordered. It is

7:54

based on Boost unordered flatmap, but it has

7:56

some very interesting innovations in particular

7:58

how they do.

7:59

There's multiple levels

8:01

to it.

8:02

On the container level, there's a read-write mutex

8:05

for which you can lock for write

8:07

access only if you have whole container

8:09

operations like rehashing or swap or

8:11

assignment. And then

8:14

one level lower, you

8:16

have each group inside the container has

8:19

a dedicated read-write spin lock to

8:22

control access to its slots. And there's lots of clever machinery how

8:25

it's all designed, and it's a detailed

8:27

blog post describing all this. So I thought

8:29

that was really impressive.

8:30

The other thing that I thought was really impressive is that that

8:32

blog post has benchmarks where

8:34

they compare that concurrent

8:36

flatmap to two other implementations, one

8:38

by TBB and one by GTL.

8:41

And it looks to me that Boost's concurrent flatmap

8:44

seems to outperform both of them,

8:46

which

8:46

is also very interesting.

8:48

Yeah, if you're into concurrent programming,

8:51

it's a really cool blog post. They kind of describe

8:53

the strategy, how they do the synchronization in

8:55

an effective way.

8:57

That's pretty cool. Yeah,

9:00

I didn't look at the specific library you mentioned

9:02

here, but we don't talk

9:04

about Boost that much these days, or

9:07

both on the show and maybe in the community as well, but

9:09

it's still going strong.

9:11

Obviously, its role has changed a bit. It used to be,

9:13

well, it still is to some

9:15

extent, a breeding ground for libraries

9:18

that may make it into the standard, although

9:21

not as much as it was back in the early days when

9:24

a lot of the libraries made it into C++11.

9:27

And these days, I think it's sort of, for those

9:29

that

9:30

didn't make it onto C++11, it

9:33

became a bit of a polyfill library for

9:35

some of those libraries. So it's interesting

9:37

that support for C++03 is finally

9:39

going away. I was actually surprised that it's still there.

9:42

Yeah. So that's a bit of a milestone. Yeah,

9:44

they have a lot of libraries

9:46

in there, which are things that we have

9:49

since C++11 or 14 or 17, like

9:52

Boost Any or Boost Variant, and there's

9:54

a whole bunch of them that

9:56

we now have in the standard. So they're actually not

9:58

only dropping support for C++03, but they're

10:00

also dropping support for all of those libraries. Yeah.

10:02

Because you kind of don't need them anymore.

10:05

They were useful as backports of all of these

10:08

features to C++ all three, but

10:10

now that they don't support

10:12

that anymore, they're basically saying, well, just

10:14

use the standard version. Yeah.

10:16

And of course, the older versions will still be around for those

10:18

that are stuck on C++ all three.

10:21

All right. So that's all the news

10:24

items I have for today. So we

10:26

can move on to our main guest and our main topic.

10:28

Bjarne, welcome again to the show. Yeah,

10:30

hi. How are you doing today? Doing

10:33

all right. I'm

10:35

out of New York for the summer. I don't

10:38

like New York summer with us. So I'm sitting

10:40

back in my hometown of Aarhus in

10:42

Denmark, where I have

10:45

peace and quiet and can get some work done.

10:47

Nice. Yeah, that sounds great. Yeah, we were actually

10:50

saying before we hit the record button that,

10:52

for us in the UK, I'm in Finland and you're in Denmark.

10:55

So you're kind of right in between us geographically.

10:57

So what

11:00

you want to talk about today with you is

11:02

a bunch of things. But I would like to start

11:04

with this topic of safety and security in C++, which

11:07

a lot of people have talked

11:10

about this last year and this year.

11:13

There were a bunch of conference talks given

11:15

on the topic, lots of papers

11:17

being written. So it is a really hot topic

11:19

in the community right now. But

11:21

one thing that I found interesting is

11:23

you published a paper back in December 2022, P2739, a

11:25

call to action, think

11:26

seriously about safety, then

11:31

do something sensible about it.

11:33

And that paper did receive

11:36

some criticism in the community. But

11:38

I think some aspects of the paper were kind of misunderstood,

11:41

maybe.

11:42

And I actually think there's like some

11:44

really great ideas in there. So I kind

11:46

of just thought it would be cool to invite you to the show

11:48

and talk

11:49

a little bit and a little bit more detail about

11:51

your work there and what the idea is and how that

11:53

can lead us to more safe and secure

11:55

C++. Yeah.

12:00

Software is everywhere and

12:04

that means it's deep in our critical

12:06

infrastructure. And obviously

12:09

the security guys are very interested

12:12

in that. Obviously people

12:14

who enter reliability is

12:17

very interested in

12:19

various forms of safety. And

12:22

I've been working on this for a

12:25

long time. I was

12:28

the major

12:30

person involved in generating

12:33

the GSF++ guidelines

12:36

for writing flight software for

12:39

fighter planes. Where safety

12:41

is a rather important thing. And

12:44

that was

12:46

in the early 2000s and I've

12:48

been working on and off for this for

12:51

ages. And of course part

12:53

of the original inspiration of

12:56

C++ was to get something

12:59

that was easier to write and harder

13:01

to make mistakes at than C.

13:04

So we got classes and

13:06

made smart pointers and containers

13:08

and that kind of stuff. So

13:11

I've been working on a gradual progression

13:14

towards a more

13:16

type safe language

13:18

and more productive language

13:20

at the same time. By emphasizing

13:22

abstraction. And my

13:26

call to action was that

13:28

I thought that the C++ Standards

13:31

Committee

13:32

was

13:33

not focused well enough on

13:36

that aspect of C++. A

13:38

lot of people were trying to improve

13:40

their own little corner of the language,

13:44

ignoring the big picture.

13:47

And so I wanted the big picture in

13:49

place for which safety

13:52

for some definition of safety is important.

13:55

But also the usual

13:57

engineering balancing of concerns.

13:59

And so

14:03

that was it. And I followed

14:05

up together with Gabby Dus Reyes

14:08

with discussions of how you

14:10

could get a

14:11

safer C++

14:14

aiming at a very fireably safe

14:17

C++

14:19

which led

14:22

to the work on profiles

14:24

which says specify what you

14:26

mean by safety and

14:28

then find ways

14:31

of enforcing that kind

14:33

of safety in the language. The

14:36

assumption here, the fundamental assumption

14:39

is that safety is not one thing.

14:41

It's a variety of things. My

14:44

favorite of course is the usual type and

14:46

resource safety. Notice the resource.

14:49

It's not just type safe. If

14:51

you leak resources, your system stops.

14:55

That's not a good idea.

14:56

So we need both type safety

14:59

and resource safety.

15:01

We don't leak. And

15:03

there's some design for that and they've been prototyped

15:07

in the core guidelines which you can

15:09

go and use. It's not

15:12

perfectly implemented

15:14

partly because people haven't focused on

15:17

it. And one of the reasons for my call

15:19

to action was I wanted people to focus

15:22

on it. We need improvements in

15:25

type safety. We need improvements

15:27

in containers. We need improvements

15:29

in particular in static analysis

15:32

which is needed for getting

15:34

very

15:35

fireably safe code

15:38

without runtime overheads. In

15:41

particular, we have to eliminate dangling

15:45

pointers. And you can

15:47

go back in the last

15:48

five to eight years, you can find talks

15:51

by me on this

15:54

particular topic. So there's nothing

15:56

new. We didn't start yesterday because somebody...

16:00

was interested in safety. We've

16:02

been there for a long time.

16:05

So you talk about a type and

16:07

resource safety

16:08

and usually when we hear

16:11

safety and safety I've talked about particularly

16:13

in the NSA and the Consumer Reports

16:15

articles,

16:16

the focus has been on memory safety which I presume

16:19

is a subset of resource safety? Memory

16:23

safety is a subset of type

16:25

safety and resource

16:27

safety.

16:29

Basically you want to guarantee

16:31

that every object

16:33

is used only in accordance

16:38

to the type it was defined with. So

16:40

if you can have a range

16:42

overflow

16:44

then I can manipulate your object

16:47

out there through my interface,

16:50

usually by accident.

16:51

So if you have a dangling pointer

16:54

you update

16:56

something or read

16:58

something that's just

17:01

not there anymore. Something else might

17:03

be there

17:04

and you can mess up things. This has to be

17:06

eliminated and it can

17:08

be eliminated with a combination

17:12

of making sure that you

17:14

know where the pointer is pointed to.

17:17

The most important thing is that if

17:20

I get a pointer I

17:23

can return that back because if it

17:25

was valid I can return it back. Also

17:27

I can return a pointer that points

17:30

to something static or something allocated

17:33

on the free store.

17:34

That kind of stuff can be enforced and

17:36

then you have to enforce the invalidation

17:38

rules that you can actually find in

17:41

the standard places.

17:44

If I take a pointer to an element of

17:46

a vector

17:47

then do a pushback on the vector.

17:49

The vector might reallocate all the

17:52

elements. Now your pointer points to

17:54

something wrong. It's a dangling pointer.

17:57

This can be eliminated through static analysis.

17:59

and basically

18:02

it's called invalidation. So

18:05

the sum of these

18:07

kinds of concerns can guarantee

18:10

a complete type safety. And

18:13

since resource,

18:16

if you leaked resources, you can

18:19

do a denial of service attack, you

18:21

can have a real

18:23

controlling gadgets on

18:26

some kind of vehicle, just run

18:29

out of resources and stop. This

18:31

is unacceptable.

18:33

And I see that as part

18:35

of the enforcement of

18:37

real type safety. So

18:40

type and resource safety is what I'm aiming

18:42

for.

18:43

Memory safety is a subset

18:45

of that. It's

18:47

necessary, but not

18:50

sufficient.

18:52

And I'd like to emphasize that this

18:54

is not the only kind

18:57

of safety we're interested

18:59

in. If you're doing a real

19:01

time system and something

19:03

bad happens if you don't respond in a

19:05

millisecond, you have to have

19:07

some guarantees that things happen in

19:10

a shorter time than a millisecond. And

19:13

you can imagine profiles for other

19:15

things such as I'd like

19:17

to see a teaching profile, which

19:19

basically is type and resource safe,

19:22

but also stops you from

19:25

using weird features

19:27

of the language that you don't want your students to

19:29

get into so they really need to.

19:32

That is my sort of the professor

19:35

side of me is interested in that.

19:38

And the other thing is that you would like

19:40

your arithmetic

19:42

not to overflow in some contexts.

19:44

And that's another profile.

19:47

So in my paper together

19:50

with Gabby, we listed 10

19:53

profiles that are plausible. And

19:56

we would like the fundamental

19:59

ones like type and resource. resource safety to

20:01

be defined and directly

20:04

supported by the standard. Other

20:07

profiles are more

20:09

specific to a specific

20:11

domain or industry or company.

20:14

So it's an open set.

20:17

And I'm not the only

20:19

one thinking about profiles.

20:22

After talking about this for a while, somebody

20:24

came and said, have you seen that they

20:26

have something called profiles? And

20:32

that's actually one of the

20:34

languages that are most interested in

20:36

safety and reliability. And

20:39

you know, what they call profile is essentially

20:42

what you call profiles. So

20:44

we have a

20:45

case of sort of independently, not

20:48

only coming to the same concept, but

20:50

naming it the same. Now

20:52

I'm not totally ignorant of ADA,

20:55

but I didn't know that bit.

20:58

Yeah, that's interesting. So the paper you're talking

21:00

about is I think P2687, Design

21:03

Alternatives for Type and Resource Safe

21:05

C++. That's the one that

21:07

you co-authored with Garbi.

21:09

So it's a really interesting paper.

21:12

So

21:13

from what I understand, I think this is something that took me

21:15

a while to understand

21:17

is these profiles that you want to introduce,

21:20

like, I don't know, a performance profile or a secured

21:22

profile or a teaching profile. They're

21:24

not actually

21:25

dialects of C++, right? So

21:27

the same code would mean the same thing

21:30

in all of the profiles. But the trick is

21:32

that,

21:33

like, in some profiles, some code would be

21:35

considered

21:36

ill-formed, not valid, because a static

21:39

analysis tells you that you can't do that in

21:41

this profile. Is that more or less the idea? I

21:43

wouldn't use ill-formed. They're just not part

21:46

of that profile. If you use

21:48

something that's not part of the profile, the

21:50

shaker will say, don't do that.

21:53

Try and dereference a null pointer.

21:56

No, don't. So

21:58

here's

21:59

the one million dollar.

21:59

question, which I think people

22:02

don't really know the answer to, I think is,

22:05

but maybe you do. So I'm really curious if

22:08

you take C++ with, you know, all the

22:10

UB it has, like one other definition of

22:12

safety that a lot of people like Sean Parent use,

22:14

and I also use in my

22:16

CPP-OnC talk is,

22:18

safe code is like when you don't

22:20

have unbounded undefined behavior.

22:22

Right? So that's one

22:23

way of looking at it, which I think overlaps a little bit

22:25

with your definition. Your definition is, I think, wider,

22:28

but also I think excludes things like

22:31

race conditions and threat safety. It

22:33

seems like that's a bit of a different thing,

22:36

but maybe not. I don't want to put words in

22:38

your mouth,

22:39

but question is, can we actually

22:43

eliminate all the UB by placing

22:45

constraints on the language, like making a subset

22:47

of C++

22:48

by rejecting certain things with

22:51

a static analysis tool

22:53

and then still be left with a subset of language

22:55

that is expressive enough and useful enough

22:57

to do

22:58

real world programming? That's

23:00

something that

23:01

people don't agree with what the answer

23:04

to that question is. I know. A

23:06

lot of people base

23:08

their agreement or disagreement on

23:11

some specific view of C++.

23:14

Like a lot of the criticisms is of

23:16

the mythical language C slash C++, which

23:20

says C slash C++ is unsafe,

23:23

you shouldn't use it. And the examples

23:25

by and large is on C,

23:28

the way we wrote it 30 years ago,

23:31

not using

23:31

the facilities. Now, whether

23:34

we can eliminate all of

23:36

undefined behavior without imposing

23:39

runtime overheads

23:42

is indeed an open question. But

23:44

the reason it's open is not the reason

23:47

people usually think. The point

23:49

is that UB has been used

23:52

in the optimization pipelines.

23:55

And so there's very often not

23:58

one place you can say, well,

23:59

Well, if you reference a pointer, we

24:02

can stop that by looking there

24:04

and only there. It's

24:07

sort of the various optimizing

24:10

passes has different views.

24:13

So I think

24:15

we can do it, but it's a practical

24:17

issue of how we can do

24:19

it in existing implementations. And

24:22

existing implementations have different

24:24

constraints. So when we go

24:26

into the standard

24:29

discussions, different

24:32

compiler vendors will have different

24:34

opinions. And that's where the difficulty

24:36

is.

24:38

Clearly, anything

24:39

that provides

24:41

a guarantee cannot have

24:43

you be doing time travel

24:46

up to elimination of tests.

24:49

So

24:50

you can't have a safety plus

24:52

plus without range checking.

24:54

And so the recommendation

24:57

is don't ever dereference

25:00

a raw pointer. Use

25:02

a span or a vector or something

25:04

like that and make sure that is range

25:07

checked. The original span in

25:10

the core guidelines support

25:12

library has checking

25:15

and that's the right thing

25:18

to do. Disappeared when it got standardized,

25:20

but we have to

25:22

get the original back. Similarly,

25:25

if we go for contracts

25:27

which can help in some areas,

25:29

we have to make sure that you cannot eliminate

25:34

a contract check.

25:35

But these are practical problems.

25:38

This is engineering, not math. If

25:40

it was just math, we have the answer. We

25:42

know that. I

25:45

think I could prove it. That's

25:47

the math part. Can I implement

25:49

it? Not by myself. It involves

25:53

quite a few people that works on

25:55

compilers and they have constraints.

25:58

One of the reasons I talked about.

25:59

A performance profile

26:02

is that there are people who really want

26:04

these very unsafe features because

26:07

they claim that is key to

26:10

their performance.

26:11

I'm not sure if they're right, but I'm

26:14

sure that they write software that's important

26:16

that depends on that assumption. And

26:19

we can't just throw that away and say, okay,

26:21

everything has to be safe. Everything

26:24

has to conform to

26:26

our current definition of safe

26:29

code. Well, there's billions of

26:31

lines of code out there. There

26:33

are techniques and tricks that people

26:36

swear by for delivering important

26:38

products. And you know, if we

26:41

put a constraint in place, we

26:43

should also have a place where the constraint is

26:45

not enforced. If you are

26:47

writing a piece of safety critical software,

26:50

obviously you wouldn't use that profile,

26:53

you have to guarantee that that profile

26:55

is not there.

26:56

You use

26:58

the type and resource safe

27:01

profile for starters, possibly

27:03

the arithmetic profiles that

27:05

takes care of overflows and that kind of stuff.

27:08

But there has to be an escape clause

27:10

for people who are

27:12

writing an isolated system. If

27:14

you're not connected to the web, or

27:16

if you're connected to the web through a

27:19

certified safe module,

27:21

you can start doing things that you wouldn't

27:24

do is sort of in public.

27:26

And also this is this has

27:29

also to do with a gradual introduction

27:31

of this stuff. These billion lines

27:33

of code, I think I've never

27:35

seen a piece of code that couldn't be improved. But

27:39

it is very hard to

27:41

take a whole system

27:43

and fix it at

27:45

once. You

27:47

have to take this library now that

27:50

library now that piece of code now,

27:53

some has to be rewritten.

27:54

And others have to be carefully

27:57

used, like you can use an unsafe.

27:59

libraries through a safe interface, for

28:02

instance, so that you never feed it

28:04

bad pointers or bad data. Put

28:07

a checking interface in the place and you can use

28:09

the old code, things like that. That's

28:12

the paradox, isn't it? Safe code has to be built

28:14

on top of unsafe code. Yes. At the end

28:16

of the day. After all, there's hardware down

28:18

at the bottom. And that's not reliable

28:21

either.

28:22

I mean, there's lots of work being

28:24

done on making

28:26

sure that the bad parts

28:28

of a batch of chips is

28:31

not used. The chips are still there,

28:33

but the compiler, the really

28:35

low-level stuff in the compilers

28:38

from Intel, AMD and such,

28:41

simply dodges bad parts.

28:44

At that level, you don't have

28:46

the safety that the mathematicians dream about.

28:50

You write a spaceship software and

28:52

you get hit by a cosmic array. You

28:54

just have this big deciding that

28:57

it's always wanted to be a one. It's

28:59

never going to be anything else. Whatever

29:01

you say, you can't convince it

29:04

to be zero again.

29:06

And it's halfway to Mars. You can't

29:08

send a repairman.

29:10

So the

29:13

fact that there are unsafe,

29:15

unreliable things is a fact. We

29:18

built reliable systems out

29:20

of unreliable parts. It's

29:22

one of the beauties of the system. It's

29:25

also a thing that gives bloat

29:27

if you don't do it right. Because

29:29

then you put layers upon layers

29:31

and you have to pay for those layers even

29:34

if nothing

29:36

ever happens.

29:37

Or if something happens every once

29:40

in a while, you have

29:42

to do better than that. One

29:44

point I wanted to pick up on is that

29:47

I work for Sonar, so we do static analysis tools.

29:49

I've talked a lot about static analysis.

29:51

When you're talking about using static analysis here, you're

29:54

talking about using existing tools

29:56

like SonarLint or we need to build

29:58

something new for this. think you need

30:00

to build something new. I have

30:03

not used your stuff directly. I've

30:05

read about it. But so if I'm

30:07

making a mistake, it's

30:10

an honest mistake. And you

30:12

can correct me. But

30:15

we cannot prove

30:17

arbitrary C++ code correct

30:20

statically. That's impossible.

30:24

First of all, it's too complex. Secondly,

30:26

the algorithms for proving safety are

30:31

not linear.

30:32

There could be quadratic,

30:35

for instance. So it doesn't scale.

30:37

And anyway,

30:40

there's a halting problem. And that's

30:42

also the problem of like, if you have runtime

30:44

values, right, you read a number

30:47

from disk, and then you use that to index

30:49

into a container, right? That's true.

30:51

But I was doing it the fundamental

30:53

thing. So

30:55

to do static analysis, you

30:58

have to limit the language written to

31:00

something that can be analyzed. So

31:03

that's where the rules come in. And then

31:06

you have to make it feasible

31:08

to use the rules by providing

31:10

libraries so that you have alternatives

31:13

to the low level fiddling that you can't

31:15

verify. So my standard example

31:18

here is,

31:19

there's a lot of code out there that's pointer

31:22

comma size. And

31:24

the size is, as Timo pointed

31:26

out, a runtime value which can't be

31:28

verified. However, if

31:31

we use a span

31:34

instead of a pointer comma size, we

31:36

can, in many cases, make

31:39

sure that the size is correct, because

31:41

we got it from the compiler

31:44

from an array size.

31:45

And we therefore can

31:48

isolate the cases where

31:50

the size is runtime.

31:53

And we can actually use

31:55

a check to make sure it's correct. So

31:58

there's this three level style. in everything

32:01

I'm doing about safety. Static

32:03

analysis rules to

32:05

limit the language to something that can be

32:07

analyzed and then libraries to help

32:10

us actually write good code.

32:12

We don't want to go down to the lowest level.

32:14

And my feeling about static

32:17

analyzers is that for

32:19

good economic reasons they're focused

32:21

on finding bugs in arbitrary

32:24

C code.

32:25

And that's a hard job but it's a different

32:28

job from verifying a set

32:30

of rules for using

32:33

C++.

32:33

And I believe it is an easier

32:36

task

32:38

and we can make it easier by better libraries

32:41

and different rules.

32:43

But it is new and it

32:45

is somewhat different from

32:47

what we have. In the core guidelines

32:50

it's not just safety.

32:52

We go after all the things

32:54

like bad code but that's

32:57

a distraction in the connection of safety.

32:59

So, Bjarne, can I just drill down

33:02

into this a little bit more or less. So you gave a good

33:04

example about the range checking with the span

33:06

if you have like a

33:08

range bounce check span. But there

33:11

are examples it seems to me where we can't

33:14

get away with this approach without actually modifying

33:17

the language mechanics. Like for example unique pointer.

33:19

Unique pointer is reasonably more safe than

33:21

row

33:22

pointer. But

33:24

it has some bits where you get like a row

33:27

pointer back like .get or .release

33:30

I think which we can say don't use those.

33:33

But then it also has

33:35

like operator arrow. Like how do we do anything

33:37

with the object inside? Like anything at all.

33:39

You need to use operator arrow and that gives you back

33:41

a pointer. So in order to

33:44

make that safe you have to actually change how

33:47

pointers and references and operators work.

33:49

So you would introduce a breaking change to

33:51

the language or maybe I'm missing something.

33:53

I'm saying no here. Okay, I'm

33:55

very curious about like how to make that safe.

33:57

The point is... As

34:00

I pointed out before, that you

34:03

have to check pointer, pointers

34:05

being used and leaking and such.

34:09

And what I recommend

34:11

doing is actually a static analysis

34:14

to make sure that you don't

34:16

retain

34:17

and use a pointer that

34:19

you got from the unique pointer

34:22

after the unique pointer has

34:25

gone out of scope or things

34:27

like that. So you can do a lot

34:29

with static analysis there. So

34:32

what can you do today

34:34

if you don't have that?

34:38

You can actually build safer

34:41

versions of the standard library.

34:43

I have not tried with unique pointer,

34:46

but you could imagine a unique pointer

34:48

with some serious restrictions

34:51

on get. But I've tried

34:53

it with vector. What

34:56

happened

34:56

in some very real code

34:59

is that people have a vector,

35:02

they pass it to another thread

35:04

and then somebody does a pushback

35:07

that relocates. And

35:10

one of the two versions of

35:12

the

35:13

vector is now invalid.

35:16

And we didn't have the static analysis

35:19

software to prevent that. I

35:21

think I can explain how this can be avoided.

35:24

I think it's under the

35:26

rules of the core guidelines, it can be

35:28

completely avoided. But

35:30

we didn't have the static analysis software. So

35:33

what do we do? We build a vector that

35:35

in array, that's also

35:38

in the GSL support

35:41

library,

35:42

that simply doesn't have the

35:45

invalidating operations. So

35:47

I can give you a pointer,

35:49

but you can't do a pushback.

35:52

And if I made it as a

35:56

dinner array as opposed to a vector, then

35:59

I can do a pushback. I can't do any validation

36:01

either if I don't trust my own software

36:05

to follow the rules. And

36:07

the bug went away. This

36:11

happens repeatedly. It was very

36:13

subtle bugs and they went away.

36:16

Similarly, there has been subtle

36:18

bugs in large code bases for

36:21

intercomer size that when

36:23

changed to span, TSL span, they

36:25

were caught.

36:29

So you can make significant

36:32

improvements without having the

36:34

full profile stuff.

36:36

And I'm actually thinking about now what

36:39

can be done as a subset

36:42

of the core guidelines, a subset

36:44

of the profiles, which we could

36:46

call profiles light that

36:49

can be

36:50

implemented without

36:53

serious static analysis. Perfection

36:57

requires static analysis. But hey,

36:59

we're engineers. What

37:01

if we could get almost all of it

37:04

without going in that direction? It

37:06

wouldn't please the

37:08

NSA, but

37:11

it would please a lot of people

37:13

who has the right reliable software. You

37:16

can reduce that kind of bugs. And

37:19

so I'm wondering, can we build

37:21

something profiles light

37:24

that

37:25

takes the low hanging fruit, takes the thing

37:27

that are compiled, I can do with its current

37:29

knowledge of code and

37:31

eliminate the problem.

37:33

And that takes some thought. It's

37:36

very preliminary,

37:38

but I realized that it will take too long

37:40

to get the full blown profiles

37:43

in place for a lot of people. They want the

37:45

solution now.

37:47

So how do these profiles differ to

37:49

something like just adopting

37:51

an existing safety critical standard

37:53

like Misra, for

37:55

example? Because something

37:57

like Misra traditionally forced.

38:00

is you to write low level code.

38:02

And secondly, it doesn't provide

38:04

guarantees. It is more

38:08

like when I talk about Profiles Light,

38:11

that is, it takes away some

38:13

problems. But traditionally, it

38:17

forces you to write C-like

38:20

code.

38:22

There's some good work being done on concurrency.

38:25

I'm actually in a meeting about that

38:27

tomorrow. No, Thursday.

38:30

But about

38:33

getting concurrency rules in that

38:35

will be joined to a mincore guidelines.

38:39

And so what

38:42

I'm talking about here, safety is not

38:44

the only thing and safety is not my only

38:47

focus. Of course, yeah, we will we

38:49

will dig into some other things after our

38:51

sponsor break, I think I should just want

38:53

one more question before we break for our sponsor.

38:55

While we're talking about making C++ a safer

38:58

language, what do we think about some of these so called

39:00

successor languages,

39:01

like carbon, CPP to vowel? Yeah,

39:04

first of all, I say I'm actually aiming

39:07

for making C++, use

39:09

of C++ safe,

39:11

not just safer, provably

39:14

guaranteed safe. That's what we're

39:16

aiming for. Not for all

39:19

code. Secondly,

39:21

there's always been one of the successor

39:24

languages to C++. Remember

39:26

Java?

39:28

There's been dozens.

39:32

I think the

39:35

current one of these successor languages

39:37

are born out of various

39:39

forms of frustration, partly

39:42

that the C++

39:45

Standards Committee has a trouble focusing

39:48

and has trouble delivering

39:50

things quickly. And if it

39:52

delivers things quickly, they'll probably get

39:55

a lot of things wrong. It's 200, 300, 400 people.

40:00

trying to agree to things, that is

40:02

difficult. And I think a lot of the frustration

40:04

comes from that. The other thing

40:06

is that people always

40:09

can do the obvious, which is

40:12

simplify the language from my use.

40:15

And then later

40:18

it has to grow and get the facilities

40:22

for the full range of things. When

40:24

Java came out to

40:27

take over the world, I predicted

40:29

that if it succeeded, it would grow

40:31

by a factor of three.

40:33

I was right. And

40:35

it got better for it. But the claim

40:38

that you always get from new languages, this

40:40

is simpler. Look, all of this stuff in C++

40:43

you don't need.

40:44

Well, wait and see. A

40:46

lot of the things are there because

40:49

there was a need for it by a sizable

40:52

community.

40:53

I think C++, in C++,

40:55

we got the

40:58

major issues right.

41:00

And in retrospect, 10, 20, 30, 40 years later,

41:04

we could probably get all the details better, but

41:07

the fundamentals are still right.

41:11

So it sounds like you're fully committed to

41:13

making C++ a safer

41:15

and simpler language.

41:17

It's great. Yes, you can't simplify the

41:19

language because of compatibility constraints.

41:22

You can simplify the use of the

41:24

language. This is a very important distinction.

41:27

Right.

41:27

In the meantime, there are plenty of pitfalls

41:30

and headaches. So that's a good segue

41:32

to our sponsor break

41:34

because this episode is supported by JetBrains.

41:36

And JetBrains has a range of C++ IDEs to

41:39

help you avoid those typical pitfalls and

41:41

headaches that are often associated with coding in C++,

41:44

at least for now. Exclusively for

41:46

CPP Cast, JetBrains is offering a 25%

41:48

discount for purchasing

41:50

or renewing a yearly individual license

41:52

on the C++ tool of your choice. That's

41:55

one of C-line, ReSharper, and ReSharper

41:57

C++ or Rider.

41:59

Use the coupon code JetBrains for

42:02

CPPcast or one word during

42:04

checkout at JetBrains.com.

42:06

All

42:06

right. Thanks, Phil. We are back here

42:08

with Bjarne.

42:10

And Bjarne, when we talked about, you

42:12

know, what you want to chat about in the episode today, you said

42:14

that, you

42:15

know, safety and the things that people

42:18

typically talk about in this context is not

42:20

the whole picture, right? And also

42:23

like features like that

42:26

we add to the language, which don't seem, you know,

42:29

at first glance to be directly safety related are actually

42:32

part of the picture as well.

42:34

So you said we could talk about modules

42:36

and concepts and the C++23 standard, which is

42:39

now kind of our current one

42:41

in that context. So what are your thoughts on those?

42:43

Okay. First, I'll just add

42:46

a little bit in connection with your sponsor

42:48

comment.

42:50

Organizations like JetBrains

42:52

and Sona and such, because

42:54

they have a lot of analysis ability,

42:58

are actually important in the context

43:00

of something like core guidelines and

43:04

profiles in the future, because

43:06

that's exactly the spot where

43:09

you can make improvements. And

43:11

also ClangTidy

43:14

and Microsoft's Analyzer.

43:16

This is an area that I

43:19

think is immensely important.

43:21

Anyway, back to your question.

43:24

There's more to

43:26

engineering good systems than safety.

43:30

There's also performance.

43:32

There's also

43:34

reliability in general, which

43:36

is system property. You can write safe

43:39

programs that happens to give the wrong result.

43:42

The old saying, if I don't have to give the right

43:44

result, I can make it as fast as you like

43:46

and as safe as you like. No problem.

43:49

So it's an engineering thing. We have to

43:51

balance trade-offs. Some

43:53

areas are more

43:55

critical for certain aspects,

43:58

other areas for others.

44:00

And so we also need a

44:02

language that is expressive

44:05

and has good

44:07

abstractions for writing code. And

44:10

the C++ approach has always been

44:13

not

44:13

to solve a particular problem,

44:16

but to provide abstraction

44:18

mechanisms to allow you to solve

44:20

your particular problem and me

44:22

to solve mine. And

44:25

it's that kind of openness and

44:28

focus on generality that

44:30

is actually one of the greatest strengths of C++. And

44:34

then you add performance to

44:36

the

44:36

mix and you get this notion

44:39

of zero overhead abstraction, which

44:41

I think is key. And if you look

44:44

at modern C++, C++ 20, C++ 23, you get a very

44:46

different language from C or C++ 03, as you mentioned earlier.

45:00

And we should encourage people to use it.

45:03

And the way you encourage people

45:05

to use it is to demonstrate that it

45:07

actually makes sense. And

45:09

I think for C++ 20,

45:12

the important things were modules,

45:15

concepts, and coroutines.

45:18

Coroutines lacked library

45:20

support and it's coming,

45:23

but not as fast as I would like. But

45:25

remember, coroutines was what kept C++

45:27

alive for 10 years. So

45:31

Sun decided you didn't

45:33

need it for a general view,

45:35

including me. I was very unhappy

45:37

about that.

45:38

Anyway, I won't talk much about the coroutines

45:41

because of the lack of the library

45:43

support. But I'll talk about

45:45

the other two.

45:47

I proposed a

45:49

module C++, a

45:52

module STD that

45:56

gives you basically the whole standard library

45:58

as a module. to

46:00

try and demonstrate that

46:03

you could afford to just grab the whole standard

46:05

library and that

46:07

it is so pleasant. I've been writing a lot

46:10

of code recently using module.cd

46:12

and it is so pleasant.

46:14

I don't have to write, I don't

46:17

have to start with 10 or 20

46:20

includes. I don't

46:22

have to worry about the includes messing

46:25

with each other. I don't have to remember

46:27

in which

46:28

in which header file shared

46:32

pointer is. Yes, I know what it

46:34

is, but take a student. They

46:37

don't know what it is. Take an

46:39

experiment with interesting parts

46:41

of C++ and you don't remember where all

46:43

those library facilities are. Recumulate.

46:46

Import ACT it works and

46:48

it's so much pleasure and the

46:51

question about this was not whether it

46:53

would be nice because obviously it is. The

46:56

question was can you afford it and I

46:58

did some small experiments

47:01

showing that it's about 10 times

47:03

faster to actually

47:06

know it's much more than 10 times faster.

47:08

I think it was 80 times faster.

47:11

To import the

47:13

whole library then to just include

47:15

STD, include IO streams.

47:18

And I did some experiments

47:20

with taking all of my favorite,

47:23

the most frequently used

47:25

libraries, about 10 of them and including

47:29

those or importing the

47:31

whole library and

47:33

advantage in compile time was only

47:35

five times. Only

47:37

five times. But it's still good. It's

47:40

if you have a server farm for

47:43

doing your compilations, it

47:45

means that you can you can sort of retire

47:48

half or more of your processes. I

47:51

mean tell that to people who want

47:54

office space and floor space

47:56

in critical places. They

47:58

really love it. It's one of them.

47:59

the arguments for C++ and

48:02

for modern C++ is you

48:04

don't use as much electricity.

48:06

And then, then I've used it for,

48:09

for real for half

48:11

a year or so. And it,

48:13

it also seems to scale.

48:16

I write relatively small programs

48:19

just now, but the response

48:21

time is, is not really better.

48:24

And if you go to larger

48:27

systems, you can get all

48:30

kinds of stuff that you didn't

48:32

expect with side effects. Like

48:34

I had a graphic system that, that's

48:38

fine. Everybody's got a graphic system and

48:42

my code started breaking. I

48:44

was using Macs from

48:47

the standard library, but

48:50

somebody used the, somewhere

48:52

deep in the header files for the graphic

48:55

system, there was the, the,

48:57

the, the, the Unix, Linux

48:59

Macs, which was different.

49:02

And that kind of problem

49:04

you can eliminate. And so

49:06

I think modules are important in that

49:08

we can have

49:10

logically defined chops

49:13

of a system defined like

49:16

the graphic system or the standard

49:18

library. And so I can imagine

49:21

building million lines

49:23

of code in including

49:26

maybe five, five modules,

49:28

which are the standard ones. I could even make

49:30

a module out of those five modules.

49:33

So that for the project, you

49:35

have the import project

49:38

and all of these interference problems

49:41

will either disappear or they will

49:43

have been dealt with when you created that module.

49:46

And yes,

49:48

it beats a precompiled header is also,

49:51

this is not

49:53

theoretical. There was

49:55

a really good talk

49:58

in CPP con. in 2022 by...

50:05

Was it Daniela Ingeld? Daniela

50:08

Ingeld. I've been recommending

50:10

that a lot because she shows

50:12

really what you can do with modern C++.

50:15

It should be shown to all of the people who think

50:18

it's a minor variant of C. That's

50:20

a great talk. It's a great talk.

50:23

I strongly recommend it. I've put a link in

50:25

the show notes. Yeah.

50:28

And that was, of course, using

50:30

modules. And it used

50:33

a lot of... a fair bit

50:35

of concepts also. I mean,

50:37

concepts

50:39

are the part of the template

50:41

design that I couldn't do in 88. I

50:44

mean, I wanted three things. It's

50:47

very clear.

50:49

Generality, no

50:51

overhead runtime, and

50:53

decent interfaces. I mean, I

50:56

was the one who got type

50:58

checking in to see that the original

51:02

decorations didn't have argument types

51:05

in them. And so I knew

51:08

the importance of that even back in the darkest

51:10

stages. And I couldn't

51:12

do all three.

51:13

I asked around practical

51:16

people, to academic experts, and

51:18

such. Nobody knew how to get all three. And

51:21

now we have all three. So we can actually

51:23

write generic code the way it was supposed

51:25

to be written. And I'm quite

51:27

sad when people write a lot

51:29

of code that's template class

51:32

T or template type diff,

51:35

T or type name T. It's

51:37

just old. It's like writing with

51:40

void star pointers. We see

51:42

it in standard library. It has not

51:44

been properly integrated yet into

51:47

the language in the way that it could

51:49

be.

51:50

And we should do much more of it.

51:52

It gets much better. And of

51:55

course, it compiles faster,

51:58

because it catches errors. And

52:01

again, it takes time to get something

52:05

into the ecosystem. People have to learn

52:08

that concepts is

52:10

the right way of specifying a template

52:14

in almost all cases. And

52:16

that there are benefits from it.

52:19

Implementers has to emphasize

52:21

it in their error messages. That hasn't

52:23

happened yet. They still

52:25

think that you want as much information

52:28

as possible when you make a mistake.

52:31

No, I just want to know that

52:33

this function couldn't

52:36

be called because that type

52:38

didn't match that concept.

52:42

The prototypes that we

52:44

built ten years ago could do that. And

52:47

there was a switch that said, I want all the other

52:49

information. But the default

52:51

is you just tell us a type error, a

52:54

concept error. And

52:57

I think all the libraries should be like that.

53:00

And sort of the best interfaces

53:02

also comes from defining, I

53:05

want to sort anything sortable

53:07

as opposed to I want to

53:09

sort a specific type. That

53:13

way you avoid a number of indirections

53:16

for performance reasons. It

53:19

doesn't handle the problems where you want a

53:21

binary interface.

53:23

But that's a different issue.

53:26

So if I may, I have

53:28

two comments. The first one is the talk

53:30

by Daniel Engert that we mentioned earlier is actually called

53:32

Contemporary C++ in Action.

53:35

So go and watch that one. The

53:37

second comment, I want to drill down a little bit

53:39

more into what you said about concepts.

53:43

So obviously I've been around

53:45

when concepts were standardized for C++20. And

53:48

I think they're a great feature.

53:50

And on the one hand, it seems like

53:52

not only do they make genetic programming

53:54

easier and more reliable, but

53:57

also they even enable...

54:00

libraries that you couldn't possibly write without

54:02

them, like something like ranges, right? It wouldn't be possible

54:04

without

54:05

concepts. And I think a couple of people have written

54:07

versions of it where it's done with like certain able

54:09

if and horrible macros, but that's not really

54:12

a

54:12

good way to do it. But

54:15

as amazing as concepts are,

54:17

I haven't really seen them catch on very

54:19

much in like the libraries that I use like

54:22

day to day. And I wonder why that is. Like

54:25

I heard, for example, one person saying that

54:27

they're very wary about introducing concepts through

54:29

the library because once you define a concept,

54:32

like you can never change it again. And if they got it wrong,

54:34

like,

54:36

then that's like a dead end. And so they're

54:38

like really wary of introducing them because you can't

54:40

ever

54:41

change them without breaking everybody's code.

54:43

Do you know if that's like a thing or if there's any

54:46

maybe other reasons why they didn't really catch

54:48

on in like day to day kind of library use?

54:51

I think we are seeing, by

54:54

the way, this thing about never being able to change

54:56

it again is based

54:58

on the assumption that every

55:01

piece of code uses every part of

55:03

the concept and that you have

55:05

control or none of the rest of the code,

55:08

which is not true even from the person

55:10

who gave that talk.

55:12

Anyway, a lot of it is

55:14

that people are expert and

55:17

knowledgeable about basically

55:20

the untyped template use

55:21

and they

55:23

like their little traits or

55:28

in the standard library

55:30

and they want to poison

55:33

the use of the ADL,

55:36

which they need if

55:38

they write untyped stuff so

55:40

that the concepts doesn't catch the mistakes.

55:43

And so people get

55:45

to love their bad old ways

55:47

of doing things. And I think

55:50

then they don't say,

55:52

I don't like this novel thing. They don't say, I

55:54

really love to do it

55:55

the old way and

55:57

I don't think that's a good idea. don't

56:00

want to change my code and look,

56:03

I'm clever, I can use enable if and

56:05

read that stuff, even if you can't, they

56:08

don't say that kind of stuff, right? They

56:10

find some aspects of the new

56:13

stuff that they don't really like

56:15

and they don't,

56:16

they know people don't really understand

56:19

or maybe we haven't reached

56:21

the point where it's well supported in the compiler

56:23

is like, I don't want to use

56:26

concept because the error messages don't

56:28

really get better. Well,

56:31

if the compilers haven't picked up

56:33

on it yet, the compilers and

56:36

error messages don't

56:38

get better. But we know they

56:40

can be better, because I did it 10 years

56:42

ago together, people

56:45

colleagues. So a

56:48

lot of this is like people

56:50

get in love with the C

56:52

declaration syntax,

56:55

which is obviously a mistake,

56:58

even Dennis Ritchie knew that a

57:00

year late, there

57:03

was a function of the size of the memory

57:05

and the technology of parsers

57:08

at the time, the year later, he could

57:11

have had a linear syntax, we

57:13

didn't have the problem where people get really,

57:16

really proud of being able to, to

57:18

understand this and write for instance,

57:21

a function returning a pointer to function

57:23

without using a type diff.

57:25

Oh, that always breaks my brain. Like, that

57:28

is why people are proud of it. If

57:31

I can do it, you can't I'm smarter than you

57:33

right? No,

57:36

no, no. It just

57:38

means I've been

57:39

locked up in some strange

57:42

world where that's surprising.

57:45

And I think some of that with enable

57:47

if and with with

57:50

on typed arguments to templates

57:53

is exactly that effect is

57:55

familiar and people are proud of being able

57:57

to do it. I think

57:59

like using the

58:02

requires clauses directly, is like

58:04

writing a Simply Code. Sometimes

58:06

you have to write a Simply Code, but boy,

58:08

it is very rare. People

58:11

who can write it gets orally proud of

58:13

being able to do it. I've

58:15

written a Simply Code. I was writing

58:17

Microcode for a while. I

58:19

mean, as simple as for WIPs, I've

58:22

been there, and I don't

58:24

really want to go back because

58:26

we can do so much better today.

58:29

I think we should really wrap up. Is

58:31

there anything else happening in the world of C++ that

58:34

you find particularly interesting or exciting?

58:36

Maybe look into the future.

58:40

I would like to see

58:42

static reflection in place. I

58:45

hope people will get the asynchronous

58:48

model sorted out. We've

58:50

been almost there several times, and

58:53

then people get a brand new idea, and

58:55

we get something brand new in three years

58:57

time. Those two features

59:00

are really good. We

59:02

have been almost there with

59:05

functional style pattern matching. Again,

59:08

people got new ideas and

59:10

now they're stored trying to

59:12

pick two good alternatives, between two good

59:14

alternatives. We should

59:16

focus a bit more and actually

59:18

deliver things.

59:20

Perfection is unobtainable,

59:23

but get something that's really good and

59:25

printable. I got the

59:27

impression that both pattern matching and static

59:29

reflection really got

59:31

set back during the pandemic. Not a lot of work

59:34

happened during that time. We suffered a

59:36

lot. When it comes to design,

59:39

Zoom

59:40

is not ideal. You really

59:42

want a few people, not

59:45

a lot of people, a few people in

59:47

a room with a whiteboard,

59:49

arguing it out for a word they are through. This

59:53

has happened again and again. Major

59:56

significant progress comes

59:59

out of a small number.

59:59

group of people locked up

1:00:02

in a room together with a whiteboard. It's

1:00:04

not the computer, it's not the large

1:00:07

number of people, it's people

1:00:10

with ideas working them out

1:00:13

together. Right. Well,

1:00:15

hopefully we will see some movement

1:00:17

on those fronts. Well, we are starting to,

1:00:19

I think, so hopefully that will

1:00:20

keep progressing. Looking forward to those

1:00:23

as well. Is there anything else you want to tell

1:00:25

us before we let you go, Bjorn?

1:00:28

Yeah, don't make statements about

1:00:30

performance without measuring. I

1:00:33

hear a lot of that, even

1:00:35

in the standards committee. That's

1:00:37

a good one. Measurement is, of course, hard

1:00:40

to do for things that should

1:00:42

scale, but

1:00:44

really people waving their hands saying

1:00:46

performance, efficiency, yeah,

1:00:49

I get very nervous. I want to see numbers,

1:00:52

and I want to see exactly what they measured.

1:00:54

All

1:00:55

right. Well, thank you so much, Bjarne, for being

1:00:58

on the show with us today. It was good fun.

1:01:00

I think a very great conversation.

1:01:02

Thank you so much again for being here. Thanks

1:01:05

for inviting me. See you around.

1:01:08

All right. See you. Have a great week. Thanks

1:01:12

so much for listening in as we chat about C++.

1:01:14

We'd love to hear what you think of the podcast. Please

1:01:17

let us know if we're discussing the stuff you're interested

1:01:19

in, or if you have a suggestion for

1:01:21

a guest or topic, we'd love to hear about that

1:01:23

too. You can email all your thoughts

1:01:25

to feedback at cppcast.com.

1:01:28

We'd also appreciate it if you can follow CPPcast

1:01:30

on Twitter or Mastodon. You can

1:01:32

also follow me and Phil individually on

1:01:35

Twitter or Mastodon. All those links, as

1:01:37

well as the show notes, can be found on the podcast

1:01:39

website at cppcast.com.

1:01:44

The theme music for this episode was provided by

1:01:46

podcastthemes.com.