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: Thu, 26 Nov 2015 02:57:49 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0

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

Philip,

Thanks for the encouragement.  I've been programming C++ for decades, but I'm
new at Octave libraries...

The reason the code was getting out of sync is it treated "-inf" as "-i"
followed by "nf".  That works now, and 'inf' and 'nan' are also now handled by
the code that reads numbers with non-standard expChars or field widths.

Other bug fixes are:
- It was manually clipping values of integers to the required range, and 
assumed octave_uint8(-1) would be 255.  Since the constructors do the clipping
already, that is removed.
- It didn't handles escapes in single quoted strings, like '%[^n]'
- It replaces the library function pow10 by an explicit "pown"

The patch doesn't resolve the issue of co-existing with textscan.m, but it is
still quite a way from production, so I hope you can live with that.

Some remaining matters of incompatibility with Matlab that need to be sorted
are:

1. It treats, for example, %[a-f] as shorthand for %[abcdef].  That is
slightly incompatible -- should we keep it?  The other slight disadvantage is
that it calls code that was "static" in oct-stream.cc to parse the character
set, and so requires edits to oct-stream.{cc,h} to make that function global. 
We could duplicate the code, but that seems wasteful (and would be bad for
maintenance, such as converting to unicode).

2. It doesn't stop on invalid numbers, or mismatched literals.  I textscan.m
also doesn't, so I assume that is OK

3. In files with an incomplete last line, it doesn't distinguish whether or
not the last line finished with n.  My guess is that they did that just
because it was easier in their code.  Should we add that test?  My preference
is to keep the code cleaner by not doing so.

The other notable incompatibility is with textscan.m: my code only accepts
literal commentStyle specifiers, like "//", not names like 'C', 'C++', 'shell'
etc.  That is partly deliberate, because I can't see how to specify that "C"
introduces a comment, as it does in Fortran source (though it is not clear
that textscan is suitable for reading Fortran...).  Would you like me to put
the short-cuts in?

Thanks,
Lachlan (whose surname is Andrew, just to be confusing :)

(file #35557)
    _______________________________________________________

Additional Item Attachment:

File name: textscan_diff_default_20151126.txt Size:106 KB


    _______________________________________________________

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]