[lldb-dev] RFC: Break/Watchpoint refactor

[Sean Callanan via lldb-dev]

That solves the problem of excising the macros, but it replaces it with now having to look at a superclass.  Honestly that sounds like six one way, a half dozen the other.
I wouldn't want this great overall list of improvements to get sidetracked over bike shedding this, however.  I'm fine with whatever approach is used, even if it's the status quo.

Sean

> On Sep 27, 2016, at 3:43 PM, Zachary Turner <zturner at google.com> wrote:
> 
> One solution I've seen (I think boost does this as well) is to make a utility class called noncopyable that you can privately inherit from:
> 
> class noncopyable {
> public:
>    noncopyable(const noncopyable &) = delete;
>    noncopyable &operator=(const noncopyable &other) = delete;
> };
> 
> class Foo : private noncopyable {
> };
> 
> 
> 
> On Tue, Sep 27, 2016 at 3:29 PM Sean Callanan <scallanan at apple.com <mailto:scallanan at apple.com>> wrote:
> The issue I have with the DISALLOW_ macro is that when you're looking to see what sort of constructors etc. are possible, you now have to look through a macro.  Personally, I like to see what constructors are available on an object in one list, and not have to guess about whether e.g. a move constructor is present or disallowed.
> 
> Sean
> 
>> On Sep 27, 2016, at 3:24 PM, Jim Ingham <jingham at apple.com <mailto:jingham at apple.com>> wrote:
>> 
>> Why?  The macro states the intent explicitly, rather than having to deduce it from details scattered through the class definition.
>> 
>> Jim
>> 
>>> On Sep 27, 2016, at 3:13 PM, Sean Callanan via lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
>>> 
>>> Doing it everywhere would be a public service IMO.  I don't like macros either.
>>> 
>>> Sean
>>> 
>>>> On Sep 27, 2016, at 3:07 PM, Zachary Turner via lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
>>>> 
>>>> FWIW LLVM removed all it's disallow copy / assign macros in favor of explicitly writing it.  I agree it's easier to just change the macro, but I would just do what LLVM does as long as you don't mind the extra work.
>>>> 
>>>> On Tue, Sep 27, 2016 at 3:01 PM Daniel Austin Noland via lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
>>>> 
>>>> 
>>>> On 09/27/2016 03:37 PM, Enrico Granata wrote:
>>>>> 
>>>>>> On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
>>>>>> 
>>>>>> * Prefer explicitly deleted copy ctor / assignments over multiline macro DISALLOW_COPY_AND_ASSIGN
>>>>> 
>>>>> 
>>>>> Why not just move DISALLOW_COPY_AND_ASSIGN over to using =delete ? That seems like a trivial change..
>>>> 
>>>> That was my first thought as well.  Still, I personally try to avoid macros.  On the other hand that one is simple enough that it may be justified.
>>>> 
>>>>> 
>>>>> Thanks,
>>>>> - Enrico
>>>>> 📩 egranata@.com <> ☎️ 27683
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> lldb-dev mailing list
>>>> lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>>>> _______________________________________________
>>>> lldb-dev mailing list
>>>> lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>>> 
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160927/df8de0c1/attachment-0001.html>