Executing in VS2005 verses the .exe directly?

sausagesausage
edited January 2011 in General discussions
This is an odd question, I know, but is there any difference at all between executing a project in VS2005 verses running the .exe directly in the /bin folder?

I would have said no myself, but I notice tonight if I run my project within VS, all orxOBJECT elements are fine.

If I run the .exe directly, I notice some of my minor elements lose their position values and stick to 0,0,0.

It's not a big deal, I can fix this stuff up probably but I'd like to know why it would be different. I can't see how it could be. A pathing thing? The initial positions being picked up in the config perhaps?

The debug logs generated between the two execution methods were identical.

Comments

  • iarwainiarwain
    edited January 2011
    I can only think of two differences: the working directory which is enforced by Visual Studio and the fact that the debugger is likely to set to some value all the uninitialized variables.

    If it's none of these, I'm all for some printf (or orxLOG, in this case! ;)) debugging!
  • GreyGrey
    edited January 2011
    HA! Debugging? -REAL- men -GUESS! :D
  • sausagesausage
    edited January 2011
    orxLOG always cops a fair flogging. Executing from VS in either DEBUG or RELEASE, positions are correct. Executing the resulting .exe alone in either mode, positions are not correct.

    I'll do some orxLOG outputs and pinpoint the difference. I'll report back when I have something.
  • sausagesausage
    edited January 2011
    It appears to be uninitialised variables. Oops.

    I'll have to find out how to enable that as a warning in VS.

    You know, in my day, we used truckloads of uninitialised variables and it didn't hurt us a bit. We carried them to school, uphill, both ways. :)
  • iarwainiarwain
    edited January 2011
    Hehe, world would be so [strike]deterministic[/strike] boring without uninitialized variables! ;)

    There's probably a warning to enable in VS, but you need to check MSDN to find its number. If it were me, I'd go with CppCheck which is a great static code analysis tool which will find much more issues than VS's compiler. :D
  • GreyGrey
    edited January 2011
    LLVM and Clang... now -there- is a way to do code analysis... such -delicious- error messages *drools*

    *cough* erm... sorry, vs2008 and vs2010 also have considerably better error/warning/whatnot handling, just curious, is there any particular reason you're sticking with 2005?
  • sausagesausage
    edited January 2011
    I have all three on my system (work requires every version), but I choose vs2005 because it's an old friend and because it's the only one that can drop 0 - 100kms an hour in 3 seconds (fast startup speed :)).

    vs2010 spends too much time contemplating it's own navel, and vs2008... I don't like it's startup image. Kidding of course. I'll eventually use vs2008 more, but not vs2010 though.
  • GreyGrey
    edited January 2011
    hmm, never had any real lag on start-up with 2010, but I'm a bit of a pedant when it comes to keeping my drives... 'efficient'. Which is probably a good thing considering my system is on an -old- 120gb IDE drive *shame*

    (*edit* dang I used the word "drive" a lot :p)

    Still, to each their own I suppose :) I'd love to have vs2010's interface (not sure why, just like it... go figure) with LLVM and Clang's compiler&errors, and N-brain's collaborative ide tools... -that- would be bliss ... too bad n-brain's now dead, and Microsoft are infested with the 'not invented here' syndrome :(... ahh, dreams and their crushing defeats :(
Sign In or Register to comment.