octave-patch-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-patch-tracker] [patch #8783] C++ implementation of textscan


From: Lachlan Andrew
Subject: [Octave-patch-tracker] [patch #8783] C++ implementation of textscan
Date: Fri, 12 Feb 2016 05:45:14 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0

Follow-up Comment #43, patch #8783 (project octave):

Philip, yes, there is seekg and tellg.

However, Octave explicitly disables them.  (jwe: thanks for your offer of help
-- re-enabling these is the min help we need.)  They require functions that
are commented out in c-file-ptr-stream.cc.  Take a look at patch 
textscan_enable_seek.cset  file #36288.

I asked why these were commented out, and jwe said


On 10/26/2015 01:14 AM, LachlanA wrote:

    My biggest concern is that it needs tellg(), which was explicitly
disabled
    (#if 0) in libinterp/corefcn/c-file-ptr-stream.cc with the cryptic
comment
    "FIXME", giving no indication of why it was disabled.

Probably because of potential type problems of int vs off_t.  It looks like
the c_file_ptr_buf::seek and c_file_ptr_buf::tell functions now use fseeko and
ftello, so tellg could probably just be implemented using those.


I didn't really understand the concern, since the types are std::streamoff 
std::streampos rather than int or off_t.  I also don't understand the
internals of C++ streams well enough to be confident of re-implementing  tellg
and seekg  in a way that works for both files and string streams.  The web
says just to implement seekoff and seekpos in the streambuf subclass.

I've used textscan with files that cross the 4GB threshold between 32 and 64
bits (with octave_idx_type 32 bits) and didn't notice any problems, but I'd by
happy to do some more testing on different configurations if someone suggests
which.

You're right that reading ahead into a buffer is useful.  I was in the process
of doing that when I came up with the problem that textscan is supposed to
leave the file pointer pointing to the next item to read.  Once it has been
read into the buffer, we're stuck unless we can seek back.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?8783>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]