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 <ztur...@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 <scalla...@apple.com
> <mailto:scalla...@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 <jing...@apple.com
>> <mailto:jing...@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
