|
Veni, vidi, vici.
|
|
|
|
|
Member 9857487 wrote:
how can i improve my c programming in different ways
Learn how compilers and linkers work. That knowledge will increase your understanding of how the C language works.
|
|
|
|
|
Hello. I'm trying to open exe file , but there is a problem like this:
<<assert failure="" in="" qlist::operator[="" ]:="" "index="" out="" of="" range",="" file="" c:\qt\4.8.1\include\qtcore\..="" ..="" src="" corelib="" tools="" qlist.h,="" line="" 477="">>
but I can compile without debuging or I can debug it, and there is no problem; it works correctly:
what is it a problem at time opening exe file?
thanks for attention
|
|
|
|
|
Please do not create multiple accounts in order to post the same question twice.
Use the best guess
|
|
|
|
|
Possibly the worst sock puppetry act ever.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
How dense can you be? Its the value you are passing to the Qlist::[] opperator! Its telling you that it is too big!
Holy crap, I wish I had error messages this easy.
If you dont understand that accessing member 2909483625284948 of a 22 member array is a bad thing then go get another job.
|
|
|
|
|
f*** you Erudite_Eric
Do you think that you are smart, but you're awfully stupid
|
|
|
|
|
Actually I know I am stupid, thats why I force myself to think very carefully about things.
|
|
|
|
|
Sometimes it's better to say nothing .
|
|
|
|
|
Especialy without thinking first.....
|
|
|
|
|
Hello. I'm trying to open exe file , but there is a problem like this:
<<assert failure="" in="" qlist::operator[="" ]:="" "index="" out="" of="" range",="" file="" c:\qt\4.8.1\include\qtcore\..="" ..="" src="" corelib="" tools="" qlist.h,="" line="" 477="">>
but I can compile without debuging or I can debug it, and there is no problem; it works correctly:
what is it a problem at time opening exe file?
thanks for attention
|
|
|
|
|
Member 10072694 wrote: it works correctly: Not if it gives "index out of range" error. You need to do some more debugging to identify where this error occurs in your code.
Use the best guess
|
|
|
|
|
Member 10072694 wrote: what is it a problem at time opening exe file?
Your code is trying to access an item of the QList providing an invalid index (possibly the index is bigger than QList size). As suggested you should debug your application to find out why this happens.
Veni, vidi, vici.
|
|
|
|
|
but at time debuging there is no problem, and my project works correctly
|
|
|
|
|
Mkhitar_Sargsyan wrote: but at time debuging there is no problem That just means that the data you are using while debugging does not show the error. You need to reproduce exactly the same conditions that cause the error in order to find it.
Use the best guess
|
|
|
|
|
|
How would we know? It's your program so you are the one who understands it.
Use the best guess
|
|
|
|
|
yes I know it, but it strange that at time debugig there is no errors, I opened all list of errors, and there is nothing.
And my project with debug works correctly, it's strange that it's a problem at time opening exe file
|
|
|
|
|
Not strange at all; this is a fairly common occurrence. You need to add some code to the program to identify why this value goes out of range at some time.
Use the best guess
|
|
|
|
|
|
Member 10072694 wrote: but I can compile without debuging or I can debug it, and there is no problem; it works correctly: Negative. Assertions do not fire in release mode, only debug mode. The problem still exists.
You have a list that you are trying to access, so what does that code look like?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
There is also an easy way this comes about
In debug mode the compiler will zero all variables and memory in release mode it doesn't the memory will have garbage in it.
Are the index variable been zero or set to a specific value or are you just assuming it is?
|
|
|
|
|
leon de boer wrote: Are the index variable been zero or set to a specific value... I would have no way of knowing.
leon de boer wrote: ...or are you just assuming it is? I'm not assuming anything.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Here let me show you
void silly_error_code (int j){
const char somearray[5] = {'0','1','2','3','4'};
char testval;
testval = somearray[j];
}
int i;
main {
silly_error_code(i);
}
That code will work fine in debug mode but will most likely crash with the sort of error you have in release mode and the compiler won't pick the error.
WHY ... because variable global variable "i" was never set to any value
When you run in debug mode the compiler zeros all global variables there is a long story of why it does that but for now all you need to do is that it does.
So in debug mode testval will always come back with "0" because i is initialized by the debug mode to 0
In release mode it is highly likely this will crash as "i" could be any value including values which are way outside the array range of somearray.
See how the code above has the same problem as your code ... I can use it safely in debug mode BUT not release.
MICROSOFT TIP: Variables and allocated memory are often initialized differently in Debug versions than in Release version of software. If you've assumed that your variables are zeroed when they are declared could easily cause strange behavior in Release mode on Win9x. You can also introduce bugs that are Win9x specific. WinNT, for security reasons, zeros all memory before it is used.
modified 13-Aug-13 16:12pm.
|
|
|
|
|
leon de boer wrote: That code will work fine in debug mode but will most likely crash with the sortof error you have in release mode and the compiler won't pick the error.
WHY ... because variable global variable "i" was never set to any value
When you run in debug mode the compiler zeros all global variables there is a long story of why it does that but for now all you need to do is that it does. So in debug mode testval will always come back with "0" because i is initialized by the debug mode to 0 In release mode it is highly likely this will crash as "i" could be any value including values which are way outside the array range of somearray. I am fully aware of this.
leon de boer wrote: See how the code above has the same problem as your code... My code?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|