Hello, i'm trying to create a logging library framework. It is my second attempt, the first can be seen at http://www.codeplex.com/flog . There is some documentation in the doc directory that is perhaps worth reading. The first version used boost::iostreams and not very smart locking mechanism in mt environment (in terms of performance mainly), but served more as a verification 'it can be done and it is not that ugly as i thought' than a real library candidate. Now i'd like to focus on performance and code size, so I made a sketch of the next version. It is really small and is rather a model than anything usable, but before I start implementation, I'd like to know opinion of library writers and users - what do you think about the concept? is it worth continuing, or i'd better go doing something better? :) The sketch of the next version can be seen at http://www.codeplex.com/fflog It's meant to be illustration of the interface and it's usage itself. Short summary of the design: User specifies compile-time vector of requested filters that apply to the logged text. Each filter requiring user's input is tagged and when logging function is invoked, the supplied types are checked against expected type, set to filter and later written to a buffer. Buffers are managed by the sink_manager and likely is one of few places that has to be mt-safe, as the rest is on the stack. I thought about some lock-free queues of buffers that are assigned to caller and filled returned back to write. The actual write of the buffer can be performed in dedicated lower-priority thread. Run-time filtering like level or context is possible, but not implemented yet. The main idea can be seen in the 1st version in runtime_filtering.hpp. Again, runtime values are shared among threads, so they have to be protected in mt environment. Many thanks for your attention, Mojmir
On Wed, 04 Jun 2008 17:07:14 +0200, Mojmir Svoboda <mojmir.svoboda@illusionsoftworks.com> wrote: Hi Mojmir,
[...]The first version used boost::iostreams and not very smart locking mechanism in mt environment (in terms of performance mainly), but served more as a verification 'it can be done and it is not that ugly as i thought' than a real library candidate. Now i'd like to focus on performance and code size, so I made a sketch of the next version. It is really small and is rather a model than anything usable, but before I start implementation, I'd like to know opinion of library writers and users - what do you think about the concept? is it worth continuing, or i'd better go doing something better? :)
there is another candidate of what might become an official Boost logging library one day: http://torjo.com/log2/doc/html/index.html You might want to check the logging requirements and also have a look at Windows Event Tracing and Event Logging for some more ideas (as ideally the logging library provides some support for whatever logging standard is used on a platform). Boris
Morning', * Boris <boriss@web.de> [2008-06-07 13:31:00 +0200]:
there is another candidate of what might become an official Boost logging library one day: http://torjo.com/log2/doc/html/index.html
yes, i know of that one... though i have to look closely on the implementation, because most of the features will be the same.
You might want to check the logging requirements and also have a look at
well i am aware of most of the requirements and i think i can deliver them. the question is whether it is worth it, because John's library is good enough already perhaps. this 'going public' thingy is not really 'i do want write logging library right here right now' but more like 'heey, i have this in my drawer and i can make it better than the first version, but does anybody want it?' because i can surely find myself another toy elsewhere.
Windows Event Tracing and Event Logging for some more ideas (as ideally
i don't know anything windows tracing yet, but i know xbox360 one: simple api with lockfree mechanisms (XLFStartLog etc ). I like that.
the logging library provides some support for whatever logging standard is used on a platform).
this is not my priority right now. now i am working with something called buffer manager and something called sink. buffer manager gives me space to write (if any.. of course message will be dropped if there is not) and sink takes ownership of full buffer and does something very blackboxish then: there could be a stdout, stderr, socket with low priority thread, small black hole or a hidden schrodinger's cat reading and not reading the messages at the same time ;) Regards, Mojmir
Hi, Using boost 1.34.1, attempting a simple iteration over a std::list using BOOST_FOREACH and getting various compile errors all linked to mpl as below ****************************************************************************** "This message and any attachments are solely for the intended recipient and may contain confidential and privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." Interactive Transaction Solutions Ltd (2473364 England) Registered Office: Systems House, Station Approach Emsworth PO10 7PW ********************************************************************** Ce message �lectronique contient des informations confidentielles � l'usage unique des destinataires indiqu�s, personnes physiques ou morales. Si vous n'�tes pas le destinataire voulu, toute divulgation, copie, ou diffusion ou toute autre utilisation de ces informations, est interdite. Si vous avez re�u ce message �lectronique par erreur, nous vous remercions d'en avertir son exp�diteur imm�diatement par email et de d�truire ce message ainsi que les �l�ments attach�s. Interactive transaction Solutions SAS- France (RCS Pontoise : 489 397 877) Si�ge social : Parc Saint Christophe, 10, Avenue de l�Entreprise 95865 Cergy-Pontoise Cedex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Excuse me, I'll post all of it this time :) Hi, Using boost 1.34.1, attempting a simple iteration over a std::list using BOOST_FOREACH and getting various compile errors all linked to mpl as below d:\Projects\boost\boost_1_34_1\boost/foreach.hpp(123) : error C3083: 'mpl': the symbol to the left of a '::' must be a type d:\Projects\boost\boost_1_34_1\boost/foreach.hpp(125) : see reference to class template instantiation 'Operations::boost::foreach::is_lightweight_proxy<T>' being compiled which relates to the following code in the header: //////////////////////////////////////////////////////////////////////// /////// // boost::foreach::is_lightweight_proxy // Specialize this for user-defined collection types if they are inexpensive to copy. // This tells BOOST_FOREACH it can avoid the rvalue/lvalue detection stuff. template<typename T> struct is_lightweight_proxy : boost::mpl::false_ { }; I have no idea what mpl is and haven't linked in any new libraries to allow use of foreach. Any ideas what I'm doing wrong? Thanks, Patrick ****************************************************************************** "This message and any attachments are solely for the intended recipient and may contain confidential and privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." Interactive Transaction Solutions Ltd (2473364 England) Registered Office: Systems House, Station Approach Emsworth PO10 7PW ********************************************************************** Ce message �lectronique contient des informations confidentielles � l'usage unique des destinataires indiqu�s, personnes physiques ou morales. Si vous n'�tes pas le destinataire voulu, toute divulgation, copie, ou diffusion ou toute autre utilisation de ces informations, est interdite. Si vous avez re�u ce message �lectronique par erreur, nous vous remercions d'en avertir son exp�diteur imm�diatement par email et de d�truire ce message ainsi que les �l�ments attach�s. Interactive transaction Solutions SAS- France (RCS Pontoise : 489 397 877) Si�ge social : Parc Saint Christophe, 10, Avenue de l�Entreprise 95865 Cergy-Pontoise Cedex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Patrick Loney wrote:
Using boost 1.34.1, attempting a simple iteration over a std::list using BOOST_FOREACH and getting various compile errors all linked to mpl as below
d:\Projects\boost\boost_1_34_1\boost/foreach.hpp(123) : error C3083: 'mpl': the symbol to the left of a '::' must be a type d:\Projects\boost\boost_1_34_1\boost/foreach.hpp(125) : see reference to class template instantiation 'Operations::boost::foreach::is_lightweight_proxy<T>' being compiled
"Operations::boost"?
I have no idea what mpl is and haven't linked in any new libraries to allow use of foreach. Any ideas what I'm doing wrong?
Yes. You've probably done something like this: namespace Operations { #include <boost/foreach.hpp> } Don't do that. You can't scope the BOOST_FOREACH macro to a namespace anyway. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Thank you, should have spotted the Operations:: myself, apologies -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Eric Niebler Sent: 09 June 2008 15:51 To: boost-users@lists.boost.org Subject: Re: [Boost-users] boost::foreach not compiling Patrick Loney wrote:
Using boost 1.34.1, attempting a simple iteration over a std::list using BOOST_FOREACH and getting various compile errors all linked to mpl as below
d:\Projects\boost\boost_1_34_1\boost/foreach.hpp(123) : error C3083: 'mpl': the symbol to the left of a '::' must be a type d:\Projects\boost\boost_1_34_1\boost/foreach.hpp(125) : see reference to class template instantiation 'Operations::boost::foreach::is_lightweight_proxy<T>' being compiled
"Operations::boost"?
I have no idea what mpl is and haven't linked in any new libraries to allow use of foreach. Any ideas what I'm doing wrong?
Yes. You've probably done something like this: namespace Operations { #include <boost/foreach.hpp> } Don't do that. You can't scope the BOOST_FOREACH macro to a namespace anyway. -- Eric Niebler BoostPro Computing http://www.boostpro.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ****************************************************************************** "This message and any attachments are solely for the intended recipient and may contain confidential and privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." Interactive Transaction Solutions Ltd (2473364 England) Registered Office: Systems House, Station Approach Emsworth PO10 7PW ********************************************************************** Ce message �lectronique contient des informations confidentielles � l'usage unique des destinataires indiqu�s, personnes physiques ou morales. Si vous n'�tes pas le destinataire voulu, toute divulgation, copie, ou diffusion ou toute autre utilisation de ces informations, est interdite. Si vous avez re�u ce message �lectronique par erreur, nous vous remercions d'en avertir son exp�diteur imm�diatement par email et de d�truire ce message ainsi que les �l�ments attach�s. Interactive transaction Solutions SAS- France (RCS Pontoise : 489 397 877) Si�ge social : Parc Saint Christophe, 10, Avenue de l�Entreprise 95865 Cergy-Pontoise Cedex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
On Mon, 09 Jun 2008 11:11:31 +0200, Mojmir Svoboda <mojmir.svoboda@illusionsoftworks.com> wrote:
[...]this 'going public' thingy is not really 'i do want write logging library right here right now' but more like 'heey, i have this in my drawer and i can make it better than the first version, but does anybody want it?' because i can surely find myself another toy elsewhere.
While I'm not making the final decision which library is going to be the Boost logging library it might make more sense then to discuss what you think would make your library better than the first version? If the ideas are then implemented in John's or your library is secondary? As John's libary is not finished anyway and as I for example also like some things to be changed new ideas are surely appreciated.
[...]this is not my priority right now. now i am working with something called buffer manager and something called sink. buffer manager gives me space to write (if any.. of course message will be dropped if there is not) and sink takes ownership of full buffer and does something very blackboxish then: there could be a stdout, stderr, socket with low priority thread, small black hole or a hidden schrodinger's cat reading and not reading the messages at the same time ;)
John's library has a concept called destination which sounds like your sink. There is another concept called formatter which, well, formats messages before they are written to the destination. I'm not sure if there is any buffer involved (there is a cache though which can be activated and deactivated at any time if I'm not wrong). In my opinion one of the most important questions is what else can a Boost logging library offer than what we can do today with: clog << "Logging ..."; As we can easily redirect clog or replace it with another stream object where we can control the buffer there must be some added value? Boris
John's library has a concept called destination which sounds like your sink. There is another concept called formatter which, well, formats
oh yes, i call that filters, but are merely appenders.
In my opinion one of the most important questions is what else can a Boost logging library offer than what we can do today with:
clog << "Logging ...";
As we can easily redirect clog or replace it with another stream object where we can control the buffer there must be some added value?
oh, you almost got me there.. i did not considered these << operators when designing. mainly because of their annoying syntax. i am simple man i prefer that one of printf :) (or boost::format) so i took approach more in the style of type-safer printf using variadic templates combined with classic macro-witchery. i have to take a very close look on John's library to find out where lies the differences in interface. perhaps there won't be any. definitely my planned added value is run-time efficiency (with focus multithreaded environment). many thanks for you attention, Mojmir
Mojmir Svoboda wrote:
oh, you almost got me there.. i did not considered these << operators when designing. mainly because of their annoying syntax. i am simple man i prefer that one of printf :) (or boost::format)
Speaking only for myself -- I wouldn't use a logging library that didn't support << operators. For years now I've been in the habit of defining a custom << operator for each important class in my applications. Then I can debug by writing such an object to std::cout -- or to a log file. Or, using std::ostringstream, I can convert to a string representation if I have something more exotic in mind (e.g. output to a debug pane in a GUI). My point is that this single operator<< method suffices for all present cases in which I want to display my new object. Even if a printf-style logging library is extensible using some different mechanism -- why should I bother? I'd just pick a library (or write my own) based on << instead.
* Nat Goodspeed <nat@lindenlab.com> [2008-06-09 09:06:38 -0400]:
Speaking only for myself -- I wouldn't use a logging library that didn't support << operators.
i certainly understand your requirement, but for me it is just another redirection so i (intuitively right now) assume that there is certainly way to behave like you want: i.e. use all your operator<<s. i have to think more about this. regards, mojmir
Nat Goodspeed wrote:
Mojmir Svoboda wrote:
oh, you almost got me there.. i did not considered these << operators when designing. mainly because of their annoying syntax. i am simple man i prefer that one of printf :) (or boost::format)
Speaking only for myself -- I wouldn't use a logging library that didn't support << operators.
In my library's case, it's the user who decides what the logging syntax is. It can be << (default), or you can have your own syntax, like, a % b % c ,etc. Best, John -- http://John.Torjo.com -- C++ expert http://blog.torjo.com ... call me only if you want things done right
On Mon, 09 Jun 2008 14:40:20 +0200, Mojmir Svoboda <mojmir.svoboda@illusionsoftworks.com> wrote:
[...]
In my opinion one of the most important questions is what else can a Boost logging library offer than what we can do today with:
clog << "Logging ...";
As we can easily redirect clog or replace it with another stream object where we can control the buffer there must be some added value? [...]definitely my planned added value is run-time efficiency (with focus multithreaded environment).
The reason why I was mentioning Windows Event Logging and Event Tracing before was that I think a Boost Logging library should somehow support operating-system specific logging standards (or at least make it easy to support them). If a Boost Logging library was just a more efficient implementation of clog, maybe with a built-in mutex for thread-safety, it doesn't really deserve to be called a Boost library? :) For example the idea of a destination concept in John's library is already nice as a destination can be more than a stream (and I think there is even a destination class for syslog in John's code somewhere although I don't see it in the documentation). Boris
* Boris <boriss@web.de> [2008-06-09 15:27:16 +0200]:
The reason why I was mentioning Windows Event Logging and Event Tracing
this is it? http://oreilly.com/catalog/winlog/chapter/ch02.html
before was that I think a Boost Logging library should somehow support operating-system specific logging standards (or at least make it easy to support them).
or like syslog? i tried it few times but was rather disappointed by the performance. this is more like 'hey, something critical happened' than for regular full-blown logging. i wonder if it's better on any platform. of course i will have a look at these, but i do not see any problem as long as the two interfaces are somehow compatible with mine. i know syslog, and it can certainly be integrated into it.
If a Boost Logging library was just a more efficient implementation of clog, maybe with a built-in mutex for thread-safety, it doesn't really deserve to be called a Boost library? :)
it depends. we can always make things complex, but logging is not in most cases.
For example the idea of a destination concept in John's library is already nice as a destination can be more than a stream (and I think there is even a destination class for syslog in John's code somewhere although I don't see it in the documentation).
well destination==sink, formatter==filter and that's it :) we both made the same design decision as it seems. mojmir
participants (6)
-
Boris -
Eric Niebler -
John Torjo -
Mojmir Svoboda -
Nat Goodspeed -
Patrick Loney