Draft
Conversation
…o test what it means for code size.
- Add a ctor taking a static array of elements - Use in more places This is still WIP, cleanup and testing needed
- Add constexpr for some more constructors.
|
Memory usage change @ a701a3f
Click for full report table
Click for full report CSV |
|
Memory usage change @ 592e376
Click for full report table
Click for full report CSV |
This file contains hidden or 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
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.
Create container classes that do not depend on templates.
Notes:
This also opens the possibility to have elements that can be created, and deleted, dynamically. However, we do not have a real strategy for the latter so far. Introducing regular d'tors would cause the compiler to add a lot of tear-down code even in "static" sketches, for no good reason. Adding a virtual "destroy()" function, instead, does not seem to solve the problem (compiler does not appear to be able to figure out, when this code is unused).
An additional problem is that ownership of resources (e.g. array of child elements, but also string constants) is not clearly defined. Some of that work will definitely have to be delegated to the user.
One "relief", however, is that EmbAJAX objects really never make sense in a local scope. They'll either live on the global scope, or on the heap, never on the stack. Thus, implict d'tor calls are not really needed at all.