Jump to content
  • Advertisement

Morbo

Member
  • Content Count

    182
  • Joined

  • Last visited

Community Reputation

218 Neutral

About Morbo

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The difference between a POD and a class is that a class enforces rules (commonly called invariants) on its data, whereas a POD is simply a container for data. A class also emphasizes functionality over implementation: don't care how it's done or stored in memory, just care what you can do with it (which is also closely related to data hiding). For example, a string is usually stored as just a char*. If you just created a struct with a pointer and passed it around, anyone would be able to break your string by deleting the array, changing the pointer, or replacing the null terminator with a 1. This reveals the fact that a string is NOT just a character array, it's an array with certain constraints: mainly that it's null terminated and always contains valid data. So the job of a string class is to ensure these constraints are always met and no one can mess with them. It does this by hiding the char* and providing methods used to safely manipulate and access the string. Ideally these methods should be comprehensive yet primitive: setting the string, appending/inserting a substring, removing a substring, etc... In short, PODs are fragile and hard to modify, while classes hide data and provide methods in order to prevent breaking the data and allow you to vary how it's implemented.
  2. Quote:most member functions can be written as nonmember nonfriend by moving member variables to parameters If they really can be, then they shouldn't be fields. If you read his detailed explaination of this principle, what he's getting at is that a class should provide only the basic 'first-principal' methods required to manipulate it: These are the methods that absolutely require access to private data and code in order to work. If a method can be expressed in terms of other methods in the class, it is a candidate for being moved to a non-member, non-friend function. For example: The C++ ostream class has many << operators for dealing with all the primitive types (int, float, double, etc...). However, given a method to output a single byte, all other primitives can be output in terms of that method. So technically the instertion operators for all types byte unsigned char could be converted to non-member, non-friend functions. The purpose of this principal is to keep the number of methods that are changing private data to a minimum. By doing this it's easier to ensure that there's no way to break the invariants the class is trying to achieve. Did that help any?
  3. You should also do: for(; iter != m_objectList.end(); iter++) instead of: for(; iter < m_objectList.end(); iter++) Since comparing iterators using < is not guaranteed to work.
  4. Morbo

    TEMPLATES and MICROSOFT

    The MSVC 7.1 compiler is actually one of the most compliant C++ compilers out there these days. Templates MUST be completely declared and defined within each compilation unit that uses them. This usually means placing it all in a header file. There has been work done on using the 'export' keyword to change this, but from what I've read there hasn't been much significant progress. So to answer your question: no there isn't.
  5. Morbo

    about upx data compression

    Look at the product for info on how some (very impressive) 64k demos were made. They've even released the tool they used to make them, but no source so far.
  6. Man is that video making the rounds. Yes, it was intentional. No, he's neither rich nor a total dumbass: it was a paid-for stunt (you can see the Fox logo on the bottom skin of the canopy, and there's the blonde with the mike). Well, he's maybe a little nuts, as usually on stunts like that you want to have a tertiary (third) canopy. The guy is a very experienced skydiver and knows the risks, though. And FYI, it's nearly impossible to 'accidentally' set a canopy on fire. Nylon doesn't burn very well. For this particular one they had to soak it in kerosene overnight and leave it soaking on the ride up. Not the first time this stunt has been done, though.
  7. Quote:Original post by eq I might be wrong but shouldn't the declaration be? template< class TYPE > class CGrowableArray; Either works: class and typename are interchangeable in the template world. dxben, it would be helpful if you posted the exact error message, including the offending line of code.
  8. Morbo

    neat error!

    That's funny. I'm guessing the CString and std::string don't play nicely (then again, who does play nicely with CString?).
  9. I agree with Sagar. Any company hiring a programmer wants some indication that you can a) actually program, and b) apply that knowledge as more than just a hobby. Showing that you can make it through a school program lets them know on both counts. It doesn't even have to be a degree. I started with a diploma from a technical institute. From there you'll find many companies that hire juniors simply based on graduating (the first company I worked for, for example, typically hired more than 50% of the class from my program). If you personally know someone who's looking for a programmer, and he knows your skills, you can sometimes get in that way. But that's a longshot at best, and unless you already know that someone, it takes a while to get to know someone well enough to go that route. My suggestion: get any kind of diploma/degree/courses you can.
  10. Morbo

    Making ALIEN not Aliens

    Try any of the Thief games to see how it can be done.
  11. Note that an array of objects in Java is only an array of object references (like having an array of pointers in C). Creating the array only allocates memory for the references, NOT the objects themselves. To actually create an array of objects, you have to follow up with: for (int i = 0; i < 20; i++) TheSeats = new Seat(); Otherwise you just end up with an array of nulls.
  12. Morbo

    idea for recursive functions

    This is handled by some languages by using tail recursion. Basically, if the last line of a function is a recursive call, the call can be reduced to relacing the parameters on the stack and jumping back to the beginning of the stack. As long as the call is the last operation in the function, nothing is lost by the optimization. It's called 'tail recursion' since the recursive call has to be at the end (tail) of the function. Some languages ease this restriction a bit, but the concept is always the same. In your example, you'd have to rewrite the function like so: int recur(unsigned a) { if (a >= 1000000) return a return recur(a+1) } Now, instead of the last line returning, it can simply replace the value of a with the new one, and jump back to the top. No call required.
  13. This sounds very much like the Eclipse plugin system here. They've had a lot of success with it. I recommend checking out some of their docs for further ideas.
  14. Morbo

    Memorable gaming moments

    The abandoned insane asylum/orphanage level in Thief 3: when I went up the spiral staircase to the attic and the pounding on the door started, I ran so fast and didn't stop until I was out of that place. Took me a few minutes just to get up the nerve to go back inside. Never been so scared by a computer game...ever. In fact, that whole level had me freaked out. I really want to meet the guy that designed it.
  15. If that's your only example of STL not being performant enough, then I believe all you need to understand why people use it is more knowlege of HOW to use it. As Oluseyi already pointed out, the poor performance of your code was due to not using reserve() when you knew ahead of time how many elements would be added. If you read the docs on vector, it spells out quite clearly the performance characteristics and how to achieve optimal performance (reserve being only one technique among many). In short: if you spend a little more time learning how to use STL properly, all your questions will be answered.
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!