[lldb-dev] [RFC] Simplifying logging code

[Tamas Berghammer via lldb-dev]

I don't remember to any discussion about it but I might just missed it
(don't see it in the archive either).

>From the efficiency perspective in most of the case evaluating the
arguments for Printf should be very fast (printing local variable) and the
few case where it isn't the case we can keep the condition (using "if
(log.Enabled()) log.Printf(....)"). From readability perspective I think
ignoring the "if (log)" in most of the case won't hurt and it will
eliminate the possibility of missing a check what will cause a crash.

Tamas

On Wed, Aug 12, 2015 at 1:37 PM Colin Riley via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

> From an efficiency perspective, the arguments to Printf will still need to
> be evaluated. Some of those arguments touch multiple areas and will require
> significant effort to change into a new format, which is essentially the
> exact same as we have now.
>
> Was there not a decision to stick with what we have now when this came up
> a few weeks ago? Clean and easy to understand over verbose any day of the
> week in my view.
>
> Colin
>
>
>
> On 12/08/2015 11:52, Tamas Berghammer via lldb-dev wrote:
>
> Hi All,
>
> At the moment logging in LLDB done in the following way:
> Log* log = GetLogIfAllCategoriesSet(...);
> if (log)
>     log->Printf(...);
>
> This approach is clean and easy to understand but have the disadvantage of
> being a bit verbose. What is the general opinion about changing it to
> something like this?
> Logger log = GetLogIfAllCategoriesSet(...);
> log.Printf(...);
>
> The idea would be to return a new type of object from
> GetLogIfAllCategoriesSet with small size (size of a pointer) what will
> check if the log category is enabled. From efficiency perspective this
> change would have no effect and it will simplify the writing of the logging
> statements.
>
> Implementation details:
> Logger would just contain a pointer to a Log object and forward all call
> to that object if that one isn't null. Additionally it will have a method
> to check for nullness of the underlying log object if we want to do some
> calculation only if the logging is enabled.
>
> Thanks,
> Tamas
>
> P.S.: Other possible simplification in the logging system would be to
> use LogIfAllCategoriesSet but it require the specification of the log
> channel at each call and have a very minor overhead because of checking for
> the enabled log categories at each call.
>
>
> _______________________________________________
> lldb-dev mailing listlldb-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> --
> - Colin Riley
> Senior Director,
> Parallel/Graphics Debugger Systems
>
> Codeplay Software Ltd
> 45 York Place, Edinburgh, EH1 3HP
> Tel: 0131 466 0503
> Fax: 0131 557 6600
> Website: http://www.codeplay.com
> Twitter: https://twitter.com/codeplaysoft
>
> This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
> As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
> Company registered in England and Wales, number: 04567874
> Registered office: 81 Linkfield Street, Redhill RH1 6BY
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> 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/20150812/86e3ae89/attachment-0001.html>