[SOLVED] c++ recommended practices for a noob

Succulent of your garden · 2025-03-18 23:04:48

Hi

So I'm starting to learn c++, but the title is a little bit tricky to be honest. I know how to program in C, but never for a production level, but that made me learn c++ faster because of the similar syntax, and also because c++ is compatible with C, but I know that I should not try to do that. Also I know debugging with gdb, but also I'm currently learning valgrind and asan.

The question is: There is more to be concern apart from memory leaks ? I know that many could say that I should master things like concurrency or parallelism in c++, but I'm more concern in create fine code that could be used for production. So I know that I should master programming concepts and be able to be a better programmer is also a mandatory step to create code for production, but to make things easy just let's try to avoid that topic.

So I know that valgrind and asan have a lot of options. Any recommendations about it ? Also what about other tools like Lsan ? What are the common tools used by a c++ main developer to check programs ?

btw I know that pointers should be set to free and then set to null after usage, but any recommendations to avoid creating potential harmful code would be highly appreciated.

obviously it's for creating my c++ programs in my arch machine btw .

Last edited by Succulent of your garden (2025-03-26 12:16:33)

seth · 2025-03-19 07:08:24

Biggest issue is (in my experience) to completely undermine OOD.
Classes are effectively structs, all members public and everything treats everything else as an extension of itself (ie. class Foo implements details of class Bar)
You're creating the same spaghetti-code, but with boderline random grouping sprayed in.
Subsequent issues are code duplication and neglecting inheritence (so instead of deriving a class and altering an operator or so, you introduce wrapper code to implement the deviation outside)

This often happens by taking shortcuts instead of tackling the design issues (who's responsible for what, where should functionality be… ahhh, bah! I'll just make this public.)

C++ has some cool libraries and of course modern features that make your life easier, but the structural benefit is scalability (keeping stuff local in elements instead of throwing global stuff around and completely losing track) and you don't want to throw that away.
"Fixing it in post" isn't gonna happen, the problems spiral out of control and you sit in front of an unmaintainable mess and need an OCD and balls of steel to go clean that up.

schard · 2025-03-19 08:39:17

After having programmed about for a year in C++, I must say, that the biggest issue of the language is its backward compatibility to C.
It carries around a lot of baggage, which allows the programmer and especially noobs coming from bad tutorials to shoot themselves in the foot.
When you strictly program what's commonly called "modern C++", you can create highly performant code in a memory-safe manner, close to what Rust allows.
However, contrary to Rust, the compiler does not enforce such constraints and you can happily play around with raw pointers and manually manage allocation and deallocation of memory, without specially marked usafe blocks.
Another thing is template meta programming. It is a mightier tool than generics from other languages, but I feel it to be less ergonomic to specify trait bounds on generic templates, like you can do e.g. in Rust.
Then there's the object oriented aspect. C++ allows inheritance. I have programmed a lot in OO languages that allow inheritance and in my experience inheriting is seldomly a good idea.
I'm not just quoting the mantra of "prefer composition over inheritance" here, I've actually had the experience that the former is almost always the better choice to solve a problem at hand.
Similarly, I find that common behavior is best modelled with common traits, not with a common superclass.
To put this into perspective, this is coming from a Rust fanboy with a Python an Java background (who also programmed in C and C++), so take it with a grain of salt.

dimich · 2025-03-19 09:40:47

Succulent of your garden wrote:

What are the common tools used by a c++ main developer to check programs ?

Not a tool but concept of unit tests. Proper decomposition and unit testing can help to avoid many problems as soon as your program grows.

Succulent of your garden wrote:

btw I know that pointers should be set to free and then set to null after usage, but any recommendations to avoid creating potential harmful code would be highly appreciated.

Raw pointers usage should be avoided as much as possible. If you need to interface to C API, put raw pointer into wrapper, for example std::unique_ptr.

ReDress · 2025-03-21 08:32:28

Succulent of your garden wrote:

...but I'm more concern in create fine code that could be used for production...

Have you tried contributing to a project that you actively use? This is probably the best and also easiest way to get accustomed with how C++ development works in production. Like for instance how/which libraries to integrate into your projects, build systems and configurations, testing C++ projects etc.

twelveeighty · 2025-03-21 14:52:23

A lot of the most long-running, efficient with near-zero bugs software has been written in languages that most "experts" wave off as "unsafe", "inefficient", "outdated", etc. Present company excluded, of course. If you're lucky enough to find (and afford) an original '80s Pacman arcade machine, you'd experience that first-hand.

My position is: it's not the language, it's the programmer. You can write horrific code with the most modern, "memory-safe" and "secure" languages like "go", "rust", and all the flavors of the day.

My thesis is that programmers like to invent new languages because they get bored with the old ones and then justify that emotional decision with rational reasons that executives can sell to their customers. And, of course, each language comes with its own economy: toolchains, hosting, training/education, conferences, which drive revenue. When was the last time people got excited about the "Annual VisualBasic Conference"? And trust me, that certainly was the flavor of the day at some point.

ReDress · 2025-03-21 16:32:20

twelveeighty wrote:

A lot of the most long-running, efficient with near-zero bugs software has been written in languages that most "experts" wave off as "unsafe", "inefficient", "outdated", etc. Present company excluded, of course. If you're lucky enough to find (and afford) an original '80s Pacman arcade machine, you'd experience that first-hand.

With my little experience, it seems like most software that serves a purpose tends to survive or, rather, live to see another day.

"Near-zero bugs software" usually is a depiction of how much time, effort and expertise has gone into this software as bugs tend to occur with pretty much any language.

With a lot of software nowadays, not one single person knows the software in and out and this obviously leads to bugs.

mountaintrek · 2025-03-21 21:24:32

Suggestion

Look for an opesource project that uses c++ and volunteer. Read their developer documentation, participate in their developer communications, and read their style guides. Libreoffice held "clases" on youtube to aid new volunteers/users in writing code for libreoffice.

Succulent of your garden · 2025-03-23 21:24:43

Hi everyone:

First of all thanks for all your replies. If I take each of one to quote everything it would take me more time that I'm currently having to write this, but nevertheless I want to say that I had read all your post, and to each everyone I'm thankful for your suggestions and opinions.

So in long story short it seems that avoiding native C api is a must, trying to avoid as much as you can the use of global variables and using OOP are the keys for success in learning C++ .

I'm going to check to help in developing in a project, and see the libre office class, when I have time. Currently I'm focus in getting my lasts IT certifcations that I want to have and trying to write programs using python and typescript because probably the next half of the year I'm going to start to work doing full stack and devops stuff, but all of the information posted here is going to be applied in my free time

And for the discussion of bad software, yes it's not the language it's the developer, long story short: I found silly the idea of changing everything for Rust. I don't hate Rust and I'm going to learn it sooner or later (Also I know a little of C#), but as you many know, memory safety doesn't mean unbreakable program by default, as some people believe. So for me it's very naive and newbie thing to say that you should replace everything with Rust. If you have problems with the program most of the time the main issues are the devs and the project management, not the language (If obviously you don't make silly stuff like using javascript to make a kernel for a production OS, choosing the langue it's out of scope because I'm writting this fast as I can ). Nevertheless the cost of rewriting a program to another language hurts a lot more, because you don't longer have any person that knows the code in a certain degree welll enough. So for me using deep learning in the future to rewrite programs could be a nice feature to have , but in reality I highly don't see that could be most of the time used, because I think is more convenient to use another deep learning model to check bugs in the already made code. Also learning Rust could take more time that your team have.

So long story short:

I don't hate Rust.
Just use the right language for your work, if you have a work with C++ by heritage code maybe it's better to still coding in that language than rewriting.
Probably the right way to think is to make DL models that could help in finding bugs and errors, than just translate a code to another language.

That's what I think and sorry for typos and syntax errors. Currently I'm learning german and it's my third language, so sometimes my head it just a clusterfuck of words and syntax have oomem errors in my brain , maybe I must learn Rust first lol.

Last edited by Succulent of your garden (2025-03-23 21:37:58)

ReDress · 2025-03-24 10:48:30

Succulent of your garden wrote:

So in long story short it seems that avoiding native C api is a must, trying to avoid as much as you can the use of global variables and using OOP are the keys for success in learning C++ .

Mostly, if you have a good understanding of the language, using it becomes the easy part.... but like ;-) no-one has time to understand the language itself it's easier to jump right into using it for problem-solving, and then shoot yourself in the knee.

schard · 2025-03-24 11:11:25

twelveeighty wrote:

My position is: it's not the language, it's the programmer.

Indeed it is.
And this is why I program mostly in Rust these days. Using a strong type system and a pedantic compiler helps taking the source of most bugs out of the equation: me, the programmer.
I also drive a modern car with lane and breaking assist systems to take the weakest link out of the equation in road traffic: me, the driver.
It prevented me from rear-ending another car already once in the past year.
I could drive a classic car, but it'd have a bent bumper now.
I could write my software in C, but... you get the gist.

Succulent of your garden · 2025-03-25 21:58:49

ReDress wrote:

Mostly, if you have a good understanding of the language, using it becomes the easy part.... but like ;-) no-one has time to understand the language itself it's easier to jump right into using it for problem-solving, and then shoot yourself in the knee.

This is my full stack application, wait now it's half stack damn it. Oh boy here we go again.

schard wrote:

Indeed it is.
And this is why I program mostly in Rust these days. Using a strong type system and a pedantic compiler helps taking the source of most bugs out of the equation: me, the programmer.
I also drive a modern car with lane and breaking assist systems to take the weakest link out of the equation in road traffic: me, the driver.
It prevented me from rear-ending another car already once in the past year.
I could drive a classic car, but it'd have a bent bumper now.
I could write my software in C, but... you get the gist.

yeah sure, in a surreal reality world population could be more gigachad and starts to write mostly all in C [Okey, maybe html it's not a thing here i know], but since people like to invest the most value asset they have (time) efficiently, you would like to switch to another tools.

Some part of the problem came from discussion from people who like to program and do software, and people who works in creating software. If you have the time, go ahead made my day and write all in C, but that means coding all the data structures and more. So for creating something fine in less time you will switch to another language, like c++. Bro why should every time I need to create a hash table in my programs ? , just re use the library again who have been tested by many persons. The best example of this is python, because in esscene it's a glue language. For example in machine learning you are using c++ behind all the shit in the frameworks. But for some novice or people who don't earn money doing programming or in IT it's hard to tell them: Yes maybe using this language is more efficient in computational cost and more elegant, but sorry pal, we have been coding in java which probably it's the more meh language that I have ever know, it's not bad but also doesn't provide something to shine behind other languages, and because we have this java legacy type of code from the 90 and know it well, we are not going to change it, because if something bad happen, we can most of the time fix it quickly.

But what I see is people saying use Rust because it's far more secure than C++ and C. But for that you should invest way more time to learn it well, and also memory safety doesn't mean zero memory leaks. So for me it's a contradiction of requirements. It's one of the most hive-swarm mind behavior things that I could say that are happening recently. Forcing rewriting everything in Rust demands that in your team you will need to spend resources in teach them Rust, instead of just trying to improve newer devs in the organization and improve your already code that senior people in the organization knows mostly well.

I don't have anything against with creating translators of code to Rust, but saying that is the future, mmmm... not so sure . Probably is far more useful to use deep learning in finding bugs and errors in the code already made. in the future will be probably always have humans to check the code because 100% accuracy in neural networks it's impossible, so someone in the future should need to fix that 0.2% of probability of error made by the system

So in the end, hope someday people look more in creating AI tools for finding bugs in code than rewriting everything in Rust, also probably some video game devs loves to make buffer overflows in the game so they can improve the general performance, so time to create my buffer overflow in a bank app I guess (joke btw).

Also many thanks for you replies, really appreciated

Last edited by Succulent of your garden (2025-03-25 22:07:26)

schard · 2025-03-26 09:10:15

I just now realized, that maybe due to my own blinders, one thing I wanted to stress did not come across:
If you write C++, write "modern C++" and try to avoid the ancient C luggage.
https://www.youtube.com/watch?v=b8V-WIjlScA

ReDress · 2025-03-26 10:09:49

Guess writing C++ code requires that you write it in a C++-sy style....

Oh, wait, isn't that the case with any language? :-)

There's is this Python job somewhere on the internet. The programming question/assignment that they require you to provide is pretty easy but yeah, couldn't get the job even after providing a fully functional and satisfactory answer because ... even while my code was in Python, it wasn't really ... Pythonic.

Last edited by ReDress (2025-03-26 10:18:20)

Succulent of your garden · 2025-03-26 12:34:08

TY for the video schard.

Also since ReDress made the coding style issue, made me wonder: It's a good practice to change your legacy c++ code to a newer version ? , unlike python which probably it's like you have python 2 and 3, and 2 probably you would not need to use that, and if 3 broke then change your virt env to a right version. But it's C++ more like java ? Like sorry guys we are still going to maintain java SE 8 instead of jumping to java SE 25, because we are too lazy to do that.

Does the versions of c++ get out of support and then just die if you don't migrate to a newer version ? Or all versions are supported and you just pick your poison ?

Last edited by Succulent of your garden (2025-03-26 12:35:04)

seth · 2025-03-26 12:42:06

c++ doesn't technically "outdate" - you can compile a lot of ansi c code w/ g++
Occasionally the compiler gets more pedantic (defaults) which you typically can still switch to legacy behavior

java however includes a lot more than the compiler and you might face depreacted functions of whatever libraries you're using or when you try to compile glibc-oriented code against musl or so.

ReDress · 2025-03-26 16:53:20

Succulent of your garden wrote:

TY for the video schard.
Also since ReDress made the coding style issue, made me wonder: It's a good practice to change your legacy c++ code to a newer version ? ,

It's best to refer to them as language specific best practices otherwise it might give someone the wrong impression and they might think you're referring to the code layout on a file ;-)

Succulent of your garden · 2025-03-27 15:54:58

thanks both for the replies

EBADFD · 2025-03-31 13:45:07

Make sure you're compiling with "-fsanitize=address,undefined", this will catch plenty of mistakes and memory leaks

Succulent of your garden · 2025-03-31 21:26:04

EBADFD wrote:

Make sure you're compiling with "-fsanitize=address,undefined", this will catch plenty of mistakes and memory leaks

Thank you so much for you feedback

Arch Linux

#1 2025-03-18 23:04:48

[SOLVED] c++ recommended practices for a noob

#2 2025-03-19 07:08:24

Re: [SOLVED] c++ recommended practices for a noob

#3 2025-03-19 08:39:17

Re: [SOLVED] c++ recommended practices for a noob

#4 2025-03-19 09:40:47

Re: [SOLVED] c++ recommended practices for a noob

#5 2025-03-21 08:32:28

Re: [SOLVED] c++ recommended practices for a noob

#6 2025-03-21 14:52:23

Re: [SOLVED] c++ recommended practices for a noob

#7 2025-03-21 16:32:20

Re: [SOLVED] c++ recommended practices for a noob

#8 2025-03-21 21:24:32

Re: [SOLVED] c++ recommended practices for a noob

#9 2025-03-23 21:24:43

Re: [SOLVED] c++ recommended practices for a noob

#10 2025-03-24 10:48:30

Re: [SOLVED] c++ recommended practices for a noob

#11 2025-03-24 11:11:25

Re: [SOLVED] c++ recommended practices for a noob

#12 2025-03-25 21:58:49

Re: [SOLVED] c++ recommended practices for a noob

#13 2025-03-26 09:10:15

Re: [SOLVED] c++ recommended practices for a noob

#14 2025-03-26 10:09:49

Re: [SOLVED] c++ recommended practices for a noob

#15 2025-03-26 12:34:08

Re: [SOLVED] c++ recommended practices for a noob

#16 2025-03-26 12:42:06

Re: [SOLVED] c++ recommended practices for a noob

#17 2025-03-26 16:53:20

Re: [SOLVED] c++ recommended practices for a noob

#18 2025-03-27 15:54:58

Re: [SOLVED] c++ recommended practices for a noob

#19 2025-03-31 13:45:07

Re: [SOLVED] c++ recommended practices for a noob

#20 2025-03-31 21:26:04

Re: [SOLVED] c++ recommended practices for a noob

Board footer