<div dir="ltr">The main benefit is just cleaner code.  And really it will only just be 1 instance, since it will be a singleton.  So instead of writing Host::DoSoemthing() it would be Host::GetInstance()->DoSomething().<div>
<br></div><div>That being said, I have some other ideas as well.  I feel like maybe Host just ended up being the default place to put any function which needed to interface with the platform.  For example, I see  file-system stuff in Host, process launching stuff, and more.  I'm currently thinking about maybe separating the stuff in Host into different logical groups, and then moving that functionality into their own Host-layer classes.  So we'd have lldb_host::FileSystem, for example, which would contain the Readlink, Unlink, etc functions.  And an lldb_host::ProcessLauncher interface, which would support different ways of launching processes, with derived implementations such as PosixSpawnProcessLauncher, ExecProcessLauncher, ForkProcessLauncher, WindowsProcessLauncher, etc etc.  Then existing code that launches processes could use these classes instead.  </div>
<div><br></div><div>Thoughts?</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 12, 2014 at 3:59 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On Aug 11, 2014, at 11:27 AM, Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br>
><br>
> Currently Host is implemented as a static class with lots of ifdefs to define different versions of methods depending on the OS and platform.<br>
><br>
> Has anyone ever thought about turning this into a a singleton that returns an actual instance of a class?  This would provide a number of advantages, such as:<br>
><br>
> 1) Cleaner code.  You could use interfaces and inheritance to clearly define the common behavior of a Host, and allow each particular host to define its own platform specific functionality in derived implementations.<br>

><br>
> 2) More flexibility for supporting non-trivial platform differences.  As a quick example, currently launching a new process starts a monitoring thread, and passes data through type-erased batons and the like.  This might not necessarily be an appropriate model for all platforms.  Maybe I'd like to use one thread which I simply re-use for many different things, only one of which is monitoring processes.<br>

><br>
> 3) Member data.  Say you launch 10 processes.  It would be useful if there were just handles to all 10 processes sitting in an easily accessible location (at least for Windows anyway, this would be useful).  If there were a WindowsHost class, I could just have a list of HANDLE items in my class.<br>

><br>
> I'm sure there are many more benefits to doing so.<br>
><br>
> I'm still going over the class implementation, but I wanted to throw this out there for discussion.  Let's say I did want to go forward with this refactor though.  Anything I should keep in mind that isn't totally obvious?<br>

<br>
</div></div>Nothing has required state up to this point. You can always implement the windows stuff using this new class and see how it goes. Just use your singleton in any windows specific parts of the Host layer and we can see if it would be a good model for everyone. I would rather not require people to create a class instance if there is no real benefit, but I am open to hearing the reasons we might want such a thing.<br>

<span class="HOEnZb"><font color="#888888"><br>
Greg<br>
<br>
<br>
</font></span></blockquote></div><br></div>