[PATCH] D83088: Introduce CfgTraits abstraction

David Blaikie via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Aug 12 12:55:27 PDT 2020


dblaikie added a comment.

In D83088#2213864 <https://reviews.llvm.org/D83088#2213864>, @nhaehnle wrote:

> In D83088#2213802 <https://reviews.llvm.org/D83088#2213802>, @dblaikie wrote:
>
>> In D83088#2213797 <https://reviews.llvm.org/D83088#2213797>, @nhaehnle wrote:
>>
>>> In D83088#2208611 <https://reviews.llvm.org/D83088#2208611>, @dblaikie wrote:
>>>
>>>> This seems like a strange hybrid between a static-polymorphism (with traits) and dynamic polymorphism (with base classes/virtual functions). Could this more readily be just one or the other? (sounds like you're leaning towards dynamic polymorphism)
>>>
>>> No, it's very much this way on purpose. The idea is to support the same set of functionality as much as possible in both static **and** dynamic polymorphism.
>>
>> Could it be implemented statically as a primary interface, with a dynamic wrapper? (eg: a base class, then a derived class template that takes the static CFG type to wrap into the dynamic type) keeping the two concepts more clearly separated?
>
> That is how it is implemented. CfgTraits is the primary static interface, and then CfgInterface / CfgInterfaceImpl is the dynamic wrapper.

Ah, fair enough. The inheritance details in the traits class confused me a bit/I had a hard time following, with all the features being in the one patch. Might be easier separately, but not sure.

Would it be possible for this not to use traits - I know @asbirlea and I had trouble with some things using GraphTraits owing to the traits API. An alternative would be to describe a CFGGraph concept (same as a standard container concept, for instance) - where there is a concrete graph object and that object is queried for things like nodes, edges, etc. (actually one of the significant things we tripped over was the API choice to navigate edges from a node itself without any extra state - which meant nodes/edge iteration had to carry state (potentially pointers back to the graph, etc) to be able to manifest their edges - trait or concept could both address this by, for traits, passing the graph as well as the node when querying the trait for edges, or for a concept passing the node back to the graph to query for edges).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83088/new/

https://reviews.llvm.org/D83088



More information about the cfe-commits mailing list