On 28/8/19 4:08 am, Sebastian Huber wrote: > since C++ and Python seems to be the preferred languages for RTEMS Tools I > think we need also a C++ guide. I would not re-invent the wheel and just pick > up something existing. The Google C++ Style doesn't seem to be completely > stupid and it is supported out of the box by clang-format. So, my proposal is > to just use it along with: > > clang-format -style=Google -i some-file.cc >
I do not have this tool installed on FreeBSD and it's default cc is clang. I will have to look for it. > The Google C++ Style leaves some white space choices undefined. If we choose > this style, these gaps should be closed for RTEMS. I have briefly reviewed some parts of the Google Style Guide and some of the mixed expressions posted about it online. As is the case with these things I get what I have read in the style guide and can understand why it is present and yet some of the comments are valid when looking into the detail however I wonder if this a case of pulling apart any style guide to make a point. I do not know and I do not have the time or interest to figure it out. The debate over forward decls is a case in point. I agree with the GSG view to include where ever you can and not short circuiting the process by a forward decl and a pointer references however they are needed in localised cases ... https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-elf.h#n38 Complex structures will have them. Google's guide seems to step into language uses and I am not sure if this problematic unless I invest time in reviewing it. I agree with inlines and I have tended to avoid them in most cases unless profiling has shown a definite improvement in performance. There is a lot of code in the rtemstoolkit that exists and I would not like to have to rework it to match a new set of rules. Before I list some of how that code is written I should point out the excellent Scott Meyers article from Dr.Dobb's 2000 titled "How Non-Member Functions Improve Encapsulation" [1]. This is what comes to mind but it is hard when you have been using C++ since the mid 90's (cfront 3.0) ... - Limited if any inheritance, can and often abused - Limited use of inlines - Only use dynamic allocation where needed and these days use unique or shared pointers to manage the allocations. Contains by value is preferred where possible - Use standard containers and algorithms where possible and suitable - Handle errors with exceptions but do not use it as a signalling mechanism, returning errors is not often needed - Use namespaces and resist naming such as "this_then_that" to make unique names in a name space. - Spend the effort to provide a suitable interface to functionality you think can be reused, ie error handling, operators, non-member functions, etc Chris [1] only found it in the web archive now :( http://web.archive.org/web/20190427204318/http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
