[blackhole]

Because every now and then, we write them. Sure, they'll get chopped up into safer versions, but they're still fun to look at.

Code: [Select]

_events[i].first.second->getEvent(_events[i].first.first)->setFireID(RetrieveFromPointer<UNRELATEDDEF>(_events,refs[counter++])->first);


[Topgun]

huh? why do you have objects and namespaces named like that? that is bound to be confusing.

[blackhole]

...there are no namespaces in that line of code 

If your referring to .first and .second, those are pairs and therefore I have no control over the naming.

[Topgun]

never mind.
miss read the code. thought you where using First::getEvent.first.first

[portej05]

Thought I'd share one of the more difficult to debug ones I've seen (simplified for expository purposes, and to hide the guilty parties):

Code: [Select]

struct FunctionThreadData { };
RESULT function( )
{
   FunctionThreadData thread_data;
   ...
   afxBeginThread( thread_function, &thread_data );
   return SUCCESS;
}

If you're not sure what's going on above, it's passing a pointer to a stack allocated variable to a thread function and then returning.
If you're lucky, your threaded function gets half a chance to access data in the passed variable before it goes out of scope.

Took quite a while to track this one down.

[WMCoolmon]

Code: [Select]

if( ((wip->arm_time) && ((Missiontime - wp->creation_time) < wip->arm_time))
|| ((wip->arm_dist) && (pobj != NULL && pobj->type != OBJ_NONE && (vm_vec_dist(&wobj->pos, &pobj->pos) < wip->arm_dist)))
|| ((wip->arm_radius) && (wp->homing_object == NULL
|| (wp->homing_subsys == NULL && vm_vec_dist(&wobj->pos, &wp->homing_object->pos) > wip->arm_radius)
|| (wp->homing_subsys != NULL && get_subsystem_pos(&spos, wp->homing_object, wp->homing_subsys) && vm_vec_dist(&wobj->pos, &spos) > wip->arm_radius))))
{
return false;
}
Just imagine that without newlines or indentation.

Here's another fun piece of code.
1) You start with two functions, add_collision_pairs and remove_collision_pairs.
2) You need to add collision pairs when a ship becomes collideable and was not collideable before, and remove collision pairs when a ship becomes non-collideable but was collideable before
3) A ship is collideable when it is not in limbo and has the collision flag set.
4) obj->flags contains the old bitflags, new_flags contains the new bitflags

[portej05]

After horsing around in the ATL and MFC headers trying to track down a compile error, I'd like to nominate the ATL/MFC macros. 

[Uchuujinsan]

Not sure what I am going to do with this one..  (note the sole "delete"...)

Code: [Select]

void MapGraphics::ExecuteDelayedBlit()
{
for (std::list<DelayedBlitInformation>::iterator i = delayedBlitInfo_.begin(); i != delayedBlitInfo_.end(); ++i)
{
//SDL_SetAlpha((*i).sourceImage, SDL_SRCALPHA, 0);
if (*((*i).targetSurface) == mapBackground_) {
SDL_SetAlpha((*i).sourceImage, SDL_SRCALPHA, 0);
SDL_BlitSurface((*i).sourceImage, (*i).blitRect, *((*i).targetSurface), &(*i).destination);
}
else {
GfxEngine::BlitWithAlpha((*i).sourceImage, (*i).blitRect, *((*i).targetSurface), &(*i).destination);
}
UpdateRect((*i).destination);
delete (*i).blitRect; //delete the in MoveAndReplace with "new" created SDL_Rect
SDL_SetAlpha((*i).sourceImage, 0, 0);
}

delayedBlitInfo_.clear();
}
I also love the way to write the type of iterators..

[Flipside]

Ever read the Source Code for some of the Java functions? Some of them won't even compile in later versions of Java...

[phreak]

Code: [Select]

Int3();


[Mika]

I vote for the Fortran one.

Sometimes I feel lucky I was never taught any kind of structural programming. Otherwise, I could, like, get involved with this kind of stuff. Life is simple as long as the only thing to do is computationally efficient algorithms.

As far as I remember, they said never to use multiple threads unless it is absolutely necessary. I, for one, have, of course, no idea what they were talking about but it sounded good enough to warrant writing it down here.

Mika

[portej05]

I'd like to nominate __if_exists and __if_not_exists C++ extensions... you can see them in the ATL headers.

[karajorma]

I'd lke to nominate Microsoft for making this legal in MSVC6

Code: [Select]

for (int i=0; whatever) {
}

x = i;
Every other compiler on the planet will beat you around the head and yell "SCOPE!" at you if you tried that nonsense.

[WMCoolmon]

That's pretty blatantly unfair to Microsoft. C++ as a standard wasn't even ratified until the year that C++ 6.0 was released, meaning that there were at least 5 versions of the program released while C++ was in development. If this were something GNU/Linux related, I doubt you'd be just as quick to slap them around for not conforming to a standard during development that didn't even exist. I'm not saying that you, personally, are a Linux-lover, just that it's a lot more trendy to be quick to blame Microsoft for all the problems in their software.

Once somebody made the decision that "for loops are shorthand for while loops, so the declared variables should be accessible outside the loop" or something else happened, and it was released, and thousands and then millions of people started using Visual C++, Microsoft faces a conundrum. They can fix the language and piss off everybody who doesn't feel like they need to spend the time, and therefore money, to fix their code. Those people will hold it against Microsoft, possibly not buy the new version of their software, and go on holding Microsoft accountable for bugs in the old version of their software. Meaning Microsoft either has to support multiple versions of software, or they have to stick with the old behavior. Since sticking with the old behavior is less risky, it makes more sense while Microsoft is still competing with other companies. Nowadays, Microsoft doesn't really have to care and part of their business strategy is demonstrating that they're willing to go the extra mile to get "standards compliance".

As an example, look at all the crap I got for seriously revising the syntax for the scripting system once. I had experienced developers acting like I was incompetent just because I changed it, regardless of whether it actually made things better or not, when my changes affected all of a dozen people directly and maybe some hundred thousand people. Microsoft makes changes to the compiler, it affects millions of people directly, and billions of people indirectly. What kind of ****storm could they expect to hit the fan if there wasn't so much pressure to conform to standards as there is nowadays?

All that being said, MSVC2008 does give you

Code: [Select]

main.cpp(35) : error C2065: 'i' : undeclared identifier
So when I read your comment it comes across as a symptom of the problem that would cause Microsoft to say that they should keep things the way they are, because presumably if they left COFF support in and didn't change anything, you'd be upgrading to 2008 and using that instead. Granted, I don't see any good reason for them to take COFF out except to force people to use their proprietary debug files, but I doubt that's something that couldn't be fixed given time, effort, and some well-place #defines.

[karajorma]

That's pretty blatantly unfair to Microsoft. C++ as a standard wasn't even ratified until the year that C++ 6.0 was released, meaning that there were at least 5 versions of the program released while C++ was in development. If this were something GNU/Linux related, I doubt you'd be just as quick to slap them around for not conforming to a standard during development that didn't even exist. I'm not saying that you, personally, are a Linux-lover, just that it's a lot more trendy to be quick to blame Microsoft for all the problems in their software.

If I encountered anything as stupid on Linux I'd be just as quick to blame them.

I don't encounter stupidity on Linux cause I don't use it. You can bet I'd complain more if I ever took leave of my senses long enough to install it.

[portej05]

wrt the for loop, there's been a compiler switch since VS2005 that will change VCs behaviour on this one /Zc:forScope
It's on by default.

[blackhole]

That's pretty blatantly unfair to Microsoft. C++ as a standard wasn't even ratified until the year that C++ 6.0 was released, meaning that there were at least 5 versions of the program released while C++ was in development. If this were something GNU/Linux related, I doubt you'd be just as quick to slap them around for not conforming to a standard during development that didn't even exist. I'm not saying that you, personally, are a Linux-lover, just that it's a lot more trendy to be quick to blame Microsoft for all the problems in their software.

Once somebody made the decision that "for loops are shorthand for while loops, so the declared variables should be accessible outside the loop" or something else happened, and it was released, and thousands and then millions of people started using Visual C++, Microsoft faces a conundrum. They can fix the language and piss off everybody who doesn't feel like they need to spend the time, and therefore money, to fix their code. Those people will hold it against Microsoft, possibly not buy the new version of their software, and go on holding Microsoft accountable for bugs in the old version of their software. Meaning Microsoft either has to support multiple versions of software, or they have to stick with the old behavior. Since sticking with the old behavior is less risky, it makes more sense while Microsoft is still competing with other companies. Nowadays, Microsoft doesn't really have to care and part of their business strategy is demonstrating that they're willing to go the extra mile to get "standards compliance".

As an example, look at all the crap I got for seriously revising the syntax for the scripting system once. I had experienced developers acting like I was incompetent just because I changed it, regardless of whether it actually made things better or not, when my changes affected all of a dozen people directly and maybe some hundred thousand people. Microsoft makes changes to the compiler, it affects millions of people directly, and billions of people indirectly. What kind of ****storm could they expect to hit the fan if there wasn't so much pressure to conform to standards as there is nowadays?

All that being said, MSVC2008 does give you

Code: [Select]

main.cpp(35) : error C2065: 'i' : undeclared identifier
So when I read your comment it comes across as a symptom of the problem that would cause Microsoft to say that they should keep things the way they are, because presumably if they left COFF support in and didn't change anything, you'd be upgrading to 2008 and using that instead. Granted, I don't see any good reason for them to take COFF out except to force people to use their proprietary debug files, but I doubt that's something that couldn't be fixed given time, effort, and some well-place #defines.

I nominate this as an absurdly over-the-top totally-unnecessary response from a clearly disgruntled programmer.

 

[WMCoolmon]

I've never been happy about watching other people squander my hard work and, more importantly, my time.

I'm just glad it's all in the past now.

[General Battuta]

Does that mean you're working on FSOpen again? Or that you are forever done?

[WMCoolmon]

It means I'm around to provide support, but I don't plan on coding on FS2Open for the foreseeable future.