Modern C++ for C Programmers: part 5 • Hacker News Board

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

#51

Post by hermitdev » Wed, Jul 25, 2018, 9:02 PM UTC

mikec3010 wrote: post #16

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.

Certain IDE vendors could solve this if they really cared about UX. Not by implementing modules, but by efficiently scanning vast directories for versions of headers, and arranging them in a visually navigable manner (you know, actually being a useful IDE). The last time I used one, the OS was incapable of even searching folders. Partial string matching of filenames was apparently too complex for it to handle.

If you have your IDE properly configured with the include dirs needed to build, at least MSVC can autocomplete for you. Personally, I don't rely on this, as I do most of my C++ work from the command line using bash, vim & make.

Can't explain why, but for C++ projects, I intuitively remember what paths I need for headers, but for a C# project, I rely upon autocomplete as a crutch. Maybe it's just how much more time I spend doing C++ work and the time I spend with the libraries I use vs the relatively small time I spend with C#.

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

#52

Post by runevault » Wed, Jul 25, 2018, 9:06 PM UTC

swaroop wrote: post #13

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)…

Have you tried "A Tour of C++"? https://www.safaribooksonline.com/library/view/a-tour-of/978...

Been getting back into C++ lately after not using it since college ('02), did not know they were releasing a new edition of Tour of C++, will have to check it out (already read Principles and Practices which was interesting once it got into the meat of C++, and plan to read Myer's effective books at some point).

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

#53

Post by alaaibrahim » Wed, Jul 25, 2018, 9:07 PM UTC

merlincorey wrote: post #41

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.

Single-file header libraries are actually all the rage in C++ these days. Here's[1] a list even! [1] https://github.com/nothings/single_file_libs

Wouldn't that defeat the purpose of dynamic linking?

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

#54

Post by hermitdev » Wed, Jul 25, 2018, 9:10 PM UTC

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)…

Probably not quite what you're looking for, as I assume you're looking for a Modern C++ guide for Python developers, but surely the Boost Python source is worth a look for good Modern C++ to interact with Python. Fair warning, the learning curve on understanding or using this library is more like a cliff than a curve. It is very heaving in TMP (Template Meta Programming). That said, if you can make sense of this, you can probably consider yourself a near expert in TMP.

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

#55

Post by ape4 » Wed, Jul 25, 2018, 9:11 PM UTC

Wow that was a good post. I have read other Modern C++ things are they were so dense. If all the sections were in a little book, I'd buy it.

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

#56

Post by saagarjha » Wed, Jul 25, 2018, 9:27 PM UTC

> In general, always prefer the std::make_* form for smart pointers. For std::shared_ptr it turns two allocations into one, which is a huge win both in CPU cycles and memory consumed.

You also get exception safety because the it's not evaluated in an unspecified order.

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

#57

Post by BeeOnRope » Wed, Jul 25, 2018, 9:31 PM UTC

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.

No C doesn't have RVO in the C++ sense. Sure C can optimize the copies implied by "returning values" in the same way they can optimize other copies or anything at all, if the observable behavior is the same, due to "as if" - but that's not RVO (as it is discussed in C++). It doesn't even need a special name: it's just plain old optimization.

RVO is a very specific optimization that has its own language in the standard (which is notable since the standard is pretty much silent on the vast majority of optimizations) and it is special precisely because it allows the optimization to occur even if it changes observable behavior. C does not have it, and compilers must compile the some code more conservatively because of it: e.g., if the address of return values escape in the caller and/or callee, a C compiler must ensure that the program always observes distinct addresses for distinct objects in the source, but in C++ one is free to observe that two apparently different objects are the same.

Now, sure, at least 90% of actual RVO is about eliminating constructors and destructors with side effects - which C doesn't have and so RVO simply doesn't apply most of the time: but one shouldn't conclude that "C has RVO", rather "C mostly doesn't need RVO, and in the cases were it could use it, it is not allowed and must be more conservative than C++".

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

#58

Post by BeeOnRope » Wed, Jul 25, 2018, 9:49 PM UTC

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.

No, it is not necessarily identical in C, because even though you don't have constructors or destructors, you can make an address comparison to check whether two objects are identical.

For example the following code:

https://godbolt.org/g/ikD6bi

where the address of the caller's variable that will take the return value is passed along to the function returning it. Within the callee, f1 and f2 must be different objects in C, but not in C++.

All decent compilers compile this in C++ with only a single object, so sink() will receive identical objects. Most compilers "deoptimize" this in C since sink cannot receive identical objects: two objects are created so f1 and f2 have different addresses, and a copy is performed from f2 to the return value f1.

Due to a bug, clang mis-compiles this and applies the C++ RVO to C. So you maybe you are right: you can get RVO in C, but only due to a compiler bug!

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

#59

Post by e12e » Wed, Jul 25, 2018, 9:49 PM UTC

a1369209993 wrote: post #44

8xde0wcNwpslOw wrote: post #43

Earlier quoted context omitted.

Don't quote me on this, but I think padding bytes might have different values in certain cases.

I'm fairly sure it's always undefined behavior to observe those differences, so while it's possible in practice, it'd never work in theory.

> while it's possible in practice, it'd never work in theory.

Hah, sounds like you nailed the emergent philosophy of C there... :-)

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

#60

Post by BeeOnRope » Wed, Jul 25, 2018, 9:51 PM UTC

SidiousL wrote: post #26

stephencanon wrote: post #21

Earlier quoted context omitted.

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

See my reply to the parent poster for an example where RVO applies in C++ but not C, leading to better code in the C++ case. The key is to let the address of the objects involved escape: otherwise "as if" will let C (and C++ even without RVO) optimize away the copies anyways, since they are not observable in that case.