C / C++ / MFC Discussion Boards

Apologies for the shouting but this is important.

When answering a question please:

Read the question carefully
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar
If a question is poorly phrased then either ask for clarification, ignore it, or mark it down. Insults are not welcome
If the question is inappropriate then click the 'vote to remove message' button

Insults, slap-downs and sarcasm aren't welcome. Let's work to help developers, not make them feel stupid.

cheers,
Chris Maunder

The Code Project Co-founder
Microsoft C++ MVP

For those new to message boards please try to follow a few simple rules when posting your question.

Choose the correct forum for your message. Posting a VB.NET question in the C++ forum will end in tears.
Be specific! Don't ask "can someone send me the code to create an application that does 'X'. Pinpoint exactly what it is you need help with.
Keep the subject line brief, but descriptive. eg "File Serialization problem"
Keep the question as brief as possible. If you have to include code, include the smallest snippet of code you can.
Be careful when including code that you haven't made a typo. Typing mistakes can become the focal point instead of the actual question you asked.
Do not remove or empty a message if others have replied. Keep the thread intact and available for others to search and read. If your problem was answered then edit your message and add "[Solved]" to the subject line of the original post, and cast an approval vote to the one or several answers that really helped you.
If you are posting source code with your question, place it inside <pre></pre> tags. We advise you also check the "Encode HTML tags when pasting" checkbox before pasting anything inside the PRE block, and make sure "Ignore HTML tags in this message" check box is unchecked.
Be courteous and DON'T SHOUT. Everyone here helps because they enjoy helping others, not because it's their job.
Please do not post links to your question in one forum from another, unrelated forum (such as the lounge). It will be deleted.
Do not be abusive, offensive, inappropriate or harass anyone on the boards. Doing so will get you kicked off and banned. Play nice.
If you have a school or university assignment, assume that your teacher or lecturer is also reading these forums.
No advertising or soliciting.
We reserve the right to move your posts to a more appropriate forum or to delete anything deemed inappropriate or illegal.

cheers,
Chris Maunder

The Code Project Co-founder

Microsoft C++ MVP

Does anybody know how to program a pic micro in C to detect gradient. I have set up ADC pins and each LDR is detecting light. Just need to set that a specific gradient of light detected by LDR will switch a light on.

Quote:
gradient

Do you mean "range of frequencies" (or "range of wavelengths")?

Programming the PIC is relatively simple, I believe. You have first to:

Be sure your light detector is sensitive to such frequency range.
Filter in the light of such frequency range.

Once such conditions are satisfied you'll get a high value on the ADC measure when the 'gradient of light' is detected.

Veni, vidi, vici.

I am new to programming especially with pics. I am measuring the voltage reading from each LDR. It looks like a capacitor charging/discharging. I have an idea of what I have to do detect min and max values calculating the gradient etc. its just actually putting it in code.

Senned wrote:
I have an idea of what I have to do detect min and max values calculating the gradient etc

Please provide an example.
BTW what PIC family are you using?

Veni, vidi, vici.

for instance if the LDR is measuring 5V when it is dark and decreases to 0V this is in an ideal world. My pic is constantly scanning so I will probably need 3 variables each for min and max, so previous min, current min and main min, previous max, current max and main max. Now it will store a value for the previous value then take a new reading, if the current min is less than the prev. min then it would replace it as the main min. same goes for max if current max is greater than prev max then it would replace it as the main max value. Now that I have these I have values to calculate my gradient and determine whether or not it is detecting light from a certain light source or just background light. I am using pic24F16KL402.

Since you can write your application using C, it shouldn't be difficult to implement such logic. Or have you troubles in dealing with the ADC?

Veni, vidi, vici.

Yeah that has proved to be a problem when I tried it. The pic has only 2 buffers and I have usually had to work with more in the past (assign 1 LDR per buffer). Do you have any idea how to assign more than 1 LDR per buffer? I could send you my code if you like

Quote:
Do you have any idea how to assign more than 1 LDR per buffer?

That is not a problem, actually. Just perform the process sequentially on the LDRs e.g.

Sample and convert LDR1, take the result from ADC1BUF0, store it in variable, say ldr1.
Sample and convert LDR2, take the result from the same buffer ADC1BUF0, store it in the variable ldr2.
...

Veni, vidi, vici.

Does anybody know how to program a pic micro to detect gradient. I have set up ADC pins and each LDR is detecting light. Just need to set that a specific gradient of light detected by LDR will switch a light on.

How do I read the file index.dat written. By dcmqrscp application how is the file record format.
Is any example available for reading it and Get the name of file moved ?

Thanks
Andrea

Try some of these links[^].

Veni, vidi, abiit domum

Thanks for hint.
I had a look to the links
But stil is not clear how to read index.dat to Get the name of the files retrieved. Do you know where i can Get some example?

Andrea

Member 10174363 wrote:
Do you know where i can Get some example?

Google is the only place for questions like this. I have had another look but could not find anything that may be relevant. I would suggest you try http://medical.nema.org/dicom/[^].

Veni, vidi, abiit domum

I understand Visual Studio 2012 and 2013 are using Microsoft Foundation Classes version 11. But only in the more professional versions like Ultimate.

Is it truth that Microsoft is still using MFC for its own products such as Office?

What to conclude from the fact that sources based on MFC 6 still build without any errors in VS2012? What other libraries or templates can offer the same?

Many people are feeling unsecure for making a choice for a library to work with. After some years same questions appear again.

Using an other library makes sources completely unrecognizable for other users.

Is it still wise using MFC? Is it easy to make connections to code based on STL? Is it a wise choice when you want to make managed code when possible? In other words can it be nicely coupled to .NET code?

I tried to find a consistent policy at MSDN. More and more people within Microsoft didn't ever hear about MFC.
To find out what's the latest version took me some research.

http://msdn.microsoft.com/en-us/library/d06h2x6e.aspx[^]

modified 5 days ago.

Is it still wise? ...sure, why not? You're always going to have some amount of risk when using a framework, but given the alternative of developing everything from scratch, the benefits outweigh the risks.

Considering MFC is essentially a class based wrapper around the WinAPI (with a lot of helper classes), I doubt it's going to disappear any time soon. It has a long history and I just don't see it ending soon. As far as what versions of VisualStudio have MFC, it's usually the Professional versions (and up). That's probably because they're using part of the cost of those versions to fund the maintenance of the libraries. Usually every version of VisualStudio also comes with a new version of MFC (although not sure if that's always been the case).

If you have a completely new project... you could always opt for C# and the .net framework, or Java and JRE, but if you already have quite a bit of experience with MFC versus the alternatives, it's probably safe to stick with that for the time being.

You can easily find free or commercial alternatives to the MFC, you don't need to handcode it yourself at all. That is not a valid reason to justify using the MFC.

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)

True, there's always open source alternatives like Qt, wxWidgets, but those also have their inherit risk. When the Qt project switched ownership hands, everyone was worried that they would start charging for it. So I guess when I said MFC vs hand coding a framework, I meant using an existing framework vs hand coding a framework. There's always a risk in using someone else's framework. Big companies like L3 even make their own frameworks so they won't be reliant on anybody else.

Quote:
Is it truth that Microsoft is still using MFC for its own products such as Office?

Did they ever do that?

Veni, vidi, vici.

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. Poke tongue | ;-P

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 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 5 days ago.

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 4 days ago.

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)

Did you see this message in the thread[^]? It (sort of) explains quite a lot.

Veni, vidi, abiit domum

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.

a_matseevsky wrote:
within a procedure

This is just one of many bits of information you haven't really provided. Therefore the wide array of questions. I am well aware that many probably don't make a lot of sense to ask in your particular case if you see the exact code that the compiler used to produce the assembly.

But as repeatedly mentioned, you haven't provided that code, so all we can do is guess and poke in the dark.

In the meantime I've spotted the code that you posted in a different branch of this thread. It isn't the original code though, and doesn't provide sufficient insight to answer any of the questions I posted. You state that variant A doesn't work, but it doesn't use the max() function, so we have to assume that the assembler code generated from that doesn't match the bits you later found to be incorrect (if they are indeed that - we still do not know)

In the code you posted you use some variables that are only referenced over a couple of lines. They may not in fact be stored in the stack at all! As a result, the debugger will not show their contents in the optimized release code. Similarly, if you define a struct with data that is never referenced, the compiler may decide to optimize away the unneeded bits, reducing the size of the struct. You haven't posted the definition of the struct, nor where it's accessed, so it's impossible to tell if that is the case.

I could go on and easily bring up half a dozen or more other optimization techniques that you appear to be unaware of, and that will confound your ability to read useful information from the debugger alone within optimized code. But it's pointless.

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)

Stefan_Lang wrote:

In the meantime I've spotted the code that you posted in a different branch of this thread. It isn't the original code though, and doesn't provide sufficient insight to answer any of the questions I posted. You state that variant A doesn't work, but it doesn't use the max() function, so we have to assume that the assembler code generated from that doesn't match the bits you later found to be incorrect (if they are indeed that - we still do not know)

What do you mean, writing "it isn't the original code?" That I copied it from somewhere or what? I never stated, that variant A does not work. It is your idea. I asked, which works and which not (and why). You was not able to answer this question and preferred to ignore it.

In the code you posted you use some variables that are only referenced over a couple of lines. They may not in fact be stored in the stack at all! As a result, the debugger will not show their contents in the optimized release code. Similarly, if you define a struct with data that is never referenced, the compiler may decide to optimize away the unneeded bits, reducing the size of the struct. You haven't posted the definition of the struct, nor where it's accessed, so it's impossible to tell if that is the case.

All fields of the RECT structute was later used. If compiler decided that they are no more in use, it is just its bug. RECT structure is so well-known, that i did not placed its definition here. It contents 4 fields of type long- top, left, right and bottom. Just 16 bytes. I ran release version under debugger and I saw all assembler commands and order of their execution. Therefore, I know which variables was not stored in a stack and which temporary variables (which I did not declared!) was stored and where.

I could go on and easily bring up half a dozen or more other optimization techniques that you appear to be unaware of, and that will confound your ability to read useful information from the debugger alone within optimized code. But it's pointless.

Pointless is to repeat things like "there are more things on the Earth, on the heaven, than any dreamt of in our philosophy". What makes you think that I do not know about optimization? Stop walking around and answer to one simple question: why local variable, visible and accessible, was overwritten? You cannot name at least one more or less credible reason. If it is not visible, I couldn't get access to it and debugger wouldn't show it. Just this situation happens with variables, which are used in one-two lines of code. Debugger doesn't show them at all (worry not, I know such things).

You should be aware that asking us which optimized code would work and which wouldn't, without posting the full code with declarations and optimizer settings is ludicrous.

Therefore I decided to derive it based on you statements elsewhere: Variant B contains code that works by your own statement elsewhere. neither contains the max() funtion you refer to in your original question. So B is the working and A the not working - albeit not the original - version. Q. E. D.

As for what is pointless or not: advice is only pointless if it isn't heeded. You believe that the debugger shows you every information correctly? It doesn't. It can't. It's physically impossible.

I've dealt with optimizers 30 years ago: back then it wasn't to hard to anticipate what it would do, and in C you could often emulate pretty much the same without having to invoke the optimizer at all. meaning well optimized C code ran almost as well in debug mode as it did in release.

I've dealt with optimizers 20 years ago, and it got more tricky. Still, well optimized C-code often turned out to be near optimal.

I've dealt with optimizers 10 years ago, and the experience was very different: for one, the same optimizations in C code sometimes led to slower code, because it prevented the optimizer from performing extremely sophisticated optimizations that you'd never have thought of. Plus the size of the codebase made it impossible to optimize all of your code in that way anyway.

At that point I stopped trying to optimize my C/C++ code by hand.

Nowadays, when I check release code that doesn't do the same as debug code, I often find that half the variables aren't on stack, and some others get overwritten at unexpected moments. At least when I look at them through the debugger. It's the optimizer at work! What I usually do is pinpoint the location where everything goes south, then insert some print statements to ensure everything is as I expect it to be - and in 9 cases out of 10, something will not be as I expect it to be! And the debugger won't be able to show it!

That's why I keep telling you not to trust the debugger - and looking at the assembler code doesn't change that you're using the debugger.

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)

Stefan_Lang wrote:

Therefore I decided to derive it based on you statements elsewhere: Variant B contains code that works by your own statement elsewhere. neither contains the max() funtion you refer to in your original question. So B is the working and A the not working - albeit not the original - version. Q. E. D.

Again- I never claimed, which variant works and which does not. It was my question. And what "not the original version" means? I made my own investigation since the time, when I asked my first question. I changed code many times. I found, that no min nor max are not the source of the problem. There is no need in demonstrating of the rest of original code- it is the same for A and B. The difference is only here, in these few lines. And my question was- how could it be- both variants are correct. So you cannot answer to my question. Should I send you the answer or you will think for a while?

As for what is pointless or not: advice is only pointless if it isn't heeded. You believe that the debugger shows you every information correctly? It doesn't. It can't. It's physically impossible.

Why? Which part is hidden? Pipelines? Debugger demonstrates me all what I need to understand the core of situation. You must work really hard, if you want to cheat (or to trick- whichever word do you prefer) debugger. It happens mostly with self-modified code.

I've dealt with optimizers 30 years ago: back then it wasn't to hard to anticipate what it would do, and in C you could often emulate pretty much the same without having to invoke the optimizer at all. meaning well optimized C code ran almost as well in debug mode as it did in release.

I've dealt with optimizers 20 years ago, and it got more tricky. Still, well optimized C-code often turned out to be near optimal.

I've dealt with optimizers 10 years ago, and the experience was very different: for one, the same optimizations in C code sometimes led to slower code, because it prevented the optimizer from performing extremely sophisticated optimizations that you'd never have thought of. Plus the size of the codebase made it impossible to optimize all of your code in that way anyway.

At that point I stopped trying to optimize my C/C++ code by hand.

More than strange idea. Hi-level optimization cannot be performed by compiler. Low-level usually yes, but not always.

Nowadays, when I check release code that doesn't do the same as debug code, I often find that half the variables aren't on stack, and some others get overwritten at unexpected moments. At least when I look at them through the debugger. It's the optimizer at work! What I usually do is pinpoint the location where everything goes south, then insert some print statements to ensure everything is as I expect it to be - and in 9 cases out of 10, something will not be as I expect it to be! And the debugger won't be able to show it!

I should ask you, do you really know, how one can get debugger demonstrate all of what he needs? Do you use register's window? Co-processor's one? Debugger may demonstrate you memory at any address what you need. And when I run release under debugger, it demonstrates me result of disassembling of binary executable file- just what it is executing, BUT NOT MY SOURCE CODE! This is why I see just what is executed. And I can compare it with the listing, which contains source C++ and assembler. I can create release with debugger info and create separated file with database. Debugger (even part of Visual Studio) is very powerful one and been properly used, can give you all what you need and more that that. Sorry, but I printed variables too- many years ago. it was only because I did know how to work with debugger. Later I found that debugger offers me info which I needed in the more convenient way.

That's why I keep telling you not to trust the debugger - and looking at the assembler code doesn't change that you're using the debugger.

You may trust debugger, if you know, how to use it.

Well, I've just answered, but I do not see it... Well, let's go point by point

Stefan_Lang wrote:
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

What do you think .asm files exist for? Compiler made them and I was able to see, where local and temporary variables was allocated.

- the RECT struct is really 16 bytes in size
Nice question, it comes to my mind too- but the same compiler was so kind, that showed me the size of a RECT structure

- the offsets you show are in fact relative to the same base address
You should know, that ebp register remains constant within any procedure! And in this particular case all local and temporary variables was addressed via ebp.

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?

I saw it, running my prog under debugger and I know which command (fst) overwrote aforementioned RECT (in fact, only right and bottom).

3. What are the original declarations of the C/C++ symbols corresponding to the two addresses _lrct$ and tv5476?

RECT lrct; the second variable is local storage, using to temporary storage of ST(0)

4. How were the two objects allocated?

I wrote it, but I can repeat it again. _lrct=-212 and tv5476=-204 (number a decimal ones!) It means, that command fst tv5476[ebp] overwrites 8 bytes- one half of lrct structure.

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!

It would be possible, but in such case debugger refuses to show such variable and gives message like "expression cannot be evaluated". Moreover, compiler wouldn't let me to use a variable outside of the block, where it was declared.

I'm sure I could think of more questions, but this could be much more productive if we could see the actual code ...

You saw it. Answer a question, originally addressed to Richard- which variant (and why)   refuses to work properly.

1.a) I realize that one is from the generated assembler code , but "I am able to see" is not an answer to my question. But never mind, you later wrote the original symbol is named _lrct, which I consider sufficient information at this point.

Considering the fact that symbols starting with '_' are common within windows system libaries and the MFC, and 'rct' is a common name fragment used for windows rectangle types and variables, I presume this is the Windows RECT struct[^] that you're talking about?

1b) Are you saying you used the sizeof() function? That would be the only way I know of the compiler can 'tell' you as much. Or if you derived it from bits of the assembler code, I have to trust your word for it - I don't don't know how to extract that kind of information.

1c) it could have been different procedures, or even different threads. Before your more recent answers there was no way to tell. So this isn ot (part of) the cause of the problem.

2 As mentioned in another post: you can't trust debugger output in optimized code! Some variables may not be stored in the stack at all, others may be overwritten before they expire, and addresses used to view a particular element may not contain the correct value, or the most recent state of the variable, due to caching, or memory optimization. The only way to be sure of the actual, current state of a variable, is print it out to the console or maybe log file.

4 I meant memory allocation, as in whether they are on the stack, the heap, or temporaries. But in light of the other responses this is no longer important.

5: see 2. - Don't trust the debugger in optimized code.

I still have some doubts the compiler has a bug - the symptom you describe is just too obvious. My guess is that it's a result of optimization. But with your responses you excluded a number of possible alternate causes. If you still feel it is a genuine bug you could report it to MS. However, I'm not sure whether they'll look into an 8 year old compiler when they have various newer versions to offer: if they find a bug, they'll probably only fix it in the newest version(s).

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)

		10,337,064 members (57,985 online) Sign in Email Password Forgot your password? Sign in using