User forums > General (but related to Code::Blocks)
Compile error
thomas:
Right, like I said, sometimes it does not matter, and sometimes it does. Although I disagree on Ogre ;)
Ogre is a good example where I think exceptions are actually out of place. It certainly works. And it works excellent, too. But the main purpose of Ogre is to create games. Today, the GPU usually has plenty of cycles left while on the other hand, the game is utterly CPU-bound. You have to try very hard to be GPU-bound (unless you write very very expensive shaders).
Thus, it seems to me that losing a couple of percent of CPU time to exception handling may not precisely be what you want to do.
Of course, things like scripting easily eat up 10-20 times as much CPU as EH, but you usually cannot do without scripting.
The problem with EH is that even if you only use exceptions where appropriate, you can only compile with or without exception handling, and unless you use compiler-specific attributes (such as nothrow), the compiler has a very hard time knowing where to add stack unwinding code and where not to (most will simply insert code everywhere).
Michael:
--- Quote from: killerbot on February 07, 2006, 11:13:51 am ---There exist a no_throw new. I think it is not portable, the gurus (Sutter, ..) give the advice not to use it. So just forget you ever heard about it ;-)
--- End quote ---
I have had a look at the C++ Standard book and I have found that the two possibilities for the operator new are described and there are no constraints in using the throw-new instead of the nothrow-new. There is written something as: "If the program wishes...". Personally, I have never used the nothrow-new, but I prefer it, even if I have to specify nothrow, e.g.:
--- Code: ---int* ndata = new(nothrow) int;
//do something with ndata
delete ndata;
--- End code ---
I have also not found portability issues by searching with Google. May be this is due on how C++ standard compliant are the different compilers.
Michael
jmccay:
--- Quote from: polygon7 on February 05, 2006, 11:01:47 pm ---
--- Quote from: sethjackson on February 05, 2006, 10:55:55 pm ---@polygon7
Why the
--- Code: (cpp) ---<< 2
--- End code ---
instead of
--- Code: (cpp) --- * 4
--- End code ---
?
This line
--- Code: (cpp) ---unsigned long imageSize = (image.GetWidth() * image.GetHeight()) << 2;
--- End code ---
--- End quote ---
"<<" is shifting bits operator (shift left, SHL in assembly). SHL can be used for multiply by power of two (SHR, shift right for dividing by power of two).
x*2 == x <<1, x*4 == x <<2 ...
Bit shifting usually is faster then normal multiply.
--- End quote ---
I would like to add (because not everybody might know it) that there is one advantage to using the bit shifting operators over a normal multiplication/division. On some systems (since I don't know all systems and my assembly language is rusty I will use "some"), the operator translates to an assembly/machine language command that is faster than multiplication & division. It was/is a technique used by game developers for faster mathematics when manipulating images. They would make the images multiples of 2 to be able to use it.
jmccay
Ceniza:
Well, if you take a look at the compiler's output, even without optimizations (GCC), using * 4 or << 2 generate the same code, but * 4 is still more readable.
For this code:
--- Code: (cpp) ---b = a * 4;
--- End code ---
The compiler outputs:
--- Code: (asm) ---movl -4(%ebp), %eax
sall $2, %eax
movl %eax, -8(%ebp)
--- End code ---
There're many things compilers can handle by themselves, including such simple optimizations, and a few more advanced ones that can only be achieved in ASM.
Specifying optimizations (like -O3) will give you better results, like converting:
--- Code: (cpp) ---b = a * 5;
--- End code ---
into:
--- Code: (asm) ---movl -4(%ebp), %edx
leal (%edx,%edx,4), %eax
movl %eax, 4(%esp)
--- End code ---
As you can see those early optimizations just make your code less readable for the same output and performance.
Navigation
[0] Message Index
[*] Previous page
Go to full version