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 ?

 

[Tim Love]

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 ?

printf's expecting a C-style char-array "string". Give it what it wants
by using
printf ("%s", t.c_string());
or (better) use C++'s
cout << t;

 

[Stephane Wirtel]

Joah Senegal said the following on 14/09/2006 14:44:

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;
}

You try tu use std::string with printf.

printf is a function of library C

now, you can do it with t.c_str(), but it's not very c++ compliant.

try this code:

#include <iostream>
#include <string>

int main( int argc, char *argv[] ) {
std::string t = "tes";
std::cout << t;
return EXIT_SUCCESS;
}

 

[red floyd]

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

using namespace std;

int main(int argc, char *argv[])
{
string t = "tes";
printf ("%s", t ); cout << t << endl;
system("PAUSE");
return EXIT_SUCCESS;
}

If you *must* use printf, then pass t.c_str(), and you must include
<cstdio>. A std::string does not automagically convert to a char*. Why
did you include <iostream> if you weren't going to use it?

 

[Pete Becker]

You try tu use std::string with printf.

printf is a function of library C

now, you can do it with t.c_str(), but it's not very c++ compliant.

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

--

-- Pete

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

 

[Stephane Wirtel]

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.

Stephane

 

[Pete Becker]

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? Do you also refuse to use sin, cos, etc. because
they're C?

--

-- Pete

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

 

[Stephane Wirtel]

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

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

You are right, sorry for my previous answer.

 

[Kai-Uwe Bux]

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

 

[Pete Becker]

To some degree, it does: you are loosing a bit of typesafety by using the
printf() family.

That's different. There are reasons to choose C++ streams, and reasons
to choose printf. There is no reason for a blanket refusal to use C,
which is what I was replying to.

Besides, "pollute" is a loaded term and has a non-technical aspect to its
meaning.

Yes, that's why I used it.

In that aesthetical sense, printf() clearly pollutes a program --
at least in my eyes

But, again, this wasn't about the merits of printf, but of C in general.

--

-- Pete

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

 

[Fred Kleinschmidt]

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


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?

 

[Nate Barney]

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]

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]

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]

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_limits<> 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]

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]

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

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

 

[Pete Becker]

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.