On Wed, Dec 17, 2003 at 09:19:33AM -0500, Derek Atkins wrote:
> Lionel Elie Mamane <[EMAIL PROTECTED]> writes:

>> I would think that in principle having two schedulers in one program
>> is wasteful and less maintainable than having one.

> Well, it very much depends on your definition of "scheduler"..  It's
> not that hard to write code that does, effectively:

>     for (i = list; i; i=i->next) {
>        foo = i->data;
>        if (need_to_run_p (foo))
>           run(foo);
>     }

Well, here, all the date / repeat intelligence is in
"need_to_run_p". That's the part I wouldn't think intelligent to
duplicate, and it is the essence of the scheduler.

>>> Unfortunately you can't just make the SX engine call a "make
>>> invoice" function

>>> first, it would introduce a dependency loop in the code,

>> ? I guess I'll understand this remark when I'll look at the
>> details.

> Basically the business code is all compiled after the engine code,
> and the business code depends on the engine.  If you add a
> dependency a dependency in the other direction you now have a
> dependency loop.

Nope, because the engine would depend only on the prototype of the
"make invoice" function, not on its precise definition /
implementation. The engine would #include the right business/foo.h
file, and that's it.

Try this:

-------- A.cpp -----------------

#include <iostream>
#include "local.hpp"

using namespace std;

int main(int argc, char* argv[]) {
  cout << "The result is " << a(5) << endl;
}


int a(int n) {
  if ( n > 1024 || n <= 0 )
    return n;
  else
    return b(2*n);
}

-------- B.cpp -----------------

#include "local.hpp"

int b(int n) {
  return a(n-1);
}

-------- local.hpp -----------------

int a(int n);
int b(int n);

-------------------------

The same dependency loop between A.cpp and B.cpp, eh? This compiles
like this:

g++ -Wall -c -o A.o A.cpp
g++ -Wall -c -o B.o B.cpp
g++ A.o B.o

and also this way:

g++ -Wall -c -o B.o B.cpp
g++ -Wall -c -o A.o A.cpp
g++ A.o B.o


Or maybe I misunderstood your remark.

This discussion is a bit theoretical anyway, as the "no business code
in the engine" condition forbids it.

-- 
Lionel

Attachment: signature.asc
Description: Digital signature

_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel

Reply via email to