[00:00.000 --> 00:19.920]  A very quick update on how we use C++ standards in LibreOffice to finish off this afternoon.
[00:19.920 --> 00:28.120]  So yeah, we're still using C++ 17, almost there's one thing that keeps cropping up.
[00:28.120 --> 00:33.000]  I think Noah will try to sneak it in twice and Mike wants.
[00:33.000 --> 00:40.720]  This is this unsuspecting standard from Kars thing where you have a string view of characters
[00:40.720 --> 00:45.600]  and you want to get an integer or floating point value out of that and there's a standard
[00:45.600 --> 00:47.880]  form function for that.
[00:47.880 --> 00:54.400]  Unfortunately it's not in Libre standards C++ 8 or only in 8 and only in 11 for floating
[00:54.400 --> 00:58.320]  point values which we don't have, we're still stuck at 7.
[00:58.320 --> 01:06.080]  So people keep trying to add that to the unolibraries and I as the gatekeeper of these unolibraries
[01:06.080 --> 01:10.040]  which we never want to change because then we have these maintenance problems.
[01:10.040 --> 01:14.800]  I keep banging them back that we don't need that, we don't need to add anything there
[01:14.800 --> 01:21.400]  because we'll have C++ 17 functionality for it anyway and I keep saying that for years
[01:21.400 --> 01:22.400]  now.
[01:22.400 --> 01:26.000]  At one point we'll get there, I'm pretty sure.
[01:26.000 --> 01:35.480]  So yeah, just C++ 17 for now still but of course we're making use of whatever becomes
[01:35.480 --> 01:42.000]  available in the later standards so that C++ 20 is out for two, three years now and C++
[01:42.000 --> 01:50.360]  23 is almost finished, it's the standardizing stuff takes its time but it's quite frozen
[01:50.360 --> 01:51.680]  by now.
[01:51.680 --> 01:57.560]  And then there's always these small things mostly in the standard library that are easy
[01:57.560 --> 02:07.240]  to approximate and then we usually make use of those ideas in our own code and have one
[02:07.240 --> 02:15.800]  header file, one include file where we either use the original alias to our O3 etl namespace
[02:15.800 --> 02:23.960]  or implement our own approximation which we then throw out once we have that available.
[02:23.960 --> 02:30.000]  So this is the span thing similar to the string view where you just have a range of values
[02:30.000 --> 02:32.200]  start and length.
[02:32.200 --> 02:37.200]  Then these comparison functions they are very interesting if you don't know them then
[02:37.200 --> 02:42.240]  check them out so you always have a hard time comparing two integers in C and C++ if they
[02:42.240 --> 02:47.720]  are of different types signed and unsigned and you get surprising results and finally
[02:47.720 --> 02:54.760]  in C++ 20 they decided to come up with ugly syntax functions but they will do the right
[02:54.760 --> 02:59.400]  thing whatever types you throw at them and we have at least one place where we use them
[02:59.400 --> 03:02.240]  by now for good measure.
[03:02.240 --> 03:07.480]  And another example is these standard unreachable magic function that they introduced we still
[03:07.480 --> 03:13.040]  have a macro for that to approximate it so if there is a place in your code where you
[03:13.040 --> 03:19.320]  can't reach so a default in a speech and you don't want to return any nonsense from that
[03:19.320 --> 03:23.560]  and the compiler would warn you that you don't have a return statement there then just add
[03:23.560 --> 03:32.080]  an unreachable there to tell the compiler this is impossible to reach anyway.
[03:32.080 --> 03:40.240]  Then there is bigger features or beyond library features that we try to make use of one way
[03:40.240 --> 03:48.000]  or another for example the C++ 20 const eval similar to const expression where you have
[03:48.000 --> 03:55.760]  something that should be computed at compile time and const expo is do it at compile time
[03:55.760 --> 04:01.880]  if possible otherwise do it at runtime and const eval is forcing you to do it at compile
[04:01.880 --> 04:07.240]  time and the trick there is if you have a function that has some assert and you make
[04:07.240 --> 04:14.760]  that function a const eval function then if the assert would not hold then you get a compilation
[04:14.760 --> 04:21.360]  error instead of just a runtime error later on or not even an error if you build with
[04:21.360 --> 04:26.760]  the asserts disabled and we make use of that in some places like this we have this color
[04:26.760 --> 04:32.960]  class and I think Noel again at one point tried to get rid of the ambiguity whether
[04:32.960 --> 04:38.520]  it has alpha channel or not so we now have a constructor that wants to make sure you
[04:38.520 --> 04:43.760]  pass in some value that doesn't have an alpha channel in there so we have an assert in there
[04:43.760 --> 04:51.040]  and if we have const eval in the latest compilers then we use it and then we would get a compiler
[04:51.040 --> 04:57.080]  at compilation time error already if you pass in some value that does have an alpha channel
[04:57.080 --> 05:05.520]  after all so that helped the improvement of the changing the code from the old semantics
[05:05.520 --> 05:13.800]  to the new semantics but so we have an if around that if have cpp const eval then use
[05:13.800 --> 05:19.920]  const eval otherwise we use const expo and in our configure script we have lots of checks
[05:19.920 --> 05:25.320]  whether we can use const eval and unfortunately only clang by now even the latest compiler
[05:25.320 --> 05:31.840]  versions we have five checks in there for bugs that we discovered with all these const
[05:31.840 --> 05:40.120]  eval implementations and clang the latest one has all its bugs sorted out but gcc and
[05:40.120 --> 05:48.760]  the Microsoft compiler still can't use it so that shows how if you have a feature sheet
[05:48.760 --> 05:53.560]  of what the compiler support and there is ticks for their adult trust that too much if you
[05:53.560 --> 06:01.960]  then actually try to use it you run into all kinds of issues and then of course coming
[06:01.960 --> 06:09.840]  up is issues there even even bigger way you can't use some if death trickery or some some
[06:09.840 --> 06:17.840]  include file where you approximate things biggest two things that come to my mind are
[06:17.840 --> 06:26.000]  the concepts in c++ 20 which would make code really more readable but which is hard to
[06:26.000 --> 06:35.440]  do in some macro way we have one place I think by now where we have again around this requires
[06:35.440 --> 06:42.360]  thing we have an if death or if we have a c++ 20 implementation that supports it and there
[06:42.360 --> 06:47.840]  is one place where we where we have some function that internally there's some dangerous dynamic
[06:47.840 --> 06:53.560]  casting and you know proxies didn't support dynamic casting so I wanted to make sure that
[06:53.560 --> 06:59.160]  we never use that function on a template type that does that is a you know could be you
[06:59.160 --> 07:04.720]  know proxy so I came up with this wonderful and requires cloth there to to if you have
[07:04.720 --> 07:11.320]  a lady new enough compiler to get that sorted out at runtime and otherwise we ignore it
[07:11.320 --> 07:17.840]  and even bigger thing is modules and I guess we will have to wait for for others to come
[07:17.840 --> 07:25.160]  up with real real implementations of that or real world usage to see how we would make
[07:25.160 --> 07:35.160]  use of them but even if these features are out in the dist in the distant future in some
[07:35.160 --> 07:45.000]  cases still what we already can do is try to force the compiler is hard to to run our
[07:45.000 --> 07:50.360]  code and demonstrate to them that they what what bugs they have worried what bugs are
[07:50.360 --> 07:56.360]  in the standard library implementations if they introduce new things so what I do is
[07:56.360 --> 08:03.400]  opt into this thing to use whatever compiler you use with the latest c++ you version that
[08:03.400 --> 08:10.200]  compiler implements which is typically c++ 23 by now and then have a big matrix of of
[08:10.200 --> 08:16.440]  platforms and compilers and libraries runtime standard long term standard runtime libraries
[08:16.440 --> 08:23.760]  to build on and and find all kinds of interesting bugs whenever I update one of those things
[08:23.760 --> 08:30.600]  and then mail the people mail Jonathan that he introduced something new in lip see lip
[08:30.600 --> 08:36.760]  standard c++ that doesn't get clang that doesn't make clang happy and so forth and these people
[08:36.760 --> 08:48.280]  are happy that we are the guinea pigs for them and that's it I guess we have time for
[08:48.280 --> 08:56.360]  question if there's any questions I'm not prepared for that who do you contact if you
[08:56.360 --> 09:02.440]  find it back in the Microsoft compiler oh they do have a web form now that you can fill
[09:02.440 --> 09:14.120]  in and I think I even got a response monster wow Mike again ski brought that up okay maybe
[09:14.120 --> 09:26.160]  one more question since we're at the end of the track so what's the status of of modules
[09:26.160 --> 09:31.120]  in compilers because as far as I know only Visual Studio does it and does it kind of
[09:31.120 --> 09:41.280]  sort of no I think they're all three by now in their head trunk versions they support
[09:41.280 --> 09:54.960]  them I think they claim it works but I didn't ever try it sorry a module is a new way of
[09:54.960 --> 10:00.040]  organizing your so that you don't have this issue of having all these includes that you
[10:00.040 --> 10:05.960]  need to include this is like pre-compiled a newer version of pre-compiled headers actually
[10:05.960 --> 10:28.240]  yeah yeah that sums it up okay then thanks again thanks