sprintf equivalent in c++

[James Kanze]

[snipped conversation re. C <file.h> vs. C++ <cfile> headers.]

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>

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 <...h> header, 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 :os_t?

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
<cunistd> or 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]

Pete Becker wrote:

[C headers]

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.)

 

[Gennaro Prota]

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.

Yes, but still I find deprecation of C headers embarrassing, at
best (with all the troubles C++ goes into in order to keep
maximum compatibility with C...)

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

 

[Gennaro Prota]

On 2008-10-18 04:56:01 -0400, Gennaro Prota <gennaro/[email protected]> said: [...]

Yes, but still I find deprecation of C headers embarrassing, at
best (with all the troubles C++ goes into in order to keep
maximum compatibility with C...)

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

Yes.

Promised? ;-)

 

[Gennaro Prota]

On 2008-10-18 11:41:13 -0400, Gennaro Prota <gennaro/[email protected]> said:

[removing deprecation of C headers]

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.

 

[James Kanze]

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]

On 2008-10-18 04:56:01 -0400, Gennaro Prota <gennaro/[email protected]> said:      [...]
Yes, but still I find deprecation of C headers embarrassing, at
best (with all the troubles C++ goes into in order to keep
maximum compatibility with C...)
Couldn't a vote, as James hints at, be proposed on this?
Yes.

Promised? ;-)

[/QUOTE]

Only if someone does it.

Isn't it a little late for that this round?

(As an aside: has any standard actually removed a deprecated
feature? Or does modern Fortran still support EQUIVALENCE?)