Re: [boost] Re: io operations for stl containers?

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-03-09 18:45:49

>From: "Jason House" <jhouse_at_[hidden]>

> Terje Slettebø wrote:
> >
> > >From: "Jason House" <jhouse_at_[hidden]>
> >
> > > Is there even a way to specify/change that?
> >
> > It isn't currently, as the fundamental types aren't handled as composite
> > types, and therefore aren't formatted using any set format. Also, it
seems
> > it may not be possible in an obvious way.
> > <snip>
> > It appears to prefer the operator<<(char) stream member function, to
this
> > free function, as it isn't called when doing "std::cout << 'A';".
>
> :(
> It would be a good question to figure out why that won't work, and how
> to fix it...  What happens, in general, if somebody want to override a
> stream operator to do something else?

Well, outputting UDTs work fine, as you can then overload the operator<<.
However, as it's already overloaded, as a member function of the stream
class, for the built-in types, it doesn't help to overload it for them.

> String output probably uses
> character output by default... it would be very bad to have a system
> that made the string "string" (no quotes) output as 's''t''r''i''n''g'

Yeah. :) basic_istream/basic_ostream have overloaded stream operators for
CharType *, so they handle strings, in other words, the iostream versions of
gets()/puts().

> > > Debugger friendly manipulation would be good.  I still haven't thought
> > > about how exactly outputting of an arbitrary composite variable will
> > > work in the debugger by default...  I agree that having a wrapper
makes
> > > it easy for the output formatting of general types, but actually being
> > > able to execute "std::cout << my_suspect_variable" in the debugger
> > > without premeditation still poses a significant problem.  Why can't
bugs
> > > be predicted before you notice them?
> >
> > You're right, good point. Would it be possible to get some information
on
> > what kind of functions, if any, may be called in e.g. your debugger?
From
> > this, we may find what we can do.
>
> Well, I personally haven't gotten into the habit of calling functions
> for any debugger.

Me neither.

> I know that gdb allows that... and last that I tried
> it under the cygwin port, it wasn't very stable (but I kind of expect
> that in a cygwin port).  I do also remember hitting trouble trying to
> call templated types.  I believe that it could make calls to templated
> functions, but you needed to know the "real" name for the function...
> The base function name plus extra characters in order to distinguish
> it...  I might have gotten the "real" name off the call stack or
> something like that...
>
> Does that help to define "my debugger"?  I would hope to make it work
> for as many debuggers as possible (provided that they at least support
> making function calls)

Well, I guess that in either case, this may be handled through layering,
i.e. possibly providing convenience functions which calls the overloaded
stream operators, if the latter is difficult to call from a debugger.

Regards,

Terje