What Programming Language? C or C++?

[The Duud]

Which is better for Cell/SPU programming. thanks.

[The Duud]

100+ Views... Someone answer. I want to start programing.

[Compound]

have you checked the RSX demo? is uses a mixture of assembly and C, i think you can do pretty much everything in c and build ontop with C++, havent had a chance to have a proper look through it all yet, am busy with uni

[jimparis]

Whatever you're more comfortable with. Just start programming if that's what you want to do.

[d-range]

100+ Views... Someone answer. I want to start programing.

Maybe it's because your question cannot be answered conclusively. It depends on what you want to do. If you just want to hack around a bit for fun, and not want to start some serious project I'd start with plain C. For larger projects C++ mixed with C can be a better choice, but even then it depends on what you're doing. If you have no C++ experience at all atm you'd be spending most of your time just learning how to use it properly, for a very, very long time (years maybe ;-). Don't expect SPE programming in C to be easy either by the way.

[mc]

<flamebait>C++ adds nothing to C except a vehicle to generate bloat more quickly.</flamebait>

Write in C.

[The Duud]

<flamebait>C++ adds nothing to C except a vehicle to generate bloat more quickly.</flamebait>

Write in C.

i r choosing C :) see you in awhile :)

[d-range]

<flamebait>C++ adds nothing to C except a vehicle to generate bloat more quickly.</flamebait>

Write in C.

LOL. I think we could have a nice discussion about this over a beer or two, and I wholeheartedly disagree with that ;-). While C++ indeed does add a vehicle with which you can add quite some bloat if you don't use it properly, it also adds the tools to rethink and set-up your design in a way that makes it possible to concentrate on efficient designs and be able to plug-in better/more efficient implementations later, without having to rewrite complete functions or data structures. Programming to interfaces and re-using known efficient implementations without tying you to a predefined and strict functional interface allows for better code.

The code bloat argument is irrelevant if you know what you're doing. C++ adds virtually no runtime overhead, as long as you don't throw in virtual functions everywhere and start deriving everything from anything (like Java does). Adding a single level of indirection on function calls, like when calling class functions adds no overhead at all on modern systems, especially not on PPC because it provides opcodes that have the same cycle count as a fixed address call.

As an example: I'm setting up an MPEG decoder architecture for Cell at the moment. I take great care to keep all number crunching functions plus their in/out arguments strictly in the C domain to allow porting to SPE C or assembly later. For the rest of the code I use only C++. This allows me to use a much more complex decoder architecture, in which buffering between entropy decoding + bitstream parsing and macroblock processing can be implemented behind the scenes, in a configurable and scalable manner. For example, I have a macroblock manager that can be configured with different data partitioning classes that subdivide a frame into macroblock sets based on the data partition shape. The PPE-part of the decoder does not see any of this, it just decodes and puts the resulting macroblocks into a queue. This makes an extremely scalable design in which the number of macroblock processing threads is totally independent of the decoder itself. Together with the MB manager I have a macroblock scheduler that dispatches the blocks to processing threads without showing the internals, which allows for easy porting from PPC on iBook to PPC + SPE on Cell. The macroblock manager also arranges for a linear memory layout of the actual macroblock data of a single data partition, which allows for very efficient DMA transfer to the SPE's of *all* local data required in (hopefully) a single DMA operation. Compared to the processing time of the macroblocks itself (dequant/IDCT/ME/filter/deblock), the overhead of calling class functions instead of plain C-style functions is literally non-existant.

Anyway, all of this can of course also be implemented using pure C89 ANSI C with -Wall -pedantic compilation, but first of all it will be a pain in the ass to program or maintain, you will have no high-level overview of your design at all (especially if you didn't write the code yourself), the run-time performance gain you will get will be in the 0%-0.1% range and most importantly: there is a very big risk you will opt for a simpler design, because tracking 100s of scattered C functions without any level of data abstraction will get very, very messy if you cross a certain level of code complexity.

[Compound]

excellent response d-range

my c++ is really good but not done too much in C so i will probably struggle a little with this, i was just wondering is the ps3dev toolchain for the ps3 the same as the IBM cell sdk code? i.e would using the IBM docs as reference be suitible? or am i going to find it harder working with this? if that makes sense

[d-range]

excellent response d-range

my c++ is really good but not done too much in C so i will probably struggle a little with this, i was just wondering is the ps3dev toolchain for the ps3 the same as the IBM cell sdk code? i.e would using the IBM docs as reference be suitible? or am i going to find it harder working with this? if that makes sense

Going from C++ to C should not be much of a problem if you're not masochistic about it, and allow C99 and non-ANSI-C constructs (like gcc does by default). Then it's just a matter of programming without classes or data abstraction.

I don't know about the IBM cell SDK, since I haven't written a single line of SPE code yet. But I'm nearly there.

[ldesnogu]

The code bloat argument is irrelevant if you know what you're doing.

That's the problem with C++, unless you know what you're doing, you can quickly make underperforming code.

C++ adds virtually no runtime overhead, as long as you don't throw in virtual functions everywhere and start deriving everything from anything (like Java does).

Also remove exceptions.
And take care of class hierarchy, as it can create objects whose size would be bigger than their C counterpart structs ;)

[ps2devman]

I like easy maintenance.

If you don't need C++ just use C. Because looking for an issue in so many separated files is ugly task (you better have one file per object in C++).

But there is a nice case where you need C++. It's when you manipulate etherogenous objects in big sets, linked with sophisticated relationships.
C++ allows you to talk with one of them and ask this object to talk with others in order to obtain automatic propagation (actually a call to a method is propagated).

But usually you have sets of homogenous objects and a loop is all you need, and C is enough for that.

[d-range]

Also remove exceptions.
And take care of class hierarchy, as it can create objects whose size would be bigger than their C counterpart structs ;)

True, you don't want to use exceptions either. I don't like C++ exceptions anyway, except (no pun intended ;-) for business-like applications and such, where you actually expect exceptional conditions. It's too bad so many C++ code is so poorly written, misusing all its features just because it is possible, but I guess that's also because of modern CS eduction. It's all gone along with the RAD way of development, programming to existing API's, protecting the programming from screwing up, etc. Embedded development like you could call SPE programming is a whole different ballgame.

Anyway, it's both the beauty and the uglyness of C++ that you have so many ways to write bad code. Where in C# or Java you normally have only one 1 way of doing something (which is through some kind of API most of the time), in C++ you have literally 10s. That doesn't make it bad, it just makes it powerful and difficult.

So for The Duud I'd definitely recommend C first... Not that it's so much easier, but at least it takes less time to get used to.

I like easy maintenance.

If you don't need C++ just use C. Because looking for an issue in so many separated files is ugly task (you better have one file per object in C++).

If you know how to use common grep/find/xargs and use an editor with ctags that's not really an issue. I actually find C code harder to maintain. In my day job I write and maintain code throughout all of a very, very large codebase. There's a lot of C and (luckily) more and more C++ code in there, some of it over 10 years old. The C code is usually practically impossible to extend properly, obfuscated, buggy, badly designed and even performing poorly because of stupid use of algorithms and datastructures. The only datastructures I see used in the worst C modules are array and single-linked list. They're used everywhere, because no-one bothered to write stuff like trees, maps, hashtables, fifo's etc, which you get for free in C++. Our C++ code is much, much easier to comprehend, maintain, extend, debug, etc.

[mc]

Yup, just avoid using all the C++ constructs like exceptions, virtual methods
and templates, and you get something decent. Namely C. Except that
with a C++ compiler you miss out on some of the C99 goodies like
sane union initializers.

Classes without virtual methods are just structs.

[d-range]

Yup, just avoid using all the C++ constructs like exceptions, virtual methods
and templates, and you get something decent. Namely C. Except that
with a C++ compiler you miss out on some of the C99 goodies like
sane union initializers.

Classes without virtual methods are just structs.

There's nothing wrong with templates for performance-critical code, so you can leave that in, and end up with C plus generics (templates) plus the option to use polymorphism, overloading, constructors/destructors, etc. in places where it is useful. It doesn't have to be an all-or-nothing decision, and for 90% of the code (ie: all code outside critical loops or recursions) the performance hit of polymprphic code is not even measurable. And let's not forget the standard template library full of useful stuff.

A struct is only a class without virtual functions (and without data hiding btw) if you compile using a C++ compiler. You cannot use constructors/destructors/copy constructors/structure methods when you compile using a C compiler.

[ldesnogu]

There's nothing wrong with templates for performance-critical code

I agree, except that deciphering error messages with templates can be a real pain.

Also always declare copy constructors as private methods to avoid using them by accident :D

Did I say I hate C++ ? ;)

[Megidolaon]

Can you program just in C++?

I know a tad of C and am currently taking C++ classes, is that sufficient or do I need to program at least some parts with C?

And what about the ps2dev libraries?
Are they mostly in C or C++?
If they are in C ad I use C++, do I get any prblems or can I just use them easily?

Thanks.

[DJohn]

Does C have function and operator overloading yet? They're the only C++ features I'd really miss.

Adding a single level of indirection on function calls, like when calling class functions adds no overhead at all on modern systems, especially not on PPC because it provides opcodes that have the same cycle count as a fixed address call.

Not in my experience. The object pointer fix-up that C++ requires for multiple inheritence is a fixed cost that you pay whether you use it or not. The indirection adds more serial dependencies and more cache pressure. It's measurably more expensive (I've measured it).

Calling through a function pointer isn't too bad, particularly if you can hint to the compiler that you want to load it early.

The code I'm working on now does use virtuals. But it's designed so a large batch of objects can share a single virtual call. The cost is spread thinly enough that it can be ignored.

[ouasse]

I couldn't do without C++, for one specific feature: I make heavy use of templates for loop counts, which allows automatic loop unrolling (which helps a lot when programming the SPU). I just could not live without this.

[J.F.]

"-funroll_loops"

[ouasse]

-funroll-loops is far from being optimal. In a lot of cases, it slowers code execution rather than accelerating it. When using template loop counts, the compiler knows the number of loop iterations at compile time, thus it can generate an optimal instruction sequence corresponding to the loop count.

Note that this could certainly be achieved using macros in C, at the price of potentially unreadable code.

[J.F.]

The point is that there are ways to do it in C. Perhaps the best is designing the code without loops to begin with. Why rely on the compiler if you don't have to? While it MIGHT be SLIGHTLY more work than C++, it's better than having to use C++. Sorry, but I'm one of those people who will never use C++ for his own work, and only works on existing C++ code under protest. I've never considered the pros of C++ to outweigh its cons. Not trying to pick a fight with people who do use C++, it's just my own opinion, which I'm entitled to.