m42e's blog

unique_ptr are great

Mon, 30 Aug 2021 00:00:00 +0000

Sidenote: Ok, so I couldn’t and will not try to stick to a plan of posting, I will post if I am in the mood of telling somebody something.

I recently got in touch with rust, and read about it. Some things look nice, others rather strange. And a few of the “oh this is much better in C++” maybe true, others are just not so obvious. One special case I recently stumbled over was file access. You open a file, write to it and at some point int time you are closing it.

Well if you remember to close it, right. Maybe you forget about it, so you have it open, even if it is not used anymore. That’s bad. But can be avoided. And C++ offers you a nice and clean way of doing it:

void writeToFileUsingUniquePtr(){
  std::unique_ptr<FILE, int(*)(FILE*)> fp(fopen("test2.txt", "w+"), fclose);
  if (fp){
    fwrite("11234\n", 1, 6, fp.get());
    std::cout << "check open files you see test2.txt threr" << std::endl;
    std::this_thread::sleep_for(std::chrono::seconds(10));
  }else{
    std::cout << "could not create/access file test2.txt"<< std::endl;
  }
}

The first line in the function is the most interesting here. You create a unique_ptr to a file with fclose as deleter. I think that is so nice and easy that it is probably the only correct way to do it.

Ignore the nodiscard

Wed, 09 Jun 2021 00:00:00 +0000

I have recently decided to have [[nodiscard]] for every function that returns something. Every may have some exceptions but in general all normal every-day functions are defined [[nodiscard]].

This has two reasons:

If there is a return value, it should mean something, so you should actively decide what to do.
If the return value is not useful at all, remove it.

Non owned code

So far so good, the rule is nice and works well, but in our code base we have to deal with lots of third party code we cannot change, at least not easily. I think we all know the struggle. Additionally to the compiler raising errors on each ignored return value flagged with [[nodiscard]] we have some static code checkers which perform this check for all the function calls.

We have a third party interface which has a return value, but it is not useful for us. So we want to ignore it. Simply discard it with not at least some cast does not work, as the mentioned code checker would flag it as an issue.

Thankfully we get something within the std even if it is not exactly where you might expect it. You have to #include <tuple>. And then you get a small but useful gem. std::ignore. Remember the old days, where you did something like (void) function_with_return() or a more C++ style static_cast<void>(function_with_return()). These times are gone. From now on you can simply state what you want to do:

#include <tuple>

int function_with_return(){
  return 54;
}

int main(){
  std::ignore = function_with_return();
  return 0;
}

This makes it pretty clear you are not interested in the value receiving as a return. I like it pretty much as it solves another inconvenience we dealt way to long.

Get rid of unions and some more advantages of std::variant.

Sun, 06 Jun 2021 00:00:00 +0000

Let’s go back to C++17. It is already a while out there and a feature I really like is std::variant. It is handy in a lot of places. In all places you may have used unions before. Having an Interface which accepts a std::variant which it does not use itself, but passes it further makes the interface slimmer and easier. You could have done that with templates, but using std::variant is much more simple.

Let’s look at some code.

#include <string>
#include <variant>
#include <iostream>

using namespace std::literals;

void funcb(std::variant<int, std::string>& data){
  if(auto pval = std::get_if<std::string>(&data)){
    std::cout << "a string, how nice: " << pval << std::endl;
  }
  else{
    std::cout << "not a string, something else" << std::endl;
  }
}

void a(std::variant<int, std::string>& data){
  std::cout << "size is " << sizeof(data) << std::endl;
  funcb(data);
}


int main(){
  std::variant<int, std::string> s = "AString"s;
  std::variant<int, std::string> z = 3208;

  a(s);
  a(z);

  return 0;
}

Ok, so we are able to pass things without bothering. I mean in this case it has been easy, we have a string and an integer. So is there another way than these std::get_if? Indeed. Use std::visit.

std::visit in combination with lambdas is really great. You are using templates without a single template parameter. It is so nice, elegant and not too hard.

#include <string>
#include <variant>
#include <iostream>

using namespace std::literals;

void a(std::variant<int, std::string>& data){
  std::cout << "size is " << sizeof(data) << std::endl;
  std::visit([](auto&& arg){
    using T = std::decay_t<decltype(arg)>;
    if constexpr (std::is_same_v<T, int>){
        std::cout << "int " << arg << '\n';
    }else if constexpr (std::is_same_v<T, std::string>){
        std::cout << "string " << arg << '\n';
    }
  }, data);
}


int main(){
  std::variant<int, std::string> s = "AString"s;
  std::variant<int, std::string> z = 3208;

  a(s);
  a(z);

  return 0;
}

The lambda in the std::visit is using constexpr. This will reduce the generated functions to a minimum. The lamba here act like a template and we do a specialization there so it handles all types correctly. I found this pretty useful also for some kind of serialization. So you have it all in one place.

That did not start well. Missed already some weeks...

Sun, 06 Jun 2021 00:00:00 +0000

Ok, here we are. I already missed some weeks, but hey, don’t mind. I wanted to challenge myself into writing and now I have to possibilities:

Ignore the fact, that I missed already some weeks posts, or
cancel the project completely because I missed my own expectations.

And I have chosen the first one.

I would have done this different in the past.

Maybe I am not the only one, but for sure I would have acted different in the past. My favourite choice and of course the one that is a lot easier is the second one. But I do not want to cancel this. It is a good practice for me to write about things.

I usually assume that everyone knows a lot more than I do, aka. imposter syndrome. I mean I think of myself that I know pretty much, and from pretty broad topics, too. But still I am not confident, in a lot of areas. This is one thing that is hindering me from telling other people about what I am doing and how. I expect to bore them because for sure they already know it anyway.

The decision to continue is a decision I am doing for myself. I do not expect anybody to read this here at all :)

So enough insights, let us see what we have here this week.

Conecpts or what do you require?

Sat, 15 May 2021 00:00:00 +0000

Starting my regular blogging habit I do not want you to be bored out so I start with something that is new in C++20. C++20 is another big step forward to make templates even better. Or some would say a step into the so called meta-programming. But do not be scared by the meta it is not that complicated as you might have heard. For sure it can get complicated, but that is also true for non meta code.

I will provide you some examples where concepts might be useful and a short reminder what templates are, just in case.

Short reminder: templates

Just to make sure we are all on the same page, the basic thing we use templates for is as a cookie cutter. You do not buy a cookie cutter per dough and you do not want to repeat code.

template <typename T>
T add(T a, T b){
  return a + b;
}

This example is simple enough to show you what we can do with it. We have a function template add that takes two arguments of the same type, and applies the + operator and return the value.

So how to use it?

void main(){
  add(1, 3);
  add(3.5F, 9.2F);
}

Simple isn’t it?

So why bother with concepts?

One of the answers you might get from people which crawled through other peoples compiler error messages a lot might be: To get better error messages. This is true. You can try it yourself. Just pass a custom type to the add function (where the custom class does not implement the operator+). If you have never seen such error messages before you might be thrilled to get one :). Once more this example is so simple and easy, also the error message you get is understandable.

Concepts are a good way to specify the template arguments your template accepts in a readable way and with better error messages.

How to do it?

It is not too hard. Besides this example there are a lot of predefined concepts you can use already available in the standard library.

Let me show a concept for the add function above:

template<typename T>
concept CompareableAddable = requires (T a, T b){
  a + b == b + a
}

So what we require now is that the type passed has two things: an operator+ and an operator==. Note: Be aware that this does not mean, that it must have the same result. It just means the operation performed must be valid.

You can play around here: https://godbolt.org/z/3sooTaoTr

Try something new

Sat, 08 May 2021 00:00:00 +0000

This is my new challenge

I try to write a blog post, once a week, with at least one C++ feature I either like or have learned about recently. I take bets on how long I continue this.

I know a lot of others are doing this and you all might be bored about just another blog like this. But if there is someone out there, who is interested do not hesitate to reach out and let me know about it.

You can reach my using mail, twitter or Threema.

CPPnow 2021 - Lightning Talk

Sat, 08 May 2021 00:00:00 +0000

I had the opportunity to attend the CPPnow in 2021. I am glad is has been a online conference, because that way I could attend more easily.

Besides a lot of interesting, educating and inspiring talks I pushed myself forward and into doing a lightning talk. My first public talk somehow.

What I learned

It was a nice experience. I think that I am actually less nervous than I thought I would. Thanks to the Team and the other speakers. I really enjoy presenting something. I hope I get the chance more often.

Additionally I think my talk was far away from being perfect, but I recognized that does not matter. What matters is that I did do it.

Maybe I hit onto somebody with the talk (which at some point in time will be available for sure). And even if not I learned something:

Presenting a talk isn’t as frightening as I thought
I can do it (at least for 5 minutes)
I think it is kind of funny to do

What else

I really would like to do a longer talk somehow. But I am lacking of topics. Relevant topics, that are somehow interesting. But maybe this is a judgement I am doing to harsh?

In my job programming roughly makes about 25%. And to be honest I am doing more paperwork and process fulfillment as I would like to. Maybe that is the reason I do not get too deep into topics. Maybe, but there might be something else.

I try to deal with things as they are. So if there is not the right stuff available I will do the best I can to make things work. But I do that somehow careless. I do not make a big deal of it. I just wanted to build that stuff or to fix it. Maybe I should promote such things more.

Finally I am getting bored really fast. As long as things are new and nice I like to play around with those. But I let go of them very fast if they are not of use or I see some fancy other stuff I like more. And this lets me abandon a lot of things I started. Mostly unfinished.

#include <C++>

I learned from the talk of Bryce Adelstein Lelbach that there is a movement to create a inclusive C++ community. I really like the idea and hope you support these movement, too. Details can be found here: https://www.includecpp.org

Must Everything be a Smart Pointer?

Sat, 01 May 2021 00:00:00 +0000

TL;DR

If you pass a smart pointer you include some ownership, a raw pointer doesn’t. But use it for every allocation.

Should we only use smart pointers?

During rewriting of a legacy C codebase to C++ I have been asked if everything should be changed to a smart pointer. I replied with “Why should we do that?” and the response was “because we wanted to be modern”.

Oh dear. That was not what I wanted to have by stating that we want to have a modern codebase. For sure use smart pointers, where you used new or malloc and delete or free in former times. But not everywhere and not under any circumstances.

And here comes why. It has been explained for sure a few hundred times across the web, but I think it is worth explaining it one more time, so more people probably read it at some time.

Unique Pointer

In case of a std::unique_ptr it seems to be a bit more obvious. This one clearly states, that there is only one of it, cannot be copied, only moved around. So most programmers are aware of that and use it with care. Did I say care? I mean they do not use it most of the time, because they cannot pass it to a function without moving it. But is that true? Well it depends.

As std::unique_ptr does not have a copy or copy-assignment constructor you can only move it. That’s a fact. But there is this nice little method called get. Now what do we get here? Lets have a look at a (simplified) full signature T* get() const noexcept;. Looks like we could easily access the pointer, and pass this to functions of our choice. Nice. But wait, I wanted to have a std::unique_ptr and not pass it around.

Well I think you misunderstood the concept. The std::unique_ptr is meant to be unique in a way, that is has exactly one owner at any point in time. And if the owner does not take care of the object referenced it will be deleted. The important part here is the owner.

Shared Pointer

A std::shared_ptr describes a object that is shared. Sharing means it has at least one owner but probably more. And these owners may leave the object alone at different times not synchronized. So the object must be there till the last one looses interest and the std::shared_ptr gets destructed.

Still, every owner could pass the raw pointer of the shared object around. The interface is like the one of the std::unique_ptr. And it should be used, as long as you do not want to share ownership. If you calling a function which does something with the shared object: pass a raw pointer. If you construct an object, that has the same lifetime as your std::share_ptr: pass a raw pointer. If you want somebody else to have ownership (and therefore control over the lifetime): pass a shared_ptr.

Compared to things in real life

Lets explain with using something familiar, a cellphone number. Generally speaking there is only one owner of a cellphone number at a point in time. You may pass the mobile phone with the SIM card the number is bound, but then you do not have access to the number any more. So the SIM is kind std::unique_ptr. (I know about multisim, but keep it simple). You still can pass your mobile phone to somebody else to make a call. It remains yours. And if you do not care anymore (your unique_ptr goes out of scope), the number is freed and you do not have to take care of it.

On the other hand, lets assume you share a flat with two other people. The flat has a landline. This means, the landline is a std::shared_ptr. All three of you kind of own the landline. As long as at least one of you care about it (own a shared_ptr) it won’t get canceled.

What is Most Important when Porting Legacy Software?

Thu, 29 Apr 2021 00:00:00 +0000

I am currently working on a code base which is rather old an used to be C. It has been started over a decade ago and is still in use. As part of an automotive ECU it has seen a number of base systems it has been integrated to. If you are familiar with automotive software development you may know AUTOSAR, a kind of extra layer above the OS which should make software components portable between and independent of the actual chip or event ECU it is running on.

So the software we are currently porting fulfills the requirements and is bound to the constraints AUTOSAR requires. Additionally, as it has existed before, it has even more legacy interfaces.

The target is to port things to a modern POSIX compliant platform. And to make it more modern, to C++. C++17 to be a bit more precise. This is a great opportunity in my point of view. Get rid of all the old things that had to be supported, clean up interfaces and use the standard library. But most important: make the code more readable, understandable and maintainable.

To achieve these three things I currently see one thing as crucial: Make the code descriptive. Well, to not just give the thing another name, let me explain. I would define descriptiveness as a metric of how many lines of code do i have to read (or even worse, scroll) to determine the meaning of a single line of code.

Given the following function pt1filter. Lets assume it is everything in one file. Old C style.

void PT1Filter(uint32* pOldValue, uint32 NewValue, uint16 DeltaT,
               uint16 TimeConstant) {
  uint32 DeltaV;

  if (TimeConstant > 0U) {
    if (TimeConstant < DeltaT) {
      *pOldValue = NewValue;
    } else {
      if (NewValue > *pOldValue) {
        DeltaV = (NewValue - *pOldValue) * (uint32)DeltaT;
        DeltaV += (uint32)TimeConstant - 1uL;
        DeltaV /= (uint32)TimeConstant;
        *pOldValue += DeltaV;
      } else {
        DeltaV = (*pOldValue - NewValue) * (uint32)DeltaT;
        DeltaV += (uint32)TimeConstant / 2uL;
        DeltaV /= (uint32)TimeConstant;

        if ((NewValue == 0uL) && (*pOldValue != 0uL) && (DeltaV == 0uL)) {
          DeltaV = 1;
        }

        if (*pOldValue > DeltaV) {
          *pOldValue -= DeltaV;
        } else {
          *pOldValue = 0;
        }
      }
    }
  } else {
    *pOldValue = NewValue;
  }
}

Some design considerations have been done because of the limitation of previous platforms, e.g. limited use of float or memory restrictions.

Now I had somebody porting it to C++. Now we have the following. Well it compiles well with C++, looks a bit modern as it is now using templates, but that’s it. There has been an additional tests, for an upper and lower limit. It is not better readable nor understandable than before. And it now has six parameters.

template <typename T>
inline T pt1Filter(const T oldValue, const T newValue, const T upperLimit,
                   const T lowerLimit, const T deltaT, const T timeConstant) {
  T deltaV;
  bool filteringEnabled{true};
  if (newValue >= oldValue) {
    deltaV = static_cast<T>(newValue - oldValue);
    if (deltaV > upperLimit) {
      filteringEnabled = false;
    }
  } else {
    deltaV = static_cast<T>(oldValue - newValue);
    if (deltaV > lowerLimit) {
      filteringEnabled = false;
    }
  }

  T result;
  if ((filteringEnabled == true) && (deltaV > 0) && (deltaT < timeConstant) &&
      (timeConstant > 0)) {
    const float numerator{
        static_cast<float>((oldValue * deltaT) + (newValue * timeConstant))};
    const float denominator{static_cast<float>((deltaT + timeConstant))};
    result = static_cast<T>(
        std::floor((numerator + (denominator / 2.0F)) / denominator));
  } else {
    result = newValue;
  }

  return result;
}

If we choose any of the lines, we might have a clue, what’s going on here, but it is hard to get to it right away, are we?

Lets make it a bit simpler.

template <typename T>
class Limits {
 public:
  T const lower;
  T const upper;

  bool isWithin(T value) const { return (value <= upper) && (value >= lower); }
};

template <typename T>
typename std::enable_if_t<std::is_integral_v<T>, T> pt1Filter(
    T const old_value, T const new_value, Limits<T> const& limits,
    std::chrono::milliseconds const& time_delta,
    std::chrono::milliseconds const& time_constant) {
  auto const value_delta{new_value - old_value};

  if (!limits.isWithin(value_delta) || time_constant.count() <= 0 ||
      time_delta >= time_constant || std::abs(value_delta) == 0) {
    return new_value;
  }

  auto const numerator{static_cast<float>((old_value * time_delta.count()) +
                                          (new_value * time_constant.count()))};
  auto const denominator{
      static_cast<float>((time_delta.count() + time_constant.count()))};
  return static_cast<T>(std::lround(numerator / denominator));
}

So from my point of view it is a bit better. Basically I changed the following aspects:

use standard and meaningful types,
create a type, where it made sense,
return early.

I am not satisfied with this, as 5 parameters are likely to get wrong. To make it simpler. First thing is to check how it is actually called.

const uint32_t upperLimitPt1{50};
const uint32_t lowerLimitPt1{0};
....
filtered = pt1Filter(new, old, {lowerLimitPt1, upperLimitPt1}, deltaT, tconst);

What we can see here, is that the limits are set to fixed values by the caller. That should be a hint for us, to do is in another way. There is a part that changes tconst but this is barely called. So maybe we can do better, and work with the limits and the time constant as kind of configuration.

The limits are really a static configuration of the filter, the tconst is a dynamic configuration. And so I decided to put the filter into a class and take the configuration as part of the constructor:

Pt1Filter(Limits<T> const& limits, 
         std::chrono::milliseconds const& time_constant = std::chrono::milliseconds(0)) 
         : limits_{limits}, time_constant_{time_constant_} {}

As we want to be able to change the time constant at some time during the runtime, we add a setTimeConstant interface. The rest of the parameters stays the same and is moved into operator() member.

template <typename T, typename = std::enable_if_t<std::is_integral_v<T>>>
class Pt1Filter {
 public:
  Pt1Filter(Limits<T> const& limits,
            std::chrono::milliseconds const& time_constant =
                std::chrono::milliseconds(0))
      : limits_{limits}, time_constant_{time_constant_} {}
  void setTimeConstant(std::chrono::milliseconds const& time_constant) {
    time_constant_ = time_constant_;
  }

  T operator()(T const old_value, T const new_value,
               std::chrono::milliseconds const& time_delta) const {
    auto const value_delta{new_value - old_value};

    if (!limits_.isWithin(value_delta) || time_constant_.count() <= 0 ||
        time_delta >= time_constant_ || isValidDelta(value_delta)) {
      return new_value;
    }

    auto const numerator{
        static_cast<float>((old_value * time_delta.count()) +
                           (new_value * time_constant_.count()))};
    auto const denominator{
        static_cast<float>((time_delta.count() + time_constant_.count()))};
    return static_cast<T>(std::lround(numerator / denominator));
  }

 private:
  Limits<T> const& limits_;
  std::chrono::milliseconds time_constant_;

  inline bool isValidDelta(T delta) const { return std::abs(delta) != 0; }
};

Now lets reduce the functions parameters.

So what changes did I actually made.

Used types that represent what I actually care about. In this example I changed the type of the parameter which represents a certain amount of time to std::chrono::duration. The algorithm makes use of some limits. Making the upper and lower limit part of a struct makes the signature easier to read, understand and harder to pass the parameters in the incorrect order. And finally, I removed the parameters which are actual const anyway in the callers context and passed in every time. What we get is a lean interface and using standard library also a clean implementation which is (nearly) readable by non coders.

TL;DR

If you ever porting legacy code consider the following:

understand the intention
use proper, expressive types (use existing or create new ones)
know the std algorithms
try to make the interfaces as small as possible

Extra

How to ensure it really works? There are no tests available for the legacy implementation? You are lazy? I did it like that:

move the old implementation to the test code
wrote a data driven testcase, with a lot of combinations, taken from the code, utilizing testing::Combine. The test only compares the original result with the one of the reimplementation.
did the reimplementation

I had about 3.5 million tests to verify my solution actually works. It is not the kind of test you may want to run every time. It may also break your test result reporting tool. But while implementing such a replacement I found it very helpful and pleasing to know it actually works.

What are Inline Namespaces?

Sat, 24 Apr 2021 00:00:00 +0000

Inline namespaces are transparent for those who are using the outer namespace. This is useful if you want to allow to narrow down the functions/classes/constants used, but do not want to add some more clutter if somebody wants to have them all.

A simple example:

Simple Example

#include <iostream>
namespace m42e {
namespace cpp {
namespace test {
const int32_t my42 = 42;
inline namespace nested {
const int32_t my23 = 23;
}  // namespace nested
}  // namespace test
}  // namespace cpp
}  // namespace m42e

int main() { 
  // this works for sure
  std::cout << m42e::cpp::test::my42 << std::endl;
  std::cout << m42e::cpp::test::nested::my23 << std::endl;
  {
    using namespace m42e::cpp::test;
    // of course we can use my42 here
    std::cout << my42 << std::endl;
    // as nested is inline it is "transparent"
    std::cout << my23 << std::endl;
  }
  
  return 0; 
}