[Development] Deprecating QString::{v,}sprintf()

[BRM]

> From: Olivier Goffart <olivier at woboq.com>
> On Tuesday 21 February 2012 14:03:26 Marc Mutz wrote:
>>  On Tuesday February 21 2012, Marc Mutz wrote:
>>  > On Tuesday February 21 2012, Marc Mutz wrote:
>>  > > Hi,
>>  > > 
>>  > > The QString header contains a ### about removing sprintf() in 
> 5.0, but
>>  > > it's still there. I'd like to deprecate them.
>>  > > 
>>  > > I have a long-standing hate of the fact that QString::sprintf() 
> is not
>>  > > static, so my preferred solution would be to make it static, but 
> that
>>  > > silently breaks existing usage other than the idiomatic
>>  > > QString().sprintf().
>>  > > 
>>  > > Unless there's a clever technique by which we can at 
> compile-time catch
>>  > > non-static uses of sprintf(), I'd propose to just deprecate 
> it.
>>  > 
>>  > Actually, I just found GNU's asprintf() extension 
> ("allocated-string
>>  > printf"), arguably a better name for QString::sprintf() anyway. 
> So I'll
>>  > upload a patch to Gerrit that will:
>>  > 
>>  > 1. Deprecate QString{v,}sprintf()
>>  > 2. Add static QString::{v,}asprintf()
>> 
>>  https://codereview.qt-project.org/#change,17062
>> 
>>  The patch also nicely highlights how and where QString().sprintf() is used
>>  in Qt itself, because it adjusts all callers.
>> 
>>  Before vetoing the patch on the grounds of C-style API, please remember 
> that
>>  this functionality is required for qDebug() and that we want to keep SiC as
>>  much as possible for 5.0. A C++11-style framework is a lot more work, and
>>  not something I'd expect to land in 5.0.
>> 
>>  My main drive is the embarrassment of having sprintf not static.
> 
> Is that so much of a problem of it non being static?
> Why not just keeping it as it is?

Doesn't matter to me.
 
> (else, you could also deprecate it from the public API, but keep it in the 
> private API for qDebug)

I know of someone who (while not a Qt programmer) do like to have that kind of stuff built-in to string functionality.
He even made an argument for not using std::string (or std::wstring) simply on those grounds; and we ended up
with a lot of MFC CString cruft because of it.

Having something that does the work of {v,s,sn,a}prinf() is very useful to have.
The tr().arg() functionality while useful, does not satisfy quite all needs - its much easier to format using {v,s,sn,a}prinf()
than tr().arg() (or QString().arg()).

$0.02

Ben