• Content count

  • Joined

  • Last visited

Community Reputation

122 Neutral

About HellRaider

  • Rank
  1. dynamic_cast speed concerns

    Quote:Original post by Sc4Freak For example, submitting a draw call to the renderer means that an IMaterial pointer is passed into the renderer from the outside world. Whenever that IMaterial wants to be used, the renderer needs to downcast it to an IMaterial_Impl before it can be used. Why do you have to downcast an IMaterial to an IMaterial_Impl to use it? That doesn't make any sense. Other classes should not be aware of the existence of IMaterial_Impl. In fact, IMaterial_Impl could be directly defined within a .cpp file, so other modules would not be able to 'include' it. Quote:Original post by Sc4Freak 1) Am I completely abusing C++, and entirely missing the point of OO? 2) Should I be worried about performance here? 3) Is this design too obfuscated, too complex, or overengineered? Should I change my design? 1) Probably. 2) Not as much as the design. Focus on a clear and *simple* design. 3) Yes, I guess. As a rule of thumb, avoid diamond inheritance. Not so much because it is slow, but mainly because it's generally a symptom of complex designs. The problem seems to be that you're trying to inherit from IObject_Impl from all other Impls. That doesn't make much sense. If all implementations will inherit from IObject_Impl, kill that abstraction and put all code directly in IObject (in which case you should rename it to 'Object'). Wherever possible, use aggregation instead of inheritance and you will avoid diamond inheritance.
  2. What qualifies someone to teach computer science?

    Quote:Original post by capn_midnight Quote:Original post by HellRaider Unless the person is really a senior researcher who can totally rely on his students, he will eventually miss the ability to implement algorithms. Implementation is a poor substitute for mathematical proof, as the systems on which the algorithms are implemented are imperfect. With a proper proof, programming an implementation is a waste of time. Yes, it's a fact that theoretical computer science has nothing to do with implementations, and I was not suggesting that they could substitute mathematical proof. But how many researchers have restrained themselves to purely theoretical matters throughout their lifetime, and never wanted to implement something? Yes, they may learn how to program relatively fast whenever they want, but to me the fact that someone has no familiarity of how to instruct a computer to actually run an algorithm is evidence of a flaw in his scholarship. I may be biased since computer graphics is a very practical research area, but from my observation, the best professors I had knew at least a little bit of programming, and most of the worst professors I had knew nothing of it. Although possible, I don't think this is a coincidence :)
  3. What qualifies someone to teach computer science?

    Quote:Original post by Daerax It surprises me that people think Theoretical Computer Scientists should be able to program. Theoretical Computer Science is Applied Logic or Applied Pure Mathematics depending on who you speak to. Well, "applied pure mathematics" sounds a bit paradoxical to me, but I think I got what you meant. Sure, theoretical computer scientists are not required to be expert programmers. But in my opinion they should know enough about programming to at least teach a freshman's course and play a little bit. Unless the person is really a senior researcher who can totally rely on his students, he will eventually miss the ability to implement algorithms.
  4. What qualifies someone to teach computer science?

    At my first year as an undergrad I had the same feeling. I don't know if this is the same case as yours, by in my university they assigned unqualified professors to teach some basic courses. In my case they were not PhD's though. I was frustrated because I already had some experience when I entered the university. But as I progressed, the quality of professors got increasingly better. Those assigned to mid-to-end-level courses were actually postgrad professors. Now I'm about to obtain an MSc in computer science (phew time goes fast). In my experience, there are very good professors out there who can't program, but are really good researchers/advisors (those are generally older people). There are also those who are good researchers AND programmers (they're generally younger). And well, there are those who were never interested in programming. Might be the case of your teacher, since she's young and would probably not have forgotten how to program if she had ever learned it properly. Tip: google for your teacher's thesis, and you might discover her area of expertise (and whether she is adept at technical or purely theoretical stuff).
  5. Indeed the algorithm is called Convex Hull... Check out http://en.wikipedia.org/wiki/Convex_hull There are many references to other sites and implementations...
  6. [java] Java is my friend

    Quote:Original post by johnhattan I like Java. I'd never uninstall. Its programs won't destroy my computer, Because they barely run at all. ROFL
  7. Optimizing this algorithm

    Quote:Original post by MOVSW My coworker is sort of an asshat, i bet this algorithm is probably not even optimizable to O(n). How can you bet that if someone has ALREADY explained how to do it in O(n) in this very thread?
  8. Many scripting languages support coroutines (Python, Lua, Ruby, etc), and yes, they simplify many things. Quote:Also this seems like it is generalizable to other languages; it would be beautiful in C# 2.0 since it supports anonymous functions. Doesn't C# already support coroutines? I believe there are coroutines for C# and Java, at least as extensions. From Google: http://msdn.microsoft.com/msdnmag/issues/03/09/CoroutinesinNET/
  9. ogl or dx for 2d top down game

    If you want to use C and keep your code reasonably clean, or have a portable game, use OpenGL. On Windows it'll probably be slower than DirectX, but if your game doesn't have tight performance requisites it should be fine.