Shared code cannot call non-shared function 'int[]@ factstub()'
Shouldn't the factory stubs be marked as shared when they are generated?
Shared template factory stub
Author
When compiling a shared class that uses a template (array, say), a rather cryptic error appears:
Shouldn't the factory stubs be marked as shared when they are generated?
Shouldn't the factory stubs be marked as shared when they are generated?
Author
A probably unrelated issue I have is that I cannot use shared classes as members of the ordinary classes. Is that intended? The manual only states about non-shared entities being (obviously) inaccessible within the entities, but this is the opposite situation.
Author
It does when the first script that uses the shared class (as a member) is compiled, but the consecutive scripts throw
Illegal member type
The problem was that as the shared class was already existing from the previous module it wasn't validated again to check for illegal members. Because the validation was skipped, I forgot to set the type as valid in the new module.
I've fixed this in revision 1092.
I've fixed this in revision 1092.
Author
I'll check this once we update to the latest revision, but I am interested: can the shared classes eventually lead to the separation of class declaration and its implementation? That would do wonders for compilation time in many cases. I realize problems arising from the fact that the script modules would cease to be standalone entities, so is such a separation in plans?
Anything is possible. This other thread is discussing some ideas that might become a reality one day.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement