On 10/8/2011 12:59 PM, Jonathan Wakely wrote: > On 8 October 2011 17:37, Charles Wilson wrote: >> >> Not hopeless; but you have to treat C++ simply as a slightly more >> expressive version of C, follow the same rules previously outlined just >> as if you WERE using C, and avoid the STL... > > If you're going to spout FUD
It's not FUD; to meet the goals of the OP's proposal, the above is what you would have to do. I'm not advocating doing that in general -- it is one specific solution (among many) for a specific problem, /assuming/ you want to use C++-ish code at all. (Just like if you want to avoid RTTI -- akin here to avoiding the heap -- g++ provides a solution (-fno-rtti) but your app to work properly under -fno-rtti, you have to follow certain rules in your code and, obviously, avoid relying on constructs that require RTTI). It's a rare situation where you'd have any need to use some "Heapless C++" variant, but not completely unheard of. I've actually had to work a project where (a) C++ was mandated, but (b) heap allocation was barred. (Yes, the requirements specifications were...ill advised). I speak from experience, not "Fear, Uncertainty, and Doubt". (We didn't try replacing all heap usage with stack-based allocation; instead we wrote our own allocators using pre-defined mem pools provided at system startup by the kernel memory map. Sort of like a heap, but with bounded free() timing. The penalty was memory inefficiency due to the lack of block coalescing. Obviously you wouldn't want to do this sort of thing on a general purpose desktop, but for a single-purpose embedded system, and given those ill-advised requirements specifications, it was fine). > about C++ at least use the right > terminology please. Oh for crying out loud. I spelled out "Standard Library" twice, and took a shortcut and typed the (old) acronym once. Pedantic, much? > For a start "the STL" is a library from the 90s and what you probably > mean is "the C++ standard library" and secondly I assume you mean > avoid the standard containers such as std::vector, which allocate > memory. Yes, that is true -- containers are the main concern. But... > There's no reason to avoid using e.g. std::sort or > std::lower_bound on an array. I'm not familiar enough with the standard to know whether the implementations of all algorithms are barred from allocating memory (for temp space, etc). Certainly it seems safe enough to assume std::lower_bound and similar are allocation-free, but some general purpose 'sort' algorithms do in fact allocate memory. I don't know if gcc's standard library implementation uses one of those (and I'm too lazy to check on a Saturday afternoon during football season; the game is on) -- or if the C++ standard (which version?) says anything explicitly about that so that one could universally assume, for all compilers, that all compliant std::sort implementations are allocation-free. So sure, the primary concern is containers, but if you have a hard requirement to avoid ALL heap operations, then you have to check everything, including unlikely places. -- Chuck
