C++ Guide for RTEMS Tools?

[Sebastian Huber]

On 28/08/2019 04:40, Chris Johns wrote:
> 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.

This would be great. I spent some time reformatting GSoC code by hand in 
the last days and I really think that this should be done by a tool 
instead. Also the student had to do this by hand. I had to communicate 
via email how the style should look like. This all wastes time which 
could be spent on more useful things.

> 
>> 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.

Yes, but the rule about forward declarations "Avoid using forward 
declarations where possible. Just #include the headers you need." is 
quite vague and allows you to use 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.

Yes, reading the guide is not done in five minutes. I don't want to use 
it to go over the existing code base. My focus is more on future 
contributions, e.g. the next year GSoC. I think it would be a bonus for 
students if they can say in a job interview for a software engineer that 
they are familiar with the Google C++ Style Guide because they worked on 
a project using it.

Particularly important for me is the availability of a good automatic 
code formatter for the style. I really hate reading inconsistently 
formatted code.

> 
> 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

I think this is not in conflict with the Google C++ Style Guide.

> 
> - Handle errors with exceptions but do not use it as a signalling mechanism,
> returning errors is not often needed

This rule is all right from my point of view. The Google C++ Style Guide 
doesn't like exceptions:

https://google.github.io/styleguide/cppguide.html#Exceptions

I don't think this is a problem. We can tailor this guide if 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

I think this is not in conflict with the Google C++ Style Guide.

> 
> 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
> 

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.