|
The maximum size of a character buffer is what your software specifications specify! If your application needs a buffer to handle 10 bytes of data, there is no need to allocate 2KB of memory. The maximum size that you can allocate depends on the type of memory management being used.
[Stack]
In Win32, your stack starts at 1MB, so depending on how your code works and where it is being called, you may be able to allocate much of that on the stack. Grabbing 32KB from the stack is generally nothing unless you are dealing with recursive functions.
[RTL Memory Management]
Allocating from the standard RTL heap imposes other limits, and these limits may be platform-specific. For example on Win9x, you can only allocate a bit less than 256MB using the RTL allocation routines (this is a limitation of HeapAlloc(...) on Win9x).
[Win32 Memory Management]
You can manage larger amounts of memory using things like VirtualAlloc(...) , or using a memory-mapped file. You can also run into address space exaustion when dealing with really large amounts of memory, but this is soemthing the average developer does not experience - at least, not unless they have a serious bug somewhere...
The important thing to ask is how much memory do you need? Some developers will scoff when they see something that they believe to be arbitrary buffer sizes of 32, 64, 128, 256, etc., but these limits are specified by the requirements of the software. If your program needs a Username , and the specifications state that Username shall be limited to 31 characters, a character buffer size of 32 is perfectly fine.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR> If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong! Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road! See DeleteFXPFiles
|
|
|
|
|
James R. Twine wrote: The maximum size of a character buffer is what your software specifications specify!
That is one of the most ridiculous statements I have ever read. Beyond that you give a lot of useful information.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
Thanks... I think...
Why is that ridiculous? I know that it implies that you should have software specifications that [1] exist and [2] are accurate, but...
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR> If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong! Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road! See DeleteFXPFiles
|
|
|
|
|
Modern day OSs and hardware give you a lot more leeway than they use to, but the limitation is still determined by the hardware and not by the software specifications. I could specify in the software specification that a terabyte was require for the buffer size, but if the hardware can not provide that then the specification becomes meaningless. Software specifications are limited by the hardware, not the other way around.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
OK - I see your POV.
I was speaking in general terms - there is no need to worry about whither my hardware can handle an allocation of 2GB if I only need 32 bytes at any one time.
To offer a different POV, the software specifications dictate the hardware. If my software uses 100MB of allocated memory, then I need hardware that can handle that. I rarely encounter a software specification that starts with a hardware requirement unless dealing with a fixed/embedded/mobile system. IME, hardware requirements generally change during the development lifetime of a product for a variety of reasons (performance requirements, feature-creep, etc).
If I am ever given software specifications that state that I need to allocate a terabyte of memory(!), I better come up with suitable hardware and an addressing scheme to handle it!
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR> If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong! Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road! See DeleteFXPFiles
|
|
|
|
|
Thanks, I am glad you understand.
In the world I learned to program in the PC was very limited and every byte counted. At one point I had to write my own virtual memory manager (even with extended memory) to squeeze a little more out of it. When I wrote firmware (Z80) I had to balance the stack size against the number (size) of global variables, so that the stack did not start stepping on the globals. That also related to how much functionality you could code in because that space was limited too. I pushed it to the limits, another 16-bytes or so and the whole thing would probably fall apart. The limitations of the hardware was not something that could be adjusted, I had to work within the limitations that it gave me.
I love modern machines because I have not even seen the wall yet and have been ignoring the fact that I know it is there somewhere.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
On a side note, why use macros when enum s will work just as well? Better in fact. For example try doing this with macros:
void Function1()
{
enum { buffersize = 1024 };
char buffer[buffersize];
}
void Function2()
{
enum { buffersize = 2048 };
char buffer[buffersize];
}
The problem with macros in this context is that they don’t obey C/C++ scoping rules. Using macros to define constants is old fashioned and should be avoided.
Steve
|
|
|
|
|
I want to list all the directories in a folder including the hidden dir's.Which function to be used?
Thanks..
|
|
|
|
|
Use CFileFind .
CFileFind finder;
BOOL bWorking = finder.FindFile(L"*.*");
while (bWorking)
{
bWorking = finder.FindNextFile();
if (finder.IsHidden())
{
}
}
|
|
|
|
|
How about the FindFirstFile() /FindNextFile() pair?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
|
I need to display the file open dialog and browse directory dialog at the center of the screen. it's display right now at the top left corner ,can any body help me to display it at the center.
is there any realation with my main application window. Because the mainwindow is not display at center of screen now.
Amit
|
|
|
|
|
amitmistry_petlad wrote: I need to display the file open dialog and browse directory dialog at the center of the screen
Use CWnd::CenterWindow .
|
|
|
|
|
But Master, it's WIN32.
aMIT
|
|
|
|
|
Oh ! I guess, you had asked same question few days back[^]. And I'll answer same thing agains, Look, how CWnd::CenterWindow is implemented.
Code for above function I'm pasing,
void CWnd::CenterWindow(CWnd* pAlternateOwner)
{
ASSERT(::IsWindow(m_hWnd));
DWORD dwStyle = GetStyle();
HWND hWndCenter = pAlternateOwner->GetSafeHwnd();
if (pAlternateOwner == NULL)
{
if (dwStyle & WS_CHILD)
hWndCenter = ::GetParent(m_hWnd);
else
hWndCenter = ::GetWindow(m_hWnd, GW_OWNER);
if (hWndCenter != NULL)
{
HWND hWndTemp =
(HWND)::SendMessage(hWndCenter, WM_QUERYCENTERWND, 0, 0);
if (hWndTemp != NULL)
hWndCenter = hWndTemp;
}
}
CRect rcDlg;
GetWindowRect(&rcDlg);
CRect rcArea;
CRect rcCenter;
HWND hWndParent;
if (!(dwStyle & WS_CHILD))
{
if (hWndCenter != NULL)
{
DWORD dwAlternateStyle = ::GetWindowLong(hWndCenter, GWL_STYLE);
if (!(dwAlternateStyle & WS_VISIBLE) || (dwAlternateStyle & WS_MINIMIZE))
hWndCenter = NULL;
}
MONITORINFO mi;
mi.cbSize = sizeof(mi);
if (hWndCenter == NULL)
{
HWND hwDefault = AfxGetMainWnd()->GetSafeHwnd();
GetMonitorInfo(
MonitorFromWindow(hwDefault, MONITOR_DEFAULTTOPRIMARY), &mi);
rcCenter = mi.rcWork;
rcArea = mi.rcWork;
}
else
{
::GetWindowRect(hWndCenter, &rcCenter);
GetMonitorInfo(
MonitorFromWindow(hWndCenter, MONITOR_DEFAULTTONEAREST), &mi);
rcArea = mi.rcWork;
}
}
else
{
hWndParent = ::GetParent(m_hWnd);
ASSERT(::IsWindow(hWndParent));
::GetClientRect(hWndParent, &rcArea);
ASSERT(::IsWindow(hWndCenter));
::GetClientRect(hWndCenter, &rcCenter);
::MapWindowPoints(hWndCenter, hWndParent, (POINT*)&rcCenter, 2);
}
int xLeft = (rcCenter.left + rcCenter.right) / 2 - rcDlg.Width() / 2;
int yTop = (rcCenter.top + rcCenter.bottom) / 2 - rcDlg.Height() / 2;
if (xLeft < rcArea.left)
xLeft = rcArea.left;
else if (xLeft + rcDlg.Width() > rcArea.right)
xLeft = rcArea.right - rcDlg.Width();
if (yTop < rcArea.top)
yTop = rcArea.top;
else if (yTop + rcDlg.Height() > rcArea.bottom)
yTop = rcArea.bottom - rcDlg.Height();
SetWindowPos(NULL, xLeft, yTop, -1, -1,
SWP_NOSIZE | SWP_NOZORDER | SWP_NOACTIVATE);
}
|
|
|
|
|
ya i am in proccess of modifing that one . Is it real need to make the main screen in the center for display the system window in center?
|
|
|
|
|
amitmistry_petlad wrote: Is it real need to make the main screen in the center for display the system window in center?
Actually, If you had a look at CWnd::CenterWindow , it has flexiblity to decide the window, which should be considered for centering window in question. By default its desktop window.
John R. Shaw has shown you code snippet, having similar logic, which will center the window.
|
|
|
|
|
Interesting but the question had to do with centering to the screen and not some unknown window. Also they specifically said Win32 and not some function that depends on MFC.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
I think, you has not read my reply carefully. In my first reply, I suggested to use CWnd::CenterWindow . After that, OP indicated, he is using win32 api. So, I simply shown him how this function is implemented using win32 Api. And while implementation, its taken care of considering both possiblities.
John R. Shaw wrote: Also they specifically said Win32 and not some function that depends on MFC.
In original post, he has not mentioned No MFC this.
|
|
|
|
|
1) I did read your reply carefully and the function you showed him is not using the Win32 API directly. What you showed him was a function that depended on MFC and C++. The Win32 API does not depend on MFC and I believe it is written in C and not C++, as are all of the Windows operating systems before it. Your code starts off with a C++ name and contained lines with function calls like “Afx…”; no matter how you look at it those are not Win32 API call, they are MFC calls.
2) True he did not mention ‘No MFC’ in the original post, but the one you gave an answer to said “But Master, it's WIN32.”.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
John R. Shaw wrote: not using the Win32 API directly
Again, let me explain, what I tried to explain, I told him, see how CenterWindow is implemented, And I just pasted code , how it's defintion. So it was up to OP to extract solution from it(and there are win32 api's used there).
|
|
|
|
|
Yes I see your point.
You are applying the concept of working backwards; which I have used often. I was approaching it from the Win32 (C code) point of view. I did suggest that he create a small program using MFC and then work backwards to see how they did it, using the code browser. MFC hides a lot of things and unless you know what it is hiding then it is hard to determine what a piece of it is doing.
We where approaching the problem from opposite directions. I try to answer the questions (from memory) at the level from which they were asked. If you look further down in the posts (the one with no replies) you will see my center window solution. The only problem with it is that you need a handle to the window; which common dialog boxes do not give you unless you over ride (hook) the class (not a C++ class) and create them directly.
I do know where you are coming from and apologize if you thought otherwise.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
John R. Shaw wrote: If you look further down in the posts (the one with no replies) you will see my center window solution.
I saw that, and suggested OP to refer[^] it.
John R. Shaw wrote: The only problem with it is that you need a handle to the window;
I think, that very obvious, without window handle, its very difficult to operate on window.
John R. Shaw wrote: which common dialog boxes do not give you unless you over ride (hook) the class (not a C++ class) and create them directly.
I suggested him to handle it in HookProc[^].
John R. Shaw wrote: I do know where you are coming from and apologize if you thought otherwise.
Never mind, it bound to happen, due to communication mismatch.
Anyway, nice to have this communication.
|
|
|
|
|
You funny! LOL
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
Thanks !
My main application window screen is now in center but the browse file and brwose
directory dialog is still display the dialog in the upper left corner.For that I have did the same thing but it is unable to handle.
becuse of this is a structure so for that how can I use this one for dispaying the fileopen dialog
in the center?
OPENFILENAME ofn;
I have passed the owner window but I think its not helpful me..????
Window_Center(ofn.hwndOwner);
GetOpenFileName(&ofn);//When this will open the dialog it must in the center. but its not working.
how can this works ?
Amit
|
|
|
|
|