Re: [gtkmm] On Glib::IOChannel wrappers



On Fri, 13 Sep 2002, Martin Schulze wrote:

> Am 12.09.2002 23:27 schrieb(en) Tassos Bassoukos:
[snip]
> >  * Glib::Source (as currently implemented) cannot wrap non-glibmm
> > generated GSource's, ergo Glib::IOChannel cannot generte watches,
>
> I agree with Murray: A patch adding Glib::Source::Source(GSource* source)
> would be welcome (but probably non-trivial)! :-)

... with the emphasis on *non*trivial :-) Anyway, I don't yet feel
comfortable enough with gtkmm internals to tackle such an issue.

> > removing
> > one of IOCHannels more useful features. One could use
> > SignalIO.connect(int
> > fd,IOCondition cond), but that is non-portable as Win32 sockets are not
> > represented as ints, and are not regular file descriptors. Also, it looks
> > ugly :-)
>
> 1. Just to make clear: You are talking about sockets and not about pipes
> or something similar that is represented by an int ("HANDLE") in Win32 ?!
> I do hope that the latter is supported by Glib::IOSource. Since there was
> no feedback so far regarding that matter and I'm not using Win32 I don't
> really know, however! Does GIOChannel support Win32 sockets anyway and how?

Yes, gnet supports networking for Unices (therefore also Mac OSX) and
Win32 with the same API.

> 2. What do you mean by "ugly"? Can you think of a more elegant API?

I meant "ugly" as in "exposes representation to the class user", where the
representation is an int.

> 3. Talking about portability: In the very first lines of your patch I
> notice a call to g_io_channel_unix_new(). Are you sure this is a
> portable function? I remember that I avoided it in the implementation
> of Glib::IOSource. Also are you sure that g_io_channel_new_file() is
> portable?

You have a valid point there - the current version is relatively
win32-unfriendly - for now :). g_io_channel_new_file() is portable, as it
will just open a local file. (at least the source code was clean)

> 4. I don't want to be ignorant, but why do you need GIOChannel at all?
> What functionality does it provide that ANSI C++ streaming classes don't?
> Support for Win32 sockets??

Asynchronous notification. Integration with the main event loop. Not
relying on threads for I/O.

Yes, I too find it strange that i'm the first to experience such a raw
need ;-) for these wrappers. It is possible that i'm missing something...

> Regards,
>
>    Martin

Cheers,
Tassos

-- 
Bassoukos Tassos   +30 31 996011 / +30 93 7109954       IT Generalist

Unix:        Your gun, Your bullet, Your foot, Your choice.
M$-CE/ME/NT: Same as Unix, BUT: No choice, and We Aim Higher.
                         -- From the Linux S/390 mailing list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]