Requesting opinions on CECS (C/C++ Error Control) library for possible boost implementation.
Recently I focused on completing and releasing a public a C/C++ library for C/C++ Error Control System. I've exposed the library to public via two articles in Linked In, and especially in the "C++ Developers Groups" were I got some positive feedback (a few comments and likes). A "Senior Architect at Apple" left the following comment: "Man that’s error traceability for a lot of readability". This made me wonder if this library deserves to be exposed more to C/C++ developers, and led me to think of boost library.
Personally I'm testing the library by integrating it in different projects, and I'm quite happy from the outcome. With very few code (increased readability) and a specific design approach for capturing and handling possible errors, it does provide a lot of customized error traceability - a feature which for me is quite important on complex projects and especially when multiple libraries mix up and need integrated error tracking through all of them.
Reading the boost guidelines I joined this mailing list to request review and opinions.As my free time is a a bit limited to convert and test the library to be supported by boost, I'd like some comments and review first.Do you believe that CECS could be a useful util for Boost? Should I go for it?
Re: Requesting opinions on CECS (C/C++ Error Control) library for possible boost implementation.
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 <[hidden email]> έγραψε: