-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Sun, 16 Aug 2009 23:03:25 +0200
Eric MSP Veith <[email protected]> escribió:
> On Friday 14 August 2009, Ismael Luceno <[email protected]>
> wrote:
<...> 
> Hm, wouldn't that just mean that the programmer who passes the
> function pointer has to take care that he handles the corresponding
> datatype accordingly, and we can just stick with a void* argument for
> the function pointer?

Yes.

<...>
> > My main intention is to separate the functionality to be able to do
> > major improvements and easily replace components.
> 
> When you create a set generic DB handling routines for
> adding/removeing stuff and iterating, the separation has already been
> done. I fear I don't understand your concerns, e.g., to begin with,
> what's bad about my API proposition. (Sure, it's been a quick one,
> but nevertheless...)

The problem with both solutions is that they have the same negative
effects as "g":
1) Expose something directly to the whole system.
2) Implementations can't be swapped.
3) Functionality specific to some domain can't be moved outside the
   core.

Maybe we should unify and store everything on a single DB, thus
allowing to store any kind of content, which would descend from a
special node representing it's domain.

In that case, lists would not be appropriate anymore. The best
structure IMO is a B-tree. It's a bit more difficult to iterate over,
but provides fast lookups and is more memory-efficient than a list if
it's balanced (we can take that cost because the list is mostly static
once we loaded all the services needed).

BTW, when searching, on most architectures, with a few exceptions like
x86, calling a function is not so slow because the compiler can
potentially improve the loop by simply saving the right direction on a
register. Yet it's unable to perform any other optimization. On x86
everything becomes worse because we have the stack in the middle, which
is very slow. So we must avoid calling a function if possible.

- -- 
Ismael Luceno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkqJKV8ACgkQ/mxY0+yOXJozqgCeNRHF+DE1qhEP+8Tv+/q5TN1z
jXwAoI/DQVTswrh8YUOlRjMl2rIgiV+3
=YfOJ
-----END PGP SIGNATURE-----
--
_______________________________________________
Initng mailing list
[email protected]
http://jw.dyndns.org/mailman/listinfo/initng

Reply via email to