If there is concern over calling a GetHostInfoInstance() or some kind of singleton caller, we can always wrap that in static calls that do it for us. But I'd much prefer here to have an instance with a vtable.
On Fri, Sep 26, 2014 at 1:36 PM, Todd Fiala <tfi...@google.com> wrote: > I think some of the changes you wanted to see Tong make (which I think are > fine to change) are what Tong's looking at now, which need to deviate some > POSIX code in very minor ways. > > Tong - can you call out the code for us? > > Thanks, > Todd > > On Fri, Sep 26, 2014 at 1:34 PM, Zachary Turner <ztur...@google.com> > wrote: > >> 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? >> >> On Fri, Sep 26, 2014 at 1:32 PM, Todd Fiala <tfi...@google.com> wrote: >> >>> >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. >>> >>> 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. >>> >>> Is there any big reason not to just go to a singleton instance here? >>> >>> On Fri, Sep 26, 2014 at 1:30 PM, Zachary Turner <ztur...@google.com> >>> wrote: >>> >>>> 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. >>>> >>>> On Fri, Sep 26, 2014 at 1:17 PM, Todd Fiala <tfi...@google.com> wrote: >>>> >>>>> Hey Zachary, >>>>> >>>>> 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. >>>>> >>>>> 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. >>>>> >>>>> 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? >>>>> >>>>> On Fri, Sep 26, 2014 at 1:09 PM, Todd Fiala <tfi...@google.com> wrote: >>>>> >>>>>> >>! In D5495#27, @zturner wrote: >>>>>> > I'm not seeing the changes to HostInfoPosix and HostThreadPosix >>>>>> that I >>>>>> > suggested. Are those still coming in a followup? >>>>>> >>>>>> 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. >>>>>> >>>>>> 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. >>>>>> >>>>>> > (paraphrased) how do you launch on Android, then? >>>>>> >>>>>> In general you don't. The Android zygote takes care of launching for >>>>>> userland, and debuggers usually run attach-only. >>>>>> >>>>>> 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. >>>>>> >>>>>> http://reviews.llvm.org/D5495 >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Todd Fiala | Software Engineer | tfi...@google.com | 650-943-3180 >>>>> >>>> >>>> >>> >>> >>> -- >>> Todd Fiala | Software Engineer | tfi...@google.com | 650-943-3180 >>> >> >> > > > -- > Todd Fiala | Software Engineer | tfi...@google.com | 650-943-3180 > -- Todd Fiala | Software Engineer | tfi...@google.com | 650-943-3180
_______________________________________________ lldb-commits mailing list lldb-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits