i/o Fortran's format commands in c++

[maria]

I 've decided it's time to move from fortran to c++, but i cant find
out if c++ supposrts I/O format commands like the ones in fortran 77.
I would be gratefull for any help.
Thank you

 

[Jacques Labuschagne]

I 've decided it's time to move from fortran to c++, but i cant find
out if c++ supposrts I/O format commands like the ones in fortran 77.
I would be gratefull for any help.
Thank you

You assume we know Fortran. Why not describe how the IO should behave
first?

Jacques

 

[David Harmon]

I 've decided it's time to move from fortran to c++, but i cant find
out if c++ supposrts I/O format commands like the ones in fortran 77.

The printf(), scanf(), etc. library functions, that C++ inherits
from C, provide formatted I/O somewhat reminiscent of Fortran formatted
I/O. Most C++ programmers prefer the standard iostreams library for
type safety and extensibility.

See the section "[15] Input/output via <iostream> and <cstdio>" in
Marshall Cline's C++ FAQ. It is always good to check the FAQ before
posting. You can get the FAQ at:
http://www.parashift.com/c++-faq-lite/

 

[E. Robert Tisdale]

I 've decided that it's time to move from Fortran to C++
but I can't find out if C++ supports I/O format commands
like the ones in fortran 77.

Why can't you find out?
Do you have a C++ text book?

The C computer programming language has format *strings*


PRINTF(3) Linux Programmer’s Manual PRINTF(3)

NAME
printf, fprintf, sprintf, snprintf, vprintf, vfprintf,
vsprintf, vsnprintf - formatted output conversion

SYNOPSIS
#include <stdio.h>

int printf(const char *format, ...);
int fprintf(FILE *stream, const char *format, ...);
int sprintf(char *str, const char *format, ...);
int snprintf(char *str, size_t size, const char *format, ...);

 

[Nick Hounsome]

The printf(), scanf(), etc. library functions, that C++ inherits
from C, provide formatted I/O somewhat reminiscent of Fortran formatted
I/O. Most C++ programmers prefer the standard iostreams library for
type safety and extensibility.

Do they really?

I think it depends on what you mean by formatted. Personally I find them
extremely clunky for doing what I usualy think of
as formatted I/O i.e. the difference between 0x%06x and %d.

Putting aside the biggest problem which is properly saving and restoring the
base and fill character, including iomanip,
upper versus lower case hex letters and the std namespace you still have:
cout << x << hex << "0x" << setw(6) << setfill('0') << y << dec;
versus
printf("%d 0x%06x",x,y);

I think that the standard should actualy supply a class to save and restore
all this 'stuff' automatically in ctor/dtor e.g.
std::format_state fs(cout);

This is in no way intended to deny that they are wonderful for printing
classes where C has nothing.

See the section "[15] Input/output via <iostream> and <cstdio>" in
Marshall Cline's C++ FAQ. It is always good to check the FAQ before
posting. You can get the FAQ at:
http://www.parashift.com/c++-faq-lite/

 

[David Harmon]

Do they really?
Yes.

I think it depends on what you mean by formatted.

Formatted means converted to or from a legible character representation.
printf() and scanf() are formatted. read() and write() are raw or

Personally I find them
extremely clunky for doing what I usualy think of
as formatted I/O i.e. the difference between 0x%06x and %d.

Both of those are formatted. Come on, this isn't rocket science.

 

[Jeff Flinn]

Do they really?

I think it depends on what you mean by formatted. Personally I find them
extremely clunky for doing what I usualy think of
as formatted I/O i.e. the difference between 0x%06x and %d.

Putting aside the biggest problem which is properly saving and restoring the
base and fill character, including iomanip,
upper versus lower case hex letters and the std namespace you still have:
cout << x << hex << "0x" << setw(6) << setfill('0') << y << dec;
versus
printf("%d 0x%06x",x,y);

I think that the standard should actualy supply a class to save and restore
all this 'stuff' automatically in ctor/dtor e.g.
std::format_state fs(cout);

See http://www.boost.org/libs/io/doc/ios_state.html which saves the state as
you desire. If you still insist on printf, see
http://www.boost.org/libs/format/index.htm for a typesafe version.

Jeff F

 

[Nick Hounsome]

See http://www.boost.org/libs/io/doc/ios_state.html which saves the state as
you desire. If you still insist on printf, see
http://www.boost.org/libs/format/index.htm for a typesafe version.

Jeff F

Great but you will see that I said "I think that the standard should actualy
supply ...."

 

[Rob Williscroft]

Nick Hounsome wrote in

I think that the standard should actualy supply a class to save and
restore all this 'stuff' automatically in ctor/dtor e.g.
std::format_state fs(cout);

void f( int i )
{
std:stream os( cout.rdbuf() );
os << std::hex << i;
}

Rob.

 

[Jeff Flinn]

....

....
state

Great but you will see that I said "I think that the standard should actualy
supply ...."

Considering the large number of facilities from boost that have been
proposed in TR1, perhaps with a little prodding the ios_state could be
proposed for TR2, then your wish could be reality.

Jeff F

 

[Nick Hounsome]

Nick Hounsome wrote in


void f( int i )
{
std:stream os( cout.rdbuf() );
os << std::hex << i;
}

not bad!
probably a bit heavyweight but it will do the job.
thanks for the tip.

 

[Old Wolf]

I 've decided it's time to move from fortran to c++, but i cant find

Personally I find them extremely clunky

cout << x << hex << "0x" << setw(6) << setfill('0') << y << dec;

Or, if you follow the advice of some, it's even worse:
std::cout << x << std::hex << "0x" << std::setw(6)
<< std::setfill('0') << y << std::dec;

versus
printf("%d 0x%06x",x,y);

This is perfectly good and correct C++, nobody is forcing you to
use iostreams. If you want to avoid memory-allocation with sprintf
in general, write a small function that uses vsnprintf() to put the
output in a std::string instead of a char* . If you want type-safety,
use boost::format (although I avoid this because it slows down the
build a lot, without precompiled headers).

 

[Jeff Flinn]

Or, if you follow the advice of some, it's even worse:
std::cout << x << std::hex << "0x" << std::setw(6)
<< std::setfill('0') << y << std::dec;


This is perfectly good and correct C++, nobody is forcing you to

Without type-safety I'd venture to say that printf is not "perfectly good"
and not "perfectly correct.

use iostreams. If you want to avoid memory-allocation with sprintf
in general, write a small function that uses vsnprintf() to put the
output in a std::string instead of a char* . If you want type-safety,

How does this avoid memory allocation?

Jeff F

 

[Nick Hounsome]

[snip]

Without type-safety I'd venture to say that printf is not "perfectly good"
and not "perfectly correct.

gnu compilers check all the printf args for you (provided the format string
is a literal)
I know it's not a language thing but it is pretty helpful.

 

[Robert Paul Clark]

Look at:
ftp://www.instructor.com/CPPClass/CPPClassDirTree/Solution/FRI/MPRINTF.H

It's a C++ class that basically wraps printf() so that you can call it as a
function and use it with cout.

Ex:
cout << mprintf("Hey %d", 2);

 

[Nick Hounsome]

Look at:
ftp://www.instructor.com/CPPClass/CPPClassDirTree/Solution/FRI/MPRINTF.H

It's a C++ class that basically wraps printf() so that you can call it as a
function and use it with cout.

Ex:
cout << mprintf("Hey %d", 2);

This is a disaster - I looked at it and it uses vsprintf into an auto (don't
use the keyword auto) 1K buffer.
Do you work for Microsoft by any chance?

 

[Robert Paul Clark]

I have no association with the code. But, I'd say that the author thoroughly
documents the 1K buffer size and attempts to report buffer overflows.

Any further whining on your part should probably be directed at the author -
indicated in the source.

 

[tom_usenet]

Great but you will see that I said "I think that the standard should actualy
supply ...."

First write it, then use it, then it will be standardized.
Standardization is about standardizing existing practice, not
inventing new things. Standardization committees tend to get it wrong
when they try to invent things...

Tom

C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

 

[Old Wolf]

It's a C++ class that basically wraps printf() so that you can call it as

This is a disaster - I looked at it and it uses vsprintf into an auto (don't
use the keyword auto) 1K buffer.
Do you work for Microsoft by any chance?

Try this one
(warning 1: untested code follows)
(warning 2: this will fail miserably if your implementation of
vsnprintf is broken - test your compiler's one first,
or download a free one from somewhere and check it)

#include <string>
#include <cstdio> // or wherever you have vsnprintf()
#include <cstdarg>

std::string str_printf(const char *fmt, ...)
{
va_list ap;
va_start (ap, fmt);
int size = vsnprintf(NULL, 0, fmt, ap);
if (size < 1) return std::string();
char *buf = new char[size+1];
va_end(ap);
va_start(ap, fmt);
vsnprintf(buf, size+1, fmt, ap);
std::string ret(buf);
delete [] buf;
return ret;
}

There is the speed disadvantage (ie. it formats everything twice to work
out the amount of memory needed), so engage your brain if you
are going to call this in a bottleneck situation.

 

[Simon Elliott]

This is perfectly good and correct C++, nobody is forcing you to
use iostreams. If you want to avoid memory-allocation with sprintf
in general, write a small function that uses vsnprintf() to put the
output in a std::string instead of a char* .

I've never used vsnprintf(). It looks useful. It seems that Borland C++
Builder 3 doesn't support it (though C++ Builder 6 does.)

How widespread is support for vsnprintf?

Is it now part of the standard C library?

Is there any public domain source for it?