HN Theater @HNTheaterMonth

⬐ ur-whale

These are all good suggestions, but for me the three nicest features of modern c++ are:

    - auto
    - lambdas
    - all the "inplace" construction stuff (*.emplace_back)

These truly change the language and make it way better.

The day C++ allows trailing commas in argument lists and gets rid of semi-columns, my life will be complete ;)

⬐ je42

and - range based for loop

- deduction guides (C++17) (no more make_some_type)

- structured bindings (C++17)

- optional,variant (C++17)

⬐ ur-whale

> - range based for loop

Oh yeah.

How could I not include this in the list <bangs head>

I use them all the time.

⬐ jcelerier

I don't think it's very far for arguments list, considering that you can already do it in some cases :

    struct foo {
      float x;
      float y;
    };

    int main() {
        std::array<float, 3> x{1,2,3,};
        foo f{1,2,};
    }

⬐ SloopJon

These are the type of tips that would great in a new edition of C++ Common Knowledge. Effective Modern C++ is great, but sometimes a little more in depth than you need or want on a first reading.

⬐ eecsninja

Good stuff. Makes me wonder how many programmers still think of pre-C++11, and all the tropes of what's wrong with the older form of the language, when they opt for using other languages like Java. SMH.

⬐ smilekzs

Video excerpt:

1. When overriding methods, use `void Method() override;` instead of `virtual void Method()`. (original video says use both `virtual` and `override` but this is redundant as `override` implies `virtual`)

2. Explicit type for enum: `enum MyEnum : uint32_t { ... };`. Does not require `enum class`.

3. Prefer `using NewType = OldType` to `typedef OldType NewType` (so that it's obvious which type is your `NewType` --- not so much when function pointers and arrays are involved in the `typedef` case).

4. Struct/class member fields can have in-line default values: `struct A { int x = 1; int y = 2; };`.

5. Explicitly `delete` constructors and assign operators.

6. Use `constexpr` functions to calculate compile-time constants instead of macros.

7. `explicit operator bool`

8. `static_assert` is now standard (no more macro needed)

9. `#include <chrono>` for type-safe time

⬐ electricslpnsld

No mention of smart pointers? I'd wager I use unique_ptr way more than type-safe time!

⬐ Guvante

`unique_ptr` is more of an investment as if you call `get()` all the time you can still end up with dangling references.

⬐ kllrnohj

The context of the talk was for game devs who currently largely avoid the STL, avoiding any debate on whether or not that avoidance makes sense.

⬐ GuB-42

Because smart pointers are a different way to code. It is not a drop in feature that makes your code better without any design change.

In all examples you can't really argue. All these things are common patterns that require ugly hacks to work in traditional C++. Modern C++ made them the way people would naturally write them, and they don't involve self imposed restrictions or performance overheads.

The chrono stuff is a bonus, not included in the main 7, probably chosen because of the author personal experience. But I understand that if you work with code that involve a lot of timing, it can be a godsend. Time unit mismatch can be incredibly frustrating, I've experienced it myself both as the culprit and as a victim.

⬐ None

None

⬐ hermitdev

As someone actively working on trying to modernize & improve a poorly-written legacy C++ code base, these are all great & easy to use points.

#1 is great for catching subtle bugs. Forget a const/volatile qualifier? override will catch it. inadvertently call for an int instead of a long? override will catch it.

#3 is great for readability. Especially when the type you're naming is complex. (I'm looking at you, Boost multi_index_container). The name comes first, the rest of the gobbledygook comes after what you're looking for.

#5 is great - no longer need to inherit from boost::noncopyable or explicitly mark compiler supplied constructors/operators as private. Clearer intent. In the same vane, using default for, well, defaults. I see so much code like `struct Foo{ Foo(){} };`. The default is clearer to me as far as intent.

#6 constexpr is valuable, but the example given in the video was kind of poor. It was already possible to get the array size using template metaprogramming at compile time in arguably simpler code than the example.

#9 chrono is pretty great, but it's support is spotty. It's also not exactly user-friendly. Key formatting APIs are missing in long term supported versions of GCC in major Linux distros. (I'm currently on Ubuntu 14.04 w/ GCC 4.8 and, for example, it's missing put_time). It's usage is pretty cumbersome. I haven't used it enough to have committed operations to memory, but things that would be 1 or 2 lines using Boost DateTime can be like 5-8 lines with chrono - not ideal.

Edit: minor spelling/grammar/intent changes