On Mon, Aug 15, 2011 at 19:49, Christopher Jefferson <chris@bubblescope.net>wrote:
[...] Is worrying about high efficiency, and lack of copying, in program_options really that important? I would prefer the simplest possible interface, even if it has some small inefficiencies.
This is not about program_options, it's about passing strings in general. It's just this issue came up in this thread, so I proposed it here. On Mon, Aug 15, 2011 at 22:33, Gabriel Redner <gredner@gmail.com> wrote:
Hi Yakov,
It's not just for saving typing, it's for making the interface more generic. Consider the following: <snip> Ok, so the above is longer than the first because we didn't define a nice interface of str_ref yet, but it demonstrated the generality.
This is all true, but it's important to keep in mind our use cases. In general, these APIs will be called with string literals. The next-most-common case is for them to be called with std::strings, and other cases are even less likely. So it seems best to do the simplest thing possible which covers the common cases and does not rule out the uncommon ones.
There are dozens of other string classes people use. If anyone could map his contiguous storage string with compatible encoding to str_ref, it could simplify things greatly.
Note that the most general way is to use templates accepting any Range of chars, just as boost string algorithms do. But this is not good for separate compilation, so the above is the best compromise of efficiency, separate compilation and generality we can get.
Your compromise is missing one factor - simplicity. This is a simple API which does a simple job. Decorating it with generic tools will make it harder to understand and to maintain, in exchange for some small benefit in uncommon use cases.
Once str_ref is implemented, it makes everything else simpler. So I think that in the end things are getting simpler. Also In any case, it's Vladimir's library, so he has the last word on this.
This is not just about this library. It's relevant to interprocess too, for example. On Mon, Aug 15, 2011 at 23:25, Olaf van der Spek <ml@vdspek.org> wrote:
[...] This isn't the only lib that takes string references. It'd be nice to solve this properly once and for all.
Exactly! Yet I must admit that I have a very little experience with my own proposal. I used it successfully in compiler application where passing references to the original strings allowed one cheaply (and lazily) compute the source of an error. -- Yakov