Hi Bjorn.

From my POV the Boost.Log is an advanced generic logging utility, while CECS is a "user-friendly" error control utility. That means:

1. CECS integrates error checking and return codes in simplified expressions. Boost.Log doesn't do this. In Boost.log error checking and return codes handling must be done in two extra separated steps. Thus for example in CECS when developer sees a _ERRI() macro he easily understand its purpose; and check easily the condition check and the message. With Boost.Log he do see a classical if() block that incorporates the advanced boost logging (for example in replacement of the classic cout logging). Thus in terms of code readability the CECS is much more friendly. 1.a. That also means - as another significant implementation difference - that CECS must be "integrated" in the C++ code (e.g. can't be just commended out later from code) while Boost.Log is just another library that can be commented out/replaced later. 1.b. This kind of integration also enforces developer to use CECS error logging mechanism everywhere during development covering all possible error cases and increasing everywhere the error readability. With Boost.Log the developer is responsible to additionally put error logs everywhere, increasing significally the written code / decreasing readability. 2. In CECS error information during development (i.e. code-side) is provided in formatted C-style strings (i.e. like printf() arguments). Thus each error log has also it's custom message with descriptive information and either variables values at that time. Boost.Log on the other hand is based on using attributes. Thus typically when the error happens user has to go through attributes to debug the application (e.g. trace back code line numbers), without descriptive information (&variables values) of the error per line number; something that CECS do provide as its main target. Reading about the Boost.Log, I'm not quite sure if its able to do that too, but I have the impression that using custom string literals per error-log its a bit complex - hurts the readability of code. 3. CECS does provide also a simple Signals error tracing mechanism. I.e. in case of SIGSEV CECS can export pre-logged information. In practice, unfortunately I don't have experience using Boost.Log. Thus I'd be curious to see how an experienced Boost developer could have written the C++ example I give in the CECS page using Boost.Log (the one with the FindTheBall() call, that generates 4 possible outcomes). I've the impression that there would be a drop on code readability; and that's the reason I do believe CECS differentiates to Boost.Log and it may indeed be useful to developers. What I do see common among CECS and Boost.Log is the logging mechanism. Both CECS and Boost.Log, logs information. I may guess that a possible quick implementation of Boost.CECS could incorporate the Boost.Log as it's logging mechanism. In that case the Boost.CECS could provide a functions and macros that incorporates the error checking and return code, like _ERR() and _CHECKR_() related macros. Related to the macros with the underscore, their name could be replaced, but should be something that helps to the readability of code. BOOST_ERR() / BOOST_CHECKR_() for example seems as drop of readability to me. Names likes like B_ERR() and B_CHECKR_ seems more acceptable for me (B for BOOST). Στις Τετάρτη, 11 Σεπτεμβρίου 2019, 12:40:06 π.μ. EEST, ο χρήστης Bjorn Reese via Boost <boost@lists.boost.org> έγραψε: On 9/8/19 3:17 PM, Terablade via Boost wrote:

I have also released the library on github:https://github.com/terablade2001/CECS

This library is described as handling "textual informative error control" using severity levels, so the first question that comes to mind is how this differs from Boost.Log? PS: The standard as reserved all symbol names starting with an underscore followed by a capital letter. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost