From: Frédéric B. <fre...@fr...> - 2012-08-25 18:41:14
|
Le 25/08/2012 18:10, Alexandre Ferrieux a écrit : > On Sat, Aug 25, 2012 at 6:05 PM, Frédéric Bonnet <fre...@fr...> wrote: >> Le 25/08/2012 16:25, Alexandre Ferrieux a écrit : >> >>> (2) how do you handle the lifecycle of the containing string ? >>> Clearly for each suffix extracted we'd need to bump the refcount of >>> the container; this can easily turn into subtle memory leaks (or at >>> least waste) when a short tail is kept around much longer than its big >>> container. >> >> There are a number of possible optimizations: only use substring objects >> above a certain length threshold for example, and only allow one nesting >> level (i.e. a substring of a substring is itself a substring of the >> original string). > > Quantitative band-aids on a broken leg ;) > Anything more convincing ? > > The use case I have in mind is some parser that takes a big, > short-lived string as input, extracts an interesting chapter as a > substring object, and stores it away. The big input string is now > bolted to the wall. That's right, until the substring shimmers. Or its internal rep could suicide once its string rep is generated (i.e. on exit of its updateStringProc). I suppose your "interesting chapter" will get read eventually, won't it? |