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:
>
> 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
> 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
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
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
> 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
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
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.
>
>
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
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
> 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
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 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 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: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 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 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 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.
>
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
19 matches
Mail list logo
