Sean Barrett doesn''t have a clue about C++?

Come on. He worked from the early 90s up until 1997 in Looking Glass Studios (sadly, they had to close their doors due to financial difficulties). He worked with people who dealt with the language every day. Heck, I bet half of his programmer colleagues were MIT computer science course graduates! I''m quite confident that he knew what he was talking about.

quote: Original post by Anonymous Poster

Sean Barrett doesn''t have a clue about C++?

*snip*
He worked with people who dealt with the language every day. Heck, I bet half of his programmer colleagues were MIT computer science course graduates! I''m quite confident that he knew what he was talking about.

He says so himself in the article. ( That''s why I quoted it ).
And I''ve worked with people who know EVERYTHING about Silicon Graphics machines for years, while I still don''t have the first clue about what exactly these things do.

Sean Barret is a very accomplished C programmer. That does not give him ANY kind of authority to bash C++.





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.

Perhaps, but he has a couple of points in there.

Perhaps, but he has a couple of good points in there.

I don't think so, really.
It reads as if they are good points, but if you think about it, he's always assuming the programmer is stupid as an ass. Of course it's easier to make hard-to-find coding mistakes if your language gets more complex. That's a tradeoff, the more the language does for you, the more is going on behind the scenes.

Now we could all go back to programming in hex code, where all you have to do is check if your numbers are right. Of course, you'll never get around to doing much useful stuff anywhere...
Yes, I'm exaggerating, and I'm not really defending either side, because programming languages are ONLY tools. If you can make what you want to make with the language you are using, you're doing fine;

[edit: I just noticed I finished my last sentence with a semicolon, professional hazard I guess .]

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.

Edited by - MadKeithV on June 29, 2000 1:43:47 PM

Sean Barrett is just another person who thinks he knows more than he actually does. Most of the examples/points made in his post on the web are just ignorance and a bad attitude, and that''s quite obvious to anyone who knows the C++ language. The only thing more pointless (and utterly useless) than that article was a faked interview transcript between Mr. Stroustrop and an imaginary interviewer. Why in the world do people create such things? Can''t they read books? It never fails to amaze me, that when a C vs. C++ argument come up, how many people enter the argument who know next to nothing about C++. A Very Bad Thing, indeed.

quote: Original post by Magmai Hai Kolmar

I''d refute #1, #8, #9, #10, & #11

#1 How so? C & C++ are both loosy typed lang''s... asm is the only one less so. If you want type checking use a functional language (I *HATE* ML)...

#8 Comparing non-emulating C code to OOP designed C++ code (Apples to oranges IMNSHO) C is faster. I believe it takes 4 extra clock ticks per function call to copy that extra dword to the stack for this* It also takes an extra dereference if you use pCls->Something(), which is another 4 extra ticks for the additional mem->reg that is required (or is mem->reg faster now?). So on a Thunderbird 1200MHz machine it will take 6.7ns longer per method call . (The last time I compared the two, 486 33DX''s were new and it would take 242.4ns longer on those - a considerablly bigger difference) *note* this example does not account for RAM wait states... which made the 486 even slower!

#9 Procedurally speaking, are they not exactly the same?
Or are you reffering to op overloading? and other such things that make C++ more readable?

#10 C++ is an OOP language. C is not. (Yes you can emulate OOP design in C, you can also dynamically allocate RAM in COBOL and bit-bang the registers in BASIC. But I don''t want to)

#11 What does "generic" refer to? It doesn''t get much more generic than void* I may be wrong, but I do believe C code is more portable than C++ by shear number of varied platform support... (embedded applications come to mind) Specific to gaming, is there a C++ compiler for the N64, PSX, PS2, Dreamcast, etc? (I don''t know, I''ve never looked; ...Is there a C compiler?)

P.S. If I get bored I''ll look up the exact ticks it takes for a mem->reg & reg->mem transfer... I guessed 4

#1 C++ is not a lousy typed language. If you knew the language, you would know that C++ is founded first and foremost on typing (meaning data types, and not what you do with your fingers).

#8 First, someone already answered this (I''m not sure if it was before or after your post) so to keep my post (relatively) short I won''t go over it again. Procedural code means putting all data into global scope without structs, which I have heard can be slow too (take that hearsay with a grain of salt though -- you might try timing it yourself if you are bored). In that case, use large arrays or large structs, or many small arrays or structs. Give it a real stress test, if you are going to do it ).

Technically, C is not an Object-Oriented Programming (OOP) language. To be an OOP language, it must directly support object inheritance, polymorphism, etc. and C provides nothing like this. C isn''t even an Object-Based language like Ada. Of course OOP can be emulated, but you just waste your time and the resulting code is probably not going to be as efficient as that generated and optimized down to the assembly level by a C++ compiler.


Here''s a bit about why in the world typing is so important:


1. TYPING

Unlike C, C++ provides true user-defined data types. These are called "classes," and new types have new operations that can be performed on them. These new types would hardly be "types" if they didn''t have different operations, would they? Obviously, multiplying matrices is a bit different operation than integer multiplication -- matrix multiplication has different properties, like it isn''t commutative. You (obviously) have to define a multiplication operator for matrices if you wish to multiply them, even if you hide it in a C function or macro like "matrix_multiply()". Types require operator overloading -- that''s what makes them "types."

1.a OPERATOR OVERLOADING

C programmers use operator overloading all the time. But how does C do operator overloading? Yes, even C provides a built-in example of why operator overloading pays off in spades. Yes, ANSI C. Anyone ever hear of pointer math? It''s essential for things like arrays, structs, etc. in C - in fact it''s necessary for any kind of data collection. In pointer math, the addition/subtraction operators behave differently according to the types of the pointers. That''s operator overloading, in case you didn''t notice.

The only difference between C and C++ (regarding operator overloading) is that C++ allows user-defined operator overloading.

1.b INHERITANCE

True typing/operator overloading requires support for inheritance. Types require differentiation, and differentiation implies similarities are present. Similarities require inheritance. For someone who has even the most rudimentary knowledge of C++, this example should make sense:


// the bases of intrinsic types
class integer {};
class floating_point {};
class pointer {};
class character {};

// the types we all know, sorted by 4 base types:

// character
class char : public character {};

// integer
class short : public integer {};
class int : public integer {};
class long : public integer {};

// floating-point
class float : public floating_point {};
class double : public floating_point {};
class long double : public floating_point{};

// pointer to character
class char* : public pointer, private character {};

// pointer to integer
class short* : public pointer, private short {};
class int* : public pointer, private int {};
class long* : public pointer, private long {};

// pointer to floating point
class float* : public pointer, private float {};
class double* : public pointer, private double {};
class long double* : public pointer, private long double {};

// pointer to pointer
class char** : public pointer, private char* {}; // etc.

// no data type
class void {};

// pointer to nothing
class void* : public pointer, private void {};



And that''s how the compiler (and the language standards) refer to all of the intrinsic (built-in) types. That''s how the C standard treats the intrinsic types. Overloaded operators are defined in the standard for each type (but hidden to you). For example, the character-derived classes all feature automatic promotion to any integer type. Pointer math is different from integer math.

The only difference between C and C++ (regarding inheritance) is that C++ allows user-defined inheritance.


2. SCOPE

C++ provides a useful language feature that models how humans think/talk/act/etc. It''s called scope. It''s an essential part of abstraction. In fact, defining scope is abstracting. The human brain abstracts all the time -- if it didn''t, it would take you years to type in a few paragraphs here, because your brain would have to process the molecules in the keyboard (of which there are probably > 1 million), the coloration on your skin, how the monitor works down to the molecular level, why your desk looks the way it does, etc. In fact, you would never stop finding data to process. You have to limit it somehow, and that''s abstraction. Abstraction is the process of finding the relevant data and discarding everything else.

Here''s how scope works:


namespace 2D
{
class point;
class polygon;
};

namespace 3D
{
class point;
class polygon;
}



After all, both 2D and 3D have points, don''t they? And polygons, too. And all of your functions to work with 3D must be different than 2D -- the calculations are all different. So, we give the classes the same names but put them in different namespaces. In other words, we are giving them scope.

But how does it work? When we want to refer to something, we use the scope operator. We can''t just say point, because the compiler will not know which point class we want. So, we must qualify "point" with another level of scope. We have to tell it we want a 2D point, so we type in "2D::point". If we want to use a 3D point, we type in "3D::point".

Inside the 2D namespace, however, the compiler will know which we wish to use. Suppose we define the following function:


namespace 2D
{

void scale(point& p, const int factor)
{
p.x += factor;
p.y += factor;
}

};



Because the code is inside the scope of the 2D namespace, the compiler automatically knows which type we wish to use. You can''t pass a 3D::point into a function requiring a 2D::point, but the person who writes the 2D namespace can work as if his functions were the only ones in the project, giving them such common names as scale, transform, convert, etc. You can do the same thing with function overloading if you wish, but the namespaces are a better solution here, as they provide a whole set of functions/classes which go together. Also, the 3D namespace will likely contain things not found in the 2D namespace, like matrices, for example.

It''s just the process of separating things mentally, so that you don''t have to deal with one huge scope of source and some naming collisions. And we do it all the time. I just did it! Can you see where I have used scope?

(Let me run through that paragraph, and write everything out in its full scope so you can see how unwieldly it would be to read.)

"Scoping things is just the mental process of separating the relevant facts in the problem in the model in the world from the irrelevant facts in the problem in the model in the world, so that you on earth in this universe do not have to deal with one huge scope, which encompasses everything in your code on the earth in this universe, of source code on this earth on your computer in this universe and some naming collisions in that source code on your computer on this earth in this universe. And we, who are on this planet in this universe, do it all the time that we are here on this planet in this universe. I, who am on this planet in this universe, just used scoping. Can you, who live on this planet in this universe, see where I, who live on this planet in this universe, have used scope?"

Whoa. Ever hear of the word implicit?

Obviously, without scope we would have a horrible time in our languages. Besides, C provides scope, too. In C, there is global scope and function scope. In C++, there is global scope, function scope, type scope (which is required by the ability to define new types), and namespace scope (which is essentially the ability to further divide global scope).


3. GENERIC PROGRAMMING

Yes, generic programming is a separate method, like procedural, OOP, etc. Generic programming in C++ uses templates. There are template functions, and template classes. Templates are just a shortcut for function/class overloading. However they save time because they use the one copy of the source to generate many copies. Rather than writing min(int, int), min(float, float), min(void*, void*), we would write one copy like this:


template &lttypename type>
type min(type first, type second)
{
return (first < second) ? first : second;
}



Now, when we use that template function in our code, like this:


void main()
{
int x=1, y=5;
int iresult = min(x, y);

float z=2.7f, m=1.85f;
float fresult = min(z, m);
}



The compiler looks at the template function min and generates two copies, just like this:


int min(int first, int second)
{
return (first < second) ? first : second;
}

float min(float first, float second)
{
return (first < second) ? first : second;
}



The compiler only generates the copies that we wish to use. In our example, since we didn''t use min(char, char), it wouldn''t be generated. Only the int and float versions were used, so only they were generated. What''s so great about this is that these functions are a better way to do C macros. And they have the possibility to be faster than C macros if we make them inline. Why? I could probably write a couple of paragraphs explaining it, but I don''t see anyone interested in hearing the truth here. If someone asks, I''ll post it. Plus, template functions are actual functions, which have their own scope and can have static/const variables etc. Template functions are like #define''d functions on steroids.

But the best part about templates is template classes. Imagine being able to write one linked-list class, and have the compiler generate linked-list classes for all of the types that you use, and only the types that you use. And the class will be just as fast as if you hard-coded the type. No slow-down, no void* casting, and it''s type-safe. Now imagine having a huge, pre-written library with tons of classes like arrays, strings, files, lists, maps, etc. standard with C++. Yes, it does exist, it is extremely fast, and it''s called STL. And compiling with STL won''t add any code to your project unless you use the classes. Do all of that in C, please.


And those were just a few reasons...


I make this statement to everyone here:

Only an ignorant programmer would claim that C is a better language than C++.




- null_pointer
Sabre Multimedia

No rebuttal?



- null_pointer
Sabre Multimedia

Rebuttal:

IMO it depends on the compiler. I don''t completely agree with Sean, either, but I do think he makes a few valid points. Still, C is widely used and far from being abandoned. DirectX and Windows were both mostly written in C.

/me slaps null_pointer a five to show that there are no hard feelings here.

I have already posted about C vs. C++.

However:

quote: DirectX and Windows were both mostly written in C.

Are you absolutely sure DirectX was done "mostly in C"?


YAP YFIO,
deadlinegrunt

Yes, I''m sure. That''s what Microsoft''s developers say in "Inside DirectX". That''s also the reason the book''s code is in C, not C++.