Encapsulate standard C functions?

Question

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?

Answer 1

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 ...

http://xkcd.com/927/

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.

Answer 2

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.

Answer 3

+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.

Answer 4

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.