[PATCH] D18172: [CUDA][OpenMP] Add a generic offload action builder

[Justin Lebar via cfe-commits]

Yeah, I'd say that in the absence of a rule, consistency with surrounding
code is king.  Otherwise we're sending a message when we don't mean to be.

I'm not at my machine, but my recollection is that most of the driver uses
final sparingly.  But whatever the convention is we should do that, I think.
On Jun 30, 2016 9:16 PM, "Samuel Antao" <sfantao at us.ibm.com> wrote:

> sfantao added a comment.
>
> In http://reviews.llvm.org/D18172#471861, @jlebar wrote:
>
> > Alexey, it seems that you're asking for "final" on all classes that are
> not inherited from.  Forgive my ignorance, but would you mind pointing me
> to the document that talks about our position on "final" in LLVM source?  I
> don't see it in the style guide, but I may be missing something.
> >
> > The style guide does talk a good bit about writing concise and generally
> not-misleading code.  My concern is that adding "final" everywhere paints
> an inaccurate picture and will mislead readers.  Specifically, "final" is
> useful as a signal to readers that a class cannot safely be inherited
> from.  "Don't even think about it, buster."  But here we're adding "final"
> to a lot of classes that, as far as I can tell, aren't distinctive except
> in that they have no subclasses today.  The problem with this is that, if
> we use "final" in this way, it dilutes the first "don't even try" meaning.
> Now when I see a class with "final" that I want to subclass, I'm just going
> to rip the "final" off, because chances are, I can do so safely.  Now
> "final" does not serve as a warning to me that I shouldn't do this.
> >
> > Sorry to focus on a superficial issue, but I think this really does
> matter for usability.
>
>
> Hi Justin,
>
> Thanks for the comment!
>
> I understand both interpretations can be useful for different purposes,
> i.e. "don't inherit, it is not safe" vs "feel free to change this class
> without worrying with subclasses". I tend to think that the latter (which I
> believe is what Alexey has in mind) can, in general, be more useful in the
> sense that a class is usually safe to extend - you can always add features
> that are somewhat orthogonal to what the parent class is doing. I can, of
> course, imagine cases where your argument is valid - you can have an
> implementation that allocates memory based on the type of the parent
> therefore it does not observe the extra storage required by derived
> classes. However, I think these cases are less common.
>
> I also look at the programming guidelines and couldn't find a clear answer
> to the issue you raised.
>
> I don't have a strong opinion about this, just giving my two cents.
>
> Thanks again!
> Samuel
>
>
> http://reviews.llvm.org/D18172
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160701/34763242/attachment.html>