More sophisticated logging and error reporting

[Nexus]

In our case we can simply remove the calls to the log system by defining sfLog(message) as nothing.

Of course, that's the whole reason why I'm in favor of a macro

We don't need to change any other function or class of the log system. Thus the API and ABI doesn't differ, all calls to the log system are removed by the preprocessor -> zero overhead.

And what if the preprocessor has an effect to the ABI? I mentioned inline functions, templates are also possible. I'm not saying it's impossible, but as always when dealing with conditional compilation across libraries, we have to be careful.

It's neither obscure nor uncommon

What is it exactly? A link to a list of books is not helpful. I'm assuming you talk about a class (the "enum") that has public static constants (the "enumerators"). This overengineers the situation and introduces its own problems, for example it makes the initialization of the constants dynamic. And yes, this is a very real problem, possibly more than the comparison of different enums.

Anyway, I already said we used enum successfully throughout the SFML API and won't change it only because an authority said so 10 years ago. In SFML 3, we may consider well-known techniques like enum classes

But there are a lot of other logging options out there.  So it's not a big deal if we need to use one of those, or roll one ourselves.

People will have different requirements regarding logging, so it's best if we provide the basic flexibility to plug in other loggers, rather than reinventing one specific wheel within SFML itself.

[Jabberwocky]

People will have different requirements regarding logging, so it's best if we provide the basic flexibility to plug in other loggers, rather than reinventing one specific wheel within SFML itself.

Sounds good to me!

About defining sfLog as a macro which can be preprocessed out to nothing:

In my experience, this doesn't fully solve the problem.  Often, you need to create a string or stringstream and format various information into your log message.  If you really want to preprocess out all costs associated with logging, you need to put your #ifdefs around the entire block including both the log statement, the string(stream) variable, and the formatting / string concatenation calls.

Just #defining the sfLog call to nothing leaves a bunch of these logging perf costs in place.  It may also result in a bunch of unused variable warnings.  Those warnings can be turned off, but it's generally a bad idea to do so, as you might be masking other instances of logic errors in your code.

So, the sfLog macro idea may be less helpful than it might originally seem.

[BurningEnlightenment]

About defining sfLog as a macro which can be preprocessed out to nothing:

In my experience, this doesn't fully solve the problem.  Often, you need to create a string or stringstream and format various information into your log message.  If you really want to preprocess out all costs associated with logging, you need to put your #ifdefs around the entire block including both the log statement, the string(stream) variable, and the formatting / string concatenation calls.

Just #defining the sfLog call to nothing leaves a bunch of these logging perf costs in place.  It may also result in a bunch of unused variable warnings.  Those warnings can be turned off, but it's generally a bad idea to do so, as you might be masking other instances of logic errors in your code.

So, the sfLog macro idea may be less helpful than it might originally seem.

Meh, this is only true if sfLog has no formatting abilities. My updated proof of concept is as flexible as a stringstream (because it uses one under the hood ), can discard the log messages and associated formatting instructions at preprocessing time which guarantees zero overhead and doesn't affect binary compatibility, i.e. the ABI doesn't differ between binaries with and without logging enabled. So, the sfLog macro idea can be as helpful as it originally seems.

We don't need to change any other function or class of the log system. Thus the API and ABI doesn't differ, all calls to the log system are removed by the preprocessor -> zero overhead.

And what if the preprocessor has an effect to the ABI? I mentioned inline functions, templates are also possible. I'm not saying it's impossible, but as always when dealing with conditional compilation across libraries, we have to be careful.

Yes, I agree with you that the preprocessor can affect the ABI, but this is only the case if you use preprocessor magic within exported function/method signatures or class definitions and as my poc shows we don't need to do this, just voiding out the function like sfLog macro suffices and can't affect the ABI at all.

@Nexus regarding enums, etc.: The approach I've taken was recommended by C++ Gurus (Herb Sutter, Scott Meyers, ...) until C++11 solved the problem at language level with enum class, so I consider it as well known. Anyways I won't use SFML, i.e. I'm done with this.

[Jabberwocky]

Meh, this is only true if sfLog has no formatting abilities. My updated proof of concept is as flexible as a stringstream (because it uses one under the hood ), can discard the log messages and associated formatting instructions at preprocessing time which guarantees zero overhead and doesn't affect binary compatibility, i.e. the ABI doesn't differ between binaries with and without logging enabled. So, the sfLog macro idea can be as helpful as it originally seems.

Is it possible to preprocess that out?  What would that look like?  If so, I agree that's a good solution.

[fmatthew5876]

Have you guys considered building something simple ontop of the fmt (formerly cppfmt) library?

https://github.com/fmtlib/fmt

I've used this library in other projects and I can tell you its great to be able to do printf style logging in C++. Its also much faster than iostream (see benchmarks).

[eXpl0it3r]

Seems like a neat library. Re-reading some of the discussion I think came to the conclusion that we should keep things as simple as possible. Adding a whole dependency just for simple output formatting seems a bit too much. Unless that was a general questions to everyone and not directly connected to SFML.