This is a great question. Sounds like you have a few different problems:
- Changing the runtime state (introspection)
- The GUI
First, I'd like to ask how much memory you have available on the embedded system, and how many classes you are planning on using this introspection approach on. Do you have threads or processes on the embedded platform? Does your parameter tuning program have to run on multiple platforms?
If you have enough memory, you may want to embed something like lua, tcl, ruby, guile or python and wrap them in C++, then introspect those classes. I know this sounds like overkill, but it will seperate the dynamically changing classes from the rest of the program. As I'm sure you know, it is a pain to manipulate runtime state in C++. Pain will be eased by using SWIG
Do inherit from a class that has something like read_state() and write_state() in some format you can understand. Check boost - they may have something usable for you.
Also, think about whether it is strictly necessary to modify the various attributes on the fly with custom code. What I mean is, if you have a reload()/init() (better yet, the constructors themselves) method in your classes, you can have your GUI write out what amounts to a config file, and use the same interface to change parameters that you do to initialize the objects. This will help you keep your class invarients better.
Whatever you do, try not to let any of the UI muck get tangled in your embedded app. (For example, having your embedded app spit out html directly). Even if you have to write a seperate program to run on the embedded platform, that would be better than having your app communicate with your control program (be it a browser or native UI) directly. ( Unless your embedded app is already a web server:P )
It will almost certainly help you to use a command-line program (write it in some scripting language to save your time) as the first incarnation of the properties twiddler. Use a simple ascii protocol. This will be easy to convert to html later on. You will be happy to have your command line tool while you are debugging the browser interface.
If you have the ability to run a seperate program that just proxies your simple protocol to the web browser, so much the better. Thttpd is your friend here. It is one of the easiest HTTP servers programs to port to a limited platform.
A web interface has the following advantages:
- Easy to update/change the code
- Cross platform
If you haven't done any client UI stuff on windows or Linux, believe me, now is not the time to learn MFC or X11 or Qt or GTK+ etc etc. The only app I'd attempt with "native" widgets in that case would be with Tk.
Good luck!
P.S. The efficiency hits of all the above will almost certainly be worth it.
have you used purify/valgrind? as far as "avoiding the inefficiency of array bounds checking on each access" they pretty much suck. performance is nowhere close to what could be considered "production" level.
This is only because the C runtime does not help in this regard. This can be done very efficiently in other environments.
They are at the Olympic freakin' games! They should be lovin it. Why can't they catch the wave of human compassion, and let those corporations have a little fun, too?
Heck, if they are so opposed to a little increased mindshare, why don't they leave? They should just do it.
They shouldn't put up with being somewhere or doing something that doesn't make them happy. They should go everywhere they want to be, not where someone tells them to be. That way, they would be able to share moments. Share Life.
What do they want? To have it their way, right away?
But, with all of the terrorist threats lately, bringing passport documents into the digital world is sure to increase security
I am very disappointed that such uncritical thinking makes it through all of our BS filters daily. I know I go slack-jawed when I watch TV, too, but I try to slap myself really hard when it's all over.
There are many parts to physical security, and verifying that someone is who they say they are is only one part of it. Furthermore, one must make sure that the data cannot be copied, or used by another person. Lastly, you have to make sure that the datacon't easily be unlinked from what you are trying to authenticate (eg. Person's name and their face *shudder*)
Merely digitizing the data won't help one whit.
Putting it onto a processor that can communicate without physical contact is even worse.
I am not going to comment on the privacy/liberty angle, because it is mostly orthogonal to the security question.
If there was no IDing, they wouldn't have any idea, and might not for several days.
Wouldn't you give your Mom and Dad a call?
Wait, you do have a point - if you are horribly wounded, and there were no IDing, they might think you were dead, and you weren't. On the other hand, you probably wouldn't be far from the crash site.
Hmm. I see no clear advantage or disadvantage in this specific case (IDing bodies) to showing ID, but your post did make me think of an analagous (or rather, more extended) situation. Imagine if you had the ability to register and unregister yourself with a system that kept track of your whereabouts. Then, if you were doing something remotely dangerous (surfing, flying,...) You could register, and when you were done, you could unregister.
It's pretty clear that the individual being monitored (or their legal guardian) should have control over that system, tho.
Slashdot Mirror
- Changing the runtime state (introspection)
- The GUI
First, I'd like to ask how much memory you have available on the embedded system, and how many classes you are planning on using this introspection approach on. Do you have threads or processes on the embedded platform? Does your parameter tuning program have to run on multiple platforms?
If you have enough memory, you may want to embed something like lua, tcl, ruby, guile or python and wrap them in C++, then introspect those classes. I know this sounds like overkill, but it will seperate the dynamically changing classes from the rest of the program. As I'm sure you know, it is a pain to manipulate runtime state in C++. Pain will be eased by using SWIG
Do inherit from a class that has something like read_state() and write_state() in some format you can understand. Check boost - they may have something usable for you.
Also, think about whether it is strictly necessary to modify the various attributes on the fly with custom code. What I mean is, if you have a reload()/init() (better yet, the constructors themselves) method in your classes, you can have your GUI write out what amounts to a config file, and use the same interface to change parameters that you do to initialize the objects. This will help you keep your class invarients better.
Whatever you do, try not to let any of the UI muck get tangled in your embedded app. (For example, having your embedded app spit out html directly). Even if you have to write a seperate program to run on the embedded platform, that would be better than having your app communicate with your control program (be it a browser or native UI) directly. ( Unless your embedded app is already a web server :P )
It will almost certainly help you to use a command-line program (write it in some scripting language to save your time) as the first incarnation of the properties twiddler. Use a simple ascii protocol. This will be easy to convert to html later on. You will be happy to have your command line tool while you are debugging the browser interface.
If you have the ability to run a seperate program that just proxies your simple protocol to the web browser, so much the better. Thttpd is your friend here. It is one of the easiest HTTP servers programs to port to a limited platform.
eg. \n
class: foo
attrib: blarg=jack
attrib: sam=600
\n
A web interface has the following advantages:
- Easy to update/change the code
- Cross platform
If you haven't done any client UI stuff on windows or Linux, believe me, now is not the time to learn MFC or X11 or Qt or GTK+ etc etc. The only app I'd attempt with "native" widgets in that case would be with Tk.
Good luck!
P.S. The efficiency hits of all the above will almost certainly be worth it.
This is only because the C runtime does not help in this regard. This can be done very efficiently in other environments.
They are at the Olympic freakin' games! They should be lovin it. Why can't they catch the wave of human compassion, and let those corporations have a little fun, too?
Heck, if they are so opposed to a little increased mindshare, why don't they leave? They should just do it.
They shouldn't put up with being somewhere or doing something that doesn't make them happy. They should go everywhere they want to be, not where someone tells them to be. That way, they would be able to share moments. Share Life.
What do they want? To have it their way, right away?
Jeez
The Olympic Partner Programme (TOP)
I am very disappointed that such uncritical thinking makes it through all of our BS filters daily. I know I go slack-jawed when I watch TV, too, but I try to slap myself really hard when it's all over.
There are many parts to physical security, and verifying that someone is who they say they are is only one part of it. Furthermore, one must make sure that the data cannot be copied, or used by another person. Lastly, you have to make sure that the datacon't easily be unlinked from what you are trying to authenticate (eg. Person's name and their face *shudder*)
Merely digitizing the data won't help one whit. Putting it onto a processor that can communicate without physical contact is even worse.
I am not going to comment on the privacy/liberty angle, because it is mostly orthogonal to the security question.
If there was no IDing, they wouldn't have any idea, and might not for several days. Wouldn't you give your Mom and Dad a call? Wait, you do have a point - if you are horribly wounded, and there were no IDing, they might think you were dead, and you weren't. On the other hand, you probably wouldn't be far from the crash site. Hmm. I see no clear advantage or disadvantage in this specific case (IDing bodies) to showing ID, but your post did make me think of an analagous (or rather, more extended) situation. Imagine if you had the ability to register and unregister yourself with a system that kept track of your whereabouts. Then, if you were doing something remotely dangerous (surfing, flying, ...) You could register, and when you were done, you could unregister.
It's pretty clear that the individual being monitored (or their legal guardian) should have control over that system, tho.