|
John R. Shaw wrote: If anyone ever tells you that they can do something in C++ that you can not do in C, tell them to go suck a rotten egg.
Are you sure about this, I can agree with you that one can write any program in C if its written in C++, but aren't there some features in C++ which can't be simulated in C ?
I know that one can simulate polymorphisme in C, its hard, its hard coded for that matter but still doable. But I don't know if everything is possible?
codito ergo sum
|
|
|
|
|
Well I used to do public and private (private being hidden entirely), but I could not see how to do protected. Hard-coding inheritance is not really worth the effort, but is doable.
There are other ways to simulate other features of C++ in C, but they are all a pain.
Think about this: The original front end for C++ converted the C++ code into C and then passed the C files to a C compiler and linker.
I think, Bjarne Stroustrup first proposed using macros for creating templates instead of a separate mechanism. This was something I had done in the passed (in C) and is very doable.
I do not know if the majority of OSs are still written in C, but I suspect they still are.
None of the above really matters though; the point was that any application that is written in C++ can be written in C. It is just harder to do, because nothing is hidden (normally) and you have to be more careful (be more responsible). On the plus side, when you make a function call in C you know it, which cuts down on surprises.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
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 enums 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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
