io state and multi-restore

Is there a way to use io state savers in single save/multiple restore mode? Gennadiy

On 1/20/05 2:40 AM, "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
Is there a way to use io state savers in single save/multiple restore mode?
I don't know what you mean by "single-save / multiple-restore" mode. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

Is there a way to use io state savers in single save/multiple restore mode?
I don't know what you mean by "single-save / multiple-restore" mode.
I want to save state once at the beggining of something and restore it multiple times after some steps that may pollute io state. Gennadiy

On 1/24/05 2:54 PM, "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
Is there a way to use io state savers in single save/multiple restore mode?
I don't know what you mean by "single-save / multiple-restore" mode.
I want to save state once at the beggining of something and restore it multiple times after some steps that may pollute io state.
Nope, the classes are pure-RAII. The classes either save or do an "atomic" save-and-change in the constructor and restore in the destructor. There are no member functions you could even use for arbitrarily-timed restoring. If you could abuse the RAII paradigm to do this, then.... BTW, why would you need to do this unusual kind of multiple restoring in the first place? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

I want to save state once at the beggining of something and restore it multiple times after some steps that may pollute io state.
Nope, the classes are pure-RAII. The classes either save or do an "atomic" save-and-change in the constructor and restore in the destructor. There are no member functions you could even use for arbitrarily-timed restoring. If you could abuse the RAII paradigm to do this, then....
BTW, why would you need to do this unusual kind of multiple restoring in
Could I make an object during startup and then force restore by making copy and destroying one immediately? the
first place?
I want to save state of cout (or any other current log/report stream for that matter) at the start of test case/framework run and restore it after each assertion? Gennadiy

On 2/1/05 1:50 AM, "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
I want to save state once at the beggining of something and restore it multiple times after some steps that may pollute io state.
Nope, the classes are pure-RAII. The classes either save or do an "atomic" save-and-change in the constructor and restore in the destructor. There are no member functions you could even use for arbitrarily-timed restoring. If you could abuse the RAII paradigm to do this, then....
Could I make an object during startup and then force restore by making copy and destroying one immediately?
Pure-RAII classes don't use anything besides their constructors and destructor, so I never bothered to check how copying worked. Copying a RAII class can only work if it stores a pointer/reference to its changeable object and the old aspect values. (I think my classes do this, but you're depending on an implementation detail, so don't do it!)
BTW, why would you need to do this unusual kind of multiple restoring in the first place?
I want to save state of cout (or any other current log/report stream for that matter) at the start of test case/framework run and restore it after each assertion?
What's wrong with wrapping each trial in a block? void my_test() { { saver_type s( cout ); // do trial 1... } { saver_type s( cout ); // do trial 2... } for ( int i = 3 ; i < 10 ; ++i ) { saver_type s( cout ); // do one of the trials 3 through 9... } //... } -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

BTW, why would you need to do this unusual kind of multiple restoring in the first place?
I want to save state of cout (or any other current log/report stream for that matter) at the start of test case/framework run and restore it after each assertion?
What's wrong with wrapping each trial in a block?
I do not want to waste time on save every time. I already do this for restore. I guess it's not that big deal. What I want ot do though it reset stream from within Boost.Test code. I guess I will have to keep shared_ptr<saver> m_state_saver in my log and do m_state_saver.reset( new saver ) every time. This is kinda wastfull though: 1 extra memory allocation and unnneded constructor call. Gennadiy

On 2/1/05 1:49 PM, "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
BTW, why would you need to do this unusual kind of multiple restoring in the first place?
I want to save state of cout (or any other current log/report stream for that matter) at the start of test case/framework run and restore it after each assertion?
What's wrong with wrapping each trial in a block?
I do not want to waste time on save every time. I already do this for restore. I guess it's not that big deal. What I want ot do though it reset stream from within Boost.Test code. I guess I will have to keep shared_ptr<saver> m_state_saver in my log and do m_state_saver.reset( new saver ) every time. This is kinda wastfull though: 1 extra memory allocation and unnneded constructor call.
I could add a public "reset" member function to do the work of undoing the change, and simply have the destructor call that. This allows multiple-resets. 1. Would "reset" be a good name for this member function? 2. Is it worth it to complicate the current simple-RAII interface for 99% of users for the sake of the 'wacky' 1% that actually need multi-restore? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

I could add a public "reset" member function to do the work of undoing the change, and simply have the destructor call that. This allows multiple-resets.
1. Would "reset" be a good name for this member function?
maybe restore?
2. Is it worth it to complicate the current simple-RAII interface for 99% of users for the sake of the 'wacky' 1% that actually need multi-restore?
It's up to you. I do not know how frequent;y we would need something like that. Gennadiy

From: Daryle Walker <darylew@hotmail.com>
I could add a public "reset" member function to do the work of undoing the change, and simply have the destructor call that. This allows multiple-resets.
1. Would "reset" be a good name for this member function?
"restore" or "restore_state" would be better. "reset" suggests that it might reset the stream to defaults or avoid trying to do anything in the dtor.
2. Is it worth it to complicate the current simple-RAII interface for 99% of users for the sake of the 'wacky' 1% that actually need multi-restore?
I'd hardly call that a complication. I've frequently added such semantics to classes that were otherwise simple RAII designs and have never seen it cause any confusion. I can envision contexts in which I'd want to save the state, modify it, do some custom output, restore the original state, do some common output, and then do some more custom output, all followed by a final state restore. Consider whether bools are reported as numbers or strings. There may be specific output that you want to force one style or the other, while the rest should obey the caller's style. Yes, scoping savers will make that work, but calling restore() is far simpler syntactically. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
participants (3)
-
Daryle Walker
-
Gennadiy Rozental
-
Rob Stewart