On 12/24/2016 05:18 PM, Alexander Antimonov wrote:
>> We should have a good expectation of improving life for our users ...
> Users are important, but with such move we could improve developers'
> life at least.
More to the point, code that is easier maintain benefits developers as 
well as users.  And having a language that actually encourages code 
encapsulation, reuse, and adaptation would help us build UIs and 
subcomponents that are more consistent, and consequently, that are 
easier and more intuitive for users to understand and to become familiar 

>> - Introduce new bugs (because big rewrites always do)
> Sure, but with C++ port we can also simplify code, and less code - less bugs.
> Now considerable part of Geeqie's code is plain C which builds UI.
> It's a rare method of building UI nowadays. It should be replaced with
> something like Glade description.

It would also be a great opportunity to _remove_ latent bugs that 
already exist.  _Especially_ typing-related bugs.  Just yesterday (which 
is what spurred me to send this email), I fixed a latent buffer-overflow 
bug in the rcfile parsing code ([1]), because someone passed a short* to 
a function that was going to stuff an int into it.  So I fixed it by 
manually copying and pasting the uint helper functions and replacing 
"uint *" with "uint16 *" in the prototype.  Except I didn't copy all of 
them because it simply increases the maintenance burden for no benefit 
yet.  Except not having a unified API across all of the types creates 
its own dev usability burden.  If that's not a 100% prototypical "just 
throw templates at it" problem, I don't know what is.

Also, say you've got a GList*.  How do you avoid sticking the wrong type 
into it?  In C, you've gotta be perfect (including when returning to 
code that hasn't been touched in 4 years) or your code will magically 
crash when a user is trying to get work done.  In C++, your code isn't 
going to compile if you get it wrong.

Here's another easy example: does Geeqie have any double-free or memory 
leak bugs?  I can pretty much guarantee that it does, because they're so 
hard to detect.  C++ features enable (but don't force) you to actually 
guarantee that those classes of bugs don't exist.  Fewer crashes and 
less unintended memory use both offer significant quality-of-life 
improvements for users.

>> - Maybe exclude some core developers who just don't have as much fun in C++ 
>> as in C
> It might be a good chance for them to improve their skills a bit.
> My 5 cents, I prefer do not use love/hate words when it comes to
> technical things.

Agreed, Jeff, which is specifically why I posed this as a question and 
not as a proposal.

That said, I also agree with Alexander.  Learning C++11 (and 
_specifically_ C++11, as opposed to any earlier version) has made me a 
better C programmer, because it's made me more aware of the kinds of 
bugs I write in C that the compiler _doesn't_ catch.  Especially around 
pointer memory ownership.  And those problems are exacerbated by the 
asynchronous patterns used in Glib and GTK, as well as Geeqie itself 
(FileData, I'm looking at you).

std::unique_ptr is annoying, but it's specifically so annoying because 
it exposes so many of my bad pointer-handling habits and forces me to 
fix them.  Those bad habits also have a user impact (*cough* double 
free/memory leak), and being more aware helps me to write better code. 
But that awareness wouldn't have developed anywhere near as quickly 
without std::unique_ptr kicking me in the face every time I got it wrong.



Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
Geeqie-devel mailing list

Reply via email to