Wow, I knew all about the map cases but forgot everything I learned about volatile because I just don't use it.

It's really interesting how safe rust pretty much fixes it all (sometimes at the cost of convenience but still...), you will need to spend time understanding and satisfying the compiler but none of these issues has to be resident in the back of you brain, the compiler will tell you to take a hike bug 1: indexing is checked, period, though "range-based indexing" is also very much the standard bug 2: map doesn't have indexing, and reports lookup failure, and will never insert under you, it's interesting that the language committee itself has taken the "ban it" approach (but the API is also much richer) bug 3: lifetimes prevent this issue bug 4: volatile (both read and write) are unsafe operations on raw pointers; atomics are just... right there (though `AtomicPtr` also works on raw pointers) bug 5: the API of Arc (shared_ptr) doesn't allow this, it will only hand out a mutable reference to the T if you've got the only outstanding copy bug 5 bonus: same as (3), the lifetime of the reference is tied to the Arc instance, if the Arc is dead the reference is not valid bug 6: these are largely weird peculiarities of C++ syntax, rust syntax has its peculiarities (e.g. referencing in v out of a block) but jettisoning compatibility with C reduces the corner cases a lot, there really is no confusion between declaration and initialisation, furthermore: 6.1 the designers of the mutex API had the really smart idea to make the data protected by the mutex *owned by the mutex*, so the lock guard is a smart pointer to the protected data, therefore for "data mutexes" it's really hard to make this mistake. You can make it for non-data mutexes though, `MutexGuard` is tagged "must_use" (similar to C++'s nodiscard) which helps a bit but does not always save your bacon (this also applies to RAII types in general, if you create one you should probably tag it as must_use); Rust also has a trap here: `let _ = foo();` and `let _foo = foo();` have completely different behaviour, the second one will keep an RAII type alive to the end of scope but the first one will not: play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=34ffee864ed8f93f6e81c7741cd96ebc 6.3 the code is not confusing in rust, but it *does* allow same-scope shadowing, so you can do that. It just looks exactly like what it is.

Learning some rust was so beneficial to my ability to write C++ code. When you are forced to think about value lifetime, it makes you a lot more aware of it in other languages, especially if your previous experience was in a managed language where ownership doesn't matter.

As I'm not familiar with rust at all, could you tell me? Does it do a good job preventing some of these or not?

Reference?

I like this

sephirostoy I'm inclined to agree. However, I wouldn't be surprised if someone comes along and provides an example (that I haven't even considered) of where it is very useful.

I would love to see an example of that, because I have never seen that before. Those examples just felt dirty.

Of course it's useful. It's useful when you want to troll people. gist.github.com/aras-p/6224951

It exists because you'd have to specifically detect it and exclude it because it just happens to be part of a broader set of valid but much less confusing parses.

How do you plan to make pointers and references to functions then? Or do you want to special-case the syntax?

Also mapped memory.

Use better variable names. Don’t use i and j for writing loops. Use something like cnt or index.

@@realnapster1522 i is a readable convention, but really you should be using iterators or algorithms from the stl

Glad you enjoyed it!

I'd prob. fix it by changing the first semicolon to a comma. Avoids the need to think of a name. :)

@@Lunaticracy If someone use unique_lock, it will probably be used in the next steps. If not, they have already used lock_guard. So your argument is probably not valid.

That would be super unsafe, IMO. It's not always clear whether something is const at point-of-use and triggering UB in that case would cause lots of bugs (especially for programmers who have learned over the years that [] on maps always is safe to do without bounds checking).

That seems significantly worse

Just use Rust and 90% of your comment is invalid

You can write code safely in C, it just requires being a good programmer. C++ makes it harder to be unsafe, but easier to have logical missteps turn into wrong output. C makes a lot of those problems a moot point. Consider whether something will construct or copy, no problem in C, it's a pointer so you only construct it when you want to, you only copy it when you want to, it does nothing you don't mean for it to do and without you needing to tell it not to. R-Value references are one of the most useful additions to C++ and one of the dumbest. std::move() is super useful, but it shouldn't be needed.

@@therealjezzyc6209 No.

godbolt.org?

Rvalues are allowed to bind to *const* lvalue references due to how temporary materialization works in C++. You might find this useful: www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0345.pdf

A custom `struct` or `class` which would compile-time check the names and allow heterogeneous (non-identical) types.

You have parens from the old C rules, when you declare pointers to functions and arrays, like int (*pf)(int) or int (*parr)[10].

No. I think he was talking about a new type.

There is a Concurrency TS class `atomic_shared_ptr`, which wraps the atomic `shared_ptr` functions into a class, though possibly with efficiency gains. That's probably what he was talking about.

There's been some talk about taking `atomic_shared_ptr` and making it a template specialisation instead of a separate class, so that you would spell it as `atomic` instead. Having said that, all the current implementations of this that I've seen rely on a global spinlock (or at best, a couple of global spinlocks), which introduces some serious deadlock problems in certain types of applications.

*to prevent the compiler from optimizing away a **read or write***

I think the big problem is compatibility, making it return std::optional now.

As mentioned in the lecture by someone in the audience, this doesn't work because optional doesn't work with reference types. You want to use square brackets on the left hand side of an assignment! How this is normally done is to return a proxy type that delays the actual work until it detects the context: writing via an operator=, or reading via an implicit conversion.

The problem with default value for "at" is that "at" returns reference. But the method with default argument should return value, not reference. "value_or" sounds much better

Really, map::operator[] should have returned a reference to the abstract slot. This would be vector-of-bool levels of weird but it would be for all maps so everyone would get to deal with it. You could have implicit conversion throw if empty.

Sometimes you just forget to put a name, because you don't pay attention. And it compiles, so you don't look into that even again.

I just found a std::unique_lock{mutex} lurking in some code …

Do you know any linter that has checks against it?

It's broken because if call on 15:39 returns reference to default value, its lifetime is not extended since it is not stored in a variable as a result of some function. Here's simple example where it while sadly not crashes but leads to undefined behavior: wandbox.org/permlink/NpcfF87AuXQx5xcU

It is ok if the default value is a string literal which is mapped to the data section of the executable. He gave a bad example there. Should have used a temporary variable for the default.

Actually no, that's still bad. The character literal itself is still intact (as constant string data). The temporary std::string wrapper around it, however, is not. (And this contains a pointer to a *unique copy* of the string literal, not the "real" string literal.) And now you have an invalid std::string&. Had it been a const char*& instead, then you might have been safe -- but then you wouldn't be able to return that from a map of std::string values, so it's not a solution either.

Ah, of course. Not only does the code crash, it also doesn't do the thing it was used for in the first place (avoiding copy of memory). Thanks for explaining.

FWIW, you can make it mostly safe and without copies by making an overload that returns a std::string_view (by value) and passing the default parameter as a const char * . BUT this must be an overload (with another overload that takes const std::string&, to help discourage misuse) and you must promise to only ever call it with string literals, never with method().c_str() or similar silliness (so it's not *completely* safe). And of course in doing this you require C++17.

Because technically, the shared_ptr object is thread safe. Any operation you could do on the pointer itself(like assignment to null), and deref, would be properly synchronized. The object it's pointing to is not, but that never was the question, was it?

+PranjalAgrawal The shared_ptr object is NOT thread-safe. If you assign to a shared_ptr and e.g. deref it concurrently, that's a data race. Only the control block (and deleter call) are thread-safe. That was exactly ooltimu's point. Indeed, if shared_ptr was thread-safe, then there would be no point in e.g. atomic_shared_ptr: en.cppreference.com/w/cpp/experimental/atomic_shared_ptr

An object that is thread safe can still have a data race, it really depends on how you use it. For example, if you have a thread safe hashmap, and you concurrently put and get the same key concurrently, that's a race, but the hashmap is still considered threadsafe; the code that accesses it isn't. My point was that all operations that are inherent to the shared_ptr object are thread safe. Any object on the object it references may or may not be.

"My point was that all operations that are inherent to the shared_ptr object are thread safe. " And exactly that is wrong. Unless you can *prove* the opposite applies to shared_ptr (which of course you can't, because you very wrong), the following quote from the C++ standard holds: "The execution of a program contains a data race if it contains two potentially concurrent conflicting actions, at least one of which is not atomic, and neither happens before the other, except for the special case for signal handlers described below. Any such data race results in undefined behavior." ([intro.races/20]) timsong-cpp.github.io/cppwp/intro.multithread#intro.races-20 Conflicting actions are previously defined as any two or more accesses to a memory location, of which at least one is a write. (For object methods, any calls to a method that is not declared const is considered a write, e.g. shared_ptr::reset()). These paragraphs are written as to allow exceptions to be specified elsewhere in the standard, for example concurrent calls to std::mutex::lock(), on the same instance, are allowed even though it is not declared const: "For purposes of determining the existence of a data race, these behave as atomic operations ([intro.multithread]). The lock and unlock operations on a single mutex shall appear to occur in a single total order." [thread.mutex.requirements.mutex/5] timsong-cpp.github.io/cppwp/thread.mutex#requirements.mutex-5 However, for shared_ptr (only) the following is specified: "For purposes of determining the presence of a data race, member functions shall access and modify only the shared_­ptr and weak_­ptr objects themselves and not objects they refer to. Changes in use_­count() do not reflect modifications that can introduce data races." ([util.smartptr.shared]/4) timsong-cpp.github.io/cppwp/util.smartptr.shared#4 I.e., this confirms what has been said before… the control block is specified to be thread-safe (technically, a control block is an implementation detail, so the wording in the standard is different, but that is what it boils down to). So, you can overwrite one shared_ptr while dereferencing another (e.g.), concurrently, even if they co-own the same object. You can also deref the same shared_ptr many times concurrently, because this is a read-only operation. *But you cannot modify a shared_ptr on one thread, and safely modify or read from the same shared_ptr on another thread without additional synchronization.* This is also much different from your example of the thread-safe hash map, where the result is either of two well-defined results (either the erase happens-before the insert, or vice versa, correspondingly, either the key is present in the map after both threads are done, or not). If you overwrite a shared_ptr on one thread, and read from it on another (e.g. just with * or ->), you cannot expect to get either the old or the new value, you get undefined behavior aka nasal demons, as in the quote given above. A program crash or overwriting "random" memory are just two of many possibilities. en.wikipedia.org/wiki/Undefined_behavior Also, you didn't address what I said about atomic_shared_ptr. Again, if shared_ptr was thread-safe, why would they have bothered to define an atomic_shared_ptr class?

People like to claim that "shared_ptr is as safe as int". Which is completely and utterly false. It is actually as thread-safe as two ints. Which is to say, not even slightly thread-safe. (With the single exception of control block reference count updates.) Note that there are some architectures (notably, most desktop PCs) where a single pointer/int _can be_ threadsafe (in the sense that you will always get either the old or the new value, never a frankenvalue) even in the presence of data races -- it's just highly susceptible to accidental mistakes which break it (especially due to compiler optimisations) and it's a really bad idea to rely on it even if you're not writing portable code (so always use locks or atomics). But sadly this is also why "it seems to work anyway" and data races escape detection for so long. It is entirely possible to get a frankenvalue shared_ptr due to a data race.

you probably forgot to miss-spell it. The first one is "hey" the other is "hye"

Facebook.h be like: const PersonalInformation& spyOnUser(const user_id_t user_id);

Slower than a bare pointer? Yes. Slow, remembering what it does? No. If you don't want the extra functionality, use unique_ptr. If you do want it, well, you will never get the performance of bare pointers.

There is a huge difference between "isn't slow" and "is as fast as a raw pointer". Is it slower than a raw pointer if the code doesn't get inlined? Sure. Is that performance difference significant in most use scenarios? No. In hot loops, you shouldn't be transferring ownership of memory, so there's no reason to be copying them.

Well yeah the vector literally has the size of it baked in, so ‘at’ makes no sense in most cases. Completely different than map.

"vector::operator[], what exactly is wrong with it? Because of out of bounds access?" He actually does say that the bug is out of bounds access. "If you want to crash the site, don't check the bounds of your vector". "What if operator[] throws in case of out of bounds access? Is it still a bug then?" The [] operator does not throw. "Anyways, I find this talk pretentious and rude from the start, assuming that we all should know why something is a bug to such an extent that we are not worth being told why." This is a professional conference for C++ developers. As mentioned in the talk out of bounds access is a problem in multiple languages. Assuming everybody knows these things is a fair assumption to make and is not pretentious or rude. The person giving a conference talk is talking to the audience in the room. The fact that the talk is recorded and provided to people on KZfaq is a nice bonus for those of us who didn't/couldn't pay to attend. Making disparaging comments about the people giving the talk is rude and likely to discourage people from wanting to give talks in the future.

If you've been coding by simply calling api calls in something like python then tbh you don't really have any meaningful amount of programming experience. No seriously. This isn't elitist bullshit. In a language like python it convinces you that you've built some "ai" that does facial recognition all by yourself in only a few lines of code! No. You didn't. That's the work of an incredibly complex library that is ACTUALLY probably written in that "ugly c++" (Tensorflow for example). You probably have no clue what's actually going on any concrete level at least.

C++ is a complex language and this seems to be an ugly parser corner case. Probably most C++ programmer would not write such Code (possibly only by accident, which is probably the issue here) and therefore it is not easy to see it right away that the compiler will accept it.

lol. yes create your own data structures which will suffer from even worse pitfalls :D

Adam Zahran Creating data structures is part of a programmers job. And honestly, I've been writing my own data structures and when I do run into problems, I can at least fix mine.

@@fjs9fnehfwhxbfid It seems you work by yourself then ☺

@@MarincaGheorghe Sure you can't avoid using the cpp stdlib if your work requires you to do so. But in which field do you not write your own data structures? And have you never replaced something from the stdlib because it was deficient?

I mostly said it out as a joke and I know it's within your control to make that decision but you have to admit that if X is causing so many issues, you should stop using X.