On 08/23/2013 06:28 PM, Gary Willoughby wrote:
> On Thursday, 22 August 2013 at 14:13:29 UTC, Robert Schadek wrote:
>> lots..
>
> Just to weight in and give my four penneth. It needs to be made a little more flexible in the formats it produces (syslog?) and the input it takes. e.g. i've just finished a nice logger for work and it's main usage is like this:
Ask if you are allowed to put it into phobos.
>
> auto logger = new Logger("file");
> logger.info("device id: %s", device.id);
>
> I like the formatting that sprintf gives.
I do as well, but this will lead to template bloat, as many people will
tell you, and log("device id: %s".format(device.id)); is
not so bad.

On Friday, 23 August 2013 at 16:49:00 UTC, Robert Schadek wrote:
>> I like the formatting that sprintf gives.
> I do as well, but this will lead to template bloat, as many people will
> tell you, and log("device id: %s".format(device.id)); is
> not so bad.

I don't think you can bloat a simple logger too much with templates. It's a pretty simple framework.

The problem is that people rarely want to log only strings and not supporting other types will lead to this:

logger.info(format("Device id: %s"), device.id);

as i found when i started logging stuff. yuk!

On 08/23/2013 07:21 PM, Gary Willoughby wrote:
> I don't think you can bloat a simple logger too much with templates. It's a pretty simple framework.
every log call with more than a string will be a template. My first
private logger version was like this.
After reading the last logger thread and other stuff, template bloat
seams to be an important issue.
I will change some stuff tonight and will also make printf style logging
a default. But if anyone screams
template bloat in this thread, I expect you to hunt him down!
>
> The problem is that people rarely want to log only strings and not supporting other types will lead to this:
>
> logger.info(format("Device id: %s"), device.id);
>
> as i found when i started logging stuff. yuk!
my version looked prettier!

On Friday, August 23, 2013 19:21:33 Gary Willoughby wrote:
> I don't think you can bloat a simple logger too much with templates. It's a pretty simple framework.

If __FILE__ and __LINE__ are template arguments to a logging function rather than function arguments (and you can't make __FILE__ and __LINE__ default function arguments if the function is variadic as it would have to be to support format strings), then you get a new template instantation every single time that you call the function, unless you call it more than once on the same line (which you're unlikely to ever do).

I want to think that there's a way to handle this if you get clever, but I can't think of a clever way to get around the problem at the moment.

- Jonathan M Davis

On 8/23/13 4:10 AM, Piotr Szturmaj wrote:
> Just thought that the ability to add user defined log levels may be
> useful too.

(Just hanging this to a random comment in this thread.) I think there's some pretty good work on logging by myself and another poster (Jose?) that has since gone abandoned. It included some nice approach to conditional logging and had both compile-time and run-time configurability.


Andrei

Am Fri, 23 Aug 2013 15:16:05 -0400
schrieb "Jonathan M Davis" <jmdavisProg@gmx.com>:

> On Friday, August 23, 2013 19:21:33 Gary Willoughby wrote:
> > I don't think you can bloat a simple logger too much with templates. It's a pretty simple framework.
> 
> If __FILE__ and __LINE__ are template arguments to a logging function rather than function arguments (and you can't make __FILE__ and __LINE__ default function arguments if the function is variadic as it would have to be to support format strings), then you get a new template instantation every single time that you call the function, unless you call it more than once on the same line (which you're unlikely to ever do).
> 
> I want to think that there's a way to handle this if you get clever, but I can't think of a clever way to get around the problem at the moment.
> 
> - Jonathan M Davis

Make the templated function a stub which redirects to a function which uses normal function arguments and rely on inlining?

On Friday, August 23, 2013 21:47:44 Johannes Pfau wrote:
> Am Fri, 23 Aug 2013 15:16:05 -0400
> 
> schrieb "Jonathan M Davis" <jmdavisProg@gmx.com>:
> > On Friday, August 23, 2013 19:21:33 Gary Willoughby wrote:
> > > I don't think you can bloat a simple logger too much with templates. It's a pretty simple framework.
> > 
> > If __FILE__ and __LINE__ are template arguments to a logging function rather than function arguments (and you can't make __FILE__ and __LINE__ default function arguments if the function is variadic as it would have to be to support format strings), then you get a new template instantation every single time that you call the function, unless you call it more than once on the same line (which you're unlikely to ever do).
> > 
> > I want to think that there's a way to handle this if you get clever, but I can't think of a clever way to get around the problem at the moment.
> > 
> > - Jonathan M Davis
> 
> Make the templated function a stub which redirects to a function which uses normal function arguments and rely on inlining?

Inlining will have no effect on __FILE__ and __LINE__, and it would be a bug if it did, because they're supposed to give the file and line number of the source code, whereas inlining only affects the generated binary.

- Jonathan M Davis

On Fri, Aug 23, 2013 at 03:16:05PM -0400, Jonathan M Davis wrote:
> On Friday, August 23, 2013 19:21:33 Gary Willoughby wrote:
> > I don't think you can bloat a simple logger too much with templates. It's a pretty simple framework.
> 
> If __FILE__ and __LINE__ are template arguments to a logging function rather than function arguments (and you can't make __FILE__ and __LINE__ default function arguments if the function is variadic as it would have to be to support format strings), then you get a new template instantation every single time that you call the function, unless you call it more than once on the same line (which you're unlikely to ever do).
> 
> I want to think that there's a way to handle this if you get clever, but I can't think of a clever way to get around the problem at the moment.
[...]

Hmm. What about:

	void funcImpl(A...)(string file, int line, A args) { ... }
	template func(string file=__FILE__, int line=__LINE__, A...) {
		func(A args) { funcImpl(file, line, args); }
	}

It still has template bloat in that func will be instantiated for every call though, but at least the function body isn't duplicated that many times.


T

-- 
A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen

On 08/23/2013 09:41 PM, Andrei Alexandrescu wrote:
> (Just hanging this to a random comment in this thread.) I think there's some pretty good work on logging by myself and another poster (Jose?) that has since gone abandoned. It included some nice approach to conditional logging and had both compile-time and run-time configurability

Yes I know, but as you said, it got abandoned. So something must have
been wrong.
I rather start something fresh and argue about whats wrong with that,
than argue
whats wrong with something old that has been already argued about and
got abandoned.

On Fri, Aug 23, 2013 at 12:41:45PM -0700, Andrei Alexandrescu wrote: [...]
> (Just hanging this to a random comment in this thread.) I think there's some pretty good work on logging by myself and another poster (Jose?) that has since gone abandoned. It included some nice approach to conditional logging and had both compile-time and run-time configurability.
[...]

Where's the code?


T

-- 
What doesn't kill me makes me stranger.