hello,
is there a c++ equivalent function to the c-function 'sprintf'?
Thank you,
leo
44  7786 
On 2008-10-09 09:33:41 -0400, "A.Leopold" <an*************@himt.desaid:
>
is there a c++ equivalent function to the c-function 'sprintf'?
Yes. Its name is sprintf.
--
Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
( www.petebecker.com/tr1book)
;)
ok, I asked, cause my compiler (VS05) is complaining about the use of
sprintf ....
Pete Becker schrieb:
On 2008-10-09 09:33:41 -0400, "A.Leopold" <an*************@himt.desaid:
>>
is there a c++ equivalent function to the c-function 'sprintf'?
Yes. Its name is sprintf.
On Oct 9, 3:33*pm, "A.Leopold" <andreas.leop...@himt.dewrote:
hello,
is there a c++ equivalent function to the c-function 'sprintf'?
Maybe you want to use stringstream.
>
Thank you,
leo
juanvicfer schrieb:
On Oct 9, 3:33 pm, "A.Leopold" <andreas.leop...@himt.dewrote:
>hello,
is there a c++ equivalent function to the c-function 'sprintf'?
Maybe you want to use stringstream.
ok, I will have a look at stringstream
On Oct 9, 9:33 am, "A.Leopold" <andreas.leop...@himt.dewrote:
hello,
is there a c++ equivalent function to the c-function 'sprintf'?
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...oc/format.html
Sean
"A.Leopold" <an*************@himt.dewrites:
;)
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::ostringstream.
std::ostringstream s; s<<"Hi "<<world<<std::endl;
std::string str =s.str();
const char* cstr=s.c_str();
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
"A.Leopold" <an*************@himt.dewrites:
;)
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>
/ }).
What would make you guess something like that?
Brian
"Default User" <de***********@yahoo.comwrites:
Pascal J. Bourguignon wrote:
>"A.Leopold" <an*************@himt.dewrites:
;)
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>
/ }).
What would make you guess something like that?
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.
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
"Default User" <de***********@yahoo.comwrites:
>Pascal J. Bourguignon wrote:
>>"A.Leopold" <an*************@himt.dewrites:
;)
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>
/ }).
What would make you guess something like that?
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.
The is the C++ group here, so the C header <stdio.his to be
included using <cstdioand its content is accessible only within
the 'std' namespace.
Schobi
Pascal J. Bourguignon wrote:
"Default User" <de***********@yahoo.comwrites:
Pascal J. Bourguignon wrote:
"A.Leopold" <an*************@himt.dewrites:
;)
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/ }).
What would make you guess something like that?
First, AFAIK, C functions are in the "root" namespace;
Not (at least theoretically) if you use the headers like <cstdio>.
However, that's not necessary.
to avoid
refering a different object in the current namespace, it's advised (in
various style guides) to qualify C functions.
I've never seen such a thing.
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.
That's correct, of course. However, <stdio.his a standard C++ header.
Why would you enclose it in extern "C"?
Brian
Pete Becker wrote:
On 2008-10-09 09:33:41 -0400, "A.Leopold" <an*************@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;".
On Oct 9, 8:45*am, "A.Leopold" <andreas.leop...@himt.dewrote:
;)
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/libr...ys(VS.80).aspx
Jeff Schwab wrote:
Pete Becker wrote:
>On 2008-10-09 09:33:41 -0400, "A.Leopold" <an*************@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>.
--
Ian Collins
A.Leopold wrote:
is there a c++ equivalent function to the c-function 'sprintf'?
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
Ian Collins wrote:
Jeff Schwab wrote:
>Pete Becker wrote:
>>On 2008-10-09 09:33:41 -0400, "A.Leopold" <an*************@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.
In article <04**********************************@m32g2000hsf. googlegroups.com>, ro***********@yahoo.com <ro***********@yahoo.comwrote:
>On Oct 9, 8:45*am, "A.Leopold" <andreas.leop...@himt.dewrote:
>;)
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/libr...ys(VS.80).aspx
I am nout sure you need to go that far into dodgy non-standard
functions.
sprintf should in almost all places be replaced by snprintf.
snprintf is perfectly standard and I think it would silence the
warning.
Yannick
In article <48********@news.arcor-ip.de>,
A.Leopold <an*************@himt.dewrote:
>;)
ok, I asked, cause my compiler (VS05) is complaining about the use of
sprintf ....
sprintf is a buffer overflow waiting to happen.
Use snprintf instead.
# man sprintf
-------selected text--------
BUGS
Because sprintf() and vsprintf() assume an arbitrarily long string,
callers must be careful not to overflow the actual space; this is
often impossible to assure. Note that the length of the strings
produced is locale-dependent and difficult to predict. Use snprintf()
and vsnprintf() instead (or asprintf() and vasprintf).
----------------------------
Alternatively, learn abount C++ streams but that would require more
significant changes to your code.
Yannick
In message <12***************@irys.nyx.net>, Yannick Tremblay
<yt******@nyx.nyx.netwrites
>In article <48********@news.arcor-ip.de>,
A.Leopold <an*************@himt.dewrote:
>>;)
ok, I asked, cause my compiler (VS05) is complaining about the use of
sprintf ....
sprintf is a buffer overflow waiting to happen.
Use snprintf instead.
.... that way you only have an out-by-1 error waiting to happen ;-/
--
Richard Herring
In article <vi**************@baesystems.com>,
Richard Herring <ri*************@baesystems.comwrote:
>In message <12***************@irys.nyx.net>, Yannick Tremblay
<yt******@nyx.nyx.netwrites
>>In article <48********@news.arcor-ip.de>,
A.Leopold <an*************@himt.dewrote:
>>>;)
ok, I asked, cause my compiler (VS05) is complaining about the use of
sprintf ....
sprintf is a buffer overflow waiting to happen.
Use snprintf instead.
... that way you only have an out-by-1 error waiting to happen ;-/
I did consider adding a warning of snprintf too since I have often
encountered the out-by-one error. Not that long ago mentionning in
passing to a programmer the he should use streams instead cause they
are less bug prone but he replied that it was alright in that case
cause he was safely using the same definition for his array size
and his snprintf only for a couple of weeks later figuring out that
there was indead a out-by-1 error in his code. The typical excuse of
course is that C++ streams are not efficient (snprintf is faster) even
if there has been no measurement done and that particular piece of
code is not in a critical loop :-(
But despite all of that, sprintf is fundamentally flawed in many
situation because it can be impossible to write safe code with it as
you can't verify that the buffer was big enough. snprintf makes it
possible to write safe code. Even if you need to be careful with the
out-by-1 errors.
Personally, I am lazy. I use string streams :-)
Yannick
Jeff Schwab wrote:
Ian Collins wrote:
>Jeff Schwab wrote:
>>Pete Becker wrote:
On 2008-10-09 09:33:41 -0400, "A.Leopold" <an*************@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.
I wish it were rare.
Schobi
In article <04**********************************@m32g2000hsf. googlegroups.com>, ro***********@yahoo.com <ro***********@yahoo.comwrote:
>
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/libr...ys(VS.80).aspx
Arrghh!!! I went and glance at this link. what a bunch of idiots:
--------------------------------------
size_type copy(
value_type* _Ptr,
size_type _Count,
size_type _Off = 0
) const;
This method is potentially unsafe, as it relies on the caller to check
that the passed values are correct. Consider using
basic_string::_Copy_s instead.
size_type _Copy_s(
value_type *_Dest,
size_type _Dest_size,
size_type _Count,
size_type _Off = 0
) const;
--------------------------------------------
Hmm, It also relies on the caller to send the correct value in
_Dest_size. If I am too incompetent to send a valid _Count, how do
they expect me to send a valid _Dest_size?
Even worse for read:
-------------------------------------------
basic_istream& read(
char_type *_Str,
streamsize _Count
);
This method is potentially unsafe, as it relies on the caller to check
that the passed values are correct. Consider using
basic_istream::_Read_s instead.
basic_istream& _Read_s(
char_type *_Str,
size_t _Str_size,
streamsize _Count
);
-------------------------------
So this is only ever useful if I am idiot enough to call this method
with _Count _Str_size.
By all mean, deprecate functions like sprintf that have no way
toindicate a maximum size. However, all they have done is duplicate
an already exisiting safety mechanism. By all mean, it might, just
might catch a couple of errors but mostly poor code will look like:
#define MAX_SIZE 20;
char c[MAX_SIZE];
cin._Read_s(&c[0], MAX_SIZE, MAX_SIZE);
which has the same bug as:
#define MAX_SIZE 20;
char c[MAX_SIZE];
cin.read(&c[0], MAX_SIZE); // or cin.read(c, sizeof(c))
Bunch of ....
Yannick
On Oct 11, 5:03*pm, Jeff Schwab <j...@schwabcenter.comwrote:
Ian Collins wrote:
Jeff Schwab wrote:
Pete Becker wrote:
On 2008-10-09 09:33:41 -0400, "A.Leopold"
<andreas.leop...@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?
Probably in shops which prefer libraries which work as
specified.
IME, it's vanishingly rare, and generally a sign of
incompetence.
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.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze wrote:
On Oct 11, 5:03 pm, Jeff Schwab <j...@schwabcenter.comwrote:
>Ian Collins wrote:
>>Jeff Schwab wrote:
Pete Becker wrote:
On 2008-10-09 09:33:41 -0400, "A.Leopold"
<andreas.leop...@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?
Probably in shops which prefer libraries which work as
specified.
>IME, it's vanishingly rare, and generally a sign of
incompetence.
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.
He didn't say it was used where necessary, he said people preferred it.
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).
On Oct 15, 5:20*pm, Jeff Schwab <j...@schwabcenter.comwrote:
James Kanze wrote:
On Oct 11, 5:03 pm, Jeff Schwab <j...@schwabcenter.comwrote:
Ian Collins wrote:
Jeff Schwab wrote:
Pete Becker wrote:
On 2008-10-09 09:33:41 -0400, "A.Leopold"
<andreas.leop...@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?
Probably in shops which prefer libraries which work as
specified.
IME, it's vanishingly rare, and generally a sign of
incompetence.
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.
He didn't say it was used where necessary, he said people
preferred it.
Yes. People prefer it because they know what they are getting.
The fact that most implementations didn't implement what the
standard required in the <c...headers meant that using them
meant that you didn't know what you were getting.
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.
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."
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze wrote:
On Oct 15, 5:20 pm, Jeff Schwab <j...@schwabcenter.comwrote:
>James Kanze wrote:
>>On Oct 11, 5:03 pm, Jeff Schwab <j...@schwabcenter.comwrote:
Ian Collins wrote:
>>>>That depends on which header you include. From what I've
seen, people still prefer <stdio.hover <cstdio>.
>>>Where are you seeing this?
>>Probably in shops which prefer libraries which work as
specified.
>>>IME, it's vanishingly rare, and generally a sign of
incompetence.
>>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.
>He didn't say it was used where necessary, he said people
preferred it.
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.
Yes. People prefer it because they know what they are getting.
The fact that most implementations didn't implement what the
standard required in the <c...headers meant that using them
meant that you didn't know what you were getting.
Which leads to porting issues when one compiler does and another does not.
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.
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?
--
Ian Collins
On 2008-10-11 11:03:51 -0400, Jeff Schwab <je**@schwabcenter.comsaid:
Ian Collins wrote:
>Jeff Schwab wrote:
>>Pete Becker wrote:
On 2008-10-09 09:33:41 -0400, "A.Leopold" <an*************@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.
--
Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
( www.petebecker.com/tr1book)
Pete Becker wrote:
On 2008-10-11 11:03:51 -0400, Jeff Schwab <je**@schwabcenter.comsaid:
>Ian Collins wrote:
>>Jeff Schwab wrote:
Pete Becker wrote:
On 2008-10-09 09:33:41 -0400, "A.Leopold" <an*************@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.
[snipped conversation re. C <file.hvs. C++ <cfileheaders.]
James Kanze wrote:
On Oct 15, 5:20 pm, Jeff Schwab <j...@schwabcenter.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 "vanishingly 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.
On 2008-10-16 13:12:04 -0400, Jeff Schwab <je**@schwabcenter.comsaid:
Pete Becker wrote:
>On 2008-10-11 11:03:51 -0400, Jeff Schwab <je**@schwabcenter.comsaid:
>>Ian Collins wrote:
Jeff Schwab wrote:
Pete Becker wrote:
>On 2008-10-09 09:33:41 -0400, "A.Leopold" <an*************@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)
Pete Becker wrote:
On 2008-10-16 13:12:04 -0400, Jeff Schwab <je**@schwabcenter.comsaid:
>Pete Becker wrote:
>>On 2008-10-11 11:03:51 -0400, Jeff Schwab <je**@schwabcenter.comsaid:
Ian Collins wrote:
Jeff Schwab wrote:
>Pete Becker wrote:
>>On 2008-10-09 09:33:41 -0400, "A.Leopold"
>><an*************@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.
They're long since deprecated. They exist primarily for C
compatibility. [diff.mods.to.headers]: "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 "incompetence," 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.
On 2008-10-16 15:04:21 -0400, Jeff Schwab <je**@schwabcenter.comsaid:
Pete Becker wrote:
>On 2008-10-16 13:12:04 -0400, Jeff Schwab <je**@schwabcenter.comsaid:
>>Pete Becker wrote:
On 2008-10-11 11:03:51 -0400, Jeff Schwab <je**@schwabcenter.comsaid:
Ian Collins wrote:
>Jeff Schwab wrote:
>>Pete Becker wrote:
>>>On 2008-10-09 09:33:41 -0400, "A.Leopold" <an*************@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.
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.headers]:
"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 "incompetence," 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)
Pete Becker wrote:
P.S.: please don't reply by e-mail. I read newsgroup messages on
newsgroups.
Sorry about that; misconfigured thunderbird.
On 2008-10-16 16:04:03 -0400, Jeff Schwab <je**@schwabcenter.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)
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 "reinstatement" (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.
On 2008-10-16 17:28:33 -0400, Gennaro Prota <gennaro/pr***@yahoo.comsaid:
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)
On Oct 16, 7:12 pm, Jeff Schwab <j...@schwabcenter.comwrote:
[snipped conversation re. C <file.hvs. C++ <cfileheaders.]
James Kanze wrote:
On Oct 15, 5:20 pm, Jeff Schwab <j...@schwabcenter.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 "vanishingly
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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Oct 16, 11:28 pm, Gennaro Prota <gennaro/pr...@yahoo.comwrote:
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 "reinstatement"
(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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze wrote:
On Oct 16, 7:12 pm, Jeff Schwab <j...@schwabcenter.comwrote:
>[snipped conversation re. C <file.hvs. C++ <cfileheaders.]
>James Kanze wrote:
>>On Oct 15, 5:20 pm, Jeff Schwab <j...@schwabcenter.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 "vanishingly
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.
On 2008-10-17 05:00:14 -0400, James Kanze <ja*********@gmail.comsaid:
On Oct 16, 11:28 pm, Gennaro Prota <gennaro/pr...@yahoo.comwrote:
>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.
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)
Pete Becker wrote:
On 2008-10-18 11:41:13 -0400, Gennaro Prota <gennaro/pr***@yahoo.comsaid:
[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.
On 2008-10-18 12:11:10 -0400, Gennaro Prota <gennaro/pr***@yahoo.comsaid:
Pete Becker wrote:
>On 2008-10-18 11:41:13 -0400, Gennaro Prota <gennaro/pr***@yahoo.comsaid:
[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)
On Oct 17, 1:40*pm, Pete Becker <p...@versatilecoding.comwrote:
On 2008-10-17 05:00:14 -0400, James Kanze <james.ka...@gmail.comsaid:
On Oct 16, 11:28 pm, Gennaro Prota <gennaro/pr...@yahoo.comwrote:
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.
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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Frank Neuhaus |
last post by:
Hey
Iam occaisonally using something like
char buffer;
sprinf(buffer,"Hello test %d %s",someint,somestring);
Is there any _convenient_ and buffer overflow secure equivalent for that
using...
|
by: ios |
last post by:
Hi
Can someone tell me what is different between below case?
strcpy(eventname, "MDCX_RSP");
and
sprintf(eventname, "MDCX_RSP");
Thanks,
Leon
|
by: William Stacey [MVP] |
last post by:
If val is a long, what is the String format conversion of this in c#? TIA!
sprintf(retbuf,"%d.%.2d", val/100, val%100);
--
William Stacey
|
by: adamrobillard |
last post by:
Hi,
I went through most of the FAQ but did not find any direct references
formatting outputed data. If I have a application in C like so:
void main(void)
{
int nValue = 100;
double...
|
by: Saurabh |
last post by:
Hi all,
I am working on RedHat Linux GCC 3.0.
I am trying to convert a long to string through sprintf.
but i m getting segmantation fault.
I tried snprintf also but no avail.here is the piece...
|
by: gyan |
last post by:
Hi All,
I am using sprintf and getting starnge output in following case
char temp_rn;
memset(temp_rn,'\0',12);
sprintf(temp_rn,"0%s",temp_rn);
the final value in temp_rn is 00
how it...
|
by: jasonwthompson |
last post by:
I'm converting some old C code to C++. Although I'm not concerned
about converting every C item to C++ I'm in a situation in which using
an ostringstream makes more sense than using sprintf. ...
|
by: Ron Ford |
last post by:
I'm looking for a freeware c99 compiler for windows. I had intended to use
MS's Visual C++ Express and use its C capability. In the past with my MS
products, I've simply needed to make .c the...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
