I work at a company where we have wrappers for pretty common things: pthread library and time.h functions. Management claims that this was done so that if we ever need to switch to another thread lib or use a different set of time related functions, it can be done easily.

I understand that doing this for third party libraries can be beneficial, but it seems to me that doing this with such widespread features is pure paranoia, and detrimental to productivity. Is this a valid approach? Are there any examples of this being done somewhere else?

  • Do these wrappers offer any alternative or higher level abstractions?
    – Erik Eidt
    Oct 11, 2018 at 15:52
  • I avoided adding this to the question because I felt it would be to biased, but the time abstraction is very thin (it is almost the same as using time.h itself, minus the fact that you can use Google easily to explain some behaviour). The thread wrapper on the other has a big overhead, doing a lot of background stuff, but at the cost of a huge overhead (one of the functions takes 8 parameters). Oct 11, 2018 at 16:03
  • 2
    It's a legitimate technique. A good example of this is the use of Inversion Control containers, libraries that are supposed to help you decouple code until you realize that you're now tightly coupled to the library itself. Prism solves this problem by using an IContainer interface containing "standard" method definitions like Resolve(), so that instead of changing the container everywhere in your code, you can just write a new shim for your favorite container that implements the IContainer interface, and the change occurs in just one place. Oct 11, 2018 at 16:21

3 Answers 3


I find this kind of thing pointless busywork in most situations. The only time I can think of this being necessary is if you plan, from day 1, to write for multiple libraries.

Otherwise, if you DO, by some chance, need to swap out pthreads in the future, do you really think that all of the underlying assumptions about how the various facets of the library works are going to hold? That mutexes and threads will have exactly the same semantics?

If they do, then you can just write a shim that emulates the pthreads names when the time comes.

If they don't, then you have to touch everything anyway, so you've saved nothing by pre-writing the shim.

That said - you've got an existing code base that works. While I would advise dropping this nonsense on new projects going forward, I would NEVER advise changing the way the existing code works just because the libraries are annoying.

  • 3
    While there is no cut and dried answer to this, I think you are missing a big part of what makes wrappers valuable. If you only implement the functionality that you need, the wrapper becomes a single place to look at to understand your dependencies on a library. Imagine a serious defect or vulnerability is found in a library and you've strewn you calls to that library all over your code it's a lot harder to understand your exposure than if you've got all your calls in a one place i.e. the wrapper.
    – JimmyJames
    Oct 11, 2018 at 18:54
  • @JimmyJames - I suppose that makes sense if you regularly use small pieces of larger libraries, but that's never never come up much for me. Oct 12, 2018 at 13:16
  • I'd agree, if your wrapper is isomorphic to the underlying API. If you build higher-level abstractions around the API you can still benefit. There are cases where I where I see little value in wrappers e.g. logging or collection/data structure libraries.
    – JimmyJames
    Oct 12, 2018 at 14:29
  • @JimmyJames - That's fair - though if you really built a higher level abstraction, it might not be fair to call it a wrapper. I will also say that very few people (myself very much included) are capable of straying far from the underlying API in these situations, unless they are targeting multiple libraries/platforms when writing the wrapper. Oct 15, 2018 at 11:43
  • "though if you really built a higher level abstraction, it might not be fair to call it a wrapper". You could make a strong case for this point. I guess I'm not sure where the distinction would fall. The best example I can think of is an API I created for dealing with dates and date spans that collapsed complex series of calls against a lib into a types and operations (e.g. get the complement of a set of periods). Perhaps it's not standard nomenclature to call that a 'wrapper' but I've always thought of it that way.
    – JimmyJames
    Oct 15, 2018 at 14:45

I don't know how old your codebase is, but pthreads being implemented in a well conforming way on all the unices that matter is a very recent thing, driven as much by the thinning of the Unix herd as anything else.

Threading was for a long time poorly defined on common Unix boxes, and more then a little variable between platforms and even kernel versions, I can certainly remember user space threading libraries and the mess of #ifdef that tended to be required to get a multithreaded program to build on say Linux and Irix, let alone BSD,Linux, IRIX, Solaris, osX...., wrappers were commonplace to at least get the mess of #defines into one place.

time_t also had various issues around word lengths and the 2038 problem, I can well see wanting to wrap that as well, particularly if saving raw structures to file is a thing in your systems.

It could well be that your senior dev people grew up with that stuff, and having written wrappers that work are reluctant to change things.


As with most things software patterns/architecture, this question does not have do/don't answer. If those libs are an intergral part of your software and are heavily used throughout whole code, then yes, writing wrappers for those libs is not a bad idea. Unless of course writing wrappers for those libs would cost more time and effort than adapting your code to another lib without having a wrapper.

  • The main issue for me is that this is being done to extremely common C libraries, such as pthread and time.h. I feel that this obscures code behaviour and when you have to extend the wrapper (because the implemented functions do not cover all of the available funcionalities of the thing being wrapped) there is a huge amount of red tape to go through. Oct 11, 2018 at 16:13
  • 1
    @GuilhermeCosta, what happens when you want to migrate to Windows (and, therefore, use a different threading library)?
    – keelerjr12
    Oct 11, 2018 at 16:26
  • Migration won't happen (at least not in the foreseeable future). The code is for an embedded Linux system, with a very specific hardware configuration. As such, in this particular case, I believe that no matter the amount of wrapping, the transition wouldn't be very smooth. Oct 11, 2018 at 16:39
  • @GuilhermeCosta, yes. Extending a wrapper is inconvenient. That's the trade-off. That's why I said that there is no golden rule for cases like this. Everyone will have their own opinion on the matter. And without having an in-depth knowledge of the system and requirements, noone here will be able to make a decision on whether or not the trade-off is worth it. Too many things to consider. How likely is it that those libs will be replaced? How much time would it cost to adapt the software to new libs? All those factors are subjective and not exactly measurable, so it comes down to gut feeling.
    – Aleksander
    Oct 11, 2018 at 16:46
  • @Aleksander, I see your point. Wrappers of certain libraries can be quite useful, specially when the abstractions built upon it are sound. My concern is just that by wrapping basic stuff we are just reinventing the wheel... Oct 11, 2018 at 22:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.