Unless you're using a connection string, the instantion site would just
instantiate the exact thing it wants. e.g.
ConnectionTcpListen *listener = new ConnectionTcpListen();
listener->Connect();
listener->GetBoundPort();
something like that.
For the connection string case, you would call a factory method that
returns a Connection *
On Thu, Oct 2, 2014 at 10:29 AM, Todd Fiala <tfi...@google.com> wrote:
> Hey Zachary,
>
> >> On posix in cases where it's user specified or don't know, it seems we
> could just create a FileConnection and that would be equivalent to the
> current behavior, since it seems to treat everything the same anyway.
>
> What would the instantiation sites for these classes look like? Would it
> be a call into some kind of Host level "'Create{Socket,File,Pipe}(...)"
> factory method that knows what kind of underlying object to create based on
> that? In which case you can fork off to the right versions for Windows,
> while POSIX-y systems would (as you noted) be able to use a single
> file-descriptor-based impl?
>
>
>
>
>
> On Thu, Oct 2, 2014 at 10:04 AM, Zachary Turner <ztur...@google.com>
> wrote:
>
>> On Wed, Oct 1, 2014 at 1:44 PM, Zachary Turner <ztur...@google.com>
>> wrote:
>>
>>>
>>> I was thinking about splitting CFD into multiple classes, one for each
>>> type of descriptor. A FileConnection, PipeConnection, TcpSocketConnection,
>>> ListeningConnection, etc. Then, the caller would have to instantiate the
>>> right kind. This has its own set of problems, but at least seems to solve
>>> the problem of requiring the creator of the CFD to specify what they're
>>> actually giving us. On posix in cases where it's user specified or don't
>>> know, it seems we could just create a FileConnection and that would be
>>> equivalent to the current behavior, since it seems to treat everything the
>>> same anyway.
>>>
>>
>> The more I think about this, the more I feel like it's the right approach
>> (it might even be the only approach that even works, I can't really come up
>> with anything else that solves the problem, much less does it nicely).
>> We've already got cases where people create a ConnectionFileDescriptor of a
>> specific type, and use it in a way that would break if it weren't of that
>> type. Separating out the cases into different classes this way would allow
>> these cases to be cleaner, as many methods that are publicly exposed on
>> CFD, and some of the class members as well are specific to the type of fd
>> being wrapped. So the interfaces of the other types could become cleaner
>> as well.
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
>
>
> --
> Todd Fiala | Software Engineer | tfi...@google.com
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
