The use of C++ has cropped up from time to time in the Github comments, and it really deserves its own thread.
Background: https://github.com/networkupstools/nut/issues/102 >From Arnaud: > @clepple : also a separate discussion, but quickly: c++ is more for devs than > users. Though, by side effect, this will obviously benefit to the user, the > point is to have better code (and coding) for some news components (new > drivers or rewrites) were we could do better with OO. Not a holy grail or > golden hammer though, but just a way to push what we've learned over years. > on nut-scanner, it's not c++ at all. It was only the first version of an old > idea. But there also, we learned ( hence #14 ). No worries, there will be > some specs soon by @balooloo and me to share and show the intent. I mistakenly conflated the nut-scanner and nutclient.cpp, but my original concerns still stand. What can we (either users or developers) gain from rewriting code in C++? We already have a few instances of OO code implemented in C, and while I am not advocating getting rid of them, I don't think it's a model of how things should be, and simply rewriting them in a different language doesn't fix things either. Every layer of abstraction makes it harder to locate the exact piece of code which is logging a specific error. Bear in mind that most of our debugging is done through log files, not with an actual debugger. Inheritance (either implicitly in C++, or explicitly with C and function pointers) masks the actual control flow. I personally think we have more important things to do than rewriting code in C++ (in particular, documentation, and considering other UPS access methods like libusb1, or native HID interfaces). If someone has a use case for how C++ could help, bear in mind that the benefits of rewriting need to greatly outweigh the cost in order to make it worthwhile. As long as this is a project maintained on personal time, I don't see this happening. If someone wants to propose adding a layer of C++ somewhere, I think they really need to set the standard by cleaning up the existing C++ code in nutclient.cpp. The indentation is not consistent, and neither is the spacing between keywords. (IMHO it should not be necessary to turn on syntax highlighting to browse the code, handy as it may be.) More importantly, there is at least one warning related to virtual destructors (see Buildbot logs) that makes me wonder how closely the memory allocation has been audited. Also, there are hardly any comments. This is much more invasive than simply moving files around, and this needs to be factored into the cost/benefit analysis. -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
