On Sat, Jan 19, 2008 at 06:15:58PM -0200, Leandro Lucarella <[EMAIL PROTECTED]>
wrote:
> > > ev::get () -> ev_default_loop (0)
> >
> > maybe ev::default_loop () as well?
>
> I just like to separate initialization from just getting a pointer/object.
> But I can understand the C API don't do that so the C++ API shouldn't
> either.
But the C++ api offers the dynamic loop, so everybody cna be happy, even
the oo fetishist.
The difference (to me) really is that the default loop is a shared resource
for many parties, so its not the responsibility of any specific module to
initialise or destroy it.
> > ev::default_loop ().loop ()
> > ev::default_loop ().post_fork ();
> >
> > etc. I think default_loop should preferably a variable (this has many
> > problems! don't! :)
>
> I would say to make a macro:
> #define loop default_loop ()
> but they don't go too well with namespaces :S
Now, you give me ideas, one could of course...
static struct
{
operator loop_ref () { return ...; }
} default_loop;
would be interesting to see what kinds of overhead this creates, if any.
> Mmm, I like at least to avoid valgrind complaining about memory loss,
That should be an optional feature though, preferably only compiled in when
valgrind support is enabled or so.
One shouldn't punish everybody just because of a single tool most people
won't use.
> only still reachable memory. The weird thing is that when calling
> ev_default_destroy (), I get a lot of errors about 0 bytes in 1 blocks
> are definitely lost.
Thats a known valgrind bug: it reports memory freed via realloc as still
reachable. Pretty annoying :)
> > i think users should store the default_loop in soem variable as soon
> > as possible anyways (and most people will liekly do just to avoid the
> > function call).
>
> I'm not a fan of inconsistencies, as you said, if not all default loop
> methods are provided as free functions, then you'll have to remember
> which are available and which are not.
Which would be ok if its only very few, though.
> So if you think most people will have the loop in a local variable I'll
> leave the things are they are now (except, maybe for the default_loop
> nuking and making default_loop () to return a loop_ref for the default
> loop).
Not sure what most people do, thats really just my expecdtation, even with
the C API.
I think there are two cases:
a) people not caring about any loops thing
(they will suffer from tremendous numbers of ev_default_init calls)
b) people caring either about loops or biug overheads
(those will store the loop somewhere)
I think its best to encourage b), as having dozens of (hidden) function
calls is pretty ugly.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
