171–180 of 221 posts
How many interesting SE jobs use C++ anymore? Is anyone using it for new projects?
I'm currently doing some backend work, and I really miss it. I don't think I've done anything interesting algorithm-wise since I switched. Alas, the pay is usually much better in SaaS land.
Is there a good guide on the toolchain? What do people use today to keep sane? Something like meson, ninja or cmake? I have inherited some project in scons that was generating msvc 14.1 project and I can heartily recommend against that
I think nowadays smart pointers should not be considered an "advanced topic" in C++. Smart pointers are usually the best way to handle memory management. It's definitely useful to learn about "new" and "delete", because those are the primitives that memory management is built on top of. But it should be followed up with good advice like, rarely use these in practice. You should almost always be using unique_ptr or sh…
I really wish there was a thread unsafe version of shared pointers, without atomics overhead, in the standard. Maybe without weak pointers.
This course is a bunch of presentation slides. The idea that you can learn anything from slides is rather silly. Learning from slides is almost as bad as learning from random youtube videos.
Earlier quoted context omitted.
I find it absurd that a programming language which compells someone to set up a containerized OS just to manage their build toolchain could be considered "modern".
I install Rust's toolchain and development tools inside of a container, I also do this with Python and will do it with C++ sometime in the future. I don't do this because I have to, I do this because I prefer to keep non-system -critical software managed by non-root users and separated from the systems rootfs. On your common desktop Linux distro, I think C and C++ toolchains are the least difficult to setup and use w…
In my experience, the hard part is rigorously controlling the libraries a build uses. Using CMake, it's easy enough to add libraries to a build, but harder to stop the thing going off and looking round /usr/lib64 and so on. On my physical workstation, there is all sorts of stuff in there, because i have a desktop environment and a cornucopia of tools installed. I don't want a build using any of it! If a build needs a library which i have not explicitly added, i want it to fail, not use something from the system. But between default paths and rpaths in libraries and so on, that seems hard to do in a watertight way. I've done endless fiddling with sysroot flags, but i'm not sure it's not leaking. A container takes care of all that in a very definite way.
Any ideas where to start learning C++ as an embedded developer? I wrote many lines of bare metal C code and want to transit to higher level jobs. I see many expensive or completely free courses, but I am not sure which one is usable in my complicated situation.
It depends on what you target. I do alot of Kernel and really low level C++, and it's a completely different style than even app dev, so you have to be sure you don't go down the completely wrong route. For my target space, there's a few rules for c++. Footguns: A. No STL, it causes to much bloat when binary size is critical. B. (almost) No inheritance or virtual functions. Again, it causes some bloat and adds in som…
I also think you are a bit harsh on virtual functions - it introduces a single indirection, yes, but sometimes that is fully justified. RTTI on the other hand... of course depends a bit on target characteristics.
Perhaps controversial, I've also found (especially bare) lambdas and even std::function objects useful, although may evolve into something purely static when the dust settled. Highly dependent on target of course.
It will be interesting to see the final form of the new MISRA std, since the active one predates all of this.
Earlier quoted context omitted.
Genuinely asking: Why many programmers need tools to enforce something upon them? Why not they can't take slow, be mindful about what they write and add a couple of layers as pre-commit hooks? Like a code formatter and maybe a linter? This makes me sad. Programmers have the knowledge base to make some of the most sophisticated things bend to their will, and they tell a programming language is bad, because they can ma…
The biggest problem with C++ isn't that you can't write clean, structured code with it. It's that the language is so vast that the odds of any two developers working on two different projects agreeing on what that means are low. I programmed in C++ for a decade, then for a year or two at a second place, then picked it up again in a third... And all three places had nearly completely different best practice protocols.…
This course is a bunch of presentation slides. The idea that you can learn anything from slides is rather silly. Learning from slides is almost as bad as learning from random youtube videos.
Slides can be an extremely good medium for learning. Because brevity is required by the format, slides can require a lot more thoughtful attention to emphasize and carefully explain key points than the long-form text format. I think the course looks really nice!
There are at least a dozen C++ intros that go through every little detail like this and I don't get it. I have a pretty good ability to retain a lot of information presented this way, and I've been programming in various C-like languages for long enough that much of this isn't new to me, but this doesn't seem like a good way to learn the material. I'd much rather work through actual programs and iterate on them. I im…
I think C++ and Rust are honestly special beasts. I've heard experienced programmers say that you want to actually pick up a book to learn Rust, and the same is true for C++. Like you can basically hack your way through learning Python or JS. I didn't learn Python from a book, for sure. But with C++ and Rust that's not an optimal strategy. You have to do both -- do practical projects, and actually study it a bit. The…
Earlier quoted context omitted.
It depends on what you target. I do alot of Kernel and really low level C++, and it's a completely different style than even app dev, so you have to be sure you don't go down the completely wrong route. For my target space, there's a few rules for c++. Footguns: A. No STL, it causes to much bloat when binary size is critical. B. (almost) No inheritance or virtual functions. Again, it causes some bloat and adds in som…
I think you missed exceptions often being a problem in low level and embedded targets. That knocks out most of STL anyway. I also think you are a bit harsh on virtual functions - it introduces a single indirection, yes, but sometimes that is fully justified. RTTI on the other hand... of course depends a bit on target characteristics. Perhaps controversial, I've also found (especially bare) lambdas and even std::funct…