https://android.googlesource.com/platform/frameworks/base/+/...
they should have used make_shared, but it is still safe
It exposes everything as C APIs, even thought it is a mix of Java and C++ on the implementation side, leaving the C++ developers to write their own type safe abstractions from scratch.
Most just can't be bothered and write C in C++.
Then there is the whole issue how, following Google C++'s guidelines, the NDK is actually implemented.
I don't know how much back in the past it is, but pretty much every time in the last ten years I tried to beat a C++ abstraction, I almost never managed to substantially improve (and since gcc.godbolt.org exists it made it much easier to witness that most of the abstraction layers entirely disappear at -O2)
Or they may not see that stuff as an improvement in the first place (e.g. see Orthodox C++[0]).
Discomfort is not a valid reason to avoid learning new things.
That seems like a rather weak conclusion given all the words that preceded it. You might as well just start and end with this:
New standards have issues, people don't know how to use them correctly, and compilers are slow to catch up. Wait 5 years to use a standard so all these things are worked out, and you don't have to worry about the details that don't stick.
In any case this is just an example, there are a couple of similar "subsets" with the same idea of keeping C++ use to its bare minimum, it is just that i remember this one because of the name :-P
Thing* thing = new Thing();
thing->DoStuff();
delete thing;
is perfectly valid C++ and has been since the invention of the language. It's not a good idea, but it is valid.If, OTOH, you do
Thing* thing=(Thing*)malloc(sizeof(Thing));
free(thing);
the you fully deserve the inevitable world of pain that is coming your waywe're in 2020.
$ clang-tidy -checks='cppcoreguidelines-*' foo.cpp
/tmp/foo.cpp:10:3: warning: initializing non-owner 'Thing *' with a newly created 'gsl::owner<>' [cppcoreguidelines-owning-memory]
Thing* thing = new Thing();
^
/tmp/foo.cpp:12:3: warning: deleting a pointer through a type that is not marked 'gsl::owner<>'; consider using a smart pointer instead [cppcoreguidelines-owning-memory]
delete thing;
^
/tmp/foo.cpp:10:3: note: variable declared here
Thing* thing = new Thing();
^I'm not arguing it's good C++, but saying "C++'s destructor behaviour doesn't work if you don't use C++" in relation to using new and delete is clearly nonsense.
I guess it depends on your definition of "valid".
Let's say we have:
class Thing
{
public:
Thing() { cout << "created" << endl; }
~Thing() { cout << "destroyed" << endl; }
};
Assuming the happy path, the new/delete version will be functionally identical to a more correct/idiomatic {
auto thing = make_unique<Thing>();
}
The malloc/free version won't call the destructor, and therefore doesn't do what a "normal" object would do.It's splitting hairs, I guess, but that's where I'd draw the line.