MuffinLover, после "if( chunk.chunkId == CT_fmt )" ты ничего не записываешь в chunk, но ожидаешь, что тип поменялся. Видимо вместо fmtChunk должен быть chunk
Urilobus, перед массивом записано, сколько байт удалять.
Можно боле ерадикально поступить и заменить массивы на std::vector. На скорости не отразится, а вручную удалять не придётся ничего. Наверняка ошибка глупая и очевидная, но я не вижу.
Urilobus, ну очевидно, что строки уже были удалены и "отрабатывает до конца" отображая мусор из памяти, который пока никто не успел перезаписать.
Для эксперимента, перед удалением векторов заполняй их числом -1, например, и у тебя окажется, что после копирования в объекте неправильные данные будут. И в отладчике отслеживай, в какой момент в скопированной матрице начинают пордтиться данные.
Выглядит так, что не обнулил указатель после копирования, но вроде всё ты обнуляешь. Визуально не вижу ошибки, так что в отладчике смотри.
Кроме вот этого места другие ошибки в глаза не бросаются
if( Mat_1 != nullptr )
{
for (int i = 0; i < rows_num; i++)
delete[] Mat_1[i];
}
Сразу подсказка на будущее: вещественные числа всегда врут. На меньше/больше/равно лучше сравнивать не прям такими операторами, а с учётом заданной погрешнсоти. Сперва сравнить на равенство, что два числа отличаются не больше, чем заданная погрешность и только потом сравнивать на меньше/больше. Вещественные числа сохраняются не точно и, условно, может получиться так, что "1.0 != 1.0". Например, будут введены расстояния в км и футах, котрые в метрах должны быть равны, но из-за погрешнсотей получится, что меньше. Или больше. Н оможет получиться и равно.
PresetX, Потому и комментарий, что это не был ответ.
Самая маленькая программа, которую мне удавалось написать на С++ + WinAPI получилась 5 килобайт и она скомпонована с msvcrt.lib. Она в коде возврата возвращает число страниц в pdf файле. Но это было в старых версиях MSVC, если не ошибаюсь, сейчас даже при статической компоновке требуется одна dll'ка, может об этом и страдания на форумах.
Не майся дурью. Я серьёзно. 20 лет назад я изучал ассемблер, чтобы даже с WinAPI в ассемблере работать, дляминимизации размера и максимизации скорости. Ведь на ассемблере будет быстрее менюшечка работать, чем на С++, "это же очевидно"(с).
Идёт 2022 год, не стесняясь использую Qt, который тащит за dll на несколько десятков мегабайт, даже для маленьких утилит, которые на "голом" С++ можно уложить в несколько сот килобайт, даже при татической линковке с CRT. Тут дело в чём, скорость и удобство разработки гораздо важнее экономии десятка мегабайт на диске. Скорость и удобство разработки важнее потери 0,01% производительности. Лишняя иконка на рабочем столе займёт больше дисковог опространства, чем микроскопическая утилита, не надо экономить на крошках. Собственно, иконка твоего приложения может занимать больше места, чем супер эффективный код на голом WinAPI.
Смысл извращаться может быть только для embeded систем, где могут быть существенные ограничения всех ресурсов. На ПК, да ещё и под Виндоус, самое главное это упростить и удешевить разработку. Сэкономленное время можно потратить на котиков в ютубе или ту же иконку приложения боее красиво перерисовать.
Не майся дурью, даже из спортивного мазохистского развлечения.
Николай Гефест, Даже не знал, что не двигая кистью рисовать можно, а просто зажав кнопку. На мой взгляд, багом выглядит поведение полноразмерной кисти, а не отмасштабированной. Или есть опции, чтобы менять скорость "заполнения" при нажатии кнопки, чтобы с разной скоростью мультиплицировалось?
Не знаю, что тут посоветовать, никогда с этим не сталкивался. Раз отключение ускорения GPU не помогает, то где-то в чём-то другом проблема.
Николай Гефест, Модераторов обсуждать нельзя, так что не буду...
Кроме отключения ускорения идей нет, из-за ошибок в OpenCL могло и не такое быть, но раз не онО, то х/з. Это же последний фотошоп?
