Re: Why parseStreamToContainer calls streamClose?

[Michal H. <ms...@gm...>]

On Tue, Aug 18, 2009 at 10:20:17AM +0000, Jozef Misutka wrote:
> 
> 
> 
> ----------------------------------------
> > Date: Tue, 18 Aug 2009 12:05:53 +0200
> > From: ms...@gm...
> > To: mis...@ho...
> > CC: pdf...@li...
> > Subject: Why parseStreamToContainer calls streamClose?
> >
> > Hi Jozo,
> > why parseStreamToContainer calls streamClose on the given object during
> > cleanup?
> >
> > There is no explanation neither in the code nor in CVS history. Please
> > clarify.
> >
> > Background:
> > For some time I am working on the API clean-up which includes also long
> > term TODO - const cleanup for xpdf code. This popped out during my
> > refactoring.
> > --
> > Michal Hocko
> 
>  
> looking at the code is self explanatory, imho. because you change the
> position/reset it/read chars so it does not make sense to return
> stream in before undefined state. maybe if we store the start position
> but i did not trust xpdf.

Maybe I am missing something but what is the difference between close
and reset. I though that the later one is used to restore the state
before you made any moving and reading.

Is the stream usable also after close is called? E.g. for FileStream you
only set position to the saved one while bufEnd, bufPtr and buf are
intact. This means that the further reading will read from different
location of the file, rigth?

>  
>  
>  
>  ::Stream* xpdfStream = obj.getStream ();
>  xpdfStream->getBaseStream()->moveStart (0);
>  Stream* rawstr = xpdfStream->getBaseStream();
>  // \TODO THIS IS MAGIC (try-fault practise)
>  rawstr->reset ();
> ...
>  // Save chars
>  while (container.size() < len && EOF != (c = rawstr->getChar())) 
>   container.push_back (static_cast (c));
> ...
>  // Cleanup
>  obj.streamClose ();

Why do you call str (which is obj.getStream()->getBaseStream()) reset
right after that, then?

> 
> jm

-- 
Michal Hocko