sprintf equivalent in c++

**Jeff Schwab** · Oct 16 '08, 05:15 PM

Re: sprintf equivalent in c++

[snipped conversation re. C <file.hvs. C++ <cfileheaders .]

James Kanze wrote:

On Oct 15, 5:20 pm, Jeff Schwab <j...@schwabcen ter.comwrote:

>And where on earth are you still having trouble with <c*>?
> They've worked well for me for at least the last years or so
>(using mostly GCC).

>
Are you sure that none of the symbols that aren't allowed to be
in :: weren't.

The symbols to which you're referring are allowed to be there, and have
been allowed for a long time. At least cstdlib gives me the choice
between ::size_t and std::size_t.

For those of us who work under Posix, or have to support Posix,
there's an additional issue---Posix modifies the definition of
some of the standard C headers. And who knows whether the
<c...headers will respect the Posix standard; there isn't a
Posix standard for the <c...headers.

I use POSIX quite a bit, and haven't had any problems with it (aside
from the non-C++-specific friction, e.g. re. dlsym returning void*).
Platform-specific names (e.g. ::ssize_t) are no less plentiful in
stdlib.h than in cstdlib.

The result is that most competent programmers I know prefer the
older, C compatible forms. Not all; there are valid arguments
both ways. But it's certainly not "vanishingl y rare, and
generally a sign of incompetence."

In my admittedly anecdotal experience, it *is* vanishingly rare, and
*does* correlate strongly with the quality of the programmer's work in
other respects; I apparently hold the minority opinion in c.l.c++,
though. I guess we'll agree to disagree.

**Pete Becker** · Oct 16 '08, 06:15 PM

Re: sprintf equivalent in c++

On 2008-10-16 13:12:04 -0400, Jeff Schwab <jeff@schwabcen ter.comsaid:

Pete Becker wrote:

>On 2008-10-11 11:03:51 -0400, Jeff Schwab <jeff@schwabcen ter.comsaid:
>>

>>Ian Collins wrote:
>>>Jeff Schwab wrote:
>>>>Pete Becker wrote:
>>>>>On 2008-10-09 09:33:41 -0400, "A.Leopold" <andreas.leopol d@himt.desaid:
>>>>>>
>>>>>>is there a c++ equivalent function to the c-function 'sprintf'?
>>>>>>>
>>>>>Yes. Its name is sprintf.
>>>>Assuming that line is preceded by "using std::sprintf;".
>>>>
>>>That depends on which header you include. From what I've seen, people
>>>still prefer <stdio.hover <cstdio>.
>>>
>>Where are you seeing this? IME, it's vanishingly rare, and generally a
>>sign of incompetence.

>>
>Gosh, and here I thought I knew something about C++ libraries and
>coding. Thanks for pointing out my incompetence.

>
And thanks, in return, for the pedantic sarcasm. By "generally, " I
meant "with exceptions." If you have specific reasons for using what
appear to be obsolete headers, in favor of the standard headers that
have worked well for me over the last 5-10 years, please elaborate.

I don't use obsolete headers. I use the standard C headers that are in
the C++ language standard. They've worked fine for me over the last
thirty years, in C and C++, and I don't see any good reason to change.
It has nothing to do with competence, "generally" or otherwise.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

**Jeff Schwab** · Oct 16 '08, 07:05 PM

Re: sprintf equivalent in c++

Pete Becker wrote:

On 2008-10-16 13:12:04 -0400, Jeff Schwab <jeff@schwabcen ter.comsaid:
>

>Pete Becker wrote:

>>On 2008-10-11 11:03:51 -0400, Jeff Schwab <jeff@schwabcen ter.comsaid:
>>>
>>>Ian Collins wrote:
>>>>Jeff Schwab wrote:
>>>>>Pete Becker wrote:
>>>>>>On 2008-10-09 09:33:41 -0400, "A.Leopold"
>>>>>><andreas. leopold@himt.de said:
>>>>>>>
>>>>>>>is there a c++ equivalent function to the c-function 'sprintf'?
>>>>>>>>
>>>>>>Yes. Its name is sprintf.
>>>>>Assuming that line is preceded by "using std::sprintf;".
>>>>>
>>>>That depends on which header you include. From what I've seen, people
>>>>still prefer <stdio.hover <cstdio>.
>>>>
>>>Where are you seeing this? IME, it's vanishingly rare, and
>>>generally a sign of incompetence.
>>>
>>Gosh, and here I thought I knew something about C++ libraries and
>>coding. Thanks for pointing out my incompetence.

>>
>And thanks, in return, for the pedantic sarcasm. By "generally, " I
>meant "with exceptions." If you have specific reasons for using what
>appear to be obsolete headers, in favor of the standard headers that
>have worked well for me over the last 5-10 years, please elaborate.

>
I don't use obsolete headers.

They're long since deprecated. They exist primarily for C
compatibility. [diff.mods.to.he aders]: "For compatibility with the
Standard C library, the C++ standard library provides the 18 C headers,
but their use is deprecated in C++". Furthermore, they're not really
quite the same; aside from adding names to std, there are other
potentially subtle differences. Once upon a time, I remember having
some compliance issues with the <c*headers, but it's been quite a while.

I use the standard C headers that are in
the C++ language standard.

Lots of stuff is "in the C++ language standard" with guidelines to the
effect of "don't do this, it might hurt." The C headers fall into this
category.

They've worked fine for me over the last
thirty years, in C and C++, and I don't see any good reason to change.
It has nothing to do with competence, "generally" or otherwise.

You clearly are up to speed with modern C++ development. However, other
programmers who stick with deprecated features out of sheer inertia --
which is the only reason you've given so far for preferring the C
headers -- are unlikely to have kept as sharp.

You seem to have taken offense at my use of the word "incompeten ce," but
I get a sinking feeling in my stomach when I see a C++ program #include
the old headers; I've been conditioned by experience to see it as the
banner of a poorly coded file. There are plenty of "to each his own"
issues in software development, but I don't see this as one of them.

**Pete Becker** · Oct 16 '08, 07:25 PM

Re: sprintf equivalent in c++

On 2008-10-16 15:04:21 -0400, Jeff Schwab <jeff@schwabcen ter.comsaid:

Pete Becker wrote:

>On 2008-10-16 13:12:04 -0400, Jeff Schwab <jeff@schwabcen ter.comsaid:
>>

>>Pete Becker wrote:
>>>On 2008-10-11 11:03:51 -0400, Jeff Schwab <jeff@schwabcen ter.comsaid:
>>>>
>>>>Ian Collins wrote:
>>>>>Jeff Schwab wrote:
>>>>>>Pete Becker wrote:
>>>>>>>On 2008-10-09 09:33:41 -0400, "A.Leopold" <andreas.leopol d@himt.desaid:
>>>>>>>>
>>>>>>>>is there a c++ equivalent function to the c-function 'sprintf'?
>>>>>>>>>
>>>>>>>Yes. Its name is sprintf.
>>>>>>Assumin g that line is preceded by "using std::sprintf;".
>>>>>>
>>>>>That depends on which header you include. From what I've seen, people
>>>>>still prefer <stdio.hover <cstdio>.
>>>>>
>>>>Where are you seeing this? IME, it's vanishingly rare, and generally a
>>>>sign of incompetence.
>>>>
>>>Gosh, and here I thought I knew something about C++ libraries and
>>>coding. Thanks for pointing out my incompetence.
>>>
>>And thanks, in return, for the pedantic sarcasm. By "generally, " I
>>meant "with exceptions." If you have specific reasons for using what
>>appear to be obsolete headers, in favor of the standard headers that
>>have worked well for me over the last 5-10 years, please elaborate.

>>
>I don't use obsolete headers.

>
They're long since deprecated.

That is true. It is also irrelevant: they're not going to go away,
despite the wishes of some people early in the standardization effort.

They exist primarily for C compatibility. [diff.mods.to.he aders]:
"For compatibility with the
Standard C library, the C++ standard library provides the 18 C headers,
but their use is deprecated in C++". Furthermore, they're not really
quite the same; aside from adding names to std, there are other
potentially subtle differences. Once upon a time, I remember having
some compliance issues with the <c*headers, but it's been quite a
while.
>

>I use the standard C headers that are in the C++ language standard.

>
Lots of stuff is "in the C++ language standard" with guidelines to the
effect of "don't do this, it might hurt." The C headers fall into this
category.

There are words to that effect. There's quite a bit of wishful thinking
in this area.

>

>They've worked fine for me over the last thirty years, in C and C++,
>and I don't see any good reason to change. It has nothing to do with
>competence, "generally" or otherwise.

>
You clearly are up to speed with modern C++ development. However, other
programmers who stick with deprecated features out of sheer inertia --
which is the only reason you've given so far for preferring the C
headers -- are unlikely to have kept as sharp.

You haven't listed any specific problem that arises from the use of C
headers, so your objection apparently is purely formal. Yes, the
standard says they're deprecated. Bummer. Life goes on.

>
You seem to have taken offense at my use of the word "incompeten ce," but
I get a sinking feeling in my stomach when I see a C++ program #include
the old headers; I've been conditioned by experience to see it as the
banner of a poorly coded file. There are plenty of "to each his own"
issues in software development, but I don't see this as one of them.

Shrug.

P.S.: please don't reply by e-mail. I read newsgroup messages on newsgroups.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

**Jeff Schwab** · Oct 16 '08, 08:05 PM

Re: sprintf equivalent in c++

Pete Becker wrote:

P.S.: please don't reply by e-mail. I read newsgroup messages on
newsgroups.

Sorry about that; misconfigured thunderbird.

**Pete Becker** · Oct 16 '08, 08:55 PM

Re: sprintf equivalent in c++

On 2008-10-16 16:04:03 -0400, Jeff Schwab <jeff@schwabcen ter.comsaid:

Pete Becker wrote:
>

>P.S.: please don't reply by e-mail. I read newsgroup messages on newsgroups.

>
Sorry about that; misconfigured thunderbird.

No harm done.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

**Gennaro Prota** · Oct 16 '08, 09:35 PM

Re: sprintf equivalent in c++

Pete Becker wrote:
[C headers]

>They're long since deprecated.

>
That is true. It is also irrelevant: they're not going to go away,
despite the wishes of some people early in the standardization effort.

Can't deprecation be "canceled" under ISO rules? I'm far from
sure but perhaps that's called "reinstatem ent" (even if the
feature hasn't been removed yet). Another candidate for this
would be strstream.

--
Gennaro Prota | name.surname yahoo.com
Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.

**Pete Becker** · Oct 16 '08, 11:15 PM

Re: sprintf equivalent in c++

On 2008-10-16 17:28:33 -0400, Gennaro Prota <gennaro/prota@yahoo.com said:

Pete Becker wrote:
[C headers]

>>They're long since deprecated.

>>
>That is true. It is also irrelevant: they're not going to go away,
>despite the wishes of some people early in the standardization effort.

>
Can't deprecation be "canceled" under ISO rules?

Certainly.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

**James Kanze** · Oct 17 '08, 08:45 AM

Re: sprintf equivalent in c++

On Oct 16, 7:12 pm, Jeff Schwab <j...@schwabcen ter.comwrote:

[snipped conversation re. C <file.hvs. C++ <cfileheaders .]

James Kanze wrote:

On Oct 15, 5:20 pm, Jeff Schwab <j...@schwabcen ter.comwrote:

And where on earth are you still having trouble with <c*>?
They've worked well for me for at least the last years or
so (using mostly GCC).

Are you sure that none of the symbols that aren't allowed to
be in :: weren't.

The symbols to which you're referring are allowed to be there,
and have been allowed for a long time. At least cstdlib gives
me the choice between ::size_t and std::size_t.

It shouldn't. According to the current standard, <cstddef>
defines std::size_t, but not ::size_t---<stddef.hmay define
both.

For those of us who work under Posix, or have to support
Posix, there's an additional issue---Posix modifies the
definition of some of the standard C headers. And who knows
whether the <c...headers will respect the Posix standard;
there isn't a Posix standard for the <c...headers.

I use POSIX quite a bit, and haven't had any problems with it
(aside from the non-C++-specific friction, e.g. re. dlsym
returning void*). Platform-specific names (e.g. ::ssize_t)
are no less plentiful in stdlib.h than in cstdlib.

Where is that documented? In what standard? (I know that it's
often the case---in many cases, the implementation of the <c...>
header is simply to include the <...hheader, wrapping it in
extern "C" {}. Which isn't conform, of course, but everyone
does it.) And is it ::ssize_t or std::ssize_t? And isn't it
confusing to have to remember std::size_t, but ::pos_t?

The result is that most competent programmers I know prefer
the older, C compatible forms. Not all; there are valid
arguments both ways. But it's certainly not "vanishingl y
rare, and generally a sign of incompetence."

In my admittedly anecdotal experience, it *is* vanishingly
rare, and *does* correlate strongly with the quality of the
programmer's work in other respects; I apparently hold the
minority opinion in c.l.c++, though. I guess we'll agree to
disagree.

I don't know if your opinion is a minority one or not. It's
certainly valid to prefer the <c...forms. But prefering the
..h forms is also valid---in addition to the reasons mentionned,
it says right up front that you are using a C header, rather
than trying to pretend otherwise. And since I don't have a
<cunistdor a <cpthread>. (Basically, I consider the Posix
headers as "standard" for much of what I do, so I'm using a lot
of headers with the .h form and all of their symbols in ::
anyway.)

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

**James Kanze** · Oct 17 '08, 09:05 AM

Re: sprintf equivalent in c++

On Oct 16, 11:28 pm, Gennaro Prota <gennaro/pr...@yahoo.com wrote:

Pete Becker wrote:

[C headers]

They're long since deprecated.

That is true. It is also irrelevant: they're not going to go
away, despite the wishes of some people early in the
standardization effort.

Can't deprecation be "canceled" under ISO rules?

In theory, or in practice. In practice, each version of the
standard is a new standard, and can make any changes it wants.
The next version of the standard could replace { and } with
BEGIN and END, if there were enough support for that. (There
isn't, don't worry.) If the committee voted to remove the word
deprecated at some point, it would be removed. In the end, the
only thing ISO really requires of a new version of the standard
is that it receive enough votes from the national bodies to
pass.

I'm far from sure but perhaps that's called "reinstatem ent"
(even if the feature hasn't been removed yet). Another
candidate for this would be strstream.

"Deprecate" already has a negative prefix; the opposite would be
precate, or perhaps since we're restoring a previous status,
reprecate. Don't look for those words in the dictionary,
however:-).

(The word actually derives directly from a Latin word, which
meant to pray against. Which can be interpreted to support
Jeff's position---the committee is praying against your using
the feature---or Pete's---praying is often wishful thinking,
when you have no concrete or practical means of achieving your
wishes. Ideally, Jeff would be right, but practically, Pete's
position seems closer to reality.)

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

**Jeff Schwab** · Oct 17 '08, 09:45 AM

Re: sprintf equivalent in c++

James Kanze wrote:

On Oct 16, 7:12 pm, Jeff Schwab <j...@schwabcen ter.comwrote:

>[snipped conversation re. C <file.hvs. C++ <cfileheaders .]

>

>James Kanze wrote:

>>On Oct 15, 5:20 pm, Jeff Schwab <j...@schwabcen ter.comwrote:
>>>And where on earth are you still having trouble with <c*>?
>>>They've worked well for me for at least the last years or
>>>so (using mostly GCC).

>

>>Are you sure that none of the symbols that aren't allowed to
>>be in :: weren't.

>

>The symbols to which you're referring are allowed to be there,
>and have been allowed for a long time. At least cstdlib gives
>me the choice between ::size_t and std::size_t.

>
It shouldn't. According to the current standard, <cstddef>
defines std::size_t, but not ::size_t---<stddef.hmay define
both.

You are correct that the current standard does not specifically allow
most of those names to be at global scope, although it makes exceptions
(of course) for macros. In practice, whether the names are at global
scope is implementation-specific, and that fact is reflected in the
upcoming standard.

>>For those of us who work under Posix, or have to support
>>Posix, there's an additional issue---Posix modifies the
>>definition of some of the standard C headers. And who knows
>>whether the <c...headers will respect the Posix standard;
>>there isn't a Posix standard for the <c...headers.

>

>I use POSIX quite a bit, and haven't had any problems with it
>(aside from the non-C++-specific friction, e.g. re. dlsym
>returning void*). Platform-specific names (e.g. ::ssize_t)
>are no less plentiful in stdlib.h than in cstdlib.

>
Where is that documented? In what standard? (I know that it's
often the case---in many cases, the implementation of the <c...>
header is simply to include the <...hheader, wrapping it in
extern "C" {}. Which isn't conform, of course, but everyone
does it.)

Where is what documented? That <c*are not, in general, less
conformant than <*.h>? I don't understand what you're asking.

And is it ::ssize_t or std::ssize_t?

It's ::ssize_t. The compiler yells if you use std::ssize_t.

And isn't it
confusing to have to remember std::size_t, but ::pos_t?

No. Anything in the global namespace that is not, itself, a namespace
name, is properly the province of C, not C++. I also dislike
using-directives. I have more of a "wait, what?" moment when I see C++
library code defined at global scope, as in Qt (where all the classes
have to start with Q). I admit that it's arguably even worse to play
both sides, as the OpenAccess library does: everything there is called
oa::oaSomething . Blech.

>>The result is that most competent programmers I know prefer
>>the older, C compatible forms. Not all; there are valid
>>arguments both ways. But it's certainly not "vanishingl y
>>rare, and generally a sign of incompetence."

>

>In my admittedly anecdotal experience, it *is* vanishingly
>rare, and *does* correlate strongly with the quality of the
>programmer's work in other respects; I apparently hold the
>minority opinion in c.l.c++, though. I guess we'll agree to
>disagree.

>
I don't know if your opinion is a minority one or not. It's
certainly valid to prefer the <c...forms. But prefering the
.h forms is also valid---in addition to the reasons mentionned,
it says right up front that you are using a C header, rather
than trying to pretend otherwise. And since I don't have a
<cunistdor a <cpthread>. (Basically, I consider the Posix
headers as "standard" for much of what I do, so I'm using a lot
of headers with the .h form and all of their symbols in ::
anyway.)

The <c*headers are C++; I don't feel that I'm just "pretending " when I
use them, although I agree that adding std:: to a bunch of identifiers
doesn't automatically make the code more C++ than C, except in a shallow
sense.

POSIX is a standard, it's just not the C++ standard. However, I use
std:: where applicable, even when I'm working directly with POSIX, and
use multiple header suffixes anyway: .hpp for boost, .hh for my own
code, etc. If you really want to write C code for that kind of
relatively low-level interaction with the platform, you can always write
a module in C, then call it from C++. POSIX is really meant to be used
from C, anyway.

**Pete Becker** · Oct 17 '08, 11:45 AM

Re: sprintf equivalent in c++

On 2008-10-17 05:00:14 -0400, James Kanze <james.kanze@gm ail.comsaid:

On Oct 16, 11:28 pm, Gennaro Prota <gennaro/pr...@yahoo.com wrote:

>Pete Becker wrote:

>

>[C headers]

>

>>>They're long since deprecated.

>

>>That is true. It is also irrelevant: they're not going to go
>>away, despite the wishes of some people early in the
>>standardizati on effort.

>

>Can't deprecation be "canceled" under ISO rules?

>
In theory, or in practice. In practice, each version of the
standard is a new standard, and can make any changes it wants.
The next version of the standard could replace { and } with
BEGIN and END, if there were enough support for that. (There
isn't, don't worry.) If the committee voted to remove the word
deprecated at some point, it would be removed. In the end, the
only thing ISO really requires of a new version of the standard
is that it receive enough votes from the national bodies to
pass.

Keep in mind, too, that "deprecate" means only "Normative for the
current edition of the Standard, but not guaranteed to be part of the
Standard in future revisions". [depr]/2. Editorial comments like "we
hates this" notwithstanding .

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

**Gennaro Prota** · Oct 18 '08, 04:15 PM

Re: sprintf equivalent in c++

Pete Becker wrote:

On 2008-10-18 11:41:13 -0400, Gennaro Prota <gennaro/prota@yahoo.com said:

[removing deprecation of C headers]

>>>Couldn't a vote, as James hints at, be proposed on this?
>>>
>>Yes.

>>
>Promised? ;-)

>
Only if someone does it.

I was hoping for someone to take charge of it.

No offense intended, but playing jokes on questions and/or
replying in monosyllables isn't very useful.

--
Gennaro Prota | name.surname yahoo.com
Breeze C++ (preview): <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.

**Pete Becker** · Oct 18 '08, 05:45 PM

Re: sprintf equivalent in c++

On 2008-10-18 12:11:10 -0400, Gennaro Prota <gennaro/prota@yahoo.com said:

Pete Becker wrote:

>On 2008-10-18 11:41:13 -0400, Gennaro Prota <gennaro/prota@yahoo.com said:

[removing deprecation of C headers]

>>>>Couldn't a vote, as James hints at, be proposed on this?
>>>>
>>>Yes.
>>>
>>Promised? ;-)

>>
>Only if someone does it.

>
I was hoping for someone to take charge of it.

Then that's what you should have asked for.

>
No offense intended, but playing jokes on questions and/or
replying in monosyllables isn't very useful.

Nor is assuming that someone intended a joke when you asked a valid
question and got a valid answer.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

**James Kanze** · Oct 19 '08, 02:55 PM

Re: sprintf equivalent in c++

On Oct 17, 1:40 pm, Pete Becker <p...@versatile coding.comwrote :

On 2008-10-17 05:00:14 -0400, James Kanze <james.ka...@gm ail.comsaid:

On Oct 16, 11:28 pm, Gennaro Prota <gennaro/pr...@yahoo.com wrote:

Pete Becker wrote:

[C headers]

>>They're long since deprecated.

>That is true. It is also irrelevant: they're not going to go
>away, despite the wishes of some people early in the
>standardizatio n effort.

Can't deprecation be "canceled" under ISO rules?

In theory, or in practice. In practice, each version of the
standard is a new standard, and can make any changes it
wants. The next version of the standard could replace { and
} with BEGIN and END, if there were enough support for that.
(There isn't, don't worry.) If the committee voted to
remove the word deprecated at some point, it would be
removed. In the end, the only thing ISO really requires of
a new version of the standard is that it receive enough
votes from the national bodies to pass.

Keep in mind, too, that "deprecate" means only "Normative for
the current edition of the Standard, but not guaranteed to be
part of the Standard in future revisions". [depr]/2. Editorial
comments like "we hates this" notwithstanding .

In fact, "deprecate" is really nothing more than an editorial
comment in itself, since of course, the next version of the
standard could also eliminate things which weren't deprecated.
(In practice, of course, standards committees are lothe to break
existing code, regardless. But presumably a little less lothe
if that code uses a deprecated feature. Also in practice,
regardless of what the committee decides, compiler vendors won't
break working code, because that would cost them customers.)

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

sprintf equivalent in c++

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment