> 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.
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?
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
> 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.
