(I hope I haven't misunderstood what you're shooting for, if so, much of
this might not make sense.)
Patrick Hartling wrote:
> Dirk Reiners wrote:
>> Hi Allen,
>>
>> On Thu, 2006-08-17 at 21:34 -0500, Allen Bierbaum wrote:
>> To sum it up: could work, but would require support by the OS.
>
> I tested linking an application with unresolved symbols on Red Hat
> Enterprise Linux 4 x86_64, Fedora Core 4 i386, Windows XP (using Visual C++
> 7.1 and 8.0), FreeBSD 6.1-stable, and Mac OS X 10.4.7. With the right
> additional options for the linker, I was able to create an executable
> containing unresolved symbol references. The GNU linker, the Apple linker,
> and the Visual C++ linker all require different options to make this work,
> of course. The executable loaded, but it didn't run on any of them. It
> crashed when trying to call the unresolved symbol, but it ran fine when the
> unresolved symbol is not called. Hence, there is some hope that osgInit()
> could save the day.
Wouldn't you have to go pretty low-level in order to make osgInit() call
the OS's dynamic linker to resolve things? I've never heard of anything
like it being done ever before. (If that is what is being suggested.)
> A different issue is that, on Windows, the linker outputs a warning that is
> likely to make a lot of people nervous:
[snip unresolved symbol]
> There might be another option that can suppress this warning. Nevertheless,
> in all cases, you're basically requiring users to give up link-time checks
> that would catch missing library references or other simple mistakes that
> lead to rather ugly crashes at run time.
I think that giving up type-safe linking is quite a bad thing in
general. Either you have load-linking, or you don't (and in that case,
work around it via reflection or common plugin interfaces.)
>>> As far as b), the method I was thinking of wouldn't need that (as far as
>>> I can tell) because it would just load all the libraries that it can
>>> find at startup time. There would be no dynamic searching of the
>>> libraries that it needs for a given node type.
>> OK.
>>
>>> As an aside, using something like "FCFactory::create("Geometry")" would
>>> not really help the usability of OpenSG IMHO.
>> Nope.
>
> Unfortunately, this--or something like it--seems to me to be the most likely
> way it would have to be implemented to avoid complexities when linking. Even
> when reflection is built into a programming language, I have found it to be
> cumbersome to use. Aside from writing unintuitive code, you are, of course,
> giving up some compile-time and link-time checks that would otherwise catch
> small typos and such. Nevertheless, I really like reflection and what it
> provides at a high level, and OpenSG's use of reflective interfaces is a
> beautiful thing. Getting down to the nuts and bolts of reflection, however,
> usually requires writing code that isn't always pleasant.
It seems like we have to define what kind of code we want to write and
how that code is supposed to link to OpenSG. I don't really see
reflection/dynamic stuff replacing all my hard-linked OpenSG code
without performance going down the drain, so what problem are you really
trying to solve here? :)
On reflection & class loading in general:
Java is an interesting case of reflection, where it has it's own
dynamic-on-load-resolve-reflection thing where everything in the class
files is dynamic and you get a run-time error when trying to call a
function which doesn't exist (assuming you where able to compile the
code in the first place). Making this work requires the whole
VM/bytecode thingy to work around the constraints of linking (i.e.
C-based) that the OS gives us.
I've been looking at various ways to load code dynamically and injecting
it into processes for similar reasons, and it isn't very nice. C++ is
not a very dynamic language in terms of linking. Let's not force it into
something which it is not. (And rather concetrate on the scene graph
stuff, which is the problem we _are_ trying to solve :)
Making OpenSG bindable to any script language and then making dynamic
stuff from such a language (python/java/xml/etc) is probably a better
way to get what we want.
Making good script bindings to java is not easy either, as it is still a
statically compiled language (which is nice, since you get some support
by the compiler or the IDE (Eclipse)).
Totally dynamic stuff (python) has it's place, but is not something that
I would imagine scales to big software.) Also, the more dynamic you make
things, the more performance you lose.
My plan for our system is to have C++ in the bottom for performance
critical stuff, a java (or maybe python) binding for GUI stuff,
BeanShell/Groovy or more python for fully dynamic scripting, coupled
with some xml to set up scenes with all of our objects. Given a
java/python binding, everything else falls out quite nicely.
Since OpenSG uses FCDedit, it would be quite easy to make it also
generate script binding helpers. I.e. c-function wrappers for everything
and some additional stuff to allow users to generate bindings (similar
to swig, or perhaps in conjuction with swig, producing c++-code which
swig indeed can parse, if the current code is too complex, something
Dirk has mentioned previously.)
So, I've thought a lot about this and I would love to discuss it. (Since
I haven't found a good newsgroup for these issues, comp.lang.c++ is too
lowlevel.)
Cheers,
/Marcus
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
