I've had great success using ChatGPTv4 to help me write modern C++ that works with CUDA, using prompts like these. (I have not attempted to get it to write parallelized code given loops/serial code as an input):

> Please convert this Rust code to modern C++, compatible with the latest version of the nvcc CUDA compiler: ```rust ```

It will output a compilable/working result, and explain each of the language differences in question. It will make sure to use `std::*` instead of the more rigid C-derived equivalents when able, and take advantage of looping over array pointers etc, vice i++ loops. `auto` var types etc.

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 some instructions and code to support these features that can cause issues in low level environments.

Things to learn (All work in the kernel):

A. Learn templates, especially c++20. Templates add ZERO bloat, they literally just generate the function again with proper types the same way a macro would.

B. Use RAII.

C. Use constructors and overloading.

D. Zero pointers should be exposed to code except where absolutely needed. If you need to pass by reference, use the c++ style.

E. All allocations should be wrapped in a class with RAII. You can overload the operators on the class to make it seem like a pointer so you can still do if(!RAIIPointer).

A good video on kernel c++ is here https://www.youtube.com/watch?v=AsSMKL5vaXw . You can use a surprising amount of C++ language features in the kernel and it makes it extremely smooth and safe if you do it properly.

You can do some nifty stuff like generate CRC lookup tables at compile time without hardcoding them.

> A. Learn templates, especially c++20. Templates add ZERO bloat, they literally just generate the function again with proper types

"Avoid STL due to bloat but embrace templates" doesn't make sense to me. Isn't that exactly what code bloat is? Too much code generation?

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.

std::vector

std::list

std::map

std::unordered_map

std::set

std::unordered_set

std::sort

std::transform

std::merge

std::string

std::regex

std::swap

std::function

std::stable_partition

But there are much more than that in STL.

If you want to write bare metal C++ then this page from the above tutorial will be useful https://www.avabodh.com/cxxin/nostdlib.html

    > This open-access course is directed at those who are already familiar with C 
    > and object-oriented programming towards a proficiency level of C++ 
    > programming.

I agree with Kate Gregory that this is a bad way to teach C++ from scratch. That is, if you know only say, Python or Java (or nothing) and want to learn C++, you should not begin by learning C. Kate's approach skips many of the things you can do in C++ but you shouldn't, whereas if we try to start with C you're going to see that a lot, because "they were legal in C" is why they're allowed in C++ even though they're a bad idea and then you have to unlearn things. You're maybe expecting some of that if you've years of C programming experience, but there's no need to introduce an idea on Monday only to tell students on Tuesday that it's a bad idea and they must never do that.

The most insidious cases are where something is legal and correct in C but it's wrong in C++ yet it will compile and you maybe have broken software. There are some nasty type punning examples, where the pun was an idiomatic C expression which does exactly what you wanted, but in C++ that's Undefined Behaviour and all bets are off. You'd just never teach those type puns in a pure C++ course, they're never the Right Thing™.

I always look askance at folks who say they know C++ but not C. The C++ abstract machine is built over the C abstract machine and it becomes even more clearer when you go down to the binary level.

Understanding C idioms, the standard library, best practices, and general C software architecture , is less important if not downright negative early in your formation. You will end up picking a lot up anyway if you stick to C++ long enough.

"Less important" maybe but not "negative".

You have to have a decent C base (not necessarily expert level with knowledge of dark corners/tricky idioms/etc.) before you start with C++. One example is being comfortable with raw pointers. I often see "Modern C++" proponents say you should never use (and by inference learn) raw pointers which is absolutely counter-productive. It is also easier to learn C++ as a "better C" in the beginning else it becomes overwhelming. I believe this is the main reason most beginning C++ programmers find the language "scary/difficult/huge/overwhelming/confusing". They are trying to learn everything at the same time which is an impossibility with a language as baroque as C++.

I definitely think Bjarne Stroustrup's book about his own language isn't very good, even in later editions (which correspond to a more modern language) and so I would avoid buying that, I'm not sure it's a good defence of the language as an idea and I'm sure it isn't an effective tutorial, even if not for being out-of-date.

There are resources oriented toward embedded C++ that address these (at least memory allocation.)

On a project a couple years ago I was pushing to use C++ instead of C, if only as a "C compiled using the C++ compiler" for better type checking. I could not convince the project lead, who's technical depth far exceeded mine, that the C++ compiler was as likely as the C compiler to produce correct translations.

2) Software Architecture with C++ by Adrian Ostrowski and Piotr Gaczkowski. - Gives the overall picture of how to use C++ plus relevant modern tools as a complete development system.

3) The C++ Programming Language by Bjarne Stroustrup. - The bible/reference with programming techniques for the language.

Learning C++ is not difficult and don't let the size of the language intimidate you. Survey the different ways of programming in C++ i.e. Imperative/Object-Oriented/Generic/Meta-programming and use them as needed in your project without trying to master everything; that will only happen over time as you gain more experience.

Note for those who are not used to C++Now talks: they are intented to be a bit more informal with regular interjections from the audience (who at C++Now are also often heavily involved in the development of the C++ standard), so don't think people are being rude by jumping in!

Should "modern" C++ even use new/delete? I'm a C++ n00b, but I thought these can be avoided entirely now.

I also note a number of the possibly-ambiguous c-style casts in examples, despite already having mentioned the explicit versions (static_cast and the like).

Plus there seems to be a fair bit of system & machine dependent stuff mentioned like it's /always/ true - like stack being at a "higher" address space than the heap and code sections, or the stack growing down. It also says that the Data section is "slower" than the stack which... isn't true? If they're spilled out of registers, they're likely functionally identical? Or at least for small microbenchmarks depend on specific implementation details, like how the pointer to the object is calculated and dereferenced.... And object size and cache interactions... And a million other things...

And that's just the first few chapters I looked at :P

In my experience, every useful C++ application requires wrangling some historic smart pointers implementation: Boost, Unreal, libwebrtc, Qt.

Even NVIDIA uses its own smart pointers (thrust::device_ptr) though that's understandable. Also there's stuff like this: https://stackoverflow.com/questions/65938991/how-to-use-lamb... for e.g. TensorRT.

It's still useful to learn about the concept when dealing with old code.

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 shared_ptr instead of new'ing up pointers that you intend to explicitly delete later.

I really wish there was a thread unsafe version of shared pointers, without atomics overhead, in the standard. Maybe without weak pointers.

What exactly would you use these for? I find that usually I can get away with unique_ptr for the sort of object that I have many of where pointer performance matters.

https://cdm.link/2021/11/watch-larry-cuba-explain-how-he-ani...

    Implicit type conversion rules, applied in order, before any operation: ⊗: any operation (*, +, /, -, %, etc.)
    (A) Floating point promotion
    floating type ⊗ integer type → floating type
    (B) Implicit integer promotion
    small integral type := any signed/unsigned integral type smaller than int small integral type ⊗ small integral type → int
    (C) Size promotion
    small type ⊗ large type → large type
    (D) Sign promotion 
    signed type ⊗ unsigned type → unsigned type

Either way the C++ dependency management situation even makes the Python dependency management situation look good by comparison.

Is there a better way than “script the compilation of all dependencies and share the result” for any big project that has to support Windows? I’m interested in alternatives.

Basically I'd prefer to have a docker image with tooling that I can hook into.

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 without a container though (for me). On Gentoo I can just emerge gcc or clang and enable whatever USE flags I want, and they are installed and updated automatically with the rest of my system.

I use the Gentoo system package manager to manage my Rust toolchain as well instead of using rustup, so that it behaves like described above, it's updated and managed automatically and with the rest of my system!

I do realize that many distros have issues with software being out of date though, and that is a big problem! With Gentoo I can install multiple versions of most things in parallel and can very easily package anything that doesn't exist yet.

Also to clarify, I use the system package manager to build and manage my containers, this is how I use the system package manager to manage Rust's toolchain but also have it inside of a container. All of my containers are just nested Gentoos that I can install stuff into with the system package manager. I can also install a package manager into the nested Gentoo and build/install stuff while "inside" of it.

The thing is, you don't need to do this with Rust as far as I can tell. There may be some benefits, but ultimately your project can easily specify its own compiler version, its own target directory (the default is per-project), etc. There are some shared resources like caches, which you can split if you want to.

I can see why you'd still do this - but, the main reason would be... if you have dependencies on C/C++.

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.

It is surprising how many people look surprised (that also claim they know the language) when you tell them that code in .cpp does not get inlined into other .cpp files no matter what doing compilation. (yes the linker can (and should) do that with LTO doing linking)

The linker doesn't inline anything, LTO/LTCG is about running (part of) the compile process at link time. But that's really no concern for the C++ code but an implementation detail of the toolchain - you could just as well not have a separate link step and instead have the compiler process all compilation units in one step.

I get that it is just an implementation detail, but so are many things in C++ and you usually care about these things otherwise you would not be using the language in the first place.

Many projects also disable exceptions that is also an 'implementation detail' (or at least something that is definitely not required by the standard I would imagine), but now you are technically not writing C++ anymore.

I guess this is also one important thing when learning C++. The community is very fragmented, and there seems to be disconnect between C++ users and committee.

Having spent the better part of the last decade writing go though, I think C++'s syntax is a bit too cluttered.

"Every second spent trying to understand the language is one not spent understanding the problem"

Did a lot of work in LaTeX the last few years and they make C++ looks like something made in heaven

(You might have to jump through some links)

Also, fancy seeing someone else from RuG here :)

> Modern C++ Programming Course (C++11/14/17/20)

Kinda average in game development and sadly pretty low in embedded systems.

All way less common than your average Python position, but probably way more interesting.

I've always heard that they're currently mostly using C++ (and sometimes Java). But I'm not sure how dogmatic or change-averse they are on average.

C++ is here to stay for a very long time.

Memory safety is absolutely important in certain kinds of games. At least, as a player, I want games to not be exploited for cheats, and I don't want progress lost when a game crashes due to memory issues.

All that said, I would agree that if you want a job in games, learning C++ is a better idea than Rust right now.

     pdftk *.pdf cat output Modern_Cpp_Programming.pdf

Is anyone using it for new projects?

In fact the question should be: what interesting projects don't use C++?

For some very subjective definition of intersecting of course.

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.

LOL, yeah I think we can stop spending time on this (which was quite funny back in the day).

I am not saying that this isn't important, but learning about pointers and references is totally useless unless someone shows you why you would use them, where you would use them etc.

https://www.youtube.com/watch?v=YnWhqhNdYyk

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.

There's also a huge amount of disagreement about C++, so I think it makes sense to start with a codebase you want to work on, and then ask the people who WROTE that codebase what C++ books and learning materials they like.

e.g. Game C++ is kind of different than Google C++, but both are good (they get work done, and multiple people can work together in that style). There is a lot of really bad C++ out there. The gulf between good and bad C++ is bigger than good and bad Python or JS. You want to learn from experienced people who get things done, not language lawyers

or pascal.

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 make mistakes with it. You can cut yourself while chopping onions, too, if you're not careful.

When I code C++, I generally select the structures/patterns I gonna use, use them, and refactor my code regularly to polish it. Nobody enforces this on me, but this is how I operate. I add a formatter to catch/fix the parts I botched on the formatting department, and regularly pass my code through valgrind to see whether it makes anything funny on the memory department.

In the end it boils down to: Let the computer do what a computer does and do the things a computer can't.

Doesn't say, one shouldn't think, but computers are there and are powerful, so use it. If the checker doesn't find anything: great. If it does: good it's there.

That's why Rust say, has an escape hatch. Unsafe Rust wouldn't exist if all you could write in it were mistakes. Async Rust is to put it plainly, a pain in the ass.

These high level tools are more like chemotherapy. You hope that they kill more of the bad code before they kill you. They're not sophisticated, and it's fairly reasonable to prefer a language that let's you opt-in to stricter safety rather than opt out.

Why would I want to? Most of that is boring stuff that's hard to get consistently right and highly amenable to automation. Automation is what the computer is good at, it can have that job.

Like, why would I want to spend more mental bandwidth on tracking down whether every new goes with every delete than strictly necessary? Yeah, once in a while something is highly performance sensitive and it pays to design it just right for the use case. But it still tends to be surrounded with hundreds of other things that will do just fine with a smart pointer.

Pre-commit hook is automation. It formats the code and gives you linting notes the moment you write "git commit".

> Like, why would I want to spend more mental bandwidth on tracking down whether every new goes with every delete than strictly necessary?

It's not more mental bandwidth for me. Because I write the new, and directly delete at the point I need to, then I never think about it again. If I botch something, valgrind will tell me, even pinpointing it with line number.

> ...other things that will do just fine with a smart pointer.

If that works for you, use it. I have no objections.

So isn't that a tool that enforces something upon the programmer?

> If I botch something, valgrind will tell me, even pinpointing it with line number.

What is the benefit of needing valgrind? Isn't it even better to have the task automated away so that the problem doesn't even come up?

It's a tool I voluntarily add to my workflow, which works the way I want, when I want, according to project needs. It's not a limitation put upon me by the language/compiler/whatnot.

> What is the benefit of needing valgrind? Isn't it even better to have the task automated away so that the problem doesn't even come up?

In most cases, performance (think of HPC levels of performance). If I don't need that kind of performance, I can just use the stack or smart pointers.

If we're talking about moving to other programming languages, I'd rather not.

I spent a lot of time maintaining a lot of Perl code. While it was generally very well written, it also made me a big fan of strict, demanding compilers. Perl is quick to write, but can have very high debugging costs since it'll let you get away with a lot that it shouldn't like having a function called with arguments but that completely forgets to retrieve them.

Based on my experience, IMO any class of error that can be eliminated, should be.

So my modern approach is -Wall, -Werrors, -Wextra, and anything else that can be had to that effect, all the time.

Most people are not you. Which, I guess, also answers your original question of "Why many programmers [do the things not they way I would do]?". Incidentally, this is also the root of all the complexity in managing and coordinating people.

You generally need to use higher-level tools for that kind of work: Coq + the Iris framework, for example, in order to prove that your system can freely share memory and not leak secrets so long as X, Y, and Z hold, etc.

Or you need to run a ton of tools like Jepsen to find if your system behaves the way you think it does.

What baking more of the specification language into the programming language does (ie: better type systems) is enable us to have more of these guarantees earlier in the development process when changes are cheaper and faster to make (at the expense of requiring more expertise to use them).

Running a formatter and linter in a pre-commit hook is literally using tools to enforce things?

What I really meant is enforced externally on the programmer, in the form of compiler, development environment setup (from elsewhere) or other guidelines, without any free will to tune or disable them.

The layers I add are voluntary, just checks and balances I decided to add myself because I think they help me, and not enforced as part of the language or toolchain I'm forced to use.

IOW, a self-respecting developer striving to do a good job can continuously sharpen themselves iteratively, tuning their processes and fixing the problems they see as they go along their journey.

Perhaps pjmlp understood the gist of my comment, and his answer is a pretty nice hit on the head of the subject. Honestly, I'm coming from a point where programming is more of a passion which pays rather than work/job for me, hence I have an inner drive to do my best and improve continuously, and not everyone shares the same set of values or inner drive about programming, and want to be railroaded into an environment where they can do the absolute minimum to get things done.

If I'm writing a small toy project where I'm the only person messing with the code, I can totally do it in C, or even raw assembly if I feel like it.

If anyone else will ever write to the same codebase, or the code is for a client/company, I want every automated static check I can possibly have.

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. Pre-processor macros are banned, but deep template abstraction and CRTP abounds. Interface and implementation are separated even when templates demand they be in the same header chain, but here we do so by squirreling away the implementation in a separate file with a non-standard suffix instead of splitting it out but keeping it in the bottom of the same file. In my previous company, we used pointers to indicate the called function could mutate the data... In my new firm, pointers in interfaces are just about banned unless absolutely necessary and we indicate whether data could be mutated via const and documentation.

The language is broad enough to let the developer change almost anything, but it is unfortunately broad enough to let competent developers build competing and equivalently (un-)safe styles.

Better to have sane strict defaults with an escape hatch for experts rather than an open range filled with footguns for any newbie to pick up.

"C++ Core Guidelines" - https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

You can always count on the threads about C or C++ to have somebody ask questions like this.

As a hint, you won't see it asked on any other context. The answer is "all", no exceptions. It's widely known. For decades. In fact, C wasn't even universally used when people discovered this.

Also, there are tools to look for old practices and suggest modern ones.

You can't have a shameful past when you started shameful. ;) This language's roots are in "I wrote some extensions to simplify C, but I don't want to make it incompatible with C so the extensions don't work coherently in all contexts and you only get sound code if you hold your mouth right" and it never actually got better because nothing ever got removed to make the language more sound.

Well, it did. When it happened, it created other languages.

Unfortunately it also yells at you when your *C* code violates the C++ Core Guidelines (at least it was a few years ago when I permamently switched that "feature" off).

"Guideline support" does include libraries with classes that e.g. provide a slice which raises an exception on bounds miss, which is something, and it's certainly notable that the equivalently named C++ standard library feature is a foot gun† whereas the one in the guideline support library is not, so that's a good reason to adopt this. But VS does not in fact ensure you obey all the guidelines, it's very much a "best effort" approach even with that switched on.

† WG21 (The "C++ Standards Committee") seems to have concluded that because sometimes the fast way to do something is unsafe, therefore the unsafe way to do something must be faster... as if car executives noticed that 240mph crashes in their flagship sports car were often fatal and concluded that if they re-design their under-performing SUV so that the fuel tank explodes during any collision killing everybody aboard that'd improve its top speed...

Getting stuck in an infinite loop and never producing an answer is a 4th possibility for attempted solutions at deciding undecidable problems.

I say used to be, given the recent announcement of Azure business unit to switch to Rust as the favoured systems language for new engineering activities.

No, it defines what Microsoft C++ means and nothing more.