| |
| |
On 2/18/21 11:04 PM Ian MacArthur wrote:
On 18 Feb 2021, at 16:55, Albrecht Schlosser wrote:
These runtime info functions (or static class variables as they are currently) are only meant to give info to the program, not to be changed at runtime. They would be useful for instance if a program is linked against a shareable library and can query whether a certain function is available or on which OS or platform (X11 vs. Quartz on macOS etc.) it is running.
I'm also not sure what this info would be good for, at least the program could tell in an warning message "this program needs Cairo support but the FLTK library it is linked to does not support Cairo" or something like that.
I don't think I’ve even looked at these, nor thought about what they do - what I take from Albrecht’s description is that if a program loaded fltk as a SO/DLL then it could query these symbols and on that basis decide what features to use, is that right?
Even if I wrote something like that, it's not only for a dynamically
linked program. Imagine a user linking their FLTK program on a Linux
system with a system provided FLTK lib (as SO/DLL or static/object
library). Even a simple hello world program could access all these
functions and thus "know" something about the library provided by the
system.
What is this good for? Honestly, I don't know. It's a little like
"looking into config.h" which is not exported by FLTK (why not, BTW?).
Anyway, all these functions have been created by Matt and he could maybe
tell us about his intentions. I can only refer to the docs as they are
(links in my original post of this thread). And it's as simple as
exporting a variable with the contents that reflects the value of a
compile definition at build time.
I imagine to do that the program would need to use dlsym (or equivalent) to access any of the “optional” capabilities in the fltk lib though, since if they were actually linked in the app any “missing" symbols would presumably fail when the app bound the SO.
I’m not sure I see how that would work out though, as you’d presumably have to use dlsym to access quite a lot of fltk functionality to make that hang together?
And if you have to use dlsym to access the features, well, dlsym itself will tell you whether the feature is available or not.
Clearly, I don't understand what is being done here.
All I said is that these variables can tell you something about the FLTK
lib your program is linked to. It's somehow like querying which features
an X11 server provides or the runtime version queries some libs (and
FLTK as well) provide. How you would use that info I don't know. And
again, that's why I asked for opinions.
Presumably this is all irrelevant in a static linked app, where the capabilities are presumably known explicitly at build time anyway?
Even in a statically linked app you can query these functions/values
because you don't know what features were enabled when the library was
built (if you didn't build it yourself).
As I wrote before I don't know of any direct usage example. If nobody
else knows and - as the discussion shows - if we consider these static
variables useless then, well, let's delete them. I'd be fine with
deleting them if nobody can tell how to use them for anything useful.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/65570afb-736a-12f6-3976-7ff209c21325%40online.de.
[ Direct Link to Message ] | |
|
| |
