What are the key differences between low-level C development and higher level OOP development? [duplicate]

Question

I have been using high-level OOP language (like C# and/or Java) for quite some time. I know patterns like the gang of four, can read and write code reasonably well and am considered a senior by his peers.

I am moving to low-level C development. As a result of my background I am unfamiliar with many of the technologies and skills inherent in lower level development/implementation.

What are the key differences in the technology and approach to development that I need to understand in order to be successful in C development when coming from a higher level OOP background?

Answer 1

It will depend on how "close to the metal" you'll need to get. But a few common things you might find that may not be familiar to you:

• Right off the bat, the fist thing you'll have to pay a lot of attention to is resource management. C doesn't run a garbage collector and doesn't have automatic finalizers (AKA destructors), so allocating a chunk of memory or opening a file/socket implies that you have to manually keep track of the lifetime of that resource and free it at some point in the program. That's probably the biggest shift in paradigm, coming from Java/C#, but once you get used to it, it's no big deal. We have very good tools nowadays that help tracking resource leaks, so you don't have to live in fear.

• C doesn't provide a safety net. And by that I mean no array bounds checking, no memory guarding whatsoever and very little runtime protection against common programming mistakes. You might have heard that "C is a big gun, but it is very easy to shoot yourself in the foot with it" - and that is true, high execution performance requires making a few tradeoffs, and waving runtime checks is one of those. Any safety mechanisms that your program might need are implemented by you, the language doesn't offer much out-of-the-box.

• C is very lightweight, and so is its Standard Library. The Standard Lib consists basically of a handful of IO functions and math functions, that's about it. If you're into embedded C, you might not even get that! No nice containers and generic algorithms. Again, in the spirit of the language, if your application needs a feature, it implements it. The language and library makes no assumptions for you.

• Data typing is much more slack in C. This is debatable if good or bad, but it does allows for some interesting things like reinterpreting pointers and data read from files.

• You have to be more aware about the hardware where your program is going to run. This is not particularly related to C, but to any flavour of low-level performance-oriented programming. The closer you get to the metal, the more you have to pay attention to things like CPU cache usage, memory footprint, device IO costs and algorithm time complexity. For instance, you might eventually find out after profiling that a plain array and linear search is faster than a binary search tree due to better cache access patterns in the target architecture.

• You have to be more aware about the data, not just the code. The purpose of any program is to transform data, but it is easy to get carried away about the code and abstractions when writing high-level interfaces and forget that the code actually has to process some data and output some other data. The more you know your data, the easier it gets to optimize the code, that's data oriented design.

Those are some interesting aspects to consider. Certainly there are more, but that's what I can think of for the moment. I hope that's not too daunting. C is a great language to work with, even though I personally like C++ better ;). And low-level performance-oriented programming can also be a lot of fun. Once you enter it, you'll see programming in a whole new way.

Answer 2

The key difference is that:

• When doing high level development, you are mainly dealing with how to solve a real world problem. Your "problem domain" is a real world situation, your entities are real world entities, and your logic is application logic. (The term "real world" is somewhat flexible, here, since for example you may be developing an MMORPG, like World of Warcraft, in which case the world is anything but real, but still, within that context, that's the world you are treating as real.)

• When doing low level development, you are mainly dealing with how to get the machine to perform a specific task as efficiently as possible. The entities that you are dealing with are most of the time highly technical in nature, like memory blocks, block chains, hash values, etc. and your logic has nothing to do with the real world, and everything to do with the machine. You are often dealing with concepts that are completely machine-specific, like the endianness of machine words, or the I/O ports through which you can communicate with a specific device, and the sequences of byes that you have to send to it to get it to do its job.

As a matter of fact, when interfacing between high level code and low level code, it is often beneficial to transform the high-level entities into low-level entities (or simply view the former as the latter, without a need for an actual transformation) so that the high level code never needs to deal with machine concerns, and the low level code never needs to deal with application concerns.

So, in your application you may have a collection of, say, customers, and be doing things with it of the kind that we do with customers, like charging them for goods purchased, or sending them newsletters, without caring about the internal representation of the collection. In your low level code, however, you will be seeing the collection as a fixed length array of pointers to objects, and you may know nothing about these objects other than, perhaps, that they can be invoked to compare themselves to each other or to compute their own hash values. You are not supposed to know that they are customers, and you are not supposed to send newsletters to them in low-level code.

So, if you find yourself using a low-level language like C, and having to deal with application entities like "customers", you are doing it wrong. You have been asked to use the wrong language for the job.

Answer 3

Being an experienced C programmer and less experienced with C++ (but I have coded in projects started by other persons, just never built up a C++ project from scratch, myself), I might be traveling the same path in the opposite direction. We might be meeting in the middle somewhere and I can tell you a little of where I have come from.

Certainly there are OOPsie features of C++ that C doesn't have. There are namespace issues, templates, etc, that I have not made use of. All I have done is used and created classes and instantiated objects within the classes. And modified code in classes that other folks had created.

That said, any C programmer can write structured code that is similar, in many key respects, to fully OOP code. You have struct, typedef, pointers to struct, the ability to cast the pointer to one kinda struct to another where there are fields in common. There is also union in which you can explicitly overlay fields that are in common and other fields that are not in common. This looks a lot like inheritance that you'll find in an OOP language.

Personally, I dislike many specific syntax of C++ that I would rather just program in C where I know precisely what the "right" way to do it is. I don't know Java or C# or whatever variant.

Answer 4

Major differences:

• You are responsible for all resource management. There is no garbage collection, nor are any buffers automatically extended if you need more space. This includes string management. C does not have a string type as such; strings are stored as arrays of char. If you want to append strings, you have to make sure the target buffer is large enough before doing so.

• There is no structured exception handling. Errors and exceptional conditions are indicated by function return codes or writing to a parameter (or by setting errno). You can kind-of-sort-of fake exceptions using the setjmp/longjmp library functions, but it's a hack at best.

• C does no bounds checking on array accesses. There are no built-in exceptions for accessing elements outside of an array. It is ridiculously easy to clobber memory you don't own (as can be seen by innumerable exploits over the years).

• Data types are not smart - arrays don't know how big they are (they lose their "array-ness" in most contexts), struct types do not have any sort of methods (you can kind-of-sort-of fake it using function pointers, but there's no implicit this pointer; you explicitly have to tell each function which struct instance to operate on).

• Code is organized into modules, rather than classes, where each module consists of type definitions, object definitions, and function definitions. There's no concept of inheritance between modules. Visibility for individual data items and functions is an all-or-nothing proposition - there's no equivalent for a "protected" visibility.

• There are no container types beyond arrays. You want anything more sophisticated than that, you will either have to roll your own or find a container library. Similarly, there are no standard algorithms (such as std::copy or std::foreach - again, you'll have to roll your own).

• There are no templates, generics, or other dynamic typing mechanisms. There's no overloading of functions or operators. All type information must be known at compile time.

• There are no user-definable name spaces. C supports a grand total of four namespaces - labels, tag names, structure and union member names, and everything else.

It is possible to write OO code in C; it's just a lot of work.

Think of C as a nasty-looking table saw with exposed sharp edges, no blade guards, and visibly frayed wiring, and you'll be in the right mindset.