On Tue, Feb 20, 2018 at 10:35:01AM +0800, Andy Green wrote:
> > Not really, even C supports opaque types.
>
> No, there is no "not really" about it.
>
> C supports opaque type pointers because the size of a pointer is known
> regardless of the details of what it points to.
To
Andy Green writes:
> Libuv seems to manage it just fine.
libuv used to depend on libev, so that's no surprise. It wouldn't do for
libuv to conflict it's own dependency ...
> it's not going to change no matter what I say.
That's probably true: Even if you had a convincing use case for including
On 21/02/18 02:50, Harald Geyer wrote:
Andy Green writes:
Libuv seems to manage it just fine.
libuv used to depend on libev, so that's no surprise. It wouldn't do for
libuv to conflict it's own dependency ...
libuv is also clean against libevent, unlike libev :-)
it's not going to
On Wed, Feb 21, 2018 at 07:03:21AM +0800, Andy Green wrote:
> > Maybe you can borrow some ideas or even some code from them.
>
> Maybe you can fix your library headers. Or maybe not.
Just out of curiosity, which of Harald's libraries are you refering to?
On Wed, Feb 21, 2018
On Tue, Feb 20, 2018 at 12:40:38AM +0800, Andy Green wrote:
> You sound confident about that, but actually having implemented it, you have
> not considered that the structures composing event lib state (handles, loop
> objects etc) must be defined in one place with types
On 20/02/18 10:17, Marc Lehmann wrote:
On Tue, Feb 20, 2018 at 12:40:38AM +0800, Andy Green wrote:
You sound confident about that, but actually having implemented it, you have
not considered that the structures composing event lib state (handles, loop
objects etc) must be
On 20/02/18 19:50, Marc Lehmann wrote:
On Tue, Feb 20, 2018 at 10:35:01AM +0800, Andy Green wrote:
Not really, even C supports opaque types.
No, there is no "not really" about it.
C supports opaque type pointers because the size of a pointer is known
regardless of the