|
Even raises an important point about adopting the latest C++
standards. This point actually applies to C++ in general as well. In
particular, C++ can be used to write some very powerful but
tremendously opaque code. This problem is amplified by the
inscrutable error messages that are produced when the error is
buried in the definition or instantiation of a class. Having spent
far too much time trying to read other people's code, I've come to
value readability as the most important attribute of code (after
correctness, of course). Even's example comparing to"std::unique_ptr<int *, std::function<void(char *)>> Vals(CPLCalloc(256, 0), CPLFree); shows clearly that new features do not necessarily create greater clarity in the code."std::vector Vals(256,0); Just because a newer standard enables new capabilities, it doesn't mean we have to adopt them all. Lambda expressions are an example of a capability I would discourage for issues of readability. I have no problem when lambda functions are trivial [](int a, int b) {return a + b;} This is the sort of code you wouldn't comment outside a lambda _expression_ anyway. But when you start getting complex lambda expressions that hard to comprehend (think the sort of crazy stuff you see with Python comprehensions (so ironically named)), I consider it to be a premature optimization to use a lambda _expression_ in place of a "normal" function that is well commented. Modern compilers can be extremely effective in optimizing stuff like this. And if this does become a bottleneck, then use a well-documented lambda _expression_ if that's what it takes. Adoption of a newer standard is not the same thing as a wholesale endorsement of features that will make the code harder to read and maintain. This is where the issue of coding standards comes in. We use the coding standards to encourage those newly enabled forms we see and important and discourage/ban those that will damage readability (or correctness or efficiency). |
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
