|
I'm writing a file manipulation program, and was wondering in your experience what is the most efficient buffer size to load at a time and manipulate. Would this simply be based on the largest chunk of memory I am willing to allocate on the system, or can smaller buffers produce faster results? Speed is important because I could be converting several thousand files at a time.
Thanks,
Dustin
|
|
|
|
|
How much overhead would it be to first iterate the list of files, look for the largest file, and allocate that much memory?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
The biggest problem would not neccesarily be the overhead, but the allocation itself. What happens if I run accross a 2GB file? I'm actually attemting to write an encryption program, more as an experiment than anything, and do not know the make up of the files I will be opening.
|
|
|
|
|
Dustin Henry wrote: What happens if I run accross a 2GB file?
Indeed that would be a problem.
Dustin Henry wrote: I'm actually attemting to write an encryption program...
What does the encryption algorithm require (in terms of input)?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I am actually using my own random number generator to randomly convert each byte of data based on an initial seed, so the only requirement is that I process the data in order.
|
|
|
|
|
Then I don't see why you couldn't allocate a couple of megabytes for that.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
So basically the bigger the better then?
|
|
|
|
|
To a point, but you don't want to get so big that you introduce more disk thrashing. Allocating several MB of memory is not usually noticeable with semi-modern machines.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Great, thanks for your help David.
|
|
|
|
|
(I feel dumb this morning, really, really dumb; you have the right to giggle )
I'm trying to set the initial dir of a CFileDialog to an existing path.
if I do this it works; but the path is not hardcoded like that.
CString sInitialPath("c:\\max\\");
CFileDialog dlg( FALSE, NULL, "toto.ext");
dlg.GetOFN().lpstrInitialDir = sInitialDir;
The path is taken from an Edit Box.
CString sInitialPath;
m_EditBox.GetWindowText( sInitialPath );
CFileDialog dlg( FALSE, NULL, "toto.ext");
dlg.GetOFN().lpstrInitialDir = sInitialDir;
And this does not work because the string contains single backslash ( c:\max ) and letters will be "escaped" out of the string.
There must be a better way than manually add backslash to the string ?
Is there a default "cleanup" function that will do it ?
Thanks.
(again you can have a laugh.)
|
|
|
|
|
Off the top of my head you may want to try this:
sInitialPath.Replace(_T("\\"), _T("\\\\"));
Dustin
|
|
|
|
|
The above replacement make sense only whenever the string has to be read by the compiler.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
He wanted double slashes, I gave him double slashes. You don't actually expect me to consider the logic of my statements do you?;P
|
|
|
|
|
Dustin Henry wrote: You don't actually expect me to consider the logic of my statements do you?
ehm... No, of course!!!
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Maximilien wrote: CString sInitialPath;
m_EditBox.GetWindowText( sInitialPath );
CFileDialog dlg( FALSE, NULL, "toto.ext");
dlg.GetOFN().lpstrInitialDir = sInitialDir;
Uhm, there's a mistake in the last line, you should do instead
dlg.GetOFN().lpstrInitialDir = sInitialPath;</code>
BTW in the meanwhile I'm trying the code...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
As supposed, the following (yours, basically) code works fine on my system (dlg.m_ofn is there because I'm using VC6).
CString sInitialPath;
m_EditBox.GetWindowText( sInitialPath );
CFileDialog dlg( FALSE, NULL, "toto.ext");
dlg.m_ofn.lpstrInitialDir = sInitialPath;
dlg.DoModal();
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Maximilien wrote: ...the string contains single backslash ( c:\max ) and letters will be "escaped" out of the string.
This is only the case with string literals.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
that's strange, because escaping a backslash matters only in the source code... if the user enters in the edit box a path (which is for him compound of sigle slashes of course), that will behave as if you had written in your source code the path with '\\' characters...
and same in the debugger. it does display single slashes, but look at the ascii code of the characters, and you'll see that no way you need (and you musn't !!!) replace single slashes with double ones...
but i can't help you much, because i have no compiler with me at the moment...
|
|
|
|
|
toxcct wrote: that's strange, because escaping a backslash matters only in the source code... if the user enters in the edit box a path (which is for him compound of sigle slashes of course), that will behave as if you had written in your source code the path with '\\' characters...
Definitely true .
toxcct wrote: but i can't help you much, because i have no compiler with me at the moment...
I had it and made the attempt [^], [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
|
Question about the 'this' pointer and properly returning a reference to an object.
I am learning about OOP and working through some examples. One of the examples has me overloading the *= operator.
<br />
CRegister& CRegister::operator *=(const CRegister &rhs)<br />
{<br />
this->m_dStore *= rhs.m_dStore;<br />
return *this;<br />
<br />
}<br />
I have two questions, why does an overloaded operator need to return a reference to the lvalue? Second if I did want to return the address of the lvalue shouldn't the code look like this?
<br />
CRegister& CRegister::operator *=(const CRegister &rhs)<br />
{<br />
this->m_dStore *= rhs.m_dStore;<br />
return &this;<br />
<br />
}
Or because 'this' is a pointer, by returning '&this' am I creating a second level of indirection, because i don't want the address of the 'this' pointer, but rather the address that the 'this' pointer points to?
Thanks guys,
Joe
|
|
|
|
|
TheDelChop wrote: why does an overloaded operator need to return a reference to the lvalue?
In fact an assignment operator (like *= ) must return a l-value .
TheDelChop wrote: Or because 'this' is a pointer, by returning '&this' am I creating a second level of indirection, because i don't want the address of the 'this' pointer, but rather the address that the 'this' pointer points to?
Your guess is right. this is a pointer to the object itself, *this is a reference to the object itself.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: TheDelChop wrote: why does an overloaded operator need to return a reference to the lvalue?
In fact an assignment operator (like *=) must return a l-value.
No, it doesn't. It can return anything or nothing. The only requirement is that it takes two arguments: if it's a global function (usually a friend function) two explicit arguments, at least one being a user defined type; if it's a member function the this pointer is the first implicit argument and the second must be explicitly supplied. In most common usages the return type is a reference to the class to which the operator belongs, but this is not a requirement.
Steve
|
|
|
|
|
Stephen Hewitt wrote: CPallini wrote:
TheDelChop wrote:
why does an overloaded operator need to return a reference to the lvalue?
In fact an assignment operator (like *=) must return a l-value.
No, it doesn't.
At least, it should (MSDN on assignment operator):
The operator returns the object to preserve the behavior of the assignment operator,which returns the value of the left side after the assignment is complete. This allows writing statements such as:
pt1 = pt2 = pt3;
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
CPallini wrote: The operator returns the object to preserve the behavior of the assignment operator,which returns the value of the left side after the assignment is complete. This allows writing statements such as:
pt1 = pt2 = pt3;
As I said – this is normally the case (returning a reference) – but not a requirement as you suggested.
Steve
|
|
|
|