> On Mar 1, 2018, at 10:44 AM, Pavel Labath <lab...@google.com> wrote:
>
> On 1 March 2018 at 10:34, Adrian Prantl <apra...@apple.com> wrote:
>>
>>> On Mar 1, 2018, at 10:25 AM, Jim Ingham <jing...@apple.com> wrote:
>>>
>>> I have no general objections to macros, and reducing boiler-plate is good.
>>> They do get in the way of debugging because of the weird C rule that a
>>> macro has to pretend that it is all one source line, so if they contain
>>> code you are interested in stopping at, there needs to be some other way to
>>> do that. But provided that's taken care of, they are fine.
>>
>> I believe the only thing that needs to be in a macro is the return, and all
>> the other lines could be factored out into a helper function, in which you
>> could then break, and it would reduce code size. Hmm.. if you can factor out
>> the rest into a (templated) function, we probably don't even need to make
>> this a macro:
>>
>> if (takeAndLogError(item))
>> return Error();
>>
>
> The main reason we have these macros is that most or our logging
> statements were doing something like
> log->Printf("MyClassName::%s: blah blah...", __FUNCTION__);
> The idea was that the macro could substitute these automatically (the
> macro can't get at the class name, so it prints the file name instead,
> which is generally close enough).
> If we are fine with not having this source information, then we don't
> need the macros. That said, I think it's useful having information
> about where a particular log message came from..
Thanks, I missed the __FUNCTION__ part! I guess you could still define a
minimal macro as
#define takeAndLogError(ITEM) \
takeAndLogErrorImpl(__FUNCTION__, item)
-- adrian
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
