Darren New wrote:
> Warp wrote:
>> MyType value = something;
>> std::cout << "The value is: " << value << "\n";
> 
> Here's something I've been wondering about that. Say you have your own 
> type, and you want a set of flags like hex/oct/decimal or setfill or 
> something like that. I.e., you want to be able to say
> 
> std::cout << prettyprintindent(4) << myvalue << "\n";
> 
> Where does the "4" there get stored? And how can you make it so that 
> (say) passing -1 puts back what it was before the previous call for the 
> same stream? It would seem that you'd need some sort of data structure 
> mapping streams to pretty print indent levels, yes? And no automated way 
> of cleaning that up with a destructor?
> 
> What am I missing here?

I believe you would create a separate class which inherits from OStream, 
and give it a data member to store the 4 in.  You would then define the 
function prettyprintindent(int) to return your subclass.  Since it 
inherits, it can still be used like a regular OStream.

...Chambers

Post a reply to this message

On Sun, 04 May 2008 03:39:20 +0200, Darren New <dne### [at] sanrrcom> wrote:
> Here's something I've been wondering about that. Say you have your own
  

> type, and you want a set of flags like hex/oct/decimal or setfill or  

> something like that. I.e., you want to be able to say
>
> std::cout << prettyprintindent(4) << myvalue << "\n";
>
> Where does the "4" there get stored?

Did you not ask this once before?

http://groups.google.com/group/comp.lang.c++.moderated/search?q=custom
+stream+manipulator

Also, look up 'ios::xalloc'.



> And how can you make it so that (say) passing -1 puts back what it was
  

> before the previous call for the same stream?

http://www.boost.org/doc/libs/1_35_0/libs/io/doc/ios_state.html#user_sav
ers

Perhaps not exactly what you meant, but doing it this way avoids resourc
e  

management issues.


> It would seem that you'd need some sort of data structure mapping stre
ams
> to pretty print indent levels, yes? And no automated way of cleaning t
hat
> up with a destructor?

If you impose a fixed (and relatively small) limit on the history size, 
 

you could store all the relevant information in the stream itself. For  

automatic cleanup of arbitrary amounts of per-stream data, I think you  

might need to use custom streams.


-- 

FE

Post a reply to this message

Ben Chambers wrote:
> I believe you would create a separate class which inherits from OStream, 
> and give it a data member to store the 4 in.  You would then define the 
> function prettyprintindent(int) to return your subclass.  Since it 
> inherits, it can still be used like a regular OStream.

Which means you now have two instances pointing to the same stream?

std:cout << pretty(4) << myvalue;
std:cout << myvalue; // No longer pretty(4)?

yadda = (std:cout << pretty(4));
yadda << mine << yours;
// Now what do I do to clean up?

std:cout << pretty(4) << myprettyvalue << magic(15) << mymagicvalue;
// Looks like magic(15) has to understand "pretty" streams?

// Or even
std:cout << pretty(4) << myprettyvalue <<
   magic(15) << mymagicvalue
   << pretty(8) << myprettyvalue;

How many copies of the "pretty" value are going to be in the
thing returned by the final << operator?

Fredrik Eriksson wrote:
> Did you not ask this once before?

Yeah, but not I understand other things a bit better, so I'm trying to 
figure this one out again.  Those links you gave really don't answer the 
question, as they seem to be answering too-simple questions.

Ah, I begin to see. ios can allocate a word in each stream specific to 
your class.

> Also, look up 'ios::xalloc'.

Ok. It looks like it only works for one integer from one user-defined 
type at a time, and if you cast it to a pointer, it still doesn't get 
cleaned up when the stream goes out of scope, because there's no type 
information. Or am I misunderstanding that? If you allocate (say) a 
buffer or something for the stream, at what point does that buffer get 
cleaned up?

So it looks like the answer is either "you can't do this with standard 
streams" or "for very limited cases it's built into the stream class 
already".

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

On Sun, 04 May 2008 23:36:38 +0200, Darren New <dne### [at] sanrrcom> wrote:
>> Also, look up 'ios::xalloc'.
>
> Ok. It looks like it only works for one integer from one user-defined  
> type at a time,

The words allocated with 'ios::xalloc' are not related to any user-defined  
types. They have only whatever meaning you choose to give them.



> and if you cast it to a pointer, it still doesn't get cleaned up when  
> the stream goes out of scope,

Correct. The stream object itself neither knows nor cares what you store  
there.



> If you allocate (say) a buffer or something for the stream, at what  
> point does that buffer get cleaned up?

If you mean "automatically" then not at all.



> So it looks like the answer is either "you can't do this with standard  
> streams" or "for very limited cases it's built into the stream class  
> already".

Depending on your definition of "very limited", yes.



-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:
> The words allocated with 'ios::xalloc' are not related to any 
> user-defined types. They have only whatever meaning you choose to give 
> them.

Right, OK.

>> and if you cast it to a pointer, it still doesn't get cleaned up when 
>> the stream goes out of scope,
> 
> Correct. The stream object itself neither knows nor cares what you store 
> there.

Yeah. I'd just been thinking about Warp's example earlier that needed 
"weak" references to actually not "leak" resources. I was trying to 
figure out how C++ handled it, if at all.

> If you mean "automatically" then not at all.

OK.

> Depending on your definition of "very limited", yes.

By "limited" I mean "for anything other than an integer, like say an 
instance of a user-defined class." :-)

Thanks for the clarification!

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Yeah. I'd just been thinking about Warp's example earlier that needed 
> "weak" references to actually not "leak" resources. I was trying to 
> figure out how C++ handled it, if at all.

  Stream manipulation flags are one thing which is shamefully bad designed
in C++, and I really don't understand what they were thinking of.

  A few flags are set only until the next output action which is affected
by that flag (after which it's automatically reset). However, the rest are
permanently set until they are explicitly reset. This means that these
flags can "leak". For example this may well happen:

std::cout << 10 << std::endl;
foo();
std::cout << 10 << std::endl;

  If foo() calls, for example, std::hex(std::cout), then what is printed is:

10
a

  foo() could alleviate this problem by storing the flags into a variable
at the beginning and then restoring those flogs when it ends, but as we
all know, functions can have surprising exit points. (It's still possible
to make sure that the flags are restored at any exit point by using the
destructor mechanism of C++, but it becomes a bit more laborious. I'm
actually surprised the standard library doesn't offer an class type for
this exact purpose...)

-- 
                                                          - Warp

Post a reply to this message