abhishek.aggarwal added a comment. In https://reviews.llvm.org/D33035#799058, @clayborg wrote:
> So std::vector shouldn't be used in a public API. You should make a class > that wraps your objects. LLDB's public API has lldb::SBInstruction and > lldb::SBInstructionList as examples. std::vector on other systems compiles > differently for debug and release builds and things will crash. Hi Greg .. Does it go for the tools built on top of LLDB (e.g. in my case where feature library is not a part of liblldb shared lib but built on top of it)? If yes, then I will proceed to remove std::vector from C++ public API of the tool and create a new class for it. > If you need this via swig for internal kind of stuff, then use a typemap > where you map std::vector<T> to a list() with T instances in it in python. I want to provide a python interface for the tool's C++ public API as well so that the API can be used in python modules as well. Therefore, I think typemapping to list() will not solve the problem. Am I right? > I am a bit confused here as well. Are we exporting a plug-in specific python > bindings for the Intel PT data? It seems like it would be nice to wrap this > API into the SBTrace or other lldb interface? Am I not understanding this > correctly? Probably, I didn't understand this comment of yours. We are not exporting python binding for Intel PT data. It is a python binding for Tool's C++ API and this Tool is built on top of LLDB. Did I answer your question? Please let me know if I misunderstood your comment. https://reviews.llvm.org/D33035 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
