[log] Boost Logging Lib v2, 0.9.3
Hi all, I've completed a major update of Boost Log: http://torjo.com/log2/ - added scenarios - allow for fast compiles - updated docs - compiles with gcc 3.4.2 and VC 2005 Feedback is most welcome! Still to do: - update docs (in parts of the docs I use obsolete examples) - use TLS Best, John -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
Hi John, On Tue, Oct 30, 2007 at 01:02:26PM +0200, John Torjo wrote:
I've completed a major update of Boost Log: http://torjo.com/log2/
- added scenarios - allow for fast compiles - updated docs - compiles with gcc 3.4.2 and VC 2005
Feedback is most welcome!
I tried to compile it but noticed many errors. The attached patch fixes a few (g++ 4.3 snapshot and g++ 4.1 used for testing). You include boost/shmem/shmem_named_shared_object.hpp which I do not find in Boost trunk and sandbox. Where can I find this file? Please do not blindly apply the patch but check it carefully. I'm willing to try updated code. PS: I get warning because BOOST_NO_INT64_T and BOOST_NO_INTEGRAL_INT64_T are not defined during compilation: svn/trunk/boost/integer_traits.hpp:164:66: warning: use of C99 long long integer constant Where is it normally defined? Jens
Thanks!
Hi John,
On Tue, Oct 30, 2007 at 01:02:26PM +0200, John Torjo wrote:
I've completed a major update of Boost Log: http://torjo.com/log2/
- added scenarios - allow for fast compiles - updated docs - compiles with gcc 3.4.2 and VC 2005
Feedback is most welcome!
I tried to compile it but noticed many errors. The attached patch fixes a few (g++ 4.3 snapshot and g++ 4.1 used for testing).
You include boost/shmem/shmem_named_shared_object.hpp which I do not find in Boost trunk and sandbox. Where can I find this file?
This was an old library - could be that it's not here anymore - I need to thoroughly check this - I just ported it from the first version of my lib. I will look into this at a later time. So for, now, just an #if 0 altogether ;)
Please do not blindly apply the patch but check it carefully. I'm willing to try updated code.
PS: I get warning because BOOST_NO_INT64_T and BOOST_NO_INTEGRAL_INT64_T are not defined during compilation: svn/trunk/boost/integer_traits.hpp:164:66: warning: use of C99 long long integer constant
I think i solved it ;) I've committed everything to SVN. Note : I've fixed all the issues you found. But I don't have gcc 4.1/4.3 - could you please check that it now compiles fine? Thanks! Best, John template<class msg_type> void write( const msg_type& msg) { convert_dest::write(msg, (*m_out) ); - if ( m_out->ftellg() > m_flags.max_size_bytes()) { + // error: 'struct std::basic_ofstream<char, std::char_traits<char> >' has no member named 'ftellg' *typo ;) should have been tellg() * -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
Hi John, On Tue, Oct 30, 2007 at 04:06:51PM +0200, John Torjo wrote:
On Tue, Oct 30, 2007 at 01:02:26PM +0200, John Torjo wrote:
I've completed a major update of Boost Log: http://torjo.com/log2/
Feedback is most welcome!
I tried to compile it but noticed many errors. The attached patch fixes a few (g++ 4.3 snapshot and g++ 4.1 used for testing).
You include boost/shmem/shmem_named_shared_object.hpp which I do not find in Boost trunk and sandbox. Where can I find this file?
This was an old library - could be that it's not here anymore - I need to thoroughly check this - I just ported it from the first version of my lib. I will look into this at a later time. So for, now, just an #if 0 altogether ;)
OK.
I think i solved it ;) I've committed everything to SVN.
I attached another patch which allows now to properly compile at least each header file (independently) of Boost.Log. I fixed also really many missing includes, maybe you should check now for circular dependencies ... (I recommend graphviz tools). Maybe you don't have to include all files but can add forward declarations? In the sample code you include stdafx.h which includes itself tchar.h. That's no standard C++ file so why you do this? Pleae make all your code portable!
Note : I've fixed all the issues you found.
Except one.
But I don't have gcc 4.1/4.3
NO, this is no true! gcc is Open Source otherwise I would not use it, so you have access to it! To be honest I really wonder why you seem to use a non free system (do you know ReactOS :-?) but OK let's ignore this considering that your library is also Open Source :-) I tested gcc 3.3, 3.4, 4.1, 4.2 and 4.3.
- could you please check that it now compiles fine? Thanks!
With the new patch it works much better. I still need to test the sample code. What's with lib/logging/tests/donot_use? If I really should not use it I suggest you remove it otherwise please rename it (I would also expect it to be called do_not_use instead of donot_use).
template<class msg_type> void write( const msg_type& msg) { convert_dest::write(msg, (*m_out) ); - if ( m_out->ftellg() > m_flags.max_size_bytes()) { + // error: 'struct std::basic_ofstream<char, std::char_traits<char> >' has no member named 'ftellg'
*typo ;) should have been tellg()
No, tellp as m_out is of type ostream!? Be honest, did you really try to compile all your files as well? Since e.g. boost/logging/writer/ts_write.hpp contained not the proper namespace I wonder whether your compiler is indeed so buggy or you just forgot testing some files (which is not a big problem for me as I had some fun that's why). Not sure whether I have the time to port my code to use your new lib instead of the old one. Let's see. PS: Nice to see that you are responsive. Other people still ignore patches I sent them ... Jens
Jens Seidel wrote:
Hi John,
On Tue, Oct 30, 2007 at 04:06:51PM +0200, John Torjo wrote:
On Tue, Oct 30, 2007 at 01:02:26PM +0200, John Torjo wrote:
I've completed a major update of Boost Log: http://torjo.com/log2/
Feedback is most welcome!
I tried to compile it but noticed many errors. The attached patch fixes a few (g++ 4.3 snapshot and g++ 4.1 used for testing).
You include boost/shmem/shmem_named_shared_object.hpp which I do not find in Boost trunk and sandbox. Where can I find this file?
This was an old library - could be that it's not here anymore - I need to thoroughly check this - I just ported it from the first version of my lib. I will look into this at a later time. So for, now, just an #if 0 altogether ;)
OK.
I think i solved it ;) I've committed everything to SVN.
I attached another patch which allows now to properly compile at least each header file (independently) of Boost.Log.
I fixed also really many missing includes, maybe you should check now for circular dependencies ... (I recommend graphviz tools). Maybe you don't have to include all files but can add forward declarations?
In the sample code you include stdafx.h which includes itself tchar.h.
Yes my mistake, sorry - it's already fixed.
Note : I've fixed all the issues you found.
Except one.
But I don't have gcc 4.1/4.3
NO, this is no true! gcc is Open Source otherwise I would not use it, so you have access to it! To be honest I really wonder why you seem to use a non free system (do you know ReactOS :-?) but OK let's ignore this considering that your library is also Open Source :-)
I tested gcc 3.3, 3.4, 4.1, 4.2 and 4.3.
I know it's open source ;) I only have the 3.4.2 version at this time. Most likely I'll get more versions in the future.
- could you please check that it now compiles fine? Thanks!
With the new patch it works much better. I still need to test the sample code. What's with lib/logging/tests/donot_use? If I really should not use it I suggest you remove it otherwise please rename it (I would also expect it to be called do_not_use instead of donot_use).
template<class msg_type> void write( const msg_type& msg) { convert_dest::write(msg, (*m_out) ); - if ( m_out->ftellg() > m_flags.max_size_bytes()) { + // error: 'struct std::basic_ofstream<char, std::char_traits<char> >' has no member named 'ftellg'
*typo ;) should have been tellg()
No, tellp as m_out is of type ostream!?
Yes, right.
Be honest, did you really try to compile all your files as well? Since e.g. boost/logging/writer/ts_write.hpp contained not the proper namespace I wonder whether your compiler is indeed so buggy or you just forgot testing some files (which is not a big problem for me as I had some fun that's why).
I did not compile - the rolling_file is a port from the old version. The thing is I don't have time to do everything ;) It's on my todo list ;) This is true for ts_write.hpp as well - note that I've implemented it, and it's next thing on my todo list - add TLS/test thread-safety.
Not sure whether I have the time to port my code to use your new lib instead of the old one. Let's see.
PS: Nice to see that you are responsive. Other people still ignore patches I sent them ...
Thanks ;) =================================================================== --- boost/logging/format/formatter/defaults.hpp (Revision 40606) +++ boost/logging/format/formatter/defaults.hpp (Arbeitskopie) @@ -24,6 +24,7 @@ #include <boost/logging/detail/fwd.hpp> #include <boost/logging/detail/manipulator.hpp> #include <boost/logging/format/formatter/time.hpp> +#include <sstream> // std::basic_ostringstream #include <stdio.h> Why use <sstream> ? I tried to minimize dependencies. In defaults.hpp there's no need for basic_ostringstream. Note: I've committed all to SVN Best, John -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
On Tue, Oct 30, 2007 at 07:18:57PM +0200, John Torjo wrote:
Jens Seidel wrote:
I attached another patch which allows now to properly compile at least each header file (independently) of Boost.Log.
=================================================================== --- boost/logging/format/formatter/defaults.hpp (Revision 40606) +++ boost/logging/format/formatter/defaults.hpp (Arbeitskopie) @@ -24,6 +24,7 @@ #include <boost/logging/detail/fwd.hpp> #include <boost/logging/detail/manipulator.hpp> #include <boost/logging/format/formatter/time.hpp> +#include <sstream> // std::basic_ostringstream #include <stdio.h>
Why use <sstream> ? I tried to minimize dependencies. In defaults.hpp there's no need for basic_ostringstream.
You're wrong, it is required! I tested with both a recent 4.x gcc version (don't remember what version I used in the last test) and 3.4. (Didn't you see my comment std::basic_ostringstream? Search for this and you will find at least one match in the file!) Try the following program: #include <boost/logging/format/formatter/defaults.hpp> int main() { return 0; } You get without the fix: g++-3.4 -I. -I Boost/svn/trunk/ -Wall -pedantic -Wcast-align -Wpointer-arith -W main.cpp -o all In file included from main.cpp:3: boost/logging/format/formatter/defaults.hpp: In member function `void boost::logging::formatter::idx_t<convert>::operator()(msg_type&) const': boost/logging/format/formatter/defaults.hpp|60| error: no match for 'operator<<' in 'idx << (const boost::logging::char_type*)(boost::logging::ansi_unicode_char_holder("[", "[\000\000\000\000\000\000"))' boost/logging/format/formatter/defaults.hpp|62| error: invalid use of undefined type `struct std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >' /usr/include/c++/3.4/iosfwd|80| error: declaration of `struct std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >' I added also all other errors I get without further includes in the patch to convict you. Please apply the patch (without the comments) it is really save :-) Jens
Jens Seidel wrote:
On Tue, Oct 30, 2007 at 07:18:57PM +0200, John Torjo wrote:
Jens Seidel wrote:
I attached another patch which allows now to properly compile at least each header file (independently) of Boost.Log.
=================================================================== --- boost/logging/format/formatter/defaults.hpp (Revision 40606) +++ boost/logging/format/formatter/defaults.hpp (Arbeitskopie) @@ -24,6 +24,7 @@ #include <boost/logging/detail/fwd.hpp> #include <boost/logging/detail/manipulator.hpp> #include <boost/logging/format/formatter/time.hpp> +#include <sstream> // std::basic_ostringstream #include <stdio.h>
Why use <sstream> ? I tried to minimize dependencies. In defaults.hpp there's no need for basic_ostringstream.
You're wrong, it is required! I tested with both a recent 4.x gcc version (don't remember what version I used in the last test) and 3.4. (Didn't you see my comment std::basic_ostringstream? Search for this and you will find at least one match in the file!)
My mistake ;) I thought it's boost/logging/defaults.hpp . Fixed now. Fixed the rest also. Committed to SVN. Best, John -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
Hi John, after applying the attached patch, Boost.Log (including examples) should be in a good shape, at least related to compiler errors and warnings. On Wed, Oct 31, 2007 at 11:15:28AM +0200, John Torjo wrote:
Fixed the rest also. Committed to SVN.
Thanks. I noticed that you also nearly always increment a version number in the commit log: v0.9.10, 31 oct 2007 There should be no need for this or do you really release a new version multiple times per day? Refering to the revision number is maybe better especially as applying a single patch is often not sufficent to fix a bug properly. A few comments: * Why do you have compiler specific directories such as lib/logging/samples/gcc/ especially as files in it are (nearly) empty? I suggest to drop all kind of platform and compiler specific code from the test and sample files. * Some code evaluates the UNICODE macro to decide whether to use char or wchar. Why? Probably UNICODE is just a wrong name for something which should be called USE_MULTI_BYTE or similar. Unicode is a character set which exist in various encodings. Some encodings such as UTF-8 do not require wchar support at all! * In boost/logging/format/destination/defaults.hpp you use Windows related code to write into a "debug stream" and do nothing on other systems (this raised a warning about code without effect which you added trying to fix a "unused variable" warning). This contradicts with the documentation on other systems so that I changed it to write to std::cout in this case. * Some files are called stdafx.h but documentation refers to either STDAFX.H or StdAfx.h. Every proper operating system is able to use an arbritrary file system (Linux supports at least 30!). Does this mean this is not true for your proprietary system? I thought I read about (optional) support for ext2 or reiserfs filesystems on it as well (which are case sensitive). Why do you not drop stdafx.h. Is it really used? Jens
Hi Jens, Issues fixed and committed, thanks!
in the commit log: v0.9.10, 31 oct 2007 There should be no need for this or do you really release a new version multiple times per day? Refering to the revision number is maybe better especially as applying a single patch is often not sufficent to fix a bug properly.
I just want to track what changes I do - until I reach a version that compiles on gcc 3.4.2, 4.1 and 4.3. After that, there won't be as many comments ;)
A few comments:
* Why do you have compiler specific directories such as lib/logging/samples/gcc/ especially as files in it are (nearly) empty?
Fixed - moved to "internal" directory - not to generate confusion
I suggest to drop all kind of platform and compiler specific code from the test and sample files. * Some code evaluates the UNICODE macro to decide whether to use char or wchar. Why? Probably UNICODE is just a wrong name for something which should be called USE_MULTI_BYTE or similar. Unicode is a character set which exist in various encodings. Some encodings such as UTF-8 do not require wchar support at all!
Yes, not called UNICODE anymore.
* In boost/logging/format/destination/defaults.hpp you use Windows related code to write into a "debug stream" and do nothing on other systems (this raised a warning about code without effect which you added trying to fix a "unused variable" warning). This contradicts with the documentation on other systems so that I changed it to write to std::cout in this case.
done.
* Some files are called stdafx.h but documentation refers to either STDAFX.H or StdAfx.h. Every proper operating system is able to use an arbritrary file system (Linux supports at least 30!). Does this mean this is not true for your proprietary system? I thought I read about (optional) support for ext2 or reiserfs filesystems on it as well (which are case sensitive). Why do you not drop stdafx.h. Is it really used?
removed stdafx. files. Best, John
Jens
------------------------------------------------------------------------
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
At 4:06 PM +0200 10/30/07, John Torjo wrote:
You include boost/shmem/shmem_named_shared_object.hpp which I do not find in Boost trunk and sandbox. Where can I find this file?
This was an old library - could be that it's not here anymore - I need to thoroughly check this - I just ported it from the first version of my lib.
boost.shmem was renamed boost.interprocess as part of review feedback, and is in svn under the new name. There were also lots of API changes. boost.interprocess is one of the new libraries that I think (hope?) will be in boost-1.35.
boost.shmem was renamed boost.interprocess as part of review feedback, and is in svn under the new name. There were also lots of API changes. boost.interprocess is one of the new libraries that I think (hope?) will be in boost-1.35. _______________________________________________
Oh I see ;) Thanks for that. I'll look at that and update it - it's not very high priority, so it might take a while - lots of other TODOs :) Best, John -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
Hi John, Nice to have you back on track. I was looking at your library, because I am developing one myself and I ran in a tricky problem and was wondering how did you solve it. Let's say you have this code: [...] int foo() { LDBG_ << "foo called"; return 42; } [...] int main(int argc, char **argv) { [...] LDBG_ << "foo returned: " << foo(); [...] } How does it behave? Are you using a stack? And how do you handle multi-threading in such case?? You'll tell me: "look at my code", and you would be right :) But just wondering if you though specifically to this pb and if you tackled it so maybe I can get some inspiration from you ;p Thanks JD
Hi all,
I've completed a major update of Boost Log: http://torjo.com/log2/
- added scenarios - allow for fast compiles - updated docs - compiles with gcc 3.4.2 and VC 2005
Feedback is most welcome!
Still to do: - update docs (in parts of the docs I use obsolete examples) - use TLS
Best, John
Hi JD, Note that I have the gather concept (see "Workflow" in the online docs). The gather always happens with a temporary object. Once all data is gathered, it calls the writer's operator()(msg_type& msg). You can choose to make the writer thread safe if you wish. Best, John
Hi John,
Nice to have you back on track. I was looking at your library, because I am developing one myself and I ran in a tricky problem and was wondering how did you solve it.
Let's say you have this code:
[...] int foo() { LDBG_ << "foo called"; return 42; }
[...] int main(int argc, char **argv) { [...] LDBG_ << "foo returned: " << foo(); [...] }
How does it behave? Are you using a stack? And how do you handle multi-threading in such case??
You'll tell me: "look at my code", and you would be right :) But just wondering if you though specifically to this pb and if you tackled it so maybe I can get some inspiration from you ;p
Thanks
JD
-- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
participants (4)
-
JD -
Jens Seidel -
John Torjo -
Kim Barrett