Re: [boost] [thread library rework] Ready to start

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2005-08-29 10:03:47

> 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.

> 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.

Exception system has a size overhead (well, that depends, but if you 
have 512KB-1MB of RAM...) and in most systems RTTI and exceptions are 
disabled to save space. 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.

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. 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.

Best wishes, and regards,

Ion (embedded warrior)