================
Comment at: include/lldb/API/SBPlatform.h:106-134
@@ -102,2 +105,31 @@
+ class SBPlatformLaunchCommand
+ {
+ public:
+ SBPlatformLaunchCommand (const char* command,
+ const char* working_dir,
+ const char* arch);
+
+ const char*
+ GetCommand () const;
+
+ const char*
+ GetWorkingDir () const;
+
+ const char*
+ GetArch () const;
+
+ const lldb::pid_t&
+ GetPID () const;
+
+ void
+ SetPID (const lldb::pid_t& pid);
+
+ private:
+ const std::string m_command;
+ const std::string m_working_dir;
+ const std::string m_arch;
+ lldb::pid_t m_pid;
+ };
+
class SBPlatform
----------------
ovyalov wrote:
> clayborg wrote:
> > Can't we just use SBLaunchInfo instead of this?
> >
> > Also one thing to note: if you add anything to the lldb::SB API, you can
> > only have one member variable: a pointer, an std::unique_ptr<> or a
> > std::shared_pointer<>. Why? Because we are vending a C++ interface and you
> > can't change the size of the class. When people link against the lldb.so,
> > they need a consistent API and layout of classes in case they make classes
> > that inherit from or use a lldb::SB class so the layout can never change.
> > So to work around this we have rules:
> >
> > 1 - lldb::SB classes have one ivar (ptr, unique_ptr, or shared_ptr) which
> > abstracts you from your implementation and makes sure the size of the
> > lldb::SB object never changes
> > 2 - no virtual functions so that all function lookups are based off of a
> > pure name lookup by the dynamic linkers (no vtable that can change on you)
> > 3 - No inheritance, or only inheritance based on other lldb::SB classes
> > that obey the same rules
> Thanks for suggestions and context.
>
> I think it makes sense to use SBLaunchInfo instead of SBPlatformLaunchCommand
> since SBLaunchInfo is a wrapper around ProcessLaunchInfo which
> Platform::LaunchProcess takes as a parameter. A few follow-up questions:
> - Is it ok to remove friendship between SBLaunchInfo and SBTarget and make
> SBLaunchInfo::ref public since it will be used by SBPlatform and SBTarget? Or
> we can make SBPlatform its friend as well..
> - I'm going to add SBLaunchInfo::GetProcessID that will delegate to
> ProcessLaunchInfo::SBLaunchInfo - so, I can grab pid of launched process.
> - Does it sound okay to extract SBLaunchInfo into separate
> SBLaunchInfo.h(cpp) files?
> Is it ok to remove friendship between SBLaunchInfo and SBTarget and make
> SBLaunchInfo::ref public since it will be used by SBPlatform and SBTarget? Or
> we can make SBPlatform its friend as well..
I think we can make its friend. The ref() must be a private.
> Does it sound okay to extract SBLaunchInfo into separate SBLaunchInfo.h(cpp)
> files?
Yes.
http://reviews.llvm.org/D7263
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
