|
Phoenix101 wrote: cannot convert parameter System::Drawing::Size to &int"
That looks like C++/CLI to me.
|
|
|
|
|
I want to read a file containing unknown number of integers and store all the values to an array. I was using (in C) malloc/calloc for first allocation and and realloc subsequent allocation of memory to the array. In the process I could keep the values assigned intact while expanding the size of the array. Now I have started using C++ where I use the operator 'new' for allocation of memory. Is there any function equivalent to 'realloc' so that I can do the above thing?
|
|
|
|
|
pani68 wrote: Is there any function equivalent to 'realloc' so that I can do the above thing?
No, and thank goodness. See here for my comment. If you are now using C++, use a vector to hold the numbers.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
#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. 
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.
 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
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.
|
|
|
|
|
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
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
