On 4/9/19 5:37 pm, Sebastian Huber wrote:
> On 04/09/2019 08:44, Chris Johns wrote:
>> On 4/9/19 4:27 pm, Sebastian Huber wrote:
>>> On 04/09/2019 08:06, Chris Johns wrote:
>>>>> +}
>>>>> +
>>>>> void LTTNGClient::AddThreadName(PerCPUContext* pcpu, const ClientItem&
>>>>> item) {
>>>>> if (pcpu->thread_name_index >= THREAD_NAME_SIZE) {
>>>>> return;
>>>>> @@ -286,6 +339,12 @@ void LTTNGClient::PrintItem(const ClientItem& item) {
>>>>> pcpu.thread_ns = item.ns;
>>>>> pcpu.thread_name_index = 0;
>>>>> break;
>>>>> + case RTEMS_RECORD_INTERRUPT_ENTRY:
>>>>> + WriteIRQHandlerEntry(&pcpu, item);
>>>>> + break;
>>>>> + case RTEMS_RECORD_INTERRUPT_EXIT:
>>>>> + WriteIRQHandlerExit(&pcpu, item);
>>>> ... then take the address of? I prefer to see references being used where
>>>> possible.
>>> This is the Google style:
>>>
>>> https://google.github.io/styleguide/cppguide.html#Reference_Arguments
>>>
>>> I think it makes sense. You see right at the calling place, that a
>>> parameter may
>>> be modified.
>> I do not agree, they forgot to discuss the help the compiler gives you and
>> so I
>> will not adopt it. The Con has "... as they have value syntax but pointer
>> semantics" which is being little simplistic. I could go on but will not it is
>> style and may be related to a large existing code base and that may carry
>> real
>> weight.
>
> I am not a Google C++ Style Guide expert. I guess this rule is somehow related
> to one of the primary goals of the guide:
>
> https://google.github.io/styleguide/cppguide.html#Goals
>
> "Optimize for the reader, not the writer"
>
> The reader here is not the compiler.
I think the compiler is a better reader of code than any of us. :)
> It is fine, if you don't like this rule. We don't have to follow this guide in
> very aspect.
Looking at this I think we may have too.
> I just would like to have some common place default rule set (e.g.
> the Google C++ Style Guide) and it should be allowed to follow the rules.
Sure.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
