Ion Gaztañaga <igaztanaga@gmail.com> writes:
They were wrong to do so, most especially for templates, which are hugely useful in embedded programming.
I agree with you in templates, if you take care with code bloating.
Bah. Templates can just as easily reduce code bloat. http://groups.google.com/group/comp.lang.c++.moderated/msg/82674634c2a6b3a0 http://groups.google.com/group/comp.lang.c++.moderated/msg/2efe6b65b0e51a4f
In my opinion, that would be a huge mistake. EC++ was created as a "language subset" without the consent or cooperation of the C++ committee. Crippling C++ library interfaces simply in order to maintain compatibility with it is the wrong thing to do, again IMO.
Well, I'm not talking about EC++ but embedded world in general. In my work I program for embedded systems everyday in C and C++ and threading, in my opinion, is a very basic building block for embedded systems, so if we want to put C++ in those systems just like we can do with C (you don't pay for what you don't use) we should have a way to launch a thread in a standard way in limited systems.
I agree.
Exception system has a size overhead (well, that depends, but if you have 512KB-1MB of RAM...) and in most systems RTTI and exceptions ^ embedded are disabled to save space.
I wonder how much space gets spent on error handling without exceptions, and I wonder if the error handling is correct.
Exceptions are also not recommended in real-time systems, and you can use threads and mutexes. As an example, in iostreams, you can activate or not exceptions.
I know.
Not that I think we must limit C++ because of EC++, but that we should think that a very important C++ market (growing nowadays) will be embedded/realtime systems, replacing many C applications, because productivity in C++ is higher and you can get nearly C performance.
IMO it is crucial to engage compiler developers for embedded systems in optimizing their runtimes for those environments. http://groups.google.com/group/comp.lang.c++.moderated/msg/d37971376bfd7e09?... However I agree as a practical matter there should be an obvious way to implementat Boost.Threads that works on a system with exceptions disabled.
And again IMO, threads are too basic. I would never say this for regular expressions, serialization, or any other library. If we can't do anything about that, that's ok, but why not try? I agree that it is hard to get, but that's the beauty of C++, you can put it everywhere, from tiny devices to mainframes. And I think that Kevlin's approach can be safely used in embedded systems if we see that it's easy to get a subset of the full standard, using the same programming style (for example, futures).
It's not that I love EC++ (I don't follow its guidelines, because I use templates in some embedded systems), it's that I see a practical need to take in care those aspects. If C can have it, C++ can. I'm not saying I would sacrifice C++ for embedded world, but it is better to take in care aspects so that we can spread C++ further.
Agreed. -- Dave Abrahams Boost Consulting www.boost-consulting.com