On Mittwoch, 19. April 2023 11:38:48 CEST Vlad A wrote: > That all of those types has to be classes with clearly defined operators
Unit-safe operators would be "nice to have" and I definitely would welcome them, but I don't see them as a necessity. One way or another, they will add a lot of boilerplate code. Either of the repetitive kind or of the intricate template metaprogramming kind. > pressure_t P = currentDepth.getPressure( dive ); I don't see why this would be significantly superior to pressure_t P = depth_to_pressure(current_depth, dive); which is perfectly possible with C, since you can return compound data types for quite some time now. OK, when you compose multiple such calls it might be a bit more readable, but at that point, simply split it over multiple lines. I can't tell exactly why, but calling a member function on a numerical value rubs me the wrong way. > This construction is fool proof. You cannot confuse units. And it's > readable in a glance. It's simple to do, but it will effectively nuke all > .c files, cause you'll loose ability to use those units from plain C. Not at all. You can conditionally compile the operators for C++ code, as we already do in a couple of places. It's not pretty, but it works. It would be surprising if these kinds of changes couldn't be done incrementally in reasonably small steps. Also it might be more complex than it appears at first. See boost.operators for the whopping number of operators one has to support (for each type!). There are a number of C++ unit libraries but I guess they are all designed for floating point values and definitely don't have C-compatibility in mind. Berthold _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
