kicad-developers team mailing list archive

[Simon Richter <Simon.Richter@xxxxxxxxxx>]

Hi,

On 13.02.20 16:06, Thomas Pointhuber wrote:

> The solution discussed was to move to 64bit and to use
> constexpr/templates handling unit conversion. So a programmer can for
> example enter 2mm and the compiler automatically converts it into the
> internal unit like nm.

> I'm still in favour of improving this. The same with angles.

Angles have to go first, because we have many different representations
based on lengths, and several of the 2D representations have overloaded
"rotate" functions that consume an angle -- so if we were to add new
length/vector/size/distance types, we'd need to add more "rotate"
functions for all of these as well.

For angles, this is somewhat complicated by the fact that we have three
different representations (radians, degrees, tenths of a degree), and
the latter can also be floating point or integer. Adding new classes is
somewhat[1] straightforward[2], but the code actually using it is full
of magic multiplications and divisions with factors like 0.1, 10,
M_PI/1800, 1800/M_PI and so on, all of which are scalar so they aren't
caught by making the new type deliberately incompatible.

Once angles are done, the same thing can be done for lengths, where,
thankfully, the magic values are somewhat confined to the headers.

One thing I really like is that we can express things like

    angle a = 90_deg;

and in places where we need a scalar, such as the file reader/writer
code, we can then use

    out << ( a / deg );

to write a value in degrees ("deg" is a global constexpr angle object
with a value of M_PI/180. :) ).

For the foreseeable future I'm going to concentrate on net ties, so if
anyone wants to run wild with the angle code, go ahead.

   Simon

[1] lol
[2] https://gitlab.com/GyrosGeier/kicad/-/commits/refactor/angle

Attachment: signature.asc
Description: OpenPGP digital signature