I wrote the application on qt on windows 7, transferred Windows 10, compiled it, launched it and on every second cycle of the passage through the vector, for example in these two

for(int i=0;i<=for_step_x.size();i++)//here { scalar_product=l_oz*l_st[i]+m_oz*m_st[i]+n_oz*n_st[i]; angle_arccos.push_back(acos(scalar_product)); } for(int i=0;i<=angle_arccos.size();i++)//here { if((angle_arccos[i]*180/pi)<view_angle) { result_alpha.push_back(for_step_x[i]); result_beta.push_back(for_step_y[i]); 

an error comes out

 ASSERT failure in QVector<T>::operator[]: "index out of range", file C:\Qt\5.6\mingw49_32\include/QtCore/qvector.h, line 427 

on Windows 7, respectively, this was not observed, what is the reason I do not understand. It is treated with crutches like

 for(int i=0;i<for_step_x.size()-1;i++)// для звездной величины { 

or in other cases, simply removing = from <=

just like that on this code

  QString filename = QFileDialog::getSaveFileName(this, tr("Save jpg"), ".", tr("jpg files (*.jpg)")); 

Ie when the file dialog is called and I choose the place and the name of the file to save to the output of the application such things get out

 shell\comdlg32\fileopensave.cpp(9456)\COMDLG32.DLL!76D90750: (caller: 76D83458) ReturnHr[PreRelease](1) tid(13ec) 80070490 Элемент не найден. CallContext:[\PickerModalLoop\InitDialog\FileDialogInitEnterpriseData] shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(243)\thumbcache.dll!5B9ADFD9: (caller: 5B9AE191) ReturnHr[PreRelease](1) tid(13ec) 80004005 Неопознанная ошибка shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(153)\thumbcache.dll!5B9C6270: (caller: 7653FEE9) ReturnHr[PreRelease](2) tid(13ec) 80004005 Неопознанная ошибка shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(243)\thumbcache.dll!5B9ADFD9: (caller: 5B9AE191) ReturnHr[PreRelease](3) tid(13ec) 80004005 Неопознанная ошибка shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(153)\thumbcache.dll!5B9C6270: (caller: 7653FEE9) ReturnHr[PreRelease](4) tid(13ec) 80004005 Неопознанная ошибка shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(153)\thumbcache.dll!5B9C6270: (caller: 7653FEE9) ReturnHr[PreRelease](5) tid(13ec) 80004005 Неопознанная ошибка shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(153)\thumbcache.dll!5B9C6270: (caller: 7653FEE9) ReturnHr[PreRelease](6) tid(13ec) 80004005 Неопознанная ошибка shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(153)\thumbcache.dll!5B9C6270: (caller: 7653FEE9) ReturnHr[PreRelease](7) tid(13ec) 80030002 Не удается найти %1. shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(243)\thumbcache.dll!5B9ADFD9: (caller: 5B9AE191) ReturnHr[PreRelease](9) tid(13ec) 80004005 Неопознанная ошибка shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(243)\thumbcache.dll!5B9ADFD9: (caller: 5B9AE191) ReturnHr[PreRelease](8) tid(2758) 8004B203 shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(243)\thumbcache.dll!5B9ADFD9: (caller: 5B9AE191) ReturnHr[PreRelease](10) tid(2758) 8004B203 shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(243)\thumbcache.dll!5B9ADFD9: (caller: 5B9AE191) ReturnHr[PreRelease](11) tid(2758) 8004B203 shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(243)\thumbcache.dll!5B9ADFD9: (caller: 5B9AE191) ReturnHr[PreRelease](12) tid(13ec) 80004005 Неопознанная ошибка shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(243)\thumbcache.dll!5B9ADFD9: (caller: 5B9AE191) ReturnHr[PreRelease](13) tid(2284) 8004B200 CallContext:[\PerformFullExtract] shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(243)\thumbcache.dll!5B9ADFD9: (caller: 5B9AE191) ReturnHr[PreRelease](14) tid(2284) 8004B200 CallContext:[\PerformFullExtract] shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(243)\thumbcache.dll!5B9ADFD9: (caller: 5B9AE191) ReturnHr[PreRelease](15) tid(2334) 8004B200 CallContext:[\PerformFullExtract] shell\ext\thumbnailcache\lib\thumbcacheapi.cpp(243)\thumbcache.dll!5B9ADFD9: (caller: 5B9AE191) ReturnHr[PreRelease](16) tid(2334) 8004B200 

what could be the problem? compilers like the same

  • five
    For a vector, the indices must be from 0 to (N-1). Where N is the size. Going beyond limits leads to undefined program behavior. - αλεχολυτ
  • @alexolut, yes, but in some the error disappears only when -1 is added, and also removed = from <=, and here one element is already lost - bronstein87
  • If the indices are correct both when writing to a vector and reading, no elements should be lost. But since we do not see the full picture, the problem may be in other places of the code. - αλεχολυτ
  • Definitely going beyond the array will result in an error. It can even lead to crash programs. Your cycles should not go beyond the vector. Also, you can use an inerator or foreach ( doc.qt.io/qt-4.8/containers.html#the-foreach-keyword ) in all elements. - Unick

1 answer 1

Initially, you incorrectly defined the boundaries of indexing: from 0 to size() . If your container contains N elements, then the indices of these elements can be represented as follows:

 0..1..2..3.. ..N-2..N-1 

Total - N items. In the loop (in your example), the following condition is imposed on the upper bound: i <= size() . And this means nothing but the fact that at a certain iteration i becomes equal to N. There is no element N in the container - this is exactly what the compiler reminded you with the message:

ASSERT failure in QVector :: operator []: "index out of range"

Next, you are trying to solve the problem - but too hard to set about it. Imposed on i the following condition < size() - 1 . It was enough just to remove the = sign so that the inequality became strict. And so, you have imposed a restriction that just misses the last element; in other words, the maximum value that i can take:

i(max) < size() - 1 => i(max) < N - 1 => i(max) = N - 2

Containers are better for bypassing iterators. If you need to change the data inside the for loop, this is a regular iterator, it is NOT necessary - const_iterator.


As for getSaveFileName - it’s strange that you get the message "file not found" - either because you are using the Cyrillic alphabet (although I’m not sure if this is the case), or because this message is not related to this code. It is specific to getOpenFileName, for getSaveFileName, the "non-existence" of the file is quite expected, in the documentation on this subject it is written:

This is a static name selected by the user. The file does not have to exist.