Please see my comments.

================
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
----------------
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?

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

Reply via email to