I go with Marsupial Rodentia... Maybe not in all cases, but there are many cases when the C++ program will execute faster than a program written in C... It also depends on who''s writing the program!!

..-=ViKtOr=-..

How long is the poll that is shoved up null_pointers ass? I mean, I don''t blame him for ranting, but his post is way too long.

quote: Original post by Falagard

"Writing programs based on the concept of an "object" which is a data structure encapsulated with a set of routines, called "methods" which operate on the data. Operations on the data can only be performed via these methods, which are common to all objects which are instances of a particular "class". Thus the interface to objects is well defined, and allows the code implementing the methods to be changed so long as the interface remains the same."

Ah. Well, I''m more loose than that; I don''t "encapsulate" (hmmm, that sounds like an awfully big word for something so simple) every little thing. For instance, in my game project, v_width and v_height (the dimensions of the screen) are declared externally in the graphics module''s header; I didn''t see any reason to make v_get_width() and v_get_height() access functions (don''t kick me). The handle of the main window is also global (get_main_window_handle()?! Aaaaaargh!).

I always encapsulate things like arrays and linked lists, though--things whose implementations are likely to change, and things that would be a pain to work with directly (lists, queues, and so forth). Thus, the surfaces and palettes and clippers (ugly, system-dependent stuff) are encapsulated.

Speaking of declarations, I''ll mention again (I said this in another thread) that I don''t like having millions of private definitions in a header file. It looks idiotic. Why should someone have to look at that? If another member of the team needs to work with your module, they only need to look in the header file and see the *interface*, not the implementation. If your header file is three thousand lines long, it could be a bit intimidating.

Another thing I don''t like is all this automatic passing of the `this'' pointer. It makes code smaller, but it makes it more confusing for me.

Oh, and I think it''s annoying that C++ complains whenever I don''t cast a void pointer (a little thing, but a thing nevertheless).

So...I know those points didn''t prove anything, but that wasn''t the intent. I''m just trying to explain why I think C looks cleaner than C++; it''s not just a matter of "ignorance" and "inexperience" and "bad attitudes" (boy, do I hear those phrases a billion times a day). I do avoid hype on principle, though. :-)

heh heh no one likes my post but they didn''t refute any of my points


Anyway, David M., I didn''t mean to come down like a hornet on you I just wanted to keep everyone from spreading things about C++ that really aren''t true (but are widely believed) to discourage new users. There''s such a thing as negative hype, too.

IMHO (and no one likes my opinion here hehe), C++ creates cleaner code than C. Yes, you have to handle void* casts, but that''s only for legacy code. I can''t recall the last time I actually used a void* -- oh yes I just remembered: I had to look up an old Windows API C-style error message. (I just copied the example code, which was written about the time Windows 3.1''s SDK came out.) void pointers are really just a poor precursor to generic programming with templates.

Also, the private: section of a class declaration is necessary for the compiler, right? I mean, you can''t derive a class properly if you don''t know it''s size, and you can''t know derived class''s size without the private: section declarations in the base class. And because it''s labeled private it''s can just as easily be ignored by any reader. I''ve seen bad C source and bad C++ source, so blaming C++ because some C++ programmers don''t organize properly is...well, bashing. And I don''t think the private: thing is just in C++ -- I''ve seen my share of C structs with LPVOID lpReserved in them.

Um...I don''t like typing in accessors either (must mean I''m lazy, huh? 10 seconds of typing... ). If you are just doing the get/set functions with no error-checking, you might as well make the data members public. I''m all for using only the code that is necessary -- I regularly go through my source comments and organize my code so that is holds no unnecessary information (and doesn''t skip any necessary information).

However, from everything you have said, you are really just emulating things that can be done with C++ keywords. Instead of using function pointers, use virtual functions. Instead of void, use templates. Instead of C-style structs and global functions, use classes. Instead of return values for error codes, use exceptions. Instead of #define''s, use const variables and inline functions. If you take the time to learn that stuff, it will pay you back in spades.

C++''s chief benefit over C is that of design.




- null_pointer
Sabre Multimedia

quote: Original post by null_pointer

heh heh no one likes my post but they didn''t refute any of my points
(and no one likes my opinion here hehe)

*grin* That''s not true! I didn''t refute them ''cause I bloody well agree!
I''m not about to reinvent the wheel, and I like using C++ in all it''s glory and weirdness.




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.

quote: Original post by David M.

Another thing I don''t like is all this automatic passing of the `this'' pointer. It makes code smaller, but it makes it more confusing for me.

Well, to begin with, using subroutines without an explicit ''call'' or ''gosub'' keyword confused me As did C''s for loops compared to the nicer looking BASIC ones. Things that are confusing to start with end up looking nice once you get used to them.

quote:
Oh, and I think it''s annoying that C++ complains whenever I don''t cast a void pointer (a little thing, but a thing nevertheless).

Well, 99% of the time you don''t need void pointers in C++. If you want to pass in multiple types of objects, you''d either derive them from a common base object, or overload the receiving function, or use a templatised version of the receiving function. I''ve not needed any void pointers at all except where DirectX requires them. Implicit casting is generally considered a bad thing. As what is obvious now might not be obvious when you come to review your code 6 months later.

Funny how your first point above argues for explicitness, and your second point argues against it This just goes to show that it is all really a matter of style, and adapting to whatever tool you use.

quote: Original post by Kylotan

I''ve not needed any void pointers at all except where DirectX requires them.

Remember that window handles are void pointers...and bitmap handles, and icon handles, and cursor handles...all that stuff. How do you handle that sort of technique in C++? (I''m not saying you can''t, I''m just wanting to know.)

quote: Original post by null_pointer

Also, the private: section of a class declaration is necessary for the compiler, right? I mean, you can''t derive a class properly if you don''t know it''s size, and you can''t know derived class''s size without the private: section declarations in the base class.

That''s why I use C. :-)

quote: And I don''t think the private: thing is just in C++ -- I''ve seen my share of C structs with LPVOID lpReserved in them.

That''s definitely bad style, but I don''t do it.

quote: However, from everything you have said, you are really just emulating things that can be done with C++ keywords. Instead of using function pointers, use virtual functions. Instead of void, use templates. Instead of C-style structs and global functions, use classes. Instead of return values for error codes, use exceptions. Instead of #define''s, use const variables and inline functions. If you take the time to learn that stuff, it will pay you back in spades.

Well, all that stuff sounds very, ummm, nice, but I prefer to be closer to the machine than that. C++ just has so much pompous abstraction with pompous buzzwords tacked onto it, it makes it look dumb--sort of like C with a bunch of little pink ribbons hung on it. I prefer to have my language just one level above assembly language.

And, as I''ve said before, I just think C looks cleaner; no one can really disprove that, because it''s just an opinion, a matter of taste.

quote: Original post by David M.

Remember that window handles are void pointers...and bitmap handles, and icon handles, and cursor handles...all that stuff. How do you handle that sort of technique in C++? (I'm not saying you can't, I'm just wanting to know.)

To my knowledge, Windows handles are typed pointers to structs like this:


struct HWND__ {
int nUnused;
} HWND*;

// etc.



If you try to do something unusual like implicitly casting an int to a HWND, VC will tell you to explicitly cast it to a HWND__*, which shows the type.

Actually, the Windows GUI was modeled after polymorphism. You have one base window class that provides common services in the form of virtual functions, and then derive all the gui control classes from the window class. Then you can override whatever you like. The window handle/window proc thing in Windows just provides an implementation of it that is compatible with many different languages, but the basic concept is the same.


class window
{
public:
virtual void draw() { /* just update children */ };
virtual void on_click(int x, int y) { /* do nothing */ }

protected:
window* parent;
list children;
};

class button
: public window
{
public:
virtual void draw() { /* draw button-like rectangle */ };
virtual void on_click(int x, int y) { /* re-draw differently and do something */ }
};



Whenever you wish to draw something, the function pointers do the work of handling things according to the type. For example, if we do this:


window* new_window = new button;
new_window->draw();



Then of course button::draw() is called and not window::draw(). So you can have the following drawing code in the window class and not have to change a bit of it when you add new control types:


void window::draw()
{
for(int x=0; x < children.size(); i++ )
{
children[x].draw();// draw the children in order
}
}



Then in any derived class (like button), you do this:


button::draw()
{
// do our own drawing code...

// call base class to do default, which is to draw all children
window::draw();
}



There's an article series here at gamedev about implementing a GUI in C++ that explains it a bit better than I can.

(BTW, the list class is STL and is really just a linked-list wrapper.)

quote: Original post by David M.

Well, all that stuff sounds very, ummm, nice, but I prefer to be closer to the machine than that. C++ just has so much pompous abstraction with pompous buzzwords tacked onto it, it makes it look dumb--sort of like C with a bunch of little pink ribbons hung on it. I prefer to have my language just one level above assembly language.

Actually, the inline and const keywords are much closer to the actual compiled machine code than C defines. I take it you are talking about classes then? Virtual functions aren't used all of the time -- only when they are useful. Just like templates and what-not. Besides, it's not pompous abstraction when you know what the keywords mean.

Example:


template &lttypename integer_type>)
inline minimum(integer_type first, integer_type second)
{
return (first < second) ? first : second;
}

void main()
{
int x = 1, y = 3;
minimum(x, y);

short z = 2,000, m = 430;
minimum(z, m);
}


That code tells me a number of things which make it very clear what is compiled, how much memory it uses, its relative speed, etc.

1) the inline keyword is used and the function is one line, so the function's code will be placed directly into the source whenever it is called.

2) the template keyword is used and the function has been called with 2 different types, so 2 copies of minimum() are generated: minimum(int, int) and minimum(short, short).

3) looking at conclusions #1 and #2, I can see that the actual code interpreted turns into this:


void main();
{
int x = 1, y = 3;
(x < y) ? x : y;

short z = 2,000, m = 430;
(z < m) ? z : m;
}



Which is then optimized down to this in the release build:


void main()
{
}



Because it does nothing. First, the comparison/branching watchamacallits are taken out because the return value is not used. Second, x, y, z, and m are not accessed anymore, and since they are of the built-in types their operators in this context allow them to be easily optimized out.

So all those big words don't slow the code down a bit if you know what you are doing. And once you know what they mean, the are merely adding more description to the source, which hardly seems like abstraction to me. Less description is usually more vague.



- null_pointer
Sabre Multimedia


Edited by - null_pointer on June 28, 2000 6:23:57 PM

C++''s higher level attributes are slower than C, but if you rename a .c to .cpp it will run the same. A struct will be the same speed in C++ but a class in C++ cannot compare to the speed of a struct using some modifier functions.

Only thing I really dont like is the bloat, which is probably minimal by now but... C programs are smaller than C++ programs if you use C++''s features. Anyway, my code is some freaky sort of OOP C styul!

It doesn''t really what you use, unless of course you use COBOL.

-----------------------------

A wise man once said "A person with half a clue is more dangerous than a person with or without one."

Egads! they're coming out of the woodwork!!

quote: Original post by ImmaGNUman

C++'s higher level attributes are slower than C, but if you rename a .c to .cpp it will run the same. A struct will be the same speed in C++ but a class in C++ cannot compare to the speed of a struct using some modifier functions.

Only thing I really dont like is the bloat, which is probably minimal by now but... C programs are smaller than C++ programs if you use C++'s features. Anyway, my code is some freaky sort of OOP C styul!

Wrong. As I said before, these two declarations are EXACTLY equal:


struct point
{
int x;
int y;
};

class point
{
public:
int x;
int y;
};



C++'s "higher level attributes" (keywords, I suspect?) are not slower and do not produce larger code unless you don't know what you are doing. Saying no one should use C++ features because they cause code bloat in the hands of an inexperienced person is like saying no one should use power saws since inexperienced people could hurt themselves.

quote: Original post by ImmaGNUman

A wise man once said "A person with half a clue is more dangerous than a person with or without one."

You took the words right out of my mouth...




- null_pointer
Sabre Multimedia


Edited by - null_pointer on June 28, 2000 6:37:29 PM