Re: [boost] Proposal: Add Loki Library's SafeFormat to Boost:

Subject: Re: [boost] Proposal: Add Loki Library's SafeFormat to Boost:
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2008-12-31 09:02:04

Tom Browder wrote:
> The last Loki thread I see here is the one from 2002 discussing adding
> Loki to Boost.

Why would you want to add Loki to Boost?
- One good reason would be to allow boost libraries to rely on Loki libraries. Are there examples where this would be beneficial?
- Another reason might be to reduce overlap between Loki and Boost, thereby enabling clearer recommendations to user as to which library to use for a certain task.

However, the question I'm now asking to you came to my mind earlier when reading an "Interest check on logging library":
http://lists.boost.org/Archives/boost/2008/12/146500.php

The author writes "I know there are two proposed logging libraries out there for Boost, already, but I had a different itch to scratch on a project.", but googling for "c++ logging" showed that there are many mature logging libraries for c++ out there. The interesting thing was that some of the more actively maintained libraries seemed to be associated with some "larger" project already (log4cxx -> http://logging.apache.org/, Pantheios -> http://www.stlsoft.org/), so they were definitely not candidates for a "boost-logging" library.

So I asked myself why one would want to have a special "boost-logging" library, and one good reason I could see was to allow other boost libraries to rely on this library (like they rely on boost-test). One drawback that I could see was that the "boost-logging" library would probably not end up being the fastest logging library out there 
(http://www.pantheios.org/performance.html).
The same will probably be true for the "Boost.Format" library
(http://www.fastformat.org/performance.html).

> I asked Andrei once about doing that specifically for
> the Loki SafeFormat functions (FPrint, Printf, and SPrintf) and he
> said FPrintf wasn't good enough yet.

So what would be the advantages of having Loki's SafeFormat library in boost? Do other boost libraries currently rely on "boost-format" and could rely on "boost-fastformat" instead, if it were part of boost? I don't know, but it should be easy to find out.

What would be the consequences of "cherry-picking" libraries from Loki for inclusion into boost? I don't know, but I somehow have the impression that whether FPrintf is good enough is not the major open question here.

> However, I find all of them very useful and would love to see them
> added to the Boost library

I use both Loki and Boost side by side, and see no problems with this approach. There is some overlap in functionality with respect to "Function objects" and "Smart pointers", but I guess this is just a sign that the stl is lacking in this area.

A strength of Loki is that it is so well designed that it is possible to cherry pick libraries from it. However, actually doing this seems to undermine the continued maintenance of the Loki library. Loki doesn't depend on boost, so as soon as a Loki library would be included into boost, Loki could no longer depend on it (or one would have to come up with a way to avoid conflicts between the same library in boost and in Loki). But this would give the impression that the remaining Loki library is just what wasn't good enough for inclusion into boost.

There must be other ways of coexistence between boost and other library-collections than inclusion of the other library-collection into boost. Perhaps some sort of documentation of library-collections somehow "related" to boost, and some recommendations of how to use them together, maybe also some words about their overlap.

> I know Boost has Format now, but SafeFormat has some advantages over
> Boost.Format, one of which is that FPrintf can be output to C++
> streams as well as to FILE pointers--very handy when one is gradually
> converting legacy code to using C++ streams.  In addition, I find the
> SafeFormat family much easier to use than Boost.Format.

I just took a look at the introduction of the Boost.Format documentation:

The format library provides a class for formatting arguments according to a format-string, as does printf, but with two major differences :

    * format sends the arguments to an internal stream, and so is entirely type-safe and naturally supports all user-defined types.
    * The ellipsis (...) can not be used correctly in the strongly typed context of format, and thus the function call with arbitrary arguments is replaced by successive calls to an argument feeding operator%

You can find more Details in :
...

The line "and naturally supports all user-defined types." makes me wonder how SafeFormat supports user-defined types. On the other hand, this question might be less important than it looks at first sight, and the solution adopted by Boost.Format might give a false sense of security with respect to user-defined types.

> Andrei's original comments regarding FPrintf's shortcomings are here:
>
>   https://sourceforge.net/forum/message.php?msg_id=4525195

This thread doesn't seem to be about inclusion of SafeFormat into boost, but just about how a specific (technical) shortcoming in SafeFormat should be addressed. So I have the impression that Andrei didn't really answer to your question about proposing SafeFormat as a boost library.

> His "Dr. Dobb's Journal" article describing SafeFormat is here:
>
>  http://www.ddj.com/cpp/184401987

That's an interesting article, but I guess I will just use Boost.Format with less reservations now (because its main drawback seems to be that it is slow, but that is totally unimportant for my use-cases). The other valid point is that there is no scanf counterpart. However, scanf is not really my favorite, and parsing input seems to me like a completely different problem from formating output. Does SafeFormat really contains functionality similar for scanf for parsing input?

> Thank you for your consideration.

Thank you for helping to maintain Loki. You should interpret my comments as the comments of a user of both Boost and Loki, who's main concern is to have good and well maintained c++ libraries that help him get his job done.

Regards,
Thomas