Thread: Passing Pointers or References?

It's handy when it comes to needing to get a reference to the data I'm loading up and it's proved pretty useful so far.

What exactly is this "reference" to the data you are talking about?
Usually, you would use a smart pointer for this task, perhaps even std::string.

As for the JIT debugger... what debugger are you using? People can offer assistance, but they must know which one you use.

I use the built-in VS2009 Debugger. I've had a lot of sucsess with it but there are the nuances that can get confusing sometimes. I'm hesitant to ask about specifics because 1) I don't want to waste someone's time when my question could very well be answered on MSDN and 2) I try to stay away from platform/implementation specific questions in a general C++ forum.

As for not using a std::string for storing file data, the problem is that PhysicsFS (http://icculus.org/physfs/), the Filesystem library that I'm using, requires an address to a char* to which it writes file data to as a series of bytes. Many projects have used it sucsesfully and so I imagine that I will be able to also -- so far it hasn't given me any problems and it provides exactly the sort of disk/file access I want (including transparent reading/writing to archives such as ZIP/PAK/WAD/7ZIP/etc, big huge plus).

The 'data' I'm reffering to is basically a byte array stored in a char*. This is then passed to other components that then read whatever file I loaded using the Filesystem (e.g., an OGG would be loaded by the Mixer, a PNG would be loaded by the Renderer, a plain text XML file would be loaded by the Configuration Parser, etc.). I could simply pass this information out as a std::string but it makes it easier to just throw it out as a const char* as that's the 'format' that it's already in.

I guess you could say my terminology isn't perfect. 'Reference' may have been a poor choice of words.

I want to make clear that my issue is generally resolved. I do appreciate the continued support, suggestions, advice and efforts to offer additional assistance as I've learned a great deal over the last few days. It's great to know that there's a community I can turn to when I have questions and not be told to RTFM or STFI. Thanks again everybody!

As for not using a std::string for storing file data, the problem is that PhysicsFS (http://icculus.org/physfs/), the Filesystem library that I'm using, requires an address to a char* to which it writes file data to as a series of bytes.

You can use vector of chars in this case

Originally Posted by leeor_net

I use the built-in VS2009 Debugger. I've had a lot of sucsess with it but there are the nuances that can get confusing sometimes. I'm hesitant to ask about specifics because 1) I don't want to waste someone's time when my question could very well be answered on MSDN and 2) I try to stay away from platform/implementation specific questions in a general C++ forum.

Do that as you want, but there are a few here who has experience with the VS debugger (me included) and can give you hints, tips and guidance should you require it. Becoming a master programmer also means mastering a debugger, or so I would like to say.

Originally Posted by leeor_net

No, I can't. It doesn't crash in the debugger in either debug or release and everything appears to be normal which is what is making this so frustrating and why I've posted on cprogramming.com... It only crashes when I run the program outside the debugger which isn't exactly helpful.

So run it outside, wait till it crashes. Then - without closing the error message - use aatach to process fature of the debugger and exemine the stack.

Note that sometime stack could not be displayed even when the exe is compiled in the debug mode which in most cases indicates the memory overrun of some var declared on stack and calling return when the actual return address is overwritten with garbage

There is a way to get stack tracing in release mode when an exception is thrown, however, it requires a bit of work and some assembly code. There are examples of this in books specifically about Microsoft's debugger in Visual Studio. The MSVS debugger is powerful but is usually shipped as a lame duck most of the time. Most of the tricks you can do with it require external code or assembly and/or fairly decent knowledge of its internal workings.

The VS debugger can attach to the process, however, you will only get an assembly output when you do a break all. It is not good at parsing the assembly and giving you good information about what is going on. However there are 3rd party debuggers that are good for this. One that comes to mind is OllyDebug. You can attach to your process, analyze the source, find all intermodular calls, all referenced text strings, and it even recognizes which calls are Win32 calls. It can break down the calls by parameter and show you what each parameter is. Very handy. Perhaps this will show you what is going on.

I read in a Symantec security analysis of Vista that Vista has a technique to randomly allocate memory for programs. This way hacker or malware can not guess the place of data.
For example when you do

Code:

int *password = new int;
*password = 23124;
...
delete password;

The value of password is stiil there. It is called ghost, if remember correctly. You can read that if you know its address and have the permission to access that address (for example when the original program is terminated or has released the memory. A few time it made a hardtime debugging my code, because it worked correctly in debug mode but not in release mode. It was actually reading ghost value in debug mode. Vista may prevent this to happen.