By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,963 Members | 1,714 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,963 IT Pros & Developers. It's quick & easy.

printf and string s

P: n/a
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 ?
Sep 14 '06 #1
Share this Question
Share on Google+
18 Replies


P: n/a
"Joah Senegal" <bl****@hva.nlwrites:
>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;

Sep 14 '06 #2

P: n/a
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;
}
Sep 14 '06 #3

P: n/a
Joah Senegal wrote:
>
#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 <iostreamif you weren't going to use it?

Sep 14 '06 #4

P: n/a
Stephane Wirtel wrote:
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.
Sep 14 '06 #5

P: n/a
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
Sep 14 '06 #6

P: n/a
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? 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.
Sep 14 '06 #7

P: n/a
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.
Sep 14 '06 #8

P: n/a
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
Sep 14 '06 #9

P: n/a
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.
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.
Sep 14 '06 #10

P: n/a

"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
Sep 14 '06 #11

P: n/a
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
Sep 14 '06 #12

P: n/a
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.
Sep 14 '06 #13

P: n/a

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.

Sep 14 '06 #14

P: n/a
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_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
Sep 14 '06 #15

P: n/a
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.

Sep 15 '06 #16

P: n/a
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
Sep 15 '06 #17

P: n/a
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
Sep 19 '06 #18

P: n/a
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.
Sep 19 '06 #19

This discussion thread is closed

Replies have been disabled for this discussion.