Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Oct 2000
Offline Last Active Jul 26 2016 05:06 PM

#4836784 why is C++ not commonly used in low level code?

Posted by on 18 July 2011 - 07:07 AM

There is nothing wrong with OO done correctly, the 'problem' is the lack of design skills, critial thinking and correctly applying paradigms to solve a problem.

The problem is most people don't have those skills but then again chances are they would write bad code in any paradigm if left to their own devices...

Oh, I agree. I've just always found it funny that many c programmer's arguments against c++ revolve around inheritance, when the guy who designed the STL has pretty much the same opinion! Posted Image I'd very much enjoy watching Stepanov and Torvalds direct their arguments at one another in some kind of forum trollocalypse.

In the linked rant (in between attempts at trolling) Torvalds says similar to what you say about lack of skills. Stepanov, for all his hatred of OO, presumeably likes that in c++ you can have a function object whose operator() can be inlined, unlike a c function ptr. So he doesn't mind objects, just OO...... Posted Image

Personally, I think the problem is that 'OO done correctly' means different things in different languages and different problem spaces, which has lead to people having the skills and wanting to apply them, but applying them wrongly for c++ in performance-critical situations. There's a wealth of OO design wisdom out there, and while most of it can be applied to c++ design, not all of it should have been. For example, classical OO literature revolves around using inheritance for polymorphism, which is not always the best way to go in c++ where we have lovely compile-time polymorphism.

(insert obligatory comment about OO being possible in c and the OO argument therefore being irrelevant to this thread anyway - if I didn't someone else would!)

#4834883 CUDA hello world MSVC

Posted by on 13 July 2011 - 10:12 AM

Try installing Parallel NSight, for a possible quick fix.

IIRC the msbuild targets for 64 bit on msvc 2010 are broken/missing in the cuda sdk, but a working version comes with NSight.

#4824434 Recycling variables and performance

Posted by on 17 June 2011 - 05:56 AM

Are you being serious here? You are implying that one should write a function object to represent the internals of what in the past would have been a for loop? We should just have hundreds of function objects all over our code? If you're seriously implying this then I'd hate to see your code.

Yes, we absolutely should. It may be a lambda, but it should certainly be a function object.

Why? Because this allows you to use std algorithms (as well as algorithms from boost, TBB, PPL, and your own template algorithms). This is worthwhile purely for clarity - the function name tells you the number of iterations on the first line of the loop. For/while etc do not do this - you have to examine the body of the loop.


for(size_t i=0; i<10; ++i)
	//can break
	//can increment or decrement i
	//can continue
    //can return

//so the above may do 10 iterations, or it may do more, or less, and may not execute the entire body every time

std::for_each(begin, end, [&]( const valT& val)
	//do stuff

//whereas here we know for a fact we are doing distance( begin, end ) iterations.
//And we know this from reading only the first line.

#3033414 Chunked LoD: Getting height / collision.

Posted by on 02 May 2005 - 05:27 AM

chunked LOD really isn't designed with collision in mind.... Ulrich says it's one of the few downsides to the algorithm.

In general you can use the plane equation on any triangle in a regular heightmap to interpolate heights. Obviosuly you can't do this with chunked lod as you haven't got a regular grid.

So you're down to using AABB tests for chunks and then triangle intersection test on each triangle in the chunk.

It may be faster just to keep the heightmap (or page it with your texture data) and use the normal heightmap method.