searching in the memory pane

BTW, as a side note '-8.000000' will never be displayed like that in memory unless it's a string. Floating point values are represented in IEEE format, which is documented here: http://msdn.microsoft.com/en-us/library/vstudio/0b34tf65.aspx ("IEEE Floating-Point Representation"). How both correspond to each other is illustrated best with the code snippet from http://stackoverflow.com/questions/2404675/how-do-i-convert-from-a-decimal-number-to-ieee-754-single-precision-floating-poi - which (modified for 'double' values and more C++-like) works like

#include <iostream>
using namespace std;

typedef union
{
    long int i;
    double d;
} U;

int main(void)
{
    U u;

    u.d = -8.000000;

    cout << u.d << " = " << u.i << endl;

    return 0;
}

Select allOpen in new window

You have a couple of options that I can find (if you are on Visual Studio 2010 Ultimate... not sure what might be different for different values).

1. Right click on the memory window and change the format of the data being displayed.  The default should be '1-byte Integer' allowing you to see the raw hex values of each memory address.

But one of the options is '64-bit Floating Point' which corresponds to a double.  Since double values should be getting aligned on 64-bit boundaries (at least they do on my 64-bit system) you can indeed see the value -8.0000 by visually scanning the memory.

2. I don't know how well this would work for formats other than '1-byte Integer', but you could open a blank file in the Visual Studio binary editor.  You could then select a section of memory from the memory window.  Then right-click in the memory window to do a 'Copy', and then go paste the values in the binary editor.  You could then do a search in the binary editor for a particular hex pattern (simply key in the string of hex values with a space between each value).

Possibly the most difficult part of this issue is getting a file openned in the binary editor.  One way to do this is to use Windows Explorer to create a new text file and name it something like "mem.bin" (replacing the default .txt extension with .bin).  Then add this bin file to your project.  It will likely get automatically added to you Resource section, but you can drag-and-drop it out to the main project level (i.e. one level above the folders the source code and header files are in).  In any case, once you have this blank file added to the project, double click the file and the .bin extension should cause it to open in the binary editor.  If it does not, right click on the file and select "Open With..." to manually select the Binary Editor to open the file with.

As I say, once you have the binary editor open in Visual Studio, you can highlight a section of memory from the memory window (even highlighting the memory addresses displayed) and Copy-n-Paste it into the binary editor and only the binary memory data will get copied from the memory window to the binary editor.

... OK, HooKooDooKu, so the "Search..." option is exactly where?

Search in the binary editor...

Well... except upon further review, it turns out that a copy-n-paste from the Memory window does NOT only copy the memory data.  It instead copies the text as shown in the Memory window.

So we need a different way to get or memory data into the binary editor.  And so far, the only way I've come up with a way to do that is rather than trying to copy from the memory window, write a function like the following:

void WriteMemory( const void* p, UINT nCount )
{
	try
	{
		CFile fout;
		BOOL b = 
			fout.Open( "C:\\BW\\Test\\CPlusPlus\\mem.bin", 
			           CFile::modeWrite | 
					   CFile::shareDenyNone |
					   CFile::modeCreate );
		if( ! b ) throw "Failed";
		fout.Write( p, nCount );
		fout.Close();
	}
	catch(...)
	{
		MessageBox( NULL, "Unable to Copy Memory to Bin file", "", 0 );
	}
}

Select allOpen in new window

where you hard code the name of YOUR binary file you've attached to the project.  You can then either call this function from code, or even call it from the Debug/Immediate window.  You just have to make sure that the size of the given nCount is within the memory space allocated to your program.

this provides an alternative approach, it's not exactly the one i would prefer.