C / C++ / MFC

Re: CXX0017: Error: symbol "buf_balance" not found

11-Jul-05 14:28

I tried this in VC6, but it shows the value of global variables correctly...

did you pause the app or set a breakpoint? try with a breakpoint at the place you want to debug (or use DebugBreak())

also try rebuilding everything and try again

- Indivara

"...This city desert makes you feel so cold.
It's got so many people but it's got no soul..."
- Gerry Rafferty, Baker Street

Indivara11-Jul-05 18:19

Re: CXX0017: Error: symbol "buf_balance" not found

11-Jul-05 18:19

replying to your post in a separate thread above,

in my app, there are many files. when I pause, it is not inside file1.cpp, but stoped in file2.cpp.
I think this matters. if it stoped in file1.cpp I can see this variable.

that shouldn't make a difference. I could see global variables in the watch window no matter which file the debugger is stopped in Confused | :confused:

try restoring project settings to default in Project - Settings, C/C++ & Link tabs, settings related to debug information
(my OS is not in english, so I can't give the exact settings...)

- Indivara

"...This city desert makes you feel so cold.
It's got so many people but it's got no soul..."
- Gerry Rafferty, Baker Street

Bob Stanneveld11-Jul-05 20:40

11-Jul-05 20:40

In don't think that you gave it global scope. Did you use an extern declaration in the headerfile? Did you include the definition in file2.cpp? The reason why the debugger can't see your variable is that it does not know its definition.

Behind every great black man...
... is the police. - Conspiracy brother

Blog[^]

pointer increment

Indivara11-Jul-05 13:07

11-Jul-05 13:07

Hi...
This feels like a stupid question, but does anybody know why it is better to use a loop like this to advance a pointer

C++

int i;
BYTE *pointer;	//
int count;	// set elsewhere
int increment;	//

for (i = 0; i < count; i++) {
	pointer += increment;
}

than simply advance the pointer in a single step

C++

pointer += increment * count;

I found this in some code which used to run in both user mode and kernel mode. I think it was written by an experienced programmer, and probably isn't a mere WTF | :WTF:

...

- Indivara

"...This city desert makes you feel so cold.
It's got so many people but it's got no soul..."
- Gerry Rafferty, Baker Street

Jose Lamas Rios11-Jul-05 15:58

Jose Lamas Rios

11-Jul-05 15:58

I can see some differences between them:

1. (increment * count) might overflow in cases in which the for loop would work without problems
2. If count is negative, the for loop won't alter the pointer; in the alternative, it will always be modified unless either increment or count is zero.

Still, even if I wanted to cover those cases, I wouldn't do it that way. Are you sure that's exactly how the code was written? Maybe if you give us some more context?

--
jlr
http://jlamas.blogspot.com/[^]

Indivara11-Jul-05 18:07

11-Jul-05 18:07

Jose Lamas Rios wrote:
1. (increment * count) might overflow in cases in which the for loop would work without problems

I don't think overflow is a problem. all values are well within range for all practical purposes

Jose Lamas Rios wrote:
2. If count is negative, the for loop won't alter the pointer; in the alternative, it will always be modified unless either increment or count is zero.

I didn't think of that. increment can in fact be either positive or negative (intentionally, to move the pointer forward or backward) but as you say, there are better ways, like using the absolute value of count

Jose Lamas Rios wrote:
Are you sure that's exactly how the code was written? Maybe if you give us some more context?

this is a part of code used to copy data from a bitmap. the pointer is the bitmap buffer, and increment is the number of bytes to move to the next line. count is used to skip certain lines.

and it was written like this

if (count != 0) {
    if (count == 1) {
        pointer += increment;
    } else {
        for (i = 0; i < count; i++) {
            pointer += increment;
        }
    }
}

I skipped the first if conditions in the original post...
they are used because count is often 0 or 1 (I think), but why use the loop? Confused | :confused:

- Indivara

"...This city desert makes you feel so cold.
It's got so many people but it's got no soul..."
- Gerry Rafferty, Baker Street

Bob Stanneveld11-Jul-05 20:53

11-Jul-05 20:53

Indivara wrote:
Jose Lamas Rios wrote:
1. (increment * count) might overflow in cases in which the for loop would work without problems

I don't think overflow is a problem. all values are well within range for all practical purposes

If you use bitmaps, you never know how large your data will be. One should make his / her code as robust as possible. There is one golden rule that programmers should honer always: user data is malicious until proven otherwise! So extreme caution should be taken when using pointers and data from outside the program.

Indivara wrote:
I skipped the first if conditions in the original post...
they are used because count is often 0 or 1 (I think), but why use the loop?

I wonder why the programmer used the if's..? The following code does exactly the same:

for( int i = 0; i < count; i++ )
    pointer += increment;

But indeed, maybe for performance reasons he used the if's.

Behind every great black man...
... is the police. - Conspiracy brother

Blog[^]

Indivara11-Jul-05 21:11

11-Jul-05 21:11

Bob Stanneveld wrote:
If you use bitmaps, you never know how large your data will be. One should make his / her code as robust as possible. There is one golden rule that programmers should honer always: user data is malicious until proven otherwise! So extreme caution should be taken when using pointers and data from outside the program.

you are right about that, I've had countless problems due to assumptions about user data.. Unsure | :~

... however in this case, I doubt the programmer had that in mind when writing this code. if this were to overflow, the bitmap would be so large that the system would run out of memory long before...
there must be some other reason for the loop

Bob Stanneveld wrote:
But indeed, maybe for performance reasons he used the if's.

probably so. I was wondering whether the loop was there for the same reason, but can't figure out why it would be faster...

- Indivara

"...This city desert makes you feel so cold.
It's got so many people but it's got no soul..."
- Gerry Rafferty, Baker Street

Bob Stanneveld11-Jul-05 21:31

11-Jul-05 21:31

Indivara wrote:
I was wondering whether the loop was there for the same reason, but can't figure out why it would be faster...

Take the following scenario where a loop would run exactly one time:
<list>

Step 1: initialize the loop counter

Step 2: test the expression: i < count (0 < 1 == true)

Step 3: execute body

Step 4: increment i: i++ (i == 1)

Step 5: test the expression: i < count (1 < 1 == false)

Step 6: leave loop
If you do the test of iterating one time, you save steps 1, 4, 5 and 6. You still have to test once, so that uses the same CPU cycles as step and and the body is also executed once. So if count equals one often enough, it may save a lot of CPU cycles. If count is not equal to zero or one, it causes the loop run acutally slower.

Back in the old C days (especially with image processing and computer games) everybody was optimizing as much as they could. Nowdays the compiler often does a better job than we at optimizing.

Behind every great black man...
... is the police. - Conspiracy brother

Blog[^]

Indivara11-Jul-05 22:02

11-Jul-05 22:02

I'm sorry, I think I didn't write clearly...
what I meant was, I wondered whether the loop would be faster than simply adding count * increment to the pointer under certain conditions (like maybe in kernel mode?)

Bob Stanneveld wrote:
Back in the old C days

maybe this is left over from the old C days... Sniff | :^)

- Indivara

"...This city desert makes you feel so cold.
It's got so many people but it's got no soul..."
- Gerry Rafferty, Baker Street

Bob Stanneveld11-Jul-05 22:06