Thanks, Fortunately it was as simple as replacing '\n' with '\0' in "p" before ReleaseBuffer(). Unfortunately, my problem has just moved somwhere else, which I'm guessing means that I have other memory leak issues to deal with... That's ok, I'm sure it builds character or something like that...

Okay... the pointer is to the CString data, not a copy of it, so back to square one... Am I the only one with nothing better to do on this fine Friday night? :laugh:

My understanding from the MSDN docs on ReleaseBuffer() is that the memory that "p" points to is freed (invalidated), but when running in debug I can see that this is not the case. Is it possible that I am filling up memory by not explicitly freeing the memory that "p" points to before assigning it to a new string via GetBuffer()? Or is this a side-effect of running in debug mode?

Hello all, I am trying to track down the root cause of an out of memory error when using CString GetBuffer(). I appreciate any insight or constructive criticisms of poor methods. The CString resides in an object of the "grp_vals" class: class grp_vals{ public: CStringA Name; float Vals[MAX_VALS]; float& operator [] (int Idx){ return Vals[Idx]; } }; The code where the problem arises is: LPSTR p; grp_vals *tmpvals; ... tmpvals = new grp_vals; ... p = tmpvals->Name.GetBuffer(32);//HERES WHERE THE PROBLEM STARTS fgets(p,32,FileHandle); tmpvals->Name.ReleaseBuffer(); tmpvals->Name.Remove('\n'); This code "works" for many iterations but eventually the error occurs and was traced to the "if( pNewData == NULL )" below (from the standard atlsimpstr.h)...sure enough, it's NULL but I'm not sure why only in this one case... the pOldData does not *seem* to vary from previous iterations that "worked". ATL_NOINLINE void Fork( __in int nLength ) { CStringData* pOldData = GetData(); int nOldLength = pOldData->nDataLength; CStringData* pNewData = pOldData->pStringMgr->Clone()->Allocate( nLength, sizeof( XCHAR ) ); if( pNewData == NULL ) { ThrowMemoryException(); } ....

modified on Friday, December 14, 2007 9:38:20 PM

This sounds most promising...

I'm looking to maximize my speed while reading a binary file - the file contains a mix of floats & ints(4bytes each) and occasional strings. Floats and ints are converted to the correct endianess post read using bit shifts and masks. I've fine tuned everything I can think of for reading the file, but have not previously considered changing the interface to the file. I am currently using FILE * with the associated fread, seek etc. functions for no better reason than this being what my original C code used (this entire app is now ported to VC++ with MFC). Is there a faster file reader I should consider? Any speed increase would help, as I am reading 100's of megs of data. Thanks for any opinions.

Is it possible to send a command to the operating system without causing a command window to pop up? This seems to be the behaviour of system(command), any alternatives? Thanks

Sometimes just stating a problem helps you fix it... A good ole' extern "C" {} around the api #includes did the trick Thanks for allowing me to waste your time :)

I'm porting an old app that was created in VC6 in C-code to VS2005 C++ code. This is an api app that hits a shared lib for interaction with the main app. As soon as I change from C to C++ and build, I have unresolved externals... change back and it builds fine... I've added the project dirs (include and lib), maybe missed something else?? Any ideas? This seems to apply to functions from the shared lib, as well as other c-coded functions in the solution: gen_geo.obj : error LNK2019: unresolved external symbol _rabs referenced in function _make_bbox Thanks

TheFluffer wrote:

100kmp = 6x100 = 60mph 60 Kpm = 6x60 = ~35 mph

This must be that "new" math

I'm not as concerned about the icon displayed in explorer as much as the one in the upper left corner of the main window of my app...

I totally deleted the IDR_MAINFRAME resource and icon file on disk. I then made a new icon by importing a .bmp... clean and rebuild... still the "MFC" icon (I think it's giving me the finger). It must be defined somewhere else or cached or something?

I've got a standard MFC MDI app, and want to change the "MFC" icon to my own. In resource view, I've tried editing the icon (in VS) changing what file it points to, even deleting the "MFC" icon file - all make it look right in the resource view, but run the app and the "MFC" icon is still there. Is this called out explicitly in code somewhere? Thanks

Thanks for the reply, Just tossing a few other thoughts around... Given the following: - vertex is of type float[3] - verticies is an array of SIZE vertex (verticies = new vertex[SIZE];) - vertsfromfile is an array of (SIZE*3) floats are the floats in "verticies" aligned one after the other in this fashion: verticies[0][0]verticies[0][1]verticies[0][2]verticies[1][0]verticies[1][1]...and so on to allow for something like memcpy(verticies,vertsfromfile,(sizeof(vertex)*SIZE)) ? or is this just crazy talk? Thanks

I'm reading a bunch of raw numerical data (floats representing verticies) from disk in one endian format, and need to convert it to another (flip the bytes around). Currently I am reading the numbers one by one and bit-shifting them to the correct format, then placing them into their respective places in an array of verticies (float[3]'s). I am trying to speed up this whole operation, and may be able to do so with a better method/algorithm. The following also may help: - Each float is 4 bytes and needs a pure reversal of bytes - not bits (bytes 1234 become 4321) - the floats are contiguous on disk - I know ahead of time how many floats I will be loading into a given array - The array will be pre-allocated to hold the right number of verticies - I must keep (or end up with) the array two-dimensional (array of float[3]'s) for later OpenGL usage not sure if reading them all in at once, and applying a macro-bit-shift would be faster? Thanks for any help

I have an app that eats up a bunch of memory with objects (created with "new"), then releases it back to the system (using "delete"). I am monitoring the memory usage with taskmanager, and noticed something strange... the memory does not seem to be given back to the system. If I minimize the app, the memory is magically recovered by the system, and all is well, even after restoring the app. Is the memory actually given back, but taskmanager is just out of the loop until the minimize, or is the memory not released until the app is minimized? if so, am I supposed to call some sort of "flush" function to give it back? Thanks

The Music of the Primes, by Marcus du Sautoy - also a good read on the subject - good history

I believe display lists are limited to an OpenGL rendering context. Although you can share rendering contexts across windows (by changing the device context), they must all share the same pixel format. (found in OpenGL Superbible pg. 658) hRC = wglCreateContext(hDC); //initially create rendering context wglMakeCurrent(hDC,hRC); //change to a different hDC, keeping the original hRC Can't say I have actually done this...

Thanks to all that helped me get over my debug issues... It turns out (as many suggested) that the code I was porting from 'c' and wrapping in an MFC gui had to lose all the old malloc/reallocs it had to work correctly without causing debug to puke. This manifested itself in strings for the most part. From what several said, malloc uses a different stack than new, and was causing one to stomp on the other. I must ask at this point...why? Is there a "safe" wrapper out there for malloc (to possibly save re-writing old code)? why did only debug have a problem with sharing methods? Based on call stacks examined while getting to the bottom of this, I saw CString using malloc and free deep down inside... why don't these cause issues? Thanks again

Well Quebec is on the rest of Canada's "not like" list - tends to happen when they try to break off from your country.