C / C++ / MFC

mitil20390482304 wrote:

I am using _popen to execute an exe file...

Phoenix101 wrote:

That i wish to parse to a function by reference that receives a int value.

void foo(int *num)
{
}
...
int abc;
foo(&abc);

void foo(int num)
{
}
...
int abc;
foo(abc);

void foo(int &num)
{
}
...
int abc;
foo(abc);

Phoenix101 wrote:

cannot convert parameter System::Drawing::Size to &int"

pani68 wrote:

Is there any function equivalent to 'realloc' so that I can do the above thing?

#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();

cmk wrote:

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

cmk wrote:

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

Zac Howland wrote:

vector uses an algorithm to pre-buffer memory for you

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.

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.

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

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

Zac Howland wrote:

the Heap API's don't really gain you much anymore

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.

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.

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.

peterchen wrote:

This should be necessary only if the toolbar has TBSTYLE_EX_MIXEDBUTTONS