Здравствуйте, RailRoadMan, Вы писали:
RRM>Честно говоря, я все еще не понял проблемы? AVC>>Самое простой вопрос: как должен реагировать компилятор на следующие конструкции?
AVC>>void foo(int *p)
AVC>>{
AVC>> p[4] = 21; /* как узнать - массив p или нет? */
AVC>> p++;
AVC>>}
RRM>Он должен реагировать на эти конструкции, как это описано в стандарте (ну это в общем и без меня понятно).
Т.е. никак.
RRM>Массив или нет? Я всегда полагал, что подобные вопросы решаются в описании функции, которое в любом случае должно присутствовать и описывать, что делает эта функция. Программист, который пишет эту функцию должен знать, что он подразумавет под р.
Программист — человек. Он может ошибаться.
А вот что делать компилятору и отладчику?
RRM>Адресная арифметика — низкоуровневая возможностью. Вы считаете, что она вредна?
В том виде, как она реализована в Си, она безусловно вредна.
Я на эту тему уже много раз высказывался, и моя точка зрения не изменилась.
Ясно, что когда-то проход по массиву с перемещением указателя, а не индексной переменной, был эффективным решением.
Сейчас это уже не так (вспоминаю ассемблерный код, порожденный Watcom C++).
Потребности в адресной арифметике совсем бы не оставалось, если бы алгоритмы STL не подхватили эту форму записи. (Опять же для совместимости, надо думать.)
RRM>P.S. Возможно, что я что-то упускаю, но проблемы не вижу.
А она есть.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Не "никак", а "дословно" — есть разница.
RRM>>Массив или нет? Я всегда полагал, что подобные вопросы решаются в описании функции, которое в любом случае должно присутствовать и описывать, что делает эта функция. Программист, который пишет эту функцию должен знать, что он подразумавет под р.
AVC>Программист — человек. Он может ошибаться. AVC>А вот что делать компилятору и отладчику?
Компилятор — инструмент, и он не должен быть умнее разрабочика и как-то ограничивать его. Компилятору не дано знание, ошибся ли человек или сделал преднамерено.
RRM>>Адресная арифметика — низкоуровневая возможностью. Вы считаете, что она вредна?
AVC>В том виде, как она реализована в Си, она безусловно вредна. AVC>Я на эту тему уже много раз высказывался, и моя точка зрения не изменилась. AVC>Ясно, что когда-то проход по массиву с перемещением указателя, а не индексной переменной, был эффективным решением. AVC>Сейчас это уже не так (вспоминаю ассемблерный код, порожденный Watcom C++). AVC>Потребности в адресной арифметике совсем бы не оставалось, если бы алгоритмы STL не подхватили эту форму записи. (Опять же для совместимости, надо думать.)
Ситуации: необходимо работать с аппаратным буффером отображенным в память, который фактически является массивом значений (только эти значения находятся не в памяти, а в друггом железе, и формируются не программой, а как раз этим железом). Как эта ситуация может быть обработана без использования адресной арифметики в стиле С ? Если сипользовать, то мы просто приводим указатель на буффер к указателю на элемент нужного типа и далее работаем с массивом, через этот указатель.
Или буффер куда данные попадают из аппаратуры через DMA.
Возможно приведенные примеры мало относятся к разработке приложения, но ведь есть еще драйвера и встроенные системы.
Здравствуйте, Cyberax, Вы писали:
C>AVC пишет: >>>> А как же совместимость? >>>> (Вот, говорят, Модула-2 — это плохо, т.к. несовместимо с Паскалем.) >> C>Так вот поэтому ВСЕ и не переписывают >> Тут не вполне ясно. >> Специально не переписывают что-то с Фортрана на Си++, чтобы сохранить >> совместимость? C>Да, много фортрановского софта не переписывают на другие языки из-за C>библиотек.
В принципе, это не так страшно. Ведь к фортрановским библиотекам можно обращаться и из других языков. Например, из Си. Или из Оберона. (Что, опять же, показывает несостоятельность "теории совместимости".)
>> Как бы-то ни было, если на вопрос "Зачем Си++" отвечают "Потому что >> Си", то возникает следующий вопрос: "Зачем Си?" C>Потому что на нем к середине 80-х годов было уже написана и работала C>большая часть софта.
Говорят, что большая часть софта была написана на Коболе.
>> Зачем вообще что-то кроме Фортрана, *если уж так важна совместимость*? C>Не весь софт изначально делался на Фортране.
Это лапидарное изречение вполне достойно пополнить томик Козьмы Пруткова.
Изначально софт делался в машинных кодах.
Но все же именно Фортран был первым "языком высокого уровня", если не ошибаюсь?
И кода на нем немеренно.
Значит, надо было хранить ему верность из соображений совместимости. (Я развиваю тезис, что виртовские языки плохи, т.к. несовместимы. Хотя каждый, кто пользовался компилятором XDS, знает, что, например, Modula-2 и Oberon-2 прекрасно совместимы.)
Ан нет, не утерпели.
Говорят — неудобно на нем писать нерасчетные программы.
И поперли изо всех щелей — Лисп, Кобол и т.д.
И сказали С++ные программисты, что это хорошо. А вот Оберон — плохо.
Кстати, нормальные компиляторы Оберона (тот же XDS) предоставляют возможность использовать хоть сишный код, хоть фортрановский.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC пишет:
>>> Специально не переписывают что-то с Фортрана на Си++, чтобы сохранить >>> совместимость? > C>Да, много фортрановского софта не переписывают на другие языки из-за > C>библиотек. > В принципе, это не так страшно. Ведь к фортрановским библиотекам можно > обращаться и из других языков. Например, из Си. Или из Оберона. (Что, > опять же, показывает несостоятельность "теории совместимости".)
Ага, а еще можно в Формулу-1 играть на асфальтовом катке. Фортран
оптимизирован под скоростные вычисления так, что его еще никто не
обогнал, а такой мост съест всю скорость.
>>> Как бы-то ни было, если на вопрос "Зачем Си++" отвечают "Потому что >>> Си", то возникает следующий вопрос: "Зачем Си?" > C>Потому что на нем к середине 80-х годов было уже написана и работала > C>большая часть софта. > Говорят, что б*о*льшая часть софта была написана на Коболе.
Он жил (и продолжает жить) в отдельном мире, не оказывая сильного
влияния на остальной.
> Говорят — неудобно на нем писать нерасчетные программы. > И поперли изо всех щелей — Лисп, Кобол и т.д. > И сказали С++ные программисты, что это хорошо. А вот Оберон — плохо.
Именно.
> Кстати, нормальные компиляторы Оберона (тот же XDS) предоставляют > возможность использовать хоть сишный код, хоть фортрановский.
RRM>Ситуации: необходимо работать с аппаратным буффером отображенным в память, который фактически является массивом значений (только эти значения находятся не в памяти, а в друггом железе, и формируются не программой, а как раз этим железом). Как эта ситуация может быть обработана без использования адресной арифметики в стиле С ? Если сипользовать, то мы просто приводим указатель на буффер к указателю на элемент нужного типа и далее работаем с массивом, через этот указатель.
RRM>Или буффер куда данные попадают из аппаратуры через DMA.
RRM>Возможно приведенные примеры мало относятся к разработке приложения, но ведь есть еще драйвера и встроенные системы.
Достаточно легко. Сериализация дессериализация. Скорость копирования достаточно большая и учитывая что данные находятся в кэше.
Но зато есть контроль над массивом буфера.
Например массивы тоже легко обходятся без указателей, при этом оптимизируется проход по массиву аля P++ с контролем границ не на каждом шагу а на этапе for.
Другой пример легче использовать массив строк чем буффер строк разделенными 0
Итд. Большую часть оптимизации можно доверить компилятору.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
RRM>>Ситуации: необходимо работать с аппаратным буффером отображенным в память, который фактически является массивом значений (только эти значения находятся не в памяти, а в друггом железе, и формируются не программой, а как раз этим железом). Как эта ситуация может быть обработана без использования адресной арифметики в стиле С ? Если сипользовать, то мы просто приводим указатель на буффер к указателю на элемент нужного типа и далее работаем с массивом, через этот указатель.
RRM>>Или буффер куда данные попадают из аппаратуры через DMA.
S> Достаточно легко. Сериализация дессериализация. Скорость копирования достаточно большая и учитывая что данные находятся в кэше.
Не очень понял при чем здесь сериализация А также кэш, память на которую отображены аппаратные регистры и буферы вообще должна быть объявлена некэшируемой (как привило).
S> Но зато есть контроль над массивом буфера.
Про контроль не очень понял. Поподробнее пожалуйста. Как вообще то, что вы описали относится к ситуации описанной мной? Как вы предлагаете работать с аппартным массивом или буффером DMA, без адресной арифметики?
Здравствуйте, RailRoadMan, Вы писали:
AVC>>Т.е. никак. RRM>Не "никак", а "дословно" — есть разница.
В данном случае стандарт Си никак не различает разные типы аргументов-указателей.
Поэтому я и написал: "никак".
RRM>>>Массив или нет? Я всегда полагал, что подобные вопросы решаются в описании функции, которое в любом случае должно присутствовать и описывать, что делает эта функция. Программист, который пишет эту функцию должен знать, что он подразумавет под р. AVC>>Программист — человек. Он может ошибаться. AVC>>А вот что делать компилятору и отладчику? RRM>Компилятор — инструмент, и он не должен быть умнее разрабочика и как-то ограничивать его. Компилятору не дано знание, ошибся ли человек или сделал преднамерено.
Опаньки!
Куда ему, компилятору.
Т.е. Вы отрицаете возможность использовать избыточную информацию, благодаря которой языки высокого уровня и позволяют бороться с ошибками?
RRM>Ситуации: необходимо работать с аппаратным буффером отображенным в память, который фактически является массивом значений (только эти значения находятся не в памяти, а в друггом железе, и формируются не программой, а как раз этим железом). Как эта ситуация может быть обработана без использования адресной арифметики в стиле С ? Если сипользовать, то мы просто приводим указатель на буффер к указателю на элемент нужного типа и далее работаем с массивом, через этот указатель. RRM>Или буффер куда данные попадают из аппаратуры через DMA. RRM>Возможно приведенные примеры мало относятся к разработке приложения, но ведь есть еще драйвера и встроенные системы.
Никто не отрицает потребности в низкоуровневых средствах.
Но нельзя же превращать весь язык в одно низкоуровневое средство!
В Обероне есть четкое различие: "импорт" SYSTEM.
А в Си низкоуровневые средства "заполонили" весь язык.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, RailRoadMan, Вы писали:
S>> Но зато есть контроль над массивом буфера. RRM>Про контроль не очень понял. Поподробнее пожалуйста. Как вообще то, что вы описали относится к ситуации описанной мной? Как вы предлагаете работать с аппартным массивом или буффером DMA, без адресной арифметики?
Хотелось бы уточнить, одинаково ли мы понимаем термин "адресная арифметика"?
В Си так называют операции сложения/разности указателя с целым числом (результат — указатель) и разности указателей (результат — целое число).
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
S>> Достаточно легко. Сериализация дессериализация. Скорость копирования достаточно большая и учитывая что данные находятся в кэше. RRM>Не очень понял при чем здесь сериализация А также кэш, память на которую отображены аппаратные регистры и буферы вообще должна быть объявлена некэшируемой (как привило).
Я имел ввиду такую ситуацию http://gzip.rsdn.ru/forum/?mid=556030
S>> Но зато есть контроль над массивом буфера. RRM>Про контроль не очень понял. Поподробнее пожалуйста. Как вообще то, что вы описали относится к ситуации описанной мной? Как вы предлагаете работать с аппартным массивом или буффером DMA, без адресной арифметики?
То есть с массивом без адресной арифьетики некуда????
Есть базовый адресс и размерность.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AVC, Вы писали:
AVC>Здравствуйте, RailRoadMan, Вы писали:
RRM>>>>Массив или нет? Я всегда полагал, что подобные вопросы решаются в описании функции, которое в любом случае должно присутствовать и описывать, что делает эта функция. Программист, который пишет эту функцию должен знать, что он подразумавет под р. AVC>>>Программист — человек. Он может ошибаться. AVC>>>А вот что делать компилятору и отладчику? RRM>>Компилятор — инструмент, и он не должен быть умнее разрабочика и как-то ограничивать его. Компилятору не дано знание, ошибся ли человек или сделал преднамерено.
AVC>Опаньки! AVC>Куда ему, компилятору. AVC>Т.е. Вы отрицаете возможность использовать избыточную информацию, благодаря которой языки высокого уровня и позволяют бороться с ошибками?
Нет не отрицаю, но при этом не вижу смысла забирать низкоуровневые возможности.
RRM>>Ситуации: необходимо работать с аппаратным буффером отображенным в память, который фактически является массивом значений (только эти значения находятся не в памяти, а в друггом железе, и формируются не программой, а как раз этим железом). Как эта ситуация может быть обработана без использования адресной арифметики в стиле С ? Если сипользовать, то мы просто приводим указатель на буффер к указателю на элемент нужного типа и далее работаем с массивом, через этот указатель. RRM>>Или буффер куда данные попадают из аппаратуры через DMA. RRM>>Возможно приведенные примеры мало относятся к разработке приложения, но ведь есть еще драйвера и встроенные системы.
AVC>Никто не отрицает потребности в низкоуровневых средствах. AVC>Но нельзя же превращать весь язык в одно низкоуровневое средство! AVC>В Обероне есть четкое различие: "импорт" SYSTEM. AVC>А в Си низкоуровневые средства "заполонили" весь язык.
А С и разрабатывался как алтернатива ассеблеру. Кстати есть С++, и там вас никто не вынуждает использовать массивы, есть например vector<> + все нискоуровневые возможности С.
Согласитесь, что вы не против адресной арифметики, а против ее повсеместного и неуместного применения.
Еще мне кажется, что использование адресной арифметики в стиле С несколько проще, чем модуля SYSTEM (по крайне мере там, где это необходимо)
Здравствуйте, RailRoadMan, Вы писали:
RRM>>>>>Массив или нет? Я всегда полагал, что подобные вопросы решаются в описании функции, которое в любом случае должно присутствовать и описывать, что делает эта функция. Программист, который пишет эту функцию должен знать, что он подразумавет под р. AVC>>>>Программист — человек. Он может ошибаться. AVC>>>>А вот что делать компилятору и отладчику? RRM>>>Компилятор — инструмент, и он не должен быть умнее разрабочика и как-то ограничивать его. Компилятору не дано знание, ошибся ли человек или сделал преднамерено. AVC>>Опаньки! AVC>>Куда ему, компилятору. AVC>>Т.е. Вы отрицаете возможность использовать избыточную информацию, благодаря которой языки высокого уровня и позволяют бороться с ошибками? RRM>Нет не отрицаю, но при этом не вижу смысла забирать низкоуровневые возможности.
Низкоуровневые возможности (low-level facilities) иногда совершенно незаменимы.
Но они таят в себе опасность, т.к. программист отключает "автопилот" системы типов.
В Обероне низкоуровневые средства языка используются, в основном, в небольшом числе модулей, относящихся к операционной системе. Такие модули легко распознаются по импорту модуля SYSTEM.
В Си использование низкоуровневых средств языка разбросано по всему коду. Например, любая передача указателя в качестве параметра чревата неверным его использованием.
Искать ошибки (особенно случайные) в таких условиях гораздо труднее.
AVC>>Никто не отрицает потребности в низкоуровневых средствах. AVC>>Но нельзя же превращать весь язык в одно низкоуровневое средство! AVC>>В Обероне есть четкое различие: "импорт" SYSTEM. AVC>>А в Си низкоуровневые средства "заполонили" весь язык. RRM>А С и разрабатывался как алтернатива ассеблеру. Кстати есть С++, и там вас никто не вынуждает использовать массивы, есть например vector<> + все нискоуровневые возможности С.
Мне кажется, что мы говорим не совсем об одних и тех же вещах.
Как будто мы испольуем одни и те же слова, но вкладываем в них разный (отчасти?) смысл.
Возможно, нам надо просто уточнить терминологию, и, может статься, выяснится, что в принципе мы согласны.
Попытаюсь проиллюстрировать свою мысль на примере этого Вашего предложения.
Вы говорите, что в Си++ необязательно использовать массивы, а можно использовать векторы или другие контейнеры STL.
У меня складывается впечатление, что Вы (почти) отождествляете адресную арифметику и массивы.
Если это так, то во многом проясняется причина "дискуссии".
В Си++ использование "сишных" массивов действительно считается средством низкого уровня.
Ведь в Си выражение a[ i ] == *(a + i) == *(i + a) == i[a].
Т.е. это частный случай применения адресной арифметики. Возможно, Вы и говорите просто об употреблении массивов, и удивляетесь, как это я без них обхожусь.
А я и не обхожусь, ни на Си, ни на Обероне.
Просто на Обероне использование массива не является низкоуровневой конструкцией, и полностью контролируется компилятором. (Вот в чем значение избыточности. Массив в Обероне — везде массив. А не какой-то там указатель. )
Почти то же самое бывает и в Си. Например:
void foo()
{
int i, a[10];
for (i = 0; i < 10; ++i)
a[i] = i;
bar(a);
}
Здесь компилятор точно знает, что имеет дело с массивом, и может не допустить обращение к элементу массива с недопустимым индексом.
Но стоит передать этот массив в качестве параметра, вся эта информация теряется.
Уже в функции bar все выглядит по-другому.
void bar(int *a)
{
}
Что такое здесь a? Массив? Адрес скалярной переменной? Адрес объекта кучи?
Компилятор не знает. А значит не может контролировать корректность действий программиста.
Именно поэтому использование массивов в Си (как и весь язык в целом) относится к низкому уровню.
RRM>Согласитесь, что вы не против адресной арифметики, а против ее повсеместного и неуместного применения.
Согласен.
RRM>Еще мне кажется, что использование адресной арифметики в стиле С несколько проще, чем модуля SYSTEM (по крайне мере там, где это необходимо)
Вероятно, это вопрос привычки.
Я, например, действительно привык к адресной арифметике в Си.
Первое время именно использование модуля SYSTEM мне давалось с некоторым усилием.
Рука "сама" выводила Си-подобные конструкции.
(Интересно, что программирование без использования SYSTEM не вызвало у меня ни малейших затруднений.
Начал писать на Обероне с первого дня знакомства с ним. Причем не Out.String("Hello, world!"), а сразу системы линейных уравнений и т.п. То ли Оберон соответствует моей интуиции, то ли сказывается его систематическая простота.)
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Возможно. Важны факторы, принимаемые во внимание.
и как ни странно, в число этих факторов никогда не входили такие параметры, как "чистота", "стройность" языка, и прочие спорные вещи
AVC>Вы, часом, — не консервативный гегельянец, не полагаете, что "все разумное — действительно, все действительное — разумно"?
вы, батенька, нецензурными словами не ругайтесь
AVC>И какая, пардон, связь? AVC>Вас же не удивляет компиляция в машинный код? AVC>А теперь представьте себе, что какой-нибудь компьютер "понимает" Си++, Си или даже (вот ужас! ) Оберон.
Связь в том, что просто перевод с одного языка на другой не даст тебе работающую программу. Это — ничтожно малая часть работы, а дьявол — он совсем в другом.
Например, перенос программы с C++ под Windows на тот же C++, но под Linux — это очень большой объем работы. Странно, не правда ли?
AVC>Т.к. я многодетный отец , то этот вопрос для меня не праздный. AVC>Плюс — у моей жены есть медицинское образование.
А это уже смахивает на паранойю.
AVC>"Тешь себя, тешь себя" (поглаживает) (с) "Ирония судьбы"
Не смешите мои тапочки. Эта тема уже десять раз тут обсасывалась. Ключевые слова для поиска — "мощность языка"
Здравствуйте, AVC, Вы писали:
AVC>Кстати, нормальные компиляторы Оберона (тот же XDS) предоставляют возможность использовать хоть сишный код, хоть фортрановский.
Угу. Только ко времени их появления Оберон уже благополучно скончался.
Здравствуйте, AVC, Вы писали:
AVC>Я согласен, что хорошая голова — главное в любом деле. Но не согласен с подтекстом Вашего утверждения, что если голова хорошая, то и любой инструмент сойдет.
AVC>Есть у Сутеева такая сказка — "Палочка-выручалочка". (Прошу прощения за детские ассоциации. Моему младшему — три, вот и штудируем "классиков". :) ) AVC>Там в самом конце высказывается мысль, родственная Вашей: главное — умная голова и доброе сердце. Это, бесспорно, — главное. Но как бы ежик без этой палки зайца из болота вытянул и от волка спас? :xz:
А если продолжить? Если мне жизненно необходимо сейчас отстрелить себе ногу?
P>>Не обязательно хороший архитектор должен быть хорошим каменщиком. P>>В программировании — то же самое. Кстати, в проекте, в котором я сейчас работаю, если бы его главный архитектор не садился сам за реализацию своих идей, нашей команде было бы гораздо легче жить.
AVC>Не уверен, что метафора об архитекторе и каменщике применима к области ПО.
Есть опыт участия в двух подобных проектах. В первом случае архитектор и не пытался писать код. Он был банкиром. Тем не менее, ему удавалось координировать действия команд разработчиков так, что в итоге получился хорошо документированный и легкий в обслуживании пакет программ.
Во втором случае архитектор не доверил реализацию своих замыслов никому. В результате сейчас приходится разбираться в процедурах по 1500 — 2500 строк с кучей GOTO, сотнями глобальных переменных и константами с именами ONE, TWO, ..., TWENTY, ... .
AVC>А сколько, интересно, стоит такой переход? AVC>Вот что я вижу: для каждого приличного языка существует (библиотечная) поддержка практически всех известных алгоритмов. И возникает такая поддержка очень быстро.
Она же не сама возникает. И в новой системе, несовместимой с предыдущими, не так уж и быстро. Фактически это означает создание с нуля всей операционной систены со всеми инструментальными средствами.
AVC>Кроме того, существует множество конверторов с языка на язык.
Отлично, пишем конвертор с C++ на Оберон. В качестве теста используем STL.
AVC>(Некоторое исключение из этого правила составлял, пожалуй, лишь Фортран.)
AVC>Вообще-то, ИМХО, со стороны Bell Labs против Вирта велась "необъявленная война". :)
[....]
Тогда обе стороны высыпали друг на друга достаточно гнилых помидоров. Но не будете же Вы всерьез утверждать, что Керниган заставлял разработчиков во всем мире использовать C, а не Модулу-2?
И почему в 1990 г. из известных (рекламируемых) систем программирования была 1 Модула-2 (TopSpeed), и около 15 C/C++. Это что, тлетворное влияние Bell Labs?
P>>P. S.
AVC>Книги под рукой прямо сейчас нет. AVC>Читал я, однако, достаточно внимательно. AVC>Так что помню, говорилось о "гибкости и мощности" языка, а главное — о доступности компиляторов. (Хотя ко времени выхода книги еще не существовало компиляторов Си++, соответствующих стандарту. Это по оценкам знатоков Си++.) AVC>А потом — процитированный мной абзац, делающий бессмысленными (ИМХО) все предыдущие славословия.
Не славословие, а обоснование принимаемого решения. не забываем, что авторы книги — не профессиональные программисты, а астрономы. Они не делали программный продукт. Они пытались переложить на машину рутинную работу, освободив себе время для творческой. В полном соответствии с принципом, провозглашенным IBM: "Машина должна работать, человек — думать".
О недостатках языка, ИМХО, они сказали таким же, как они, математикам, физикам, астрономам.
Программисты об этих недостатках знают, а "кто предупрежден — тот вооружен", не так ли?
И, кстати, перешли они с надежного Паскаля на дефектный C...
Здравствуйте, Cyberax, Вы писали:
>> Может быть, в таком случае стоило остановиться на Фортране?
C>Интересно, почему же большую часть научного софта до сих пор на нем C>пишут?
Тот софт для суперкомпьютеров, в то время как для PC научный софт пишут на модификации языка Oberon-2 под названием Component Pascal (http://www.inr.ac.ru/~info21/).
Здравствуйте, Cyberax, Вы писали:
>>SomeObject *obj=new SomeObject(); >>static int ref=(int)obj; >> >> C>вызовет _утечку_ _памяти_. >> Именно _такого_ — не вызовет.
C>А если убрать static, то вызовет (до выхода из стекового фрейма)
Что Вы такое выдумываете! Нет, не вызовет!!!
В переменной int ref хранится численное значение указателя obj взятое в момент выполнения операции присваивания int ref=(int)obj. В следующий момент времени, вообще говоря, численное значение указателя obj может быть любым другим т. к. сборщик мусора может переместить объект в другое место. Число хранящееся в целочисленной переменной int ref останется прежним, сборщика мусора это число не интересует. Если Вы когда-нибудь потом (после нескольких запусков GC) захотите превратить число int ref обратно в указатель — то этот указатель будет 100% повисшим.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Cyberax, Вы писали:
>>> Может быть, в таком случае стоило остановиться на Фортране?
C>>Интересно, почему же большую часть научного софта до сих пор на нем C>>пишут? ;)
СГ>Тот софт для суперкомпьютеров, в то время как для PC научный софт пишут на модификации языка Oberon-2 под названием Component Pascal (http://www.inr.ac.ru/~info21/).
Сколько в лаборатории матмоделирования работал (на PC), столько там Фортран и использовался.
Что, для суперкомпьютеров реализаций Оберона не Существует? А что мешает?
Здравствуйте, AVC, Вы писали:
AVC>В принципе, идея мне кажется разумной. AVC>Но что особенно радует в предлагаемом подходе — его простота.
Добрая ирония
На самом деле, я здесь просто глубже развил парадигму "доступ по указателю". Если развивать парадигму "доступ через функции", то получим другую картину.
AVC>Правда, в Обероне таких проблем вообще нет. (Он просто грамотно сделан.) AVC>Но ведь это такой скучный язык. AVC>А вот Си++ — это романтика.
На самом деле, указатели в Си — с одной стороны, крайне небезопасный, а с другой — очень выразительный механизм, в том числе — механизм абстракции.
Как в языках со слабой типизацией абстрагируются от типа данных, так в Си (ещё не С++) — от размещения данных.
В обоих случаях — это паттерн "простота (хуже воровства)", для слабо типизированных языков — получается более простой транслятор, для Си — облегчённый рантайм.
Красивое развитие идеи указателей — это итераторы STL. Хотя с таким же, а то и с большим успехом можно было вместо итераторов ввести понятие "диапазон", и такие попытки делаются.
Оберон — да, действительно скучный язык. Типизацией по пальцам надавал, размещением по пальцам надавал, а средств абстракции — не надавал
AVC>Ну где еще можно "зацепить" один поток за стековую переменную другого потока? Такая прелесть!
Здравствуйте, RailRoadMan, Вы писали:
RRM>Ситуации: необходимо работать с аппаратным буффером отображенным в память, который фактически является массивом значений (только эти значения находятся не в памяти, а в друггом железе, и формируются не программой, а как раз этим железом). Как эта ситуация может быть обработана без использования адресной арифметики в стиле С ? Если сипользовать, то мы просто приводим указатель на буффер к указателю на элемент нужного типа и далее работаем с массивом, через этот указатель.
Например, вместо модели "Итератор произвольного доступа" (частным случаем которого является указатель) мы используем модель "Диапазон с доступом по индексу".
Выражаясь на С++,
typedef unsigned long address_t; // предположим, что это такой встроенный типtemplate<class T>
class range
{
public:
range(address_t start, int count); // конструктор низкого уровня
range(T& var); // диапазон доступа к одиночному объектуtemplate<int C> range(T array[C]); // диапазон доступа к массивуint count() const;
T& operator[](int index) const;
range subrange(int offset, int count) const;
range domain() const; // возвращает полный диапазонprivate:
address_t start_; int total_; // полный диапазонint offset_, count_; // действующий диапазон
};
Сергей Губанов пишет:
>>>SomeObject *obj=new SomeObject(); >>>static int ref=(int)obj; >>> >>> C>вызовет _утечку_ _памяти_. >>> Именно _такого_ — не вызовет. > C>А если убрать static, то вызовет (до выхода из стекового фрейма) > Что Вы такое выдумываете! *Нет, не вызовет!!!* > В переменной int ref хранится численное значение указателя obj взятое > в момент выполнения операции присваивания int ref=(int)obj. В > следующий момент времени, вообще говоря, численное значение указателя > obj может быть любым другим т. к. сборщик мусора может переместить > объект в другое место.
А вот фигвам. GC в той реализации Оберона, которую я смотрел,
обрабатывает стек консервативно. То есть любая последовательность байт
на стеке, которая напоминает указатель — будет считаться указателем.
Причем такие объекты, естественно, двигаться в куче никуда не будут.
> Число хранящееся в целочисленной переменной int ref останется прежним, > сборщика мусора это число не интересует. Если Вы когда-нибудь потом > (после нескольких запусков GC) захотите превратить число int ref > обратно в указатель — то этот указатель будет 100% повисшим.
А также кэш, память на которую отображены аппаратные регистры и буферы вообще должна быть объявлена некэшируемой (как привило).
Перекуём баги на фичи!
