[LLVMdev] Final added to parser<bool>
Simon Atanasyan
simon at atanasyan.com
Wed Mar 18 21:35:52 PDT 2015
Hi Reed,
The FalseParser has a rather strange design. It's purpose to parse
options like -no-to-do-something and always return false even if a
user provides -no-to-do-something=no. That should be fixed on the
MCLinker side.
On Thu, Mar 19, 2015 at 5:14 AM, reed kotler <rkotler at mips.com> wrote:
> //===----------------------------------------------------------------------===//
> // FalseParser
> //===----------------------------------------------------------------------===//
> class FalseParser : public parser<bool> {
> public:
> explicit FalseParser(Option &O) : parser<bool>(O) { }
>
> // parse - Return true on error.
> bool parse(cl::Option& O, StringRef ArgName, StringRef Arg, bool& Val) {
> if (cl::parser<bool>::parse(O, ArgName, Arg, Val))
> return false;
> Val = false;
> return false;
> }
> };
>
> I don't know the history of this. I'm just starting to do some mclinker work
> to add the new mips r6 relocations to it.
>
>
> On 03/18/2015 07:00 PM, David Blaikie wrote:
>
>
>
> On Wed, Mar 18, 2015 at 6:48 PM, reed kotler <rkotler at mips.com> wrote:
>>
>> Hi David,
>>
>> Is there a reason that we need to have "final" for parser<bool> ???
>
>
> Clang has a (reasonable) warning for types with virtual functions and a
> non-virtual dtor. This warning is suppressed if the dtor is protected or the
> class is final (since in the first case it's clear that the user intends not
> to destroy objects via base pointers, only derived ones - and in the second
> case there's no risk of derived classes, so public access to the dtor is
> safe even without virtual dispatch.
>
> Since the parser hierarchy never needed polymorphic destruction (all
> instances are concrete instances of derived classes owned and destroyed
> directly, not via base pointers) this seemed like a fine way to structure
> the API.
--
Simon Atanasyan
More information about the llvm-dev
mailing list