streams and functions

[grahamo]

Hi,

I have written an app that uses streams in a very standard way. I make
use of some legacy code something like this;
// legacy operator<< , standard enough.
ostream& legacy_function::operator<<(args);
cout << legacy_function(args) << endl;
legacy_function(args) simply takes the args and does some fancy
parsing etc and returns a ostream object in the usual manner. With
this code in dev, I get all my info on stdout, no problemo.

However, now that I have everything up and running I have to log to a
file instead of stdout, which was ok for development and debugging
purposes.

I am obliged to use another 3rd party api (again!) which takes the
form;

void log_message(const char*);

This will automatially log my char* to a pre-configured logfile.

However I am not sure how I can get from the ostream returned from

ostream& legacy_function::operator<<(args);

to the char* that I need to pass to log_message(const char*).
Do I simply create an instance (something like)
std::ostream output(legacy_function::operator<<(args));
const char* the_char_star_im_after(output.some_method);
I hope I've explained that correctly. I haven't used streams much
(well apart from the obvious use, so forgive me if this is blindingly
obvious).

thanks a million

GrahamO

[John Harrison]

"grahamo" <gr************@hotmail.com> wrote in message
news:79**************************@posting.google.c om...

Hi,

I have written an app that uses streams in a very standard way. I make
use of some legacy code something like this;
// legacy operator<< , standard enough.
ostream& legacy_function::operator<<(args);
cout << legacy_function(args) << endl;
legacy_function(args) simply takes the args and does some fancy
parsing etc and returns a ostream object in the usual manner. With
this code in dev, I get all my info on stdout, no problemo.
I'm surprised that compiles, you seem to be doing this

cout << another_stream;

which is not standard C++ I think.

However, now that I have everything up and running I have to log to a
file instead of stdout, which was ok for development and debugging
purposes.

I am obliged to use another 3rd party api (again!) which takes the
form;

void log_message(const char*);

This will automatially log my char* to a pre-configured logfile.

However I am not sure how I can get from the ostream returned from

ostream& legacy_function::operator<<(args);

to the char* that I need to pass to log_message(const char*).
Do I simply create an instance (something like)
std::ostream output(legacy_function::operator<<(args));
const char* the_char_star_im_after(output.some_method);
I hope I've explained that correctly. I haven't used streams much
(well apart from the obvious use, so forgive me if this is blindingly
obvious).

I think maybe you are looking for std::ostringstream.

Assuming you can get you output into an ostringstream (called buffer say)
then

const char* the_char_star_im_after = buf.str().c_str();

john

[Jerry Coffin]

gr************@hotmail.com (grahamo) wrote in message news:<79**************************@posting.google. com>...

[ ... ]

However, now that I have everything up and running I have to log to a
file instead of stdout, which was ok for development and debugging
purposes.

I am obliged to use another 3rd party api (again!) which takes the
form;

void log_message(const char*);

This will automatially log my char* to a pre-configured logfile.

However I am not sure how I can get from the ostream returned from

ostream& legacy_function::operator<<(args);

to the char* that I need to pass to log_message(const char*).

Create an instance of an ostringstream:

std::ostringstream s;

s << whatever;

log_message(whatever.str().c_str());

A bit clumsy, but effective.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[grahamo]

perfect, thanks a lot for that guys. I was a tad concerned for a moment there,
The compiler (Forte6 on Solaris) barfed on

std::ostringstream output;

but luckily I found this....

std::ostrstream output;
which works. Which one is standard? I'm sure theres a bit of history to it.

thanks again

GrahamO

jc*****@taeus.com (Jerry Coffin) wrote in message news:<b2*************************@posting.google.c om>...

gr************@hotmail.com (grahamo) wrote in message news:<79**************************@posting.google. com>...

[ ... ]

However, now that I have everything up and running I have to log to a
file instead of stdout, which was ok for development and debugging
purposes.

I am obliged to use another 3rd party api (again!) which takes the
form;

void log_message(const char*);

This will automatially log my char* to a pre-configured logfile.

However I am not sure how I can get from the ostream returned from

ostream& legacy_function::operator<<(args);

to the char* that I need to pass to log_message(const char*).

Create an instance of an ostringstream:

std::ostringstream s;

s << whatever;

log_message(whatever.str().c_str());

A bit clumsy, but effective.

[JKop]

grahamo posted:

perfect, thanks a lot for that guys. I was a tad concerned for a moment
there,
The compiler (Forte6 on Solaris) barfed on

std::ostringstream output;

but luckily I found this....

std::ostrstream output;
which works. Which one is standard? I'm sure theres a bit of history to
it.

thanks again

GrahamO

jc*****@taeus.com (Jerry Coffin) wrote in message
news:<b2*************************@posting.google.c om>...

gr************@hotmail.com (grahamo) wrote in message
news:<79**************************@posting.google. com>...

[ ... ]

> However, now that I have everything up and running I have to log to
> a file instead of stdout, which was ok for development and debugging
> purposes.
>
> I am obliged to use another 3rd party api (again!) which takes the
> form;
>
> void log_message(const char*);
>
> This will automatially log my char* to a pre-configured logfile.
>
> However I am not sure how I can get from the ostream returned from
>
> ostream& legacy_function::operator<<(args);
>
> to the char* that I need to pass to log_message(const char*).

Create an instance of an ostringstream:

std::ostringstream s;

s << whatever;

log_message(whatever.str().c_str());

A bit clumsy, but effective.

"std::ostringstream" is standard.

And conversely I belive the header file is "ostrstream", not sure though...

-JKop

[John Harrison]

"grahamo" <gr************@hotmail.com> wrote in message
news:79**************************@posting.google.c om...

perfect, thanks a lot for that guys. I was a tad concerned for a moment there,

The compiler (Forte6 on Solaris) barfed on

std::ostringstream output;

but luckily I found this....

std::ostrstream output;
which works. Which one is standard? I'm sure theres a bit of history to it.
thanks again

GrahamO

ostrstream is historical and deprecated, but still standard. The header file
is <strstream>. The big issue with it is that /you/ must delete[] the
returned char* pointer after calling str(). Also you are responsible for
ensuring that the string is null terminated, the manipulator std::ends is
provided for this purpose.

ostringstream is standard. The header file is <sstream>.

Use ostringstream if you possibly can.

john

[Ron Natalie]

grahamo wrote:

which works. Which one is standard? I'm sure theres a bit of history to it.

They are both standard. stringstream is in <sstream> and stores it's
data in a std::string. This is probably the safer and easier one to
use. strstream is officially deprecated (it predates the standard) is
in the header <strstream> and stores it's data into a char buffer pointed
to by a char*. It obviously has a lot more issues with buffer management.

The one time it is useful is if you have data in already in a char array
you wish to read via a stream. The fact that you can feed a strstream
the buffer pointer directly is a slight improvement in that with a stringstream
you'd have to copy it to a string first. Buffer management in that case
isn't an issue so much as you already have it allocated.

On output, stringstreams win hands down. If you need the char*, just call
the .c_str() or data() member on the string.

[grahamo]

Ah thanks for that. It adds up... when using strstream I saw the leak
happening (was in the process of throwing purify at the code when I
read this reponse and previous one). I wasn't calling delete, hence
the leak. Also, I was including the wrong header, hence the
compilation error. I'll go with the reccommended
sstream/std::ostringstream approach.

thanks much for your help. Works a treat now :)
GrahamO

They are both standard. stringstream is in <sstream> and stores it's
data in a std::string. This is probably the safer and easier one to
use. strstream is officially deprecated (it predates the standard) is
in the header <strstream> and stores it's data into a char buffer pointed
to by a char*. It obviously has a lot more issues with buffer management.

The one time it is useful is if you have data in already in a char array
you wish to read via a stream. The fact that you can feed a strstream
the buffer pointer directly is a slight improvement in that with a stringstream
you'd have to copy it to a string first. Buffer management in that case
isn't an issue so much as you already have it allocated.

On output, stringstreams win hands down. If you need the char*, just call
the .c_str() or data() member on the string.

[grahamo]

meant to say, wasn't calling "delete[]" in previous post.

thanks again

G

which works. Which one is standard? I'm sure theres a bit of history to it.

They are both standard. stringstream is in <sstream> and stores it's
data in a std::string. This is probably the safer and easier one to
use. strstream is officially deprecated (it predates the standard) is
in the header <strstream> and stores it's data into a char buffer pointed
to by a char*. It obviously has a lot more issues with buffer management.

The one time it is useful is if you have data in already in a char array
you wish to read via a stream. The fact that you can feed a strstream
the buffer pointer directly is a slight improvement in that with a stringstream
you'd have to copy it to a string first. Buffer management in that case
isn't an issue so much as you already have it allocated.

On output, stringstreams win hands down. If you need the char*, just call
the .c_str() or data() member on the string.