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 with.
>> - 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. --xsdg [1] https://github.com/BestImageViewer/geeqie/commit/a43d40845dcc2fb63c1ad6cae31b8b1ff5527701 ------------------------------------------------------------------------------ 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 Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
