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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
