[llvm] r212403 - Declare variable on first use.
rafael.espindola at gmail.com
Tue Jul 22 14:20:32 PDT 2014
Sorry for the delay in replying, I was on vacations.
> Surely create* functions other allocation functions should return raw
> pointers, leaving it up to the caller how to adopt them?
> This is built right into the C++ programming language (new/delete),
> verifiable using all kinds of checkers and instantly recognisable to C and
> C++ developers.
> I'm really not keen on wrapping these return types in multiple layers of
> templates, and I don't think anyone seriously thinks the current situation
> ErrorOr<std::unique_ptr<MemoryBuffer>> is turning out well.
I do actually. Having that work is one of my favorite things with the
switch to c++11. Before we had to choose between ErrorOr or a
error_code return with a OwningPtr out param.
> Ultimately every raw pointer in the codebase could be wrapped with some kind
> of smart pointer, but it'd achieve little other than wearing down < and >
> keys, so let's avoid going that way.
So for you have been the only one to express this opinion. In the
cases I switched to using an explicit unique_ptr it was not uncommon
to find a leak in an error case that was just not being tested.
I much prefer having the ownership being explicit in the type. The
analogy with new is not appropriate for a few reasons, not the least
of it being that new predates smart std::unique_ptr.
On the original issue:
LTOModule::createFromBuffer could return a unique_ptr, but I would
like to avoid too many changes to lib/LTO at the same time. There will
be some refactoring to it as part of getting a much improved
tools/gold and eventually lld LTO support. I will take a look at
lib/LTO api once the bigger changes are done.
More information about the llvm-commits