Should boost log be accepted into the boost library? My vote is no. This library will just reinforce boost's reputation as being a repository of needlessly complicated highly templatized libraries for relatively easy programming tasks. I don't mind this added complexity when it comes to genuinely difficult problem spaces. In my view, however, logging is not one of those problem spaces. Logging is one of those things that if it takes longer than 10 minutes to read the documentation and get up to speed, it will not get used. What is your evaluation of the design? Very much in the spirit of a typical boost library. However, it has very little attention to "C" interfaces and makes heavy use of templates. I suppose because this is boost, that that is acceptable. However, boost and the c++ community at large should start moving towards a more friendly attitude towards a "C" style api for utility libraries. Most non-boost c++ developers will dismiss this library out of hand, not because its a bad library, its not, it's just more of the same. Heavy handed use of templates. I guess I've spent too much time over the last 5 years ripping out poorly conceived heavily templated code. The thought of adding to this madness, with another utility library that is burdened by templates is hard to swallow. What is your evaluation of the documentation? Good What is your evaluation of the potential usefulness of the library? Logging is useful. Yes. Did you try to use the library? With what compiler? Did you have any problems? Yes. GCC++. No problems How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 2 hours Are you knowledgeable about the problem domain? Yes. I was the review wizard for three years and have followed the progression of boost from the beginning, Tom Brinkman
On Sunday 14 March 2010 07:21:08 Tom Brinkman wrote:
Should boost log be accepted into the boost library?
My vote is no.
This library will just reinforce boost's reputation as being a repository of needlessly complicated highly templatized libraries for relatively easy programming tasks.
I don't mind this added complexity when it comes to genuinely difficult problem spaces. In my view, however, logging is not one of those problem spaces.
Logging is one of those things that if it takes longer than 10 minutes to read the documentation and get up to speed, it will not get used.
What is your evaluation of the design?
Very much in the spirit of a typical boost library.
However, it has very little attention to "C" interfaces and makes heavy use of templates.
I suppose because this is boost, that that is acceptable. However, boost and the c++ community at large should start moving towards a more friendly attitude towards a "C" style api for utility libraries.
Most non-boost c++ developers will dismiss this library out of hand, not because its a bad library, its not, it's just more of the same. Heavy handed use of templates.
Tom, can you list some areas where templates are overused by the library? I imagine it will not be possible to rip those usage, but probably simpler alternatives can be provided. - Volodya
On 03/14/2010 07:21 AM, Tom Brinkman wrote:
I don't mind this added complexity when it comes to genuinely difficult problem spaces. In my view, however, logging is not one of those problem spaces.
The conversations on this list and the diversity of requirements clearly show that logging is not a simple and straightforward thing.
Logging is one of those things that if it takes longer than 10 minutes to read the documentation and get up to speed, it will not get used.
Did you look in the Tutorial? First thing there is the "trivial" logging, which involves one header and one macro. Looks as trivial as it can ever get to me.
What is your evaluation of the design?
Very much in the spirit of a typical boost library.
However, it has very little attention to "C" interfaces and makes heavy use of templates.
Boost is a collection of C++ libraries. Boost.Log is a C++ library. If you're looking for C, you're looking in the wrong place, IMHO. Also, I second the question Vladimir asked. What are the particular places with excess use of templates are you referring to?
You coud probably fix all my concerns by adding something like the following. Notice that there are no macros, no templates, its header file only and it does not require any other boost libraries. Usage: boost::error("An Error has occured: %s\n", "Put message here"); namespace boost::log { static void error (const char *format, ...) { va_list args; va_start (args, format); boost::log (LOG_DOMAIN, LOG_LEVEL_ERROR, format, args); va_end (args); for(;;) ; } static void message (const char *format, ...) { va_list args; va_start (args, format); boost::log (LOG_DOMAIN, LOG_LEVEL_MESSAGE, format, args); va_end (args); } static void critical (const char *format, ...) { va_list args; va_start (args, format); boost::log (LOG_DOMAIN, LOG_LEVEL_CRITICAL, format, args); va_end (args); } static void warning (const char *format, ...) { va_list args; va_start (args, format); boost::log (LOG_DOMAIN, LOG_LEVEL_WARNING, format, args); va_end (args); } static void debug (const char *format, ...) { va_list args; va_start (args, format); boost::log (LOG_DOMAIN, LOG_LEVEL_DEBUG, format, args); va_end (args); } }
On 03/14/2010 09:50 PM, Tom Brinkman wrote:
You coud probably fix all my concerns by adding something like the following.
Notice that there are no macros, no templates, its header file only and it does not require any other boost libraries.
Usage: boost::error("An Error has occured: %s\n", "Put message here");
I'd say that interface is very limited and unsafe. But if you like it, you can write a wrapper header around Boost.Log in the following style: void error (const char *format, ...) { va_list args; va_start (args, format); char buf[1024]; vsnprintf(buf, sizeof(buf), format, args); va_end (args); BOOST_LOG_TRIVIAL(error) << buf; }
Nothing unsafe about a "C" style interface. This technique is used by thousands of applications. If you dont provide a "c" style logging interface, this library will be very limited in its use. Please dont think that because this is boost, your limited to only c++ techniuques. I'm concerned about boost. It is becoming more and more irrelevent. Boost developers need to "wake up" and also address the needs of those developers who don't like heavy templated libraries. As is, this library will scare off most developers. Sorry, but I have to be blunt. On Sun, Mar 14, 2010 at 12:10 PM, Andrey Semashev <andrey.semashev@gmail.com
wrote:
On 03/14/2010 09:50 PM, Tom Brinkman wrote:
You coud probably fix all my concerns by adding something like the following.
Notice that there are no macros, no templates, its header file only and it does not require any other boost libraries.
Usage: boost::error("An Error has occured: %s\n", "Put message here");
I'd say that interface is very limited and unsafe. But if you like it, you can write a wrapper header around Boost.Log in the following style:
void error (const char *format, ...) { va_list args; va_start (args, format);
char buf[1024]; vsnprintf(buf, sizeof(buf), format, args);
va_end (args);
BOOST_LOG_TRIVIAL(error) << buf;
} _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 03/14/2010 10:32 PM, Tom Brinkman wrote:
Nothing unsafe about a "C" style interface. This technique is used by thousands of applications.
Ellipsis is not safe. Neither in C, nor in C++. It's wide spread in C because there is no alternative, not because it's superior.
If you dont provide a "c" style logging interface, this library will be very limited in its use.
Please dont think that because this is boost, your limited to only c++ techniuques.
C users can create wrappers around the library, if there is interest in it. I mostly program in C++ and thus have little interest in providing such a wrapper.
As is, this library will scare off most developers.
I disagree. And you haven't specified the concrete parts of the library that look scary.
Nothing unsafe about a "C" style interface. This technique is used by thousands of applications.
Tom, The printf style parameters is responsible for thousands and thousands of security vulnerabilities. The problem is that you put the burden of sanitizing the parameters on the programmer, not the library. If one zero-terminal disappear, you open Pandora's box. That's just an example. What happens when the programmer replaces a string by an int and forgets to update the parameters? I really don't think in 2010 it's sound to encourage that kind of API. I would rather prefer something like this: boost::error("The error " << error_code << " occurred: " << error_message << std::endl); Regards. -Edouard __________ Information from ESET NOD32 Antivirus, version of virus signature database 4944 (20100314) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
The printf style parameters is responsible for thousands and thousands of security vulnerabilities.
Just plain wrong.
I really don't think in 2010 it's sound to encourage that kind of API.
Also wrong. "C" style api's are the standard, even in C++ applications. Utility libraries should written to that standard. As logging is a utility library, it should be written to that standard. I also am a long time C++ developer, and sympothize with your c++ bias. C++ developers need to write their api's in a way that is also "C" friendly. Thats even more true for utility libraries.
Tom Brinkman wrote:
Just plain wrong.
What about arguments then ?
wrong. "C" style api's are the standard, even in C++ applications.
Which comittee decided that ? When I do C++, I do C++. If I need C API, then I write C
C++ developers need to write their api's in a way that is also "C" friendly. Thats even more true for utility librarie Except sometimes we can't because C lack type safety and tons of proper, strongly typed language feature.
-- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
wrong. "C" style api's are the standard, even in C++ applications.
Its the established practice. Sorry if your experience is different. Modern C++ is losing its pull around here. (Silicon Valley) Very few projects use it any more. By modern, I mean Boost style and heavy templates. Most of my recent projects have consisted of ripping out templated code and replacing it with "C" friendly "API's". I still prefer C++ for most tasks. However, I like to wrap them in "C" api's so others can use them. Using stream operators or std::string in a public API is a absolutly horrible thing to do around here. Those C++ developers that develop in isolation probably have not experienced this push back. I understand. I sympothize. It just doesnt make any sense to write a utility library for general purpose use that only addresses the needs of boost style C++ developers. The core of the library needs to be written in a way that all C/C++ developers can use it. Fine, if you want to write a wrapper around the core with some fancy C++ technique go for it. On Sun, Mar 14, 2010 at 1:24 PM, joel falcou <joel.falcou@lri.fr> wrote:
Tom Brinkman wrote:
Just plain wrong.
What about arguments then ?
wrong. "C" style api's are the standard, even in C++ applications.
Which comittee decided that ? When I do C++, I do C++. If I need C API, then I write C
C++ developers need to write their api's in a way that is also "C"
friendly. Thats even more true for utility librarie
Except sometimes we can't because C lack type safety and tons of proper, strongly typed language feature.
-- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Tom Brinkman wrote:
Its the established practice. Sorry if your experience is different.
Modern C++ is losing its pull around here. (Silicon Valley) Very few projects use it any more. By modern, I mean Boost style and heavy templates.
Good for you, but one tree != one forest. BUilding generalities from local samples is a no-go. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
NOTE: is this not slightly OT? I ask and then I immediately continue on this dreaded path. This has nothing to do with the style of API's that C++ applications use or expect, it is about the simple fact that the interactive language of choice between libraries and components in the "native" world "around there" (SV) is C, not C++. So, what you are saying is that "around there", people prefer to use one "glue" language, C, to another one, and that the glue will affect all code to make it less "extreme/templated"? That is fine, and a loss for those companies, in my humble opinion. Well, well, you cannot win them all, most developers will feel more comfortable in C or Java than in "heavier" languages like C++ (not "C plus some strange syntax to support MFC") or Scala. So, should we give up this nonsense of expressing our solutions in powerful languages (with abstractions fitting the more experienced formalist) and just use C and Java? PS Yes, I know we have had this discussion before, where some people got a bit upset by my elitist view of C++, and instead argued that C++ can be made for everyone, or that it should be a goal to address as many developers as possible with our Boost efforts. Only that elusive entity addressed to in some of our signatures will ever really know. /David On Mar 14, 2010, at 4:38 PM, Tom Brinkman wrote:
wrong. "C" style api's are the standard, even in C++ applications.
Its the established practice. Sorry if your experience is different.
Modern C++ is losing its pull around here. (Silicon Valley) Very few projects use it any more. By modern, I mean Boost style and heavy templates.
Most of my recent projects have consisted of ripping out templated code and replacing it with "C" friendly "API's".
I still prefer C++ for most tasks. However, I like to wrap them in "C" api's so others can use them. Using stream operators or std::string in a public API is a absolutly horrible thing to do around here.
Those C++ developers that develop in isolation probably have not experienced this push back. I understand. I sympothize.
It just doesnt make any sense to write a utility library for general purpose use that only addresses the needs of boost style C++ developers. The core of the library needs to be written in a way that all C/C++ developers can use it.
Fine, if you want to write a wrapper around the core with some fancy C++ technique go for it.
On Sun, Mar 14, 2010 at 1:24 PM, joel falcou <joel.falcou@lri.fr> wrote:
Tom Brinkman wrote:
Just plain wrong.
What about arguments then ?
wrong. "C" style api's are the standard, even in C++ applications.
Which comittee decided that ? When I do C++, I do C++. If I need C API, then I write C
C++ developers need to write their api's in a way that is also "C"
friendly. Thats even more true for utility librarie
Except sometimes we can't because C lack type safety and tons of proper, strongly typed language feature.
-- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Most of my recent projects have consisted of ripping out templated code and replacing it with "C" friendly "API's".
I still prefer C++ for most tasks. However, I like to wrap them in "C" api's so others can use them. Using stream operators or std::string in a public API is a absolutly horrible thing to do around here.
Few points: Indeed "C" API is much nicer in terms of shortness and usability but: 1. It is limited to basic types only. In comparison: debug_log("player position (%f,%f,%f)",pos.x,pos.y,pos.z) or debug_log() << format("player position %1%") % pos. This makes the difference. Yes, templates are heavy, bloated hard to compile and to be honest... I quite hate to use heavily "templated" libraries (see ASIO awesome piece of software that drives me crazy when it comes to compilation times). But... Once C++0x comes things would be simpler and faster at least in printf like cases. For a long time period I preferred C style printfs, but now I use boost::format like API anywhere even it costs me a lot in terms of compilation times. Why? Flexibility that "C" API does not have. Same for Boost.Locale I created iostreams based `boost::locale::format` because it is much more powerful. So... 1. Yes iostreams heavy bloated and requires endless compilation times. 2. But iostreams are so much flexible that it worth it. Take a look on what can be done with iostreams in Boost.Locale... Quite amazing things. Artyom
So, what you are saying is that "around there", people prefer to use one "glue" language, C, to another one, and that the glue will affect all code to make it less "extreme/templated"?
Yeah, thats about it. "C" is the glue language that everyone can use. Like it or hate it, its still around, and still the most popular language for the widest variety of programming tasks. Although, for the most part, I still prefer boost style "C++" for my own projects where I have full control of the code. When it comes to being a library writer, you need to understand your intended audience. If it is the intent of the library author to limit his users to a small subset of C/C++ developers, that is is his choice, of course. I would perfer that boost developers think bigger and target a larger audience.
______ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 03/15/2010 12:42 AM, Tom Brinkman wrote:
So, what you are saying is that "around there", people prefer to use one "glue" language, C, to another one, and that the glue will affect all code to make it less "extreme/templated"?
Yeah, thats about it. "C" is the glue language that everyone can use. Like it or hate it, its still around, and still the most popular language for the widest variety of programming tasks.
Although, for the most part, I still prefer boost style "C++" for my own projects where I have full control of the code.
When it comes to being a library writer, you need to understand your intended audience. If it is the intent of the library author to limit his users to a small subset of C/C++ developers, that is is his choice, of course.
I would perfer that boost developers think bigger and target a larger audience.
Guys, please, move the flame wars of C vs. C++ to another topic. I've expressed my point regarding Boost.Log rather clearly.
On Mar 14, 2010, at 6:04 PM, Andrey Semashev wrote:
On 03/15/2010 12:42 AM, Tom Brinkman wrote:
So, what you are saying is that "around there", people prefer to use one "glue" language, C, to another one, and that the glue will affect all code to make it less "extreme/templated"?
Yeah, thats about it. "C" is the glue language that everyone can use. Like it or hate it, its still around, and still the most popular language for the widest variety of programming tasks.
Although, for the most part, I still prefer boost style "C++" for my own projects where I have full control of the code.
When it comes to being a library writer, you need to understand your intended audience. If it is the intent of the library author to limit his users to a small subset of C/C++ developers, that is is his choice, of course.
I would perfer that boost developers think bigger and target a larger audience.
Guys, please, move the flame wars of C vs. C++ to another topic. I've expressed my point regarding Boost.Log rather clearly.
It is actually more relevant that a "flame war." We are discussing how a log API should look to be most useful (in terms of depth and width), and that discussion pertains to all (new) libraries of Boost: do we want them to be used by the larger C populace? How much are we ready to sacrifice in expressivity (or succinctness) in order to widen our target? Should we have C wrappers for the most "utilitarian" libraries, such as a log library? My point is that Boost is a C++ library and should not care at all about the impact on C developers, or people who happen to be used to that "glue language," even for their C++ development. I still think it is a valid discussion to have. /David
On 14 March 2010 15:21, Tom Brinkman <reportbase2007@gmail.com> wrote:
The printf style parameters is responsible for thousands and thousands of security vulnerabilities.
Just plain wrong.
Some evidence for your position would be good, since it's trivial to find documentation of holes from printf-style parameters: http://en.wikipedia.org/wiki/Format_string_attack
On Sunday 14 March 2010 23:37:06 Scott McMurray wrote:
On 14 March 2010 15:21, Tom Brinkman <reportbase2007@gmail.com> wrote:
The printf style parameters is responsible for thousands and thousands of security vulnerabilities.
Just plain wrong.
Some evidence for your position would be good, since it's trivial to find documentation of holes from printf-style parameters: http://en.wikipedia.org/wiki/Format_string_attack
I don't think that's hole from printf-style parameters. By reading that page it's trivial to notice that it's the %n format specifier -- which actually writes something into program -- is the key component of attack. Clearly a printf-like function that does not support any way to modify program state is safe. Am I missing something? Thanks, Volodya
On 03/15/2010 12:50 AM, Vladimir Prus wrote:
On Sunday 14 March 2010 23:37:06 Scott McMurray wrote:
On 14 March 2010 15:21, Tom Brinkman<reportbase2007@gmail.com> wrote:
The printf style parameters is responsible for thousands and thousands of security vulnerabilities.
Just plain wrong.
Some evidence for your position would be good, since it's trivial to find documentation of holes from printf-style parameters: http://en.wikipedia.org/wiki/Format_string_attack
I don't think that's hole from printf-style parameters. By reading that page it's trivial to notice that it's the %n format specifier -- which actually writes something into program -- is the key component of attack. Clearly a printf-like function that does not support any way to modify program state is safe. Am I missing something?
You do understand that the use of ellipsis is error-prone, even if it doesn't lead to program modification, do you? It is common knowledge that sprintf-like functions are often misused, which results in buffer overruns or incorrect arguments being passed. In C++, the problem of accidental passing of non-POD typed arguments is added.
On Monday 15 March 2010 01:10:10 Andrey Semashev wrote:
On 03/15/2010 12:50 AM, Vladimir Prus wrote:
On Sunday 14 March 2010 23:37:06 Scott McMurray wrote:
On 14 March 2010 15:21, Tom Brinkman<reportbase2007@gmail.com> wrote:
The printf style parameters is responsible for thousands and thousands of security vulnerabilities.
Just plain wrong.
Some evidence for your position would be good, since it's trivial to find documentation of holes from printf-style parameters: http://en.wikipedia.org/wiki/Format_string_attack
I don't think that's hole from printf-style parameters. By reading that page it's trivial to notice that it's the %n format specifier -- which actually writes something into program -- is the key component of attack. Clearly a printf-like function that does not support any way to modify program state is safe. Am I missing something?
You do understand that the use of ellipsis is error-prone, even if it doesn't lead to program modification, do you?
Error prone in what way? That you can pass integer for %s and get garbage? Well, good compilers tend to help: a.c:12: warning: format ‘%s’ expects type ‘char*’, but argument 2 has type ‘int’ And even without compiler help, a tradeoff between convenience and accidental bug is a valid tradeoff. Saying that elipsis is a no-no seems a bit too much.
It is common knowledge that sprintf-like functions are often misused, which results in buffer overruns
Uhm. You cannot have buffer overrun if you don't have a buffer, don't you think? I don't think anybody suggests that boost.log sprintfs anything into a fixed-size buffer.
or incorrect arguments being passed. In C++, the problem of accidental passing of non-POD typed arguments is added.
For all I know, there's no such problem: a.c:19: warning: cannot pass objects of non-POD type ‘struct S’ through ‘...’; call will abort at runtime Of course, some folks ignore warnings, but well, they probably have bigger problems. - Volodya
On 03/15/2010 01:34 AM, Vladimir Prus wrote:
On Monday 15 March 2010 01:10:10 Andrey Semashev wrote:
On 03/15/2010 12:50 AM, Vladimir Prus wrote:
On Sunday 14 March 2010 23:37:06 Scott McMurray wrote:
On 14 March 2010 15:21, Tom Brinkman<reportbase2007@gmail.com> wrote:
The printf style parameters is responsible for thousands and thousands of security vulnerabilities.
Just plain wrong.
Some evidence for your position would be good, since it's trivial to find documentation of holes from printf-style parameters: http://en.wikipedia.org/wiki/Format_string_attack
I don't think that's hole from printf-style parameters. By reading that page it's trivial to notice that it's the %n format specifier -- which actually writes something into program -- is the key component of attack. Clearly a printf-like function that does not support any way to modify program state is safe. Am I missing something?
You do understand that the use of ellipsis is error-prone, even if it doesn't lead to program modification, do you?
Error prone in what way? That you can pass integer for %s and get garbage? Well, good compilers tend to help:
a.c:12: warning: format ‘%s’ expects type ‘char*’, but argument 2 has type ‘int’
And even without compiler help, a tradeoff between convenience and accidental bug is a valid tradeoff. Saying that elipsis is a no-no seems a bit too much.
As I said, I understand its usage in C, because there's no other choice there. But in C++ we have better alternatives, ignoring which in favor of ellipsis seems not wise to me.
It is common knowledge that sprintf-like functions are often misused, which results in buffer overruns
Uhm. You cannot have buffer overrun if you don't have a buffer, don't you think? I don't think anybody suggests that boost.log sprintfs anything into a fixed-size buffer.
Are you implying that I'd have to reimplement sprintf in Boost.Log? Looks like a futile job to me.
or incorrect arguments being passed. In C++, the problem of accidental passing of non-POD typed arguments is added.
For all I know, there's no such problem:
a.c:19: warning: cannot pass objects of non-POD type ‘struct S’ through ‘...’; call will abort at runtime
Of course, some folks ignore warnings, but well, they probably have bigger problems.
Well, I don't render that point valid. In our company we develop under Windows, and MSVC doesn't give such warnings. Only GCC under Linux does, but many developers simply don't look at it since it compiles. You can argue it's our problem, but I'd say it's the problem with the API, if it allows such errors to slip silently. Warnings are just an attempt (only partially successful) to solve the problems by some particular compiler vendors. I, as a lib developer, cannot rely on that the users of my lib will be using one of those "right" compilers.
or incorrect arguments being passed. In C++, the problem of accidental passing of non-POD typed arguments is added.
For all I know, there's no such problem:
a.c:19: warning: cannot pass objects of non-POD type ‘struct S’ through ‘...’; call will abort at runtime
Of course, some folks ignore warnings, but well, they probably have bigger problems.
Well, I don't render that point valid. In our company we develop under Windows, and MSVC doesn't give such warnings. Only GCC under Linux does, but many developers simply don't look at it since it compiles.
Having just encountered that warning for the first time while moving some MSVC code to GCC, I strongly request that the library not emit that particular warning. In my situation, the offending code compiled but crashed 100% of the time. - Rhys
AMDG Tom Brinkman wrote:
You coud probably fix all my concerns by adding something like the following.
Notice that there are no macros, no templates, its header file only and it does not require any other boost libraries.
It can also cause technical ODR violations if used in another header.
Usage: boost::error("An Error has occured: %s\n", "Put message here");
namespace boost::log { static void error (const char *format, ...); static void message (const char *format, ...); static void critical (const char *format, ...); static void warning (const char *format, ...); static void debug (const char *format, ...); }
In Christ, Steven Watanabe
participants (10)
-
Andrey Semashev -
Artyom -
David Bergman -
Edouard A. -
joel falcou -
Rhys Ulerich -
Scott McMurray -
Steven Watanabe -
Tom Brinkman -
Vladimir Prus