C++: Changes to models library.

[geoffw0]

This is a sort of prototype for changes I intend to make to the entire models library, the intent being to discuss these ideas on a small scale before I spend more time applying them more widely. Once it's merged I intend to make a second, larger PR applying what is agreed upon to all of models\implementations. The changes are:

• make the QL classes in models\implementations representing library functions private; there may be cases where we think using them directly has legitimate value to users (possibly bits of Allocation.qll), in which case we should consider migrating sufficient code from implementations to interfaces. But in most cases these classes are implementation details, and we may want to change their details in future (for example combining or splitting models).
• add a QL module for Std, instead of naming lots of classes StdPairConstructor, StdMapInsert etc. This was suggested by @tausbn. I'm not really sure what the pro's and con's will be for us so I'd like to discuss what we want to get out of it before pressing on with this.
• avoid the pattern: getParameter(_) - because it's believed to be inefficient (I only found one remaining use anyway)
• more use of [, ] syntax; I expect this is uncontroversial at this point.

I'm also open to further suggestions (porting taint models to the upcoming shared flow summary interface is out of scope, however).

[rdmarsh2]

I'm not sure a private Std module in a file that only has models standard library classes makes a significant difference. It would be more interesting to look at how it affects the iterator models where there are both specific names in std:: and generic concepts like iterator accesses.

[jbj]

Overall I like the direction of these changes, but I have the same reservation as @rdmarsh2.

make the QL classes in models\implementations representing library functions private

Agreed: private by default, and then we can make individual classes public if the value outweighs the maintenance burden.

add a QL module for Std, instead of naming lots of classes StdPairConstructor, StdMapInsert etc. This was suggested by @tausbn.

I don't see the value in this, even if we'll later put public items into that module. A QL module is different from a C++ namespace in that the contents of a QL module has to be enumerated in one central location. That may fit how the Python libraries are organised, but I don't think it fits the C/C++ libraries.

I don't find that Std::PairConstructor breaks up the name in a helpful way. Maybe Std::Pair::Constructor would look good, but I don't see that it looks better than StdPairConstructor. At least not enough to outweigh the library organisation issues.

avoid the pattern: getParameter(_) - because it's believed to be inefficient (I only found one remaining use anyway)

👍

more use of [, ] syntax; I expect this is uncontroversial at this point.

👍

[geoffw0]

I'm not sure a private Std module in a file that only has models standard library classes makes a significant difference

I've reverted the addition of the Std module. I'm open to suggestions but I've also yet to see how modules can really improve what we do here.

[jbj]

Sounds good to me. I'll merge this PR Thursday morning unless there are unresolved discussions.