Re: [boost] [string] proposal
Dean Michael Berris wrote :
On Sat, Jan 29, 2011 at 5:24 PM, Artyom <artyomtnk@yahoo.com> wrote:
-
From: Dean Michael Berris <mikhailberis@gmail.com>
On Sat, Jan 29, 2011 at 3:02 PM, Artyom <artyomtnk@yahoo.com> wrote:
It would turn away 90% of users.
It might turn you away because you obviously love std::string. Generalizing is a different matter and is largely a hot-air blowing exercise that is futile for convincing anybody.
I would say it more clear:
1. All users that use C libraries and need c_str() at boundaries And this is a huge amount of users that need to communicate with modules that are already working and ready but written in C.
And this is about of half of libraries there is C is the lowest level API that allows easy bindings to all languages.
But c_str() doesn't have to be part of the string's interface.
*My* *guess* is that Artyom think that: os_func ((s1 + s2 + s3 + ... + s100).c_str()); // s for std::string is dramatically faster than: os_func ((c1 + c2 + c3 + ... + c100).to_string().c_str()); // c for "boost::chain" Regardless of the validity of my present guess, I'm quite sure that this concern (and other similar ones) will be shared many developpers. Ivan
On Sat, Jan 29, 2011 at 14:07, Ivan Le Lann <ivan.lelann@free.fr> wrote:
*My* *guess* is that Artyom think that:
os_func ((s1 + s2 + s3 + ... + s100).c_str()); // s for std::string
is dramatically faster than:
os_func ((c1 + c2 + c3 + ... + c100).to_string().c_str()); // c for "boost::chain"
Aren't they perform the same? Actually with lazy evaluation the latter will be faster. -- Yakov
On Sat, Jan 29, 2011 at 8:07 PM, Ivan Le Lann <ivan.lelann@free.fr> wrote:
Dean Michael Berris wrote :
But c_str() doesn't have to be part of the string's interface.
*My* *guess* is that Artyom think that:
os_func ((s1 + s2 + s3 + ... + s100).c_str()); // s for std::string
is dramatically faster than:
os_func ((c1 + c2 + c3 + ... + c100).to_string().c_str()); // c for "boost::chain"
And this is precisely my point as well: the one that uses boost::chain is perfectly suited for this kind of use case in both efficiency and clear-cut semantics. I for one don't like to make to_string() a member either -- I much rather make it a conversion operator so boost::chain (if we're going to call it that) can be used where interfaces take a std::string. Now the converted "linearized" version can be interned and reference counted as well because it is guaranteed to never change but that's an optimization that's unnecessary (yet) when we're talking about interfaces. ;)
Regardless of the validity of my present guess, I'm quite sure that this concern (and other similar ones) will be shared many developpers.
Which is valid. But then consider the case when your "c's" above are really long strings. -- Dean Michael Berris about.me/deanberris
participants (3)
-
Dean Michael Berris -
Ivan Le Lann -
Yakov Galka