> 4 okt. 2018 kl. 10:57 skrev Martijn Verburg <martijnverb...@gmail.com>: > > Hi Kim, > > I like this initiative. I'm wondering if some of these rules can be easily > codified or written into a jcheck style checker (ccheck?) so that Authors > can adhere to the conventions and not rely on a Human review to pick out > where that convention isn't met.
That's an interesting thought! I googled around a bit, but could find no obvious candidate for doing such a check. In fact, parsing and analyzing C++ seems quite a hard problem, compared to many other languages. (Sad, but not really surprising.) I found two possible routes to explore: cpplint [1], the official Google tool to verify that the Google C++ Style Guide [2] is followed, and Vera++ [3], a framework for creating scripts that can analyze and/or transform C++ code. Neither seem like an ideal solution. The Google tool is hard coded to support the Google rules. It's possible we can fork it and add our own, but it's not clear that this is even possible, much less so that it's a good way forward. Vera++, on the other hand, seems much more likely to be able to provide the tooling needed to write checks that enforce these rules. However, what we have is just a framework, and someone's got to write those rules (in TCL of all languages...). Then again, Vera++ is an old and quite popular tool, so its possible there is already a bunch of predefined rules that we can use as a starting point out there. (I didn't go that far in my analysis). Apart from these two, there appear to be no popular, well-encompassing, open source C++ checker out there, that could possibly be verifying rules like these. :( /Magnus [1] https://github.com/google/styleguide/tree/gh-pages/cpplint [2] https://google.github.io/styleguide/cppguide.html [3] https://bitbucket.org/verateam/vera/wiki/Introduction > > Cheers, > Martijn > > >> On Wed, 3 Oct 2018 at 20:13, Kim Barrett <kim.barr...@oracle.com> wrote: >> >> I've submitted a JEP for >> >> (1) enabling the use of C++14 Language Features when building the JDK, >> >> (2) define a process for deciding and documenting which new features >> can be used or are forbidden in HotSpot code, >> >> (3) provide an initial list of permitted and forbidden new features. >> >> https://bugs.openjdk.java.net/browse/JDK-8208089 >> >>
