It's a good idea to look through one of these books (Stroustrup, Meyers, Alexandrescu, Antony Williams) just to index the topics in your mind.
Then there's the standard library, worth playing with a few data structures to get used to it. Possibly Boost as well though IMO a lot of the good stuff went into the STL.
If you came from either of these languages and read a c++ file, you'd eventually wonder why there's this extra keyword in the inheritance specifier.
Does it really matter a whole lot? Probably not. Luckily you will find the answer quite quickly if you search for it.
Regardless of conference topic, this is how it usually goes: the first talk in the morning is fine, the second one is a mindnumbing one-hour walkthrough of a really complicated way to do something obvious, and by lunchtime I'll rather escape for good than eat lukewarm sandwiches while listening to small talk of how someone's [IoT blockchain startup / enterprise logistics dev team / college course] is amazing because of [conference topic].
1. Optional "workshop" add-on day, preceding the main conference. Basically a guided tour through writing a Hello World app in Spring Boot, or React, or whatever framework is hot that year.
2. The main conference. Two days of hour-long sessions, with speakers consisting of:
(a) consultants trying to promote their firms,
(b) "evangelists" trying to promote their company's products, or
(c) local devs who don't require travel expenses, and are just presenting a topic to pad their resumes.
Around 90% of the value I've received from technical conferences came from group 2(c), and I'm not sure that was enough to justify the whole.
What the author describes sounds more like "a training class", which is a different animal. Even then, I've never seen a training course longer than 5 days.
PyCon is the longest conference event that I've encountered, but that involves pre-conference workshops and sprints after the conference. It is great to be able to immerse yourself in the community, but it can be tiring by the end.
The conference I’ve attended most is Siggraph which is one of the larger conferences the ACM has, and it lasts 5 days. There are several well known co-located “pre-conferences”, both of the educational/training variety as well as pure academic.
I get a lot of value out of Siggraph’s content, and almost none from local devs. So, I guess my experience is much more like the article author’s and not much like yours.
Cppcon isn’t really a training class per-se, though, maybe you skimmed and accidentally mixed together what the author said about the conference and the pre-conference class? They’re two different things, FWIW.
When going to a conference you should be thinking "what is that one thing". There are many different ways to get it: then keynote, the talks, hallway conversations, the vender exhibits, the dinner conversations with strangers. You never know what it will be in advance.
Ones like Strangeloop out in St. Louis offer an incredible diversity of talks, topics, and forums offered: from language deep dives and workshops to architecture talks to rather arcane talks about modifying an automatic sewing machine to print jpegs onto sweaters and more casual forums on topics like validating resilience and durability guarantees of different datastores.
Ones like Google's series on GCP are exactly as you described though.
The Rust compiler will teach you concepts you need to understand to be an effective C++ developer, like moves versus copies, working with type variables, working with smart pointers, etc.
You could learn these things in C++, but it will be much harder. The Rust compiler error messages are much nicer, and certain features like type variables are at a higher level of integration than equivalent features in C++ like templates. The borrow checker will also teach you how to write hygienic C++ which is something that will take you years to master on your own.
Lastly, Rust's tooling will keep you focused on learning the language rather than fiddling with C++ build systems.
Also I recommend looking into F#, Haskell and Clojure.
And honestly it is not because C / C++ is hard to learn. They just didn't age well. C++ is full of anti patterns, the build system (makefile) is absolutely horrendous (yeah i know about cmake, dont tell me - tell the manufacturer/vendor), the compiler is your worst enemy (gcc errors are useless), testing isn't as widespread as I see it in webdev.
Code Quality is not a concern. I found myself often times looking for the documentation in the source code. And truth be told i rarely find someone advocating against it. IDE support before CLion is laughable compared to IDEA. There was just VS that was nearly as good, but not a option for me as a Linux User.
I had a discussion with someone on a Embedded Meetup and this guy trashed JS because it isn't type safe. I tell you something C/C++ is NOT type safe. You can't trust the type you would expect. NEVER. That is actually a big problem in some use cases.
I am now in a state where I would say that I have a lot of experience in embedded. It took a lot of time and frustration. But I really envy the people that put so much effort into teaching and putting so much content to improve and learn more about webdev. I am aware of the fact that some people are programming trash in JS too. The thing is they didn't need to. It is so easy to find good resources advocating good patterns for programming.
I have read on Rust for embedded and the work that some people put into it gives me hope. I really really wish for C/C++ to vanish in its current state. It is not friendly to newcomers and surely that is not because they re too stupid.
And if I can recommend you some books (for embedded C/C++):
9781788830287 Embedded Systems Architecture (Good Introduction)
9788131521267 Data Structures and Algorithms in C++ (That actually helped me a lot with persisting state in memory, some cool tricks)
EDIT: added some newlines
So, you know, your experience may vary.
I think you really need to differentiate between C, C++ before C++11 and modern C++ (i.e. C++11/14/17 and newer).
I actually switched some time ago from C to C++ only - when possible. And about the features of modern C++ standards: On embedded you can't use STD or excessively use templates.
Some features will crash because of the Memory Protection Unit and are not usable when using the MPU.
I believe there is a lot of room where we can improve and lower the barrier for entry.
For example better packaging system, better IDE support (CLion is already very good tbf), modernizing vendor api, improve documentation and testing solutions, compiler that actually throw meaningful errors and of course good learning material...
I know it is a lot to ask and I don't want to sound like a ungrateful child. There are a lot of people working their asses off for free and all that. But i think it is not wrong to point some of the problems we have.
You can also generate Ninja files btw.
Becomes very easy as soon as you're up to date.
On another note, besides C legacy (memcpy, printf, malloc, etc.), could you point me towards something that is not type safe in C++ (preferably post C++11)? I find the argument a little bit disingenuous after claiming rust is type safe (you can do the same kind of non type safe magic with the unsafe keyword).
The idea that you were misusing the word was more appealing than the truth that you knew what it meant.
So I think some people are forgetting that I work and talk only about embedded development C/C++.
Generally what i mean with you can't trust the data is that memory can get corrupted in embedded very easily. There are some mechanisms to prevent it (MPU for example). The other thing that I see often is the usage of opaque pointer by vendors. That is not necessarily a problem with C++ but you will have to use it and deal with it.
But yeah you re right about modern C++ features being more type safe. I would love to use them but the problem is many of those std features are not usable in embedded or are not worth the cost.
I agree with the parent on this point (although make is not _the_ C/C++ build system) - makefiles are horrible. Make is arcane, full of quirks that bite you as a beginner, and suffers hugely from being not-portable (gnu make is not the same as other flavours, and make on windows is practically non-existent)
> could you point me towards something that is not type safe in C++
Not the parent but  is a reasonable example.
A better example of breaking type safety would be to involve a reinterpret_cast or a C-style cast, or maybe pass something through a void*.
You can created tagged structs, but you inevitably end up needing to extract the value underneath.
Regarding casts and void pointers, I think they're a slightly less dangerous case. My Spidey senses tingles whenever I need casts - static (or to a certain extent dynamic) casts are normally ok, but a reinterpret cast or a void* parameter is going to warrant a discussion and explanation in a code review.
We definitely agree here. Better would be to use a library such as Boost Units, rather than naked aliases.
void* is definitely problematic, and I kill it every chance I get, but it persists in a lot of code due to C libs and unfortunate legacy dependencies.
> Better would be to use a library such as Boost Units, rather than naked aliases.
> void* is definitely problematic, and I kill it every chance I get, but it persists in a lot of code due to C libs and unfortunate legacy dependencies.
I've not seen it (thankfully) in anything other than actual C code or graphics code, but whenever I do see it, I make a mental note of "here be dragons" and make sure to take extra care around there... It's not ideal but it's life..
Rust is probably the most type safe language I’ve ever used, granted it’s not many, but definitely between Java, C, C++, JS, Python, Lisp, etc. If you put Rust in the same category because it has unsafe, you might as well just throw your hands up and say that no language, not a one is typesafe, with the exception of possibly Assembly, which practically treats everything as just a series of bits.
There is a misconception that b/c Rust has unsafe it is proof that it is itself unsafe, but this devalues the entire point of having any form a safety in language.
The language is typesafe, memory safe, and datarace safe, so long as you keep the guardrails on. Sometimes you take the guardrails away for very special reasons, but those are generally rare (unless you’re working with FFI, hardware, or low level concurrency). I have entire codebases of multiple thousands of lines in Rust without the need to use unsafe at all.
How about typedef's in general, what problem BOOST_STRONG_TYPEDEF solves (and its limitations)?
Things like smart pointers, move semantics, lambdas, type inference are great additions and can save you from the footguns of the past. And that’s just C++11. The documentation and learning resources on the web have never been better, too.
The problem, as you point out, is on the embedded side, specifically vendor support. There doesn’t seem to be a solution to vendors who don’t give a shit. They scrape together an old build of g++, manage to barely get it to work, and call it a day. There’s probably some “disruption” opportunity here, and someone smarter than me will see it. I think Apple has actually set a great example of how it could/should work. Getting Hello World running on a production, end-user iPhone is 10x easier than getting it working with CrappyChineseVendor’s SuperDeluxe BSP and reference hardware, whose only purpose is to support software development. And Apple’s toolchain is reasonably up to date and gets yearly updates vs the other embedded toolchains which are 5 years old and never get touched post-sale. That should be totally unacceptable but we still hand our money over to these vendors.
Same here and I thought it were weird. Glad to see someone with the same experience.
You forgot to mention C/C++ package manager. There are approximately 74 different build systems and a patchwork framework of 28 various package managers, most of which only support a certain platform/environment and are useless outside of it.
I hope it does not end up like one of those "grass is greener on the other side"-thing :D
Nothing weird. Someone has to understand the end-to-end embedded-server-webui.
To start off I would use the create react app. It sets up a project and all the required settings for babel, linter and all that magic is behind a curtain. Again the documentation is fine for starting. And remember React is just the view library. If you need (global) state management look at redux or mobx, http client axios and read their documentation.
I started 3 years ago with React. Back then i just used the documentation. Now i follow Dan Abramov and other React Maintainer / developer (like Sophie Bits) on twitter and I learn a lot of internal or advanced stuff about react. I definitely would recommend following them.
There are lots of ways to connect to these APIs, but a common one with React is to a Redux middleware to do the fetching. Underneath everything, something will be using either the classic "XMLHttpRequest" or the newer "fetch api" to do the actual HTTP requests.
Also, often when C/C++ comes up, more often it is embedded, but when I learned C/C++ it was mostly os/game/dbengine etc.
Embedded sounds interesting but not sure where to start. A few pointers for beginner friendly resources would be appreciated!(will try to get my hands on the books mentioned)
Also, do you think if I start now, Rust is better?
That is actually not hard to do on an embedded system. Getting the ETH or WiFi Driver to work is another story. That depends on the vendor and "how many/much batteries are included". Some will make it very easy and offer an fully working API that you can use. But sometimes you need to get deeper for custom solutions and that's when you need to read into the documentation and internal API.
I would start with an Arduino for basic stuff like turning on LEDs. Learn about the PIN Levels or the need of pull down / push up wiring. Try to implement software debounce for input reading. All that basic stuff. Programming is done via their IDE. You get an UART Console (serial) for debugging / logging. I use it to this day for prototyping (last week CAN bus for example to read the OBD interface of my car). There are LOT of resources online for the arduino.
When you re done with it you can look at raspberry pi. There you can use linux (which is very elegant) to do some advanced stuff like networking. You can start with monitoring temperature and printing to the console. There are lot of libraries and documentation for it.
If you are still interested you can go a level deeper. Without an OS or an RTOS (like FreeRTOS). There you are pretty much on your own with a lot of things. I started with an STM32F4. You have an integrated Display on some models. And there is also a lot of tutorials and documentation. The stmcube software helps you setup your pin and board configuration.
If you use FreeRTOS: Try playing with tasks (context switching, priorities) or scheduler (cooperative vs preemptive). You can look at the examples provided in the repository (firmware packages) and run them on your board. Play with them, change or modify some parts.
About Rust I didn't try it. But currently i am not sure since the vendor of the board i am currently developing for provides only a API in C. You will either have to write in C or use C++ and write some sort of wrapper (https://www.oracle.com/technetwork/articles/servers-storage-...).
I'd like to try CLion with a hobby project and some esp32 modules, but there doesn't seem to be a standard, best practices way to do that.
But for my work project i am using compilation databases, which works great with sources that are included in your makefile. It gets a bit tedious recompiling but there is a way to automate this. Ah one thing that i noticed sources that are not included or libraries with your drivers and middlewares that you link against are not recognized and a warning will appear.
Eclipse was a bit smarter as it could resolve those dependencies.
What build system are you currently using ?
My goal is sensors to monitor conditions like soil moisture and temperature, and control pumps on a water catchment system for landscaping, and potentially fire safety control purposes.
If I extend the functionality to fire safety control, that might involve starting a generator, and being able to fallback to LoRaWAN to accept simple commands to run programs and send updates on conditions. During extended power outages in the past I've found that cell towers stop working within a day or so, while only a couple line-of-sight miles away all of the infrastructure is working perfectly fine.
Note that for every thousand square feet of roof area, you can collect about 10,000 gallons per year if you're in most parts of Silicon Valley (16" rain/year), or 20,000 if you're near Santa Rosa (30"). Part of the inspiration for water catchment was the price of water, and the inspiration for automation was seeing photos of swimming pools filled to the brim surrounded by complete fire devastation after the Tubbs fire in Santa Rosa.
So, by all means, people should learn the concepts from other languages. But then, they should also go deep into various areas. Knowing C++ well enough to write portable, efficient, maintainable code, and developing the habits so that's natural, is a good skill to have.
The moment my programming abilities changed was when I had to write a complex database.
One day I was doing some python job automation and decided I wanted to store the data in a database. I found sqlite existed, now I'm an addict.
ANSI had made the C++11 standard available for $40 several months after it was formally accepted by ISO.
I still use my copy of the C++11 standard time to time. Helpful for explaining why things work in a particular way and for answering "I think I found a compiler/stdlib bug, is my implementation conforming" questions.
Go home and do a C++ project.
Try turning on stuff with an arduino, then try making it useful.
Or try building a program for yourself.