Hacker News Reader

Comment by jcelerier | Hacker News Reader

> After years of usage of GC, it is very hard to go back time for manually managing the memory.

... are you guys sure of your "experienced C++ developers" ? There's as much memory management in modern C++ than in GC'ed language: none. Create your objects with `make_unique` or `make_shared` according to what makes sense (or just enforce `make_shared` if you're really dubious of the coding abilities of your team but at this point you'll have problems whatever you do).

View on HN

"...make_shared"

Sorry, I'm going to be a bit harsh now.

There is a host of distinctive differences between garbage collection and reference counting. Yes, both are memory handling strategies. That's where the similarities end.

"Just slap it in a shared pointer" is never a good advice without knowledge what 'it' is or in what kind of system it exists in.

> There is a host of distinctive differences between garbage collection and reference counting.

No, reference counting is commonly seen as a specific implementation of garbage collection. https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

> "Just slap it in a shared pointer" is never a good advice without knowledge what 'it' is or in what kind of system it exists in.

I agree, but it seems from their blogpost that they are not sure that their developers are able to handle the "mental overhead" of managing ownership, hence the simple solution of going for shared ownership everytime.

(btw, I re-read your post three times and could not find any hint of harshness !)

"No, reference counting is commonly seen as a specific implementation of garbage collection"

Shared pointers provide the reference counting, but reference counting alone hardly constitutes a garbage collector because it doesn't collect all of the garbage.

For example, shared_ptr:s alone do not automatically detect and collect cycles.

Chapter 5 of The Garbage Collection Handbook.

http://gchandbook.org/

The dirty secret of the "garbage collection vs. manual memory management" war is that there isn't actually a bright shining line to be drawn anywhere; it's actually a relatively smooth continuum ranging on the one end from statically allocating all values up front (in the style of embedded system) to the dynamic languages on the other end, with dozens of stops in between.

Yeah, that read like some Java advertising from the 90s.

I wish more of these posts were honest and said "we picked X cause we think it's cool and we're gonna get paid to learn it". But they have to make up some convoluted explanation that sounds rational and acceptable instead.

from the post , looks like they really do think picking rust is dope and already built a cool db system upon it. Maybe they already got bunch of bucks in the pocket. Huhhh..

Hahahah, you're right. We picked Rust cuz our CEO and I think it's cool... XD

I think you are being needlessly inflammatory. The list of 3 items against C++ makes it pretty clear they do have experienced C++ developers.

But then your program uses slow, cache-unfriendly and much-reviled reference counting. I'd even prefer Ocaml and its fully-featured GC if C++ is only fast in artificial benchmarks and not in idiomatic code, which apparently must use RC.

Note: I haven't used C++ at all on any project larger than a single file.

And do all the C++ libraries take only smart pointers as arguments and return only smart pointers as return values?

> And do all the C++ libraries take only smart pointers as arguments and return only smart pointers as return values?

C++ libraries that would be as recent as Rust libraries would certainly take things by value or reference so there would be no problems. I honestly don't know libraries with raw pointers in their APIs that aren't from the 90's or before; and I don't think you want to use those in a current product anyways.

This is a little difficult on Windows or POSIX systems.

Also, as others have pointed out, you can smart-pointerise everything, but still have problems with common tree and graph structures. Rust is rigorous. C++ isn't; I'm not aware of any mainstream compilers which even have the option to make use of bare pointers or unsafe casting or undefined behaviour into compiler warnings/errors.

Which is what keeps companies like LDRA in business.

http://ldra.com/

> This is a little difficult on Windows or POSIX systems.

How so ? it's not like you are using the Win32 or POSIX APIs in 2017 anyways

Not everything has a convenient wrapper, just the high profile stuff like files and GUIs. Are there wrappers for things like dlopen()? posix_madvise? All the various set... functions? Filesystem ACLs? COM objects?

(I'm something of an outlier here, maintaining a big legacy MFC application that targets Windows CE, but I can't be the only one. One implication of this is that I'm using the Microsoft MIPS compiler with this banner, that's probably older than some of the readers here and certainly predates C99:

    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
    Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

... but my point is that it's not sensible to say nobody's using the system native APIs in 2017!)

> I'm something of an outlier here, maintaining a big legacy MFC application that targets Windows CE, but I can't be the only one.

The problem is not developing "legacy" apps, it's comparing the development and maintenance of "legacy" apps with apps that just get started being written today, for which the bare minimum is being cross-platform.

> Are there wrappers for things like dlopen()? posix_madvise?

Actually, yes, in a cross-platform way:

* http://www.boost.org/doc/libs/1_65_1/doc/html/boost_dll.html (does dlopen, dlclose, and so much more)

* http://www.boost.org/doc/libs/1_65_1/doc/html/boost/interpro... (advise() == posix_madvise if available)

> Filesystem ACLs ?

none that I know of :( though MS has a fairly decent "modern C++" API that covers WinRT: https://github.com/Microsoft/cppwinrt but I don't think ACLs are even available in WinRT

> COM

oh, yes: https://www.codeproject.com/Articles/5748/Introducing-Comet

Interesting stuff. Boost do seem to be aiming for complete wrapper coverage.

> Boost do seem to be aiming for complete wrapper coverage.

I don't think "boost" is aiming at anything. If you have a good idea of a library (and a good implementation!) you can submit it to boost. It's more a big repository of libraries with a somewhat consistent coding style.

They don't, and it is (or should be) considered bad practice for functions, in general, to take/return smart pointers. Normally these should only be used as variables or class members; functions, on the other hand, should take/return raw pointers (except some special cases) or, better yet, references (except when there is a need to check for null value).

I disagree? Functions which allocate things returning unique_ptr is much clearer than returning a raw pointer. Clear ownership being passed, as opposed to maybe just having a view into some internal buffer.

I mean, if you only view functions as being called for side effects, then yeah maybe. But if you're constructing a data pipeline, unique_ptr in and out makes a lot of sense.

Sure, and that is a special case I was referring to. (Another one would be a class factory method returning a unique pointer to an interface.)

In general, though, passing a unique_ptr around is a bit cumbersome as this requires calling std::move way too often.

First sentence is why I dread reading comment. Why you gotta be like that?

sorry, could you explain a bit more ? does '... are you guys sure of your "experienced C++ developers" ?' sound harsh to you ?

It's just a very loaded opinion, while you pretend it's a universal fact. I have never heard, nor experienced, any seasoned C++ developer claiming that smart pointers is a substitute for garbage collection.

Yes, smart pointers are nice, they alleviate you from a whole lot of manual memory management - but the programming model is still vastly different from what you would do in a traditional GC'ed language(such as Java or C#)

A lot of C++ big names have said that smart pointers are better than garbage collection for handling resources. And they are, because GC only handles memory.

Having memory leaks in modern C++ is a sign of not keeping up with the established idioms. Saying that experienced C++ programmers are worried about memory leaks is bizarre.

You're talking to someone who says they're an experienced painter. They show you some of their work. You reply "are you sure you're an 'experienced painter'?"

After answering a question during a job interview, the interviewer says 'are you sure you're a "senior programmer?"'

I don't see a problem with either (and heard far worse in my professional life; the best to date would more or less translate to "what are you ? a bunch of fucking monkeys ?").

And how would smart pointers help you if you need to return pointer to a member from a function? Does C++ protects you from moved from unique_ptr? Or from iterator invalidation? Or maybe you can safely use non-atomic shared pointer if you don't need to send it across threads?

While "just enforcing `make_shared`" wouldn't solve all the memory safety issues, it actually can be somewhat practical to "just avoid using any (or most) C++ elements that can access invalid (or uninitialized) memory", instead using the safe, compatible substitutes in the SaferCPlusPlus[1] library.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

You'll have to manually break cycles using weak_ptr though.

But you'd have to do that in Rust too, or at least use a library like petgraph, because Rust hates cycles even more than C++.

True. But you wouldn't have to do that in most GC languages.

Reply on news.ycombinator.com