C++.CodeCompared.To/C

Note main(void) rather than main(): in C an empty parameter list means "unspecified arguments", not "no arguments", so main() declines a check the compiler would otherwise do for you. The newline is part of the format string because printf has no std::endl, and it does not flush — which matters when a program crashes with output still buffered. And printf is variadic and type-unchecked at the language level, so the format string and the arguments can disagree; GCC's -Wformat catches the common cases but it is a warning, not a rule.

One name, one symbol. That single constraint is what rules out function overloading, default arguments, namespaces, and member functions, all of which need more than one entity to share a source-level name. It is also what makes C the lingua franca between languages: a C symbol is just its name, so every other language can call it without knowing anything about C's type system. Note the comment style too — // is legal in C99 and later, but /* */ remains the convention in most C codebases.

This is why C library authors prefix everything — SDL_, png_, sqlite3_, pthread_ — and why short generic names in a C header are considered rude. There is no using, no nested namespace, and no way to shorten a prefix at the call site; a local #define is the only approximation and it is a bad one, because it is textual and does not respect scope. Plan the prefix before you write the library, because changing it later touches every caller.

File-scope static is the whole mechanism, and it does the same job: the symbol does not reach the linker, so two .c files can each have a private double_it. This is the closest thing C has to private, and it operates on files rather than types. Beware that static means something completely different inside a function (a variable with lifetime beyond the call) — the keyword is overloaded exactly as it is in C++.

C's inline is not C++'s. In C++ an inline function may be defined in every translation unit and the linker picks one; in C, bare inline requires exactly one translation unit to also provide an extern declaration, and forgetting it yields an undefined-symbol error at link time. static inline avoids the whole question and is what you will see in real C headers. #pragma once works in GCC and Clang but is not in the standard, so portable C keeps the #ifndef guard.

C keeps struct tags in a separate namespace from ordinary identifiers, so the type is spelled struct Point in full. The near-universal fix is the typedef above, which is why so much C code declares structs that way — and why the tag and the typedef name are usually identical, which looks redundant but is not. A side effect worth knowing: because the two namespaces are separate, a variable named Point and a struct Point can coexist, which is legal, confusing, and occasionally deliberate.

Type names in C stay short because the type system stays small: there are no templates, so there is no std::map<std::string, std::vector<int>>::const_iterator to abbreviate. The idiom you will actually miss is the sizeof(array) / sizeof(array[0]) line above, which computes an element count and silently produces nonsense the moment the array decays to a pointer — for instance after being passed to a function. C23 adds auto and typeof, but this site targets C17.

sizeof('a') is 4 in C and 1 in C++: a character constant has type int in C and type char in C++. It rarely matters, but it is the classic proof that C is not a subset of C++. NULL is a macro rather than a typed keyword, so it does not distinguish a null pointer from the integer zero the way nullptr does — which is one reason C compilers cannot catch passing NULL where an int was wanted. C23 promotes bool, true, false and nullptr to real keywords; C17 does not.

C++ made const imply internal linkage and constant-expression-ness precisely so that it could replace #define for named constants. C did neither, so a const int at file scope is an ordinary variable with external linkage — put one in a header included twice and you get duplicate symbols. The C idioms are the anonymous enum above, which is a genuine compile-time constant with a type, or #define, which has no type at all. This is also why array sizes in C headers are almost always macros.

Casting malloc is a well-known C style error, and the reason is specific: before C99, calling an undeclared function made the compiler assume it returned int, and the cast would silence the resulting warning while the truncated pointer stayed broken. Modern C makes that an error anyway, but the convention stuck for the second reason — the cast is noise that has to be updated whenever the type changes. Write malloc(count * sizeof(*pointer)) and the size follows the declaration automatically.

The goto cleanup idiom is not a code smell in C — it is the accepted answer, used throughout the Linux kernel and every serious C codebase, because the alternative is duplicating the free list at each early return and eventually missing one. The rules that make it work: initialize every pointer to NULL up front, have exactly one label, and free in reverse order of acquisition. free(NULL) is explicitly defined to do nothing, which is what lets the single cleanup block run no matter how far the function got.

A freshly malloc'd struct holds indeterminate bytes, so reading a field before assigning it is undefined behavior — use calloc when you want zeros, which is why the previous row used it. There is no new[]/delete[] distinction because there are no destructors to run, so one free serves both. malloc returns NULL on failure rather than throwing, so the check is on every call and cannot be skipped. And sizeof(*single) rather than sizeof(struct Reading) keeps the size correct if the declaration's type ever changes.

readings = realloc(readings, …) reads naturally and leaks: when realloc fails it returns NULL without freeing the original block, so the only pointer to it has just been overwritten. Always land the result in a temporary first. Two more things to carry over: growing one element at a time is O(n²) in copies, so real code doubles a separate capacity field, and every pointer into the old block is dangling after a successful realloc — the same invalidation rule std::vector has, with nothing to warn you.

The naming convention is load-bearing, since the prefix is all that groups these functions with their type: counter_ here, fclose/fread/fwrite in the standard library. A const member function becomes const Type *, which is the same guarantee written one level out. Note also Counter counter = { 0 }; — there is no default constructor, so a struct left uninitialized contains garbage, and = { 0 } is the idiom that zeroes every field.

Nothing calls buffer_destroy for you: not scope exit, not an early return, and nothing at all on a path that gotos past it. This is the discipline the previous goto cleanup row exists to support. Two conventions worth adopting: return a status code from the init function rather than leaving failure unreported, since there is no constructor exception to throw, and null the pointer in the destroy function so a second call is safe — C has no way to mark an object as destroyed.

An opaque pointer hides the fields from the compiler, not merely from the programmer: a caller that never sees struct Connection's definition cannot reach a field even by trying, and — unlike a C++ private member — changing the layout does not force callers to recompile. That is why this pattern is everywhere in C library design (FILE, sqlite3, pthread_mutex_t in some implementations). The cost is that the type can no longer be stack-allocated by callers, so the library must hand out heap objects and take them back, which is exactly the _open/_close pair above.

Two conventions make the cast legal rather than merely lucky. Putting the base struct first means the standard guarantees a pointer to the struct and a pointer to its first member have the same address, so the downcast is well-defined. And the vtable is static const, so one copy is shared by every instance — exactly what C++ does. This pattern is how GTK, the Linux kernel's file_operations, and COM all work. What you give up is any type checking on the cast: get the base wrong and there is no diagnostic, just wrong memory.

The void *context parameter — variously called user_data, closure, or arg — is the standard C answer to closure capture, and once you recognize it you will see it in every callback API you have ever used. When you design one, always put it there even if today's callbacks need nothing: adding it later breaks every caller. The cautionary counter-example is qsort, whose comparator takes no context, which is why sorting by a runtime-chosen key needs a global variable or the non-standard qsort_r.

Because the length is not stored, strlen walks the whole string — so the innocent-looking for (i = 0; i < strlen(text); i++) is quadratic. Because the buffer is fixed, every write needs a bound, which is why strncat appears above rather than strcat, and why its size argument is the remaining room rather than the total. And because the terminator is what makes it a string, a buffer that fills exactly leaves no room for it — the commonest single cause of C string bugs.

It returns the length the formatted string would have been, not the number of bytes written — so wanted >= sizeof(line) is exactly the truncation test, and code that ignores the return value silently produces a shortened string. Never use sprintf, which has no bound at all, and prefer snprintf to strcpy/strcat chains even when the latter would fit, because one call with one bound is easier to audit than four. Note also that %s with an int argument compiles and crashes; the format string is a second, unchecked type system.

What C does ship is qsort and bsearch, both taking a comparator, and that pair covers a surprising amount of ground: sort once, then binary-search, and you have a read-mostly map without writing a hash table. When that is not enough the options are to write the structure (a few hundred lines for a decent hash table), to vendor a single-header library, or to restructure so you do not need one. Real C codebases lean on the third far more than a C++ programmer expects — fixed-size arrays and linear scans are genuinely fine at the sizes most code actually handles.

Note the comparator body: (first > second) - (first < second) rather than the tempting first - second, which overflows for large-magnitude inputs and returns the wrong sign — a real and frequently-shipped bug. qsort also gives no stability guarantee (std::stable_sort has no C counterpart) and no way to pass context to the comparator, which is why sorting by a runtime-chosen field needs a file-scope variable or the non-standard qsort_r. The type erasure is the whole difference: std::sort monomorphizes and inlines, qsort cannot.

One allocation instead of two means one cache line rather than a pointer chase, and one free rather than an ownership question — which is why this appears throughout networking code and the Linux kernel, where a header followed by a variable payload is the shape of nearly everything. The rules: the flexible array must be the last member, the struct must have at least one other member, and sizeof the struct does not include it, which is what makes the sizeof(*packet) + length arithmetic correct. C++ has no standard equivalent; the closest is the non-standard "struct hack" with a one-element array.

Nothing checks that the two pointers have the same type, or that size matches either of them — swap_values(&an_int, &a_double, sizeof(double)) compiles and corrupts memory. It also cannot be inlined through the indirection, so it is slower than the template for small types. This is the trade every void* API in C makes, including qsort and memcpy. The alternative is the macro in the next row, which keeps the speed and loses different things.

Every argument appears twice in the expansion, so LARGEST(next(), 0) calls next() twice — the classic macro bug, and the reason the parentheses around every parameter are not optional either. There is no scoping, so any temporary the macro introduces can collide with a caller's variable, which is why C macros use __ugly_names. And the argument types are never checked: mixing an int and a double here silently applies the usual arithmetic conversions. C11 _Generic can dispatch on type inside a macro, which recovers some safety at considerable cost in readability.

The naming convention is worth copying rather than inventing: a suffix for the type (abs/fabs/fabsf) or a descriptive verb phrase (connect_on_port). Default arguments become a wrapper function, which has one genuine advantage — the default lives in one place at link time, rather than being baked into every caller's compiled code the way a C++ default argument is. C11's _Generic can fake overloading inside a macro, and that is exactly how <tgmath.h> makes sqrt work for floats and doubles alike.

The visible & is arguably an improvement — a C++ call double_in_place(reading) gives no hint that the argument may change, while &reading says so. What is genuinely lost is the guarantee: a reference parameter cannot be null, so C++ needs no check, whereas every C function taking a pointer must decide whether null is a caller error (document it and let it crash) or a supported input (check it). Pick one per function and say which in a comment; the standard library is inconsistent about this and it causes real bugs.

Struct assignment, struct arguments and struct returns have all been in C since C89, and the compiler applies the same return-value optimization it does in C++ — the result is built in the caller's storage, not copied. The one thing that does not come along is deep copying: a struct containing a char * copies the pointer, not the string, because there is no copy constructor to run. Arrays are also still special, and still decay to pointers when passed, which is why a struct wrapping an array is sometimes used to get by-value semantics for one.

Note strtol rather than atoi: atoi returns 0 for both "0" and "nonsense" and cannot tell you which, so it has no place in code that cares. The stopped_at pointer is how strtol reports where parsing ended, which is what makes "trailing garbage" detectable. The bigger consequence is one the C++ reader will feel constantly: an ignored return value is silent, so there is no equivalent of an unhandled exception terminating the program — a failure nobody checked simply proceeds with garbage.

errno is thread-local in any modern implementation, so it is not the data race it looks like, but the timing rule is strict: read it immediately after the failing call, because a successful library call is permitted to clobber it and many do. It is also only meaningful after a failure — a successful call may leave any value behind, so testing errno without first testing the return value is a bug. strerror turns it into a message; perror prints one directly. Nothing forces you to look at either, which is the recurring theme of C error handling.

C17's _Static_assert requires the message argument — the single-argument form C++17 allows is a C23 addition and does not compile here. Including <assert.h> gets you static_assert as a macro spelling of the same thing, which is what most C code uses. Runtime assert behaves identically to C++'s, including being erased by -DNDEBUG, which means the usual warning applies twice over: never put an expression with side effects inside one, because in a release build it will not run at all.

C++ requires the designators to appear in declaration order, so {.verbose = true, .port = 8080} above is a C++ error and valid C. C also allows mixing designated and positional initializers, and array designators ([3] = 7), neither of which C++ has. The shared and genuinely valuable part is the zeroing: any field you do not name is zero-initialized, so a struct that gains a member does not silently leave it as garbage in existing code — which makes this the right default for configuration structs in both languages.

A compound literal has an address and a storage duration — automatic inside a function, static at file scope — so &(struct Point){5, 6} is legal C and has no C++ equivalent. That makes it genuinely useful for passing a one-off struct to a function taking a pointer, which otherwise needs a named local. The lifetime rule is the one to respect: an automatic compound literal dies at the end of its enclosing block, so returning that pointer is the same dangling-reference bug it would be for a local.

This is a promise you make, and nothing checks it: call add_arrays(values, values, values, 3) and the behavior is undefined, with the usual symptom of correct debug builds and wrong optimized ones. That is the opposite of Rust's &mut, which gives the compiler the same information but proves it. Used correctly on numeric kernels the payoff is real — often several times faster, because the compiler can hoist loads and vectorize instead of assuming every store may have invalidated every load.

No heap allocation means no free and no failure path, and sizeof on a variable-length array is computed at runtime and gives the real size. The reason C++ said no is the reason to be careful in C too: the length is unchecked, so a large or attacker-influenced count blows the stack with no diagnostic — several CVEs have exactly this shape. Use them for small, bounded sizes only. Note also that C11 made VLAs an optional feature, so strictly portable C cannot rely on them; GCC and Clang both support them.

C explicitly blesses reading a union member other than the last one written; C++ does not, and although every mainstream C++ compiler does the expected thing in practice, the standard permits it not to. The portable answer in C++ is std::memcpy, which every optimizer recognizes and turns into the same single instruction, so it costs nothing — and C++20 added std::bit_cast as a typed spelling of it. When porting C to C++, union punning is one of the specific things to look for, because it compiles silently and only misbehaves under optimization.

extern "C" tells the C++ compiler to emit an unmangled symbol with the C calling convention — it does not change the language of the code inside, which is still C++. That means an extern "C" function may not be overloaded (there would be one symbol for two definitions) and must not let an exception escape, since the C caller has no unwinding machinery. The __cplusplus guard is the standard way to write one header both compilers can read, and you will find it at the top of essentially every C library header in existence.

The two languages share an enormous amount and diverged in 1983; C has kept moving since (C99, C11, C17, C23) and not always toward C++. Practical consequences: compiling a C file as C++ is a porting exercise rather than a no-op, C++ keywords like new, class, template and this are ordinary identifiers in C and appear in real headers, and a header meant for both must avoid every construct either language rejects. The reliable way to use C from C++ is to keep compiling the C as C and cross the boundary with extern "C".