On 21 April 2013 13:06, Ricardo Fabiano de Andrade <ricardofabianodeandr...@gmail.com> wrote: >> >> I'd avoid ostringstream in anything where performance might be a factor. >> Perhaps some implementations of it are fast enough but in general it is >> rather slow and plain old ssprintf() is generally preferable. > > > I agree and I used snprintf() in my implementation taking advantage of an > existing buffer. Less a couple of copies.
That's the kind of details I suggested to leave to users. >> I unrepentantly hate boolean parameters, they're unreadable and >> inextensible. > > > I'm glad you understood the reason of the options even using the bool > notation. > And you're right they're ugly but honestly, I wrote in the mail what came > first to my mind (what I don't do while coding). +1 >> So I'd rather use either a separate function >> set_log_full_vector_contents(bool) (boolean arguments are fine for the >> functions taking a single parameter only where its meaning is clear) or, if >> we really want to combine everything in a single function call, use some >> logging_options helper class with methods like set_max_length() and >> enable_full_vectors(). > > I must agree. And logging_options class is a nice idea. Some related ideas here :) http://article.gmane.org/gmane.comp.db.soci.user/2340/ To me, logging splits into two main categories: 1) log single tuple (1D list of simple values, either one received or one being sent as use() data) 2) log bulk of tuples (2D, ...) Then, possible configurations covering all/most cases: - no values logged - log single tuple (switched on, by default) - log bulk (if requested explicitly, here we don't care about performance) >> But I also have more semantic concerns about this function. First, I'm not >> sure how useful is it to specify the maximal length in characters. How >> would you decide which length to use here, exactly? > > > As a library developers sometime we face such questions. > No, we really can't specify a valid limit for maximal length in characters. > > But I still think it's valid a solution having all the parameters but > limited to a certain length. > Thinking about it again, the default should be the whole length but user > could be able to limit that (mostly applied to strings). > > If you read Mateusz' last comments on this subject he suggested giving the > user the decision of how to format all this information. > Maybe he's right, I need to make too many assumptions to print a single log > line. I don't want to suggest I'm right. I just say what I'd like as a library user. For instance, I may want to adapt soci::soci_error or soci::error_context as boost::fusion sequence and pass it through boost::spirit::karma to generate errors in JSON format and report it over network :D Not hard-wiring any specific string bashing into SOCI doesn't sound as a difficult thing, but it would give greater flexibility to users. > The idea of a pair soci::converter / soci::backend_converter just crossed my > mind. What those would do? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ soci-devel mailing list soci-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/soci-devel
