Elysian Shadows

Ok so I keep running into LNK errors in VS. usually either 2001 or 2005. And usually with classes and header files.

But i wondered if it was a bad programming practice, for when you delcare classes that you declare them like this

you should get rid of ClassObject at the end



class Name
{

watever

};

yea i thought so... But what is so bad about doing that though ? Like what problems could i have in the long run ?

I'm not aware of any "problems" from doing this. It's just like creating a global ClassObject of ClassName. Some people frown upon globals, but I have never really been much of a style whore. I'll leave it to somebody else to tell you whether its in good form or not.

In theory, classes should be in separate files, so you wouldn't need an instance of the object at that point...

With that said, we all use hacky globals from time to time.

...or glorified globals like singletons and pretend that we aren't breaking the theory of OO design.

MakazeGamer wrote:Ok so I keep running into LNK errors in VS. usually either 2001 or 2005. And usually with classes and header files.

But i wondered if it was a bad programming practice, for when you delcare classes that you declare them like this

Code: Select all

class ClassName
{
private:
public:
}ClassObject;

its actually not bad,
but you are probably using it wrong.

classobject would usually be a alias for a pointer to that class/struct/union, thus in your program you wouldend have to write ClassName *Name, but only pClassName pName;

GyroVorbis wrote:...or glorified globals like singletons and pretend that we aren't breaking the theory of OO design.

I'm curious as to why singletons are getting such a bad name these days. I've found them to be ideal for several projects. Having an object that can only instantiate itself ensures that you don't have multiple instancing floating around the server, chewing up more memory, and potentially stepping on one other.

At work, a buddy and I built a web-based chat / bidding application - kinda like a realtime eBay. They originally outsourced it to India and it ran like shit. It crashed the web server when more than 8 users got in a room - cuz it was chewing up so many resources. We rewrote the backend using singletons. Basically each room was only instantiated once on the server, regardless of the number of people in the room.

There was also a project where we needed a single instance of a runtime running on the webserver. Having more than one would screw things up because they would step on each other. Wrapping the runtime in a singleton did the trick.

I agree that singletons don't fit every case, but I'm surprised that so many people are against them.

trufun202 wrote:

GyroVorbis wrote:...or glorified globals like singletons and pretend that we aren't breaking the theory of OO design.

I'm curious as to why singletons are getting such a bad name these days. I've found them to be ideal for several projects. Having an object that can only instantiate itself ensures that you don't have multiple instancing floating around the server, chewing up more memory, and potentially stepping on one other.

At work, a buddy and I built a web-based chat / bidding application - kinda like a realtime eBay. They originally outsourced it to India and it ran like shit. It crashed the web server when more than 8 users got in a room - cuz it was chewing up so many resources. We rewrote the backend using singletons. Basically each room was only instantiated once on the server, regardless of the number of people in the room.

There was also a project where we needed a single instance of a runtime running on the webserver. Having more than one would screw things up because they would step on each other. Wrapping the runtime in a singleton did the trick.

I agree that singletons don't fit every case, but I'm surprised that so many people are against them.

the singleton design pattern is my fav

Yeah, I agree. I honestly hate this whole OO whore movement that lots of indie developers seem to be a part of. It's like they are strictly adhering to this abstract idea of what is good and bad when coding based solely on what they read--it's clear that they don't have enough experience to decide what does and does not work for themselves.

These are also the same guys who make a million topics "IS THIS OO DESIGN OKAY?!?!" What good does it do if you question your overly complicated idea for implementation every step of the way? They are seriously working backwards.

I learned not too long ago how to be smart about game development. I am my own boss. I do as I please how I please. I make decisions based on what works for me and the project. I choose what will help further the project, not what the programming elitists say.

This is also why you won't really see me in C++ design topics commenting on OO implementations much. It's all too subjective for my liking. I'm all about the actual game development implementations of things. I will always be involved in those topics. But seriously, when it comes to bitchy OO design, count me out.

^ totally agree.

having a singleton design pattern does not neccasarily mean its not OO. anyways.

i cant remember who when or where, but it has been mathematically proven that any problem can be
solved by a procedural programming method.

also a small note, if you start with private, you don't have to declare it private. Its private by default(right people?)

From a testing point of view (I'm taking a testing class), tracing dependencies is harder, which means that testing is harder, since most testing has to happen on the interfaces (read: interactions) between objects, since that's where things go wrong most of the time. You can't look at the class and say "this class uses this class", you have to go through the code itself, or attempt to automate such a procedure (and if it's harder for you to do it's harder to automate, right?)

Same problem with globals. And that's why globals/singletons are bad... apparently. Not that I care... yet :)

MarauderIIC wrote:From a testing point of view (I'm taking a testing class), tracing dependencies is harder, which means that testing is harder, since most testing has to happen on the interfaces (read: interactions) between objects, since that's where things go wrong most of the time. You can't look at the class and say "this class uses this class", you have to go through the code itself, or attempt to automate such a procedure (and if it's harder for you to do it's harder to automate, right?)

Same problem with globals. And that's why globals/singletons are bad... apparently. Not that I care... yet

actually its alot easier to debug procedural code. there are no fancty things like JUnit or whatever they have these days.

testing suites are nice. but they do not do the job better in anyway. i believe that testing units and stadards were invented to make untechincal people understand how far along/ how fucked up a project on a technical level is.

showing a manager a pictures saying a the XML package has a bug with nice red colors, but thats the only thing that not working and we are fixing it.
is better than telling him, oh yeah, we have a major memory leak thats causing faulty data in the XML parser, but we dont know if its the parser because we havent tested to see if the function that support the XML class is giving it proper variables.

PS: if you wanted a decent testing suit for C++ i would use Unit++
its free.