Skip to content
This repository has been archived by the owner on Feb 7, 2024. It is now read-only.

Move document dependent data out of header section #13

Open
RigoLigoRLC opened this issue Jan 26, 2021 · 1 comment
Open

Move document dependent data out of header section #13

RigoLigoRLC opened this issue Jan 26, 2021 · 1 comment
Assignees
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@RigoLigoRLC
Copy link
Owner

Document dependent data could come in multiple ways; Net manager returns a string object while net class is deserialized through deserializer (which output pointer to dynamically allocated string).

Putting them into the header will result in the situation where we must concatenate everything, which causes a lot of unneeded copying.

There should be a function in the deserializer which returns a vector of pointers pointing to strings on heap. Then Core will ba able to output them without having to concatenating everything again. This also requires the return type of data should be unified (all should be pointers to strings on heap).

@RigoLigoRLC
Copy link
Owner Author

Why nets are not going through deserializer? because nets needed to be converted while serializing. So we have the net manager to do it. And we integrated the deserializing functionality into the manager, which seems okay. But netclasses doesn't need such conversion so serializer literally puts the data into the list of netclasses accordingly.

Obviously this is a behavior we should unify.

@RigoLigoRLC RigoLigoRLC self-assigned this Jan 26, 2021
@RigoLigoRLC RigoLigoRLC added enhancement New feature or request good first issue Good for newcomers labels Jan 26, 2021
@RigoLigoRLC RigoLigoRLC added this to Needs triage in Bug fix plans via automation Jan 26, 2021
@RigoLigoRLC RigoLigoRLC moved this from Needs triage to Low priority in Bug fix plans Jan 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
Bug fix plans
Low priority
Development

No branches or pull requests

1 participant