Question

I am a C++ programmer and recently joined a new company that uses a lot of C. When they reviewed my code, they were thinking I over-designed some of the things which I totally disagreed. The company is doing everything in embedded system, so my code needs to be memory
efficient, but the stuff I am doing is not CPU intensive. I would like to know how you guys think what my design. Here is the list.

1. I have some arrays that need to pass around and eventually need to pass to some C code. I could pass a pointer and a size all over of the place. But I chose to create a class that represents this — a class that has a fixed size (we know the maximum size) buffer, and a length which should be always <= the size of the buffer, otherwise assert. In this way, I can pass the array around with only one variable instead of two, and if the maximum size changes in the future, I should be able to change it easily. I don’t use dynamic allocation for the array because it is embedded system and memory allocation could potentially fail and we don’t use exception. The class is probably less than 30 lines code, and I use it for quite a few places. They said I over-designed it.

2. They have their own containers implementation in C. I needed to use one of them, but I wanted to hide all the detailed code away from my main logic, so I created a wrapper class
   for it. The wrapper class is similar to stl, so I have iterators and it manages the memory
   allocation internally, but unlike stl, it returns a error code when it can’t allocate more
   memory. Their argument on this one is that I am the only one uses it, so they don’t want it to be in the repository. I found it stupid to be honest.

EDIT: The following class is more or less that I used for point 1. All I wanted to do is to have something to pass around without carrying the length all the time.

class A
{
  static const MAX_SIZE = 20;
  int m_Array[MAX_SIZE];
  size_t m_Len;

public:
  A(const int* array, size_t len)
  {
    assert(len <= MAX_SIZE);
    memcpy(m_Array, array, len);
    m_Len = len;
  }

  size_t GetLen() const { return m_Len; }
  const int* GetArray() const { return m_Array; }
};

Answer 1

You’re probably right, but on the other hand if everyone in the company decided that they don’t like the existing APIs, and each designed their own shims and helper functions, that only they used, then maintenance would be tricky.

If your array wrapper is “over-designed”, then I’d question whether the code reviewer considers any amount of design to be acceptable. It looks harmless to me[*]. I suppose you could have just made it a struct with two public members, and lose the benefit of read-onliness. How keen are your colleagues on const-correctness in general?

I think the goal for 2 should be to reach consensus on whether that C API should be used directly from C++, or wrapped. If it should be wrapped (and the arguments for that are probably quite strong, what with namespacing and RAII), design a wrapper that everyone will use, and designate it “the C++ API for this module” rather than “a C++ wrapper that one module uses for this other module”.

It’s possible that everyone else genuinely prefers the API as it is, over a more OO API or using STL. Following their conventions will make it easiest for them to maintain your code, as long as their conventions are solid C programming style. C++ is a multi-paradigm language, and “C with a limited number of bells and whistles” isn’t the paradigm you’re used to. But it is a valid paradigm, and if it’s what the existing codebase uses then you have to question whether what your company needs right now is a one-man revolution, however enlightened.

[*] (the API, that is. They might question whether it will be passed by value inappropriately, and whether it’s wise for every instance to have to be as big as the biggest. That’s all for you to argue out with the reviewer, but is nothing to do with “over-design”.