C

C is the ancestor of C++ and remains the lingua franca of low-level systems: operating system kernels, device drivers, sensor firmware, and many embedded runtimes are written in C. You will rarely write a full SLAM system in C, but you will constantly read and interface with C code.

What to learn

• Pointers and memory: malloc/free, pointer arithmetic, arrays vs. pointers. C has no smart pointers or RAII — every allocation is your responsibility. Understanding this makes C++‘s abstractions (and their costs) much clearer.
• Structs and functions: C programs are organized around plain data structures and free functions rather than classes; many high-performance libraries keep this style for predictable memory layout.
• Function pointers: the C mechanism for callbacks. Sensor SDKs deliver frames by calling a function pointer you register — the pattern below is what almost every camera/IMU driver API looks like.
• The compilation model: headers, translation units, linking, extern "C". This is the same model C++ inherits, and most build errors you will fight in SLAM projects (undefined references, ABI mismatches) are easier to debug once you understand it.

#include <stdlib.h>

typedef struct { float x, y, z; } Point3;

Point3* cloud_alloc(size_t n) {
    return (Point3*)malloc(n * sizeof(Point3));  /* must free() later */
}

/* Callback registration, the universal sensor-SDK pattern */
typedef void (*frame_cb)(const unsigned char* data, int w, int h, void* user);
void sensor_set_callback(frame_cb cb, void* user_data);

Bridging C and C++

C++ compilers mangle function names to encode types; C does not. extern "C" tells the C++ compiler to use C linkage so the two worlds can call each other:

extern "C" {
#include "vendor_camera_sdk.h"   // C header from the sensor vendor
}

// C++ wrapper: RAII around the C API's open/close pair
class Camera {
public:
    Camera()  { handle_ = vendor_cam_open(); }
    ~Camera() { vendor_cam_close(handle_); }
private:
    vendor_cam_handle* handle_;
};

This wrapper pattern — C API inside, RAII outside — is how well-engineered SLAM codebases contain the unsafety of C interfaces.

Where C shows up in SLAM work

• Sensor drivers and SDKs: camera, IMU, and LiDAR vendors often ship C APIs; your C++ wrapper calls them through extern "C" interfaces.
• Embedded and microcontroller code: on compute-constrained platforms (drones, embedded boards), the sensor-side code is frequently plain C.
• Bindings: Python extension modules and many cross-language interfaces are defined at the C ABI level, because C’s ABI is the stable common denominator.

Common pitfalls

• Memory leaks and double frees: every malloc needs exactly one free; leaks in a 30 Hz frame callback exhaust memory in minutes.
• Dangling pointers: sensor callbacks often lend you a buffer that is invalid after the callback returns — copy what you need, don’t store the pointer.
• Ownership is undocumented: unlike C++ smart pointers, a C API’s header rarely says who frees what; read the docs (or source) for every handle-returning function.
• Struct layout assumptions: casting byte buffers to structs breaks under padding/alignment differences; use explicit (de)serialization for anything crossing a wire or ABI.

Why it matters for SLAM

Real-time SLAM lives close to the hardware, and the boundary between your algorithm and the sensors, OS, and accelerators is almost always a C interface. Reading C fluently — and understanding manual memory management — makes you a better C++ programmer and lets you debug the full stack, from driver callback to bundle adjustment. Most learners can treat C as a companion to C++ study rather than a separate deep dive.

Related

• C++
• Python
• C++/Python interop
• Edge deployment
• Camera device