Øyvind Harboe wrote: > There are a couple of problems with C++: > > - there is no consensus to use it for OpenOCD. This will be > *hard* to arrive at since there are a lot of deeply embedded > developers that we need for OpenOCD to succeed. > - there is a lot of messy & nasty C++ libraries. I'd hate to see > something as simple as OpenOCD go overboard with cryptic > usage of templates, boost, stl, etc. libraries > - today OpenOCD can compile easily on deeply embedded > OS's, such as eCos, with C++ that gets a bit harder. > > > I believe that OpenOCD would benefit from some restrained > and cool-headed usage of C++ instead of all these virtual > method tables analogues, lack of exception handlnig and > less than robust resources tracking.... Perhaps define strict > rules for what C++ features & libraires that are acceptable >
Yes, I agree wholeheartedly. It is easy to over use the features of C++, especially in an embedded setting. C++ is a rich language. But it is not impossible to get 80% of the value in using it by using only 10% of its features. We do it on our SoftPLC runtime, which is an embedded process controller with great success. The biggest hurdle to the switch is getting a C++ runtime library in place, period. On Linux, that work is zero. On Windows, I dare say it is near zero with mingw. On other platforms I cannot imagine. I don't really understand why somebody needs a small small computer to run openocd anyway. A 64 mbyte linux box can be about as small as you want it nowadays, so I am not totally empathetic to this concern about supporting *all* non-linux embedded environments. Maybe a minimum feature set for targets could be identified. Dick _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
