Pretty much seconding Fruny also. Okay, I guess that's thirding...
What are the actual definitions (code) of these constructors, and what are the member variables for 'Bullets'?
(I wouldn't have made Bullet plural for the class name btw)
what to do when 2 constructors of the same class take the same paramaters?
Ok, horrible advice I'm going to give but hey,
Do whatever works so long as you ship product and you can understand how it works. If you're using VS.net, make sure that you at least put in comments before the constructors so that intellisense will tell you "this is the constructor which takes..."
Never trust anyone who hasn't finished a project... Regardless of the badness of design, I'd probably just do a hack [like reorder the parameters] for now and add a '#pragma message("todo : fix me")' and try to eventually get around to fixing it but that's just me. This seems like the simplest solution because you've obviously got one type of constructor which is used everywhere already and another which you're just introducing, so why not make the syntax for this new one different. Or get the constructor for the first bullet to construct the other two bullets and assign values directly.
Overall, I don't think that there is a particularly clean way to solve your problem, other than calculating velocity / direction 3 times without resorting to fixing code in other areas, but I'm assuming that you haven't taken perfect design decisions in the first place to get to the point where you 'have to look through 20k lines of code' not knowing where the weapon stuff would be called... so I say, have a hack solution [which at least works, and fix it later, I'm assuming that this new constructor would only have limited use through the rest of the application [ie in the first constructor or the SMG::FireWeapon() function or something]]. You'll be glad you did, when you're working on a far more complete project, learning new things, rather than refactoring old work in pursuit of a perfect design.
//End bad advice rant
CJM
Do whatever works so long as you ship product and you can understand how it works. If you're using VS.net, make sure that you at least put in comments before the constructors so that intellisense will tell you "this is the constructor which takes..."
Never trust anyone who hasn't finished a project... Regardless of the badness of design, I'd probably just do a hack [like reorder the parameters] for now and add a '#pragma message("todo : fix me")' and try to eventually get around to fixing it but that's just me. This seems like the simplest solution because you've obviously got one type of constructor which is used everywhere already and another which you're just introducing, so why not make the syntax for this new one different. Or get the constructor for the first bullet to construct the other two bullets and assign values directly.
Overall, I don't think that there is a particularly clean way to solve your problem, other than calculating velocity / direction 3 times without resorting to fixing code in other areas, but I'm assuming that you haven't taken perfect design decisions in the first place to get to the point where you 'have to look through 20k lines of code' not knowing where the weapon stuff would be called... so I say, have a hack solution [which at least works, and fix it later, I'm assuming that this new constructor would only have limited use through the rest of the application [ie in the first constructor or the SMG::FireWeapon() function or something]]. You'll be glad you did, when you're working on a far more complete project, learning new things, rather than refactoring old work in pursuit of a perfect design.
//End bad advice rant
CJM
Quote:Original post by JohnBoltonQuote:Original post by Fruny
... Having your constructor do different things based on just parameter ordering is an unspeakable horror.
LOL. Where on the scale would you find "evil", "spawn of Satan" and "your worst nightmare" in relation to "unspeakable horror"?
(Good) Bunnies - Evil - Your Worst Nightmare - Spawn of Satan - Altering parameter order as a hack - Azathoth (Not good)
Excerpt from evil.h, an actual header in our local toolkit. The header is intended to encapsulate all those evil bit-twiddling functions (e.g. fast inverse square root) you might be tempted to use elsewhere, to keep code clean.
The evil level determines whether the hacked-up functions or the slower-but-sane versions are used. Not all evil levels are meaningful. But that's ok, it's evil.h after all.
#define EVIL_WHY_ARE_YOU_EVEN_BOTHERING_WITH_THIS (-1)#define EVIL_NOT_AT_ALL 0#define EVIL_DEAD 1#define EVIL_DEAD_PART_II 2#define EVIL_DEAD_ARMY_OF_DARKNESS 3#define EVIL_THE_DIET_COKE_OF_EVIL 5#define EVIL_KNIEVEL 6#define EVIL_MCBRIDE 7#define EVIL_QUASI_EVIL 10#define EVIL_PSEUDO_EVIL 20#define EVIL_SNIFFLES 50#define EVIL_PAPER_CUT 75#define EVIL_UNUSED_EVIL_LEVEL_TO_TAKE_UP_SPACE 99#define EVIL_SNOWBOARDING 100#define EVIL_EVIL 250#define EVIL_HOMER 350#define EVIL_AND_WE_MEAN_EVIL 500#define EVIL_FRUITS_OF_SATAN 666#define EVIL_YOUR_WORST_NIGHTMARE 999#define EVIL_THE_SICKNESS 1000#define EVIL_STENCIL_BUFFER 1024#define EVIL_CTHULHU 4096#define EVIL_UNSPEAKABLE_HORROR 8192#define EVIL_BROGANIZATION 65536#define EVIL_FAST_AND_WRONG_BUT_WHO_CARES 314150The evil level determines whether the hacked-up functions or the slower-but-sane versions are used. Not all evil levels are meaningful. But that's ok, it's evil.h after all.
Quote:#define EVIL_THE_DIET_COKE_OF_EVIL 5
LMFAO. I'd agree with that scale of wickedness except I'd have to change this one to :
#define EVIL_THE_DIET_DECAFFEINATED_SURGAR_FREE_SAMS_CHOICE_GRAPE_SODA_OF_EVIL
Named constructors.
Bullet* b = Bullet::velocity(stuff);
Bullet* c = Bullet::position(stuff);
or whatever.
Bullet* b = Bullet::velocity(stuff);
Bullet* c = Bullet::position(stuff);
or whatever.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement