C vs C++ ?!

When I coded in C, I used to write class-like' modules, where I would have a constructorie. Object_CREATE ( Object *pObject ) and all methods associated with that object type would accept a pointer,ie:

Object_DO_THIS_WITH ( Object *pObject );

Now - this works in that code and data are fairly closely bound (up to the programmer of course) - however, of course polymorphism, inheritance etc are impossible to implement in this way without kind-of writing your own compiler - which would be a total waste of time when you can use C++.

My vote, of course, is C++… http://www.nigels.com/glt/

Given that C nearly always compiles clean
with a C++ compiler, and C++ has lots of
good features, in the graphics context I
don’t see the point of using C.

Things like type safety and function
overloading are good things. IMHO
Proper OO and generic programming (templates) are the icing on the cake…

That’s just my 0.02, which is worth only USD$0.01!

[This message has been edited by nigels (edited 04-25-2002).]

I use C mostly, but with it I use classes.

I just couldn’t resist:

Originally posted by Michael Steinberg:
This is a debate about what you define OOP. Many faq’s and I believe even the inventor of C++ say that polymorphism is what OOP makes “practical” (?). Just having structs or simulating OO stuff with C is not object oriented programmin in my eyes.

“I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.”
- Alan Kay

Okay.

Let’s come to the conclusion that c++ is a OO language whereas c is not. What you do with it depends on the programmer.

typedef struct {
void (*drive)(void);
} car;

void vwdrive()
{
printf("crash
");
}
car *createVW()
{
car *ret = malloc blah blah
ret->drive = vwdrive;
return ret;
}

void dodgeneondrive()
{
printf("Drive all bad arsed
");
}

car *createNEON()
{
car * ret = malloc blah blah
ret->drive = dodgeneondrive;
return ret;
}

I just created not only a virtual function table in C, but also polymorphism with exactly then same syntax as C++ (no switch statements).

Car = createVW()
Car->drive();
“crash”

Car = createNEON();
Car->drive();
“Drive all bad arsed”

Which is not to say it is not easier in C++, but you can do OO and polymorphism in as horrifying a language as F77 if you want.

[This message has been edited by nickels (edited 04-26-2002).]

Hmmm, how would you implement the this pointer then. Without the this pointer this stuff basically is senseless. I actually have no idea how to implement the this pointer, since c itself won’t give the function the pointer to the struct. You would end up having to pass the pointers to the functions.

As I said, C is a non-OO language, you can do oo with it however. As c++ is an OO language but you can certainly do non-OO stuff with it.

I recommend c++ for large projects > 10,000 lines of code. Really, global functions(you don’t want them static and hidden) are impossible to look up in a sea of function names. You would have to prepend monikers to differentiate and order your functions. I already do that in c++ with z_Foo() in vc++6, I can’t imagine you doing straight c and scrolling down the list everytime you want to look up a function. Try Genesis3D source code and you’ll see exactly what I mean.

Plus, c++ operator overloading is nice for vector, plane, etc. math classes. You don’t have to go with inheritance, you can subclass other objects. There are too many advantages to going with c++. If you’re going to use it as c then at least you’ll gain encapsulation which is helpful in large projects like I’ve mentioned previously.

IMHO operator overloading is a nice gimmick, but it’s not really usable because of the copies involved. Template Expressions help, but on 4-component vectors they’re slower than using inline functions. They’re much faster than operator overloading though.

Mike, what do you mean by copies? Don’t you use references? I’m baffled.

I mean temporary copies of the objects during evaluation.
That is, because you can’t return a reference to an existing vector when you have the + operation on them, because it results in a new vector. I didn’t look too much into compiler optimizations, but on the one i did, it really made these temporary copies.

Michael,

IIRC (haven’t coded for several months now), the general convention for operator overloading on a class would be like this:

class vector4 {

explicit vector4(const vector4& v) : /* implementation dependent */ {}

inline vector4& operator+=(const vector4& rhs)
{
// add rhs to *this
}


};

const vector4& operator+(const vector4& a, const vector4& b)
{
vector4 temp(a);
return temp += b;
}

Of course I may be showing my ignorance here because as I say, it’s been a while since I fired up my compiler.

OK, I just opened up Stroustrup 3rd Ed and he has a similar operator+= example and mentions that it should be inlined very easily depending on how you do your implementation of vector4. You can’t get away without a temp variable in the operator+ but if you define an efficient copy constructor, it should still be fairly cheap. I like using this method for readability anyway.

Gruesse.

[EDIT]BTW, you need a temporary copy anyway for the operator+ example. If you do:

a = b + c;
// then a is a new vector isn’t it? Otherwise, if you are doing:
a = a + b;
// then you should just be using:
a += b;
// and you get the inlined version anyway.
// I guess the other case is if you are doing:
vector4 a;
a = b + c;
// and a already exists, in which case you
// could create a new function like this:
void add(vector4 *a, const vector4& b, const vector4& c);
// and return the value in a. That’s how I
// would do these operations (although I
// probably wouldn’t do the last one).
// How would you do the equivalent operations
// (I’m just curious )?

[/EDIT]

[This message has been edited by ffish (edited 04-29-2002).]