CppCast - Physical Units and a System of Quantities

Episode Date: October 20, 2023

Mateusz Pusz joins Phil and new guest co-host, Anastasia Kazakova. Mateusz talks to us about his physical units (and quantities) library, mp-units, why v2 is a complete redesign compared to the previous version, and how incorporating a system of quantities is so central to this new design. News clang 17 released Conference videos released in October AMA with Abbas Sabra (automatic/ static analysis) Is it too hard for junior developers to get on the C++ career ladder (Reddit) Links mp-units on GitHub mp-units - Documentation C++ on Sea 2023 video The Mars Climate Orbiter crash p1935 - "A C++ Approach to Physical Units" p2980 - "A motivation, scope, and plan for a physical quantities and units library" p2981 - "Improving our safety with a physical quantities and units library" p2982 - "std::quantity as a numeric type" p3003 - "The design of a library of number concepts"

Episode 370 of CppCast, with guest Matthias Pusch, recorded 19th of October 2023. This episode is sponsored by Sonar, the home of CleanCode. In this episode, we talk about Claim 17, more conference videos, and whether C++ is just too hard to get into. Then we're joined by Batej P. Batej talks to us about version 2 of his Unix library and the follow-on standardization method.

Welcome to episode 370 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Phil Nash, joined by another guest co-host, Anastasia Kazakova. Hello. Anastasia, how are you doing today? Doing good. Good to see you again. Haven't seen you for a couple of weeks after CppCon. That's right. We saw each other at CppCon. Now, it has been a while since we did the last episode. Well, Timur has been away for a bit longer than expected. I had another three weeks of travel in the meantime, and a lot of extra work on top of that, so I didn't have much

headspace. We may talk about some of that in the future, but yeah, sorry about the delay there. Funny enough, I did actually take my audio recorder to CppCon, so I could try and do some ad hoc interviews while I was there, but my SD card broke at too short notice to get a replacement. And I made the cardinal sin of not taking a second card with me. So I missed the opportunity, unfortunately. But we are back now. Timo is probably going to be away for one more episode after this. But it's, well, we've got Anastasia here today.

It's appropriate that we have her because not only have all three of us worked together at JetBrains, and Anastasia is still there, of course, but we hosted another show together, No Diagnostic Required. going to be that Timo was going to join us as a third co-host which never happened because some things came up for him as well at the time that delayed things by the time we were ready we're already talking about taking over CppCast so it just feels like now we've sort of got some closure on that whole thing so finally yeah yeah finally we did that so maybe we meant that that day so who knows what we had in mind yeah but good to be here back and good to co-host with you, Phil, again. So yeah, we did lots of episodes of NDR. And actually good to be back to CBPcast now as a co-host. That's something new to me. Well, thanks for stepping in.

Now, at the top of every episode, we do like to read a piece of feedback. So this one is from Robert. We had him come in by email. And he says, I love your show. Since I found out about CPPcast a couple of months ago, I've steadily been working my way through present and past episodes. And in every episode, I find some link that I want to explore further. As Francis Bontempo said, now I have even more tabs open in my browser.

One thing I wonder about is that, seemingly, has not covered Qt-related topics in a long time. I'd be interested to know more about their plans to make use of C++20 and C++23 going forward, especially modules support. That is an interesting question. I don't think we have had, certainly not in my time with Timo or anyone talking about Qt. So probably it's about time that we get some coverage of that again. And I know there's lots of interesting discussion about awesome modern C++. So that could make for a good episode. We will consider that for the future. Thank you, Robert. So we would like to hear your thoughts about the show. You can always reach out to us on X, formerly Twitter, Mastodon, LinkedIn, or you can email us at feedback at cppcast.com. Joining us today is Mateusz Puszcz.

Matt's a software architect, principal engineer, and security champion with more than 15 years of experience in designing, writing, and maintaining C++ code for fun and for a living. A trainer with 10 years of C++ teaching experience, consultant, conference speaker, and evangelist. His main areas of interest and expertise are modern C++, performance, low latency, safety, and maintainability. Mateusz is the head of the C++ Competency Center at EPAM Systems and is also the founder of TrainIT, providing dedicated C++ training and consultancy services to corporations around the world.

Matt is an active voting member of the ISO C++ Committee, and he mainly contributes to LEWG, that's the Library Evolution Working Group. So Matt, welcome to the show. Yeah. Hello. I'm happy to be here again. Thank you for inviting me. Yeah, welcome to the show. Yeah. Hello. I'm happy to be here again. Thank you for inviting me. Yeah.

Welcome, Matt. It's great to have you here. And actually, I have a question regarding your training experience, because you're a very experienced trainer, working many years and training C++. So as an adapt of the modern C++ standards. So quick question, which C++ standard do you usually use in your trainings? And if there's something coming from you or requested by your clients, if the latest, what they do request usually?

Well, that's a tricky question, right? I typically try to teach so-called modern C++. And I always say that modern C++ started with move semantics and C++ 11 additions I always say that modern C++ started with move semantics and C++ 11 additions that we got. Right? So we cannot talk about move semantics, modern

C++ without move semantics at all. And I try to teach people how to write correct code, code that's correct by construction, easy to inspect and easy to maintain after that. For this, we don't need new features like C++ 20, 23, and so on. Of course, those are really interesting ones.

But in most cases, people, projects are not there yet. And the amount of subjects that are needed for such a training typically ends up with a training for five days for a corporation. Because corporations say that they want to learn often from starting with move semantics up to, I don't know, multi-threading or C++20. It is impossible to actually teach both C++20 when you know that move semantics is not there.

Right? So in five days, you have just limited scope and you have to start with something. And this is my advanced model C++ course that we are talking about C++11, 14, 17, but mostly scoping on the language to understand how it works. And this takes entire five days.

I have another five days training only for C++20 because this is huge material to cover, right? I could try to merge those, but then I will never fit like in one week with everything, right? So I'm providing like an example. By the way, this is how it will look in C++20,

but I'm not teaching C++20 on my primary course just because lack of time. if the production will catch up and I will not have to talk about move semantics anymore I will have some time to introduce C++20 to my let's say basic training okay yeah good to know yeah I think Jason Turner has a similar story people ask ask him to come in and do training in advance C++, but by the time he's had them answer a few survey questions, they really need the grounding and the fundamentals first. And so that's what they focus on. So it seems to be a common thing. Yeah, yeah, indeed. Okay, so we'll get more into what you've been up to in the next few minutes. But first,

we've just got a couple of news articles to talk about so feel free to comment on any of these okay so first up this is not actually new news but since we've had a bit of a break since we last recorded clang 17 has been released and i believe it's actually now to 17.0.4 is the one that i uh i downloaded yesterday and obviously this is this is quite big news in general, but it's particularly interesting to me because as a hint to that, last time I've started work on Catch-23 and I'm using C++ 20 and 23 features. And one of the problems I had,

and I'm sure you can relate to this, Matt, is half of the code base compiles with Clang and half of it compiled with GCC and neither of them did both. But now, at least for Catch-23, what I've done so far, compiles with Clang and half of it compiled with GCC and neither of them did both but now at least for Catch-23 what I've done so far it all compiles with with Clang 17. So are you finding the same thing Matt? Yeah it's similar but you forgot about the third one on the market here none of my none of my code actually compiles with MSVC. Right yes I was

going to say I think most of mine does but but I don't actually have an installation of that because I'm not running on Windows. Right, but Clang 17 actually was a deal-changer here because with Clang 17, I could get rid of all of my workarounds and hacks in order to make Clang work. So with Clang 17, it's just working with pure entire interfaces

that I intend in my library for C++ 20. And also, according to my knowledge, most of the module stuff that we still have on the branch work also fine with Clang 17. Right. That's good to know. I haven't got into the module side of it yet, but I did say there was some big news on that side.

Yeah, I think Clang 17 is quite a nice step forward as we work towards some level of conformance across compilers for C++20. It's nearly 2024 now, so it's about time. Okay, so the next one is more conference videos. So we talked a little bit about this last time, the C++1C videos were starting to come online. In the meantime, we've had CppCon, and even the videos from there are starting to come online in the meantime we've had cpp con and even the videos from there are starting to come out now so we've got the the keynotes most of them are up uh one or two others as well but also there's a whole stream of videos coming from cpp north c++ now accu more c++ on c

videos and just as a little teaser one of the c++ on c videos that got released i think just last weekend already has over 110 000 views so somehow got picked up by the the youtube algorithm i'm not going to say which one it is it's your job now to go find that out i have a guess i haven't checked but i have a guess it shouldn't be too hard to find but there is a page on reddit that i'll put on the show notes so all of the videos for all of these conferences are being released this month. So if you're keeping up, that'll be the place to go to. Okay, next up, also on Reddit,

I'm only going to mention this briefly because by the time this episode is released, it's already going to be over, but there's an AMA, if you can ask me anything, with Abbas Sabra, my colleague who was on a couple of episodes back, who was going to talk about automatic analysis, static analysis in general.

So that's going to be going on not long after we finish recording this. So it'll be done by then, but I'll put a link into the archive of that for anyone that's interested in following up. And then the final thing, it's not really news, it's again another Reddit page. i did a lot of

spent a lot of time on reddit this week this one caught my interest because somebody was talking about how hard it is to to get into c++ as a junior developer not so much the language although that does put a lot of people off we're just getting into the career ladder because so many roles seem to require a lot of experience or domain knowledge or both but at the same time one of the things came out in the comments still a lot of people trying to hire for C++ roles finding it very difficult to to find competent people so it seems to be a bit of a mismatch between these two things. This is a subject that does come up from time to time seems it's still true and I think part of it is just different perspectives on things.

But what do you two think? Is this really a problem for C++? Are we going to die because we're not getting enough people coming in at the bottom? I don't think we're going to die. I mean, I think we have this problem for ages. We're lacking people and also the people who hire are lacking people, but also the people who study C++ lack the proper positions.

But I would maybe redirect that to Matt, because as a trainer, you might see a picture in death and understand what's going on there. Yeah, actually, both perspectives here are valid for me. So as a trainer and actually as a C++ Competency Center head, where I try to actually hire good people to our company. And yeah, so there is a problem because a lot of companies struggle to find good, experienced engineers.

On the other hand, there's plenty of engineers that are looking for work and cannot find any, as you said, right? And there are two possibilities. Either we have to lower our requirements for the job or change our interviews, the style of how we do interviews, because typically I see also this is an issue for many corporations. They, for example, love to ask those problem-solving tasks or brain teasers, right?

That actually I do not help much in C++ domain often. Or ask about Gang of Four book with all of the polymorphism stuff being there. I'm not trying to say that the design is not important. It is, but it should be done how it's being provided in the latest books by Klaus Igelberger, for example. Not how Gang of Four described this in their books.

The fact that they use C++ was only because this was the only, let's say, object-oriented language at this time the book was written, besides Smalltalk, right? But this book is more appropriate for languages like Java or probably C Sharp than C++ by itself. If you want to learn how to do design properly, go to the Klaus book and you will find how the design

should be done in C++ properly, even using the same patterns. Right? But asking about that on the interviews actually do not provide you good employees and also does not allow you to hire good employees

because good people will tell you that basically this is not important, that polymorphism is bad, and if people are fixed on those design patterns from this book, they will just not hire this person because he doesn't know how to do polymorphism, right? But this is not how you should write modern C++ code. And on the interviews, we barely check for C++ skills that allows you to write safe to use, easy to maintain code.

For example, I often ask someone to write simple wrapper, like RIAI, right? Resource Acquisition Insatiation Wrapper. Something like a simple unique pointer, whatever. You have one member and make it easy to use and hard to abuse. Most of the people coming from the interview

don't know how to do it properly. They forget about special member functions. They forget about destructors. They forget about checks in assignment operators. And such people cannot be allowed to write the code by themselves, let's say, without any supervision, because this code will leak and will be allowed to write the code by themselves,

let's say, without any supervision, because this code will leak and will be unsafe to use. And I would encourage everyone to actually improve their skills in this domain and also on the interviews to ask for those skills, because first of all, the code has to be safe to use, easy to maintain, and after that, it has to be fast. Right. Right? And we should change the ways how we think about interviews and also invest in the education of people. If we cannot find good

experts, maybe we can hire graduates and invest in the trainings for them. In the end, it may be cheaper for the company because you are not paying graduates as much as experts. So just invest some money to do upskilling of them. I spent like two weeks in London last year upskilling graduates for one of the HFT companies there. And it has a lot of sense as well. Yeah, and I think we have to match, like that's a very nice word about matching the

expectations and the goals because we know that which standards are used the most so if the company is say on c++ 11 no need to dive on the interview into the modern things if you're not going to be great there what's the sense like what are you checking for so if you are going to like migrate to c++ 70 or C++20 or whatever, then yeah, there's like, you need someone who knows how to do that, who knows like the new things and why they're there so that they're able to migrate. Because maybe they will work in on say C++14

as the majority of the people for many, many years and they just like can't adapt. And that will be a very painful migration then. I remember I was working in the company where we used to you know to remove all the people's c++ code when they were leaving the team because it was cheaper than to maintain it so uh like when the person was leaving it was like okay we'll just remove that because we can't maintain that it's too complex so it's like much easier just to write this part to update it and that's not uh that's not right i don't want to do that yeah exactly yeah another point here

is that uh in in case you are planning to change a work change job uh and you are stuck in the c++ 11 or c++ 98 project, you have to spend some time by yourself to learn modern C++ because you will not find work on the market because plenty of projects moved on and plenty of interviews require later

skills, right? I always say if you depend on an employer or a university to teach you C++ and you don't have to do anything by yourself, you are wrong. Find a pet project or contribute to open source, do anything that allows you to stay current and even if you don't need it at the current work.

Yeah, I think that came out in the thread on Reddit that you need to keep your skills current with extra work outside of your working hours. Yes, in a anyway to to stay relevant and it shouldn't be that way but i think it is in certainly in the c++ community so that's uh that's one tip for people looking for work and just to summarize what you say i think there's a there's onus on us when we're in the hiring role to look for the right skills and not just look for the thing that we think is cool or follows our own personal preference but the actual getting the fundamentals right so yeah i think this is going to be a topic that comes up every year but uh

we'll we'll leave it for now we've got some uh some more meaty topics to get into today, so we'll move on to our main topic. So, Matt, you've been on CPPcast before, back in 2020, and back then you were talking about your physical units library, MPUnits. It's now 2023, and you're on to talk about your physical units library, MPUnits. So what's changed in the meantime? Well, actually, through last year,

I was working first on the branch and then on the mainline on so-called version 2 framework. Version 2 framework is a huge change comparing to whatever you've seen before in this library. So that would have been v1, wouldn't it? Yeah, it even wasn't v1.

Actually, it was 080 before. We skipped v1 in our version scheme. I didn't want to release v1 because it will provide impression that this is an evolutionary change of the stable interface of what we had before. But it's a totally different project written from scratch,

both code and the documentation. I could start Ranges v3 from scratch in GitHub as a totally different project written from scratch, both code and the documentation. I could start like ranges v3 from scratch in GitHub as a totally separate repository with mpunits v2. But I decided to be on the same repo. I just make the major change in the naming of our versions to make sure that everyone understands that this is a huge breaking change because it breaks every single user's code that we had before.

And I'm really sorry for our users because of it, but hopefully for better. So, I mean, just very high level then, what sort of things have changed? We'll get into the details in a bit, I think. So, first of all, we removed so-called the downcasting facility that I was talking a lot about on different conferences. I still believe it is a really interesting and nice feature, but not useful for the physical

use library. We introduced systems of quantities that is a unique feature in our library that none of the other libraries have it. We have really been based right now on class types and non-type type parameters, which is the C++20 feature. It improves interfaces a lot. So everything composes now nicely with arithmetics, operators, multiply, division and so on. We improved the quantity construction helpers, improved readability of generated types.

We provided many additions, like a feature that we called faster-than-light-speed constants, which actually improved compile times comparing to DABU. I mean run times, not compile times. And improved safety of interfaces, so interfaces are even safer than before, safer than Stute Chrono provides, or typically other libraries do. And many other changes, smaller ones.

Well, that is quite a lot. Some big breaking changes there, I can tell, but it sounds like all for the right reasons. But before we do get into the details, could you just give us a quick overview again of what a Unix library, what problem that's actually trying to solve? Sure, of course. So, I don't like to talk about this only about Unix library because it's not about Unix. If there are libraries on GitHub or on open source

in general, if they scope only on Unix, typically they fail to be able to model things that they want to achieve. That's why I always say that the libraries that we provide right now is quantities and units library, because quantities and units are better models. And we are going to talk later about systems of quantities,

as you said. But this allows us to provide additional type safety and conversion rules and possible to express ourselves in a better way. Unilever libraries are about compile-time safety in all of the possible stages. We have strong typing that prevents reordering of arguments. We allow restricting correct operations on typical types. And by this, I mean that, for example, we can model things like affine space, where you have quantities and quantity points, and those have different set of operations.

Like, for example, you are not able to add two quantity points. Quantity point is similar to time point in Chrono, right? Adding two time points doesn't have sense, so the same comes from quantity points. We are having support for vector and tensor quantities. They have also specific operations like dot product

and cross product and other things, and we want to make sure that all of the conversions are done correctly. We prevent accidental truncations of the quantity value in such libraries. So you have to be explicit in conversions. For example, like you have duration cast in chrono to say that I want to enforce some unsafe conversion.

Otherwise, the code will not compile if the value can be truncated accidentally. And also there are strict and automated conversion rules between different entities. For example, kilometers convert to meters, not the other ways around because this is

truncating operation. And while you are doing this conversion, the value will be automatically scaled by the ratio, by the magnitude of the unit. Right?

But also it's not only about units. Talking about quantities, we have things like radius and the length. Every radius is a length, but not vice versa. So you should not be also

allowing the conversion in other way because, as I said, not every length is a radius. Right? And those libraries, of course, are about performance.

As I said, they should be as fast or even faster than double. And it's possible to be faster, for example, thanks to those optimizations we can do for constants I mentioned. And those are also important for the market because

they are so-called vocabulary types. So they allow different companies to talk to each other through standardized interfaces. Imagine a world without string or a vector. If one would have their own versions in their companies,

typically we would not be able to communicate between different products from different vendors. And this is exactly the same case, right? Yeah, I maybe have some very basic question here, but just I'm trying to understand. So to me, the whole library looks, I mean, the principle,

the goals it has created looks very similar to Stuttgart, right? So all these safety arguments, all these conversion arguments are still valid, like both of them. So is there something different for this library? I mean, like in the approach and the goals compared to Stuttgart, or is it like just following the same trend and just like continue this kind of tradition? Yeah, that's a really good question.

We started as being compatible with Stuttgrona as much as possible because this is the best probably part of the standard library. It is my favorite one. I would say if you want to learn more about C++, go and learn how Cronos is being done because Howard Hinnant and also Walter Brown contributing to this did it really, really great.

Right? But time has passed. We learned how to do some things better. We got also better abstractions in the language. For example, through entity piece being able to be passed to the templates, right? Yeah. So the more time passes, the less

consistent with Stude Chrono interface as I am. I'm providing better safety than Stude Chrono. I, of course, support more dimensions and quantities than because Chrono is only about time. Right? But

also plenty of practices that were new and great in C++11, like UDLs, for example, right now are not the valid choice for physical units library. So you should not use user-defined literals for units in general. Interesting. Yeah, okay, thank you. That kind of explains the ego for me. And the other question I had was about the system of quantities.

Maybe you can just explain on the basic level again what it is and how you use that, what's the main point for that. Right, yeah, so system of quantities is quite an important thing that no one before thought about, which might be interesting, as you said, right? Most of the libraries support so-called dimensions. And dimensions

are physical dimensions. We have seven of them in, let's say, typical physics. And each of them is having SI-based unit assigned to be basically used to measure this dimension in specific units in this system that is international. However, it turns out that in many cases dimension is not enough.

For example, consider quantities like frequency, activity, or bitrate, all of them are measured in the dimension of one per time or time minus one power. So in theory, you could be able to add them or compare them, which probably is wrong. You don't want to be able to compare radioactivity with bitrate, right? Not usually. Or for example, if you are

measuring the fuel rate of your fuel consumption of your car, you have, let's say, dimension and unit like liters per 100 kilometers, typically. So this is volume per length, so an area. Would you like to be

able to assign to fuel consumption the area of the football field? In some cases, that might be useful. So if you're talking only about dimensions, it is not enough. Right? So it turns out that there's a standard. The standard called ISO 80000. So the same institution that the C++ standard is being done.

And this standard provides hundreds of different quantities that are standardized and actually are claimed by both this standard and the SI to be the base of the SI system for units. So SI is known to be based on so-called ISQ, International System of Quantities. And this is what we're trying to model in this library. So we may have many quantities of the same kind, like frequency, activity, bitrate, or fuel consumption, and area being totally different things.

Or we may have also many quantities of the same kind. But because, for example, as I said, radius and length and altitude and displacement are totally different lengths and you don't want to mix them as well. And also when you want to create direct quantities from them, you don't want to say that I'm creating some radial-based derived quantity from length. You probably want to use radius

directly in the equation for it. And you may say, I want this direct quantity to be created only in case I'm dealing with radius, not with any length. Because it doesn't have sense to create a radial quantity from width. So all of this gives additional safety,

but it was quite hard to figure out. The design part of it took me most of the time, not the implementation. Because no one ever did it. This was a new problem to be solved. And we have to find out how to do it correctly, how to make conversions work how to make the comparisons addition subtraction work correctly so it is both safe

but also easy to use because it's easy to be like strict saying everything has to be always the same type everywhere but then you end up with plenty of explicit casts everywhere and the library starts to be barely usable. Okay. And you mentioned it took you quite a while to move from version 1 to version 2, or how is it, 0.9, right, to version 2. So is there still a big roadmap ahead of you? I mean, do you have other big, maybe significant changes planned?

Will it take another how many years? Yeah, sure. We are still far from being done. There are plenty of discussions being done on our GitHub. So if you're interested, I welcome everyone to go and see our issues that we are discussing there. Right now, we are trying to find out if you can do something that will be type safe, but still easy to use for non-negative quantities. Because the ISQ specified some of the quantities as being non-negative.

Like, for example, width. That shouldn't be negative, right? And magnitudes of vectors probably will also not be negatives because those are magnitudes. And maybe you can optimize based on this. Of course, those will be checked probably negatives because those are magnitudes. And maybe you can optimize based on this. Of course, those will be checked probably at runtime, maybe with contracts if we get them. But still,

it adds some additional safety to the operations. But everything is tricky because you may say, for example, height, I like a person height, probably should not be negative, right? It's how to imagine a person that has negative height. But on the other hand, if you will have like a set of heights, and you would like to compare if the second person is taller or lower than the previous one,

you may end up with quantity of height being negative because someone is two centimeters lower than the previous one. So when the negative quantity has sense and when it doesn't have sense, right? And how to work with that. This is an interesting, again, design discussion to find out how to make it correctly, because probably implementation will be quite tricky and easy. I meant not tricky. Tricky is the design. Another issue that we are working on is

the improved algebra for vector and tercent quantities. For example, most of the libraries assume that in case they are working with linear algebra, the quantity they provide is being put into the linear algebra

type by itself. So if you want to create a vector of lengths, you put three quantities of length inside. So you have like three quantities of meter, meter, meter, and this is your vector. But this is one of the ways to do it. The other way is to put linear algebra type, assuming

we'll get one in the standard at some point. Right now we have to have non-standard solutions, into quantity type or a duration type you have in chrono as a representation type. And then immediately everything breaks.

And none of the libraries in C++ domain covers this correctly. Right? Consider that some quantities are created by operations like dot products or cross products.

And this is fine, but those libraries model that as multiplication. And this is fine, but those libraries model that as multiplication. And then immediately if you do multiplication of displacement and possibly some velocity, both being vector quantities, and this tries to do the multiplication on the representation types under the hood,

it will just not compile because any algebra will not provide you multiplication operator for vectors because there's no such operation in LinearGebra operations. So what actually should be provided are the

functions, probably named functions, like dot product, cross product, because you don't want to mix them. This is the same like mixing multiplication division in terms of scholars. The same is dot and cross product in terms of vectors. You can do both on displacement and velocity, but you will end up with different quantity type

and different value. Right? So as we expect every physical use library to protect us from accidentally doing multiplication instead of the division, we

should also expect this in vector domain for dot product, cross product. But the only library that actually models that is

pinned in Python. None of C++ actually does it. And you're trying to find out how to make it properly right now. So it's, again, easy to use, but safe. So you have to find some compromise.

That's interesting because Python is a language where you can multiply strings. Yeah, exactly. But they have NumPy. If you had NumPy in C++, or some physical or some linear algebra library in the language, I'm sure that people will start to care more about quantities of those types. But as we don't have anything in the standard for now, probably people don't think about it too much.

Are you contributing to the effort to standardize linear algebra? I work closely with Bob and Guy on their proposal. I mean, I'm also the contributor, but provided a lot of feedback for them. Hopefully they will progress at some point, but right now we are having a new proposal based on BLAS that was accepted by the Evolution Group and hopefully will be the part of the C++26.

However, this is a library that will probably not help me too much because this library is more scoped on data crunching. Like you have huge matrices of spans, so non-owning things. And this is not what we need. We need a simple owning, like three-dimensional vectors, for example, right?

And this is not provided by this library. So we need to provide some wrappers, owning wrappers, by ourselves maybe. And which standard does the library currently target? Because you mentioned many things which are not in the standard, which are interesting to you, like the contracts and the linear algebra

and what's the current standard for the library? Well, this is tricky. You were not expecting me asking easy questions, right? Yeah, this is tricky because there's plenty of work ahead of us. We're still working on number concepts and C++ modules and plenty of things. So we are still also not ready with the design. There are plenty of dependencies and plenty of quantity-specific logic that has to be described in the papers.

We'll be talking about papers later, probably, but those are huge already, and there will be even more to come in the future. All right? So it would be great to be able to be in C++ 26, but realistically thinking, we don't have a chance to get there. But on the other hand, I was told that

if you will not be targeting C++ 26, no one will be eager to listen to us in the next two years. Because they want to finish C++ 26, they don't want to talk

about C++ 29 features now. So we are officially probably talking that we target C++ 26, but we'll hope for C++ 29 you'll stay

quite safe with us don't worry we won't tell anyone yeah just don't tell don't tell anyone so we've

been keeping it mostly to high level concepts about units and algebra and so on but it's very difficult

to talk about the concrete code in an audio podcast. But one thing I did want to touch on, so I did watch most of your C++ on C talk, which I'll put a link to in the show notes. I think you did the same one at CppCon or something similar. What I really liked was the way you combine this feature

where you name your types the same as a value of that type, and then you can refer to that in non-template type parameters to give you a really nice sort of algebra of effectively types, but you're actually using values. Do you want to talk a little bit about that, how that cleans things up? Well, this feature is controversial, probably. I'm not sure how the committee will react on this one, right? Because this is an old legacy from the C language

that we can name a struct and we can provide the identifier for them with the same name and do it in one line even. So this actually helps me a lot because I can say every entity in the library can be created with one line and that's it. So this is really easy to build new systems, extend current systems, and so on.

However, it doesn't extend to templates, for example. You cannot have a template and a variable with the same name. For example, you cannot name a variable of vector of int as a vector. Even though for structs it works. So in some cases, there are limitations and they will need more than one line for entities. And this is some inconsistency. But we can do it in one line as well.

But at least for most of the things it works. And the rationale to do it actually is that the library by itself provides those objects to the users. And the user always, in the code written by the user, always deals with only values. So the user never has to actually refer to a type. But the types are what is being visible in compile-time errors or in a debugger. And we want to be able for the user to easily be able to match the code they write with the error code message they see.

If I use the same identifier, they even don't have to know that actually there is a trick that compile-time error provides a type and the code has value. It is named the same, like length or meter. And then it just looks really easy and nice. Yeah. But I'm not sure if it will fly in the committee. If not, we'll see compiler error messages with something like meter underscore T and length underscore T everywhere, right?

This is what we do in the standard. Yeah. Well, I'm hopeful because I think it works really nicely when you do things like meters divided by seconds and you're dividing two values and you're passing that as a parameter to a template and you get the right type as a result of that. That's a really nice way to do it.

Exactly. And you observe exactly the same identifiers in the type that you use for a value. Okay. Well, we're going to get back to talking about units in a moment, but I'm going to take a brief break to thank our sponsor. This episode is once again sponsored by Sonar, the home of clean code. Now, Sonar Lint is a free plugin for your IDE and helps you to find and fix bugs and security issues from the moment you start writing code.

But you can also add SonarCube or SonarCloud to extend your CICD pipeline and enable your whole team to deliver clean code consistently and efficiently on every check-in or pull request. SonarCloud is completely free for open source projects and integrates with all of the main cloud DevOps platforms. So back to talking about Units. Now, you mentioned that, I think you even mentioned this the last time you were on the show, that you wanted to standardize some sort of Units library or Units handling.

What was the current status of that? Are you still working on that? Yes, right. So I written the first paper in 2019. It was the paper number 1935. And this paper was mostly to do the homework, to prove that I did the homework to the committee, to describe what is the status of the libraries, how the domain looks like, what are the challenges, what are the issues, what are the possible fixes for them. But I never mentioned actually my interfaces that I would like to standardize. And talking about the standardization, the standardization by itself is not like my

ultimate goal. I'm not writing this library to be in the standard. I'm doing this library to solve the issue, to solve the problems we have in the production. If it were to be standardized, by the way, it would be nice, but it is not my ultimate goal. And also, this is why the library right now uses probably some names

or practices that may be a bit controversial in the committee and we'll have to refactor if the committee agrees to actually have it in the standard. And I didn't come back to the committee of new papers for a while, for like the last four years, because I was not happy with the current design.

The v1 version was not ready to be part of the standard. It was not only my opinion, but also others. And I had plenty of issues that I couldn't address with v1 on my GitHub repository and was looking for a better solution. And now we have version 2 and I think we are finally ready to standardize this in the standard. I'm talking we because it turns out that when v2 appeared on the market, I was able

to contact the authors of all of the major libraries on the market to work together on a unified proposal for the committee based on my repository. So we have on board a Nick Holt House that has probably the most successful library ever that is actually maintained. I'm not talking about the Boost units because this is quite an old one and it's not actively maintained anymore. But talking about the actively maintained ones,

Nick Holt House has the most probably successful ones. Also, we have Dominik Berner from SI Units. And we have Chip Hawk from Aurora Units Library on board. So you're having four authors, including me. And when I counted last time, we have like 90% of all of the stars

on GitHub for C++ in this domain. Okay. So this makes us quite great GitHub for C++ in this domain. Okay. So this makes us quite a great power force to work on this one. And also we have contributors and advanced users in the group and physicists and computer scientists that help us to actually craft those papers. And for upcoming meeting in Kona, which will happen in November this year,

we prepared three papers. One of them is the paper about the scope, motivation, and some plan for solidization, and it's targeted to LEWG, so Labor Revolution Working Group. And we also have two other papers that target safety and numerics groups.

And each of the papers is longer and longer, so the numerics one is a monster. You can check by yourself. It's like, it's the number, it's 2982. And how do you measure the length of a standards paper? Yeah, it is huge and it's still not complete. There are some chapters missing there. We just don't have enough time to finish everything.

And maybe also we don't want to scurry everyone right away because this subject is deeper than many of people think when they say that we actually want to target c++ 29 to lewg people they say well we still have like five minutes for five meetings for c++ 26 just do it there's plenty of time i say well that's a huge subject you don't even realize how huge it is yeah and this big group like from different libraries working on well, that's a huge subject. You don't even realize how huge it is. Yeah, and this big group, like from different libraries working on these proposals, does that mean that you managed to agree on some common design

and eliminate any inconsistencies or differences between the library and these common papers? Yeah, this is mostly based on the MPUnits v2. They say that they like the interfaces. Of course, we are not claiming that what we have in the library right now is the final thing we are going to provide. There may be some polishing being done, some minor changes to be discussed.

But we plan to provide first API papers in Tokyo in March next year. And hopefully until this time, we'll be able to polish those things and provide the final interface for at least the most basic things in the framework. I see, yeah. And I just, I'm sorry. Like, I wanted just to ask about

the goal of decentralization, because you said that that's not your primary goal, like with the library, but still, why do you think it's important to get the MP units in the standard? Why it's important to standardize? Why we can't just live with just library? Right, so the first paper, 2980,

actually describes the motivation in detail, why we actually think it's important for this to be standardized. But to be brief, I will maybe mention a few things. First of all, it is about bringing safety to C++, right? There are plenty of possible issues that are possible right now to be done in the code, and probably right now even more than ever. We are living in the world right now that we start to depend more and more

on autonomous vehicles, machines with our lives. With this, more and more C++ developers are exposed to writing safety-critical, life-critical software. And typically, either they like experience or actually, anyway, it's really hard to do it even if you are an expert.

So having additional safety in your hands that will prevent simple errors or sometimes even more complicated errors at compile time would be great. Right? Second of all is about having vocabulary types, right?

C++ standard is to provide standard interfaces to be able to communicate between different libraries, between different vendors in a standardized way. If vocabulary types are not the thing, then what should be standardized? And

I mentioned that this library is mostly about being vocabulary types. Those are the things you want to put in the interfaces to say I expect a quantity of length in kilometers or miles or whatever, right? And if you have software written, like, let's say, by NASA and Lockheed Martin, no pun intended, right?

They want to be able to be successful in their next space mission that we'll provide. Right? Yeah, that's true. Actually, I've read these nice critical examples mentioned in the paper, I guess, in the very, very beginning, which just mentions this. Quite catastrophic situations, which happened because of several inconsistencies in the measurements.

So I was just wondering, I I guess that the goal of the standardization is just to push more people to use that, so that they definitely with it. But are there other ways, I guess, to help the adoption? I mean, is the library in like Conan VC package? So if I want to start using it like right now, what should I do? Well, it is in both.

And actually, it's also in Compile Explorer. So you can get it easily from Conan. You can get it from VC package, although I'm not sure if they have version 2.0 or not because I'm not that current with the VC package status right now. But you can always try to hack in Compile Explorer and find out if you like it or not. Try it out.

Make maybe some simple proof of concept. And then if you are satisfied with the results, try to get it to the production or some proof of concept code you have on your laptops or servers, right? A couple more questions. First of all, I presume you have unit tests for your library. Are they unit tests for your library. So are they units, unit tests? Yes. Exactly.

And most of them actually are done with static asserts. So sorry, I'm not using most of the frameworks there. But for the rest, like for the formatting things that still is not concept in the standard, I'm using catch. That's good to know as well um uh no i just um i just wanted to continue with this thing of adoption because i'm thinking like what is more

important to get the library into the standard or to get it like uh for all this package because i think this is super important to get the latest version of the library in the package management because that's what usually stops people from you know proper usage like the standard yeah it's like good to direct people and i think it's great that we have chrono we have fmt and i think these are fantastic examples so and would be good to have your library there as well but i mean like all these practical things of how to start using the library is uh also very important because if you take a look like we at their brains and foundation like we always ask people every year how do you use the libraries like how do you compile your uh third-party libraries in your project and so many people say

that like yeah they're still taking the as a code and just compile with the whole project and that's the major point pain point in the language for them. So I think that's much more important to have it in all these package management systems and in all these easy ways to get it installed. And Compile Explorer is also like a great way so you have this kind of playground. So I think this is the same importance

or maybe even more important than getting it to the standard. So because if I can start using it right now, I will probably do that, not waiting for C++ 29 or whatever standard you target, actually. Yeah, that would be nice. Yeah, I totally agree. That's why we care about providing our library

in the package managers. I'm mostly familiar with the Conan. That's why I'm making sure it's there. But VC package, I know that it also works. However, it's not the case for everyone that they can use just package managers and open source software, right? We are having some

domains, especially for those life critical, safety critical missions that I said that they cannot actually take anything from the open source and just use in the production. Having non-certified libraries is not an option for them. Okay. And for those customers, actually having this in the standard

would help them to actually be able to use them in foreseeable future. Yeah, that makes sense. Then you have a bit of a chicken and egg problem because for standardizing, one of the prerequisites is usually that we're standardizing existing practice. So you need sufficient amounts of existing usage outside the standard. Look, I figured out a way.

So you put to the package management, you force people to start using that, then you push to the standard, and then those who can't use the open source software just start using it. It should be working, right? Yeah, but actually actually i think we are starting to take existing practice right now right now maybe the library uses some novel c++ interfaces using the latest features but we are having these libraries for ages in the c++ language right on the market we know how to

handle this we know how to use it and And as I said, we are having right now 90% of all of the stars on GitHub in our team. So we have plenty of experience in our team to find out how to do it correctly. Yeah, but it all sounds good. And I'm glad that you're going to great lengths to push this through. So thank you for that.

I do encourage people to go and watch one of the videos of your talks about this, because obviously you're going to a lot more of the code and some of the specific techniques we haven't had to get into here. So I'll definitely put some links in the show notes for that. Yeah. And also great docs for the project. Yeah.

Don't forget the docs. So just, just before we wrap up, what else in the world of C++ outside of Unix do you find interesting these days? Oh, well, we are living in really interesting times lately, right? All of those successful languages, all of those discussions about safety, about error in use behavior

are really interesting to see and observe. I'm really interested to see how it will move on, when we are going to end up in like two years from now. Are we going to work in some TypeScript languages that are built on top of C++, or maybe C++ will actually try to be more agile, do maybe some more brave and maybe breaking changes. By breaking, I mean

breaking APIs, maybe. Right? In order to improve safety and performance in the future. Otherwise, we may end up in doing Rust, which is also a solution at some point. Yes.

I think the whole question of do we have, do we have the ABI break, as well as breaking some more backward compatibility at source level as well, well, we don't need to do that enough, I think, that could still be back on the cards, despite what's happened in recent years. Yeah, I would love to get epochs in the language. Or something very similar to it. Yeah. We definitely need some way to diversion sem get epochs in the language. Or something very similar to it. Yeah, yeah.

We definitely need some way to version semantics or syntax of the language in some way, I think. We just haven't figured out what that looks like yet. But we'll work in C++ because epochs hit a hurdle that it couldn't get over. But maybe something else will get past it. So I'm very interested in that space as well. Okay, we should wrap up. Before we let you go, anything else you want to tell us or any ways to reach you? People want to find out more.

If people want to reach me directly, you can find me easily on LinkedIn or on the Discord, like inclusive++, right? But in case you have any questions or feedback regarding the project, please feel free to go to our GitHub repo and provide some new issue or discussion thread there. We are going to

answer and provide some feedback for you or help if you need to get one to get you started with the project. Great. We'll put all those links in the show notes as usual. So with that, thank you very much

for coming on the show for us today, Mateusz, and telling us all about the latest in MP units. Thank you very much. It was a pleasure. And thank you, Anastasia,

for the co-hosting. Okay, guys. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast please let us know if we're discussing the stuff you're interested in or if you have a suggestion for a guest or topic we'd love to hear about that too you can email all your thoughts

to feedback at cppcast.com we'd also appreciate it if you can follow cppcast on twitter all those links as well as the show notes can be found on the podcast website at cpp