Re: [boost] [log] Status (was: Is there any interest in a Group of library like to Application System!)
On Wednesday, January 04, 2012 09:08:16 Renato Tegon Forti wrote:
Hi Andrey,
Thanks for your response! What is status of your lib? Do you need any help?
The library is moving slowly to v2 release. Right now I'm wrapping up bounded async frontends, I intend to finish them by the weekend. Other things left to be done before the release are: - Port filters and formatters to Phoenix v3. As a part of it, improve error messages in exceptions and make filters and formatters not throw by default. - Introduce "default" sink concept to mitigate problems with trivial and advanced logging coexistence. Trivial logging will no longer initialize the library under the hood. - Implement a common attribute registration mechanism to simplify library extension. This should solve problems with settings file parser not recognizing user-defined attribute types. - Update the documentation. There are many other things to be done but they are not showstoppers for the release. Yes, help would be much appreciated, most notably in the porting to Phoenix v3 part. If anyone is willing to help, please contact me privately or through this list.
On 4/01/2012 10:31 PM, Andrey Semashev wrote:
There are many other things to be done but they are not showstoppers for the release.
Out of curiosity, have you considered at some point adding support for the new C++11 user-defined literals? I believe there would be a huge efficiency advantage in having the length of the literal at compile time, rather than having to determine it at run-time.
On Thursday, January 05, 2012 18:49:46 Arash Partow wrote:
Out of curiosity, have you considered at some point adding support for the new C++11 user-defined literals? I believe there would be a huge efficiency advantage in having the length of the literal at compile time, rather than having to determine it at run-time.
There is a tool named basic_string_literal that does it in C++03. Is there something new in C++11 that helps in this area? Could you provide a link to the proposal or a particular section in the standard?
On 5/01/2012 7:08 PM, Andrey Semashev wrote:
On Thursday, January 05, 2012 18:49:46 Arash Partow wrote:
Out of curiosity, have you considered at some point adding support for the new C++11 user-defined literals? I believe there would be a huge efficiency advantage in having the length of the literal at compile time, rather than having to determine it at run-time.
There is a tool named basic_string_literal that does it in C++03. Is there something new in C++11 that helps in this area? Could you provide a link to the proposal or a particular section in the standard?
Is basic_string_literal in the log library? I'll have to look at that, As for c++11 udsl, basically one can define a suffix for a particular type of string, and a corresponding handler operator, which takes a pointer to the literal and a size (length) value - which is determined at compile-time, hence no need for internal calls to strnlen (multipasses) or inefficient loops of pushing 1 char at-a-time to a stream(file, stdout etc..). [section 3.4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2378.pdf
On Thursday, January 05, 2012 20:35:43 Arash Partow wrote:
On 5/01/2012 7:08 PM, Andrey Semashev wrote:
On Thursday, January 05, 2012 18:49:46 Arash Partow wrote:
Out of curiosity, have you considered at some point adding support for the new C++11 user-defined literals? I believe there would be a huge efficiency advantage in having the length of the literal at compile time, rather than having to determine it at run-time.
There is a tool named basic_string_literal that does it in C++03. Is there something new in C++11 that helps in this area? Could you provide a link to the proposal or a particular section in the standard?
Is basic_string_literal in the log library? I'll have to look at that,
Yes, see boost/log/utility/string_literal.hpp.
As for c++11 udsl, basically one can define a suffix for a particular type of string, and a corresponding handler operator, which takes a pointer to the literal and a size (length) value - which is determined at compile-time, hence no need for internal calls to strnlen (multipasses) or inefficient loops of pushing 1 char at-a-time to a stream(file, stdout etc..). [section 3.4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2378.pdf
Interesting, I wasn't aware of this extension. Thanks for the pointer. I'll have to think if and how it can be applied to the library.
On Thursday, January 05, 2012 20:35:43 Arash Partow wrote:
As for c++11 udsl, basically one can define a suffix for a particular type of string, and a corresponding handler operator, which takes a pointer to the literal and a size (length) value - which is determined at compile-time, hence no need for internal calls to strnlen (multipasses) or inefficient loops of pushing 1 char at-a-time to a stream(file, stdout etc..). [section 3.4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2378.pdf
After reading the standard and a few code samples on the net, this looks like an interesting but somewhat dangerous feature. There seem to be no way to specify a namespace for the literal operator, so name clashes are most possible. I could introduce a suffix operator to automatically convert a string literal to a basic_string_literal object, but would that be significantly better than traditional generator functions? string_literal s1 = "abcd"s; vs string_literal s2 = str_literal("abcd"); Note that in the latter case I can specify namespace for the str_literal function while in the former case it's not possible.
Andrey Semashev wrote:
After reading the standard and a few code samples on the net, this looks like an interesting but somewhat dangerous feature. There seem to be no way to specify a namespace for the literal operator, so name clashes are most possible. I could introduce a suffix operator to automatically convert a string literal to a basic_string_literal object, but would that be significantly better than traditional generator functions?
string_literal s1 = "abcd"s;
vs
string_literal s2 = str_literal("abcd");
Note that in the latter case I can specify namespace for the str_literal function while in the former case it's not possible.
It's not dangerous. The way I would do it is provide a macro for logging that appends a suffix to the passed string - perhaps "boost_logxx" etc, the operator itself can be in the boost::log namespace.
On Friday, January 06, 2012 21:40:34 Arash Partow wrote:
Andrey Semashev wrote:
It's not dangerous. The way I would do it is provide a macro for logging that appends a suffix to the passed string - perhaps "boost_logxx" etc, the operator itself can be in the boost::log namespace.
The way I understand it, the operator is found via ADL, so in case of string literals it should be in global namespace. Also, the macro is not any better than the generator function.
2012/1/5 Arash Partow <arash@partow.net>
On 4/01/2012 10:31 PM, Andrey Semashev wrote:
There are many other things to be done but they are not showstoppers for the release.
Out of curiosity, have you considered at some point adding support for the new C++11 user-defined literals? I believe there would be a huge efficiency advantage in having the length of the literal at compile time, rather than having to determine it at run-time.
I don't know about other compilers but gcc can execute strlen in compile time if passed a literal as input. Roman Perepelitsa.
On Thursday, January 05, 2012 10:43:10 Roman Perepelitsa wrote:
2012/1/5 Arash Partow <arash@partow.net>
On 4/01/2012 10:31 PM, Andrey Semashev wrote:
There are many other things to be done but they are not showstoppers for the release.
Out of curiosity, have you considered at some point adding support for the new C++11 user-defined literals? I believe there would be a huge efficiency advantage in having the length of the literal at compile time, rather than having to determine it at run-time.
I don't know about other compilers but gcc can execute strlen in compile time if passed a literal as input.
Yes, but in real life I have only seen examples of such optimization when the code calls strlen inside a function and this function gets inlined. Then the compiler may be smart enough to see that strlen is actually called on a literal and replace it with a constant. I think I also saw this with some recent MSVC but I'm not sure. All in all, this optimization is at compiler's mercy.
participants (3)
-
Andrey Semashev -
Arash Partow -
Roman Perepelitsa