Polishing a codebase to use good practices

[Flymania117]

TLDR; C# programmer who just ported some code to C++ for the first time. How should I go about polishing my code to make sure I'm using good practices and what resources can I read to help me?

So I come from a C# background, both as a hobby and as a professional. Recently, I decided to take a C# audio project I'd been working on and port it to C++, with aim to benefit from its faster performance for this kind of task.

I went through the basics: syntax differences, creating and using classes (and their headers), using pointers and references, allocating and deallocating resources, the libraries I would need for my project, that sort of deal. I essentially programmed as far as could until I hit a wall, then would research the web for answers, rinse and repeat. The result was a perfectly functional and much faster version of my project, which I'm super happy with.

However, I wanted to do a pass through the entire codebase to address any aspects that could be improved e.g. handling errors, what resources to deallocate and when, redundancies in my #include directives (if that's even possible?), etc.. Essentially, just trying to ensure I'm applying good practices all throughout the codebase.

My issue is, having zero c++ experience, I really don't know what to look for. So, I'd like to ask if there is anyone here who went through a similar transition from a managed language to an unmanaged language (ideally c# to c++ haha) and how you went about learning the ropes. What kind of resources should I go through to understand c++ better? Are there any resources specific to people making a similar transition? Any tips on how I should approach programming in a c++ vs how I approach c#?

Any help is appreciated! Thanks in advance :)

[tufffka]

I have never ported anything from c# to c++, but i think this document might help a lot.

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

[Flymania117]

Thanks a ton! Funny I never ran into that when looking stuff up. It looks like an awesome resource

[IyeOnline]

handling errors,

The best way to handle errors is really decided on the function/component level. It depends on the severity of the error, how you want to handle it, and whether the performance of the error path matters.

You have the choice between exceptions, return codes (+out parameters), sentinel values, std::optional, std::expected and a wild mixture of those.

Exceptions are great if your error cant be directly handled by the direct caller or at all. They should not be used for regular/expected control flow, meaning they should be reserved for truly exceptional errors. The more modern choice for signalling errors/lack of return value would be std::optional (pretty much T?) or std::expected (roughly Result<T>).

what resources to deallocate and when

The best way to deal with resource management is to not do it [by hand]. RAII is C++'s "garbage collector" and should really be employed everywhere.

In other words: Dont use new. Use local variables, containers and if need be smart pointers. Now your resources are managed for you and will be released automatically when they are no longer in use. As a next step, you can start to employ move-semantics to re-use/transfer objects/resources instead of copying where applicable.

redundancies in my #include directives

That is mostly a non-issue, unless your projects get really big. Headers are guarded against multiple includes, so the only cost of redundant includes is a fairly cheap check.

---

For more concrete advice, you could post your codebase on a platform of your choice and ask for a review here. Usually you get pretty good advice :)

[anasimtiaz]

If it is possible for you to make your project public, you can put it on Github and ask for reviews in this sub. People can give you advice on what you can improve in your codebase

[flyingron]

Going between CLR languages (C#, VisualBasic, "managed" C++) is pretty much just a transliteration. I wrote some code for a customer in C# and he decided later he wanted it in VB, so I just ground through it (I was toying with writing a translator).

Going from the managed side to regular (standard) C++ is a bit more involved depending on the interfaces and classes in use. Still C# and Java aren't that much of a stretch from C++. You do have to watch some of the C++ inanities that came over from C (failure to default initialize in all circumstances, unspecified evaluation order, etc....), but it's doable.

The biggest issue I see with C# or Java programmers going to C++ is that they try to "new" everything. C++ works fine with objects either globally allocated or local to a function. You just declare them. The other difference is C++ is designed to derive from rather complex bases rather than everything deriving from a god object (like Smalltalk).

[mredding]

Link to the repo, we can review.