-
-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue #91 progress. #194
Issue #91 progress. #194
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We started this conversation on Slack but it was never completed: can we ship a simple static allocator for use with variable-length arrays and make it the default? The bounded-size nature of DSDL makes it the most natural choice for virtually all cases (with the notable exclusion of #189).
Yeah. I think that makes sense. |
Also, one thing I forgot to mention: can we please support at least a basic iterator API (pointer-based) for the variable array type? Otherwise, the class would be much less useful when interfacing with 3rd-party code. |
1. Fixed support generator to properly use specified file and line post-processors. 2. General progress on the variable length array. 3. Added "no-cov" to cmake build so it doesn't get in the way during development. This was a constant problem on OSX. Still left is to get all the noexcept guarentees to be correct and to figure out how to verify them.
I'd like to release this initially with the most minimal support needed for ser/des. Let's then analyze usage and expand as real use cases present themselves. I really don't want to provide a generalized container library from Nunavut. That doesn't seem like its competency. |
Also note that the CI will remain broken until we agree on the content of the PR as I'm restructuring the CI interface to better support parallelization going forward. |
@thirtytwobits are you planning to further advance this or do you want it merged as-is? |
I have more work to do to respond to all your comments. |
@pavel-kirienko , let me know if this is okay to merge as-is (i.e. the c++ work isn't done but we need to get all this change in) and I'll fix up the CI |
This is a checkpoint merge to put a firebreak in a growing change-set. Most all of these changes are behind the --experimental-language flag so there's little risk. There are a couple of fixes in the core python library that should not break anybody we know of.
Highlights: