Re: A simple question about memory reallocation - C / C++ / MFC Discussion Boards

#include <vector>

vector <int> intvector;

...for each int read from file...

intvector.push_back( intfromfile );

Edited for anglebrackets LOL

If the file is in text format, you just need to do the following:

#include <iostream>
#include <fstream>
#include <vector>
#include <iterator>
#include <algorithm>

using namespace std;

...

vector<int> myVec;
ifstream fin;
fin.open("myFile.txt");
copy(istream_iterator<int>(fin), istream_iterator<int>(), back_inserter(myVec));
fin.close();

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Keep using malloc/realloc/free, for POD's you get no gain from using new/delete.

I'm surprised by David's aversion to realloc, he's usually so sensible. Smile | :)

I'm sure he realizes that vector has to do the same thing as realloc using new/delete, but much less efficiently. Just look through the vector/xmemory header files.

The next step up from malloc/realloc/free, for your case, would be to alloc your own heap (via HeapCreate) and use HeapReAlloc (which takes a flag that will zero expanded memory).

The next step up from that would be to alloc/manage your own virtual memory block. This is the method preferred by people into self-flagellation.

...cmk

Save the whales - collect the whole set

cmk wrote:
I'm sure he realizes that vector has to do the same thing as realloc using new/delete, but much less efficiently.

Not really. vector uses an algorithm to pre-buffer memory for you. That is, when it needs to resize, it doesn't just add 1 new element to the list, it increases the buffer by a % of what it currently is (50% if memory serves me correct). This decreases the number of allocations needed, so instead of calling realloc 49 times to allocation space for 50 integers, it might have to call new once and copy over the old data to the new buffer.

cmk wrote:
The next step up from that would be to alloc/manage your own virtual memory block.

Not when using C++ ... perhaps if you wanted to use pure C and manage your own memory ... but even then, that is a poor choice.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Zac Howland wrote:
vector uses an algorithm to pre-buffer memory for you

My comment still stands, when vector needs to increase the size of memory it has to alloc a new larger chunk, copy the existing members to the new block, then free the old block, same as realloc.

At _best_ this is a wash in comparison to realloc. If new explicitly touches each member in the array for POD's and sets to zero, then this would likely be less efficient than calloc. I would hope the VS compiler optimizes this step out, but i believe it would be compiler specific.

I am aware of the pre-buffer method, i use it in my container classes as well, it is a method that i would hope the OP would uses with realloc as well, but it is at a higher _level_ than the realloc discussion.

... the virtual memory comment was slightly tounge-in-cheek ... however, seeing as we are arguing ... i would say that using the virtual mem api's to manage your own alloc/realloc is good or bad depending on how it is used, it is just another tool. Using virtual mem to manage your own pool of objects of a specific type can be a huge win (in fact you could do this to create a custom alloc for vector), in most other cases i would agree that at best you would achieve performance comparable to what the Heap*() api functions provide.

...cmk

Save the whales - collect the whole set

cmk wrote:
My comment still stands, when vector needs to increase the size of memory it has to alloc a new larger chunk, copy the existing members to the new block, then free the old block, same as realloc.

At _best_ this is a wash in comparison to realloc. If new explicitly touches each member in the array for POD's and sets to zero, then this would likely be less efficient than calloc. I would hope the VS compiler optimizes this step out, but i believe it would be compiler specific.

The problem is then that you have to keep track of the memory you allocated, how much is left, if you need to reallocate this time around, etc. With vector, that is taken care of for you. I have no problem with the C memory management routines, but when using C++, you really should stick with using the C++ versions instead (and mixing them is a big no-no).

cmk wrote:
Using virtual mem to manage your own pool of objects of a specific type can be a huge win (in fact you could do this to create a custom alloc for vector), in most other cases i would agree that at best you would achieve performance comparable to what the Heap*() api functions provide.

Other than making the code non-portable, the Heap API's don't really gain you much anymore. They were useful in the Win 3.1 days, but 32-bit architectures have more or less eliminated their usefulness.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Zac Howland wrote:
The problem is then that you have to keep track of the memory you allocated, how much is left, if you need to reallocate this time around, etc. With vector, that is taken care of for you

I agree that it would be nice to use some kind of container, but for his stated use (reading a file of a bunch of ints) using vector to: read 4 bytes from file, vector.push_back, repeat, is probably the least efficient way of doing things. Allocating a big block of memory and doing a bulk read is the fastest he'll get, in which case realloc is an acceptable solution. My remarks were based on the context of his question.

Again, vector and other container types are fine for managing objects where you add infrequently, but are horrible for bulk-load ... although as a hack, he could use a vector, call reserve(), validate amount reserved, then call front() to get a reference (& for pointer), and pass that pointer to the file read function. But really, for what he needs to do, what does he gain.

Zac Howland wrote:
I have no problem with the C memory management routines, but when using C++, you really should stick with using the C++ versions instead

Totally disagree, C vs C++ is irrelevant. Using new/delete vs alloc/free is a matter of which tool is best for the job. In C++ both have a place.

Zac Howland wrote:
the Heap API's don't really gain you much anymore

I use them to create custom allocators for certain object types. Using the default new/delete for all cases will lead to memory frag issues, paging issues, thread contention issues, ... Custom allocators can create much more efficient code. The Heap*() api provides a convenient way of creating/managing these allocators. An alternative would be custom code using the Virtual mem api to do something like http://www.hoard.org/[^]

...cmk

Save the whales - collect the whole set

cmk wrote:
I agree that it would be nice to use some kind of container, but for his stated use (reading a file of a bunch of ints) using vector to: read 4 bytes from file, vector.push_back, repeat, is probably the least efficient way of doing things.

Agreed. Which is why you don't see that in the code sample I provided him. When using STL, the algorithms are your best bet 90% of the time. Chances are if you are thinking of writing a loop, you could do it better and faster using an algorithm.

As a side note, realloc suffers from the same problem unless he knows how much memory is needed at the start (in which case, you avoid the need for extra memory allocations with vector as well by using reserve). The deque container is also a good choice for this kind of operation.

cmk wrote:
Totally disagree, C vs C++ is irrelevant. Using new/delete vs alloc/free is a matter of which tool is best for the job. In C++ both have a place.

To an extent, that can be coughed up to a matter of opinion. However, when using malloc/free and new/delete mixed in the same application, you run into the potential for memory corruption (say, by calling free on something you new'd). It is just better avoided most of the time.

cmk wrote:
I use them to create custom allocators for certain object types. Using the default new/delete for all cases will lead to memory frag issues, paging issues, thread contention issues, ... Custom allocators can create much more efficient code. The Heap*() api provides a convenient way of creating/managing these allocators.

The default new/delete are designed to be a general purpose operator. They will work for most things, but yes, there are a few cases where you may want to override them. Those cases are few and far between though. I've seen far too many programmers try to "optimize" their code by overriding new/delete only to realize that memory was never their main bottleneck anyway.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

ATL Full control containing an WTL CToolBarCtrl:

I have a toolbar button with text where the text doesn't show up, and the image remains in the center.

The button has TBSTYLE_AUTOSIZE | TBSTYLE_DROPDOWN style, and the width does change with the length of the text I set, but the text itself never shows up.

WTF | :WTF:

Any ideas?

We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP

Linkify! || Fold With Us! || sighist

Probably a silly question, but does the button have the BTNS_SHOWTEXT style?

Mark

This should be necessary only if the toolbar has TBSTYLE_EX_MIXEDBUTTONS

I *think* I tried tht already, but I'll explicitelsy try again tomorrow (with all the other stuff in place)

We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP

Linkify! || Fold With Us! || sighist

peterchen wrote:
This should be necessary only if the toolbar has TBSTYLE_EX_MIXEDBUTTONS

From the SDK...

For TBSTYLE_EX_MIXEDBUTTONS:
"This style allows you to set text for all buttons, but only display it for those buttons with
the BTNS_SHOWTEXT button style"

For BTNS_SHOWTEXT:
"All buttons can have text, but only those buttons with the BTNS_SHOWTEXT button style will
display it"
"This button style must be used with the ... TBSTYLE_EX_MIXEDBUTTONS extended style"

Hopefully that's all it is Smile | :)

Mark

Hi,

I have created CRichEditBoxes using the following in VC++ MFC

vector<cricheditctrl*>RichEditBox;
CRichEditCtrl *r1 = new CRichEditCtrl;
r1->Create(WS_CHILD|WS_VISIBLE|ES_AUTOVSCROLL,
CRect(x1,y1,x2,y2), p, 1);
r1->SetEventMask(ENM_CHANGE | ENM_SELCHANGE );
RichEditBox.push_back(r1);

I get n CRichEditBoxes on the active window.
Now I want to navigate through these boxes by using Up Down arrow keys.

Can you please help
Pritha

Hi,
Please read
vectorRichEditBox;
as
vector<cricheditctrl*>RichEditBox;

This is the code I have written

Pritha

Hi,

Sorry but I am not aware how to print angle brackets on this page hence the mistake
But please read
vectorRichEditBox;
as
vector ANGLEBRACKETS CRichEditCtrl* ANGLEBRACKETS RichEditBox

RichEditBox is just a vector of CRichEditCtrl.

I hope you understand

Prithaa

didn't we answer this last week ?

either you use the default TAB key to "tab" between the controls, either you handle the WM_CHAR ( or something similar ) to process the up and down keys to navigate to te previous/next edit box.

Maximilien Lincourt
Your Head A Splode - Strong Bad

Hello,

Where should I apply the default TAB key since these boxes are not made on a dialog box but are on a window whose view is derived from CScrollView.I display CRichEditBoxes on this view window.
Where do I use WM_CHAR ?
Since any messages if written in the view class then message for the view window is handled but not for the vector of editboxes which are placed on the window.

please guide

Prithaa

prithaa wrote:
Where do I use WM_CHAR

In your CRichEditCtrl-derived class. Note that you won't be able to insert tabs into your
rich text if you capture the tab key presses Smile | :)

You could send/post a message to the parent view window which then uses the vector to find the
next Rich Edit control to set the focus to.

Mark

prithaa wrote:
vectorRichEditBox;

You messed this up last time, too. Use the < and > button about the emoticons.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

Hi,
Sorry to have messed with < > signs

I tried using WM_CHAR in the class derived from CRichEditCtrl but the control doesn't go the LButtonDown function which I wrote in the derived class.
so when I press a key inside the CRichEditBox where does the control go .

Can you please guide.

Prithaa

Hi,

Sorry to bother you.

but for now the problem is solved and I was able catch the LButtonDown message with your suggestion.

Thanks

Prithaa

prithaa wrote:
but for now the problem is solved and I was able catch the LButtonDown message with your suggestion.

That's great, but I did not offer any suggestion other than to make your code more readable.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

In this existing MFC application, what I want to do is this: once a user clicks on the print button in the main dialog, I want to get the page number currently displayed in the static webbrowser control, check for the corresponding pdf file in the file system and print that pdf file rather than the html file. I'm not sure how to do this. I was thinking of first creating a CDocument object and attaching a view to enable printing, but found out that I can't pass the filename of the document to open in CDocument. Please help!!!

Hello all,

I am writing a MFC program and I have to display a message like "Processing, please wait" in a box, and the close it from the program when the processing is finished. I don't want the user to be able to close the box in any way: no "Close" button or "X" button.

Ah! you'll say. Use a progress bar!
I can't! I perform the processing with a Perl script which I call with a shell command from the programm so I don't have information on its progress. I can't only wait for it to finish.

Any idea?

Giulio

See if this helps.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb