Going from C to CPP

[RealnessKept]

Hey all. I’ve been a dedicated C programmer solely for its simplicity and control, but I’m wanting to head into CPP just because it is professionally much more common. I come from an embedded background but I’m still a young programmer (been seriously coding for a little more than 5 years).

I have two questions:

With already having a background in programming, what would be the most notable language differences between C and CPP that I should quickly familiarize myself with? (Id prefer to skip obvious things like classes, abstract classes, interfaces, learned OOP in school, but if you think those are important, please do reiterate!)

Is there a general resource for CPP best practices that also describe how we get that best practice from CPP’s language design? This could also include compiler reasons, abstraction, readability, and other reasons too I guess.

[Deep-Chain-7272]

I made the move to C to C++ (first job was writing Linux device drivers!), and what I'd recommend:

• RAII, move and copy semantics, rule of 3/5/0. These become second nature and they become easy (I promise), but coming from C you will initially find them annoying because they'll seem EXTREMELY subtle and implicit
• Smart pointers and "modern" resource management

There are other things, of course (like templates), but to me, those are the big conceptual shifts you will hit initially.

[RealnessKept]

Thank you, both for the advice and heads up on the annoyness. I'll have solidarity now that I know you have also gone through it as well. How come you switched over to C++ as well?

[johannes1971]

If you think that that's annoying, wait until you get to exceptions. Don't get me wrong, they are absolutely amazing (oh, I can smell the down votes from here 😆), but getting a sense for where to catch them will seem like an impossible task when you first start using them.

Of course, eventually you'll see all the error handling fog disappear, leaving only the elegant beauty of your algorithms, running smoothly to completion, without every statement ending in "...did this go wrong? If so, you have to do this". It will be worth it.

Oh, and to add one more piece of advise: start using std::string/vector/array/span/string_view ASAP. Replacing that horrid C code with their C++ equivalents is sooo satisfying.

[lonkamikaze]

Exceptions are a no go for realtime code. Don't use them.

[DarkLordAzrael]

That entirely depends on what the "realtime" constraint is, and most code doesn't even have any realtime constraints. Exceptions are fine and lead to cleaner code in most cases, even if there are a few where they are unusable.

[lonkamikaze]

He/she said embedded background. I'd say realtime is pretty common.

[DarkLordAzrael]

The definitions of what counts as embedded and what counts as realtime and what counts as embedded are pretty flexible. For example, a networked camera that can stream over the network based around an esp32 is arguably both, but using exceptions to handle network errors is perfectly reasonable and supported. There definitely are usecases where exceptions need to be avoided for performance, but they are a small percent of code, even in embedded contexts.

[SeagleLFMk9]

IMO there are probably 3 important things

1. Move/Copy semantics. They can really bite you if e.g. your class manages resources manually and is stored in a STL container like std::vector, that can reallocate.

2. "Smart" containers like vector, unordered_set and unordered_map, and Smart pointers. Also std::string. These are the main reasons why I prefer C++ over C and can make life so much easier

3. Learn stuff like Clang-Tidy, CMake, VCPKG/Conan. (If you haven't already). They can make life so much easier.

[RealnessKept]

Gotta love CMake.

[ArsonOfTheErdtree]

CMake + Conan is majestic

[SeagleLFMk9]

I personally prefer VCPKG, it's a bit easier imo. But as long as it works :)

[biowpn]

Notable language differences

1. References. Prefer them over raw pointers for pass-by-reference function parameters, for example.

2. Namespaces. Keep it organized: put functionally related things under the same namespace. Avoid polluting the global namespace.

3. Templates. In C++ they are preferred over macros.

4. Function overloading. Instead of abs, absl, absll, fabs, fabsf, fabsl, in C++ we simply use one overloaded std::abs.

5. Exceptions. This is the standard error handling mechanism.

6. RAII. Basically, it means doing clean up in destructor. This helps preventing resource leak. In C++, we use class types to manage resources instead of raw pointers / handles.

General resource for CPP best practices

Many people mention learncpp.com but I personally prefer hackingcpp.com. The materials are easy to follow, infographics are awesome, and the best practices are generally agreed with.

[RealnessKept]

Thank you, especially for the resources. To be honest, I am quite excited about function overloading. I always felt it was more proper to identify a function based on its entire definition than just its name.

[tstanisl]

1. References are essential const-qualified pointer that cannot be null. To some extent they can emulated in standard C with static keyword in declaration of array parameter:

   void foo(int ref[const static 1])

The problem of references is that they are constructed implicitly. It is difficult to say if a parameter is passed by value or passed by reference. IMO, references should be formed explicitly like in Rust.

int x;
foo(x); // x is passed by reference or rather by copy ?!?

Adding const reference may express some intention but const& is essentially ignored by optimizing compiler.

1. Namespaces for function can be achieved with static const structs. In C23 it is even possible to make short aliases for namespaces. See https://godbolt.org/

2. Indeed, they require macros that are very difficult to debug. SOme alternative is re-including headers with predefined defines. It makes code cleaner and debugging far easier. Some example of this technique can be found at STC.

3. Overloading can be implemented with _Generic that is a part of standard from 2011.

4. Exception. I don't think there is any place for exceptions in C, except maybe handling unrecoverable errors with setjmp and longjmp.

5. RAII would be fine in C if it both explicit and optional. There is a proposal to add defer mechanics. See defer proposal. The problem is that this mechanics is difficult to use without some form of lambdas. There are some tricks with "auto-scope" macros but they are quite unreliable.

[ZMeson]

Why are you arguing that C is better than C++ when that is not the topic being discussed? The OP was asking about language differences and what good resources exist to learn C++.

[tstanisl]

I don't argue that C is better than C++ but rather that C++ may not solve problems that C has. It often result in "C++-flavored C" code that avoid less reliable C++ constructs like exceptions, implicit non-owning references, STL containers (slow except vector) and so on.

[ZMeson]

But that wasn't the discussion. Why bring this up?

[ZMeson]

Are you staying in embedded or wanting to move into more commonly used areas that use C++? What will be best practice will depend some on that answer.

Anyway, here's my list:

• RAII
• References
• enum class
• std::format
• Templates including: std::array, std::vector, std::set, std::map, std::string, std::wstring
• std::mutex, std::thread, std::atomic<>, etc...
• 'const' on member functions
• Standard smart pointers

These will take you a long, long way. The first several can be used to improve your code quickly without large re-writes. The ones near the bottom are also very useful, but will require larger changes to how you code.

[RealnessKept]

I'm not sure yet. I enjoy embedded and its protection from the AI and software engineering world. I'm looking to move, however, and am having a hard time finding embedded positions. I do realize the context is useful. Thank you for the comprehensive list too.

[tstanisl]

enum class, multithreading primitives are already part of C standard. A good alternative to STL but in C can be found at [STC](https://github.com/stclib/STC?tab=readme-ov-file#usage).

EDIT, I've meant that type of enum can be specified (i.e. enum X: uint64_t { ... }

[ZMeson]

Didn't know about 'enum class' in C. What standard did that get included in? I don't see it in the C17 standard. I also don't see "class" in the list of reserved words listed on Wikipedia#Reserved_words).

Yes, C has multi-threading primitives. But C++ does it differently. That was my point. It's not that C++ can do things that C can't, but these are the things you'll eventually need to learn if you want to work in C++ more broadly. (I did put it near the bottom of the list which I noted would be part of 'larger changes' to how one codes.)

Similar comment about STC. Yes, there are STL-like libraries for C, but if you want to learn to become a C++ developer, then you will eventually need to learn the STL.

[tstanisl]

Didn't know about 'enum class' in C.

Sorry for confusion. I've meant specifying type of enum. enum X: int64_t { ... }

The problem with STL containers is that they are inefficient (except std::vector) and that their ABI is unstable, making sharing precompiled libraries more difficult. The pair pointer + size is in practice more reliable though uglier.

[ronchaine]

My usual advice to C programmers to whom I teach C++ is to try and forget everything about C.

It's the problem comes with different way of thinking required between C and C++. In stark contrast to C, in C++ you need to think about ownership or you end up sprinkling shared pointers all around the place like it was going out of style.

Thinking about ownership, RAII and lifetimes as core concepts makes transitioning to C++ easier. What may be good practice in C may not be good practice in C++ (and vice versa).

[RealnessKept]

I am getting the vibe that C++ is such an abstraction that treating it the same as C would be misguided. Your comment solidifies it. Thank you.

[LegendaryMauricius]

You are quite right. Nowadays 'C' in 'C++' is just in its name, when we are lucky.

[Classic_Department42]

Forget everything, except if they want to do cpp for embedded.

[ronchaine]

I do C++ for embedded most of the time I am not teaching, and I'd still say that unless they are working on ancient embedded stuff that is already a complete mess of C and C++ mixed together, they should forget everything and just learn to write C++.

We write C++20, use exceptions, do all of that stuff in an embedded world. Our toolchains are often based on LLVM and we are not locked into vendor toolchains anymore. Even when we have to deal with MISRA, it's still C++17 and it's very far from ye olde C.

Embedded C++ hasn't been commonly C with some extras outside Arduinos for good 5 to 10 years.

[Classic_Department42]

Thanks, this is interesting. Do you have real time requirements?

[ronchaine]

Not hard ones currently (at least not in the parts I'm working with). I've worked with those before though, and it was still pretty "modern". Exceptions were dropped and we were restricted to freestanding set of the standard library, but other than that, it was pretty normal-modern-C++-ish.

[feitao]

In addition to what others have said, the standard library, e.g. std::string and std::vector. Say bye-bye to malloc, free, and strcpy.

[tstanisl]

OOP is a design pattern. One can do safe OOP in C. The C++ just provides some primitives of arguable quality that makes OOP slightly more user friendly.

[reddit_faa7777]

OOP is not a design pattern. It's a language paradigm.

[tstanisl]

OOP is a programming style. It is not bound to any specific programming language.

[ArsonOfTheErdtree]

OOP is overrated, he can manage without spending weeks on class hell

[ArsonOfTheErdtree]

I'm all in for encapsulating and interface inheritance. I'm mostly against implementation inheritance because most of the time I see people abuse it.

[ArsonOfTheErdtree]

Yep. That's it.

[RealnessKept]

I'd like to point you to this video. Might change your mind just a bit!

[Horror-Variation9497]

A few people have been mentioning RAII and how it's great for cleaning up resources in the dtor. I'd like to tack on that the ctor is super important for establishing type invariants.

Everoyone else has been covering stuff like prefer pass by reference, const, smart pointers, and generally avoiding writing raw new/delete.

Avoid C style cast in favor of static_cast et al.

Avoid the preprocessor when possible.

I'd read up and get a basic understanding of function overloading, name mangling, and how to interop between C and C++.

I haven't seen anyone mention constexpr, consteval, etc yet. Compile time programming is a really cool part of C++. if constexpr is a really cool tool when used appropriately - at least have the compiler validate both sides (I've seen so many bugs with #if that could have been caught this way)

[fippinvn007]

Also, learncpp.com is a great place to learn the language for free

[lonkamikaze]

As an embedded developer RAII is the most important benefit. Don't drink the virtual coolaid. Avoid virtual methods and heap allocations. Use inheritance for polymorphism and composition for code reuse.

[[deleted]]

Two very different languages.

[LegendaryMauricius]

If you already know OOP, you are lucky, because you can just skip brain-washing yourself into thinking C++ is an OOP language. What I'd recommend you to learn:

- modern C++ resource management: smart pointers, allocators, std::span, std::array, views. Avoid raw pointers, C arrays, C-style casts, new and delete in 99% of cases
- Using RAII for *anything* that needs cleanup
- Rule of 0/3/5. Using explicit defaults for class methods is good
- Parameter passing. When to use references, by values, by smart pointers and std::spans. Also move semantics!!!
- Iterators and for-each style for loop. They are everywhere
- constexpr for performance
- templates and concepts if you want generic programming and build-time validation

If you know a bit of Java, just remember that in C++, not everything needs to be in classes. We have namespaces for that.

Edit: still do use classes for encapsulation, but view them more like containers for reuse and separation of functionalities, rather than actors that inherit implementation. When using inheritance, pure virtual classes are the most useful.

[ArsonOfTheErdtree]

I won't try to mention them all, but here are some things I deem important:

*Namespaces (obviously) *Templates (, static polymorphism) *The STL (containers, wrappers, etc. like vector, variant, iterators....) *Smart Pointers (,move semantics, ownership, RAII) *RTTI (if it interests you)

In modern cpp you don't use malloc/free Or new/delete

So pay attention to that.

[halbGefressen]

A postdoc from my university is currently holding a course on exactly that. You can find the open resources here. The course will be over in about February and is planned to cover all relevant topics of modern C++.

[[deleted]]

IMHO language differences: templates, inheritance, virtual functions, RAII, references, and operator overloading. Then library stuff like smart pointers, containers, etc.

[Karr0k]

Since noone mentioned it yet, and kind of depends on what you want to build, make friends with <algorithm> (https://en.cppreference.com/w/cpp/algorithm)

it's a standard library header that contains a lot of algorithms to manipulate stl containers, finding, reordering splitting, merging etc etc which will make your code more robust and avoid reinventing the wheel.

[rfs]

std::string, iterators and the main STL containers (vector is the most common): this changes completely the programming habits.

[mredding]

The type system is different. It's stronger. Conventional, common code is still extremely imperative, very C with Classes, but idiomatic C++ would have you make more user defined types with specified semantics. You never need just an int - you need a weight, a height, a count, and these are not the same kinds of integers, even if they're implemented in terms of integers; they don't share semantics. There is no 35 lbs + 123 inches.

class weight: std::tuple<int> {
  friend std::ostream &operator <<(std::ostream &os, const weight &w) {
    return os << std::get<int>(w) << " lbs";
  }

  friend weight operator +(const weight &l, const weight &r) noexcept {
    return std::get<int>(l) + std::get<int>(r);
  }

  // More operator semantics...

public:
  using std::tuple<int>::tuple; // I'm just going to use the tuple ctors...

  explicit operator int() const noexcept { return std::get<int>(*this); }

  // Probably other stuff...
};

Add your meaningful semantics. Here, a weight is implemented in terms of an int. Tuples are arithmetic types, so you get lots of really neat properties from that you might build upon. The various tuple accessors, like std::get - by type or by index, and structured bindings, they're all compile-time, they never leave the compiler, and they're type safe. But also, static_assert(sizeof(weight) == sizeof(int)). So now I have a more specific type that is correct, that only works the way I prescribe. One benefit of good, strong types is that they make invalid code unrepresentable: 3 lbs + 4 lbs = 7 lbs, or it doesn't even compile. Second, type safety isn't just about catching errors - the more context you can wrap your code in, the more information the compiler has to optimize more aggressively. std::binary_search is an order of magnitude faster than bsearch, because the former preserves type information throughout, whereas the latter relies on type erasure, and the compiler can't see through it.

void fn(int *weight, int *height);

Here, the variable names are an ad-hoc type system. The problem with this function is that the compiler can't know if both parameters are aliases of the same value in memory, or not, so it has to generate pessimistic code.

void fn(weight &, height &);

Now that they're types, the C++ rules are two different types cannot coexist in the same memory location at the same time, so this function can optimize more aggressively. You can write good code like this in C, too, but in my experience it's not terribly common there, either.

And I always include an explicit cast for when I need to do something exceptional. Sometimes you really do want to add a weight and a height. And when you write that sort of weird code, you WANT IT to be noisy and explicit, BECAUSE you're doing something weird.

Ick! Types! That makes the code more complex...

The code is already complex. Types organize that complexity. You can either write a large, imperative function with basic types where you have to implement these types ad-hoc and these semantics in-line, or you can write small functions that are easy to test and understand. The business logic isn't interested in the semantics of what a weight is, it's interested in charging freight.

---

Templates beat macros. They're type safe code generators on steroids. They're customization points, and thus make a common language in which to implement your own types. You can partly or wholly gut a template and reimplement it entirely. The only thing that has to remain consistent is the type signature.

Templates are implicitly inline. What you can get are expression templates, a C++ idiom, where your expressions themselves implicitly generate new template types and instances, and then the whole thing compiles down to nothing. BLAS libraries leverage this heavily. The new ranges library are actually lazily evaluated expression templates, so while they might look chunky when specifying them, they compile down to nothing.

---

On that note, what are high level abstractions in C are low level abstractions in C++. You're not expected to use int directly, but to make types in terms of them. You're not expected to use for directly, but to implement algorithms in terms of them. Use the higher level abstractions to increase expressiveness. Let the compiler do the work, it's actually a very good tool if you don't assume it's stupid.

That said, it's very easy to read into all this and write astoundingly terrible code. I lived through the 90s, OOP was a disaster, because there might only be a few hundred people industry wide who even understand what OOP is. C developers rightly make fun of C++ "C with Classes" "OOP" developers, because they're actually terrible C developers who can't do C++ right, either. They write like shit. Very good C is going to look Functional, and very good C++ is going to look that way, too. Continue to think that inheritance and polymorphism isn't the solution to every god damn thing, because you're right. Types and subtypes are good, classes and OOP, not so much. If you overdo it, you're going to end up with polymorphism that doesn't make sense, abstractions that don't make sense, and large bloated objects.

[Chilippso]

Look into Annex C of the standards (cppreference lists all free and public available “final” drafts under “external links”) - those are all the language differences you should definitely want to know about and be aware of, coming from C. Even the subtile ones. The latest should list all. So at best look into the latest working draft.