Yes, I had the array activity in mind. I am suggesting to do the same for pointers and references.
I am unsure which std methods are available in gcc version 4.1 or 4.4 however we could maybe in case of smart and weak pointers fall back to boost if not available in the compiler. By this we can # reduce code # modernize code # while keeping support for pretty old systems. (Like centos 5) All the best Peter Am 16. August 2017 04:31:25 MESZ schrieb Patricia Shanahan <p...@acm.org>: >I have suggested a refactoring pass to make more use of STL structures >instead of fixed size, unchecked arrays. Some security problem would be > >caught by array bounds checking. > >We have some new volunteers over on the recruitment mailing list. I >think refactoring would be a good project for getting people involved. > >Even if we can't go all the way to C++11, we can make some progress >towards the 21st century. > >On 8/14/2017 12:04 PM, Peter kovacs wrote: >> Sorry, for my bad english. >> I meant that I think that some of the functionality which we have >implemented in helper functions in the past can be retired by using >modern c++11 and later standards. >> The code will be smaller,and according to Bjarne Stroustrup also >faster. >> I also would like to limit if not ban usage of C code. It makes >tmaintainability more difficult, and I do not see the benefit. Honestly >even less then the Java stuff. >> I also don't like helper structures. It is a sign for weak >architecture in my eyes. (But that's naming and structuring of code) >> >> With our small team, I would opt always for less codelines if >possible. Limit is only readability. >> >> I would like to know if there is support from others to remove those >whenever possible with c++11 Or later code? Or what strategy do we want >to head out for. >> >> I have soon more little time. And then I want to do some stuff. Sadly >I will do less then I want to, but I hope it will go fine. >> >> All the best. >> Peter >> >> >> Am 14. August 2017 19:54:06 MESZ schrieb Marcus ><marcus.m...@wtnet.de>: >>> Am 14.08.2017 um 19:38 schrieb Peter kovacs: >>> >>>> I am going through the code, when I have little time left. >>> >>> :-) >>> >>>> There is a lot of code I think we don't need the modern >>> implementation should provide us similar functionality. >>> >>> What do you mean with "modern implementation". Should newer libaries >>> and >>> frameworks we use nowadays provide this support? >>>> >>>> Is it okay if we target to get rid of such old Code? >>>> >>>> Btw. There is a code for a workaround of a bug from gcc version 3. >>> Can we retire that Code? >>> >>> Version 3 started in early 2000. A quick search in our Wiki [1] >found >>> only some hits and these are - surprise - very old. But I don't >think >>> that these are relevant any more. >>> >>> I cannot lookup what the configure script is tell you as minimal >>> version >>> of gcc. But I would bet it's far away from 3. >>> >>> [1] https://wiki.openoffice.org/ >>> >>> My 2 ct - as non-developer. >>> >>> Marcus >>> >>> >>> >--------------------------------------------------------------------- >>> 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 >> > >--------------------------------------------------------------------- >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
