I have been giving study to the private and public classes for
break/watchpoints and I have some ideas for how to improve them. I am
looking for comments from the community on this now to avoid wasted work
and invite suggestion for improvements and any objections you may have.
Some problems w
On Tue, Sep 27, 2016 at 1:09 PM Daniel Austin Noland via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> 4. All of these classes are "old school" (not necessarily bad, but
> potentially a problem). For example:
>a. lots of const char* running around.
>
We should use llvm::StringRef here.
>
> On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev
> wrote:
>
> I have been giving study to the private and public classes for
> break/watchpoints and I have some ideas for how to improve them. I am
> looking for comments from the community on this now to avoid wasted work and
> On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev
> 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..
Thanks,
-
On 09/27/2016 03:23 PM, Zachary Turner wrote:
On Tue, Sep 27, 2016 at 1:09 PM Daniel Austin Noland via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:
4. All of these classes are "old school" (not necessarily bad, but
potentially a problem). For example:
a. lots of const c
> On Sep 27, 2016, at 2:23 PM, Zachary Turner via lldb-dev
> wrote:
>
>
>
>
> On Tue, Sep 27, 2016 at 1:09 PM Daniel Austin Noland via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 4. All of these classes are "old school" (not necessarily bad, but
> potentially a problem). For examp
On 09/27/2016 03:30 PM, Jim Ingham wrote:
On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev
wrote:
I have been giving study to the private and public classes for
break/watchpoints and I have some ideas for how to improve them. I am looking
for comments from the community on t
On 09/27/2016 03:37 PM, Enrico Granata wrote:
On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev
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_ASSIG
> On Sep 27, 2016, at 2:55 PM, Daniel Austin Noland
> wrote:
>
>>> The main problem here is that Watchpoints & Breakpoints should share the
>>> Options class, and most of the StopInfo DoOnRemoval. I don’t think you’ll
>>> need to write a lot of new code to do this, it’s mostly ripping out th
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
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
> 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 ma
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
> wrote:
>
> Doing it everywhere would be a public service IMO. I don't like macros
> either.
>
>
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 con
> On Sep 27, 2016, at 2:55 PM, Daniel Austin Noland
> wrote:
>
>> Folks on the outside of the SB API’s need to be able to pass callbacks in.
>> We don’t currently have any templates you need to instantiate or classes you
>> need to override to go from outside the SB API to inside it. So wha
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 : privat
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
> On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev
> wrote:
>
> I have been giving study to the private and public classes for
> break/watchpoints and I have some ideas for how to improve them. I am
> looking for comments from the community on this now to avoid wasted work and
> On Sep 27, 2016, at 3:43 PM, Zachary Turner via lldb-dev
> 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 &) = delet
llvm::function_ref is preferable to std::function. It's smaller and faster
while still allowing lambdas, function pointers, and function objects
On Tue, Sep 27, 2016 at 4:35 PM Greg Clayton wrote:
>
> > On Sep 27, 2016, at 3:43 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
19 matches
Mail list logo
