Re: ios output width

On Dec 6, 5:27 pm, Ralf Goertz
<r_goe...@expires-2006-11-30.arcornews.de> wrote:


You can't. An ostream will never output a field with less width
than is necessary to display it correctly, so any value outside
the range of [-9...99] will display wider.


ostream_iterator is pretty worthless as classes go. You'll have
to write your own if you want anything but the simplest
formatting. (The implementation shouldn't be that difficult.
Defining the interface so that you don't have to specify more
than you need is far from trivial, however.)


That's the convention.

You could write a class along the lines of:

    class FixedWidthInt
    {
    public:
        FixedWidthInt( int i ) : i( i ) {}
        friend std::ostream& operator<<(
            std::ostream& dest,
            FixedWidthInt const&obj )
        {
            int w = dest.width() ;
            dest << obj.i ;
            dest.width( w ) ;
            return *dest ;
        }
    private:
        int i ;
    } ;

and invoke:

    std::cout.width( 2 ) ;
    copy( v.begin(), v.end(),
          std::ostream_iterator< FixedWidthInt >( std::cout ) ) ;

I don't like it, though; it more or less changes the expected
behavior of the ostream. Alternatively, if the width is always
constant, you could use a template:

    template< int w >
    class FixedWidthInt
    {
    public:
        FixedWidthInt( int i ) : i( i ) {}
        friend std::ostream& operator<<(
            std::ostream& dest,
            FixedWidthInt const&obj )
        {
            dest << std::setw( w ) << obj.i ;
            return *dest ;
        }
    private:
        int i ;
    } ;

    // ...

    copy( v.begin(), v.end(),
          std::ostream_iterator< FixedWidthInt< 2 > >( std::cout ) ) ;

This seems more acceptable to me, since you aren't counting on
the width not changing. (I.e. this FixedWidthInt doesn't cause
the width not to be reset, against expectations of a <<
operator. The preceding one does.)

Finally, you could arrange that FixedWidthInt get the width, not
from a template argument (which must be a compile time
constant), but from a special format field, set by
maniipulators. Something like the following:

    class FixedWidthBase
    {
    public:
        static long width( std::ios& stream )
        {
            return stream.iword( index() ) ;
        }

        static long width( std::ios& stream, long newWidth )
        {
            std::swap( stream.iword( index() ), newWidth ) ;
            return newWidth ;
        }

    private:
        static int index()
        {
            if ( ourWidth < 0 ) {
                ourWidth = std::ios::xalloc() ;
            }
            return ourWidth ;
        }
        static int ourWidth ;
    } ;

    int FixedWidthBase::ourWidth = -1 ;

    template< typename T >
    class FixedWidth : private FixedWidthBase
    {
    public:
        FixedWidth( T const& value )
            : myValue( value )
        {
        }

        friend std::ostream&
                            operator<<(
                                std::ostream& dest,
                                FixedWidth const& obj )
        {
            dest << std::setw( width( dest ) ) << obj.myValue ;
            return dest ;
        }

    private:
        T myValue ;
    } ;

    int
    fixedwidth(
        std::ios& stream,
        int newWidth )
    {
        return FixedWidthBase::width( stream, newWidth ) ;
    }

    // ...

    fixedwidth( std::cout, 3 ) ;
    std::copy(
            v.begin(), v.end(),
            std::ostream_iterator< FixedWidth< int > >( std::cout,
"\n" ) ) ;


See above. The real solution is to design and implement an
ostream_iterator that is useful, but that's decidedly
non-trivial. Failing that, I suspect that the template version
of FixedWidth that I propose above might be a useful snippet.

Another important thing to remember: there is no requirement
that the type of the ostream_iterator be the same as the type
you are writing. All you need is that the type you are writing
be convertible to it. You can do an awful lot with user defined
classes along the lines of those above. (It's far from perfect,
but it solves a lot of problems with ostream_iterator.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34