7 ms·

last time I used C++ was in the mid-2000s. With all the new features since then, I assume the "proper" way/style to right C++ has changed since then?

gumby 7y ago
I don't know if you mean formatting, in which case I don't believe anything has changed (pretty much anything goes) but yes, you can now do for (auto [x, y] : list_of_coordinates()) ... and things like that.
gameswithgo 7y ago
* is now deprecated.
- gumby 7y ago
  Not formally, but as you were responding to a comment on style: indeed, you don't really need * that often; there are more powerful, safer options in most cases. But C++ is a systems programming language and * is still quite useful.
- CodeMage 7y ago
  This is not even remotely true. Let's say you have: std::unique_ptr<foo> m_foo; How do you pass that into a function that can receive a pointer to foo, but does not require it? The only way to do so is to declare the function to take a foo* and pass it m_foo.get() In summary, * will never be deprecated until C++ has support for something along the lines of Rust's borrowing and lifetimes.
  - Leherenn 7y ago
    I am not sure I understand what you mean, but now (c++17) you can use an optional in this case.
  - paulddraper 7y ago
    > How do you pass that into a function that can receive a pointer to foo, but does not require it? Same as you would have a function that can receive an `int` but does not require it. Or a receive a `std::vector` but does not require it. I surmise that you mean "how do you pass any value (pointer or otherwise) into a function that can receive a value but does require it". And I surmise you have before used pointer indirection to pass that value because it has a conventional sentinel value of 0/NULL/nullptr. You are correct in that optional values did not have a standardized solution, until C++17 std::optional. If you don't have C++17, I recommend one of the equivalent third-party implementations: * https://www.boost.org/doc/libs/1_52_0/libs/optional/doc/html/index.html https://www.boost.org/doc/libs/1_52_0/libs/optional/doc/html... * https://github.com/akrzemi1/Optional https://github.com/akrzemi1/Optional
    - deleted 7y ago
      [deleted]
    - jcelerier 7y ago
      std::optional does not support references (std::optional<MyVeryLargeType&>) however unlike boost, so this precludes usage with non-copyable types.
      - paulddraper 7y ago
        That was decided against for now, though I'm not sure why. [1] In any case, you can use std::optional<std::reference_wrapper<MyVeryLargeType>>. [1] https://stackoverflow.com/a/26895581 https://stackoverflow.com/a/26895581
        jcelerier 7y ago
        > In any case, you can use std::optional<std::reference_wrapper<MyVeryLargeType>>. I would frankly give a negative code review to anyone who would do that. You go from e.g. void my_function(T* foo, T* bar, int baz) { // ... foo->stuff(bar, baz); } to void my_function(std::optional<std::reference_wrapper<T>> foo, std::optional<std::reference_wrapper<T>> bar, int baz) { // ... foo->get().call(&bar->get(), z); } this also has more overhead (sizeof(std::optional<std::reference_wrapper<T>>) is twice the size of T* ), and let's not even start talking about calling conventions and the compile time cost of having to include both <functional> and <optional> everywhere.
  - gumby 7y ago
    This is precisely what std::optional is for.
  - CodeMage 7y ago
    I can't edit my original comment anymore, so I'll just write a clarification in the reply. Many people have pointed out that C++17 has std::optional. While that's true, I don't think it'll deprecate raw pointers. I'll try to explain why. Here's an example you can paste, compile and run: #include <iostream> #include <memory> struct foo { int thingamajig; }; void borrow_optional_foo(foo * borrowed) { if (borrowed != nullptr) { borrowed->thingamajig = 42; } } int main() { std::unique_ptr<foo> owned = std::make_unique<foo>(); owned->thingamajig = 17; std::cout << owned->thingamajig << std::endl; borrow_optional_foo(owned.get()); std::cout << owned->thingamajig << std::endl; return 0; } If you run it, it should print: 17 42 What would it look like if we wanted to use std::optional and get the same behavior? #include <iostream> #include <functional> #include <memory> #include <optional> struct foo { int thingamajig; }; void borrow_optional_foo(std::optional<std::reference_wrapper<foo>> borrowed) { if (borrowed) { borrowed->get().thingamajig = 42; } } int main() { std::unique_ptr<foo> owned = std::make_unique<foo>(); owned->thingamajig = 17; std::cout << owned->thingamajig << std::endl; borrow_optional_foo(std::make_optional(std::ref(*(owned.get())))); std::cout << owned->thingamajig << std::endl; return 0; } As you can see, there's a tradeoff involved. On the one hand, you get crystal clear, descriptive type: std::optional<std::reference_wrapper<foo>> is clearly an optional reference to foo. On the other hand, using it is absolutely atrocious: you have to write borrowed->get().thingamajig as opposed to borrowed->thingamajig, and std::make_optional(std::ref(*(owned.get()))) as opposed to owned.get() Does it work? Absolutely. Is it crystal clear? Indisputably so. Will it deprecate raw pointers? I really, really doubt it, but that's just my opinion.
    - jez 7y ago
      This is a great reply and I think it echoes what I've seen written elsewhere. For example, this one by Herb Sutter: https://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters/ https://herbsutter.com/2013/06/05/gotw-91-solution-smart-poi...
MauranKilom 7y ago
Largest changes (most from C++11, some from C++14 and C++17) are: - std::unique_ptr and std::shared_ptr (your code should not have any new/delete). It's easy to write code with clearly defined ownership semantics, and I've yet to create a memory leak. - Proper memory model so that multithreading has defined semantics. - Lots of syntactic sugar (auto, range-for, lambdas, structured bindings, if constexpr, etc.). - More metaprogramming tools/fun. C++11 alone is a very different world compared to what you are probably used to.
- noobermin 7y ago
  Generally good things, but I get triggered when I hear people call metaprogramming "fun." Such is the beginning of all sorts of woes.
  - ncmncm 7y ago
    Many of the improvements are to make metaprogramming increasingly unnecessary. I practically don't use it at all anymore. But coding on C++ has become quite fun. Generic lambdas deserve much of the credit.
- sramsay 7y ago
  > - std::unique_ptr and std::shared_ptr (your code should not have any new/delete). It's easy to write code with clearly defined ownership semantics, and I've yet to create a memory leak. I cannot begin to describe how huge a thing this was for me. I came to C++-17 (just about) from C++-98 -- a language I hated so much, I vowed I would never, ever write anything in it on purpose. It is a massively different beast today from what it was, but the biggest thing of all is this change in how you deal with memory. It was like going from a particularly annoying and verbose aberation of C to a particularly fast and expressive version of Python. YMMV, of course. In fact, it may vary to the point of becoming absolutely unrecognizable if you're dealing with a massive legacy codebase. But I have to say, I've become a very big fan in the last few years.
  - axilmar 7y ago

gumby 7y ago

I don't know if you mean formatting, in which case I don't believe anything has changed (pretty much anything goes) but yes, you can now do for (auto [x, y] : list_of_coordinates()) ... and things like that.

gameswithgo 7y ago

* is now deprecated.

gumby 7y ago
Not formally, but as you were responding to a comment on style: indeed, you don't really need * that often; there are more powerful, safer options in most cases. But C++ is a systems programming language and * is still quite useful.
CodeMage 7y ago
This is not even remotely true. Let's say you have: std::unique_ptr<foo> m_foo; How do you pass that into a function that can receive a pointer to foo, but does not require it? The only way to do so is to declare the function to take a foo* and pass it m_foo.get() In summary, * will never be deprecated until C++ has support for something along the lines of Rust's borrowing and lifetimes.
- Leherenn 7y ago
  I am not sure I understand what you mean, but now (c++17) you can use an optional in this case.
- paulddraper 7y ago
  > How do you pass that into a function that can receive a pointer to foo, but does not require it? Same as you would have a function that can receive an `int` but does not require it. Or a receive a `std::vector` but does not require it. I surmise that you mean "how do you pass any value (pointer or otherwise) into a function that can receive a value but does require it". And I surmise you have before used pointer indirection to pass that value because it has a conventional sentinel value of 0/NULL/nullptr. You are correct in that optional values did not have a standardized solution, until C++17 std::optional. If you don't have C++17, I recommend one of the equivalent third-party implementations: * https://www.boost.org/doc/libs/1_52_0/libs/optional/doc/html/index.html https://www.boost.org/doc/libs/1_52_0/libs/optional/doc/html... * https://github.com/akrzemi1/Optional https://github.com/akrzemi1/Optional
  - deleted 7y ago
    [deleted]
  - jcelerier 7y ago
    std::optional does not support references (std::optional<MyVeryLargeType&>) however unlike boost, so this precludes usage with non-copyable types.
    - paulddraper 7y ago
      That was decided against for now, though I'm not sure why. [1] In any case, you can use std::optional<std::reference_wrapper<MyVeryLargeType>>. [1] https://stackoverflow.com/a/26895581 https://stackoverflow.com/a/26895581
      - jcelerier 7y ago
        > In any case, you can use std::optional<std::reference_wrapper<MyVeryLargeType>>. I would frankly give a negative code review to anyone who would do that. You go from e.g. void my_function(T* foo, T* bar, int baz) { // ... foo->stuff(bar, baz); } to void my_function(std::optional<std::reference_wrapper<T>> foo, std::optional<std::reference_wrapper<T>> bar, int baz) { // ... foo->get().call(&bar->get(), z); } this also has more overhead (sizeof(std::optional<std::reference_wrapper<T>>) is twice the size of T* ), and let's not even start talking about calling conventions and the compile time cost of having to include both <functional> and <optional> everywhere.
- gumby 7y ago
  This is precisely what std::optional is for.
- CodeMage 7y ago
  I can't edit my original comment anymore, so I'll just write a clarification in the reply. Many people have pointed out that C++17 has std::optional. While that's true, I don't think it'll deprecate raw pointers. I'll try to explain why. Here's an example you can paste, compile and run: #include <iostream> #include <memory> struct foo { int thingamajig; }; void borrow_optional_foo(foo * borrowed) { if (borrowed != nullptr) { borrowed->thingamajig = 42; } } int main() { std::unique_ptr<foo> owned = std::make_unique<foo>(); owned->thingamajig = 17; std::cout << owned->thingamajig << std::endl; borrow_optional_foo(owned.get()); std::cout << owned->thingamajig << std::endl; return 0; } If you run it, it should print: 17 42 What would it look like if we wanted to use std::optional and get the same behavior? #include <iostream> #include <functional> #include <memory> #include <optional> struct foo { int thingamajig; }; void borrow_optional_foo(std::optional<std::reference_wrapper<foo>> borrowed) { if (borrowed) { borrowed->get().thingamajig = 42; } } int main() { std::unique_ptr<foo> owned = std::make_unique<foo>(); owned->thingamajig = 17; std::cout << owned->thingamajig << std::endl; borrow_optional_foo(std::make_optional(std::ref(*(owned.get())))); std::cout << owned->thingamajig << std::endl; return 0; } As you can see, there's a tradeoff involved. On the one hand, you get crystal clear, descriptive type: std::optional<std::reference_wrapper<foo>> is clearly an optional reference to foo. On the other hand, using it is absolutely atrocious: you have to write borrowed->get().thingamajig as opposed to borrowed->thingamajig, and std::make_optional(std::ref(*(owned.get()))) as opposed to owned.get() Does it work? Absolutely. Is it crystal clear? Indisputably so. Will it deprecate raw pointers? I really, really doubt it, but that's just my opinion.
  - jez 7y ago
    This is a great reply and I think it echoes what I've seen written elsewhere. For example, this one by Herb Sutter: https://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters/ https://herbsutter.com/2013/06/05/gotw-91-solution-smart-poi...

MauranKilom 7y ago

Largest changes (most from C++11, some from C++14 and C++17) are: - std::unique_ptr and std::shared_ptr (your code should not have any new/delete). It's easy to write code with clearly defined ownership semantics, and I've yet to create a memory leak. - Proper memory model so that multithreading has defined semantics. - Lots of syntactic sugar (auto, range-for, lambdas, structured bindings, if constexpr, etc.). - More metaprogramming tools/fun. C++11 alone is a very different world compared to what you are probably used to.

noobermin 7y ago
Generally good things, but I get triggered when I hear people call metaprogramming "fun." Such is the beginning of all sorts of woes.
- ncmncm 7y ago
  Many of the improvements are to make metaprogramming increasingly unnecessary. I practically don't use it at all anymore. But coding on C++ has become quite fun. Generic lambdas deserve much of the credit.
sramsay 7y ago
> - std::unique_ptr and std::shared_ptr (your code should not have any new/delete). It's easy to write code with clearly defined ownership semantics, and I've yet to create a memory leak. I cannot begin to describe how huge a thing this was for me. I came to C++-17 (just about) from C++-98 -- a language I hated so much, I vowed I would never, ever write anything in it on purpose. It is a massively different beast today from what it was, but the biggest thing of all is this change in how you deal with memory. It was like going from a particularly annoying and verbose aberation of C to a particularly fast and expressive version of Python. YMMV, of course. In fact, it may vary to the point of becoming absolutely unrecognizable if you're dealing with a massive legacy codebase. But I have to say, I've become a very big fan in the last few years.
- axilmar 7y ago