A
A.Leopold
hello,
is there a c++ equivalent function to the c-function 'sprintf'?
Thank you,
leo
is there a c++ equivalent function to the c-function 'sprintf'?
Thank you,
leo
A
A.Leopold
ok, I asked, cause my compiler (VS05) is complaining about the use of
sprintf ....
J
juanvicfer
Maybe you want to use stringstream.
A
A.Leopold
juanvicfer said:
ok, I will have a look at stringstream
S
sean_in_raleigh
You can also check out boost::format, which can be
easier to work with than stringstream:
http://www.boost.org/doc/libs/1_36_0/libs/format/doc/format.html
Sean
A
A.Leopold
thank you, that looks much more convenient!
P
Pascal J. Bourguignon
A.Leopold said:
ok, I asked, cause my compiler (VS05) is complaining about the use of
sprintf ....
I guess it's rather ::sprintf (with extern "C" { / #include <stdio.h> / }).
But if you want some safety, you'd use ::snprintf, and if you don't want to implement
the safety yourself, you could rather use lisp^W std:
stringstream.std:
stringstream s; s<<"Hi "<<world<<std::endl;std::string str =s.str();
const char* cstr=s.c_str();
L
Lionel B
There is also boost::lexical_cast (something like a "cheap and cheerful"
version of stringstream formatting):
http://www.boost.org/doc/libs/1_36_0/libs/conversion/lexical_cast.htm
D
Default User
Pascal said:
What would make you guess something like that?
Brian
P
Pascal J. Bourguignon
Default User said:
First, AFAIK, C functions are in the "root" namespace; to avoid
refering a different object in the current namespace, it's advised (in
various style guides) to qualify C functions.
Then, using a function without declaring it would make a sane compiler
complain, so it's good practice to include some header declaring it
before using it.
H
Hendrik Schober
Pascal said:
The is the C++ group here, so the C header <stdio.h> is to be
included using <cstdio> and its content is accessible only within
the 'std' namespace.
Schobi
D
Default User
Pascal said:
I've never seen such a thing.
That's correct, of course. However, <stdio.h> is a standard C++ header.
Why would you enclose it in extern "C"?
Brian
R
robertwessel2
ok, I asked, cause my compiler (VS05) is complaining about the use of
sprintf ....
Please don't top-post.
If you're getting the MSVC warning about depreciated functions, you
may ignore that, or turn off the warning with the appropriate compiler
option, #pragma or #define. Current versions of MSVC warn about the
use of many traditional functions which have the potential, if used
incorrectly, to lead to buffer overflows. MS has taken a fair bit of
heat for this, especially because they chose to describe the functions
as "depreciated" (which means something specific in terms of the
language standard), instead of something describing the risk. In most
cases they provide a (Microsoft specific) replacement function which
has the potential to be used more easily in a safe way (for example,
the non-standard sprintf_s is offered as a "safer" replacement for
sprintf).
The did it to a number of C++ library functions to. For example,
basic_string::copy is "depreciated" while the non-standard
basic_string::_Copy_s is provided as a "safer" alternative.
http://msdn.microsoft.com/en-us/library/ttcz0bys(VS.80).aspx
I
Ian Collins
Jeff said:
That depends on which header you include. From what I've seen, people
still prefer <stdio.h> over <cstdio>.
K
Kai-Uwe Bux
A.Leopold wrote:
Assuming that vnsprintf is C99 or C++0X compliant
that std:string is contiguous (as in C++0X) and
that writing \0 at str[ str.size() ] is harmless,
you could try:
bool strprintf ( std::string & buffer, char const * format, ... ) {
while ( true ) {
buffer.resize( buffer.capacity() );
int old_length = buffer.size();
std::va_list aq;
va_start( aq, format );
int length_needed =
vsnprintf( &buffer[0], old_length + 1, format, aq );
va_end( aq );
if ( length_needed < 0 ) {
return ( false );
}
buffer.resize( length_needed );
if ( length_needed <= old_length ) {
return ( true );
}
}
}
This will do what sprintf() does, except it will use a std::string as the
target and increase it when needed.
Best
Kai-Uwe Bux
Assuming that vnsprintf is C99 or C++0X compliant
that std:string is contiguous (as in C++0X) and
that writing \0 at str[ str.size() ] is harmless,
you could try:
bool strprintf ( std::string & buffer, char const * format, ... ) {
while ( true ) {
buffer.resize( buffer.capacity() );
int old_length = buffer.size();
std::va_list aq;
va_start( aq, format );
int length_needed =
vsnprintf( &buffer[0], old_length + 1, format, aq );
va_end( aq );
if ( length_needed < 0 ) {
return ( false );
}
buffer.resize( length_needed );
if ( length_needed <= old_length ) {
return ( true );
}
}
}
This will do what sprintf() does, except it will use a std::string as the
target and increase it when needed.
Best
Kai-Uwe Bux
R
Richard Herring
Yannick Tremblay said:
.... that way you only have an out-by-1 error waiting to happen ;-/
J
James Kanze
Probably in shops which prefer libraries which work as
specified.
Using a library which works as specified is incompetent? Using
one that doesn't isn't? Implementations where the <c...>
libraries work as specified are so rare that the standards
committee changed the specification.
J
James Kanze
Yes. People prefer it because they know what they are getting.
The fact that most implementations didn't implement what the
Are you sure that none of the symbols that aren't allowed to be
in :: weren'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.
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 "vanishingly rare, and
generally a sign of incompetence."
I
Ian Collins
I prefer it.
Even though the C standard library is incorporated in the C++ standard
library, it is still C. I prefer to emphasise that distinction by
keeping the symbols in the global namespace. I would never consider
reusing them inside another namespace.
some "standard" symbols in the global namespace and others in std::.
Why make life more complex than it already is?
Even though the C standard library is incorporated in the C++ standard
library, it is still C. I prefer to emphasise that distinction by
keeping the symbols in the global namespace. I would never consider
reusing them inside another namespace.
Which leads to porting issues when one compiler does and another does not.
We also tend to consider Posix headers as "standard" and dislike having
some "standard" symbols in the global namespace and others in std::.
Why make life more complex than it already is?
G
Gennaro Prota
Pete Becker wrote:
[C headers]
Can't deprecation be "canceled" under ISO rules? I'm far from
sure but perhaps that's called "reinstatement" (even if the
feature hasn't been removed yet). Another candidate for this
would be strstream.
[C headers]
Can't deprecation be "canceled" under ISO rules? I'm far from
sure but perhaps that's called "reinstatement" (even if the
feature hasn't been removed yet). Another candidate for this
would be strstream.