Robert, On Wednesday 04 June 2008 11:12, Robert Osfield wrote: > Wr.t. the Config and Config.in files. The Atomic implementation is > done purely in the header, so rather than being a configuration of > OpenThreads itself (as OpenThreads itself won't actually build/use > it), it's actually an issue of configuration of the code using the > header. I don't yet actually have an idea what the full implication > of this is, it might be that we have no Config file at all, or move it > into the OSG side. However, what happens in we do make Atomic built > and used internally in OpenThreads.... I would normally agree here. But the basic trick here is that this *is* *inline*. That means that we do not have a function call overhead in some of the implementations. That is the gcc/icc one and the sgi one. The sun implementation and the win32 implementatinon will call library functions anyway. But we can avoid one call here.
Given we use compiler intrinsics in some cases that are exposed to the optimizers, having them inline will provide the compiler to have the opportunity to may be optimize that increments/decrements completely away in some cases. I do not know if gcc/icc/CC is far enough to do that, but in theory such optimizations are possible - and you would sometimes be surprised about what a compiler really does. This kind of optimization cannot happen if this is an implementation in a library. Sure If such a configure option can be encapsulated into the prebuilt sources, this should be done. But under some conditions this will just make sense to have it in a config file. This condition is met at least if such a configuration changes the api of a class - that is also the signatures of the calls (Matrix-Matrix[df]) or if it changes the class layout. > I must admit I'm not entirely comfortable with header files containing > build configurations - its something the OSG has so far not utilised, > instead the build system itself toggles on/off features. And for > items like Matrix mapping to Matrixf/Matrixd this is configured via > the build system, but this in turn means the application has to use > the same setting that the OSG was built with - to solve this for P3D > and VPB I've used Cmake to query the option the the OSG lib was built > with. Is this better or worse than having headers? I have this kind of change, to move that matrix selection into a header in preperation also. IMO it is *way* better to have a installed library shared object match the headers without any commandline define that is required to make it even link with the library... So all in all I would vote for such a Configure file. Greetings MAthias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
