I am not so sure that will help us. What are the pros what the cons? Am 17. April 2018 08:13:33 MESZ schrieb Damjan Jovanovic <dam...@apache.org>: >The Mozilla project also uses C++, also started in a similar timeframe >to >StarOffice, also has a huge codebase, also uses a component-based >development methodology, and so on. > >Lately, they've dealt with memory issues by developing in another >language >that is memory-safe: Rust. > >We could learn from them. > >On Tue, Apr 17, 2018 at 7:26 AM, Peter Kovacs <pe...@apache.org> wrote: > >> I would like to pick the discussion up again. >> >> In general I prefer a Class type approach over a Function based >approach >> in Code methology. Since Class based has the "buildIn" RAI approach, >I >> think the pool approach does not make sense when classes are used. >When >> ever the desicion goes in favour of function based programing we >should >> concider the pool based memory management for data structures. >Therefore a >> structure that has not an owner is owned and managed by a pool >instead of a >> class. >> >> That has some logic to me. Is there something I miss? >> >> >> >> On 25.03.2018 22:59, Pedro Giffuni wrote: >> >>> On 3/25/2018 10:44 AM, Pedro Giffuni wrote: >>>> > Somewhat related ... >>>> > > I have been considering the use of APR pools: >>>> > > http://www.apachetutor.org/dev/pools >>>> > > It would be great to have the memory managed by the same >technology >>>> used > in Apache httpd. >>>> >>>> I need to think about this. It seems very appropriate for >transaction >>>> processing. I am not so sure it is a good fit for AOO. >>>> >>> >>> We do a lot of different memory processing in AOO: in some cases it >may >>> be more useful that in others. >>> >>> For the time being I was only looking at using pools to replace some >>> malloc()/calloc()s in SAL but I haven't found time to do a PoC. >>> >>> Pedro. >>> >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >>
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
