|
Well, I tried to. I have to prefix this "\\?\" to the path right? In C the prefix would be written as "\\\\?\\". This produces the exact same results.
<br />
strPattern = "\\\\?\\" + m_folder;<br />
<br />
if (strPattern.Right(1) != TEXT("\\") )<br />
strPattern += "\\";<br />
strPattern += "*.*";<br />
hFind = ::FindFirstFile(strPattern, &FindFileData);
Any ideas?
|
|
|
|
|
skullfire wrote: Any ideas?
No, sorry. 
--
Simulcast on Crazy People's Fillings
|
|
|
|
|
skullfire wrote: I have to prefix this "\\?\" to the path right?
No. You do not have to add the prefix. Just go to your project settings and change your project to using UNICODE.
And you have to change all string constants in your program to wide char strings, i.e., "*.*" should be replaced with L"*.*", unless you are using the TEXT macro like:
skullfire wrote: if (strPattern.Right(1) != TEXT("\\") )
|
|
|
|
|
Currently I have a working example code (VC++ 8) for Win32 platform which uses WinPcap libraries. Does anybody know how to change the platform to Pocket PC 2003? Do I have to have WinPcap libraries for Pocket PC?
Yinyan Wang
|
|
|
|
|
Hi,
How do I send message to the parent window to move a cursor from one point to another
Any ideas please
Prithaa
|
|
|
|
|
Move the mouse cursor? SetCursorPos()
Move the "text cursor" (caret)? SetCaretPos()
Does the parent need to do this?
Mark
|
|
|
|
|
Hello,
Yes ,I need to send a message to the parent to move the keyboard cursor
Thanks
Prithaa
|
|
|
|
|
Hi
I am using _popen to execute an exe file and read back the result in to a text file and analyze it. but from the time that user clicks the button the console window appears on the screen and goes away when the process is finished. how can i hide the console window from the user and show something like work in progress instead.
is there a way to hide _popen ?
char Buffer[9];<br />
string commandline="address";<br />
<br />
FILE *fp;<br />
<br />
if ( (fp= _popen(commandline.c_str(),"r"))==NULL)<br />
exit(1);<br />
<br />
fgets( Buffer, 9, fp );
|
|
|
|
|
mitil20390482304 wrote: I am using _popen to execute an exe file...
To create a Windows application that redirects input and output, read the section "Creating a Child Process with Redirected Input and Output" in the Win32 SDK. See here and here.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
thanks man..i have already read those,,,and I have a really hard time undrestanding how i can use it in my case...can you help me some more...how can i run my _popen inside a process that has a hiden window?
|
|
|
|
|
|
Hi good people,
I was wondering if anyone could help me with a error i keep getting?
I have variable - int Size;
That i wish to parse to a function by reference that receives a int value.
However, i keep getting the following error message,
"cannot convert parameter System::Drawing::Size to &int"
If I parse it by value i get the same message just without the & "ampersand".
Please Help,
Thanx everyone
Phoenix
|
|
|
|
|
Phoenix101 wrote: That i wish to parse to a function by reference that receives a int value.
Pass-by-reference means to pass the variable's address (i.e., a pointer), like:
void foo(int *num)
{
}
...
int abc;
foo(&abc);Pass-by-value means to pass the variable itself, like:
void foo(int num)
{
}
...
int abc;
foo(abc);Lastly, if the function is expecting a reference, use:
void foo(int &num)
{
}
...
int abc;
foo(abc);
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Hey Good People,
I found the solution to the error...
It turns out that Size is a reserved word or something.
I changed it to size and it parsed without any errors.
Thanx everyone for your help;)
Phoenix
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
