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