5mo ago

The C++ learning process

Incase it doesn't show up:

120 comments

“Give it six months”
It only needed 3!

After you've done some languages, they all look the same. Yes, some have interesting features like the indent-based blocking of Python, and I'll have to look up if the new language has "else if", "elsif", "elif", or whatever, but als long as it is coming from the family of ALGOL-like languages, it does not matter much. You'll learn the basic functions needed to get around, and off you go.
Just a few weeks ago, I started learning Python. Yes, this indenting takes some time to get used to. My son does Python for about a year now - he started with it at university. Maybe ten days after I started learning, I invited him to have a look at my first Python program. I have no idea what he expected. A "Hello, World" with a few extra features, maybe? Definitely not the 2.5k lines app I had written in my spare time, with GUI, databases, harvesting data from a web site with caching, and creating PDF files with optimized layout for the data I processed. In the end, it was just another programming language.
- I guess you've never seen some of the 10-page template errors C++ compilers will generate. I don't think anything prepares you for that.
  
  I've seen way worse. Imagine a project that uses C preprocessor structures to make a C-compiler provide a kind-of C++. Macros that are pages long, and if you forget a single bracket anywhere, your ten pages look like a romance novel.
  Or VHDL synthesis messages. You've got no real control over them, 99.9% of the warnings are completely irrelevant, but one line in a 50k lines output could hint at a problem - if you only found it.
  So far, the output of C or C++ compilers (except for the above-mentioned project) has not been a problem or me, but I'm doing this for about 40 years now, so I've got a bit of experience.
  
  I've not had those while working with concurrent programs with c++ for over a year. Pointers, QT programming, non-qt backend programming, coding an engine to work with computer vision runners (openvino mostly), image management (more pointers)... Idk, this is gonna sound rude but just code better? Most of my errors were segfaults, I have had to plug the debugger and/or tons of prints and I made it work.
  If you want to see giant error logs, check pyspark errors. But even those have the relevant line of info and then all the rest of the garbage info that no one really needs, like any other language.
- Yeah this only really applies to Algol style imperative languages. Dependent types and say stack languages like idris and apl are dramatically different in their underlying axioms.
  
  Indeed. I have done languages like Prolog and Forth, too, and have actually written a bit in APL ages ago. Yes, they are different, but in the end, it just adds a little bit of complexity. The underlying algorithms are universal, just the methods and structures to achieve them differ. Actually, the first programming language I have written was a simplified Forth derivate - in 6510 Assembler.
- I didn't even know about the Python indentation thing until I was practically done learning it! I'm just used to copying whatever indentation scheme my coworkers are using, for consistency.
- Definitely not the 2.5k lines app
  MVC can be a great experience, especially with python dictionaries.
  
  Learning how to get models and views together took some time, but after the second refactoring that week I managed to have neat objects for each MVC with clean interfaces. My biggest source in the app defines a requester with three columns of lists: a global category, then parts from that category, and finally the available colors for that part. Each of those views is an object, their interacting logic is an object, and finally the actual requester is an object, and this makes thing easy to handle.
- I’m interested in specifically what your first program did?
  Like what data is it harvesting and how is it showing that in PDFs or should I say why?
  
  The software gets data from a website named bricklink.com, where one can buy and sell LEGO bricks and sets.
  The main view holds a list of bricks I've selected from the large range available. In a requester to add parts, I can select a certain brick from the list of existing bricks by first chosing a category (e.g. "Bricks") in the leftmost column, then chosing it's shape (e.g. "Brick 2x4") in the middle one, and then selecting the color (of the known existing colors for this brick, e.g. "Black") in the right column. On all three selections I can multi-select and sort, which allows me to select e.g. a number of different Bricks, then sort the last view by color, and multiselect those bricks in the color I need. OK'ing the requester add the part(s) to my list.
  The list that shows all the properties (including when this part was in production, how much a single brick of it weighs, as well as mold codes and article numbers). From there, I can choose some bricks (usually 15 in a go) to print, which produces a PDF with 15 labels on a double-sided A4-paper with cut-marks on one side. I cut them along the cut marks and put them into the bag with the coresponding part. This is quite helpful, if you consider a box with bags all containing e.g. black parts and bad lighting conditions in the storage room. Alternatively, I can print a double-sided paper with four larger cards to cut, which I laminate and use for marking boxes when I have larger amounts of one brick shape and color.
  I can (and do) export those bricks to an export folder as CSV once I've printed the labels. In a future version of the software, I will be able to take a bag or box of parts from my collection, select it in my software via it's article number, and derive an approximate count by weighing them (therefor the parts weight) to get an approximate inventory.

Jokes aside, I struggle more with abominations like JavaScript and even Python.
- Do you have a minute for our lord and savoir TypeScript?
  
  As long as it can distinguish between int and uint - yesss!
- Python has its quirks, but it’s much much cleaner than js or c++, not fair to drag it down with them imo
  
  I think the thing with C++ is they have tried to maintain backward compatibility from Day 1. You can take a C++ program from the 80s (or heck, even a straight up C program), and there's a good chance it will compile as-is, which is rather astonishing considering modern C++ feels like a different language.
  But I think this is what leads to a lot of the complexity as it stands? By contrast, I started Python in the Python 2 era, and when they switched to 3, I was like "Wow, did they just break hello world?" It's a different philosophy and has its trade-offs. By reinventing itself, it can get rid of the legacy cruft that never worked well or required hacky workarounds, but old code will not simply run under the new interpreter. You have to hope your migration tools are up to the task.
  
  The terse indexing and index manipulation gets a bit Perl-ish and write-only to me. But other than that I agree.

C is dangerous like your uncle who drinks and smokes. Y'wanna make a weedwhacker-powered skateboard? Bitchin'! Nail that fucker on there good, she'll be right. Get a bunch of C folks together and they'll avoid all the stupid easy ways to kill somebody, in service to building something properly dangerous. They'll raise the stakes from "accident" to "disaster." Whether or not it works, it's gonna blow people away.
C++ is dangerous like a quiet librarian who knows exactly which forbidden tomes you're looking for. He and his... associates... will gladly share all the dark magic you know how to ask about. They'll assure you, oh no no no, the power cosmic would never turn someone inside-out, without sufficient warning. They don't question why a loving god would allow the powers you crave. They will show you which runes to carve, and then, they will hand you the knife.

This is so believable. You copy a few examples out of a textbook using cout and cin and it seems reasonably inline with other languages.

A friend of mine whose research group works on high throughout X-ray Crystallography had to learn C++ for his work, and he says that it was like "wrangling an unhappy horse".
- I'm not sure how I feel about someone controlling an X-ray machine with C++ when they haven't used the language before... At least it's not for use on humans.
  
  https://en.m.wikipedia.org/wiki/Therac-25
  
  He doesn't directly control anything with C++ — it's just the data processing. The gist of X-ray Crystallography is that we can shoot some X-rays at a crystallised protein, that will scatter the X-rays due to diffraction, then we can take the diffraction pattern formed and do some mathemagic to figure out the electron density of the crystallised protein and from there, work out the protein's structure
  
  C++ helps with the mathemagic part of that, especially because by "high throughput", I mean that the research facility has a particle accelerator that's over 1km long, which cost multiple billions because it can shoot super bright X-rays at a rate of up to 27,000 per second. It's the kind of place that's used by many research groups, and you have to apply for "beam time". The sample is piped in front of the beam and the result is thousands of diffraction patterns that need to be matched to particular crystals. That's where the challenge comes in.
  I am probably explaining this badly because it's pretty cutting edge stuff that's adjacent to what I know, but I know some of the software used is called CrystFEL. My understanding is that learning C++ was necessary for extending or modifying existing software tools, and for troubleshooting anomalous results.
- Probably makes 7 figures working for big pharma though
  
  Unfortunately no. I don't know any research scientists who even make 6 figures. You're lucky to break even 50k if you're in academia. Working in industry gets you better pay, but not by too much. This is true even in big pharma, at least on the biochemical/biomedical research front. Perhaps non-research roles are where the big bucks are.

Last time I did anything on the job with C++ was about 8 years ago. Here's what I learned. It may still be relevant.
C++14 was alright, but still wasn't everything you need. The language has improved a lot since, so take this with a grain of salt. We had to use Boost to really make the most of things and avoid stupid memory management problems through use of smart (ref-counted) pointers. The overhead was worth it.
C++ relies heavily on idioms for good code quality that can only be learned from a book and/or the community. "RAII" is a good example here. The language itself is simply too flexible and low-level to force that kind of behavior on you. To make matters worse, idiomatic practices wind up adding substantial weight to manual code review, since there's no other way to enforce them or check for their absence.
I wound up writing a post-processor to make sense of template errors since it had a habit of completely exploding any template use to the fullest possible expression expansion; it was like typedefs didn't exist. My tool replaced common patterns with expressions that more closely resembled our sourcecode¹. This helped a lot with understanding what was actually going wrong. At the same time, it was ridiculous that was even necessary.
A team style guide is a hard must with C++. The language spec is so mindbogglingly huge that no two "C++ programmers" possess the same experience with the language. Yes, their skillsets will overlap, but the non-overlapping areas can be quite large and have profound ramifications on coding preferences. This is why my team got into serious disagreements with style and approach without one: there was no tie-breaker to end disagreement. We eventually adopted one after a lot of lost effort and hurt feelings.
Coding C++ is less like having a conversation with the target CPU and more like a conversation with the compiler. Templates, const, constexpr, inline, volatile, are all about steering the compiler to generate the code you want. As a consequence, you spend a lot more of your time troubleshooting code generation and compilation errors than with other languages.
At some point you will need valgrind or at least a really good IDE that's dialed in for your process and target platform. Letting the rest of the team get away without these tools will negatively impact the team's ability to fix serious problems.
C++ assumes that CPU performance and memory management are your biggest problems. You absolutely have to be aware of stack allocation, heap allocation, copies, copy-free, references, pointers, and v-tables, which are needed to navigate the nuances of code generation and how it impacts run-time and memory.
Multithreading in C++14 was made approachable through Boost and some primitives built on top of pthreads. Deadlocks and races were a programmer problem; the language has nothing to help you here. My recommendation: take a page from Go's book. Use a really good threadsafe mutable queue, copy (no references/pointers) everything into it, and use it for moving mutable state between threads until performance benchmarks tell you to do otherwise.
Test-driven design and DevOps best-practice is needed to make any C++ project of scale manageable. I cannot stress this enough. Use every automated quality gate you can to catch errors before live/integration testing, as using valgrind and other in-situ tools can be painful (if not impossible).
1 - I borrowed this idea from working on J2EE apps, of all places, where stack traces get so huge/deep that there are plugins designed to filter out method calls (sometimes, entire libraries) that are just noise. The idea of post-processing errors just kind of stuck after that - it's just more data, after all.

Reminds me of the joke about the guy falling from the top of the Empire State Building who, half way down, was heard saying: "Well, so far, so good"
- Reminds me of the start of La Haine.
  https://youtu.be/4rD05HsmtIU
  
  I suspect indirectly both variants come from the same source or maybe even it's the La Haine that's indirectly the source for my variant (though I learned this joke a long time ago, possibly before 1995).
  By the way, that's excellent film intro.

In my country C++ is taught as a base language along with Scratch(not a language, but yk what I mean). I recently started learning Kotlin with Jetpack Compose (the only sane way to learn Kotlin) and I realized I wasted two years of my life learning C++, with 5 more to come as it is mandatory in ICT classes.... :((
- Which programming language would you like to teach if you were a teacher? P.D I also learned C++ as my first language
  
  Idk about other people but just learning c is so logical. You do stupid shit, you get stupid results. Of course there are a lot of bad things with c but at least when you sit down to understand how it works, it works while most oop languages are so detached from the hardware its hard to understand anything. It might be just me but oop breaks my brain. Also ive never coded in c++ but i automatically avoided it. I heard rust has very minimal oop and its just to make things smoother so i may try that.
  
  C++ was my second programming language after BASIC, if that still qualifies as a programming language these days.
  
  I'm not a teacher, and I don't want to become one tbh.
  That said, something like Python is standard, and for good reason IMO. For OOP they usually teach Java here, though I'm not a huge fan. I think Kotlin would be better to teach nowadays. There are other OO languages of course, but I'm of the opinion that after messing around with Python, students should probably use something strongly typed, so that's JavaScript out - I suppose TypeScript could be used, but IMO it'd be best to keep JS/TS in a web dev specific course.
- In hungary its python and c++ in the curriculum but on the tests you can usually choose between a few languages.

I learned c from a book from the 80s and then skipped to rust.
The only time I touched c++ was modding games in the early aughts and to try it for a couple coding challenges. I've heard templates are a thing of note when it comes to complications but not sure.
As for c# ... We don't talk about that (jk. I had to do it for one or two projects and played with unity a bit ages ago)
- Honestly C# has grown on me quite a bit. Shakes off some of the bloat of Java and linq is pretty handy. God knows if I can't tell you what the distinction is between C# and .NET Core and whatever the hell ASP is.
  
  C# = Java (the language itself)
  .NET (Core) = Oracle JDK (a runtime and std lib implementation for the language)
  ASP.NET = Spring boot (the default web framework)

I started to learn C++ once, had semester and couldn't wrap my head around the object oriented part. At some point I looked at learning objective C on my own, though I didn't really use it. I had a 1000x better understanding after an hour.
- I learned it while at the same time learning (or really enhancing my previous knowledge of) javascript, thanks to an insane mostly-Finnish app development platform known as Qt Creator, which for no rational reason uses C++ for the under-hood-stuff and javascript for the UI front end. Just an absolutely horrible mismatch of mental states. For bonus points, the company that I worked for that used this monstrosity for its suite of apps got purchased by a huge west coast company and the apps were shut down and everybody was fired, after two years of my working on this shit.
- Something like ruby is a pretty quick way to get up and running with something easy and object-oriented. Groovy if you already have a jvm running (though ruby might be easier depending upon your background)

I actually just started learning C++ today.
If Lovecraft were alive today one of his stories would start with this line.

Instructions unclear, attempted to learn JS

We used C++ based software. Who need sanity ? Clearly overrated

The image doesn't open for me. But I guess the joke still works in a way.

Unfortunately, those of us that make games in Unreal Engine are stuck writing a lot of C++, unless we want to do everything in BPs (no thanks, they're fine, but it's not coding, and it's difficult to maintain and refactor for complicated projects, they're good for taking C++ components and building bigger components out of the base C++ functionality though).
With that said, UE's support for C++ is decent. Which is, that as long as you tag all your fields, properties, methods, classes, etc. with some UnrealEngine attribute filter (like UCLASS or UPROPERTY), Unreal will handle the memory management of those constructs for you. Which is nice.
Unfortunately it has some other limitations to the C++ language that you can't work around, like disallowing pure abstracts because every C++ derivative class based on any UE construct (Actor, Character, Pawn, etc.) has to be instantiatable in the editor. So no pure abstracts and such.
In general, I'd give it a 6/10.
It's still mostly C++, but some of the things suck less.

Sums up my experience with C++. It's fun until you actually start using it and then you get hit with: Idiotic syntax, no package management, C compilers, different operating systems, compiling in general, having to code everything from scratch, memory management and a lot more...
Shit hit me so hard, I began learning web dev instead and never looked back...

They are still using Reddit, so one has to wonder if they have not abandoned sanity and intellect a long time ago.

120 comments