text: This is the class that orchestrates the reading of a NEXUS data file, and so is the central class to NCL. More...
  #include <nxsreader.h>
  This is the class that orchestrates the reading of a NEXUS data file, and so is the central class to NCL.
  NxsReader does not call delete on any of the blocks that are added to it via the Add method.
  In the "classic" (v2.0) NCL API:
  Versions of NCL after 2.0.04 also support a "factory API" augments the former behavior:
  Important: The use of the factories that are supplied with NCL can trigger casts of pointers. This can be unsafe if you create NxsBlocks that do not have the expected inheritance. For example, if you create a class to read Taxa blocks, but do NOT derive this class from NxsTaxaBlockAPI then the casts will be unsafe. If you do this, and you wish to use the factory API then you must write your own factories.
  See NCL_TOP/examples/normalizer examples for an example of the factory API (using the MultiFormatReader). In those examples the PublicNexusReader::PublicNexusReader() constructor is the function that installs the templates for a clone factory.
  When an illegal construct is found, a NxsException is raised. This exception is caught within NxsReader::Execute and NxsReader::NexusError is called. This allows subclasses of NxsReader to handle exceptional circumstances by overriding one function. Whenever you are using a NxsReader instance that is NOT a subclass of ExceptionRaisingNxsReader this is still the behavior (thus any code that was written to the v2.0 API will still have this behavior).
  ExceptionRaisingNxsReader implements NexusError by raising another NxsException. This results in the exception being propagated to the caller. The newer NxsReader classes (including PublicNexusReader and MultiFormatReader) are derived from ExceptionRaisingNxsReader. So their Execute methods will also raise NxsExceptions. Deriving a subclass of these classes and overriding NexusError would prevent this behavior.
  The advantage of ExceptionRaisingNxsReader is that one is no longer required to subclass NxsReader to handle errors.
  Traditionally, the user of an application can send an SIGINT to cause it to stop. NCL has very limited support for handling signals, and this support is turned off by default.
  If you want NCL to raise an NxsSignalCanceledParseException if a signal is encountered during a parse then call: NxsReader::setNCLCatchesSignals(true); before calling Execute on your NxsReader instance. Note that only the slowly-parsed blocks (TREES and CHARACTERS) and the NxsReader currently check to see if a signal has been caught. So the NxsSignalCanceledParseException will often have a generic message indicating that the signal was caught during the parse.
  The NCL signal handler is only installed during NxsReader::Execute calls!
  Note: that if you want your program to exit on SIGINT, you can leave the signal handling turned off. If you do turn NCL's signal handling on, then after you do your apps clean up you'll have to exit by something like this: signal(SIGINT, SIG_DFL); kill(getpid(), SIGINT);
  Definition at line 118 of file nxsreader.h.