Just being picky:

quote:
The extra size of the language required to support templates is almost trivial, isn''t it? One new keyword, two new contexts...

Don''t you mean two new keywords

I use both C and C++ - and the class can be a useful construct. But it''s not that useful for most applications.

C++ supposed advantages are encapsulation/data hiding, inheritance, operator overloading, and Polymorphism.


If you look closely at C, you''ll realize that seperate files are important for data hiding.

You could have a class:

class Model{
private:
Vertex* i;
int** faces;
public:
void rotate(double,double,double);
void rotateX(double);
void rotateY(double);
void rotateZ(double);
//etc
}

Or you could do the same thing in C:

//Model.c
//"private" data members.
static Vertex* i;
static int** faces;
//"public" functions
void Model_rotate(double x, double y, double z){//foo }
void Model_rotateX(double x){ Model_rotate(x); }
void Model_rotateY(double y){ Model_rotate(y); }
void Model_rottateZ(double z){ Model_rotate(z); }


Now the only difference is the way it''s called:
Model.rotate(x); //c++ version
Model_rotate(x); //c version

The C version will likely be a tad faster -- but maybe not enough to be a big deal. I dunno, I can''t think of a good example to use either C++ over C or C over C++...


Basically, I''m the kind of guy who mixes both C and C++. C++ is a superset of C -- why not take advantage of that? My matrix routines make extensive use of operator overloading to make matrix manipulation easier. For drawing lines and other simple primitives, I use the "C way" - no classes. It''s important to make sure the mix is intelligent though - the important thing to remember is to keep every concept seperate. "Fight code entropy" and all that.

quote: Original post by An Irritable Gent

> which is faster, using classes, or using straight code?

Impossible to answer. :-)

> But isn''t it just that little bit slower because you have to pass the ''this'' pointer to every method?

If you don''t use classes (and thus the hidden "this" pointer), you''d end up having to dereference a pointer, or pass an extra pointer yourself anyway. Besides, if passing an additional single pointer is producing a significant slow-down in performace, something''s wrong with your design. Or try inline. :-)

> Another thing, is it really as easy to write a program using classes as it is to write code like you would in C? Or is it easier?

I used to be an "only C" programmer. When I started learning C++, it took me a couple months to really get the hang of things. Now, for me, I have trouble thinking of how to approach a programming problem *without* using classes. But that''s the nice thing about C++ - as you''re learning it, you can still use as much "only C" as you want to minimize the learning curve.

the Gent

Wilka:

They used to just use the "class" keyword, but then they changed it to allow the "typename" keyword. Either way, my numbers are off: 1 more context or one more keyword. IMO, "class" should have been "type" to begin with, because defining a C++ class is much more like defining a new type than simply an class in the OOP sense of the term. In one manner of speaking, it''s like typedef on steroids.


Anonymous Poster:

Aren''t you forgetting about this?


// C++ classes
Matrix m1, m2;

// C++ module
?



If you are going to use multiple instances, then I would advise using C++ classes. The easiest way to do multiple instances with that method in C is to put all the instance data in a struct, then keep a static (meaning: hidden) array (or list) of them in the module. Whenever you want a matrix, you call "create_matrix()" and save the matrix handle. Then you just pass the handle in to any functions and those functions can then look up the correct struct.

(Of course, if you allow the user to directy access the struct (and then an instance handle would be unnecessary), then there is no speed difference. )

There are two problems with the handle approach.

1) Instance management speed. I don''t think that any C method would be much faster than C++''s compiler-generated assembly, and I don''t even know if it will be as fast. What''s the answer in C? It depends on what method you use.

Look at the following examples:


// C++ data member access

class.function(arguments); // = class::function(this, arguments);

void class::function(this, arguments)
{
this->data_member;
}


// C multiple module instance data access
// (assuming the handle is an array index)

module_function(handle, arguments);

module_function(handle, arguments)
{
instances[handle].data_member;
}


// C multiple module instance data access
// (assuming the handle is a list position)

module_function(handle, arguments);

module_function(handle, arguments)
{
list_node* current = list_head;

for( int x=0; x < handle; x++ )
{
current = current->next;
}

current->data_member;
}


// C multiple module instance data access
// (assuming the handle is a pointer to a list_node)

module_function(handle, arguments);

module_function(handle, arguments)
{
handle->data_member;
}


Of course, that code is just to the point of accessing a data member, and we aren''t looking at insertion/removal/sorting and whether multiple data member access in that function is going to be faster/slower. To my knowledge, struct.data_member is one pointer addition and one pointer dereference, as with (&struct)->data_member. Do any of the people who know assembly care to comment on this code? Anybody see anything they knew, or weren''t expecting? Are any of my solutions not feasible? Could the C methods be optimized further? Or are they too simple?


2) Coding/debugging time. It''s irritating to have to implement the workaround when you could have written a class. After all, the same code is necessary, except of course the code to juggle multiple instances. And, of course, when you replace the someone else''s code with your own, you introduce the opportunity for bugs.

You might say that C++ classes are an easy way to implement multiple instances (and much more, of course).




- null_pointer
Sabre Multimedia

quote: They used to just use the "class" keyword, but then they changed it to allow the "typename" keyword.

typename was added so that you could safely declare variables of a type defined in a template class. e.g.

template
void f()
{
typename T::something myVar;
}

You can also use if in the template parameter list, but that''s not the reason it was added.

quote:
Either way, my numbers are off: 1 more context or one more keyword.

I was referring to template and typename, so it''s still two Or did you miss type that (you said your numbers are off, but didn''t change them)?

Wilka:

I haven''t been able to do much online except respond to this topic.

Actually, I meant "one more than I accounted for," which is two.

BTW, thanks for the interesting explanation of why typename was added! Is typename really needed though? Why not just do:


T::something myVar;



Or was typename added just to reflect what typedef really does? - typedef just makes a synonym for an existing type, and not a new type.




- null_pointer
Sabre Multimedia

I''ve been programming in C for about a year now, however I utilise a large amount of C++ code in my work. Hence I use stuff like encapsulation all the time and just didn''t know it had it''s own special name...

Anyway, my opinion is that it depends on what you are really doing to be using C or C++. If you are going to be just writing a quick hack to prototype code for all means use C. If you want to incorporate it into a large project, then use C++, it makes your life so much easier it is not funny.

An example:
Write a stack routine in C
Write a stack routine in C++

Which can be reused in the future without any real effort, the C++ version of course, using templates you can effectively prevent rewriting the stack for different types (long, floats etc) and you don''t have to make the data global to the entire stack.

This helps to reduce program''s general "buggyness" by preventing the external code from doing stuff to the stack that would be unexpected. (through encapsulation).

Therefore: I personally prefer to use C++ code in my projects but I will probably prototype code in C.



--------
Nekosion
--------

null_pointer:

The compiler would be able to tell if something is a type some of the type, but not all the time. For example (and a pointless example, because people don''t do this):

T::something(myVar);

This could be a function taking ''myVar'' as a parameter, or it could be the declaration of a variable ''myVar'' with a type of T::something. So unless you specify that it is a type, it''s assumed to be a function. typename is needed whenever the name of a type depends on a template parameter. Some compilers correctly ''guess'' that you mean a type (some of the time), but there''s no rule that says they need to, so it''s better to use typename all the time.

Oh yeah, if you take the handle approach with multiple module instances in C, how do you do arrays?

Like this, of course:


matrix_handle matrices[3];

for( int x=0; x < 3; x++ )
matrices[x] = create_matrix;



But what if you need to allocate contiguous arrays of the instance data, as with bitmaps using a color class?


BTW, here''s a chart for classifying C++ programmers:

1) If he mentions a feature that C doesn''t support but C++ does, he is arrogant and a show-off.

2) If he constantly corrects or explains performance "problems," he is narrow-minded and stupid.

3) If he uses big words to talk about concepts he considers extremely important, he is just another media zombie.

4) If he posts source code to explain his points, he is showing off.

5) If he says his methodology is superior, that means he is self-conceited.

6) If all of the above apply, he is a C++ zealot.


Just match up the actions with the adjectives, and you''ve got a description. Or at least that''s how I''ve seen it work. Maybe I''m wrong?


Here''s a chart for responding to C++ posts:

1) If the post claims that a C++ feature reduces development time, show how we can do it in C.

2) If the post claims that doing it in C is harder, then the post is wrong because we all know C is easier.

3) If the post claims that the C++ method for that feature introduces additional features and benefits, then C++ is too complex.

4) If the post claims that the C++ feature introduces no overhead, well, we all know that C++ is just slower.

5) If the post says something we don''t understand, it''s stupid.

6) If the post proves something, go somewhere else - we all know that whatever it is, it''s not true anyway.

7) If the post says I''m wrong, then it is being too opinionated.


Just classify the post and you''ve got your automatic reply.


(NOTE: These charts were not intended to irritate anyone - they are merely my observations on this topic and numerous others just like it. If you can correct any of these things, please reply.)




- null_pointer
Sabre Multimedia

STOP!!!

quote: Original post by null_pointer

5) If the post says something we don''t understand, it''s stupid.

I don''t get it, this post is stupid, I''m going somewhere else!

( nice summary of generic flame posting in this thread though, null_pointer. I can pick out an example for each point somewhere in this thread )

C++ FOREVER! Mwuhahaha!




Give me one more medicated peaceful moment.
~ (V)^|) |<é!t|-| ~
ERROR: Your beta-version of Life1.0 has expired. Please upgrade to the full version. All important social functions will be disabled from now on.