Sam Varshavchik replied me in the "C++ professionals group" forum on LinkedIn. Based on his information, I resolved this issue.
The below was his comment.
Modern CPUs have no "memory alignment" issues. In the worst case scenario, the CPU will burn a few extra cycles fetching an adjacent memory word, to execute the instruction or fetch the data. No impact on the application, except for it taking a few ticks of the clock to complete.
Memory alignment issues were often an issue with older CPUs, such as the earlier versions of the Motorola 68K CPU family, where attempting to fetch a word at an odd address caused a trap. Modern CPUs just deal with this by burning more fuel, no harm done. Whatever your problem really is, a "memory alignment" issue would be on the bottom of my list of suspects.
The symptoms being described -- adding a debug statement making an apparent error go away -- often happen as a result of subtle memory corruption; such as wild pointer dereferencing, using memory after it's been freed, etc... Adding some debug statements does not really fix anything, it merely masks the bug. Many times, effects of memory corruption are very sensitive to the layout and the internal arrangement of the code in the final executable. Often, one might think that adding an innocuous debug statement magically fixes their problem, only to see things come crashing down hard, after making some other innocent change to some completely unrelated part of the same application.
There is no universal answer how to fix this, or where the problem is. Roll up your sleeves, it's old-fashioned debug time.
I often found a lot of valuein a memory instrumentation and usage checker. For MS-Windows, your apparent platform, Purify is a popular tool for pin-pointing where things go astray. On Linux, I find valgrind to be indispensable, and worth every penny of its no-cost. Very often it began screaming at me about bugs in my code that I didn't even know about, yet!
Of course instrumenting code changes its runtime behavior, and might also have unpredictable results that depend on the timing of its execution -- especially with multithreaded applications. Can't win them all.
I do not have the IBM Rational Purify tool (IBM asked me to register a user account), but I downloaded and installed the 30-day trial version of Intel Parallel Inspector 2011. It reported about 30 memory errors: most of them were in the built-in source code of Visual C++ 2010, but one occurrence was in my project source code. I looked some lines back before this line, initialized a DWORD variable with value 0 (the DWORD dwFilter in the code snippet below), and this issue is resolved.
I am currently reviewing many programs I wrote for Windows 2003/2000 where I call the NetServerEnum Function to enumerate all the servers in a domain. Calling the NetServerEnum Function is dependant on the Computer Browser Service (NETBIOS) running on a Domain Controler in the specified domain. In Windows 2003, this service was on by default.
In a Windows 2008 built domain, Microsoft has decided to disable the Computer Browser Service (NETBIOS) on all windows 2008 machines. This means that if your domain controller is windows 2008, the NetServerEnum Function will not work at all. Enabling the computer Browser Service on the Windows 2008 Domain Controller and setting it to Automatic will solve the issue.
In a quest to update my code to avoid having to start services on domain controllers, does anyone have, or know of another function that can enumerate servers on a windows 2008 based domain that is not based on Netbios calls. I am prgramming in VC++.
but how to do that myself i know that using NULL brush on the WM_PAINT draws the window transparent but just it does that draws a no fill rect, so i can see the back of the window but just the moment it gets drawed, so i am thinking of using a timer but that is not efficient can someone they me how i can do it myself without libraries?
OnPaint() is the method that the MFC infrastructure calls to draw the screen, that would be the appropriate override for this, if you do it there, it should do it the same every time, if you need to get the screen redrawn at any time, just invalidate it and MFC will once again go to OnPaint() to redraw.
I was making exercise 4.23 from C++ essentials and ended up with this code:
double Sum (int n, double val ...)
doublevalue = val;
double result = 0;
double n = Sum(3, 2, 2, 2);
cout << "Result: " << n;
It compiles fine and when i do the call "Sum(3, 2, 2, 2)" it just prints "Result: 6" but when i call "Sum(3, 2.1, 2.0, 2.0)" it prints "Result: 6.3" while it should print 6.1, right? What am i doing wrong? D: thanks! btw, the solutions the book provides aren't working...
I do wonder why the authors thought to dig up one of the worst elements of the Dark Ages Of C in a work called 'C++ essentials'! If this was labelled 'C++ complete' or something like that I'd grudgingly admit that this is still part of the language and as such belongs here. But the term 'essentials' indicate that everything in there is required for desgning good C++ code. Yet the opposite is true in this case!
While streams may be harder to implement and use, they are much safer, and provide the full functionality of varargs. The only reason to use them in a C++ program is for the purpose of interpreting arguments in a command line application. (and it's sad that the C++ standards committee never thought to provide a better interface for that purpose!)