[lldb-dev] LLDB API c++ exports

Zachary Turner zturner at google.com
Tue May 27 14:06:50 PDT 2014

In trying to clean up the warnings in the Windows build, I found the
most prominent warning to be C4251 ('identifier' : class 'type' needs
to have dll-interface to be used by clients of class 'type2').  This
is because almost all of the exported classes (e.g. SBAddress, etc)
contain an stl object as part of their interface, usually a smart
pointer.  This is a bad idea, as described in the following post:

The warning can usually be ignored if none of the non-exported classes
are made accessible through the public interface of the class, and it
seems that at least some effort has been made to see that this is the
case, but it does not appear to always be true.  I've gone through
each of the exported classes, and found the following instances where
non-exported classes are exposed through the public interface:

    SBDebugger(const lldb::DebuggerSP &debugger_sp);
    SBFrame (const lldb::StackFrameSP &lldb_object_sp);
    SBProcess (const lldb::ProcessSP &process_sp);
    SBQueueItem (const lldb::QueueItemSP& queue_item_sp);
    void SBQueueItem::SetQueueItem (const lldb::QueueItemSP& queue_item_sp);
    SBTarget (const lldb::TargetSP& target_sp);
    SBThread (const lldb::ThreadSP& lldb_object_sp);
    SBValue (const lldb::ValueObjectSP &value_sp);
    lldb::ValueObjectSP SBValue::GetSP () const;
    SBWatchpoint (const lldb::WatchpointSP &wp_sp);
    lldb::WatchpointSP SBWatchpoint::GetSP () const;
    void SBWatchpoint::SetSP (const lldb::WatchpointSP &sp);

I guess there are a couple of approaches to fixing this:

1) Add a comment to each function explaining that it should be used
only internally, and suppress the warning.

2) Make the opaque pointer a raw pointer that is manually allocated in
the constructor and de-allocated in the destructor.

#2 seems like the "best" approach, but it's also more work.  Does
anyone have strong feelings one way or the other?

More information about the lldb-dev mailing list