While studying the C programming language and learning safe practices, I'm inclined to write a layer of functionality over several parts of the standard library. This would serve two purposes: I could use standard parts of the language in ways that feel more familiar or rational to me, and I could easily replace that functionality with my own, if I needed to.

I could benefit from this, but should I do it? As an example, we can consider memory management. If I've written malloc() into the constructors of each of my objects, then decide that I need to handle memory allocation on my own, I have to edit the constructor associated with every object. By referencing my own function, I can change the contents of that function without writing a new constructors.

It seems obvious that I should do this, but I'm used to Python. I'm extremely comfortable in that environment and have no problem linking to any part of the standard library from any part of my program because I know I will almost certainly leave that relationship untouched for the life of the project. The situation I'm running into with C feels like I'm trying to hide the language from myself.

Will writing a layer of functionality over the C standard library help me in learning the language and developing a codebase, or will it stifle my understanding going forward?

  • You can see this happening in certain kinds of libraries. See memory manager interface in jpeglib . However, if you want to do this on a massive scale because of your personal taste (of Python), I'd say C might not be the appropriate language. Lack of function overloading, virtual methods, generic programming etc. will severely limit what can be achieved. This goal is somewhat more achievable in C++. If you really must try, learn about COM, MS's attempt to add OOP to C.
    – rwong
    Oct 30, 2013 at 4:41

4 Answers 4


I think there could be some use in writing your own layer, so long as you retain appropriate perspective.

When you interact with other people about your code, you'll still need to talk about it in terms of the standard functions.

But it could help you crank out similar applications if you wrap-up a nice set of routines that's useful. At the worst, the artifact you may end up with will be little more than a well-organized snippets file. And that's not such a bad thing. This is iff you keep perspective.

There is a danger of going waaaaay overboard. Basically implementing your own language within C. And, well, that's dangerous, crazy territory! You may seize upon something really cool and becomes the next big thing (it could happen!) or you may bounce around the endless circles of speculation: oh, and this could be expressed like this, and all of that would be simpler through this interface, and you convert it all to a new super-canonical representation, and ...

xkcd: "Standards"


I believe the danger zone I'm talking about is approximately the same as the "Architecture Astronaut" paradigm. <yoda>Remember: don't build another game engine, build a game. Then a second game. Then a third game. Then you may build an engine. </yoda>

Writing a layer over the API is a possible method of building an application. It is the approach taken by one of the most-readable X11 book I've ever found: X Window Applications Programming (Johnson & Reichard) (the series kept using K&R function syntax until at least 1996!), but for pedagogical value, it's priceless. Like I alluded to above, a well-organized snippets file.

  • Perhaps implementing that layer with each new project (at least while I develop a foundation within the language) would keep the layer lean while still requiring me to play with lower level functions.
    – user82901
    Sep 19, 2013 at 6:15
  • 1
    Yeah, that sounds like a reasonable way to approach things. But just be careful about thinking that you need to make a better interface than the standard one. You may easily end-up rewriting functions that already exist, and just wasting time instead of building useful programs. There's usually loud condemnation of such notions whenever they arise in discussions in comp.lang.c. Sep 19, 2013 at 6:19
  • I can understand that. It's easy to get lost in the philosophy of over-analyzing a problem when you could have written a solution.
    – user82901
    Sep 19, 2013 at 6:27
  • Indeed. Here's one of my trainwrecks: stackoverflow.com/questions/13459300/… . Sep 19, 2013 at 6:35
  • It's been roughly two and a half years. I've moved very far away from the sort of thinking I presented in the question. A fear has developed of adding extraneous code, function names, coding standards, etc., that all pile up and create resistance for other developers. In most cases, I'm the other developer, coming back to my own code base weeks, months, or years later. If only I could go back and tutor myself. sigh sip cough sigh
    – user82901
    Jan 25, 2016 at 16:16

The temptation of writing a layer above a standard API is common among beginners. I've been there too.

Although you may find short term benefits, I strongly advise not to do so. The standard API is, by definition, standard. It is known and used by all developers and sooner or later you'll have to know and use it. Don't delay that learning by encapsulating the standard API with something that only you will be familiar with.


+1 @mouviciel.

I came into C from the Pascal highway (Turbo Pascal and yea, it was a long time ago). I decided that C needed "Begin" and "End" and struggled for months to no avail. In the end I gave up because there were bigger fish to worry about. Any interpretive changes you make will have to be logical to whoever has to update your code in a few months (or years). Odds are that won't happen because they aren't you and don't have your POV. Your code (and reputation) will get thrown under the proverbial bus.

I suggest just bite the bullet and dig in. Embrace the preprocessor. You will have to contend with the failure of the presentation layer to control the functional (the Pythonic White Space Rules paradigm). I'd also recommend jumping to C++ since you've already gotten past the O-O hurdle. You're gonna love multiple base classes and having to do your own GC.

My favorite reference was the Harbison-Steele but that (as noted) was many moons ago.

  • 1
    +1 for "bite the bullet", -1 for "jump to C++". real C coding is a very valuable experience.
    – Javier
    Sep 19, 2013 at 17:56
  • But +1 for "You're gonna love..."
    – mattnz
    Oct 30, 2013 at 2:55
  • lol, I have a friend that used to work with a team of ex-Pascal devs being forced to write in a C-language who used macros to convert begin..end blocks into {}. He said it used to drive him nuts Oct 30, 2013 at 10:45

Moving from Python to C/C++ is a substantial jump in complexity and is no surprise that you are wanting to find a way to manage that complexity in your code.

In reality, trying to write your own complexity management layer will fail. In part, because you probably don't know enough about the language and how to use it effectively to do a good job, and secondly there are already libraries out there that provide what you are after (albeit it a C/C++ way, not python)

Have a good read through the Standard Template Library code, particularly around the shared_ptr and auto_ptr classes as ways to manage the heap memory safely. This will, over time give you a good understanding of the way to solve problems in C++, rather than trying to use C++ to write python code.

  • I can take a look into that. I haven't spent any time with C++, but should. I'm missing out on a large part of the discussion without it.
    – user82901
    Sep 19, 2013 at 6:30

Your Answer

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