C++ Guide for RTEMS Tools?

[Chris Johns]

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