Printable View
I am wondering if it is possible to have part of a program "pluggable": that you can change out a single source file for another one without recompiling or re-linking the rest of the program.
Is this possible? If it is, does is come at the cost of slower execution?
Not sure what you on about but unless you choose rebuild then the rest of the program remains as compiled in the current object file
I am not sure what you meant by that.Quote:
Originally Posted by rogster001
It should be possible.
If you are calling any methods inside the file that you swap out, you may or may not have to recompile or relink the rest of the program that depends on this file.
You could also make a DLL out of the source and only swap this one out. You may have to relink, though, but it should be faster than compiling.
I'm sure there are methods out there to avoid recompiling source files.
I the DLL method won't work for me because it exists only in Windows, but by program is exclusively written for and depends on *nix/X Window System.
But maybe there is an equivalent thing in Linux.
And I would still like to avoid relinking, because the point was that the user would have the executable to run, and they could swap out the pluggable part (doesn't matter if it has to be in binary or source form) to get different behavior, without having to use a compiler/linker.
Ah, well, why didn't you say so in the first place?
Then you would use dynamic dll loading, or equivalent in Linux.
"Perhaps UNIX has the functionality of something more complex than a pocket calculator."Quote:
Originally Posted by MTK
Uh, yes, of course it does ;-)
Shared objects can be loaded and unloaded at runtime. See dlopen(), which is the moral equivalent of LoadLibrary() on Windows, and see dlsym(), which is the moral equivalent of GetProcAddress(). You will need to understand how to use function pointers.
I didn't get it.Quote:
Originally Posted by brewbuck
I'll see what dlopen() and dlsym() is.Quote:
Originally Posted by brewbuck
The windows equivalents don't help, I know nothing about Windows-specific programming.
I made a small test program and got this compiler error:
main.cpp:Code:$ g++ main.cpp
/tmp/ccQ6aIip.o: In function `main':
main.cpp:(.text+0x13): undefined reference to `dlopen'
main.cpp:(.text+0x28): undefined reference to `dlsym'
collect2: ld returned 1 exit status
Code:#include <dlfcn.h>
int main() {
void *dlhello = dlopen("pluggable.o", RTLD_LAZY);
dlsym(dlhello, "hello()");
}
The dlopen() and dlsym() functions are located in a separate library called libdl. Add "-ldl" to the end of your compile command.
Also, you will not be able to dlopen() a .o file. It needs to be a shared object.
To convert a .o file into a shared object, do:
Then use myobject.so instead of myobject.oCode:ld -shared -o myobject.so myobject.o
Thirdly, you need to leave the "()" off the end of the function name.
Fourthly, if you are using C++, the C++ function name will be mangled. Unless you want to directly pass a mangled name, you need to turn off mangling for that name by wrapping it in extern "C" {}
It gave me this error:Quote:
Originally Posted by brewbuck
Code:$ ld -shared -o pluggable.so pluggable.o
ld: pluggable.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
pluggable.o: could not read symbols: Bad value
I don't really understand that.Quote:
Originally Posted by brewbuck
On this subject, I got curious if it's possible for a C++ program to call functions in a script (e.g. python, perl)?
That's what I thought you were asking in the first place. You were asking if C++ could parse C++ source code at runtime, like a script, like in Python, Perl, PHP, and every other scripting language. The answer is no. Everything must be compiled beforehand. If you want to use shared objects, that is source code compiled beforehand, separately from the application.Quote:
Originally Posted by MTK
You hit the nail on the head, the solution is to have C++ load and call scripting languages. Python, Perl, LUA, PHP, Ruby, they have a C API to load/parse and call/create functions. You can find it on the respective websites.
You would then compile your C++ application, create your Python script, the application loads it, runs it, and you can change your script without ever recompiling C++. However, you'll end up being required to put a lot of effort into it. Everything you want to do (access) from the script has to be explicitly declared in the C++ application. So there's a lot more initial work, but usually less in the long-run if it's a big project. Especially if you require some sort of scripting anyway, like in a game.
No, I am not talking about parsing C++ code. I am talking about linking to precompiled source code during runtime.
The interpreted language thing was kind of a side question, I was wondering if it would be a better alternative for my project than linking at runtime.
This project is a little experimental GUI toolkit using Xlib, and I thought that linking to a seperate piece of code that draws the widgets during runtime would be a good way to implement themes.
The idea is that the main C++ code manages the widgets, windows, and events, while the pluggable part does the drawing.
Maybe there is a better way to do this, that's just all I could think of.
Using scripting languages for GUI implementation is fairly common. Another common method is just using XML (create, configuration, events, etc). Smaller projects just use the GUI API directly (ala C++). Compiling them separately would certainly work for themes, like plugins, but seems impractical imo.
I'm still not sure that you get it. The pluggable part is NOT a layout diagram for an existing toolkit.Quote:
Originally Posted by Dae
It is a component of an experimental GUI toolkit that I am making that draws the contents of the controls on the raw window at the command of the main code. Simply swapping out this part you can change how the controls of all programs that use it look.
The user that wants to change the theme does not have to compile it. The person that created the theme has to compile it to a .so file or whatever it should be, and the user can just swap those out.Quote:
Originally Posted by Dae
I am still not sure how you can change the theme while the program is running, because it would be quite annoying to have to exit all your programs to change the theme.
I wonder how toolkits like GTK+ and Qt do it.
GTK+ uses some kind of separate theme engines and a special language, it doesn't seem like a fast, elegant, and versatile solution to me.
I heard that Qt themes actually are written in C++ code, not sure how it actually works.
So long as you do not actually load the library into memory, you can swap them all out however you want.
So if you want the user to change a theme, you could, say, enumerate the directory of plugins, load them, call a function inside them to get a friendly name or something. And when the user selects a new theme, you simply unload the old library and load the new library.
Hot pluggable.
This should work with the API you have been given.
Won't it be very, very slow then?Quote:
Originally Posted by Elysia
Not at all...
is that just because hard drives have a cache?
If you load the libraries once and only unload them when changing a theme, it should not be slow.
How would tha program know that the theme is being changed?
Usually, you would have the user notify the program to change theme, no?
A command option or a gui option?
This was going to be more of a library used by many applications.
But, I mean, you know when to swap the library, do you not? In some way, you would know. And when knowing, you can load/unload only when necessary.
Loading and unloading all the time will be expensive, naturally, so you just have to limit it down somehow. This is the only way that you can hot plug code.
I get it. o.0 I use, and create, a lot of applications that do this. It's dynamic, and you do it on Windows with .DLL's and on Linux with .SO's. Console emulators use it to load plugins, .DLL's, compiled by other developers. Valve HL2 engine uses it to load client/server, .DLL's, compiled by game developers. You could use it to load themes, .SO's, created by other developers, I just meant it seems overkill.Quote:
Originally Posted by MTK
Anyway, looks like you got your answer, a long time ago, specifics in brewbuck's post.