search

abumq / easyloggingpp

C++ logging library. It is extremely powerful, extendable, light-weight, fast performing, thread and type safe and consists of many built-in features. It provides ability to write logs in your own customized format. It also provide support for logging your classes, third-party libraries, STL and third-party containers etc.
MIT License
3.75k stars 918 forks source link

Question to the community #485

Open abumq opened 7 years ago

abumq commented 7 years ago

I have a question and this question is for whole community who love Easylogging++

Do you prefer compilable (that can be included in your project) or with compiled shared object where you use linker instead. The reason why I ask is because we are planning a new design of Easylogging++ that is:

  1. Keeping all the existing features especially format and configuration etc. except only few will be removed that are hardly used, like vmodules unless developers want it
  2. Super faster in dispatching logs
  3. Support asynchronous logging for applications who want to support it
  4. Contain even more features like sending logs to socket (or even secure)
  5. Much more thread-safe
  6. Make full use of C++11 features (hence our support for compilers will limit to compilers that fully support C++11)

So we planning to separate files for easy pull requests and having a single entry point for user (easylogging++.h) (keeping as much backward-compatibility as possible)

Branch for this is called new @madphysicist @aparajita @adah1972

adah1972 commented 7 years ago

I am comfortable with the current model, and the monolithic header file is kind of a uniqueness in easylogging++. If you change the model, does it mean all features will be compiled in by default, and users need to use more options and configuration items to replace the current compile-time macros? (If yes, then all is good; otherwise we probably need to check more details.)

I do not use vmodules, and the change list looks good to me. I never had a success with asynchronous logging. I also suppose the new model may accelerate compilation a little bit. So overall the benefits outweigh the shortcomings (mainly more complicated deployment, and the troubles about library versioning too, I suppose).

adah1972 commented 7 years ago

To answer your question directly, I am neutral. I think other features may matter more.

aparajita commented 7 years ago

Going forward I think you have to do this if you want to make it easier for others to contribute. And definitely require C++11, it's such a huge improvement.

As long as there is a simple build system to create a static or dynamic lib, a more granular design will be a big win. You (and others) can provide pre-built libs as well.

madphysicist commented 7 years ago

While having a single header file was a nice selling point, having a small compiled library is fine too. I a definitely on-board with all the new features.

moneromooo-monero commented 7 years ago

All other things being equal, my preference goes to having a separate library, as it means some of the stuff is already compiled once, and so doesn't have to recompiled for every single other translation unit, slowing things down at every compile.

This doesn't necessarily need to take the form of an installable shared library, maybe a separate source file that one can add to their own project's source files is enough.

Thread safety is a must.

romariorios commented 7 years ago

maybe a separate source file that one can add to their own project's source files

Making a static library (instead of a shared one) also could work.

abumq commented 7 years ago

@moneromoo-monero separate source file is already done and its thread safety is also reliable