C++ Guide for RTEMS Tools?

[Chris Johns]

On 28/8/19 3:34 pm, Sebastian Huber wrote:
> 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.

Yeah I saw that and I like how it is written. I see the wording as saying "be
sensible".

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

I agree. I think it is a good idea. Would this is part of the waf build, say a
target?

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

The rtemstoolkit has been developed with exceptions in mind. I also think the
recent language additions such as unique and shared pointers helps. We have
tools and not long running critical pieces of code so most errors are just being
reported to the user in main.

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

Great.

Chris