C++ development notes
Optimizing my workflow, Writing C++23/C++26 code on Debian trixie, Next step
Optimizing my workflow
It took 4 monthes of hobby time between v0.0.1 and v0.0.2. Just to manage the standard input to catch printable characters, special key strokes and cursor position reports.
Beyond the sluggishness induced by the heatwaves during most of the summer, what dragged the work was all the book-keeping between specification files, tasks files and code. The whole compounded with a tentative to get incremental outcomes, as I somehow tried the INVEST technique (I got the incremental outcomes, and it was nice ; I also got a lot more book-keeping to do, cancelling the gains of the method).
By the time I finally reached my milestone, I started to devise and apply another strategy.
Reducing and delaying friction
“Friction” here means whatever prevents me to instantly materialize a new idea into code.
In my context, it essentially means writing and maintaining specs (in specs files as well as in documentation comments) and writing and maintaining build files to support new source files.
I have so little available time and energy, I MUST make the most of it. Especially to bootstrap a new idea.
So I would now start with delaying friction, by writing new code and its documentation in an already referenced translation unit that would need the new code, or that can be mutated into a test bed for that new code.
Get David Sporn’s stories in your inbox
Join Medium for free to get updates from this writer.
When the code has a good enough shape (compiles and works), I would start a refactoring process to get clean and covered code as well as good documentation.
As for reducing friction, I would not maintain a separate specification file anymore. The relevant documentation will be embedded in class documentation or as test runner comments. (That leaves the questions of specification of a whole application, I will have to tackle that at some point, but not now.)
Writing C++23/C++26 code on Debian trixie
Debian trixie is the current stable distribution (at the time of writing), and I discovered that I cannot use ranges, nor C++ modules.
I was told that clang 19 is available, so I keep that in mind.
But as I wish to use GCC, I am considering to compile it myself to get the latest features. More on that later, when I will do it.
Next step
The DataSource model was used to implement the retrieval of the escape sequences and of the printable characters from the standard input. I wrote a mock implementation to write tests, and an implementation using the read() function.
I realized that I need batch operation, and the “next()” seems ill-named. So at the next step, DataSource will have a single read operation “pull()”, and a batch read operation “fill(std::vector<T> bucket)”. The default implementation will use the template method pattern to call the single read operation.
The dumpkeys demo quickly implemented a way to emit escape sequences (an exemple of delaying friction) that hint at the counterpart of a DataSource : a DataSink. It will have a single write operation “push(T t)” and a batch write operation “drain(std::vector<T> bucket)”.
Finally, I will need to decode/encode UTF-8, to be able to store any text using char32_t.
