Feature/c interface custom #89
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some files aren't finished yet, and will be uploaded in a few days. So, this particular update won't build!! Added broad infrastructure for HDF5 handling... ...Wrapper class ...Assignment operators ...convert() functions ...Constructors ...read() functions ...write() functions Etc. Completed many (not all) HDF5 capabilities. Very basic HDF5 write needs to be smarter (not string-only). HDF5 reading still needs work. Touchups are needed here and there throughout the new HDF5 code. In particular, we need smart, non-string handling. Small tweaks were made to XML and JSON material, for consistency. Some comment changes and other odds and ends.
To be used for non-GNDS products, e.g. NDI3. When ProjectDir is given, namespaces and various other constructs are done differently. Made miscellaneous small improvements in various other files. For example: direct read() and write() in Component, aligning with Node's. So: autogenerated classes have those read()s and write(); there's no need for a user to explicitly go through Node.
Won't compile right now, but wanted to get this in.
Regenerated some sample classes.
…fficient. Also allowed for additional debug printing in generated classes.
This helps with some efficiency issues. Some new, alternative query formulations elsewhere allow the T to go. This other work will be uploaded shortly.
…ave a T. Removed some constructs elsewhere that were no longer needed.
…ons. Small changes to a couple of test codes.
Update to the code generator. Updates to some example/test material.
Via reformulation and extension of some floating-point read/write capabilities.
…rsion. Used in BlockData::get(). So, relevant for getting vector<floating-point> in Component-derived classes.
Work in progress.
A few more terminology tweaks.
Changing "comment" to "remark" may seem pointless at first glance, but serves a purpose. I'm currently preparing the way for some updating to how GNDStk handles certain special nodes - think CDATA and PCDATA in XML, as well as comments (in XML and elsewhere). Some modifications in the handling of special nodes will be important for the smooth handling of GNDS 2.0 files.
Throughout GNDStk, I'd been using the word "comment" in both a casual sense ("In this comment I'll describe such-and-such..."), and in a technical sense (the comment() function, comment nodes, etc.). To help make future grep'ing more useful, I decided to use "remark" for the casual sense, and keep "comment" for the technical sense. Henceforth, when I search for instances of the second case, I'll encounter less clutter.
This is all in preparation for adding some things we'll be needing for GNDS 2.0, in particular regarding CDATA and plain-character data nodes.
This is part of a series of updates to help us enable proper GNDS 2.0 handling. Besides, "vector" is really a better name, given what we're trying to accomplish. We may eventually support other container types than vector, in which case the specific name "vector", not "data", makes more sense.
This is in preparation for some things I'll be doing for GNDS 2.0. Fixed an informational message in one of the test codes. Added a "generic special node", for certain upcoming purposes. Removed dumb sounding aliases for "/" nodes. Factored some conversion-related stuff into detail functions.
Adding newly autogenerated files.
Some general cleanup and simplifications. Regenerated classes, per the new autogenerator.
Convenience functions: xml(), json(), hdf5() for quick printing. Improved formulations for various functions in class Field. Gave class Field a size() and operator[] where warranted. Similarly to above, with class FieldPart as well.
…sses. Tweaked the prettyprinting coloring scheme of Component-derived classes. Also tweaked the prettyprinting formatting a bit. Made the names of some global flags more consistent. Fixed a comment that was no longer correct, and another that had a typo. Updates some test codes, as necessary. Put in some other variations of the xml(), json(), and hdf5() print functions.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Autogenerate customization files for the autogenerated C-language interface.
A user who's writing customizations needed this ability.
Besides, I thought @whaeck would appreciate another pull request!