Closed woollybah closed 5 years ago
Is there a reason to handle it differently to objects? So it stays alive as long as one reference is kept. Or is this having too much overhead?
Doesn't your idea require a lot of if-then to take care of potentially lost data? If the original string element is to get edited...and you want to avoid changing the "duplicates"...?
If the original string element is to get edited...and you want to avoid changing the "duplicates"...?
String objects are immutable, so (ignoring evil pointer-based hacking of course) their contents cannot be changed.
With that in mind, do we actually need a new type? Or would it be possible to do some sort of string interning to optimize memory consumption behind the scenes, like Java and C# do? Strings with identical content could share their character data (or simply be the same instance) and smaller strings created by slicing a larger string could share the character data with that larger string. (This means that the character data would need to be reference counted or garbage collected separately.)
But in case of a separate new type, my first thought would be making it a lightweight struct, which would store a private reference to its parent String (to make sure it doesn't get collected) and a pointer into the String's character data. (Rust has something vaguely similar, but Rust's String
type is more of a string buffer, whereas ours is immutable.) What would be the advantages of making it a class, and a subclass of String at that?
A String whose text data belongs to another String, and therefore requires no more resources other than for the instance of the object itself. The data is only valid for the life the original data, but could be useful when processing large sets of text that would otherwise result in the duplication of a lot of data in memory.
As a subclass of String, existing string functionality would be unaffected.