Package management and build systems are one of the next big challenges C++ is going to face. In this article series, I offer some thoughts and ideas to solve that. This post is the second part, where we talk about toolchain definition, how a standard could work and what challenges it would face.
Christmas and New Year Eve are that particular part of the year when we wish for impossible things and make unreasonable promises. Get a bottle of a 1999 DRC La Tâche, lose weight, have a C++ ecosystem with a built-in package manager…
A quick follow-up on the previous article ‘Better polymorphic ducks’ to address two small issues.
Peer reviews are a great source of insight. This is why we do code reviews and talks rehearsals. Blog posts are no exceptions and my astute readers pointed two things in the previous article Better polymorphic ducks that I will now share with you.
In a previous post we discussed how to combine duck typing with runtime polymorphism. A polymorphic duck if you will. Today let’s see how we can improve on our original design to remove some limitations.
The use of the TEPS (Type Erasure (Sean) Parent Style) we have shown in the first part of this series gave us what I call a Polymorphic Duck: something that can walk like a duck and quack like a duck, but it not necessarly inherited from a base Duck class. Moreover, the quack() and walk() are expected to be free function, not methods, which allows for looser coupling (especially if they take arguments that have nothing to do with the duck itself).
It’s no secret C++ favours static polymorphism. But sometimes, runtime polymorphism is needed and suddenly we find ourselves down the virtual rabbit hole. Do not despair, for there are ways to avoid this madness.
I hate the virtual keyword. Inheritance fills me with a sense of dread. I can always quote half a dozen technical reasons to explain it. People much more smarter than me have discussed why it’s the worst form of composition.
I was at Meeting C++ 2017 to give a talk and then relax while listening to other speakers. That didn’t go exactly as planned.
About 6 months ago, I sent the abstract of one of my submissions to CppCon to my colleague Jonathan Boccara for advice. A few messages in the discussion he asks “did you also submit for Meeting C++?” and I admitted the thought hadn’t crossed my mind. To me, speaking at one conference like CppCon was already a big step and it would be redundant to propose the same talk at two different conferences anyway.