Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 May 2007
Offline Last Active Mar 08 2013 03:06 AM

Posts I've Made

In Topic: What language should I write my indie game in?

19 December 2012 - 04:39 PM

Do you want to make a game or learn how to program? Do you know any languages yet? If you don't even know what language/technology you want to leverage, you might want to use something that less programming-oriented. In any case, it would let you do some prototyping so you can figure out if your idea is fun or not.

In Topic: Once you go OO, you never go back?

19 December 2012 - 12:29 PM

After being a C++ programmer for a little while and dabbling with Java, I have to say that in my opinion object-oriented programming is relatively worthless to me. I honestly don't see why I should ever bother worrying about whether or not a particular set of functions can "see" each other, or whether or not I can make two functions with the same name. Why would I ever want more code obfuscation like that -- two functions with identical names that can do two completely different operations? Why on earth would I ever want such a thing?

But this is of course only my opinion. I'm not unique in the way I think, surely, but I'm also probably not at all a rare, dying species of programmer.

Most of the projects I've worked on professionally did NOT do much in the way of data hiding. 99% of the member variables in a class were public. It was annoying at times.. every time you reached in to set a value you had to be careful that you wouldn't cause side effects, but ultimately those projects shipped. Unrealscript is an example of an everything-is-public OO implementation.

Data hiding is a good idea. But can you ship without doing it? Yes, definitely. It raises the requirement of others not screwing up when working with your code though. In the case of unrealscript, they made the explicit choice to not hide data for performance reasons of calling a getter/setter (in C++ it's essentially no extra cost due to inlining, but in script.. there was definitely cost.) But that decision was not without other consequence in the form of maintenance hassle.

In Topic: Once you go OO, you never go back?

19 December 2012 - 09:23 AM

I have no statistics so I'll make unsubstantiated sweeping generalizations instead Posted Image

Most places outside of games DEFINITELY do OOP, whether or not they understand why they are using it and its advantages and disadvantages. Most game studios/engines I'm aware of also do OOP. I've seen a very small shift away from OOP in favor of thinking in terms of data transformations.

In my opinion OOP is very often a good choice. But unfortunately it seems like this is the way *everyone* learns how to program and don't understand the pros/cons of that style. "This is the way thou shalt make software."

You benefit from OOP by easy data hiding/encapsulation, and if we mean OOP as in common language features, ability to use polymorphic functions and type safety/inheritance. It's also a well-understood style by the person coming behind you.

A bad side of OOP is that few people succeed in only having a single concern per each object type and so what often happens is you get large classes that throw a bunch of unrelated functionality together with its data, and it makes it very difficult to extract a single aspect of the class out for reuse. You end up creating generalized objects that are more complex than necessary to solve a problem. OOP is also a trap for people to make code that attempts to model the real world (i.e. your objects are "chair" or "car" when maybe the better solution would be SitableComponent or DrivableComponent that's attached to something more general). It's difficult to have the discipline to break down a seemingly simple object into the various concerns it has, but failing to do so makes bad OOP designs.

One alternative might be a data transformations style, where you have lots of homogeneous data and you simply rip through it all using loose functions. Even with such a style, you can think in terms of OOP and limit how/when/where you access data in those lists. And yet you can keep data and logic separated. In other words, you can get the advantages of OOP without using the class keyword.

I think OOP is so prevalent because it's almost always a decent solution and it's very intuitive. So for big companies that just want to grow a workforce of moderately skilled people who can make standard business software without needing to have the depth of understanding to choose what style to use, OOP is a good choice.

I think the most important thing is realize that you can get the benefits of OOP without using the class keyword, while skirting the negative aspects of it by either being careful to keep your objects single-minded or thinking in a more raw form of data transformations in sequence. Consider many solutions/styles and *think* about the tradeoffs you make with your choice.

In Topic: std::Queue and multithreading

05 December 2012 - 11:02 AM

The easy solution is to use a lock or someone else's thread safe queue as has already been suggested. If you're just trying to solve a problem, this is definitely the way to go.

If you're interested in really digging into concurrent programming for the purpose of learning, you may want to investigate writing your own lockless queue where exactly one thread can write and exactly one thread can read. It doesn't require a ton of code to do something simple and it's well worth the learning experience. The need to pass data continuously from thread A to thread B in this way is extremely common. An easy implementation is to have a "read pointer" and a "write pointer" that wraps in a circular buffer - just be careful of order of operations and make the read pointer and write pointer volatile. The "pointer" can be an index into the static-sized circular buffer.

Using a queue like this is great for passing data to be processed. It can also proxy a function call to another thread by using the "command" pattern. You can even pass exceptions this way.

In Topic: Exporting template instantiations to DLL

10 September 2011 - 06:51 PM

I'm thinking #1 won't work for me as I don't think static members in the template would be shared across DLLs. I was hoping I wouldn't have to do something like #2 but looks like there aren't better options.

Thanks for the suggestions.