C++ Guide for RTEMS Tools?
chrisj at rtems.org
Wed Aug 28 02:40:20 UTC 2019
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 ...
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" .
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
 only found it in the web archive now :(
More information about the devel