Delivering Safe C++ - Bjarne Stroustrup - CppCon 2023

https://youtu.be/I8UvQKvOSSw?t=1

Transcrição

tactiq.io free youtube transcript

Delivering Safe C++ - Bjarne Stroustrup - CppCon 2023

https://www.youtube.com/watch/I8UvQKvOSSw

00:00:10.120 I'm going to talk about how to write C++
00:00:13.599 at safe for some definition of
00:00:16.239 safety and
00:00:18.960 um the general idea is um what what what
00:00:23.840 is safety what kind of safety are there
00:00:26.400 what do we need uh that's the first
00:00:28.720 quarter then I'm going to show you that
00:00:31.160 we've been creeping up on that uh for a
00:00:34.040 few decades it's part of the initial
00:00:36.840 aims of
00:00:38.200 C++ then I'm going to talk about how to
00:00:41.039 write good contemporary C++ under the
00:00:44.520 label of the C++ core guidelines and
00:00:47.520 then I'm going to talk about profiles
00:00:49.719 which is about how to guarantee uh
00:00:53.280 safety because guidelines and being
00:00:56.120 careful is not sufficient in all areas
00:01:01.199 um so one of the reasons there's so much
00:01:05.199 talk about uh safety is that uh parts of
00:01:10.159 the US government uh started going on
00:01:13.439 about safety which is quite reasonable
00:01:16.320 but uh they they're talking about the
00:01:18.920 whole Community which may or may not be
00:01:21.799 true and they're talking about the
00:01:23.439 mythical language
00:01:25.640 cc++ um which I have something to say
00:01:29.000 about anyway you can look it up this is
00:01:32.040 a serious concern that we have to deal
00:01:34.600 with on the other hand there's not no
00:01:37.799 reason to panic C++ is is doing well in
00:01:42.200 general thing I mean to measures noise
00:01:45.719 not usage but so these numbers doesn't
00:01:49.280 show precisely anything but it does show
00:01:52.920 that
00:01:54.119 uh maybe a billion or two people depend
00:01:57.719 on what we are doing so we better do it
00:01:59.680 well
00:02:01.560 well um so we we have to address the the
00:02:06.439 safety issue it's it's a real serious
00:02:08.758 problem I mean I I really don't want my
00:02:12.560 brakes not to work when I press it if I
00:02:15.360 had a car um and uh there there are
00:02:19.000 other things if you're in finances you
00:02:22.000 you don't want a uh a transaction to
00:02:25.560 disappear especially when it went if it
00:02:27.640 was going into your account and so um
00:02:32.440 there's a lot of aspects of this and uh
00:02:36.920 the interesting thing is that massive
00:02:38.680 Improvement really is uh is possible in
00:02:41.840 a lot of areas um one of my messages on
00:02:45.599 this talk is don't write c/
00:02:48.080 C++ uh write
00:02:50.360 C++ um we can do much much better than
00:02:53.800 some of the problems that has been
00:02:56.200 documented and um well if we we don't do
00:03:00.239 it somebody else will tell us what to do
00:03:02.599 and we'll like that even
00:03:04.519 less um so ignoring safety issues would
00:03:08.480 hurt the
00:03:09.680 community and offering guaranteed safety
00:03:12.720 will be in the best tradition of C++ so
00:03:15.200 this is actually an opportunity I mean
00:03:18.440 don't don't let
00:03:20.319 a a problem stop you from doing
00:03:23.280 something good so um the idea of
00:03:28.200 complete type and resources safety was
00:03:30.200 in C++ from the beginning uh simula was
00:03:34.560 one of the completely safe languages
00:03:37.879 except for the bugs I was pretty good at
00:03:40.200 breaking it um
00:03:42.560 but one thing that we know is
00:03:46.120 that we couldn't have complete safety um
00:03:51.159 with the hardware we had then and we
00:03:53.159 can't now for all languages and for all
00:03:56.120 uses but being careful doesn't scare so
00:03:59.159 we have to use judicious programming
00:04:02.159 techniques supported by Library enforced
00:04:04.920 by language rules and Analysis and um I
00:04:09.280 I wrote up a basic model for how to do
00:04:12.360 that a few years ago I actually
00:04:14.239 presented it here but not much happened
00:04:18.880 um we need it to be C++ that is there
00:04:22.960 shouldn't be restrictions on what we can
00:04:25.479 do um even though there might be
00:04:28.160 restrictions on how we do it and there
00:04:31.240 shouldn't be any decline in performance
00:04:34.680 uh this is C++ and actually some of the
00:04:38.520 techniques for writing safe codes
00:04:40.800 improve
00:04:41.880 performance um there I'm talking mostly
00:04:46.320 about what can be done by a compiler and
00:04:48.400 static checking because it is free or
00:04:51.280 actually gives improvements in
00:04:53.039 performance but of course you need range
00:04:55.600 checking to deal with things that cannot
00:04:58.520 be be dealt with with
00:05:00.560 statically and so basically I'm talking
00:05:03.840 about type and resource safety um and I
00:05:08.240 think this is pretty well defined every
00:05:10.360 object is access according to the type
00:05:12.759 with which it was defined that's type
00:05:15.400 safety uh and every object is properly
00:05:18.280 constructed and destroyed uh resource
00:05:21.160 safety uh you can manage resources that
00:05:23.800 way um if you don't initialize things
00:05:27.120 then you are breaking some rule and
00:05:29.800 every pointer either point to a valid
00:05:31.880 object or is a null pointer that's
00:05:33.919 memory safety um that's harder to
00:05:36.479 achieve but we can do it and a reference
00:05:39.280 through a pointer is not through the
00:05:41.919 null pointer that is we have to check
00:05:44.199 for null pointers before we go and D
00:05:46.479 reference these valid pointers um and
00:05:50.319 access
00:05:51.840 through a subscripted pointer is in
00:05:55.440 range that requires a runtime check and
00:05:59.120 I'll get get to that so basically this
00:06:02.319 is just what the rules require you read
00:06:04.880 the uh the standard and that's what it
00:06:08.039 requires read uh Dennis Rich's 45 page C
00:06:13.960 manual from 78 that's what it requires
00:06:17.759 it's just we haven't been doing it and
00:06:20.639 so the rules I'm putting forward here
00:06:24.199 are are more deduced than invented they
00:06:27.160 are deduced for what it takes to do what
00:06:29.639 on this slide and um enforcement rules
00:06:33.560 that I'm suggesting are mutually
00:06:35.120 dependent you can't just take one thing
00:06:37.680 out of context and expect to get a
00:06:41.120 easily specified benefit out of it uh
00:06:44.800 you you have to have a framework for
00:06:47.120 what you are doing to see what you are
00:06:49.639 planning to get out of it and um C++
00:06:54.199 still has to serve a wide variety of
00:06:56.960 uses in areas we have millions ions of
00:06:59.840 users and and billions of people relying
00:07:04.199 on us and one size doesn't fit all we
00:07:07.440 can't just say this is this is what
00:07:10.240 safety is everybody do it this way um
00:07:14.360 that that that doesn't quite work C++ is
00:07:17.080 also ass systems programming we um
00:07:19.960 manipulate Hardware in various ways we
00:07:22.680 use unusual Hardware that uh is is is
00:07:26.720 not known in the language specification
00:07:29.639 and we can't Outsource this uh to other
00:07:32.400 languages a lot of the so-called safe
00:07:34.840 languages Outsource all the lowlevel
00:07:37.520 stuff to CS
00:07:39.080 C++ so if we couldn't do it uh well
00:07:42.879 there would be C left uh and basically
00:07:46.240 but somebody has to do the dirty job
00:07:48.240 here and we can't break billions of
00:07:50.759 lines of existing code I say can't not
00:07:53.840 shouldn't because we can't if we try
00:07:56.919 people will use the old compilers they
00:07:59.120 will go to uh different subset they'll
00:08:02.080 just ignore us this this can't be done
00:08:05.240 uh and we can't upgrade the millions of
00:08:08.840 developers quickly it takes uh a long
00:08:12.360 time I keep bumping into people who
00:08:14.599 learned C++ from videos and books that
00:08:17.759 are 10 or 20 years old I mean it's
00:08:21.000 tragic but they could have it could have
00:08:23.280 been so much easier and the result could
00:08:25.400 have been so much better if they had up
00:08:27.599 to-date uh material teaching up toate
00:08:31.479 C++ but getting a whole Community like
00:08:35.399 this like this to move forward is much
00:08:38.479 harder than than most people IM uh
00:08:41.919 imagine okay these are
00:08:44.360 difficulties but we must improve and we
00:08:47.680 can so the challenge is is to describe
00:08:51.200 what we mean by type safe C+ plus use no
00:08:55.440 violations of the static type system no
00:08:57.640 resource leak if if a system leaks a
00:09:01.600 resource memory uh locks file handles
00:09:05.959 and such I I wouldn't consider it safe
00:09:08.959 because I can crash it with the
00:09:11.079 equivalent of a denial of service attack
00:09:14.680 or I could just be slobby and it crashes
00:09:17.519 when it runs out of resources so I'm
00:09:19.680 very keen on resource uh safety and this
00:09:22.959 is actually one of the things that came
00:09:24.680 into C++ on in the first two weeks and
00:09:30.000 uh we have to convince developers to do
00:09:32.440 this there's a lot of belief out there
00:09:35.240 that if you do grubby complicated
00:09:37.720 low-level stuff it must be
00:09:40.600 faster and furthermore I can write this
00:09:43.800 grubby low-level complicated stuff to
00:09:46.320 snow how smart I
00:09:48.880 am this does not work um we we have to
00:09:53.480 raise the level of of programming and
00:09:56.120 get this to work at scale I mean if I
00:09:58.600 have a class of students I can get them
00:10:01.120 to do what I tell them to because
00:10:02.720 otherwise they get a bad grade if you
00:10:05.000 are a manager you can get people to
00:10:07.160 write code the way you like it to
00:10:09.040 otherwise they don't get their pay rise
00:10:11.240 or they get fired but at scale we
00:10:13.760 actually have to convince people they
00:10:16.040 have to believe it's true and so that's
00:10:18.880 an important
00:10:20.600 thing and stability over decades matters
00:10:24.440 I mean the only reason people will
00:10:26.279 believe that the code they write today
00:10:29.160 will run in 10 years is that the code
00:10:31.959 that was written 10 years ago runs
00:10:35.360 today um and safety is not just type
00:10:38.320 safety
00:10:40.880 uh I think most of the areas I see are
00:10:43.880 logic eras I have seen a less than um
00:10:48.240 and equal where greater than was uh
00:10:53.120 expected and the cost was very
00:10:56.880 large uh and uh
00:11:00.079 if you if you want to prove that the
00:11:02.519 program does what exactly does you get a
00:11:05.320 a very restricted language uh there's
00:11:08.720 some Ada Ada code that goes in that
00:11:12.320 direction resource leaks I mentioned
00:11:14.560 that concurrency eras um we are doing a
00:11:18.360 lot of concurrency to be able to scale
00:11:21.240 our problems and such and we have to
00:11:23.639 make sure that this works you could
00:11:26.279 consider any uh concurrent error a type
00:11:31.560 violation
00:11:33.320 because the an object wasn't used in its
00:11:36.639 proper way but it's well worth
00:11:39.200 separating it out so that you can
00:11:40.839 analyze and address it directly uh
00:11:43.560 memory corruption we just have to
00:11:45.760 eliminate that uh type errors um if you
00:11:50.320 use low-level code with a lot of costs
00:11:53.120 and void stars and other um tricky stuff
00:11:57.720 like that void star star even worse um
00:12:01.600 we have to avoid that and timing errors
00:12:05.160 if
00:12:06.519 a response is needed in um
00:12:11.000 say uh 1.2 milliseconds then um that's
00:12:16.880 that's not if if if you are not on time
00:12:20.079 it's not good enough in a lot of
00:12:21.800 realtime control
00:12:23.760 applications and uh allocation on
00:12:27.240 predictability um there's aad on the on
00:12:30.600 the use of the free store in um in in
00:12:34.240 Flight software you cannot allocate
00:12:36.920 something after the engine starts and
00:12:40.160 you can't deallocate something at any
00:12:43.120 point because you might get
00:12:45.160 fragmentation and stuff like that this
00:12:47.839 means that separately managed chunk of
00:12:51.959 memories are very important in C++ all
00:12:55.160 the significant applications have
00:12:57.959 something on the side side where they
00:12:59.440 manage their memory themselves uh the
00:13:02.079 vector is the first and simplest example
00:13:04.560 we all using that it actually takes a
00:13:06.959 chunk of memory and manages it for you
00:13:10.399 uh and then termination eras I've dealt
00:13:12.800 with uh systems where termination is not
00:13:16.480 acceptable now if you have say 40,000
00:13:19.760 processes you have to take into account
00:13:23.040 that something will crash roughly every
00:13:26.120 day or at least every week and therefore
00:13:28.399 you can have a strategy that says well
00:13:30.639 if a processor has a problem just crash
00:13:33.639 it because we have written our software
00:13:35.360 to make it to work but what if there's
00:13:38.160 not such an extra thing what what if
00:13:40.920 you're not allowed to crash a friend of
00:13:43.880 mine pointed out that he was programming
00:13:46.680 um scuba controllers there's only one
00:13:49.480 processor in them uh no crashing is not
00:13:53.120 an option some Financial systems legally
00:13:56.079 you can't crash because you could lose a
00:13:58.240 transaction
00:13:59.480 and that's not allowed legal so um
00:14:03.120 there's many things here I'm sure you
00:14:05.320 could find another slide or half a slide
00:14:08.480 of examples of this kind of thing we
00:14:11.120 have to be able to say what is it we're
00:14:13.920 trying to do we're not trying to do
00:14:16.360 everything everywhere because that is
00:14:19.480 not necessary for a lot of people and
00:14:21.639 anyway it's not feasible on the scale
00:14:24.160 we're talking about so security is also
00:14:28.000 not memory safety there's been some
00:14:30.560 confusion in places between security and
00:14:35.000 um and and safety type safety type
00:14:38.399 safety is not security um I was at a
00:14:43.680 security uh course at uh Bell Labs many
00:14:47.600 many years ago the first class was
00:14:51.240 lockpicking the second class you are not
00:14:53.519 allowed to use your badge to get into
00:14:55.199 the building if I can get your computer
00:14:58.800 all your backup tapes uh all your memory
00:15:01.839 sticks I've got your stuff um spies
00:15:06.360 inside attacks um there's if you're a
00:15:09.839 large organization you have people that
00:15:12.759 can be bought
00:15:15.079 or idealistic for something that's not
00:15:17.839 the company's thing uh spear fishing
00:15:20.639 apparently works very well door ridling
00:15:23.800 if you try enough places people have not
00:15:26.399 done the right thing denial of service
00:15:28.800 SQL re injection uh corrupted input data
00:15:33.759 so if you want to attack something you
00:15:36.800 always attack the weakest link I was
00:15:39.680 told how do you avoid getting your car
00:15:41.880 stolen at new yor airport the answer is
00:15:45.199 park next to a nicer
00:15:47.959 car um so what I'm pointing out I'm
00:15:52.440 talking about type safety and memory
00:15:54.600 safety and things like that but don't
00:15:56.720 confuse it with security security is a
00:15:59.160 system property and the system involves
00:16:03.040 computers people storage areas physical
00:16:06.959 things lots of stuff I'm not talking
00:16:09.360 about all of that but remember it
00:16:11.519 somebody comes and and and screams
00:16:13.680 security because you could have a bug in
00:16:15.959 your
00:16:17.279 program uh languages are not
00:16:20.000 safe um like that thing of writing uh
00:16:24.759 less than instead of greater than such
00:16:27.480 and all safe general purpose languages
00:16:30.399 have Escape Clauses you have to access
00:16:32.560 Hardware resources you have to improve
00:16:35.240 efficiency of key abstractions doing a
00:16:38.079 safe link list implementation is very
00:16:41.639 very hard if you want it to be
00:16:43.920 verified safe I think we're up against
00:16:46.480 the haling problem but let let's say
00:16:49.160 it's just close to impossible so there
00:16:51.480 are things that we want to to do and we
00:16:54.800 have to use the techniques that um that
00:16:58.480 they're not verified it's safe and then
00:17:00.720 you have trusted uh code segments that
00:17:03.720 works those are trouble spots of course
00:17:07.240 but also libraries uh code written under
00:17:10.079 less strict rules you have to call
00:17:12.119 something how about the operating system
00:17:14.160 that's written in C um you can't verify
00:17:18.160 um the the operating system for that
00:17:20.439 reason it's far too
00:17:21.959 complicated and often the Escape Clause
00:17:24.480 is C++ so we can't just close all unsafe
00:17:30.400 areas um being safe where it matters
00:17:33.720 having it guaranteed where it matters
00:17:36.039 and preferably uh by default is is
00:17:39.360 really good and so pointing out that uh
00:17:42.799 you can't get absolute safety is not an
00:17:44.880 excuse for ignoring safety issues it is
00:17:48.160 an argument for focusing our efforts to
00:17:51.440 where we can actually make
00:17:53.720 progress um so I'm going back in
00:17:56.720 history um
00:17:59.280 one of the reasons I uh started with C++
00:18:03.360 was I wanted to deal with uh hardware
00:18:05.880 and I wanted to abstract from it so that
00:18:07.880 I could write better code and static
00:18:10.320 type safety was the idea I've been
00:18:12.880 written writing in languages that were
00:18:15.080 statically safe for a while including
00:18:17.440 simula which is the root of a lot of the
00:18:22.159 uh higher level stuff in C++ we had
00:18:25.400 classes uh
00:18:27.320 encapsulation
00:18:28.919 things like that um but it's an elusive
00:18:33.720 ideal uh because sometimes we need
00:18:36.600 progress sometimes we need better um
00:18:40.039 progress in what we understand sometimes
00:18:42.120 we need better uh Hardware so um
00:18:45.880 efficient use of Hardware that's where C
00:18:48.200 is manage complexity that's where simula
00:18:52.039 is and I've been trying to move us more
00:18:54.960 towards the simular area where where we
00:18:59.120 can afford it where we can do
00:19:01.600 it okay so when I started um if you
00:19:05.840 wanted to call a square
00:19:07.480 root uh you could crash the machine
00:19:10.799 square root of two would crash the
00:19:12.480 machine if you are lucky otherwise it
00:19:15.080 just give you a bad result the point was
00:19:17.559 that uh the compiler had forgotten that
00:19:19.840 you required a double and it wasn't
00:19:23.039 converted so one of the first things I
00:19:26.320 did was to make sure that such things
00:19:28.360 didn't crash uh since crashes are
00:19:30.840 considered a safety problem you could
00:19:32.600 say that I started on this right
00:19:35.400 away um actually it was very interesting
00:19:39.400 in the context of tightening up the
00:19:41.280 language today was that I got 10 years
00:19:44.600 of trouble out of that little fix I mean
00:19:48.679 even C today is is is like that but it
00:19:52.039 was controversial do do you mean I have
00:19:54.880 to look at the Declaration to see what
00:19:56.760 it means I can't just look at the code
00:19:59.880 that was an argument I heard a lot it's
00:20:02.600 incompatible so whenever people didn't
00:20:05.320 like C++ C classes whatever in the early
00:20:08.200 days they they pointed to oh it's
00:20:11.880 incompatible it's it's it's it's
00:20:14.679 different you haven't done your job
00:20:16.840 right well I couldn't uh get my type
00:20:20.000 safety without uh having an
00:20:22.200 incompatibility and one thing I've
00:20:24.000 learned is people when they want to not
00:20:27.000 use a language like C++ they pick
00:20:29.880 something and says oh it doesn't do that
00:20:32.760 today it is safety it's not
00:20:35.520 safe um okay anyway it was essential the
00:20:39.640 type checking overloading user defined
00:20:43.159 types consistent linking type safe
00:20:45.720 linking all of these things require that
00:20:48.400 the language supported argument checking
00:20:51.919 properly fine so sometimes you just have
00:20:54.400 to do it it's important and I think
00:20:56.559 we'll get to that again on uh safety
00:20:59.760 issues and basic idea was to represent
00:21:02.679 things in code and uh create uh
00:21:06.240 abstractions that you could use that Mak
00:21:08.280 your code um simpler and actually safer
00:21:11.880 Vector string file handle concurrent
00:21:14.640 task message cues da da unfortunately
00:21:17.880 they're not all standard today but most
00:21:21.200 of them are things take time I think if
00:21:24.720 we want to address safety we need
00:21:26.799 abstractions that support
00:21:29.039 that
00:21:30.000 notion and immutability came in early
00:21:34.279 um
00:21:36.039 const um I I felt I needed it I was
00:21:39.880 coming out of operating systems and
00:21:41.880 things like that and I knew that those
00:21:44.520 things that couldn't happen things that
00:21:46.520 I didn't want to happen if I had con
00:21:50.520 constant um actually what I really
00:21:52.600 wanted was read only and write only but
00:21:56.360 um I I talk to the Sea guys and they
00:21:59.480 would take con they wouldn't take read
00:22:01.400 only and write only we would have been
00:22:03.159 better off with that but
00:22:05.559 fine um basically you can
00:22:08.960 do leral constants and you can do
00:22:12.840 interfaces this way that way we get
00:22:15.120 better interfaces that's also something
00:22:17.279 that keeps going on uh
00:22:19.840 ra um this was in the first two weeks
00:22:23.400 have a Constructor that constructs the
00:22:25.960 object initializes the object
00:22:28.480 uh establishes the invariant of the
00:22:30.679 object uh if nothing else if you have
00:22:33.200 encapsulation you need it if you don't
00:22:35.080 have encapsulation you still need it to
00:22:37.159 be able to think about your code and
00:22:39.640 then when you are finished if it has
00:22:42.120 acquired uh resources you uh have to
00:22:45.960 give them back again otherwise you have
00:22:47.919 a resource leak uh any librarian can
00:22:50.880 tell you that that people will take out
00:22:53.159 books and they'll forget to give them
00:22:54.559 back again it's a sort of human nature
00:22:57.640 and uh we have to do these things at
00:23:00.240 scale so resource release has to be
00:23:04.000 automatic and U it was phrased rather
00:23:10.200 differently in those days because I
00:23:12.200 hadn't invented the terminology but
00:23:15.279 today we we have it and I hope um we all
00:23:18.840 using it uh examples of non-memory
00:23:22.679 resources I have there file handles
00:23:25.320 locks sockets shaders
00:23:29.080 like that okay so basically here is an
00:23:32.120 example of a resource leak this is naive
00:23:35.679 on safe code and I used to see it a lot
00:23:39.039 people open a file they
00:23:42.000 acquire the file the file handle they
00:23:45.159 use it and they get out again and code
00:23:48.640 is not actually that nice it's sometimes
00:23:51.480 two pages long and there's a return
00:23:54.440 statement or a long jump or a exception
00:23:57.600 in that use F and you never get to the F
00:24:00.480 close so we we we need
00:24:03.559 to not have such code all the compiler
00:24:07.880 sees all the analysis that we see all
00:24:10.720 that the programmer sees is that a fun
00:24:14.720 at a poter comes out of a function and
00:24:17.480 the manual says it has to be given back
00:24:19.440 to another function this this is not a
00:24:22.279 good code and it was a source of bugs
00:24:25.679 and so what we do is represent things
00:24:28.440 directly in code I talk about a resource
00:24:32.320 it should be in the code whoops did
00:24:36.960 I
00:24:39.679 H strange um out of order um anyway so
00:24:46.360 uh objectoriented programming came out
00:24:48.480 of similar well- defined interfaces
00:24:51.240 classes abstract based classes
00:24:53.200 overloading all that kind of stuff
00:24:55.440 that's um um ol yand Dal in the funny uh
00:25:01.360 cheer jacket and CH nugo in the uh the
00:25:05.840 other jacket he was the one that
00:25:07.720 invented inheritance and basically
00:25:09.919 objectoriented
00:25:11.640 programming and but where I lost a slide
00:25:15.000 that showed how to uh handle the file
00:25:18.039 handle thing obviously you create a file
00:25:20.640 handle class and it's Destructor uh
00:25:23.840 closes the file
00:25:26.279 um problem solved and uh we should just
00:25:30.080 do more of that so the evolution of the
00:25:33.360 language of course continued uh
00:25:35.799 templates allowed us to have compile uh
00:25:39.080 time selection of implement of
00:25:41.960 implementations and we finally got
00:25:44.039 Concepts so we have precisely defined
00:25:46.919 interfaces we really should use those um
00:25:51.279 consistently if I if I had a time
00:25:54.240 machine I would go back and tell me
00:25:55.880 about Concepts back in H
00:25:58.320 and we would have had much better
00:25:59.600 templates and I would have had an easier
00:26:01.240 time designing and implementing them uh
00:26:04.360 containers so that we don't have to
00:26:06.000 fiddle with arrays and pointers and it
00:26:08.600 enables range checking there's enough
00:26:10.679 information available to range check
00:26:13.120 containers and the major Implement
00:26:15.880 implementations have range checked uh
00:26:19.159 vectors unfortunately there's not a
00:26:21.640 standard for it and you can't just walk
00:26:23.840 up to a computer and without doing
00:26:26.360 anything else gets range checking that's
00:26:28.600 sad I think and relevant in the context
00:26:31.360 of safety and algorithms we had the
00:26:35.039 traditional HL begin end stuff and now
00:26:37.679 we can actually just sort the vector or
00:26:39.840 any container and that again means that
00:26:42.559 there's bugs you can't make like you
00:26:44.799 can't sort from end to begin or things
00:26:48.600 like that it gets simpler it gets
00:26:51.480 clearer and um safer and smart pointers
00:26:55.760 we can use but uh there's SP
00:26:58.760 pointers um so we have range for and
00:27:02.520 spans um the the loops the sea style
00:27:06.279 Loops there are sort of suspect um I
00:27:11.320 mean at this end really the number of
00:27:13.360 elements there um and uh you you can't
00:27:18.600 range check it because the from the
00:27:20.880 language point of you because there is
00:27:22.960 not enough information in the pointer to
00:27:25.919 be able to do range check
00:27:28.279 uh now we have
00:27:29.720 span that uh that knows the size we can
00:27:33.000 range checks where it's needed or it can
00:27:34.880 just do the whole thing like in that
00:27:37.320 example there I'll again point out that
00:27:40.240 Dennis Richie and I was discussing this
00:27:42.960 problem
00:27:43.960 back uh in the in the 0s and he wanted
00:27:48.399 fat pointers that was span uh so did I
00:27:52.159 but it took us some time to get it this
00:27:54.840 is not I mean if Dennis had they been in
00:27:58.039 control of C we would have had this 20
00:28:01.840 years
00:28:04.720 ago oh and here was the slide that had
00:28:08.840 disappeared I will put it in the right
00:28:11.360 place but basically you solve the
00:28:13.480 problem by having the appropriate
00:28:15.080 abstraction that does the appropriate
00:28:17.559 checks and releases the appropriate
00:28:20.640 resources fine better late than
00:28:23.720 never um okay so uh I wrote up the
00:28:28.360 ideals for C++ and
00:28:31.559 basically uh one of the first things is
00:28:33.840 no implicit violations of the static uh
00:28:36.279 type system um and uh those are quite a
00:28:41.240 few things there the point is this has
00:28:43.320 been documented for a while this when
00:28:46.240 I'm talking about safety and safer
00:28:48.360 things and higher level didn't start
00:28:50.679 yesterday it's in the best tradition of
00:28:52.640 the language and uh benefits comes from
00:28:56.000 using the language which well uh use the
00:28:59.720 facilities we're talking about here and
00:29:03.440 avoid uh raw pointers that you're
00:29:06.279 supposed to delete an owning raw pointer
00:29:08.720 don't subscript the raw pointer because
00:29:10.720 you don't actually know what the range
00:29:13.480 is uh and don't de reference raw pointer
00:29:18.240 before you check whether it points to
00:29:20.360 something don't have uninitialized
00:29:22.760 variables it's a DFT uh and you can do
00:29:25.760 it uh that book there which I wrote for
00:29:29.720 beginners in
00:29:32.480 2001 I think it doesn't show any
00:29:36.279 pointers and arrays until chapter 17
00:29:39.919 after I show them how to do Graphics
00:29:42.720 this can be done the good C++ the higher
00:29:47.360 level C++ is a consistent set of
00:29:50.080 features you don't actually have to go
00:29:52.840 and Fiddle with the lowlevel stuff till
00:29:55.240 you really really need to you can write
00:29:58.000 perfectly good code perfectly good
00:30:00.039 applications without going down there
00:30:03.320 and so if you want um save C++ don't
00:30:06.960 write C C++ there's no such language but
00:30:10.360 there certainly are uses where you think
00:30:12.960 people had it they they say it's C++ and
00:30:16.120 they they do all the things I said on
00:30:17.840 the previous slides that you shouldn't
00:30:20.159 and uh they avoid the higher level stuff
00:30:22.799 usually claiming performance uh problems
00:30:26.559 and uh
00:30:28.559 it's they don't measure um I
00:30:32.600 teach sometimes graduate students and
00:30:34.960 they still don't know how to measure
00:30:36.559 stuff and they still talk about
00:30:38.320 efficiency this this shouldn't happen so
00:30:41.240 anyway we have to evolve our style
00:30:43.640 towards what's provably safe because
00:30:46.080 provably safe is the the the easiest
00:30:49.080 thing to deal with it's easiest things
00:30:50.960 to to to think
00:30:52.720 about and uh as usual I'm trying to talk
00:30:56.200 people into it uh it has its
00:30:59.600 limits so being careful doesn't scale we
00:31:02.720 have to formal formalize formulate the
00:31:05.720 rules for safe use uh we have to um
00:31:10.200 provide ways of verifying that people
00:31:13.000 actually do what they are trying to do I
00:31:16.600 mean I don't think anybody here I'm not
00:31:19.840 excluded that hasn't written a piece of
00:31:21.960 code and they thought it did something
00:31:23.600 and it
00:31:24.559 didn't I would say it happens uh
00:31:27.720 well probably every week to me um that's
00:31:31.440 why I like
00:31:32.600 compilers um and we have to articulate
00:31:35.240 the guidelines so that we can um so so
00:31:38.919 that we can understand what we're saying
00:31:41.000 long long lists of complicated rules or
00:31:44.480 Greek letters is actually not going to
00:31:46.600 be easy to follow um and then we have to
00:31:50.279 enforce the guidelines where needed for
00:31:53.279 what where where needed means we have to
00:31:56.039 say the this is what I want here in my
00:31:59.399 code we'll get to that so the State of
00:32:02.639 Affairs is that if essentially
00:32:05.240 everything what I describe in the past
00:32:08.120 and what I will describe in the right
00:32:09.880 rest of the talk has been tried and many
00:32:12.840 at scale for instance range checking
00:32:15.000 strings vectors and span but nowhere has
00:32:18.320 it all been integrated into a consistent
00:32:20.840 coherent whole and that's what I'm
00:32:23.000 arguing we should do um much of the work
00:32:27.600 uh is is
00:32:29.440 uh I'm talking to is influenced by the
00:32:32.880 work on the core guidelines what we have
00:32:35.080 to go further than the guidelines as I
00:32:37.919 said uh being careful uh
00:32:40.480 doesn't doesn't scale and the aim is
00:32:44.000 still guarantee type and resource safe
00:32:46.399 C++ and then other things too this type
00:32:50.600 and resource safe
00:32:52.880 is pretty fundamental but there's other
00:32:55.919 things we want
00:32:57.600 and therefore we have to specify what
00:32:59.519 these other things are and a lot of
00:33:02.279 stuff can be uh done today we don't have
00:33:05.440 to go and wait for a new release of the
00:33:08.760 standard or something like that and this
00:33:11.240 is not just about safety I have
00:33:14.159 seen code speed up by going to a higher
00:33:18.799 level by expressing more clearly what
00:33:21.639 should be done if I can understand
00:33:24.159 what's going to be happen What should be
00:33:26.480 done so can the optimizer and quite
00:33:29.399 often uh you get benefits one of my best
00:33:32.320 ways of uh debugging and speeding up
00:33:35.559 things these days is to rip out the
00:33:37.320 complicated stuff and uh what is left uh
00:33:42.200 the optimizer can do a good job
00:33:44.919 on
00:33:46.960 oops what is it
00:33:49.799 this okay uh C++ core
00:33:53.519 guidelines or just for information that
00:33:56.120 is the machine that that makes your
00:33:58.240 highend chips high-end processors
00:34:01.760 essentially all of them and of course
00:34:04.720 it's programmed in
00:34:06.919 C++ uh they contacted me to see if I
00:34:09.679 could help them hire good C++
00:34:12.119 programmers no I'm not in that business
00:34:14.800 but really good C++ programmers can do
00:34:18.239 really interesting things General
00:34:21.320 strategy um we rely on static analysis
00:34:25.000 to eliminate potential errors
00:34:27.918 and this is impossible for General code
00:34:30.639 it's easy enough to write a piece of
00:34:32.520 code that cannot be proven to be correct
00:34:36.000 and Global static analysis is just
00:34:38.719 unaffordable a scale so basically we
00:34:41.800 need rules to simplify what we are
00:34:44.079 writing to something that can be anal
00:34:47.599 analyzed uh efficiently and and cheaply
00:34:50.520 local static analysis and there are some
00:34:53.000 analyzers for um for the core guidelines
00:34:55.839 that does things like that and then
00:34:57.960 provide libraries to make relying on
00:35:00.440 these rules feasible if if we had to do
00:35:03.640 everything at the language level uh
00:35:06.440 things get slow and unpleasant to write
00:35:09.320 and then we won't do it with the right
00:35:11.880 abstractions with the right uh libraries
00:35:15.000 just about everything becomes um becomes
00:35:19.680 Pleasant okay there's a philosophy here
00:35:22.599 this is a slide I made I don't know
00:35:25.560 almost 10 years ago
00:35:27.720 I highlighted a few things in
00:35:32.000 red statically type
00:35:34.960 safe can be checked uh at compile time
00:35:38.720 don't leak resources prefer immutable
00:35:41.040 data all of this is safety related so
00:35:44.720 again this is in the best tradition of
00:35:47.839 C++ and raising the level of um of the
00:35:52.480 writing and then there's low-level rules
00:35:54.800 that we use to implement uh these ideal
00:35:57.839 so basically we State what we want and
00:36:00.720 then we make long lists of rules that
00:36:03.560 allows us to approximate getting that um
00:36:07.680 and that's the lowlevel
00:36:09.440 things um
00:36:13.079 yeah and the strategy of the uh core
00:36:17.760 guidelines and of the uh profiles that
00:36:21.560 I'm going to talk about next is the
00:36:25.040 observation simple subsetting doesn't
00:36:27.400 work if you want to subset C++ to
00:36:30.680 something safe or something elegant or
00:36:33.680 something whatever the first thing you
00:36:35.960 have to get rid of is subscripting raw
00:36:39.720 pointers and explicit memory management
00:36:43.160 without any implicit releases from
00:36:48.240 destructors well if you take that away
00:36:50.480 you can't build just about anything so
00:36:53.960 what you do instead is you build some
00:36:55.960 better abstraction
00:36:57.359 s uh vectors smart pointers uh file
00:37:02.359 handle classes things like that and once
00:37:05.760 that is done you can then cut away a lot
00:37:08.480 of the complicated and dangerous stuff
00:37:11.079 at the
00:37:12.000 bottom um this strategy seems to work we
00:37:15.359 use the STL the standard library of
00:37:17.760 course and then there's a small support
00:37:19.880 Library GSL that was by the way where um
00:37:25.119 where span came from and a lot of people
00:37:28.440 still use GSL span because it's
00:37:31.640 guaranteed range
00:37:33.400 checked and um but the point is we add
00:37:37.440 no new language features I want the
00:37:40.200 result of using all of this to be ISO
00:37:43.400 standard
00:37:44.839 C++ I don't want to design a new
00:37:47.400 language it's too hard work and it takes
00:37:50.400 too long I want to write code good code
00:37:53.560 now so what we want is C++ on steroid
00:37:57.599 uh not not some some pitiful
00:38:02.720 subset okay and so we can actually
00:38:07.040 um okay if I had 10 hours instead of one
00:38:12.720 and a bit I could go through this list
00:38:15.480 and argue that we can do all of that of
00:38:18.560 course there's not time to this this is
00:38:20.200 a key note not a deep technical dive so
00:38:23.560 we can eliminate on uninitialized
00:38:26.040 variable range errors n pointer D
00:38:29.119 referencing resource list and dangling
00:38:32.760 references we can do more things unions
00:38:35.640 use variants casts just don't do them
00:38:39.520 overloading and template programming
00:38:41.960 eliminates most cost if you do it right
00:38:45.079 underflow and o on overflow I have not
00:38:47.760 worked my myself uh on that there but I
00:38:52.839 showed you a picture of an engine
00:38:54.560 earlier there was a marine diesel engine
00:38:58.800 was so big that if you look carefully
00:39:00.960 you could see the engineer by cylinder
00:39:02.839 head number
00:39:04.560 five um and that is run by some generic
00:39:08.760 programming that checks for underflow
00:39:11.040 and overflow so it can be done uh I just
00:39:14.480 don't have specific proposal for it and
00:39:17.160 we have some uh ways of dealing with
00:39:19.160 data races but that takes a whole day at
00:39:21.599 least so that's it uh uninitialized
00:39:26.440 variables I mean just do it there's many
00:39:29.480 clever ways of having delayed
00:39:32.800 initialization that act like um like
00:39:36.760 initialization but the code becomes
00:39:39.480 brittle and it becomes hard for the
00:39:42.000 human to see uh what is going on even if
00:39:45.760 the compiler have no problems with it
00:39:48.640 making sure that every object is
00:39:50.880 probably initialized I'm in favor of
00:39:53.599 just initialize everything
00:39:56.920 there's one exceptional case at least
00:39:59.359 probably more which is a huge buffer and
00:40:03.000 if you're doing low latency stuff you
00:40:05.960 don't want to initialize the buffer
00:40:07.880 first and then fill it with good stuff
00:40:09.960 second then you've just doubled the time
00:40:12.400 for filling that buffer I can think of
00:40:14.920 quite a few Industries where you would
00:40:17.000 need to be able to have the Escape
00:40:18.760 Clause from the initialization rules
00:40:21.640 where you can Mark things this one it's
00:40:23.839 uninitialized so it stands out in the
00:40:26.079 code so you can check it and things like
00:40:28.920 that um a lot of these rules to become
00:40:33.640 realistic you have to have some kind of
00:40:36.400 Escape clause and you have to have it
00:40:38.520 explicit so that the humans and static
00:40:41.440 analyzers can understand what what is
00:40:44.200 going on um Range checking of course I
00:40:48.800 want range checking um I don't want
00:40:52.520 subscripting of individual pointers um
00:40:56.000 if if you are writing C style code you
00:40:58.119 should be horrified but uh we can do
00:41:01.119 without it uh vector and span are the
00:41:03.359 two main examples where the range
00:41:06.359 checking can be done and sometimes is
00:41:09.119 being done uh simply because there's a
00:41:11.760 sufficient information available to do
00:41:14.599 the check with a pointer that isn't we
00:41:17.480 have to trust that we have checked thing
00:41:20.319 the ranges
00:41:22.079 correctly and sometimes we don't get it
00:41:25.119 right so it's much better to to use the
00:41:27.359 abstraction for it range 4 is really
00:41:29.960 nice uh it eliminates a lot of the
00:41:33.720 static checking because you only have to
00:41:35.599 check the beginning and the end um
00:41:38.160 algorithms are good I had a bunch of
00:41:41.160 students do some measurements of Loops
00:41:43.640 uh two weeks ago they were really deeply
00:41:46.839 shocked uh for each and accumulate beat
00:41:51.000 their hand coated SE style
00:41:54.520 Loops uh no L but you should have seen
00:41:58.200 my
00:41:59.800 students okay and and rightfully so
00:42:02.880 they've been told low level stuff is
00:42:04.920 important and efficient so
00:42:08.800 often no point of T referencing uh it's
00:42:12.480 fairly easy to check that uh you you
00:42:17.200 have uh a unold pointer there's an
00:42:20.680 abstraction in the TSL there uh for it
00:42:24.040 or you could have the an static analyzer
00:42:26.280 check that there is a test close enough
00:42:29.000 to uh the um to to to to the use that
00:42:34.800 you can verify that it's been done uh
00:42:37.760 again I don't want analyzers to be allly
00:42:41.079 uh clever because I want to understand
00:42:43.160 it too uh no resource leaks be
00:42:46.800 consistent with uh using abstractions
00:42:49.880 that follow the
00:42:51.240 ra uh we have a whole bunch of them uh a
00:42:54.960 naked new is a code smill don't have it
00:42:57.400 a naked delete is uh the same don't have
00:43:00.960 it not an application code they belong
00:43:04.240 in implic applic in implementations of
00:43:09.240 abstractions and um I see a fair amount
00:43:12.680 of code like this uh mostly from people
00:43:15.880 coming in from U from java and C where
00:43:20.640 you have to say new uh to get a user um
00:43:24.400 to to get a
00:43:27.160 an object of a userdefined class so you
00:43:30.480 have a gadget there I don't know what's
00:43:32.960 inside the gadget it may grab locks it
00:43:36.119 may grab file handles and things like
00:43:38.240 that and then you write some code and
00:43:40.839 then you have to remember to delete it
00:43:42.800 delete it and people quite real says
00:43:46.119 well I don't want to have to write that
00:43:48.359 delete but they say I want my garbage
00:43:50.640 collector but the garbage collector is
00:43:52.720 not going to help you because of what
00:43:55.079 was inside the G you don't know what it
00:43:57.559 is uh it may be something that has to be
00:44:00.200 explicitly freed and that code of course
00:44:03.440 can either throw and get out not get to
00:44:07.480 the delete or it can uh return perfectly
00:44:11.240 ordinary stuff this is nothing to do
00:44:13.319 with exceptions uh though I love
00:44:16.000 exceptions and they're really good for
00:44:17.680 this kind of stuff you can get into the
00:44:20.040 trouble without having
00:44:21.680 that um and so re resource handles we uh
00:44:25.720 use a lot of unique pointers and the
00:44:29.440 shared pointers these days and that sort
00:44:32.319 of solves the problem uh we are now
00:44:35.960 guaranteed that the destructor is called
00:44:38.760 and things are properly released um
00:44:41.640 simple and cheap but but you know it's
00:44:44.240 still a pointer and it still uses the
00:44:46.839 free store there's allocations so what
00:44:49.559 really we should do is more uh local
00:44:52.920 objects U there everything works uh
00:44:56.280 without added notation and
00:44:59.440 added um added allocations of course if
00:45:04.000 you're writing code for a embedded
00:45:06.880 processor with very limited stack space
00:45:09.599 you have to be careful about this but in
00:45:12.200 in general programming and actually in
00:45:14.079 most programming this is what's
00:45:16.280 preferred so uh it's it's not just this
00:45:20.880 that should make you worried but you see
00:45:22.920 the uh the the make it new and analyzers
00:45:28.079 easily warn you against that but you
00:45:30.160 should also be a little bit suspicious
00:45:32.240 about the um the the smart pointers
00:45:35.960 because they're really
00:45:38.440 inelegant um okay so dangling pointers
00:45:42.680 you really have to eliminate dangling
00:45:44.680 pointers there's all kinds of bad things
00:45:46.760 that can be happen with a dangling
00:45:48.520 pointer you can write through it into
00:45:50.559 somebody else's memory you can read from
00:45:53.040 it and get some garbage data um
00:45:56.400 you you can scramble things this is
00:45:59.119 really bad and by pointer I mean
00:46:01.520 anything that directly refers to an uh
00:46:05.079 an object I mean this this could be a
00:46:09.319 smart pointer if you're allowed to them
00:46:11.079 to dangle it could be
00:46:13.480 references you name
00:46:15.400 it and we have to eliminate them we can
00:46:19.319 eliminate them with a combination of
00:46:22.079 rules and by assuming that raw pointers
00:46:26.119 are not owners so that we don't have to
00:46:29.920 get interference from the memory
00:46:32.119 management problems
00:46:34.839 here okay so here is a piece of code
00:46:38.040 that's not
00:46:39.240 okay uh it
00:46:41.240 looks
00:46:42.800 um innocent I get a pointer and I delete
00:46:46.880 it well under the rules I'm crafting
00:46:50.640 that is a naked new and the analyzer
00:46:53.280 will reject it and that is good because
00:46:56.599 when you see G it makes
00:46:58.960 something uh an object it passes it to F
00:47:04.119 and then it uses it the use down there
00:47:07.920 is a um is a use of a dangling pointer
00:47:12.920 and of course in a real piece of code uh
00:47:16.079 the void f ofx is not visible like that
00:47:19.200 it's probably on some Li Library
00:47:21.640 somewhere that you've never seen um and
00:47:25.119 but the static analyzers can can handle
00:47:27.440 this and should I I really would like
00:47:31.559 the guarantee that this doesn't happen
00:47:33.880 my code and what you do is you deal
00:47:38.640 with every object has one and only one
00:47:42.559 um owner that means that we know who's
00:47:45.599 who is supposed to do the deletes the
00:47:48.160 closings or whatever you call them and
00:47:50.880 then there can be as many pointers as
00:47:52.599 you like as long as they are
00:47:56.280 um
00:47:58.839 not in the execution after where the
00:48:02.640 owner uh was this is a fairly simple
00:48:06.319 simple model and uh it can be
00:48:09.839 enforced here is an example um I have a
00:48:14.440 function here uh that has a local
00:48:17.599 variable and I call G with the address
00:48:20.280 of
00:48:21.000 it um and uh G then stores it in a
00:48:25.119 global this has to be stopped we have to
00:48:27.720 analyze it and say that uh it's not okay
00:48:32.000 to take something that comes as an
00:48:34.119 argument and store it in something
00:48:36.720 Global because you don't know if it is
00:48:39.680 valid after uh you execute you you exit
00:48:45.760 um on the other hand things that we get
00:48:48.440 from from pointers actually uh pretty uh
00:48:51.720 good because under this rule they will
00:48:54.359 be valid when they come in into the
00:48:56.040 function and they will be valid until we
00:48:58.520 leave the function again because they
00:49:00.720 came from outside the
00:49:02.799 scope and
00:49:05.040 um what do we got here remember
00:49:08.200 containers um pointers or any anything
00:49:12.480 that point can be in containers so I
00:49:16.440 took here a vector of integers rest
00:49:20.200 something and that is okay we create
00:49:23.880 collections of pointers iterators
00:49:27.640 wherever we call them and give them some
00:49:29.680 functions to be called and then when the
00:49:31.440 function comes back again everything is
00:49:33.799 fine because the fact that they the
00:49:37.240 pointers were valid in the calling code
00:49:40.799 if here means that it's valid in the
00:49:43.160 called code we're fine we're not
00:49:45.599 actually having to eliminate all kinds
00:49:47.720 of uh stuff uh this this works on the
00:49:51.480 other hand it is not okay to return that
00:49:54.200 rest because there are point there to
00:49:56.040 local elements in it that will go out of
00:49:58.400 scope that will become invalid when we
00:50:01.640 uh
00:50:02.720 leave um invalidation can be a serious
00:50:06.400 problem so we need to eliminate it sorry
00:50:09.960 um here we have a traditional Vector use
00:50:13.240 push back of nine that can relocate all
00:50:15.960 the
00:50:16.760 elements fine that's uh that's usually
00:50:19.480 fine but G uses it in a not good way it
00:50:25.000 starts by grabbing a pointer to the
00:50:28.319 first element an iterator to the first
00:50:30.160 element then it calls the function that
00:50:32.400 does the push back and then it tries to
00:50:35.319 use the pointer it kept mean this is the
00:50:38.680 reason for using um reserve and for
00:50:42.160 using uh linked uh linked uh containers
00:50:46.839 like a list because things don't
00:50:49.640 relocate we can however
00:50:53.000 detect that this piece of code is is bad
00:50:56.880 um it has been done so what we actually
00:51:00.720 do we have the the idea of
00:51:04.000 invalidated uh when the pointer points
00:51:06.400 to an element of a container that may
00:51:09.079 have relocated the elements that called
00:51:11.200 invalidated it it may or may not be
00:51:13.760 valid and uh
00:51:16.520 then we can
00:51:19.680 uh handle it by a fairly simple
00:51:23.079 rule uh and no a const member
00:51:29.640 function uh doesn't
00:51:33.599 invalidate because it would have to do
00:51:35.920 something nasty to the const it would
00:51:38.319 have to use a um a cast or something
00:51:41.400 like that so also it's easily validated
00:51:44.559 by a an analyzer on the other hand we
00:51:48.040 must assume that
00:51:49.680 any um noncon member function could
00:51:53.760 invalidate it has access to the data and
00:51:56.240 it can it can it can it relocate it can
00:51:59.160 it can move things
00:52:00.680 around um I would think that we need a
00:52:03.839 new annotation in
00:52:06.680 the core guidelines and in uh the
00:52:10.760 profiles which basically says yeah this
00:52:13.839 one doesn't invalidate even though it is
00:52:16.480 non-const standard example Vector
00:52:18.839 operator subscript it doesn't
00:52:21.280 relocate um but it can't be constant so
00:52:25.440 uh it's also easily validated so that is
00:52:27.599 a provable thing so it is perfectly safe
00:52:31.280 and easy to do so uh represent ownership
00:52:35.799 we use ownership abstractions as usual
00:52:38.480 stay high level don't mess with the
00:52:40.599 lowlevel things if you don't but we
00:52:43.359 always have to consider how do we deal
00:52:45.799 with code that's not written according
00:52:47.520 to our rules like thing that like code
00:52:51.640 that has C style interfaces with lots of
00:52:54.920 point in them and so we have an
00:52:58.240 annotation in the uh core guidelines
00:53:02.119 primarily to deal with the fact that the
00:53:05.079 world isn't that simple and we don't own
00:53:06.880 it all um and that's called owner I can
00:53:09.640 say this poter is an owner I'm passing
00:53:12.119 it over to you and I know it's your job
00:53:15.079 to delete this thing can be done
00:53:19.520 um so basically there's been a fair
00:53:22.319 amount of work done with this um and
00:53:25.640 there's some rules about how you can
00:53:27.480 copy owners and not they they you can
00:53:30.720 deduce them from what is safe so I'm not
00:53:32.799 going to go through them here if you're
00:53:34.880 looking at the slides or you can freeze
00:53:37.880 this and see what this is so now I want
00:53:40.960 to get to uh future stuff where do we go
00:53:44.280 to here uh we can write good
00:53:47.440 C++ I hope I made a reasonable argument
00:53:51.440 for that and too many developers don't
00:53:54.520 they write c/ C++ this mythical language
00:53:59.079 uh guidelines are not enough we need
00:54:02.359 guarantees uh partly because we make
00:54:04.839 mistakes and uh partly because we're
00:54:08.280 more comfortable if we have a real proof
00:54:11.880 and uh we we we need new standards for
00:54:16.040 what the static analyzers what the
00:54:18.040 compilers analyze and so we have some
00:54:20.839 Alternatives of how we can proceed from
00:54:23.040 here to get the guarantees we we can
00:54:25.280 change
00:54:26.920 C++ uh we can start using another
00:54:30.200 language which is of course what
00:54:32.079 proponents of all other new languages
00:54:34.359 are suggesting and we can enforce a
00:54:37.119 variety of guidelines um that's the
00:54:39.960 profiles I'm arguing for so fixing
00:54:43.559 C++ how there is so many different or
00:54:48.760 and incompatible ideas about how to
00:54:51.000 change uh C++ and to change C C++ in
00:54:56.040 ways that addresses the problems I've
00:54:58.319 been talking to it will not look like
00:55:01.119 C++ and there are um several suggestions
00:55:05.799 so we have years of delay and chaos and
00:55:10.480 a single clean up language will provide
00:55:12.839 a single kind
00:55:15.160 of safety unless of course it adopts the
00:55:18.880 profile approach and uh that that would
00:55:23.319 not be what a lot of people people talk
00:55:26.000 about and the clean up C++ will have to
00:55:29.280 interoperate with classical C++ code
00:55:33.000 Forever that that's just just a fact is
00:55:36.119 these billions of lines of code are not
00:55:38.039 going to disappear and much of it is
00:55:40.480 critical much of it is really high
00:55:43.359 quality so gradual adoption is essential
00:55:46.640 partial adoption is
00:55:48.640 essential um
00:55:51.160 and well for C++ I have had had it's
00:55:56.319 meant to evolve but also meant to evolve
00:55:59.280 in a reasonable compatible way if you if
00:56:02.720 you accept that last statement it won't
00:56:05.240 won't be fixed in the way uh people talk
00:56:10.319 about and then we can try using another
00:56:13.480 language uh safety is used as an
00:56:16.359 argument uh often c/ C++ and very
00:56:21.760 typically ignoring c++'s strength and
00:56:25.280 very often uh ignoring weaknesses of
00:56:29.000 Alternatives um often the safety
00:56:31.200 mentions is just memory safety that's
00:56:33.760 not enough and the need for unsafe
00:56:37.319 construct is not heavily
00:56:39.799 featured and the need to interoperate
00:56:43.240 with other languages including C++ and C
00:56:46.680 tend not to be mentioned and the cost of
00:56:49.400 conversion can be ferocious that's
00:56:52.039 rarely mentioned and of course this is
00:56:54.480 natural this is human nature you you you
00:56:57.520 argue for your case and you
00:57:01.119 overestimate the virtues of what you
00:57:04.160 have and underestimate
00:57:06.200 the strength of the opposition but still
00:57:10.079 we have to be more serious about how we
00:57:13.480 um have these argument and we need to
00:57:15.839 get some numbers and anyway which other
00:57:19.160 language um the way I have seen it
00:57:22.000 argued we were going to have C++
00:57:24.960 replaced by about seven different
00:57:26.880 languages as of suggestions of about now
00:57:31.079 by the time it happens 40 years from now
00:57:34.280 uh we'll probably have 20 different ones
00:57:36.280 and they have to interoperate this is
00:57:38.839 going to be difficult anyway let's look
00:57:41.559 there's new languages new resources new
00:57:45.799 expert users every new language of
00:57:48.599 course is claimed to be simpler cleaner
00:57:50.640 safer and more productive than C++ on
00:57:53.599 the other hand we heard that one from
00:57:55.559 java at the time I said yeah if it
00:57:58.880 survives it will become three times
00:58:00.839 bigger and be better for it I was right
00:58:03.400 about that uh you can apply that
00:58:05.520 argument to most new
00:58:07.680 languages and uh often the claim
00:58:10.440 superiority is in a limited domain and
00:58:13.839 again often compared to c/
00:58:16.799 C++ and one thing I have noticed when
00:58:19.720 you have a new language this happened
00:58:21.839 with C++ also you get a bunch of writing
00:58:26.039 code they are just much better than
00:58:28.480 average they are much more enthusiastic
00:58:31.000 they're better informed uh they know all
00:58:34.079 the latest stuff and then you come up
00:58:37.039 against the law of large numbers when
00:58:39.480 you have a language that is used at a
00:58:41.839 large scale your developers are average
00:58:45.960 quality average enthusiasm Etc um which
00:58:50.280 means that number is comparing a small
00:58:52.920 new community with a large much older
00:58:55.520 community is is going to be
00:58:58.200 skewed um let's see um I was thinking
00:59:02.520 about what it would take to convert
00:59:04.960 something so said consider converting a
00:59:08.200 10 million line system there's lots of
00:59:10.720 those uh it needs High reliability and
00:59:13.520 high performance because if it wasn't
00:59:15.960 why would you bother converting it for
00:59:18.000 safety reasons and such a good developer
00:59:21.200 completes in lines of production quality
00:59:23.520 code today I don't know what n is it
00:59:26.520 depends on what kind of code we're
00:59:28.880 talking about but for the kind of
00:59:31.559 critical uh software we're talking about
00:59:34.280 now maybe 5
00:59:36.400 10 100 let's say 2,000 lines a year
00:59:40.680 that's not too far off and let's assume
00:59:45.039 that a 10 million line uh system can be
00:59:49.480 written in the new language in the new
00:59:51.760 way from scratch in 5 million lines
00:59:55.319 half the size um this is sort of very
00:59:58.680 optimistic but if this is true it'll
01:00:01.520 take 500 developers 5 years to complete
01:00:04.200 the new system and the old system will
01:00:07.039 have to be maintained by uh for those 5
01:00:10.960 years till you can replace it and so
01:00:13.599 what is the loaded salary of a good
01:00:15.760 developer that's the cost of the salary
01:00:18.960 uh Pension funds uh buildings heating
01:00:22.640 cooling Computing all of this kind of
01:00:24.760 stuff let's say half a million in the US
01:00:27.680 it's not that far off we can argue about
01:00:30.680 100,000 in each way but this thing so it
01:00:34.160 would
01:00:35.160 cost um roughly a billion added cost
01:00:39.359 over those five years and for 1 million
01:00:43.079 you can divide for 100 million you can
01:00:46.440 multiply um and I made the Assumption of
01:00:49.200 us
01:00:50.240 developers um if you can find a develop
01:00:54.559 because with the relevant
01:00:57.760 experience um in the new language that's
01:01:01.960 uh often a problem and maybe Outsourcing
01:01:05.760 could cut cost that doesn't always
01:01:08.440 happen when you Outsource and then it
01:01:10.720 has its own problems especially when the
01:01:13.680 um when you start talking security and
01:01:16.319 such it's it it it's not obvious how can
01:01:20.599 you can cut that course dramatically but
01:01:23.039 anyway um I I said that I assumed the
01:01:26.640 new system would half the size of the
01:01:29.000 old one it doesn't happen very uh very
01:01:32.480 often but it certainly is possible if
01:01:35.880 you have better understanding of the
01:01:37.799 problem better language better tooling
01:01:39.799 Etc such and there would be no feature
01:01:42.920 creep for 5 years this is hard and the
01:01:47.480 new system would be would work and be
01:01:50.400 delivered on
01:01:52.079 time uh what is is going on with this
01:01:55.839 stupid
01:02:01.680 system oh I see what went on with that
01:02:19.079 system I am not seeing what you are
01:02:23.359 seeing
01:02:24.960 now I
01:02:26.839 am okay uh so there are of course people
01:02:31.720 for whom a billion dollars or100
01:02:34.279 millionar or not a lot of money so let's
01:02:37.599 not just dismiss the whole thing for
01:02:39.960 that reason um there's people who think
01:02:43.319 that a 10 million uh line system is
01:02:46.000 medium I did some asking around here um
01:02:50.079 and
01:02:51.599 yeah and so I think I think these kind
01:02:55.039 of numbers are an argument for an
01:02:57.000 incremental and evolutionary approach uh
01:03:00.160 as opposed to just going to something
01:03:02.799 brand new and obviously that could be
01:03:05.440 C++ or a combination of C++ and other
01:03:09.000 languages that are able to interoperate
01:03:12.079 smoothly with C++ and you can have a
01:03:14.640 community of both things I think it's
01:03:17.079 better to stay with C++ anyway C++ will
01:03:20.799 play a major role for decades to come
01:03:23.200 and we have to keep working on it
01:03:25.000 standards committee has to focus and
01:03:26.880 make C++ better and then I was um
01:03:30.240 looking up something I knew and to find
01:03:32.559 a quote people like quotes so there's
01:03:35.359 something that's called G gals law a
01:03:38.200 complex system that works is invariably
01:03:40.760 found to have evolved from a simple
01:03:43.440 system that
01:03:44.680 worked in other words this idea of just
01:03:48.920 building the new system over on the side
01:03:51.520 without any of the problems of the old
01:03:53.400 one is a f fantasy but it's a very
01:03:56.160 popular fantasy um I I agree with that
01:03:59.319 last statement down
01:04:01.000 there so profiles how can we guarantee
01:04:04.480 safety with standard C++ code uh
01:04:08.480 guidelines are not enough and the
01:04:11.160 profile summary here um is that
01:04:15.920 everything is ISO C++ standard um the
01:04:19.640 fundamental guarantees is up uh the most
01:04:22.920 fundamental guarantee that we want is
01:04:25.440 complete uh type and resource safety
01:04:28.680 ownership has to con uh constitute a dag
01:04:33.279 otherwise the uh the model breaks down
01:04:36.960 if you have loops and such you can
01:04:40.440 handle loops with say shared pointers
01:04:42.680 and weak pointers but to easy proof uh
01:04:46.599 stick to a dag pointers dealt with as I
01:04:50.680 said before um gradual conversion
01:04:55.160 uh offering guarantees has to be
01:04:57.520 supported uh the set of guarantees are
01:04:59.920 open I do not
01:05:02.480 know whatever everybody wants for
01:05:06.400 guarantees I can see somebody wanting a
01:05:10.440 um unsafe guarantee where they can use
01:05:13.000 all the unsafe features in the latest
01:05:16.079 Optimizer um in in other words it's an
01:05:18.839 open
01:05:19.640 set and we want some fundamental
01:05:23.480 guarantees to be standard I I'm
01:05:26.000 imagining type and resource safety
01:05:28.680 memory safety range safety um arithmetic
01:05:32.720 safety things like that could be
01:05:35.000 standardized um nothing is easy to
01:05:38.279 standardize but this is possible and the
01:05:41.640 set of guarantees assumed are stated in
01:05:44.799 code otherwise we don't know which kind
01:05:47.079 of analysis to apply to a code and we
01:05:50.119 don't know if we're users what kind of
01:05:52.400 analysis the wor applied for that code
01:05:56.480 and there's many Notions of safety I've
01:05:58.480 said this before but I think it's worth
01:06:00.799 showing the the list again because
01:06:03.000 people tend to forget it and focus on
01:06:06.079 the thing that they're looking at just
01:06:08.079 now in in their everyday problems um and
01:06:12.640 here's the type and resource safety
01:06:14.760 definition basically every object is
01:06:17.559 accessed according to the type with
01:06:19.319 which it was defined boom that's a nice
01:06:22.119 one and we don't have any um any
01:06:27.640 leaks and so what about c/
01:06:31.680 C++ well it's not a language but I think
01:06:34.640 it's a style of usage that I happen not
01:06:36.920 to like it's probably also unavoidable
01:06:40.440 because you have to call C libraries and
01:06:42.920 then we have to think about how to call
01:06:45.039 things with other guarantees the owner
01:06:48.160 annotation and not all checking is
01:06:52.119 examples of that we can't just focus on
01:06:55.559 making the the new shiny version of
01:06:58.760 everything um it's too complex for
01:07:01.960 static analysis if we can write
01:07:03.480 arbitrary code we we're up against
01:07:05.880 Dynamic linking cost and the holding
01:07:09.359 problem um arbitrary C++ focuses to deal
01:07:13.000 with low-level abstraction so we have to
01:07:15.000 raise the abstraction level to the point
01:07:17.160 where analysis is possible and
01:07:20.039 understanding by humans and we care
01:07:22.680 about performance and type and resource
01:07:25.760 safety so the idea is guarantees with
01:07:29.119 static analysis have coding rules to
01:07:32.119 make sure that the analysis is feasible
01:07:34.839 and have libraries to make it uh
01:07:37.000 reasonable to to write such code and the
01:07:39.960 profiles is a coherent set of guarantees
01:07:43.279 not just a set of unrelated tests and
01:07:46.359 the profile
01:07:48.520 um is then specified as a set of
01:07:52.720 guarantees and then implemented with a
01:07:54.839 set of rules that yields the uh
01:07:57.520 guarantee that we wanted and um I've had
01:08:01.599 people saying this is just too novel
01:08:03.599 it's too complicated it's too new what
01:08:06.680 we want is something simple and new this
01:08:09.079 shiny new language that you can Define
01:08:11.640 in 45 pages just like uh the first
01:08:15.079 version of c um I I don't don't believe
01:08:18.960 so um there's a vote there you you're
01:08:22.520 always supposed to not do something new
01:08:24.439 you're supposed to just put put some
01:08:27.520 kind of aade on something old I don't
01:08:30.040 believe this is feasible I think we have
01:08:33.399 to have an overall approach a general
01:08:36.080 approach each
01:08:38.040 individual techniques and feature has
01:08:40.319 been tried before many times and that's
01:08:43.679 good but for specific tasks and they are
01:08:47.920 not none of those solves all the
01:08:50.439 problems so a combined and coherent
01:08:52.439 approach is necessary
01:08:54.759 and profiles has to go beyond guidelines
01:08:57.759 because we want it
01:08:59.238 validated uh and we have to deal with
01:09:02.158 provide in code annotations and we have
01:09:05.600 to deal with mixing of uh profiles
01:09:08.839 different sets of guarantees in a in a
01:09:10.920 large system you can't imagine a million
01:09:13.359 lines of code that all follows exactly
01:09:16.359 the same rule uh and if you can I'll
01:09:19.399 just up the number to 10
01:09:22.560 million uh so we mix profiles and I
01:09:27.040 think we have to find the
01:09:30.520 tightest specification of when we uh can
01:09:34.520 use the non validated non- guaranteed
01:09:38.719 features we can't just say
01:09:41.799 uh this these 100,000 lines are not
01:09:45.080 checked that's not good enough it it is
01:09:47.960 good to have maybe the implementation of
01:09:50.920 the link list um two pages code have
01:09:55.239 that
01:09:56.840 specified so that's just some design
01:09:59.159 work going here um still under
01:10:02.120 development I'm suggesting uh that you
01:10:05.199 have module based
01:10:06.960 controls memory safety here type safety
01:10:10.280 is suggested and incode controls
01:10:13.640 suppress type safety in this area and
01:10:16.400 enforce type safety in this area I could
01:10:18.760 have a piece of code that is just
01:10:22.280 too compc at or too difficult to convert
01:10:25.600 so I can't do it but I can say for this
01:10:28.000 section here I would like the analysis
01:10:30.400 to be done and suggest standard profiles
01:10:33.960 type safety range arithmetic uh would be
01:10:37.880 a good initial set and uh here's a
01:10:41.239 summary of what it would take to do this
01:10:43.800 in terms of uh
01:10:46.120 syntax and um this work in progress
01:10:50.520 there's Papers written about it and uh
01:10:54.440 you you can go and look it up there's
01:10:56.480 also talks about it and basically no
01:11:00.400 we're not here yet we've come a long
01:11:02.920 long way from classic C and from CW
01:11:06.080 classes and from C++ 11 and we have to
01:11:10.040 first of all get people who are not up
01:11:12.719 to date with C++ uh to become up to date
01:11:16.679 it does not mean using every new feature
01:11:19.880 exclusively and using every uh every
01:11:22.679 neat little new thing no it means uh
01:11:26.480 defining what you want and seeing the
01:11:28.440 simplest way of getting it the core
01:11:30.480 guidelines are an attempt with that and
01:11:32.760 we need to start standardizing uh
01:11:35.120 profiles as
01:11:36.760 described and um of course this is
01:11:39.880 something that uh can't be done by one
01:11:43.760 or two people maybe it could in five
01:11:46.360 years but I don't think we have five
01:11:48.560 years so how can you help um how do we
01:11:53.960 refine profiles what profiles do we need
01:11:58.000 uh how do we best formalize the
01:11:59.880 specification of a profile and what can
01:12:02.960 we do now I'm dreaming of something like
01:12:06.800 profiles light that uh
01:12:10.440 provides most of the guarantee of a
01:12:13.679 profile but can't do all the last things
01:12:16.520 because say the static analyzer isn't up
01:12:18.760 to it
01:12:19.960 yet and U what library compon components
01:12:23.920 can be simplified to use I've been using
01:12:27.440 a din array uh that doesn't have push
01:12:30.679 back so that I can use it in a
01:12:32.440 concurrent system without worrying that
01:12:34.480 somebody does a push back or on the
01:12:36.239 other
01:12:37.239 thread U maybe we need more of that and
01:12:41.480 I'm setting up a GitHub
01:12:45.320 for where people can put uh suggestions
01:12:48.679 and where I'm going to put my uh drafts
01:12:51.639 and S such so that that we can create a
01:12:54.880 community working on getting this kind
01:12:57.920 of stuff done uh in a reasonable time uh
01:13:04.080 the GitHub is
01:13:07.840 not live but should become live this
01:13:12.440 afternoon okay thank
01:13:22.360 you
01:13:32.679 um do we have questions do we have time
01:13:36.280 for questions or have a run over so
01:13:39.000 badly as we
01:13:46.199 can't that's if you have a question
01:13:49.000 please come up to the
01:13:52.360 microphone
01:13:54.400 there's one over there
01:14:05.400 also hey thanks a lot so you mentioned
01:14:08.080 uh for example uh Vector without push
01:14:10.800 back in a certain profile so uh do you
01:14:12.960 think that a profile uh will like
01:14:15.440 eliminate member functions in some cases
01:14:17.960 or just make those member functions
01:14:19.480 behave
01:14:21.920 differently I don't quite understand the
01:14:24.520 question sorry you mentioned that in a
01:14:26.719 certain uh context you might want a
01:14:28.679 vector class that doesn't have push back
01:14:30.920 yes so there could be a profile that
01:14:33.080 like eliminates certain member
01:14:35.679 functions um that's one way of doing it
01:14:39.000 that's not the way I imagined doing it
01:14:41.199 because well I did it some other way uh
01:14:44.480 because I couldn't actually mess with
01:14:46.880 our standard implementation of the
01:14:50.760 um of the vector so for instance my
01:14:53.639 students get a range check Vector I
01:14:56.159 can't do that without messing with the
01:14:59.440 implementation and there several
01:15:01.639 implementation so I don't do that
01:15:03.880 similarly what I did in case of the uh
01:15:07.400 invalidation was I used another class
01:15:10.000 which I call Din array which I believe
01:15:12.480 you can find in the GSL which simply
01:15:14.960 didn't have that operation that's the
01:15:18.000 other way of doing it and if you are not
01:15:21.719 uh the standards committee or a vendor
01:15:24.199 of a standard Library that's the way you
01:15:26.760 must do it and so I
01:15:33.679 did okay question on uh immutable data
01:15:36.880 you said prefer immutable data over
01:15:39.360 mutable data at the same time famously
01:15:42.360 the string class and C++ is
01:15:45.000 mutable and ISO quite you know some some
01:15:49.239 discussion about immutable string class
01:15:51.480 but it didn't really catch on um I hear
01:15:54.960 a lot about immutable string classes but
01:15:57.880 you know I like the mut mutating some
01:16:01.159 strings some of the time and uh I have
01:16:04.760 not seen a coherent argument for why
01:16:07.679 it's better to have it
01:16:09.400 deed uh immutable what are the benefits
01:16:12.960 what are the problems and in the absence
01:16:16.480 of such a suggestion we're not going to
01:16:20.560 get one furthermore there's so so much
01:16:23.480 code out there so it would almost
01:16:25.280 certainly be an example of a a different
01:16:28.760 thing um that was immutable but somebody
01:16:33.320 has to do a thorough logical and
01:16:36.560 hopefully data argument for why
01:16:39.400 immutable strings are good is it a issue
01:16:42.760 of correctness is it an issue of
01:16:45.280 performance all of that I haven't seen
01:16:47.639 that kind of argument thank
01:16:52.080 you
01:16:53.880 I noticed uh a lot of the various
01:16:56.760 suggestions you're making are enforced
01:16:58.520 by Static analyzers or are tooling
01:17:00.840 separately from the compiler one of the
01:17:03.159 issues I've observed when setting up new
01:17:04.960 C++ projects on my own or at work is
01:17:07.280 getting additional tooling into the
01:17:09.080 build chain into the CI takes effort and
01:17:12.040 is not trivial effort at production
01:17:13.880 scale do you have any suggestions on how
01:17:16.760 to make that process easier of how to
01:17:18.840 make you know tooling integration
01:17:21.199 simpler there there are couple of
01:17:23.560 problems related to Tool chains and yes
01:17:26.920 it's hard to get something new into the
01:17:30.199 tool chains and the usual problem with
01:17:32.600 C++ is that we have many of something we
01:17:36.679 we never just it's not that C++ doesn't
01:17:39.199 have a Graphic system it has many
01:17:40.960 graphic systems we have many build
01:17:42.960 systems we have many static analyzing
01:17:46.159 systems um so what I am hoping is that
01:17:50.960 the profiles will encourage people to
01:17:55.679 have to to build static analyzers that
01:17:59.199 supports a
01:18:01.239 specific
01:18:03.040 profile and that the build system the
01:18:07.040 compilation system sees that this is
01:18:10.760 required and uses the
01:18:13.360 installed um static
01:18:16.120 analyzer now a lot of what I'm doing can
01:18:20.040 actually be put into the compiler itself
01:18:22.480 because compiler is a static analyzer
01:18:25.120 and these days quite a sophisticated
01:18:27.280 stat static analyzer um the simplest
01:18:30.320 would be the in init no uninitialized
01:18:34.239 data rule which they're already doing
01:18:38.040 more complicated stuff to detect whether
01:18:40.639 it's been an uh initialized or
01:18:44.760 not but I think the the idea of profile
01:18:50.480 annotations should help with that
01:18:52.639 problem
01:18:56.199 thanks so it seems that the new
01:18:59.360 Improvement on safety and C++ are adding
01:19:02.679 or addition to the language new
01:19:05.480 annotations new types do you think and
01:19:09.719 there will be a time where the default
01:19:11.920 is actually um the saf ones and unsafety
01:19:16.280 one you actually need
01:19:18.760 addition uh if you want to maintain
01:19:21.840 compatibility you have to work through
01:19:25.080 extensions and to you
01:19:28.800 cannot efficient effectively eliminate
01:19:31.840 features from the language we tried
01:19:33.600 several times with deprecations and such
01:19:36.719 and E
01:19:38.199 even incompatible changes have caused a
01:19:41.120 lot of grief so I'm not going that way
01:19:44.040 what I actually am going for is to to
01:19:49.639 simplify the use of the language through
01:19:52.520 the gu guidelines and then if you follow
01:19:55.480 the guidelines you have a simpler
01:19:57.040 language to deal with you don't actually
01:19:59.400 have to know uh the horrors of pointers
01:20:03.679 to pointers to void uh because the
01:20:07.120 analyzer will stop you from writing one
01:20:11.120 um and so extend the language make a a
01:20:15.840 simpler subset of the language that you
01:20:18.239 can
01:20:19.360 enforce thank
01:20:21.760 you
01:20:24.719 uh hi uh you briefly mentioned about uh
01:20:27.560 you wanted to add right only when when
01:20:29.920 you were talking about con uh as the
01:20:32.400 language feature uh you mentioned that
01:20:35.280 it will create a better interface or
01:20:37.159 something like that so what were you
01:20:39.239 thinking of a use case of right only and
01:20:41.400 then uh is there alternative we can use
01:20:44.440 or uh yeah anything about right only I'm
01:20:47.719 afraid I didn't understand that oh uh so
01:20:51.560 when you were mentioning about the const
01:20:53.440 you talked about read only and write
01:20:55.159 only and then it would it would have
01:20:57.760 created a better interface if there was
01:20:59.679 write only like
01:21:02.639 const
01:21:06.639 um the const example was just an example
01:21:10.400 of how from the very earliest days um we
01:21:14.800 have tried to create a a safer language
01:21:18.960 a language where it's harder to make
01:21:21.080 mistakes and easier to understand and
01:21:24.080 and I just threw in a historical fact
01:21:27.760 that I didn't just actually have
01:21:30.080 const which is read only uh I also had
01:21:33.880 write only but uh I couldn't get it okay
01:21:37.920 all right thank
01:21:41.560 you hello um so do you
01:21:45.520 think um like sometimes you might want
01:21:49.360 to express that the function is thread
01:21:51.880 safe or that it does IO operations you
01:21:55.320 think maybe under the hood uh you could
01:21:57.920 use Tag dispatching uh to implement the
01:22:01.199 profile you were talking
01:22:03.719 about um I have not thought about this
01:22:07.600 so this is an off the cough
01:22:10.800 comment but yes I could imagine there
01:22:14.600 being a a threat safe annotation that
01:22:18.320 would that may be part of a profile
01:22:23.239 uh profiles will
01:22:26.360 invariably partly be built out of other
01:22:29.280 profiles currently in the um in the core
01:22:33.520 guidelines we
01:22:35.040 have
01:22:37.120 um memory safety and type safety and I
01:22:41.560 think there's three of them that would
01:22:43.639 add up to type and resource safety and I
01:22:47.840 would
01:22:48.840 imagine that a threat
01:22:51.560 safe
01:22:53.010 [Music]
01:22:54.159 um thread would be part of a profile
01:22:59.040 what I really would not like to see is a
01:23:02.360 total sort of 50 or 100 things you can
01:23:06.840 request because then you got chaos and
01:23:09.719 if you go and see the current static
01:23:11.639 analyzers they are very prone to giving
01:23:14.400 you a free
01:23:15.800 choice and that very often doesn't add
01:23:19.719 up to a coherent set so of guarantees so
01:23:24.760 yes it would be a candidate for
01:23:26.880 something but I'm not quite sure
01:23:33.560 what do you think that if we had the
01:23:36.920 compil time reflection as part of the
01:23:38.719 language we would be able to implement
01:23:40.719 most of the static analysis checks by
01:23:43.040 using Concepts or Conex functions
01:23:45.920 instead of a external
01:23:49.360 analysers no I don't think so it's a IT
01:23:54.719 addresses I would like to see static
01:23:57.080 reflection but I think it addresses
01:23:59.520 different uh sets of
01:24:04.679 problems yeah thank you for the talk um
01:24:07.280 I think there is a good examples when
01:24:09.639 you're in a controlled environment when
01:24:11.320 you are the author of The Cod but what
01:24:14.080 if how what do you think how you can
01:24:16.159 improve the safety when you're dealing
01:24:18.360 with the libraries that you know cc++
01:24:21.159 libraries that passing your pointers
01:24:24.480 what can be done there that is the
01:24:26.480 problem which I refer to as mixing
01:24:28.920 profiles you
01:24:31.199 can you can annotate the import or the
01:24:35.639 include um with something about what
01:24:39.480 assumptions you may make about uh what
01:24:43.199 you're importing and that's about all
01:24:46.119 you can do you can handle
01:24:49.760 subsetting of profiles
01:24:53.159 arbitrary you can sub setting and
01:24:55.960 disjoint what sort of arbitrary sets of
01:25:00.760 guarantees are just too hard to um
01:25:04.800 mechanically deal with and so we'll have
01:25:08.320 to have some annotations and have some
01:25:10.639 humans uh actually try and understand
01:25:13.960 and see what they're dealing with okay
01:25:17.040 and the problem will not go away yeah
01:25:19.679 for decades basically if you have
01:25:21.800 Rangers you it's you you we have to know
01:25:25.880 it's a problem we have to try and deal
01:25:28.080 with it as best we can but we can't
01:25:30.840 eliminate it thank
01:25:35.400 you hi um so I noticed that you
01:25:38.600 mentioned Concept in your talk and uh we
01:25:41.800 try to use it in our batteries at work
01:25:44.719 um I guess the problem we have is that
01:25:46.880 it's making the code become more complex
01:25:49.719 and understanding for other people when
01:25:52.000 they F to maintain appies and we haven't
01:25:54.960 found any actual benefit of using
01:25:57.960 concept um so I wonder if you can
01:26:00.360 elaborate on the benefits of it and um
01:26:03.360 some resource for gight to use it
01:26:05.480 correctly sure I mean I have used it
01:26:08.560 successfully in code that are not sort
01:26:11.760 of Computer Sciences especially
01:26:15.520 communication
01:26:16.880 software and we found it uh very helpful
01:26:21.920 uh one thing to avoid is people using
01:26:25.440 requires Clauses as um requires requires
01:26:31.440 and sort of low-level uses of guarantees
01:26:34.520 that creates a filthy mess I don't know
01:26:36.800 if that's what you did but that's one
01:26:38.639 thing I have seen uh failing people
01:26:41.320 think they're using uh modules they're
01:26:43.840 not they're using the assembly code for
01:26:46.800 creating
01:26:47.920 modules and well it's say successful as
01:26:50.960 a sampler
01:26:52.760 um and it takes some experience to build
01:26:58.040 proper Concepts um I've seen people try
01:27:01.080 and build Concepts on the idea that they
01:27:03.800 have to be the absolute minimal
01:27:05.600 constraints for everything uh again you
01:27:08.440 get far too many Concepts and you can't
01:27:10.400 remember them um when I write about
01:27:13.040 Concepts speaks about Concepts to say
01:27:15.080 concepts has to be designed to
01:27:19.800 um to to encourage comp uh composition
01:27:24.520 that is they have to be sufficiently
01:27:26.400 high level that a concept can be used in
01:27:29.040 many places in many algorithms so if
01:27:32.080 people build a um a less than concept
01:27:36.400 and somebody else uses a less than an
01:27:38.440 equals concept you you're on the way to
01:27:41.119 something chaotic whereas if you build a
01:27:45.639 um ordering Concepts as there is in the
01:27:48.800 standard uh then with all the four
01:27:51.520 operations
01:27:52.960 you're you're on the way to something
01:27:55.040 better uh I I mean it may be that
01:28:01.000 your problem area has something that we
01:28:04.760 haven't addressed uh but in most cases I
01:28:08.440 have seen problems like that it has been
01:28:11.880 been uh immaturity of uh of use it's
01:28:17.080 like when when people start writing code
01:28:20.080 they don't write good code uh they they
01:28:22.960 they make beginners mistakes
01:28:26.239 and I hope you don't think I'm rude when
01:28:29.480 I suggest that that might be a
01:28:31.840 possibility um if you analyze your stuff
01:28:35.080 and see if you can be precise about what
01:28:38.239 it was it didn't seem to work I would
01:28:40.840 like to hear about
01:28:42.639 it thank you yeah thank you and I think
01:28:45.880 this is it thank
01:28:51.000 you