[PATCH] Allow for the use of StringRef command line options instead of cl::opt<std::string>

David Blaikie dblaikie at gmail.com
Fri Aug 16 08:54:56 PDT 2013


On Fri, Aug 16, 2013 at 8:43 AM, Chris Lattner <clattner at apple.com> wrote:
>
> On Aug 15, 2013, at 10:57 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>> On Thu, Aug 15, 2013 at 4:56 PM, Puyan Lotfi <plotfi at apple.com> wrote:
>>>
>>> This sounds like a workable compromise.
>>> To avoid leaking how about a CommandLine.cpp handled string pool that allocates copies on demand (specified maybe by an optional flag to ParseCommandLineOptions/ParseEnvironmentOptions) but also has the option of flushing/deallocating the pool?
>>
>> I'm with Chris - I think it should be simpler to have
>> ParseCommandLineOptions/CommandLine in general not be concerned with
>> task of owning the strings. That should be the responsibility of the
>> caller.
>
> Also, I don't know if switching from cl::opt<std::string> to cl::opt<StringRef> is enough, but I'd really like for the cl::opts scattered through llvm to stop requiring static constructor/destructors.  This seems like a useful step along the way.

True - it shouldn't be hard to make StringRef's defoult ctor constexpr
under C++11 - not sure what else is in a cl::opt that might present
challenges to that kind of solution.



More information about the llvm-commits mailing list