The short answer is "Yes."
Of course, the running time depends on exactly how big the dataset is. NCL's character matrix parsing speed is about as fast as PAUP*'s parsing (and we NCL writers are very proud of that), and its tree reading is slower that PAUP's but not terribly slow.
v2.1 and later are much more efficient than previous versions. On a 2.6GHz i386 MacBook (with 4GB of RAM), Mark Holder obtained the following benchmark results for parsing a file (with comparisons to previous versions of NCL and PAUP* for reference):
Because NCL rocks!
Seriously, we do try hard to make the error messages helpful and have them accurately describe where the error occurs. This is definitely a strength of the library, and we strive to maintain it. Please let us know if you find a file that generates cryptic/unhelpful error messages (Also see Why do the error messages that NCL generates because of invalid files have the wrong column number?)
So despite our generally rockin' error messages, there are some warts. It is tough to get accurate column numbers for errors. We try to support reporting of column numbers of errors because extremely long lines are common in TREES and CHARACTERS blocks. Let us know if you find misleading column numbers (check tab characters, first; NCL counts characters since the last newline. A tabstops are assumed to be set to 4, but this is admittedly arbitrary.
Short answer: convenient appending to strings (including overloads of the "put to" operator).
It is usually considered unsafe to derive from a class (such as std::string) that lacks a virtual destructor. NxsString does not have any additional data members that std::string does not, so we have gotten away with it. It is too late to reverse the decision to bundle a new string class. It is probably best to avoid using it when you don't have to.
At one point we were going to abandon the use of NxsString, so newer functions take and return std::string objects. But we really don't want to break old code, so we are not going to complete the migration away from NxsString just for the sake of consistency of the API.
Sorry about that, we realize that it makes the library harder to use for newer users.
No good reason - history and backwards compatibility
It is only the convenience header ncl.h that does this. Either do not include this file (and simply include the headers of the parts of ncl that you do use), or define a preprocessor macro NCL_AVOID_USING_STD to keep the contents of the std namespace from being "dumped" into your code's namespace.
No good reason - history and backwards compatibility
We were trying to declare functions that should be const, but that would break old code. So if you compile NCL without any special preprocessor directives, then NCL_COULD_BE_CONST will be converted to an empty string. But if you compile with the NCL_CONST_FUNCS preprocessor flag defined(-DNCL_CONST_FUNCS for most compilers), then NCL_COULD_BE_CONST will be replaced with the word const.
In short if you want const-correctness checking, make sure that NCL_CONST_FUNCS is defined when you build NCL (the --with-constfuncs argument to configure will do this ), and that NCL_CONST_FUNCS is defined when you build your application.
If you are not obsessive compulsive, don't worry about out it.
Yes, we know that some more functions should be decorated with NCL_COULD_BE_CONST to improve const checking (and yes, it bugs us).
Yes. See Dealing with Datatype=Mixed discussion.
1.6.3
