Single-byte key addressing (for boards with fewer than 256 keys)

[noseglasses]

@algernon

This appears to be a reasonable guide about the topic of typecast operator overloading, with examples and all that. Starting from a getter/setter setup, towards a cast overload.

You are damn fast

[merlin (Michael Richters)]

@buc

That’s several layers of type indirection, and I can completely see how someone might miss the typedef and think that StorageType is something built-in to C++, but somehow doesn’t show up in any of their searches.

That would be very frustrating and off-putting.

It is.

@buc

Would things maybe have been better if instead of the very generic term StorageType something more specific had been used like KeyAddrInternalType, something that couldn’t reasonably be mistaken for language-level magic?

Yes, that would have been better, but I still find the multiple layers of indirection confusing, and am reminded why, when I first tried out C++ and was delighted by the idea of operator overloading, I gave up on it very rapidly when I first tried to actually use it.

[merlin (Michael Richters)]

@noseglasses

I just added the weird ways to call it to show what C++ does under the hood. Please, don’t get this wrong, no-one would actually write

auto t2 = static_cast<KeyAddr::StorageType>(a);

everybody would call

KeyAddr::StorageType t1 = a;
uint8_t t2 = a; // less portable

and that’s what the cast operator is good for. To enable a class to pretend to be another type e.g. in assignments or when passed as a function parameter, without requiring the user to add an explicit type conversion.

I loathe the idea of writing any of that. Apart from not understanding auto, I only want to write:

KeyAddr k = 12;

…which I can do with a typedef, and now I’m not sure if it can be done with your version. It is so complex, for something so simple, that it makes me want to give up the whole project, and just fork Kaleidoscope now and write my own separate version for personal use and stop trying to contribute to the main codeline.

[noseglasses]

@buc

Would things maybe have been better if instead of the very generic term StorageType something more specific had been used like KeyAddrInternalType, something that couldn’t reasonably be mistaken for language-level magic?

Sure, that might be even more descriptive. The indirection is there for

• portability (KALEIDOSCOPE_KEY_ADDR_STORAGE_TYPE being defined through the build system) and
• encapsulation (a class informs about the types it uses, i.e. StorageType (or KeyAddrInternalType).

That’s the way it is done. Just have a look at boost or Eigen.

But as mentioned before, no-one should ever be forced to look at the implementation.

Check out e.g. the documentation of Eigen. I never ever looked at the implementation and I am using it for more than ten years now. And please, don’t look at Eigen’s implementation, at least not without sunglasses

[merlin (Michael Richters)]

@algernon

This appears to be a reasonable guide about the topic of typecast operator overloading, with examples and all that. Starting from a getter/setter setup, towards a cast overload.

Thanks. I read something similar last night, but there weren’t enough examples for me to understand it. Maybe I’ll get it this time, but I’d just rather not have to learn it at all.

[noseglasses]

@merlin

I loathe the idea of writing any of that. Apart from not understanding auto, I only want to write:

KeyAddr k = 12;

…which I can do with a typedef, and now I’m not sure if it can be done with your version. It is so complex, for something so simple, that it makes me want to give up the whole project, and just fork Kaleidoscope now and write my own separate version for personal use and stop trying to contribute to the main codeline.

There is a line in my above code example that reads

@noseglasses

KeyAddr c = 1;

at the bottom in the main function.

[merlin (Michael Richters)]

@noseglasses

But as mentioned before, no-one should ever be forced to look at the implementation.

How about developers who want to contribute to the core, or port Kaleidoscope to other hardware (e.g. Planck)? This makes it much harder for them.

[buc]

@noseglasses

encapsulation (a class informs about the types it uses, i.e. StorageType (or KeyAddrInternalType).

That is a misuse of encapsulation. With proper encapsulation you have only an opaque container and ought not ever care about what is inside.

If an opaque box (i.e. object) has to have a mechanism to tell you the details of its implementation then things have already gone off the rails.

If outside code has to care about the internal implementation details of an object, then either the object is done wrong or an object is the wrong solution.

[noseglasses]

@merlin

How about developers who want to contribute to the core, or port Kaleidoscope to other hardware (e.g. Planck)? This makes it much harder for them.

I know I cannot convince you. And developers should of course understand the code. And, writing this on a Planck, I am really interested in a port. So, if you can do it if we stick with a typedef, I will certainly opt for the typedef

But seriously. A port to another keyboard would not require touching the code of KeyAddr. That’s an important aspect of portability. The only thing that needs to be done, concerning the KeyAddr class, is to define other values for the macros

KALEIDOSCOPE_MATRIX_ACCESS_TYPE
KALEIDOSCOPE_KEY_ADDR_STORAGE_TYPE
KALEIDOSCOPE_KEYBOARD_ROW_SIZE

in a hardware/platform specific type definition header.

[noseglasses]

@buc

That is a misuse of encapsulation. With proper encapsulation you have only an opaque container and ought not ever care about what is inside.

If an opaque box (i.e. object) has to have a mechanism to tell you the details of its implementation then things have already gone off the rails.

If outside code has to care about the internal implementation details of an object, then either the object is done wrong or an object is the wrong solution.

Interesting. Just ask google for ‘c++ vector iterator’ and click on an arbitrary hit, e.g.

Vector iterators

If it was true what you say then the whole STL has ‘gone off the rails’. Public typedefs in classes are part of an interface, not the implementation. Actually, everything that is defined in the public section of a class is part of its interface and not ‘inside’.

[buc]

@noseglasses

But seriously. A port to another keyboard would not require touching the code of KeyAddr. That’s an important aspect of portability. The only thing that needs to be done, concerning the KeyAddr class, is to define other values for the macros

That makes your class very well implemented indeed, but it may simply be the best implementation of a wrong approach.

[noseglasses]

Ok, guys. I won’t continue to insist in any type of implementation. My class sketch of KeyAddr was just a suggestion.

[noseglasses]

@buc

That makes your class very well implemented indeed, but it may simply be the best implementation of a wrong approach.

Possible. Eventually, programming discussions always end at philosophy, same as parties end in the kitchen (not sure if this saying exists in english).

[buc]

@noseglasses

If it was true what you say then the whole STL has ‘gone off the rails’.

And I think it has.

I’ve worked with C++ when templates were still relatively new, and I’ve worked with the Boost STL. And I prefer not to work with C++ any more. I don’t think these things are completely unrelated.

[noseglasses]

@buc

I’ve worked with C++ when templates were still relatively new, and I’ve worked with the Boost STL. And I prefer not to work with C++ any more. I don’t think these things are completely unrelated.

I continuously work with C++ for almost 20 years now. It’s not that bad. Actually, It’s my favorite language. No other language allows to generate such lengthy discussions

[buc]

@noseglasses

No other language allows to generate such lengthy discussions

Have you not heard of Perl 6?

[algernon (Gergely Nagy)]

@noseglasses

And, writing this on a Planck, I am really interested in a port. So, if you can do it if we stick with a typedef, I will certainly opt for the typedef

We can. The hard part with a Planck port is the Teensy, because that needs a different HID library, as far as I remember. There has been same work on that front before, and I plan to revisit that soon for various reasons. Once we make it easier to use different HID libraries, and dispatch events between them, a whole lot of things get easier. Including porting to Teensy-based platforms. Once that code is in, the Planck port should be doable in an afternoon.

Key addressing is a non-issue when porting to keyboards that use the exact same MCU under the hood (the Teensy in the Planck has the same Atmega32u4 processor in it as the Model01, the Shortcut, and Raise). It would become an issue only when porting to a keyboard with more than 255 positions in its matrix. I don’t see that happening anytime soon. And even then, putting the typedef in the hardware plugin would solve most of the portability problems.

[noseglasses]

@buc

Have you not heard of Perl 6?

I must honestly confess that I switched from Perl to Python before Perl 6 came along. But I seem to have missed something.

[noseglasses]

@algernon

We can. The hard part with a Planck port is the Teensy, because that needs a different HID library, as far as I remember. There has been same work on that front before, and I plan to revisit that soon for various reasons. Once we make it easier to use different HID libraries, and dispatch events between them, a whole lot of things get easier. Including porting to Teensy-based platforms. Once that code is in, the Planck port should be doable in an afternoon.

Nice. Thank’s for the info. I am looking forward to the Teensy port. My ErgoDox might like it too.

[buc]

@noseglasses

I must honestly confess that I switched from Perl to Python before Perl 6 came along. But I seem to have missed something.

I was referring primarily to the 15 years it took from the start of the design discussions to the “1.0” release.