<div dir="ltr">I think that for the purposes that I wrote HostInfo to handle, very simple methods that answer simple queries about the host os, the virtual methods would not be needed. For example, what's the username of the currently logged in user? What's the page size? Get the value of an environment variable. If something is more complicated than that, it probably belongs somewhere else. Do you have an example in mind that you think is a natural fit for HostInfo, but would require calling virtual methods?</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 26, 2014 at 1:32 PM, Todd Fiala <span dir="ltr"><<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">><span style="font-family:arial,sans-serif;font-size:13px">It wasn't made a class instance hierarchy for the same reason that Host wasn't a class instance to begin with. HostInfo only contains method that are inherently static. You could make it an instance, but it would be awkward, because you would have to create one for the sole purpose of calling a method that is actually static. </span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></span><div><span style="font-family:arial,sans-serif;font-size:13px">Right - but when we want to nuke #ifdefs, we really do need the virtual methods. Which I think is all for the best. But needs the virtual methods to share large bits of code and only deviate in little places.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Is there any big reason not to just go to a singleton instance here?</span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 26, 2014 at 1:30 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It wasn't made a class instance hierarchy for the same reason that Host wasn't a class instance to begin with. HostInfo only contains method that are inherently static. You could make it an instance, but it would be awkward, because you would have to create one for the sole purpose of calling a method that is actually static. </div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 26, 2014 at 1:17 PM, Todd Fiala <span dir="ltr"><<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey Zachary,<div><br></div><div>I just started looking at the HostInfo* classes. I'm a little confused - we are going to want to have Android behavior differ in just a tiny little way from Linux (and POSIX). So we're going to want to break out some implementation details into some virtual methods that are possibly no-op or different-op on the *largely same* code for POSIX/Linux. Yet all the calls in these classes are static.</div><div><br></div><div>Why isn't this just a class instance hierarchy? We're going to want it to be more like that so we can use typical C++ class design patterns like using virtual methods and the like.</div><div><br></div><div>Or did you have some other paradigm in mind for nearly-similar classes that want to share the bulk of the code in these classes?</div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Fri, Sep 26, 2014 at 1:09 PM, Todd Fiala <span dir="ltr"><<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>>>! In D5495#27, @zturner wrote:<br>
> I'm not seeing the changes to HostInfoPosix and HostThreadPosix that I<br>
> suggested. Are those still coming in a followup?<br>
<br>
</span>With Android, it's *mostly* Linux (at the kernel level) except we have a whole slew of different runtime libraries that differ. So, for much of the behavior, it will be like Linux/POSIX, but with certain libc calls and whatnot that just don't exist. Ideally we minimize how much we differ and only when needed.<br>
<br>
Tong, can you take a look at that? If we need a Linux-derived Android variant of these classes, this might be a good time to look at those. Thanks.<br>
<br>
> (paraphrased) how do you launch on Android, then?<br>
<br>
In general you don't. The Android zygote takes care of launching for userland, and debuggers usually run attach-only.<br>
<br>
That's just a half-truth, though. We do have low-level, internal capabilities for launching, but since that is not a supported path for developers, they are not exposed in a way we can access with POSIX-like calls. The launch code might end up only showing up in an AOSP environment but, in any event, the attach path is the crucial one for Android right now.<br>
<br>
<a href="http://reviews.llvm.org/D5495" target="_blank">http://reviews.llvm.org/D5495</a><br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><font color="#1155cc"> <a>650-943-3180</a></font></td></tr></tbody></table><br></div>
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><font color="#1155cc"> <a>650-943-3180</a></font></td></tr></tbody></table><br></div>
</div>
</div></div></blockquote></div><br></div>