Hi Erik, On 20 March 2012 16:27, Erik den Dekker <[email protected]> wrote: > I would like you to reconsider the submission because: > > 1) I don't see why the warning is dumb or stupid; it does expose genuine > issues in code. It actually exposed the bug in the DXF plugin below! > Recommending to disable it seems strange to me.
The errors about the constant is dumb. Changing it to a const bool would still be a const yet it quietens the warnings. Dumb is as dumb be. The only warning of any use here was the one note about the & but that error has nothing to do with the operand being a const. > 2) It would improve consistency in OSG. Generally, #defines of style OSG_xxx > are used for: > > (a) conditional compilation (including header guards) > > or > > (b) as a poor men's function declaration (which is in many > cases also not recommendable practice) > > But the OSG_GLxxx_FEATURES #defines are used for computation (The other > exception being OSG_HEADER_HIGH and OSG_HEADER_LOW, which should really also > be changed to consts) Don't agree. > 3) These #defines is being misused to represent what is in fact a const. > However, the #define is not type safe. The OSG_GLxxx_FEATURES are #defined to > an int value (0 or 1), but are only being used in a bool context. It's standard C/C++ to use a int as bool. Yes bool is slightly more type specific but it really isn't going make the OSG any more consistent or robust. Using const bool instead of #define precluded any use of these #defines within #if blocks. > 4) Using a #define when it is not necessary pollutes the global namespace of > the users of OSG. All #defined that the OSG uses are prefixed with OSG_, the pollution is within the OSG itself. > 5) Note that I changed the casing / style of 'OSG_GLxxx_FEATURES' to > 'osg::hasGLxxxFeatures' only for consistency. The exact name may be a point > for discussion. This was a change that was inconsistent and pointless. > 6) The original submission contains straightforward replacement of X by Y in > a total of 36 lines of code (in a total of 18 files). Is this really too > extensive? Then, you may want to consider this alternative submission which > contains changes to 13 lines of code in 1 file (it does not actually change > the names of OSG_GLxxx_FEATURES). In my experience of developing and supporting the OSG over the last 13 years I can say without doubt the less lines code changed the less likely there will be a bug introduced. Changing a name because of whim is about a bad a reason as I can think of changing code. > 7) I know this submission hardly changes the functionality of OSG. But I do > not fully understand why you reject the chance to increase the quality (IMHO) > of the OSG code. High quality code is certainly not only about functionality? Your code changes didn't improve functionality or reliability. If they did they would have been merged. You may have a different opinion but as I'm the guy who has to maintain the code year in year out I do have rather more exposure of the downsides of any mistakes that get made. My hurdle for changes making into the OSG is clearly higher than yours. Frankly I'm pissed off that I'd even have to explain myself a second time. Please stop wasting my time on this pointless piffle. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
