Le 16/08/2016 à 18:44, mathog a écrit :
Always use one of these instead:
if(blah)do_something; //if the conditional and action fit entirely on one line
or
if(blah){ do_something; }
According to Inkscape coding style: https://inkscape.org/en/develop/coding-style/ I suggest you write:
if (blah) do_something;
// or
if (blah) { do_something; }
instead.
There are instances where coding logic as a one time loop is convenient because then "break" may be used instead of "goto". In some programming projects a religious dispute results if a goto is employed, and this avoids that conflict.
Yeah, I noticed it reading the code and attempting to find a better solution (and I felt ashamed of my comment). My personal solution would be to run the two cases without checking and checking both at the end:
if (cond) { a = load(); b = load(); if (a && b) { run(a, b); } }
thus b will try to load even if a failed — we expect it will be an unusual case. In that case, we could also have:
if (!a) return;
just after trying to load a, as all the below statements will be useless in the function. But it lacks symmetry.
The one-time loop is not so bad after all. Note that Java doesn't have any goto instruction, but its break instruction can accept a label.
Le 16/08/2016 à 20:39, Michael Soegtrop a écrit :
I would be careful with the this!=NULL statement for
bool SPLPEItem::performPathEffect
as far as I can tell, this is not a virtual function, and there is no reason why the this pointer of a non virtual function should not be NULL. One can call a non virtual member function on a NULL pointer. Not very nice, but some people put such checks into the code as extra safety check on purpose and some even use tricks like calling a function on NULL pointers on purpose, e.g. for saving a lot of checks when the function is called.
Sure! As, for SomeClass::func being non-virtual, these statements:
SomeClass *some_obj = nullptr; some_obj->func();
are pretty much similar to:
func(some_obj);
whereas if the function is virtual, it'll be something like that:
(some_obj->vtable_ptr_for_func)(some_obj);
and that will cause a segfault when reading vtable_ptr_for_func.
I copied your comments stating your competition with the analyser on the bug report: https://bugs.launchpad.net/inkscape/+bug/1613662 so that PVS-Studio can benefit of their contribution to the Inkscape project — :). -- Sylvain