granata.enrico added a comment. We are not supposed to be inheriting from SB classes, much less introduce virtual-ness to them (Greg can go in detail about the reasons, the tl;dr is that it has the potential to be ABI-breaking)
The way one would do that is to have a typedef akin to (and after fixing up any syntax errors and choosing a nice name) typedef bool (*SBSummaryFormatterCallback)(SBValue, SBTypeSummaryOptions, SBStream&) Unfortunately it has to be a C-style function pointer, and not an std::function, again because the SB API can't use the STL Then you would have a creating function of the sort of: SBTypeSummary::CreateCxxFunctionSummary(const char* name, const char* description, SBSummaryFormatterCallback callback) (CxxFunctionSummary is definitely not great as a name, but I have no better suggestion right now - let's worry about that once we have some code up and running) You might need to make yourself a subclass of TypeSummaryImpl in the .cpp file to store these formatters. It will essentially be very similar to CXXFunctionSummaryFormat except it would end up using the SBSummaryFormatterCallback typedef - and also it has to live in the SBTypeSummary.cpp because we can't put things that reference the SB API in lldb_private. Notice that, if you're so inclined, your helper class *can* actually use an std::function, and have virtual functions, and all such niceties, because it is an implementation-only detail not exposed to API clients http://reviews.llvm.org/D13657 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
