C++ programming or a PhD in Macro defs (Was: How difficult is a Knowledbase notion?)

If SWI-Prolog would be rewritten in C++ maybe a GLOBAL_LD
wouldn’t be needed at all. You could make Knowledgebase
and Engine classes, the C++ compiler would optimize for
you passing around GD or LD in the form of a “this”, and
a method inside an Engine, could access a Knowledge base,
by “this->KB” or simply “KB”. C++ would be even less
annoying than Java, since you can do deferred mixin:
class Person {
    [...]
}
And later:
void Person::Print() {
    [...]
}
Because I don’t have deferred mixin in Java, my own
modularization looks extremly messy, passing around a
parameter explicitly, hoping that the usual register
file optimization of a Java compiler eliminates
most parameter passing. But my C++ knowledge is very
limited, so I don’t know whether a PhD in Macro defs
was the better solution. Was there never a C++
implemenation of SWI-Prolog ?
Mild Shock schrieb:

  > The required changes could be fairly limited.
 I don’t know. You never know before you did it.
With the current design you might end up in a
Münchhausen scenario, trying to defy gravity by
pulling your own hair. It seems there is a global switch
 which engine is active? I don’t understand, isn’t
SWI-Prolog able to run truely concurrently on a
multi-core machine. Because such things, wouldn’t
work for threads that distribute themselves over cores.
 I saw an L_THREAD lock somewhere?
 #define GET_LD      PL_local_data_t *__PL_ld = GLOBAL_LD;
 In the “worker” scenario, a “worker” can typically grab
a CPU core all for himself, and for its knowledge and
for all the engines that work over this knowlegde base.
Thats the beauty of JavaScript
 isolation through “workers”, and it is also used in
the Ciao Playground. Its very multi core friendly, a
“worker” can also have its own garbage collection etc…