<div>+lldb-dev<br></div><div><br></div>I'm actually ok just migrating towards override slowly (i.e. when you touch a class that overrides some methods, add the override keyword), but if people think it should be all or nothing (and if nobody else volunteers to help with the "all" part), then I guess I'll do it.<div><br></div><div>Eric, or anyone else: Is there a compiler flag that will warn or error if a virtual method in a derived class overrides one in a base class but does not use the override keyword?  Otherwise it's going to be difficult to find all the places that require changing.<br><br><div class="gmail_quote">On Mon Nov 17 2014 at 6:16:55 PM <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Nov 17, 2014, at 5:54 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> It's true you have to remember whether you're in the base class, but as you deduced, that's pretty much the point.  FWIW I switched all of ProcessWindows over to using it just a day ago, because I found some dead code that occurred due to not using it, which this would have found.  Apparently process plugins used to have plugin logging and plugin commands, because ProcessLinux and ProcessWindows had stub methods like EnablePluginLogging and ExecutePluginCommand, but these methods were nowhere to be found in base classes.  So I guess at some point they were deleted, but since virtual both declares a new virtual method and overrides an existing one, this dead code was never detected.<br>
><br>
> This isn't quite as serious as introducing an actual bug, but either way, we can all agree that dead code sucks.<br>
><br>
> Since the virtual keyword is optional but harmless on an override, we could always adopt the policy of requiring the "virtual" keyword on an override, which should address your concern of having to look in two places.  This way you can still simply look at the beginning to see if a method is virtual or not, and override is just a little syntatic sugar on the end to get the compiler to generate an error when you actually make an error.<br>
<br>
I guess override doesn't go in the same place as virtual because the C++11 folks didn't want to grab another keyword, so they had to stick it at the end of a declaration so they could tell what it meant?  That's unfortunate since it means two tokens with very similar semantic meaning occur in totally different places in the declaration, but I guess we're stuck with that.<br>
<br>
If we are going to use it we should probably stick to one or the other.  Otherwise it's just even more noise.<br>
<br>
On the topic of noise, I also kinda hate the notion of the noise making all our code consistent would introduce, but if we are going to use it we should do so consistently.  I have a strong vote which is that whoever votes FOR this should take on making it consistent, and those who vote against it can politely thank them for their efforts ;-)<br>
<br>
Jim<br>
<br>
<br>
><br>
> On Mon Nov 17 2014 at 5:36:22 PM <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
> Override seems kind of gross to me.  I can't use it on base class functions.  If I just use override I get<br>
><br>
> override.cpp:3:22: error: only virtual member functions can be marked 'override'<br>
>   int DoSomething () override;<br>
><br>
> and if I put both I get:<br>
><br>
> override.cpp:3:15: error: 'DoSomething' marked 'override' but does not override any member functions<br>
>   virtual int DoSomething () override;<br>
>               ^<br>
> Now I have to remember whether I'm in the base class for this method or not, and I have to look in two places in the declaration (one after lots of noise) to see whether the method is actually virtual or not.<br>
><br>
> It's kinda nice that it tells me if I got a method a little wrong, but I wonder whether that "at the time I change method names" convenience is worth the more common reading through code annoyance.  I vote not to use it, though it's not a strong vote.  If we are going to use it we should go through and make its use consistent otherwise we'll keep getting errors where people copy from the base class and forget to switch all the "virtual" on the LHS to "override" on the RHS...<br>
<br>
<br>
<br>
><br>
> Jim<br>
><br>
><br>
> > On Nov 17, 2014, at 5:28 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> ><br>
> > override implies virtual and is a strict superset of virtual, so there's nothing inherently wrong with "mixing" them.  The advantage of override is that it will cause the compiler to error if, for example, you delete a virtual method from a base class (or change the signature), but forget to make a corresponding change in derived implementations.<br>
> ><br>
> > For example, if you have<br>
> ><br>
> > class A<br>
> > {<br>
> > public:<br>
> >    virtual void Foo();<br>
> > };<br>
> ><br>
> > class B : public A<br>
> > {<br>
> > public:<br>
> >   virtual void Foo();<br>
> > };<br>
> ><br>
> > this is all fine.  If someone goes and changes A to the following:<br>
> ><br>
> > class A<br>
> > {<br>
> > public:<br>
> >    virtual void Foo(int x);<br>
> > };<br>
> ><br>
> > This will continue to compile no problem, and not alert the user to the fact that there is now a bug in the code.  On the other hand, if the original implementation of B had been like this:<br>
> ><br>
> > class B : public A<br>
> > {<br>
> > public:<br>
> >    virtual void Foo() override;   // keyword "virtual" is optional here<br>
> > };<br>
> ><br>
> > then when the change was made to A, B would generate a compiler error that there was no appropriate method to override.<br>
> ><br>
> > As far as deciding to switch to override, I propose we decide that right now :)   There's no advantage to not doing so, since it is a strict superset of virtual, and surfaces a common source of programmer error as a compiler error.<br>
> ><br>
> > On Mon Nov 17 2014 at 4:43:31 PM <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
> > As I understand it, mixing override & virtual is a recipe for confusion...  We currently use virtual, and not override.  At some point we can talk about switching over to using override everywhere, but I don't think we are at that point.<br>
> ><br>
> > So in this case your patch is incorrect, and the "virtual" should go back in.  And then until we decide to switch to using override, can you turn off whatever warning is causing you to (as I understand it) incorrectly remove these "virtual" markers?<br>
> ><br>
> > Jim<br>
> ><br>
> ><br>
> > > On Nov 17, 2014, at 3:14 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br>
> > ><br>
> > > It's fine as virtual, but you're overriding a method and not marking it as override. You don't need to write both down (you could, but it's a nop) as override only works on virtual functions.<br>
> > ><br>
> > > -eric<br>
> > ><br>
> > > On Mon Nov 17 2014 at 3:07:27 PM <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
> > > I'm sure I'm missing something obvious, but I don't understand what this warning you are fixing is supposed to be telling you about.  The inheritance hierarchy is:<br>
> > ><br>
> > > PlatformDarwin<--<u></u>PlatformPOSIX<--Platform<br>
> > ><br>
> > > Platform.h defines:<br>
> > ><br>
> > >         virtual Error<br>
> > >         ResolveExecutable (const FileSpec &exe_file,<br>
> > >                            const ArchSpec &arch,<br>
> > >                            lldb::ModuleSP &module_sp,<br>
> > >                            const FileSpecList *module_search_paths_ptr);<br>
> > ><br>
> > ><br>
> > > Then PlatformPosix.h doesn't override ResolveExecutable, and finally, PlatformDarwin has:<br>
> > ><br>
> > >     virtual lldb_private::Error<br>
> > >     ResolveExecutable (const lldb_private::FileSpec &exe_file,<br>
> > >                        const lldb_private::ArchSpec &arch,<br>
> > >                        lldb::ModuleSP &module_sp,<br>
> > >                        const lldb_private::FileSpecList *module_search_paths_ptr);<br>
> > ><br>
> > ><br>
> > > Why is it wrong for PlatformDarwin to define this method as virtual?<br>
> > ><br>
> > > Jim<br>
> > ><br>
> > ><br>
> > ><br>
> > > > On Nov 17, 2014, at 2:55 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br>
> > > ><br>
> > > > Author: echristo<br>
> > > > Date: Mon Nov 17 16:55:13 2014<br>
> > > > New Revision: 222186<br>
> > > ><br>
> > > > URL: <a href="http://llvm.org/viewvc/llvm-project?rev=222186&view=rev" target="_blank">http://llvm.org/viewvc/llvm-<u></u>project?rev=222186&view=rev</a><br>
> > > > Log:<br>
> > > > Fix override/virtual warnings.<br>
> > > ><br>
> > > > Modified:<br>
> > > >    lldb/trunk/source/Plugins/<u></u>Platform/MacOSX/<u></u>PlatformDarwin.h<br>
> > > ><br>
> > > > Modified: lldb/trunk/source/Plugins/<u></u>Platform/MacOSX/<u></u>PlatformDarwin.h<br>
> > > > URL: <a href="http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/MacOSX/PlatformDarwin.h?rev=222186&r1=222185&r2=222186&view=diff" target="_blank">http://llvm.org/viewvc/llvm-<u></u>project/lldb/trunk/source/<u></u>Plugins/Platform/MacOSX/<u></u>PlatformDarwin.h?rev=222186&<u></u>r1=222185&r2=222186&view=diff</a><br>
> > > > ==============================<u></u>==============================<u></u>==================<br>
> > > > --- lldb/trunk/source/Plugins/<u></u>Platform/MacOSX/<u></u>PlatformDarwin.h (original)<br>
> > > > +++ lldb/trunk/source/Plugins/<u></u>Platform/MacOSX/<u></u>PlatformDarwin.h Mon Nov 17 16:55:13 2014<br>
> > > > @@ -27,57 +27,58 @@ public:<br>
> > > >     //----------------------------<u></u>------------------------------<u></u>--<br>
> > > >     // lldb_private::Platform functions<br>
> > > >     //----------------------------<u></u>------------------------------<u></u>--<br>
> > > > -    virtual lldb_private::Error<br>
> > > > +    lldb_private::Error<br>
> > > >     ResolveExecutable (const lldb_private::ModuleSpec &module_spec,<br>
> > > >                        lldb::ModuleSP &module_sp,<br>
> > > >                        const lldb_private::FileSpecList *module_search_paths_ptr) override;<br>
> > > ><br>
> > > > -    virtual lldb_private::Error<br>
> > > > +    lldb_private::Error<br>
> > > >     ResolveSymbolFile (lldb_private::Target &target,<br>
> > > >                        const lldb_private::ModuleSpec &sym_spec,<br>
> > > > -                       lldb_private::FileSpec &sym_file);<br>
> > > > +                       lldb_private::FileSpec &sym_file) override;<br>
> > > ><br>
> > > >     lldb_private::FileSpecList<br>
> > > >     LocateExecutableScriptingResou<u></u>rces (lldb_private::Target *target,<br>
> > > >                                         lldb_private::Module &module,<br>
> > > > -                                        lldb_private::Stream* feedback_stream);<br>
> > > > +                                        lldb_private::Stream* feedback_stream) override;<br>
> > > ><br>
> > > > -    virtual lldb_private::Error<br>
> > > > +    lldb_private::Error<br>
> > > >     GetSharedModule (const lldb_private::ModuleSpec &module_spec,<br>
> > > >                      lldb::ModuleSP &module_sp,<br>
> > > >                      const lldb_private::FileSpecList *module_search_paths_ptr,<br>
> > > >                      lldb::ModuleSP *old_module_sp_ptr,<br>
> > > > -                     bool *did_create_ptr);<br>
> > > > +                     bool *did_create_ptr) override;<br>
> > > ><br>
> > > > -    virtual size_t<br>
> > > > +    size_t<br>
> > > >     GetSoftwareBreakpointTrapOpcod<u></u>e (lldb_private::Target &target,<br>
> > > > -                                     lldb_private::BreakpointSite *bp_site);<br>
> > > > +                                     lldb_private::BreakpointSite *bp_site) override;<br>
> > > ><br>
> > > > -    virtual bool<br>
> > > > +    bool<br>
> > > >     GetProcessInfo (lldb::pid_t pid,<br>
> > > > -                    lldb_private::<u></u>ProcessInstanceInfo &proc_info);<br>
> > > > +                    lldb_private::<u></u>ProcessInstanceInfo &proc_info) override;<br>
> > > ><br>
> > > > -    virtual lldb::BreakpointSP<br>
> > > > -    SetThreadCreationBreakpoint (lldb_private::Target &target);<br>
> > > > +    lldb::BreakpointSP<br>
> > > > +    SetThreadCreationBreakpoint (lldb_private::Target &target) override;<br>
> > > ><br>
> > > > -    virtual uint32_t<br>
> > > > +    uint32_t<br>
> > > >     FindProcesses (const lldb_private::<u></u>ProcessInstanceInfoMatch &match_info,<br>
> > > > -                   lldb_private::<u></u>ProcessInstanceInfoList &process_infos);<br>
> > > > -<br>
> > > > -    virtual bool<br>
> > > > -    ModuleIsExcludedForNonModuleSp<u></u>ecificSearches (lldb_private::Target &target, const lldb::ModuleSP &module_sp);<br>
> > > > -<br>
> > > > +                   lldb_private::<u></u>ProcessInstanceInfoList &process_infos) override;<br>
> > > > +<br>
> > > > +    bool<br>
> > > > +    ModuleIsExcludedForNonModuleSp<u></u>ecificSearches(lldb_private::<u></u>Target &target,<br>
> > > > +                                              const lldb::ModuleSP &module_sp) override;<br>
> > > > +<br>
> > > >     bool<br>
> > > >     ARMGetSupportedArchitectureAtI<u></u>ndex (uint32_t idx, lldb_private::ArchSpec &arch);<br>
> > > ><br>
> > > >     bool<br>
> > > >     x86GetSupportedArchitectureAtI<u></u>ndex (uint32_t idx, lldb_private::ArchSpec &arch);<br>
> > > ><br>
> > > > -    virtual int32_t<br>
> > > > -    GetResumeCountForLaunchInfo (lldb_private::<u></u>ProcessLaunchInfo &launch_info);<br>
> > > > +    int32_t<br>
> > > > +    GetResumeCountForLaunchInfo (lldb_private::<u></u>ProcessLaunchInfo &launch_info) override;<br>
> > > ><br>
> > > > -    virtual void<br>
> > > > -    CalculateTrapHandlerSymbolName<u></u>s ();<br>
> > > > +    void<br>
> > > > +    CalculateTrapHandlerSymbolName<u></u>s () override;<br>
> > > ><br>
> > > > protected:<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > ______________________________<u></u>_________________<br>
> > > > lldb-commits mailing list<br>
> > > > <a href="mailto:lldb-commits@cs.uiuc.edu" target="_blank">lldb-commits@cs.uiuc.edu</a><br>
> > > > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-commits</a><br>
> > ><br>
> ><br>
> ><br>
> > ______________________________<u></u>_________________<br>
> > lldb-commits mailing list<br>
> > <a href="mailto:lldb-commits@cs.uiuc.edu" target="_blank">lldb-commits@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-commits</a><br>
<br>
</blockquote></div></div>