[format] Any interest in decoupling it from std::basic_string?
I.e. such that alternative string implementations could be used (GCC's vstring, boost's...). I've attempted two methods, both pretty simple. First is to simply template basic_format on the string type and propagate that change throughout the library (including similar for the altstream/stringbuf classes). Second was to add a template template parameter for the string, e.g.: template <class Ch, class Tr, class Alloc, template <typename, typename, typename> class StringT = std::basic_string> class basic_format; and propagate that. I would assume the first method is definitely out due to breaking the interface (especially the altstream classes which I would guess are supposed to look like the std ones). I've not looked at whether something such as templatizing the str() method on the string implementation is possible, as either of the above is sufficient for my own purposes and trivial which I suspect a templatized str() wouldn't be... Anyway, if there's any interest I can post a patch for either or both and if not continue using the first method (simpler diff from the original)! Best regards Luke Elliott.
On Mon, Jul 2, 2012 at 1:59 PM, news.gmane.org <lukester_null@yahoo.co.uk> wrote:
I've not looked at whether something such as templatizing the str() method on the string implementation is possible, as either of the above is sufficient for my own purposes and trivial which I suspect a templatized str() wouldn't be...
Anyway, if there's any interest I can post a patch for either or both and if not continue using the first method (simpler diff from the original)!
What's the concrete advantage? OT: I would like to see a way to avoid the ( ).str() bits. Olaf
On 02/07/2012 15:20, Olaf van der Spek wrote:
On Mon, Jul 2, 2012 at 1:59 PM, news.gmane.org <lukester_null@yahoo.co.uk> wrote:
I've not looked at whether something such as templatizing the str() method on the string implementation is possible, as either of the above is sufficient for my own purposes and trivial which I suspect a templatized str() wouldn't be...
Anyway, if there's any interest I can post a patch for either or both and if not continue using the first method (simpler diff from the original)!
What's the concrete advantage?
OT: I would like to see a way to avoid the ( ).str() bits.
Olaf
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
For me, avoiding the use of ref-counted G++ strings. Currently use STLport for this sole reason, but there seems to be little development on STLport these days and their SSO string uses a buffer of 4 * sizeof(void *) - which isn't great when your mean string length is 11 bytes and you're running on a 64-bit platform... g++'s vstring seems to have performance almost as good as STLport's (and way better than boost's) from the limited testing I've done. I should mention that the performance of boost.format is not an issue as it's not used in any time critical code - just a while load of pain if unable to support alternative strings, hence my hackery. Regards Luke Elliott.
On Mon, Jul 2, 2012 at 4:56 PM, news.gmane.org <lukester_null@yahoo.co.uk> wrote:
For me, avoiding the use of ref-counted G++ strings.
Isn't G++ going to fix their strings?
g++'s vstring seems to have performance almost as good as STLport's (and way better than boost's) from the limited testing I've done.
Does Boost have a string type?
I should mention that the performance of boost.format is not an issue as it's not used in any time critical code - just a while load of pain if unable to support alternative strings, hence my hackery.
If performance is not an issue, why would you use another string type? -- Olaf
On 04/07/2012 11:22, Olaf van der Spek wrote:
On Mon, Jul 2, 2012 at 4:56 PM, news.gmane.org <lukester_null@yahoo.co.uk> wrote:
For me, avoiding the use of ref-counted G++ strings.
Isn't G++ going to fix their strings?
One day ... no good for now ("now" for me being until RHEL5 is no longer supported).
g++'s vstring seems to have performance almost as good as STLport's (and way better than boost's) from the limited testing I've done.
Does Boost have a string type?
Yes; I was referring to boost::container::string.
I should mention that the performance of boost.format is not an issue as it's not used in any time critical code - just a while load of pain if unable to support alternative strings, hence my hackery.
If performance is not an issue, why would you use another string type?
Performance of boost.format is not important; of strings themselves it very much is. Regards Luke.
On Wed, Jul 4, 2012 at 2:31 PM, Luke Elliott <lukester_null@yahoo.co.uk> wrote:
I should mention that the performance of boost.format is not an issue as it's not used in any time critical code - just a while load of pain if unable to support alternative strings, hence my hackery.
If performance is not an issue, why would you use another string type?
Performance of boost.format is not important; of strings themselves it very much is.
Right. So what exactly is the problem? Return type of format::str()? -- Olaf
On 05/07/2012 17:22, Olaf van der Spek wrote:
On Wed, Jul 4, 2012 at 2:31 PM, Luke Elliott <lukester_null@yahoo.co.uk> wrote:
I should mention that the performance of boost.format is not an issue as it's not used in any time critical code - just a while load of pain if unable to support alternative strings, hence my hackery.
If performance is not an issue, why would you use another string type?
Performance of boost.format is not important; of strings themselves it very much is.
Right. So what exactly is the problem? Return type of format::str()?
Well "problem" is a bit strong, but str() is the issue with using alternative strings with "no" changes to client code AFAICT. I'm sure there are many other ways to achieve the same result, but this is the least intrusive for me. Anyway, no big deal if there's no interest - it doesn't seem like there's much development of format these days so it's not like it's going to be much effort with each new boost release to keep the patch up-to-date. (I guess there's also no interest in a hack around the (format("%u") % byte_t(65)) == "A" problem...) Regards Luke.
On Thu, Jul 5, 2012 at 6:44 PM, Luke Elliott <lukester_null@yahoo.co.uk> wrote:
Right. So what exactly is the problem? Return type of format::str()?
Well "problem" is a bit strong, but str() is the issue with using alternative strings with "no" changes to client code AFAICT. I'm sure there
Because std::string can't be assigned to the alternative string type?
are many other ways to achieve the same result, but this is the least intrusive for me.
Anyway, no big deal if there's no interest - it doesn't seem like there's much development of format these days so it's not like it's going to be much effort with each new boost release to keep the patch up-to-date.
(I guess there's also no interest in a hack around the (format("%u") % byte_t(65)) == "A" problem...)
I've been bitten by that one too and wouldn't mind seeing a solution. -- Olaf
On 05/07/2012 18:53, Olaf van der Spek wrote:
On Thu, Jul 5, 2012 at 6:44 PM, Luke Elliott <lukester_null@yahoo.co.uk> wrote:
Right. So what exactly is the problem? Return type of format::str()?
Well "problem" is a bit strong, but str() is the issue with using alternative strings with "no" changes to client code AFAICT. I'm sure there
Because std::string can't be assigned to the alternative string type?
Yes. lexical_cast works, and obviously .c_str()/.length() could be used but instead of a 50-odd line patch to boost.format that's a whole load more changes to a lot of client code... plus whilst I don't care about format performance, I'm not sure I don't care about it enough to not care about additional string construction :)
are many other ways to achieve the same result, but this is the least intrusive for me.
Anyway, no big deal if there's no interest - it doesn't seem like there's much development of format these days so it's not like it's going to be much effort with each new boost release to keep the patch up-to-date.
(I guess there's also no interest in a hack around the (format("%u") % byte_t(65)) == "A" problem...)
I've been bitten by that one too and wouldn't mind seeing a solution.
Well I've attached my hack. I'm sure it's wrong in lots of ways but kinda does the trick, for some definition of kinda. Cheers Luke.
On Thu, Jul 5, 2012 at 8:30 PM, Luke Elliott <lukester_null@yahoo.co.uk> wrote:
Because std::string can't be assigned to the alternative string type?
Yes. lexical_cast works, and obviously .c_str()/.length() could be used but instead of a 50-odd line patch to boost.format that's a whole load more changes to a lot of client code... plus whilst I don't care about format performance, I'm not sure I don't care about it enough to not care about additional string construction :)
Why don't the alternative string types support implicit construction from std::string? Does str() move from the internal storage or does it construct a new std::string anyway? Olaf
On Mon, Jul 2, 2012 at 6:59 AM, news.gmane.org <lukester_null@yahoo.co.uk>wrote:
I.e. such that alternative string implementations could be used (GCC's vstring, boost's...).
I've attempted two methods, both pretty simple. First is to simply template basic_format on the string type and propagate that change throughout the library (including similar for the altstream/stringbuf classes).
Second was to add a template template parameter for the string, e.g.:
template <class Ch, class Tr, class Alloc, template <typename, typename, typename> class StringT = std::basic_string> class basic_format;
and propagate that.
I would assume the first method is definitely out due to breaking the interface (especially the altstream classes which I would guess are supposed to look like the std ones).
I've not looked at whether something such as templatizing the str() method on the string implementation is possible, as either of the above is sufficient for my own purposes and trivial which I suspect a templatized str() wouldn't be...
Anyway, if there's any interest I can post a patch for either or both and if not continue using the first method (simpler diff from the original)!
I've always thought format could be decoupled to output via iterator, which would be a lot more flexible to use than depending on a full string type. I suppose that'd be quite a large change. -- Cory Nelson http://int64.org
On 7/2/2012 7:59 AM, news.gmane.org wrote:
I.e. such that alternative string implementations could be used (GCC's vstring, boost's...).
I've attempted two methods, both pretty simple. First is to simply template basic_format on the string type and propagate that change throughout the library (including similar for the altstream/stringbuf classes).
Second was to add a template template parameter for the string, e.g.:
template <class Ch, class Tr, class Alloc, template <typename, typename, typename> class StringT = std::basic_string> class basic_format;
and propagate that.
Have you considered using boost.iostreams lib to directly write to your alternate string type? The tutorial 2.1.3 in the docs: http://www.boost.org/doc/libs/1_47_0/libs/iostreams/doc/tutorial/container_s... Describes a generic container_sink, but also describes using iostreams::back_inserter. This could be wrapped in a generic function that returns your desired string type. Assuming of course that the type is back insertable. Jeff
participants (5)
-
Cory Nelson -
Jeff Flinn -
Luke Elliott -
news.gmane.org
-
Olaf van der Spek