Hacker News Reader

Comment by WildUtah | Hacker News Reader

C++14 (and higher) feels like coding in Go or Python.

C++17 is so full of good stuff I'm considering beta compilers just to get it. Soon Python and Ruby won't have any advantages left in writing beautiful, clear, correct, bug-free, and easy to read code and C++ will still run 200x faster.

View on HN

> C++17 is so full of good stuff

Structured bindings are going to be amazing! Yea we didn't get modules, but I for one am psyched about this feature alone.

If only they were faster to upgrade compilers at work...

> Soon Python and Ruby won't have any advantages left in writing beautiful, clear, correct, bug-free, and easy to read code

Come on, it's not like they've added garbage collection.

No garbage collection. But, modern C++ recommendations pretty much deprecate manual memory management for 90% of situations. std::vector and std::make_unique for 80% of everything; other containers and make_shared when you really have to; malloc and new for specialty situations.

That's still a lot more work and error-prone than using garbage-collection.

it more like 99% of the time and as long you don't go near new or malloc you generally can't leak.

Then with RAII you can clean up any kind of resource. Most languages have pretty rudimentary tools for closing files and worse for releasing mutexes. These tasks are almost easy to get right in modern C++.

I still love 'with-open-file and its sisters in LISP. Get that resource in one line and it's guaranteed to be cleaned up right without ever thinking about it again. Then you have total freedom to use it however you want and the results destructure themselves.

You could implement something comparable:

    int main() {
        with_open_file_for_writing("foo.dat", [](FILE* fp) {
            fprintf(fp, "old style I/O, automatically closed\n");
        });

        return 0;
    }

"With" is even better in Python. Exceptions during closing work right. The big problem with RAII is that if anything goes wrong in a destructor, you're in trouble.

Newbie C++ programmer here.

Firstly, what exactly is the difference between make_unique and plain old unique_ptr? Why do I need to include a separate template to use the former?

A related issue I faced today. Say I want to create a std::vector of objects. From what I understand, I have three options.

1) Use raw pointers, but be sure to cleanup using delete.

2) Use shared_ptr, which will ensure that your object is safely deleted once no one is referencing it.

3) Create a stack allocated object, then push that onto the vector. The vector will create a shallow copy of the object, and the original copy will be deleted at the end of the current scope.

In this scenario, I wouldn't be able to use unique_ptr, because that would mean that both the vector and the local scope have pointers to that object. Am I correct?

Are there other options for achieving this that I don't know of? Also, which one is the best approach for the general case? I ended up using shared_ptr and it seems to be working fine... I think.

You want std::vector::emplace_back.

I think technically you could use unique_ptr and transfer ownership (move) when pushing into the vector, but the underlying "bad pattern" here is that you almost never want to have a vector of (smart) pointers. The vector should own the objects directly.

>what exactly is the difference between make_unique and plain old unique_ptr

make_unique is just a convenience function for creating a unique_ptr without having to write "new" yourself. It returns a unique_ptr.

> Say I want to create a std::vector of objects. From what I understand, I have three options.

Vectors already own their contents, so there is no need to use unique_ptr here. The objects will be allocated on the heap either way, and you don't need a stack object either. Just push or emplace the object into your vector and be done with it. When the vector is deleted, so will its contents, automatically.

So when I do something like this: http://i.imgur.com/WrRxXCm.png

Is there any overhead (e.g., copying or moving), or potential for memory leaks?

Yes. You will have a memory leak if you don't delete that memory later.

But don't use new. Just push/emplace it into the vector. Perhaps ask more on stackoverflow.

Yeah, your comment is confusing though:

> The objects will be allocated on the heap either way, and you don't need a stack object either. Just push or emplace the object into your vector and be done with it. When the vector is deleted, so will its contents, automatically

I guess what you mean to say is that emplace_back will do the allocation and lifetime management. But using push_back on a stack-allocated object is going to result in a copy.

emplacement doesn't handle lifetime management; the vector itself does this, whether you emplace or push.

push_back with a stack object will copy the object, yes. Emplace_back with a stack object will also, they are not much different. But if you emplace by creating the object inside the emplace call itself, then there is no copy.

see the examples here:

http://en.cppreference.com/w/cpp/container/vector/emplace_ba...

That makes sense. Thanks for the help man, and sorry if I bothered you!

Well of course that is going to leak, but you could instead do std::vector<Person> v; Person p(10); v.emplace_back(p); and be safe

Emplacing an object that already exists misses the point of emplacement.

> Firstly, what exactly is the difference between make_unique and plain old unique_ptr?

The make_unique function uses variadic templates to take the arguments to your constructor:

    auto oldway = std::unique_ptr<Foo>(new Foo(1, 2));
    auto newway = std::make_unique<Foo>(1, 2);

The new way has the small virtue of eliminating one more place where you ever need to call new. However, it also offers the library writer more possibilities in the internal implementation. For instance, they can nest your type in another struct for accounting purposes without copying or additional dereferencing. However the second advantage is more relevant to shared_ptr, which is probably why C++11 had make_shared, but not make_unique (added in C++14).

> I wouldn't be able to use unique_ptr, because that would mean that both the vector and the local scope have pointers to that object.

Yeah, if you're using unique_ptr, the pointer is uniquely owned in at most one place at a time. For your situation, I think the vector should probably own the objects, and you borrow them with references, iterators, or pointers (via the get() method). Be wary of holding on to those references though (the Rust fans will be quick to point out the dangers here).

A fourth option, which you should consider unless your objects are expensive to copy, is to make your objects copyable and not use unique_ptr or shared_ptr at all. I think it's much simpler to reason about objects as values than it is to reason about objects as smart pointers or (dumb) references.

> I ended up using shared_ptr and it seems to be working fine... I think.

Go with what works for you, but shared_ptr makes additional promises about thread safety and interactions with weak_ptr that increase its runtime costs. I wish shared_ptr was simple by default and that there was yet another smart pointer type for when you need those additional features.

The biggest reason to use make_unique and make_shared is to avoid the ancient C++ problem with non-deterministic order of evaluation. In code like this:

    // definition
    foo(std::unique_ptr<bar>, std::unique_ptr<baz>);

    // call
    foo(std::unique_ptr<bar>(new bar), std::unique_ptr<baz>(new baz));

the only guarantee is that `new foo` and `new bar` will occur before the corresponding shared_ptr constructor, and all of them will occur before the call to foo. This means that the following is a valid sequence:

1. new foo 2. new bar 3. unique_ptr ...

Now, if constructor of bar throws, you've leaked foo.

With make_unique, construction and smart pointer acquisition is a single atomic operation - if it throws, everything gets cleaned up.

Interesting, thanks for the example.

That is useful. Thank you.

Garbage collection could prove to be a dead end. Rust and Swift are prospering as the latest cool things because they don't have any. Decades from now we may be hearing about garbage collection as a vastly expensive experiment that simply didn't pan out.

The clever combination of declarative management for common cases and reference counting for complicated cases looks like the winner in the long run.

> Garbage collection could prove to be a dead end.

You'd have to elaborate on that an awful lot to be at all persuasive.

> Rust and Swift

You were comparing C++ to Python and Ruby. We're talking two different paradigms here.

Swift surely has garbage collection. Reference counting is a garbage collection algorithm.

In that case C++ has garbage collection too with std::shared_ptr. I guess 1 is a count too so also with std::unique_ptr.

Indeed, according to these "ref counting is gc" folks, free(void *) is a garbage collector, so C has always been garbage collected since 1970.

No, because the language C doesn't provide any of the algorithms described here:

http://gchandbook.org

Although, there are conservative GCs for C that replace malloc () and make fre () a nop, they cannot release all memory properly due to C semantics.

I am pretty WildUtah was being sarcastic to be a more extreme version of my post. Or perhaps it was an attempt to expand the grey area.

And technically, also unique_ptr, which has a reference count of 1 or 0.

C++ has a GC ABI introduced in C++11 and the dialects C++ Builder, C++/CLI and C++/CX do have GC support at language level.

Library types like std::shared_ptr don't really count to say that a language has a GC, because their use, specially their correct use, is not enforced by the compiler.

You can't just redefine a word that a person has already defined (albeit implicitly), in order to make them wrong. That's not how being right on the internet works. If you want to be right on the internet, you have to define the word before they do.

He's not redefining it. It was defined in the 70s.

https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

Reference counting is definitely a method of garbage collection.

This is just terminology. The important question here is: "Can your program leak memory?"

The risk of memory problems don't disappear because of any form of GC. The problems are just different, and leaks are still quite possible.

They're possible, but not nearly as common. Back when I was coding C++ full time I spent most of my debugging time chasing down memory leaks and out-of-scope variables. Then in a decade of Java programming I think I had one memory leak.

But that's a two-edged sword. Many Java developers, especially those recently out of school, who have never had a C or C++ background, think the GC is a magical blanket that takes care of everything, and as a consequence they don't have an intuitive grasp of the true costs of memory. They just throw things around like it's no big deal. I've interacted with a lot of C++ developers who were hired to rewrite large Java applications in C++ for performance reasons, when really Java could have handled it if only the developers understood memory better.

GC is an abstraction that can work well but can also interfere with how a developer thinks.

> I've interacted with a lot of C++ developers who were hired to rewrite large Java applications in C++ for performance reasons, when really Java could have handled it if only the developers understood memory better.

Yep, this is a big issue.

Another good example is copying arrays of primitive types with for loops instead of using intrisics like System.arrayCopy().

Or using lists instead of arrays.

Sure there are many situations where there is no another way other than step out of the JVM into C++, but many could be avoided with better code as well.

I think Raymond Chen once noted that garbage collection just aims to give the programmer the illusion of infinite memory under the assumption that only finite amounts of memory are every in use at once, while also absolving them from having to release memory manually.

So if your program allocated less than available, doing nothing would be a valid GC strategy as your program never hit an upper bound in what it can allocate.

I found that an interesting way to think about the problem because it's more concerned with what GC enables instead of what it strictly does. The former is always the same, no matter the GC implementation, but the latter can vary considerably (doing nothing, reference counting, mark-and-sweep, full concurrent and compacting GC, ...).

> garbage collection just aims to give the programmer the illusion of infinite memory under the assumption that only finite amounts of memory are every in use at once, while also absolving them from having to release memory manually.

Interestingly, this is also the description of Virtual Memory. https://en.wikipedia.org/wiki/Virtual_memory

I have not redefined anything.

http://gchandbook.org/

Chapter 5.

One of the best CS references in GC algorithms.

I can post links to 70's papers if you wish, specially ones related to Lisp research.

Then C++ is also garbage collected.

Kind of, but only because C++11 defined a pluggable GC ABI.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n267...

Also, there are the C++/CLI and C++/CX that support GC at language level.

Now std::*_ptr<> types don't count to make the language GC, because their use is not enforced by the compiler.

> Now std::*_ptr<> types don't count to make the language GC, because their use is not enforced by the compiler.

Then you also shouldn't say that Swift is garbage collected.

Swift RC is managed by the compiler and is visible in the type system and language semantics.

C++ language definition doesn't give any special treatment tostd::*_ptr<> types regarding compiler semantics. They could be be something else.

Only partially, in Swift, it is still up to the user to cleverly work around scenarios that the system does not catch. Which is why you have weak references and other many tricks in the language to circumvent infinite reference cycles and related problems. It's hard to call language garbage collected when you have to deal with all that stuff yourself. Just look at the stuff you have to do sometimes in your closures to avoid them creating memories leaks.

Why should it be enforced by the compiler?

We're talking about garbage-collected languages (and "language" traditionally includes the standard library), not garbage-collected-only languages.

I mean, by your definition, C# also doesn't count, because it has unmanaged pointers in it.

Totally different.

In C#, GC is part of the language semantics and its interaction with unmanaged pointers is well defined in the language semantics standard, including how the memory is pinned when unmanaged pointers need to access GC allocated memory.

My point is that you're arbitrarily drawing a line between core language and its standard library, that is meaningless in practice.

If reference counting is a kind of GC, and the standard library offers reference counting, then the language offers a kind of GC - same as if the language itself had a built-in refcounted pointer. There's simply no practical difference here.

No, because there is nothing in the language that requires making use of that specific library.

It only makes sense to talk like that, if the language semantics define a relationship between the language and library requiring the library to always exist as a form of runtime and how the use of that runtime relates to language constructs.

If I can just throw away the library and replace it by something else where those types aren't available and still make use of 100% of the language features, this relationship doesn't exist.

That's splitting hairs to the point where the difference is not relevant for any practical purpose.

There's a single document defining what is ISO C++. It defines both the language and the standard library. Therefore, to "write in C++", by default, means to write code that uses and relies upon both the language semantics and the standard library functionality. Which means that std::shared_ptr etc is readily available, and is the standard way to use refcounting-based GC in C++.

Hence, ISO C++ is a language with optional refcounting-based GC.

I add the remark here: in some literature, especially older, Reference Counting is not listed under Garbage Collection, but under Automatic Memory Management or Automatic Storage Reclamation.

See page 6, remark 7 in 'Uniprocessor garbage collection techniques', Paul Wilson:

http://scholarworks.rit.edu/cgi/viewcontent.cgi?article=1322...

Who needs garbage collection when you have std::shared_ptr.

Probably people who are having more complex data than a single tree.

Exaggerated, I know, but it's not like your post was particularly nuanced.

> Probably people who are having more complex data than a single tree.

Reference counting is safe with a DAG (not just a tree), but I get your point. For the times I've needed an arbitrary graph data structure, I used an adjacency matrix to store it.

std::shared_ptr works, but fyi often there's a slightly better alternative. For cases where the target object is not shared between asynchronous threads, mse::TRefCountingPointer[1] is smaller/safer/faster/more scalable. For cases where the target is shared between threads (while being modified) mse::TAsyncSharedReadWriteAccessRequester[2] is safer.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus#reference-c...

[2] https://github.com/duneroadrunner/SaferCPlusPlus#asynchronou...

Put your data in the stack.

If only the stack were large enough for everything. In which case, use unique_ptr.

Isn't not having garbage collection and advantage?

I mean we have destructors which handle so much more than garbage memory.

Close files, release mutexes, close sockets, cleanup thread pools, manage the lifetime of anything. One time I opened a web browser in the constructor and closed it in the destructor, and I had full confidence that no matter what crap happened in the middle my app never leaked whole browsers.

Memory fragmentation? And alloc/free aren't free. So now you have to hack together your own memory management scheme and hope it performs well enough in both areas to be worth the extra effort and lost safety.

Contemporary allocators make allocation cheap. Not sure how GC is any better at fragmentation.

Some garbage collectors can move objects to remove fragmentation and update the pointers to them. eg: https://hacks.mozilla.org/2015/07/compacting-garbage-collect...

If you're thinking like that I don't see why you wouldn't prefer Java or C#? One of the major advantages of C and C++ is explicit memory allocation and lack of GC pauses.

A person could wish for a more compact and lightweight runtime than what Java and .Net offer while still having GC. I imagine some of those people are checking out Go nowadays.

Oracle's JVM have compacting GC that solves memory fragmentation, but Python and Ruby certainly do not. Python and Ruby interpreters also do a lot more dynamic allocations, so if memory fragmentation is ever a problem, they suffer worse.

Most languages with garbage collection also have a mechanism for deterministic cleanup, e.g. IDisposable in C#, or AutoClosable in Java. That's because when dealing with external, or non-memory resources, deterministic release is a good thing. That doesn't mean that that scheme has to be the only option for memory allocations. Garbage collection has a lot of benefits, too.

Herb Sutter presented one in a talk a little while ago. https://github.com/hsutter/gcpp https://www.youtube.com/watch?v=JfmTagWcqoE

So it's totally doable in library without cost to those that do not need it.

That looks like a great talk, as all of Sutter's talks are. Thanks.

With C++ since C++11, there is little need for garbage collection. I haven't written a manual memory "new" or "delete" in years, thanks to unique_ptr (which in my benchmarks is somehow also faster than manually managing the memory).

> Soon Python and Ruby won't have any advantages left in writing beautiful, clear, correct, bug-free, and easy to read code

Does that mean C++17 will finally get support for the generator pattern?

The generator pattern is really not that fundamental a language construct, and, in general, is quite straightforward to implement in languages with powerful enough abstractions. C++ is one such language: http://www.boost.org/doc/libs/1_62_0/libs/coroutine/doc/html...

I wouldn't call it straightforward, boost.coroutine requires custom assembler for its implementation. Then again, stackfull coroutines are significantly more powerful than generators available in most other programming languages (notable recent exceptions are Go and Lua).

Boost.asio provides stackless generators [1] implemented purely in C++, by (ab)using the preprocessor and the switch statement.

[1] http://www.boost.org/doc/libs/1_62_0/doc/html/boost_asio/ove...

Care to share any resources where you can learn about the new features that take it there?

Wish I could. The hours I've spent reading the formal committee proposals and specs would have been better spent on video games and junk food.

But there will be books, and good ones. Next year probably. The compilers aren't even ready yet.

The best I found are CppCon youtube videos, really

Reply on news.ycombinator.com