|
Personally I've been avoiding MFC wherever I could for at least the last 10 years. That said, I'm probably not the best person to ask about it's current state in version 11. 
I do know however, that the MFC never changed their abysmal design of event handling functions: I just say two words: LPARAM and WPARAM. The need to convert and sometimes split up and reinterpret parts of these event parameters is assembler level coding; it's type-unsafe, prone to errors and misunderstanding, requires a thorough understanding to do right, the resulting code is difficult to maintain, and likely breaks when you switch from 32-bit to 64-bit.
There are both free and commercial frameworks available if you're looking for an alternative. QT and CodeJocks XTreme ToolKit Pro come to mind. But you can easily find more on the web.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Assembler level coding? ...that's a bit of an exaggeration... it's C-style coding. As far as 32 vs. 64 bit assemblies, well a lot of things break when that happens, so you're not likely to find a universal answer there anyway.
|
|
|
|
|
I think a very useful reaction. Just because of the flexibility to use ANSI and Unicode and prepare for 32-bit and 64-bit alongside, it turned out to be wise to take MFC (and ATL). I understood MFC and ATL are more or less integrated and coupled now.
To be critical on the role of Microsoft is wise to. Meanwhile (2018) the version for MFC is 14.
Newer versions of Visual Studio aren't linked to new versions for MFC anymore.
But … hate to say … sometimes the one you criticize (or criticizes you)... has right.
For example the preparation for Unicode wasn't understood by a lot of MFC-users (for a long time including me). I'm sure it even gave MFC a bad reputation. What the hell with … CString, TCHAR, LPCTSTR, LPTSTR, TEXT, etc. ???
The level of understanding of preprocessors has to be high. So even more people will drop out as fans for MFC. My level of understanding of preprocessors is very modest.
Some quick testing showed that MFC can be used 64-bit still. The CDAO... classes might be an exception. Although the MS communication on DAO in general was kind of an example of a large dragon with two heads (or even more) speaking with 2 mouths and thus speaking the truth always … or never. I didn't test, but perhaps those CDAO... classes can be used in 64-bit code as well. Let's be aware of the fact that 64-bit compilers are often 32-bit programs themselves. The IDE for 64-bit development … is often 32-bit. Real programmers have to laugh for the request for 64- bit software, because of the belief that for sure that will be faster. Even Microsoft again turns out to be that multi-mouth-dragon. Some people hope to sell us new 64-bit software … because of …
In my humble opinion MFC can be used seamingly alongside raw Win32 code. Many may smile now. It comes close to the contra for MFC being it just a little wrapper around Win32. It can be used seamingly alongside managed code of NetFramework, although I prepare for disappointments for years already. For many developers that sounded as crazy sadomasochism.
How many developers understand (and use!) the concept of deployment with debug-builds and runtime support with surveillance tools at site with the customers ? Do developers have to prepare for that before compile-time ? Do developers have to prepare for testing ? As a developer my ego tends to shrink and shrink.
To hear experiences from others is still welcome. I still use MFC but still … critical … I hope.
|
|
|
|
|
I have a solid guess, that it is a bug in compiler. Look at the next code:
int xmin=max(xl1, max(xl2, xl3));
It works fine in the debug version, but gives me some nonsense in the release one. At that very time this variant works properly in both versions:
int xmin=xl1;
if(xmin<xl2)
xmin=xl2;
if(xmin<xl3)
xmin=xl3;
Any idea how could it be?
|
|
|
|
|
a_matseevsky wrote: but gives me some nonsense in the release one
What about providing some input/ouput in order to show us the nonsense?
Veni, vidi, vici.
|
|
|
|
|
OK, but I do not think, that it will make you happier.
As a matter of fact, there was two similar lines of code:
int xmin=max(il1, max(il2,il3));
int xmax=min(ir1, min(ir2,ir3));
The right variant was xmin=80, xmax=262.
Wrong variant, presenting only in release version, was the next:
xmin=76, xmax=38.
-- modified 16-Jan-14 20:37pm.
|
|
|
|
|
Actually it would make me happier, anyway you did not provide the input values.
Veni, vidi, vici.
|
|
|
|
|
Have you defined your own version of max() or are you using the one provided in some windows header? If the former, try commenting out that function and see if it still compiles in debug and/or release. If the latter, try defining your own function and see if it does compile in debug and/or release.
As an alternative to either of the above you can try and #define NOMINMAX before including windows.h . This will prevent the macro definitions for min() and max().
These suggestions are based on the fact that MS provides macros for min() and max() in some Windows header, and that these macros might mess up code in unexpected ways. I know it did break std::valarray::min() and std::valarray::max() in VS 2003, and it did break std::min and std::max in later versions, until MS eventually fixed it.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Thanks, boys, for yours comments, but I've just found the reason. And it did not make me happy. Really, great knowledge means great pain. Look at this small part of a stack frame:
_lrct$ = -212 ; size = 16
tv5476 = -204 ; size = 8
Do you see something interesting here? A RECT structure of size 16 bytes and something too close to it- in fact, variable tv5476 partially overlaps RECT. And what command
fst QWORD PTR tv5476[ebp]
does? It rewrites half of my RECT. I can only hope, that it is the bug in my own Visual Studio. I'll reinstall it- may be, it will help (once I met something like tis- a "new" operator refused to work at all and re installation resolved this situation)
|
|
|
|
|
I think you are reading that the wrong way round. The variable tv5476 is 8 bytes long starting at offset -204, so it goes from -204 to -212. The variable _lrct$ is 16 bytes from -212 to -228. Your problem is much more likely to be a bug in your code that only shows up in the release version, and that is far from uncommon.
[edit] OK, my shoulders are broad enough to admit that I was wrong with that first statement. Lack of coffee/gin. [/edit]
Veni, vidi, abiit domum
modified 17-Jan-14 12:11pm.
|
|
|
|
|
Richard MacCutchan wrote: Your problem is much more likely to be a bug in your code that only shows up in the release version, and that is far from uncommon.
Yes. 
However his actual code, like his I/O values are 'top secret'.
Veni, vidi, vici.
|
|
|
|
|
Veni, vidi, abiit domum
|
|
|
|
|
You, boys, made my face red. Not because of me- you even do not know assembler. Command like
mov [ebp-4], eax
rewrites bytes from [ebp-4] UP to [ebp-1] .
Just as fst QWORD PTR [ebp-204] does.
RECT was allocated at [ebp-212], therefore its 16 bytes occupied addresses from ebp-212 to ebp-196.
So simple. And aforementioned fst overwrote half of them. And BTW, I saw the whole process under debugger. My recommendation- any boy, who pretended to be a pro, must know assembler. I know what the mainstream in programming is- to replace pros by cheap yesterdays scholars. And it really does not me happy.
|
|
|
|
|
Jolly good for you. You obviously won't need any help from us in the future then.
Veni, vidi, abiit domum
|
|
|
|
|
I need help. Question is, if any of you can give me some more or less valuable tip. When I asked my question the first time, I was not sure, that a bug really presents in Visual Studio. Now I know it. Problem is, what I have to do in such sorrowful situation. If someone else met such problem and fixed it, such person could share his experience. May be, this bug presents only in my own exemplar of Visual Studio- may be, it was damaged in some way and produces code with defects- in such case re-installation will solve this problem. Or such bug presents in each exemplar of Visual Studio 2005- in such case, I have to throw it away and buy 2008 or 2010. I know about a bug in Borland's compiler.
|
|
|
|
|
a_matseevsky wrote: I need help.
Then you could start by showing the actual code that is going wrong, as raised in your original question. Also you need to show the exact values of the variables that cause the problems, and the actual and expected result values.
Veni, vidi, abiit domum
|
|
|
|
|
I did it. Problem was caused by incorrect allocation of local variables in stack frame. This is what I hardly can change- it is a bug in compiler. The only important fact is that one value was replaced by another. Exact values of variables here mean nothing.
|
|
|
|
|
If you continue to refuse to provide the information we have asked for, then there is no way we can offer any suggestions as to what may be wrong. If you are convinced that this is a compiler bug then you should collect all the information and send it to Microsoft.
Veni, vidi, abiit domum
|
|
|
|
|
I clearly demonstrated, what cased problem in particular. I can repeat it again.
There was two local variables:
_lrct$ = -212 ; size = 16
tv5476 = -204 ; size = 8
The next command rewrites 8 bytes of _lrct$
fst QWORD PTR tv5476[ebp]
That's all info. Which data in particular was replaced and by what- means nothing. The only important fact is that data was replaced with something else.
|
|
|
|
|
You have not clearly demonstrated anything. Unless we see the source code there is nothing we can suggest. And, as I said before, if you are convinced that this is a compiler bug, then you should be sending it to Microsoft.
Veni, vidi, abiit domum
|
|
|
|
|
This is not the C/C++ source code.
There is a reason Richard is asking for it: it is all too common among people working "close to the metal" to "over-optimize" their code in a way that is simply wrong, or leads the compiler to produce inieffective or incorrect code. I'm not saying you did that, but you wouldn't be the first nor would you be the last.
Anyway, we can't decide where the error or bug is without seeing the actual C/C++ source code. Nor can anyone provide additional suggestions or help if you don't at the very least offer us the same information that your compiler got.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
There are a whole lot of questions that remain unanswered. Either may deliver the true reason for the bug you're experiencing. Compiler bugs are certainly possible, but rather unlikely.
You should really look at the problem again and consider some or all of the following questions:
1. Where did you get the information that
- _lrct$ refers to the start address of the RECT struct you're referring to
- the RECT struct is really 16 bytes in size
- the offsets you show are in fact relative to the same base address
2. Did you derive from your observation of these addresses that part of your data is overwritten, or did you check the actual RECT structure to verify that?
3. What are the original declarations of the C/C++ symbols corresponding to the two addresses _lrct$ and tv5476?
4. How were the two objects allocated?
5. Are you sure that one of them (the RECT) hasn't been deallocated in the meantime? Note that optimizers may discard variables before the end of their lifetime as seen in code if they realize it is no longer used!
I'm sure I could think of more questions, but this could be much more productive if we could see the actual code ...
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
|
Umm ... yes ... I kind of see it now
I think I'll go ... meditate or something
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Dear Stefan, it seems to me, that I have to remind you some theory. Local variables within some procedure may be addressed via ebp or esp. In my particular case they was addressed via ebp. It is much simpler to read such code, because ebp remains constant within a procedure. I some local variable is defined within some block, it becomes inaccessible, when eip leaves this particular block. Its place may be overwritten by something else, that's correct. But simultaneously debugger refuses to show this variable!!! But it showed it- therefore, lrct (16 byte RECT structure) was in its own block, was visible and accessible. But it was partially overwritten- 8 bytes was used as temporary storage for ST(0). That behavior cannot be taken as a normal one. And not lrct only- same fate waited h and maybe something else.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
