printf and string s

[Joah Senegal]

Hello all,

I'm trying to print a string on my screen... But the string comes from a
variable string... This is the code

#include <cstdlib>
#include <iostream>
#include <string>

using namespace std;

int main(int argc, char *argv[])
{
string t = "tes";
printf ("%s", t );
system("PAUSE") ;
return EXIT_SUCCESS;
}
But this isn;t working.... the program is crashing when doing printf...
anyone know how to fix this ?

[Fred Kleinschmidt]

"Kai-Uwe Bux" <jk********@gmx .netwrote in message
news:ee******** **@murdoch.acc. Virginia.EDU...

Pete Becker wrote:

>Stephane Wirtel wrote:

>>>Code that uses it is well-formed and portable, so "compliant" here must
mean something else. Care to elaborate?

I don't want to use C and C++ in the same source, it's C (printf, libc)
or C++ (std::cout, std::string, STL, ...) and not both.

printf is C, but it's also C++. Does the fact that it's part of C
somehow pollute it?

To some degree, it does: you are loosing a bit of typesafety by using the
printf() family. Otherwise, the compiler would have complained about the
OPs attempt to pass a std::string. This relates to their C heritage in
that
strict typing is not that much of an issue in C (after all C does not use
type information for overload resolution and templates).

Besides, "pollute" is a loaded term and has a non-technical aspect to its
meaning. In that aesthetical sense, printf() clearly pollutes a program --
at least in my eyes :)

>Do you also refuse to use sin, cos, etc. because they're C?

Nope, those are typesafe despite coming from C. (However, in my eyes these
also polute a program but for a different reason: you are calling a
function with a somewhat ill-defined contract: the standard says that
sin(x) computes the sin of x, which is a lie for almost all values of x.
What it actually computes is some unspecified approximation to the sin of
x. Thus, precision guarantess become a portability issue.)

Best

Kai-Uwe Bux

So I presume you also avoid using float or double, since they, too,
obviously "pollute" your program with "somewhat ill-defined" values?

--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Software Reuse Project

[Nate Barney]

Fred Kleinschmidt wrote:

"Kai-Uwe Bux" <jk********@gmx .netwrote in message
news:ee******** **@murdoch.acc. Virginia.EDU...

>Pete Becker wrote:

>>Do you also refuse to use sin, cos, etc. because they're C?

Nope, those are typesafe despite coming from C. (However, in my eyes these
also polute a program but for a different reason: you are calling a
function with a somewhat ill-defined contract: the standard says that
sin(x) computes the sin of x, which is a lie for almost all values of x.
What it actually computes is some unspecified approximation to the sin of
x. Thus, precision guarantess become a portability issue.)

I believe the standard says that sin(x) computes the sine of x to some
implementation-defined precision, which is true. In practice, every
compiler that I've seen uses IEEE 784 floating-point numbers, but your
compiler's documentation should tell you what representation is used, so
there should be no surprises.

So I presume you also avoid using float or double, since they, too,
obviously "pollute" your program with "somewhat ill-defined" values?

I agree that the above argument is rather specious, but it doesn't
negate the overall point that I think this discussion is about. Namely,
that there is often a "C++ Way" of doing things that supersedes the
older "C Way" of doing things. The C standard (C90, I believe) is
indeed part of the C++ standard, so using stdio is perfectly valid C++.
Personally, I feel that it's better to use the "C++ Way" of doing
things (iostreams, in this example) when writing C++ code, unless
there's a good reason for it. I think most C++ programmers would agree
with me.

Nate

[Pete Becker]

Nate Barney wrote:

>
I believe the standard says that sin(x) computes the sine of x to some
implementation-defined precision, which is true.

The precision of the computation of sin is not specified, nor is it
implementation-defined.

In practice, every
compiler that I've seen uses IEEE 784 floating-point numbers, but your
compiler's documentation should tell you what representation is used, so
there should be no surprises.

That's two different things. IEE 754 tells you (if I remember correctly)
the minimum number of bits in the significand of a float and of a
double, as well as the minimum number of bits in the exponent. That, in
turn, tells you the maximum precision and range that you can rely on in
portable code. Results of floating-point computations often lose low
bits, so turn out to be less precise than the representation supports
and, often, less precise than a more careful implementation of that same
computation would be. For example, Dinkumware spent most of a year
implementing the special math functions in TR1, burning thousands of
hours of computer time checking results and revising algorithms. The
resulting functions are far better than anything else that's available.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

[Noah Roberts]

Kai-Uwe Bux wrote:

Pete Becker wrote:

Stephane Wirtel wrote:

>Code that uses it is well-formed and portable, so "compliant" here must
mean something else. Care to elaborate?

I don't want to use C and C++ in the same source, it's C (printf, libc)
or C++ (std::cout, std::string, STL, ...) and not both.

printf is C, but it's also C++. Does the fact that it's part of C
somehow pollute it?

To some degree, it does: you are loosing a bit of typesafety by using the
printf() family. Otherwise, the compiler would have complained about the
OPs attempt to pass a std::string. This relates to their C heritage in that
strict typing is not that much of an issue in C (after all C does not use
type information for overload resolution and templates).

Unfortunately, there is standard replacement for the formatting
functionality found in the printf family. The stream formatting
mechanisms are quite limited.

[Kai-Uwe Bux]

Fred Kleinschmidt wrote:

>
"Kai-Uwe Bux" <jk********@gmx .netwrote in message
news:ee******** **@murdoch.acc. Virginia.EDU...

>Pete Becker wrote:

[snip]

>>Do you also refuse to use sin, cos, etc. because they're C?

Nope, those are typesafe despite coming from C. (However, in my eyes
these also polute a program but for a different reason: you are calling a
function with a somewhat ill-defined contract: the standard says that
sin(x) computes the sin of x, which is a lie for almost all values of x.
What it actually computes is some unspecified approximation to the sin of
x. Thus, precision guarantess become a portability issue.)

[snip]

>
So I presume you also avoid using float or double, since they, too,
obviously "pollute" your program with "somewhat ill-defined" values?

The contracts for double and float are way better defined: through
std::numeric_li mits<you can investigate the precision of the built-in
floating point types, e.g., via epsilon. However, there is no standard way
to obtain assurances about the accuracy of sin() or cos().
Best

Kai-Uwe Bux

[microx]

To some degree, it does: you are loosing a bit of typesafety by using the

printf() family. Otherwise, the compiler would have complained about the
OPs attempt to pass a std::string. This relates to their C heritage in that
strict typing is not that much of an issue in C (after all C does not use
type information for overload resolution and templates).

Using things like printf() doesn't suddenly transform your program back
into C. It's still a C++ program, it's just using a function that used
to exist in C. One could argue that since it's C++, you should use the
more "modern" cout method, but cout is no more a feature of C++ than
printf(), it just so happens that printf() used to exist in C, and
people thought up cout after they thought up printf(). Still, there is
nothing else as flexible as printf() in C++.

Besides, I never liked the "cout << foo << bar << endl" style syntax
anyway, it doesn't make sense. The function call form for a printing
function is more readable, and more easily understood.

[Kai-Uwe Bux]

microx wrote:

>To some degree, it does: you are loosing a bit of typesafety by using the
printf() family. Otherwise, the compiler would have complained about the
OPs attempt to pass a std::string. This relates to their C heritage in
that strict typing is not that much of an issue in C (after all C does
not use type information for overload resolution and templates).

Using things like printf() doesn't suddenly transform your program back
into C. It's still a C++ program, it's just using a function that used
to exist in C.

So far, we are in agreement; and I think you are not contradicting anything
I claimed.

One could argue that since it's C++, you should use the
more "modern" cout method, but cout is no more a feature of C++ than
printf(), it just so happens that printf() used to exist in C, and
people thought up cout after they thought up printf(). Still, there is
nothing else as flexible as printf() in C++.

I never said what you "should" do or not. I just said that using the
printf() family has certain drawbacks. These drawbacks are not unrelated to
those functions coming from C.

>Still, there is nothing else as flexible as printf() in C++.

It depends on what you mean by flexible: you can overload operator>and
operator<< for your own classes. In my book, that makes those tools far
more flexible than the printf() family where you cannot introduce new
formating options to accommodate for user defined types.

Besides, I never liked the "cout << foo << bar << endl" style syntax
anyway, it doesn't make sense. The function call form for a printing
function is more readable, and more easily understood.

That is very much a personal or cultural thing and depends on what you are
used to. I find the printf() family harder to use since those functions
essentially implement an auxiliary formating language, which is far too
terse for me. I prefer a more verbose style. But that is entirely a matter
of style and taste. The technical differences lies in type-safety and
support for user defined types. In this regard, printf() looses to
operator<<.
Best

Kai-Uwe Bux

[Mike Smith]

Pete Becker wrote:

Stephane Wirtel wrote:

>>Code that uses it is well-formed and portable, so "compliant" here must
mean something else. Care to elaborate?

I don't want to use C and C++ in the same source, it's C (printf, libc)
or C++ (std::cout, std::string, STL, ...) and not both.

printf is C, but it's also C++.

Well, it's not very *idiomatic* C++, given the existence of iostreams.

--
Mike Smith

[Pete Becker]

Mike Smith wrote:

Pete Becker wrote:

>Stephane Wirtel wrote:

>>>Code that uses it is well-formed and portable, so "compliant" here must
mean something else. Care to elaborate?

I don't want to use C and C++ in the same source, it's C (printf, libc)
or C++ (std::cout, std::string, STL, ...) and not both.

printf is C, but it's also C++.

Well, it's not very *idiomatic* C++, given the existence of iostreams.

It's idiomatic C++ if it's simpler to do the job with printf than it is
with iostreams.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.