вопрос по си

[ihq.pl]

mihaild в сообщении #1267965 писал(а):

А в чем вопрос-то? Ну да, вы обращаетесь к ind_1 по индексу большему чем его размер. При этом может произойте всё что угодно (undefined behavior), в данном случае происходит еще вполне разумная вещь - меняется массив, идущий дальше. Что не так?

я привык, что в таких случаях выдается segmentation fault. Но программа выполнялась до конца, и меня это смутилло. Опыта мало. А кстати, о коде что скажете, он всё так же ужасен?

[mihaild]

ihq.pl в сообщении #1268019 писал(а):

я привык, что в таких случаях выдается segmentation fault

Segmentation fault выдается если вы пытаетесь писать по адресу, вам не принадлежащему. Тут вы пишете по принадлежащему вам адресу - просто занятому не тем, что вы ожидаете.
По коду - сходу видно, что нужно перенести переменные поближе к месту использования, проверять Q и nR на инициализированность и в конце освобождать память. Дублирование кода для ind_1 и ir1 лучше убрать.

Для остального уже нужно внимательно разбираться, что конкретно происходит.

[ihq.pl]

mihaild в сообщении #1268022 писал(а):

Segmentation fault выдается если вы пытаетесь писать по адресу, вам не принадлежащему

Например, что выдаст такой код

Используется синтаксис C

int mass[3];
int i;
for(i=0; i<5; i++) mass[i]=0
 

разве не segmentation fault? В моём представлении "принадлежащий мне адрес" - это место в памяти, отведенное массиву. Это так?

[mihaild]

Нет, не так.
Тут есть два уровня - стандарт и реальное поведение.
В стандарте написано, что поведение этого кода не определено (undefined behavior). Т.е. при его выполнении может произойти всё что угодно (segfault, форматирование диска, аннигиляция Земли).
В реальности скорее всего будет сгенерировано обращение к адресу mass + 4. Этот адрес может принадлежать запущенному процессу, может не принадлежать - как повезет.
Если не принадлежит - то при попытке записи по нему ваш процесс упадет с segmentation fault. Если принадлежит - то запись по нему произойдет (и что будет происходить в коде дальше - неизвестно, потому что по этому адресу могло лежать что-то важное).

Но напрямую никакого механизма, отслеживающего что через указатель mass вы обращаетесь только к памяти, выделенной "под него", нет (в общем случае такое понятие вообще не определено). Есть разные дополнительные средства - например, AddressSanitizer или valgrind - которые созданы для поиска в том числе таких ситуаций. Но они слишком сильно замедляют работу (asan - в 2-3 раза, valgrind - в 10-50 раз), чтобы собирать под ними код в "боевом" режиме. А вот для отладки они очень полезны.

[ihq.pl]

боле мене понятно:) Спасиб.

[Dmitriy40]

На самом деле кроме стандарта есть ещё много тонких моментов, например большие куски памяти выделяются ОС выравненными на 16 байтовую границу. Возможно ваши массивы достаточно большие для этого ... И тогда если их размер не кратен 16, то остаток до этой границы будет вам фактически выделен и никакой ошибки защиты не будет. А может не будет и до 4КБ границы страницы памяти. В x64 системах память может выделяться вообще с выравниванием на 64КБ (и даже не контроллироваться страничным механизмом внутри этой грануляции). Но это со стороны ОС. Библиотеки же С могут память выделить и из своей "кучи", а вот там грануляция может зависеть например от версии компилятора и библиотеки (не уверен что это оговорено стандартом).
Я это к тому, что вовсе не обязательно обращение за пределами массива вызовет ошибку защиты памяти и полагаться на это нельзя. Даже для одного массива. Это в дополнение к причинам выше.

Насчёт контроля выхода за границы массива в runtime, в дельфи есть просто галка в настройках компилятора, range checking, к каждому обращению в массив добавляется код проверки индекса. Да, разумеется замедляет, но не так уж сильно (2-3 быстрых команд процессора на каждое обращение к массиву). Возможно в Вашем компиляторе С тоже есть подобное, даже без указанных инструментов.

[ihq.pl]

Dmitriy40 в сообщении #1268048 писал(а):

Я это к тому, что вовсе не обязательно обращение за пределами массива вызовет ошибку защиты памяти и полагаться на это нельзя.

Я в этом уже убедился. Стоило мне переместить наверх блок определения массивов tau, указанная ошибка исчезала, программа находила все нужные узлы решетки без проблем, даже в критическом случае, когда заданной длины массива ind_1 оказывалось недостаточно. После таких экспериментов начинаешь хорошо понимать, что такое bug.

[Dmitriy40]

(Оффтоп)

Да, я иногда жалею что i432 не получил распространения, там была аппаратная защита прав доступа каждого объекта, а не просто куска памяти. Включая отдельные переменные. И даже скопировать объект в другой можно было только при точном совпадении их типов. Ну и проверка границ массивов тоже очевидно была. Однако победила плоская модель памяти и теперь десятилетиями мучаемся в том числе с переполнениями буферов и прочими "прелестями" чрезмерного упрощения.

[realeugene]

(Оффтоп)

Dmitriy40 в сообщении #1268128 писал(а):

Включая отдельные переменные. И даже скопировать объект в другой можно было только при точном совпадении их типов. Ну и проверка границ массивов тоже очевидно была. Однако победила плоская модель памяти и теперь десятилетиями мучаемся в том числе с переполнениями буферов и прочими "прелестями" чрезмерного упрощения.

Кто мешает писать на Яве или Шарпе? "Прелести С" были заложены в язык by design. К простоте аппаратуры они отношения не имеют. Но простая аппаратура оказалась эффективнее, особенно, когда часть проверок можно выполнить на уровне компилятора.

[Dmitriy40]

(Оффтоп)

realeugene в сообщении #1269412 писал(а):

Кто мешает писать на Яве или Шарпе?

Скорость выполнения кода. Насчёт скорости C# не очень уверен, а вот Java вообще интерпретируемая (даже с JIT компиляцией). И не надо говорить мол "да кого волнует скорость выполнения", меня - волнует. Это можно заметить хотя бы по моим сообщениям с хештегом ASM или AVX.

[realeugene]

Dmitriy40 в сообщении #1269449 писал(а):

Скорость выполнения кода. Насчёт скорости C# не очень уверен, а вот Java вообще интерпретируемая (даже с JIT компиляцией).

Comsol Multiphysics написан на Java. Математические алгоритмы для него, возможно, на Фортране. Не знаю точно. Когда волнует скорость, алгоритмы нижнего уровня, перемалывающие данные, пишут на чём угодно (но обычно не на ассемблере), а скорость верхнего уровня никого уже не волнует, так как накладные расходы на него малы.

Ассемблер не позволяет компилятору оптимизировать код, Си содержит кучу низкоуровневых свойств, затрудняющих оптимизацию.

[Dmitriy40]

Вы правда думаете что сказали что-то не банальное?

[arseniiv]

(Оффтоп)

Dmitriy40 в сообщении #1269449 писал(а):

а вот Java вообще интерпретируемая (даже с JIT компиляцией)

Какое сочетание имеется в виду?

[Dmitriy40]

(Оффтоп)

arseniiv в сообщении #1269534 писал(а):

Какое сочетание имеется в виду?

Да в общем любое. Java же в принципе не в машинных кодах, обязательно есть этап компиляции (интерпретаторы не рассматриваем вообще), а из-за ограничений на его время компиляция не может быть достаточно оптимальной.
Хотя да, есть пара интересных идей, типа динамической перекомпиляции в зависимости от диаграммы мгновенных потоков данных, или генетические алгоритмы отбора оптимального варианта кода, но это всё хорошо на произвольных данных, а для заранее известных человек соптимизирует лучше (на ассемблере).
Впрочем, я мог и отстать от жизни, всё же мало сталкиваюсь с современными технологиями, а в моей области компиляторы это просто ужас что, прошлый век.

[realeugene]

Dmitriy40 в сообщении #1269600 писал(а):

а для заранее известных человек соптимизирует лучше (на ассемблере).

Давно уже не факт.