Are there standard restrictions on C++ features?

views:

199

answers:

+2 Q:

Are there standard restrictions on C++ features?

I am about to start a new realtime project. Now there is (again) the debate about c vs c++. Yes I read about Linus and all the other threads on SO.

First I was tending more towards to use C but then I read an answer that C++ includes C. Then I read on the internet about "Embedded C++". According to this article EC++ is dead. But I think a kind of "feature guideline" for C++ could be useful to manage the complexity of C++.

So now I ask myself (and you):

Do you use Embedded C++?
Are there other other guidelines for using C++s features in your company/project? (apart from just formatting guidelines)

+3 A:

Embedded C++ basically removed exceptions, mainly because they added a lot to the library, and in embedded system you are very space constrained. As RAM get smaller & cheaper (40 GB iPods?), even that is less of a concern.

I have yet to hear any legitimate reason to prefer C over C++.

James Curran 2010-09-24 19:18:35

Linus Torvalds has a popular presentation on that somewhere.

Gabriel Ščerbák 2010-09-24 19:20:24

@Gabriel: I've seen his rant (which is basically "C is better than C++ because bad programmers use C++"), and I stand by my statement.

James Curran 2010-09-24 19:24:58

C++ has some actions (destructors, mostly) that are not apparent in code and may take up time within a critical code path while being difficult to spot. Aside from that many C++ libraries are written with the assumption that there is plenty of memory available, which isn't a limitation of the language proper, though. A few other memory usage issues could probably be worked around with different implementations of the virtual object stuff (slower, but smaller) and could probably be improved with global optimization. Oh, it's difficult for C++ to optimize out called methods.

nategoose 2010-09-24 19:37:23

@James Curran I agree, that is a rant, but often quoted... Linus is well known for his arogance, which is seen as appropriate, based on his achivements

Gabriel Ščerbák 2010-09-24 19:47:31

The only legitimate reason for using C over C++ is compiler support on your platform. If your platform supports it use C++ otherwise use C. The gain in maintainability is huge, while any drop in performance is minimal to non existent (for comparable functionality) the extra memory used is slight.

Martin York 2010-09-24 19:58:34

sbi 2010-09-24 20:28:08

@sbi: Thanks for this enlightened answer, doubt it'll change Linus' mind about C++, but I'll give him something: with `std::string` in the Standard Library, it's difficult to pose as a serious language... too bad we have to keep it for backward compatibility reasons :/

Matthieu M. 2010-09-24 20:50:49

@Matthieu: What's wrong with std::string?

James Curran 2010-09-24 20:53:16

@James Curran: it's bloated (http://www.gotw.ca/gotw/084.htm) yet you need the Boost.String algorithms libraries to get the most out of it... Also note the dualism indices / iterators which certainly contribute to the bloated code. Finally note how despite being so big it doesn't address the very important issue of internationalization (you need libraries for Unicode).

Matthieu M. 2010-09-24 20:56:08

@James: It has about four hundred search functions, and I can never remember which ones take indexes and which ones take iterators. And the half a dozen (or so, I didn't count) searching functions from `<algorithm>` add insult to injury to that.

sbi 2010-09-24 20:58:38

<pedanting>40GB ipods have 40GB of Flash, not 40GB of RAM. 40GB of RAM would be very nice, but it's still a few years away even for most desktop PCs</pedanting>

Steve314 2010-09-24 21:33:01

`std::string` is far better than C's string handling, and is generally superior to what most people could code for themselves. For most purposes not involving Unicode (and they're getting rarer nowadays) it's good enough.

David Thornley 2010-09-24 21:51:56

@Matthieu: From what little I have seen of the guy, nothing will ever change his mind on anything, once he has acquired an opinion.

sbi 2010-09-25 09:47:16

@David: I agree, at least it works. I do wish for a guru out there to design a truly magnificient class, but working with multiple languages (like Greek or Russian... still waiting for Asiatic ones ;)) I find myself quite contrite that Unicode is not really supported (thanks for ICU, but the interface is C-ish). @sbi: that's a shame since given his successes people are likely to listen to him :/

Matthieu M. 2010-09-25 10:28:12

+2 A:

I think MISRA is exactly what you might be looking for.

Gabriel Ščerbák 2010-09-24 19:19:29

Thats for C isn't it? Or is there even Misra-C++? .... google... Oh yes, I look into that.

schoetbi 2010-09-24 19:22:38

@schoetbi there is a direct link to C++ version on the page I linked to.

Gabriel Ščerbák 2010-09-24 19:48:45

JSF C++ standard (http://www2.research.att.com/~bs/JSF-AV-rules.pdf) incorporates a lot of MISRA.

gregg 2010-09-24 19:50:54

+4 A:

Our software runs in realtime, and after spending quite a few weeks with oscilloscope, I had to concede that on our hardware (pentium M and the like) modern C++ with all of the heap allocations done by the default_allocator of its maps and deques, and all the locking done by shared_ptrs, passed every latency/jitter/determinism test we could come up with.

The OS settings (like disabling the C2 state or tuning the drivers' kernel thread priorities) had orders of magnitude stronger effects than switching to memory pool allocators or any other classic RT programming approaches. Of course we can extract more microseconds from the same hardware using strictly disciplined C, but the cost of development and maintenance of that software would dwarf the cost of a slightly more up-to-date controller.

I'd say the main guideline is to get a good digital scope.

Cubbi 2010-09-24 19:42:58

@Cubbi: You have by any chance used the Loki::SmallObjectAllocator? If so, what impact on the performance have you seen?

Gabriel Schreiber 2010-09-24 19:55:51

@Gabriel Schreiber: Didn't try that one. Tried boost pool, FSBAllocator, and a self-made proof-of-concept one. I guess we just don't do enough allocations to make a big difference.

Cubbi 2010-09-24 20:05:27

Also, the C++ language is not the C++ library. If you need different containers with different memory characteristics, there's no reason why you can't package them up in your own library - or use someone elses that has already been written and tested. Boost intrusive containers, for instance.

Steve314 2010-09-24 21:18:59

+1 A:

Here is one real life scenario. May not answer the question but still interseting.

One popular desktop software was to be ported on mobile. The code was in C++. The team saw problems in using virtual functions. The problem was that the vptr pointer was taking lot memory which was causing problem. The team went back removed all the virtual functions and then used function pointers.

There could be such small glitches like this, but in such case you can always go back and code that part in pure C.

Manoj R 2010-09-24 19:51:13

Erm, could you please elaborate on that? I mean, _replacing virtual functions by function pointers_? That's like replacing an airbag by an automatically inflated air cushion.

sbi 2010-09-24 20:31:44

+2 A:

I develop professional software for an embedded platform (ARM). We use C++. We do have a number of common and reasonable guidelines, but nothing that is specifically there because of embedded systems. We have no restrictions on C++ features (no exception ban etc).

A "feature guideline" might help you but will not eliminate the need to just learn the language. Which takes some time. If you don't have the time, choose a different language that can be learned faster.

As for C vs. C++ vs. EC++:
In another company we developed software for embedded boards that needed to be battery-powered and had really small memory. In that case C can be sufficient, but still doesn't really provide an advantage. If this is not the case, choosing C over C++ is like choosing a pedal car to drive on a german highway. It is ridiculous.

I just read about EC++ and just could not figure out what advantage it might provide. I just couldn't. Without EC++ there is still now one forcing you to use exceptions.

I have yet to hear any legitimate reason to prefer C over C++.

I second that.
I have thought about this now and then. Avoiding C++ might just be a strategy of people who are too [beep] to learn C++ and who are then arguing that there are technical reasons.

Gabriel Schreiber 2010-09-24 19:51:56

C++ is my main language, but I wouldn't go this far. The legitimate reason to use C is because you don't need the extra features in C++, or because the gain from using C++ would be less than the cost from learning it and making all the usual newbie mistakes (such as excessive data hiding, forcing things to fit x or y design pattern, etc). There is no one true way - what is best depends on context, and if you're using C now and it works for you, the "if it ain't broke don't fix it" principle applies.

Steve314 2010-09-24 21:29:32

Other reasons for using C: It's still more portable than C++, and there's a heck of a lot of existing C software out there. I'm not sure if it's harder to code safely in C or C++, but coding safely is very different between the two.

David Thornley 2010-09-24 21:53:59

+1 A:

From my experience of over 30 years in the embedded systems arena, I prefer C++ over C. C++ has added more robustness and safety with less work by the programmer.

I've programmed on small platforms as well as platforms with huge memory space. Trying to implement some C++ features using C is still a pain. These features include, but not limited to: exceptions, smart pointers, inheritance and templates.

If it were my decision, I would program embedded systems in C++. Most of the time, the choice has already been set: C. :-(

Thomas Matthews 2010-09-24 21:34:58

ansaurus

tags:

views:

answers:

Are there standard restrictions on C++ features?

related questions