Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern C++ for C Programmers: part 5

ds9a.nl

Post reply on HN
Print view View original

21–30 of 82 posts

Re: Modern C++ for C Programmers: part 5

#21

Post by stephencanon »

ajross wrote: post #8
stephencanon wrote: post #2

Return value optimization is absolutely allowed in C, and ~all compilers do it. It's not commonly talked about because in C, there can be no side-effects when constructing or copying a struct, so there's nothing to discuss. It just happens automatically and there's no observable change in program behavior.

C compilers can do copy ellision when inlining code as long as the result is identical. That's not quite the same thing as RVO, which deliberately relaxes the notion of "identical result" such that it's possible to write C++ code to detect whether or not RVO was actually performed. That's not possible in C (or shouldn't be).

It's possible that I'm missing something, but I believe that the result is necessarily identical in C, because there can be no observable side-effect of a struct copy in the C abstract machine.

Re: Modern C++ for C Programmers: part 5

#22

Post by stefan_ »

rrmm wrote: post #7

Please please please can we get rid of headers and have modules? I find it super annoying having to specify things half in one place and half in another. Unfortunately, there still seems to be a bit of disagreement on the implementation among the standards committee.

Don't forget about the whole "include what you use" problem. There's a static analysis tool for that but of course it's a hopeless proposition for something as powerful as headers (despite no one ever needing that power).

Re: Modern C++ for C Programmers: part 5

#23

Post by microtherion »

datamart wrote: post #12
mikec3010 wrote: post #10

> The move constructor is the important bit. Its presence tells C++ that this class can not be copied, only moved Is that true? I thought move ctor enabled move semantics, but if you pass by value the copy ctor was still called (except in places where RVO makes sense). And I thought to disable copying you made the copy ctor = delete.

The implicitly-declared copy constructor is deleted if there is a user-defined move constructor. See: https://en.cppreference.com/w/cpp/language/copy_constructor#... So if you define a move constructor and still want your class to have a copy constructor, you'll have to explicitly define the copy constructor, too.

Luckily, in modern C++, defining the copy constructor in this case (where you just want to make the default available) is as simple as:

    A::A(const A &other) = default;

Re: Modern C++ for C Programmers: part 5

#24

Post by yoklov »

mlevental wrote: post #9

is there a modern C++ for python programmers? i have ~5 years programming in dynamic/interpreted (python/js) and compiled/gc'd(java/go) languages and i'd like to learn a systems language. i'm reading the rust programming book (and it's really good/easy to grok) but i'd also like to learn C++. the problem is that most books are either too easy (C++ as your first language) or too hard (straight into RAII and templates)…

Worth noting that auto_ptr is decidedly not modern, it was deprecated in c++11 because it was error prone and replaced with C++11's unique_ptr (and shared_ptr/weak_ptr too sort of, although they have a different use case -- unique_ptr really is basically the same use case as auto_ptr).

I figure you didn't mean to call it out specifically and more meant general smart pointers, but just felt I'd let you know that searching for that terminology may lead you astray.

Re: Modern C++ for C Programmers: part 5

#25

Post by _pmf_ »

tlb wrote: post #17
mikec3010 wrote: post #10

> The move constructor is the important bit. Its presence tells C++ that this class can not be copied, only moved Is that true? I thought move ctor enabled move semantics, but if you pass by value the copy ctor was still called (except in places where RVO makes sense). And I thought to disable copying you made the copy ctor = delete.

"The implicitly-declared or defaulted copy constructor for class T is defined as deleted if any of the following conditions are true ... T has a user-defined move constructor or move assignment operator" (since C++11) https://en.cppreference.com/w/cpp/language/copy_constructor But there's no harm in explicitly deleting it, and it helps document the intent.

What's the motivation behind this?

Re: Modern C++ for C Programmers: part 5

#26

Post by SidiousL »

stephencanon wrote: post #21
ajross wrote: post #8

Earlier quoted context omitted.

C compilers can do copy ellision when inlining code as long as the result is identical. That's not quite the same thing as RVO, which deliberately relaxes the notion of "identical result" such that it's possible to write C++ code to detect whether or not RVO was actually performed. That's not possible in C (or shouldn't be).

It's possible that I'm missing something, but I believe that the result is necessarily identical in C, because there can be no observable side-effect of a struct copy in the C abstract machine.

I tried to find an example that contradicts what you said, but I can't find any. Here's an online example which can be compiled as both C and C++ and I obtain exactly the same assembly using both clang and gcc. Maybe somebody can tweak this example to force the C compiler not to perform the optimization.

https://godbolt.org/g/7Ewun7

Re: Modern C++ for C Programmers: part 5

#27

Post by tlb »

_pmf_ wrote: post #25
tlb wrote: post #17

Earlier quoted context omitted.

"The implicitly-declared or defaulted copy constructor for class T is defined as deleted if any of the following conditions are true ... T has a user-defined move constructor or move assignment operator" (since C++11) https://en.cppreference.com/w/cpp/language/copy_constructor But there's no harm in explicitly deleting it, and it helps document the intent.

What's the motivation behind this?

The committee probably observed that in most cases where people wanted a move constructor, they needed either no copy constructor or a more complicated one (to handle duplicating a resource.) So creating a default copy constructor (a convenience in the common case of a simple structure) wasn't a win.

Perhaps if you were designing C++ from scratch without legacy and had a more Python-like mindset, you'd require an explicit "= default" rather than complicated rules about whether a default is provided for you or not.

Re: Modern C++ for C Programmers: part 5

#29

Post by cmrdporcupine »

rrmm wrote: post #7

Please please please can we get rid of headers and have modules? I find it super annoying having to specify things half in one place and half in another. Unfortunately, there still seems to be a bit of disagreement on the implementation among the standards committee.

Absolutely There keeps being proposals for C++ standard modules, and it keeps getting punted.

Having a reasonable module system, and hell even some lovely tools for migrating sane projects over to it, would make me much happier with the language.

For what it's worth, Clang has experimental support for C++ modules.

Post reply on HN