Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

null_pointer

Unnecessary C++ features?

This topic is 6518 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I started this thread so that if anyone can think of an unnecessary feature in C++, something they do not understand how to use very well, or anything different between C and C++ that you could post here and someone might reply and explain it. Perhaps there are unnecessary features in C++. Perhaps C++ is worse than C. We''ll find out if we keep an open mind, right? I''ll try to answer what I can, but keep in mind I don''t know everything! There are other people here who know quite a bit more about C++ and the assembly it typically generates - I hope they''ll reply to this post. (I hope to avoid the tension of C vs. C++ posts, and make this post a bit more educational. Rather than saying "C is worse than C++" it would be good to see whether C++ really measures up as a language by itself. ) DISCLAIMER: I AM NOT GOD. DO NOT EXPECT ME TO BE PERFECT. Oh, before I forget! I''m looking for things like: C++ keywords (like if, else, etc.) STL classes/functions (like auto_ptr, list, etc.) Features that are not keywords (like operator overloading) C++ syntax (like "x += 7") I don''t want discussion about OOP vs. structural - it''s just too vague. Or programming methodology wars. Just the C++ language. You could ask about the class and virtual keywords if you want, though. Happy Coding!
- null_pointer Sabre Multimedia

Share this post


Link to post
Share on other sites
Advertisement
[ nice topic, null_pointer. I mean that in a very serious way ]

I''ll be the first to post a question here, to know other people''s opinions.

This is about C++ exceptions, and the overhead they generate.

I know how to use try, catch and throw myself, but I never really have. I think it is because it''s such a large unknown as far as performance is concerned, and I''m usually writing high-performance stuff to be shared among many people.
I''d love to use C++ exception handling, but can anyone tell me what I''ll be paying for it in terms of performance/object file size?

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.

Share this post


Link to post
Share on other sites
Hi.

Well, IMO, the assignment shortcuts, declaring variables in the middle of a statement, and the -- and ++ operators (except may be in the FOR statement), are unnecessary.

The "variable += variable1" confuses me, and I rather increase/decrease variables in a separate statement.

May be I am just old fashioned, i don''t know.

Topgoro

Share this post


Link to post
Share on other sites
The name says it all .
Anyways, var1 += var2 is actually, performance wise, better then var1 = var1 + var2, because in the first, you do 1 addition, 1 ''get'' and one ''set'', whereas in the second, you do 1 addition, 2 ''get'' and one ''set''. Ok tiny performace, but if you do it 1000 times that adds up... right....
Anyway operator overloading is great. What would YOU rather do:
Matrix M,M2;
M = M.Multiply(M2);

Matrix M,M2;
M = M * M2;

Performance wise, lets see:
M * M2 is actually M.operator*(M2) which is performance wise the same as M.Multiply(M2). So no loss of speed, increase of readability, ease of use, etc... Which saves in the long run, a lot of coding time think - *M2 is 11 characters less then M.Multiply(M2). Times that by a few thousands times, even if you are a fast typer... adds up. Operator overloading is merely renaming functions to different names, and getting the compiler to call them, instead of you. This is more noticeable when you see the declaration for a operator overloaded operator:
class XYZ {
public:
XYZ& operator*(XYZ& Other); //is the same as:
XYZ& Multiply(XYZ& Other);
};


STL classes.
Ok, perhaps not so necessary. Lets see: the play of life.
1) programmer writes list class.
2) programmer feels great.
3) programmer reads about STL.
4) programmer thinks: is it better to use stl then my list class?
5) programmer either uses STL, kicks himself for wasting time, and gets on with it.
5) programmer convinces himself that he should reinvent the wheel, writes a set of containers taking about 2 or 3 weeks, another 2 debugging, etc etc.

Obiviously you can see my slant here...
I use the STL all the time (map class being the best). I really really hope that some day, they make the STL more ,well, NOTICEABLE then it is now. Then it would save a lot of time. Think: how many list classes do you think everyone has made??? a few thousand at least. times that by an average of 3 weeks makes 3000 weeks - WAIT! NO OOP vs STRUCTURAL. Oh well. Still, hope you can see where i''m going..

C++ keywords.
Well, now. C has them too. So they can''t be unnecessary. (NO if''s else''s are you CRAZY!) where are you going to branch code? No user input! IMHO!

The & syntax whatever.
This is important, to you Performance buffs. Very necessary. Take function x:
void x(ABigClass y) {}
Function x must copy y every time it is run. You can''t change y, either (well you can, but the changes will be lost). So to get around this:
void x(ABigClass* y) {}
Which is at the assembly level nearly the same as:
void x(ABigClass& y) {}
but without all those ->. Usual compiler implementations define & as simply a pointer to a point in the memory, with the stack on the calling sides of the function setting up the pointer to point to the argument, and the function side setting up a temporary argument that uses the pointer. Saves all that copying around. I use it mainly for operators, saving copying every time I do:
M = M*View.
or whatever.

Oh yeah, C++ can''t possibly be worse then C. Argument: C++ is built on C. So if C++ is worse, that means C is worser, which means nothing changed. If you don''t like C++ stuff, don''t use them. C++ doesn''t force you to use C++. Obiviously.

Whew! Who would of thought I would of written this much!

Share this post


Link to post
Share on other sites
quote:
Original post by c++freak

Oh yeah, C++ can''t possibly be worse then C. Argument: C++ is built on C.



Null_pointer specifically asked to stay AWAY from comparing C to C++, we''ve both been there before, and there is no point starting it up again.

( I can refute the claim anyway, by saying that excess baggage is not necessarily a good thing, and more features can in fact be worse instead of better. )



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.

Share this post


Link to post
Share on other sites
Oh yeah, about exceptions:
Basically they incur no performance (I could be wrong though) overhead _UNTIL_ the exception is (ever) thrown. Of course there is some code size overhead, but that isn''t that much compared to a usual game''s size (1 MB or so for a simple 3d walkaround). Once the exception(s) are thrown,at that point, the stack is unwound (functions are ''un''called) until a ''catch'' is found. If so, the handling code is called (usually: ''ERROR: Exception xyz has been thrown. Somethings wrong. Bye!'') and then, the stack is rewound to the point where the exception was thrown. Oh yeah, when the stack is getting wound up and unwound, all that happens is that the stack order is messed around with, and the code execution pointer is messed with too, no actual performance hit. Mainly, when you use exceptions, is for things like no file exists, DX isn''t working, GL doesn''t have all the libaries, etc. that will terminate the game/app, so that any performance hit - at that point - will not matter. To reiterate - there is no performance hit until a exception is called.
On using exceptions:
create a exception class, or USE the STL ones. All that it must do is contain a string stating the message/error. For even better exceptions, make a DXError or whatever class derived from that, that turns a HRESULT to a string.Now, when the mode is not supported by the device:
instead of:

if FAILED(xyz)
return hr;
....

if FAILED(LoadDX()) {
MessageBox("Error","Error",other parameters here);
return;
}

do:

void CheckHR(HRESULT New) {
if(FAILED(New)) throw(DXError(New)); //will turn HRESULT to string
}
...
hr = SetDisplayMode(x,y,z);
CheckHR(New);
...
LoadDX(); //NO ERROR CHECKING!!

and in the winmain:
int winmain(....) {
try {//first thing. VERY important.
... //all code here. windows stuff, dx/gl stuff, game loop etc.
}//last thing.
catch(Exception& AException) {
MessageBox(NULL,"Error",AException.String,MB_OK);
return 1;
}

So now, there is no error checking, and one big try/catch statement to catch all errors. You might want it so that you could have Error levels (Fatal,Big,OutDebug) so that some errors terminate the app, some show it via messagebox, some outputdebugstring the message.

Share this post


Link to post
Share on other sites
I don''t like STL since there is no place to go to see what is out there, so it really isn''t needed. Show me a book that lists and describes STL. Ditch STL.

Share this post


Link to post
Share on other sites
I kinda like the var+=var2 and var++ type of thing....

it''s a lot quicker to type at least

"The road of excess leads to the palace of wisdom." --William Blake

Share this post


Link to post
Share on other sites
(Whirlwind)
Show me a book that lists and describes STL

Haven''t you heard of compiler documentation? What compiler are you using? (VC++ I would guess, Borland always has documentation ). There should be documentation for the STL with your compiler. There was documentation for the SGI implementation of the STL out on the web, I forgot where though... Would you rather spend 2 or 3 hours learning the stl then a few weeks implementing a copycat container system? Up to you..

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!