Здравствуйте, tarkil, Вы писали:
T>Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!
Delphi. Начиная, если не путаю, с 4 не то 5.

type MyInt = type int

Здравствуйте, Трурль, Вы писали:

Т>Здравствуйте, raskin, Вы писали:

R>>Для Integer — пойдёт на ура, насколько я помню.
Т>Вот только, если определить
Т>

type MyType=Integer;

Т>то MyType становится неотличим от Integer и можно использовать один вместо другого.

Верно, но только если опустить второй type:

type MyType= type Integer;

FDSC wrote:

> C>Ну и в чем тут компилятор поможет? Чистая логическая ошибка времени
> C>исполнения.
> Логических ошибок времени исполнения не бывает. Компилятор должен
> указать мне, что такая возможность у пользователя есть, иначе мне
> придётся искать её самому (это тяжело, правда).

Это невозможно в принципе в общем случае, а лишь в некоторых частных
случаях и со знанием семантики приложения.

> C>Два случая:
> C>1. Ассемблера мало — так вынесите его в отдельный файл и нечего ради
> C>этого уродовать язык.
> C>2. Ассемблера много — точно надо выносить в отдельный файл.
> Тут прикол в том, что я рад бы от него вообще избавиться.

А зачем? Пусть себе живет там, где он нужен.

> C>А если у меня PPC? Или Amd64 или Itanium?
> Amd64 то же совместимый с Intel x86.

С большими (и влияющими на производительность) оговорками.

> С Itamium наши пользователи никогда не работают. Да и Delph то же.

Ну вот, сами себя ограничиваете.

> В этом и прикол, нужно, что бы можно было оптимизировать код не уродуя
> его и прямо в нём.

Тогда надо смотреть язык С — в нем есть почти все для низкоуровневой
оптимизации.

>>> Ничего себе небольшие — час или 15 минут!
> C>Крайне редкий случай — обычно выигрыш в десятки процентов.
> В некотрых приложениях сплошь и рядом (всё равно редко, но очень
> значительно). Особенно в Delphi.

Ну так давно пора ее выбросить.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>FDSC wrote:

>> Вся "винда" проверяется с помощью систем автоматической проверки
>> (существует два поколения таких систем). Это очень серьёзно. Если бы у
>> меня такие были (желательно, бесплатно), я бы сейчас не нервничал.

C>Эта система называется 'lint' И толку от нее ~0.



Нет. Первое поколение: PREfix и PREfast.
Второе поколение: Slam, ESP и Vault.

Здравствуйте, Cyberax, Вы писали:

C>FDSC wrote:

>> C>Ну и в чем тут компилятор поможет? Чистая логическая ошибка времени
>> C>исполнения.
>> Логических ошибок времени исполнения не бывает. Компилятор должен
>> указать мне, что такая возможность у пользователя есть, иначе мне
>> придётся искать её самому (это тяжело, правда).

C>Это невозможно в принципе в общем случае, а лишь в некоторых частных
C>случаях и со знанием семантики приложения.

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

По ассемблеру не согласен, но разумного ничего сказать не могу (да и не я решаю: выбрасывать Delphi или нет).

Здравствуйте, FDSC, Вы писали:

FDS>Я встречал, когда конструктор вызывается 1 раз, а деструктор — 100 000 раз (буквально, в мае). Но чтоб деструктор впереди конструктора.....
Вот только в С++ с этим проблем нет. Ибо деструкторы автоматические те за их вызовами следит компилятор.

Здравствуйте, Дарней, Вы писали:

>>> 4. IDE реализует сам код, как граф. Названия методов даются как
>>> справочная информация для программиста, могут меняться автоматически.

C>>Было такое в Together и Rational Rose — успешно провалилось как
C>>неудобное и неюзабельное решение.

Д>очень интересно. а можно подробнее?

Изменять имена методов может любая утилита рефакторинга. Тут ЮМЛ-и и на фиг не уперлись.

Здравствуйте, Дарней, Вы писали:

Д>Ну это ты зря. Текущие проблемы — это только проблемы кривых реализаций

Возможно. Вот бы на одну прямую глянуть.

Здравствуйте, FDSC, Вы писали:

FDS>Вся "винда" проверяется с помощью систем автоматической проверки (существует два поколения таких систем). Это очень серьёзно. Если бы у меня такие были (желательно, бесплатно), я бы сейчас не нервничал.

А я бы нервнечал. Уж больно в ней много глюков.

Здравствуйте, FDSC, Вы писали:

FDS>Нет. Первое поколение: PREfix и PREfast.
FDS>Второе поколение: Slam, ESP и Vault.

PREfast входит в VS 2005. Но это довольно примитивное средство контроля. Своеобразный FxCop для анменеджед-кода. В МС вроде и посерьезнее были средства.

Здравствуйте, WolfHound, Вы писали:

VD>>Значит ты еще не все встречал. встречал когда конструктор вызывался дважды, а деструктор раз десять, и все это для одного экземпляра. В общем, С++ рулит адназначна.
WH>Я такое встречал только в багландовском компиляторе, а он известен тем что в нем очень много ошибок.
WH>Короче не надо говорить про С++ то чего нет.

Там компилятор был не причем. Там были махинации со своим пулом памяти и вручную вызывались деструкторы. Конструктор же вызывался дважды из-за прохода по памяти в одном из деструкторов (или еще где... уже не помню).

Здравствуйте, FDSC, Вы писали:

S>>Да сколько угодно. Вон, в форуме Delphi регулярно предлагают конструктор поместить внутрь try, а free — в finally вот тебе и деструктор без конструктора...

FDS>Класс..

Ага. Высший.

Здравствуйте, WolfHound, Вы писали:

WH>Вот только в С++ с этим проблем нет. Ибо деструкторы автоматические те за их вызовами следит компилятор.

Гы-гы:

class A
{
    A() { } // скрытый !!! :)
public:
    ~A()
    {
        printf("Goddammit! This is not supposed to happen!!!\n");
    }
};

void main()
{
    for (int i = 0; i < 10; i++)
        ((A*)&i)->~A();
}

И что самое поскудное — это же совершенно корректный код .

Здравствуйте, FDSC, Вы писали:

FDS>К сожалению я мало программировал на C#. По моему, там вообще приведение типов используется "в принципе" осторожнее.
FDS>Вообще, я скажу, проектирование программы на C++ и C# просто абсолютно разные вещи.

Не совсем. Конечно на стиль языки влияют, но почему-то мне кажется, что человек после хорошей школы Шарпа будет и на С++ писать намного качественее. Шарп он подталкивает к более грамотному проектированию... к использованию ООП, безопасным приемам и т.п.

FDS> Я когда учил C# голову чуть не сломал.

Очень странно. Многие находят изучение этого языка очень простым. Причем именно потому, что он очень логичен и интуитивен.

FDS>>>Я только пытался её провести (статистику). Такая чушь получилась, если честно, не хочеться показывать, обсмеёте.

VD>>Не, ну, все же интересно...

FDS>Привожу, что от неё осталось (кстати, это в основном были интерфейсные приложения), ошибки в порядке убывания значимости:
FDS>0. Разнообразные ошибки.

FDS>1. Ошибки при отладке, от усталости и при внесении изменений (после цикла при добавлении команд забыты скобки; функция закомментирована при отладке и забыта; функция делает не то, что написано в названии; дважды вызвана очистка памяти; вызвана не та функция очистки памяти (это и к п. 5); функция очистки памяти вызвана для каждого элемента массива, хотя должна была только для всего массива; функция вообще не документирована и потеряна и т.п.) (у всех и всегда, по количеству ошибок, около половины от всех (включая п. 0))

FDS>2. Отсутствие доказанного математического алгоритма вплоть до процесса отладки. Полное незнание предметной области. Непонимание предметной сущности объекта. Путаница в порядках следования индексов свойств-массивов и правилах их перестановки.
FDS>Сюда же: неполная проработка проблемы перед кодированием: обычно ведёт к конфликтным ситуациям с объектами, зависанию приложения в бесконечном цикле или другим "экспрессивным" ошибкам. (очень часто)

FDS>3. Слшком сильная иерархичность доступа к объектам => запутанный код. Слишком сильное разделение на
FDS>приложения на слои. Наличие централизованного хранилища информации, не привязанного ни к одному физическому представлению (ввод пользователя, диск, обработка, вывод пользователя), что вводило лишние преобразования объектов в программу.
FDS>(тотально у всех программистов — непрофильных выпускников с опытом менее 1-3 года (за редким искл.), или профильных с опытом менее 1 — 1,5 года (у всех, видимо отличные в фирму не идут — идут куда получше))

FDS>4. Обнуление полезной информации, в следствие вызова метода инициализации после считывания информации. Проверка на корректность данных, которые должны быть или могут быть некорректны (у всех программистов, обычно в каждом приложении или через раз (у неопытных гораздо чаще)).

FDS>5. Неправильные вызовы функций из других библиотек (несогласование типов и методов выделения памяти), забытые stdcall и pascal (удивительно, даже у довольно опытных программистов).
FDS>Сюда же: неправильные преобразования типов в межмодульных связях. Т.е., например, в одном модуле загружается однобайтовое значение в 4-байтовый стек, старшие байты не инициализированы. Другой модуль читает все 4-байта. (редко)


Прочита по внимателнее свой список. Он конечно хаотичен, но одна тенденция в нем прослеживается. Буквально половина ошибок — это ошибки связанные с неверным использованием типов. Все эти "два раза освободил", "вышел за пределы массива" и т.п. все это следствие некоррекной работы с типами и всего этого можно избежать.

FDS>Я об этом и говорю. Но стремиться нужно к полной автоматизации кодирования (интересно, меня тогда уволят?

Да.

FDS> Я ведь кодировщик, типичный).

Не бойся. Полной автоматизации не бывает. Даже генератор кода нужно писать. Так что можно добиться повышения уровня разработки, но от самого процесса разработки уйти нельзя. Правда прцесс разработки можно визуализировать или заменить на универсальные рещения. Но это уже прикладные решения и их самих нужно программировать.

FDS>Со сборщиками мусора я в C# то же намучился, но кажется понял — легко и удобно, но очень убого.

Что же там убогого? С тебя просто снимают лишнюю заботу. Единственная проблема сборщиков мусора — это сильный расход памяти. В остальном — это очень удобное и правильное решение.

FDS> Уж тогда бы сразу на аппаратном уровне сделали. Мне, как assembler-программисту, пусть и микроконтроллеров, жутко на это смотреть.

На аппоратном уровне это конечно здорово. Но пока и так неплохо. Возможно когда нибудь сделают (если это даст выигрыш).

FDS>Кстати, до сих пор не могу понять, почему компилятор не может сам контролировать выделение памяти, особенно, когда на этапе компиляции уже всё понятно.

Компилятор и контролирует. Только не тот что текст на токины и ветки AST крамсает. А тот который из промежуточного кода в рантайме машинный код строит. GC — это очень сложный механизм и JIT-компилятор внем один из главных элементов. Он строит карты доступности и делает кучу разных оптимизаций.

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

FDS> А если не понятно, опять же компилятор может вставить код — счётчик ссылок (другое дело — такой код уже сложно сделать в общем случае, нужен анализ копирования с копии и т.п. Но ведь это возможно).

Счетчик ссылок — это:
1. Довольно медленно. Сборщик мусора работает значитльно быстрее чем счетчики ссылок в скриптовых языках или КОМ-е.
2. Не решает всех проблем. При подсчете ссылок есть вероятность появления циклических ссылок. В скриптовых языках использующих подсчет ссылок для контроля жизни объектов специально для решения этой проблемы периодически запускают специальный код отыскивающий мертвые циклы в ссылках и прибивающий "подвисшие" объекты. Этот код крив и не очень то эффективен. Тот же ЖЦ Явы намного более эффективное решение.

Здравствуйте, tarkil, Вы писали:

T>Кстати, при знакомстве со SmallTalk меня больше всего вырубило, что его авторы считают этот механизм ненужным. Там всё на этапе исполнения проверяется.

Ну, это их тараканы. Мое мнение очень просто. Лишать себя дополнительного контроля и при этом получать приципиально более медленные решения не стоит. Гибкости мне хватает и в C#.

T>Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!

Если не ошибаюсь, в D нечто подобное возможно. Было в Паскале... перекочивало в Аду. Эта концепция вообще-то была во многих языках. Называлась по разному, но суть одна неких typedef, но порождающий не алиас, а новый тип. По-моему очень полезная концепция. Ну, да можно жить и без нее. Все же и копипыст, и шаблоны, и дженерики для этого применимы. И лучше помучиться с ними, чем постоянно вставлять проверки и молиться.

Кстати, было бы куда лучше если бы можно было создавать наследников вэлью-типов. Пусть даже без полиморфизма. А с полиморфизмом так вообще была бы круть.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FDSC, Вы писали:

FDS>>Нет. Первое поколение: PREfix и PREfast.
FDS>>Второе поколение: Slam, ESP и Vault.

VD>PREfast входит в VS 2005. Но это довольно примитивное средство контроля. Своеобразный FxCop для анменеджед-кода. В МС вроде и посерьезнее были средства.


PREfast несравним с Slam, ESP и Vault и действительно примитивен. Что у MS серьёзнее?

Здравствуйте, VladD2, Вы писали:

VD>Не совсем. Конечно на стиль языки влияют, но почему-то мне кажется, что человек после хорошей школы Шарпа будет и на С++ писать намного качественее. Шарп он подталкивает к более грамотному проектированию... к использованию ООП, безопасным приемам и т.п.

Согласен. Я то как раз после С++ (точнее C++ я к тому времени уже забыл, с Delphi) на C# переходил, а не наоборот.

FDS>> Я когда учил C# голову чуть не сломал.

VD>Очень странно. Многие находят изучение этого языка очень простым. Причем именно потому, что он очень логичен и интуитивен.

После Delphi слишком сильное различие в проектировании, потому что очень похоже в принципе и очень отличается в реализации. Вообще мне он очень понравился.

VD>Прочита по внимателнее свой список. Он конечно хаотичен, но одна тенденция в нем прослеживается. Буквально половина ошибок — это ошибки связанные с неверным использованием типов. Все эти "два раза освободил", "вышел за пределы массива" и т.п. все это следствие некоррекной работы с типами и всего этого можно избежать.

Согласен: все решения были вообще наполовину процедурными — удивительно как вообще жили. Доходило до вызовов в Delphi функций LocalAlloc совершенно без надобности.

VD>Что же там убогого? С тебя просто снимают лишнюю заботу. Единственная проблема сборщиков мусора — это сильный расход памяти. В остальном — это очень удобное и правильное решение.

Убого там как раз — расход памяти и процессора.

VD>Вообще, если ты попыташся по глубже разобраться с устройством ЖЦ, то поймешь, что это очень интересная область знаий и что это очень некислный код.

Я уже давно это понял. Три раза разбирался: кажется понял, а потом ...

VD>Счетчик ссылок — это:
VD>1. Довольно медленно. Сборщик мусора работает значитльно быстрее чем счетчики ссылок в скриптовых языках или КОМ-е.

Не знаю. Поверю на слово.

VD>2. Не решает всех проблем. При подсчете ссылок есть вероятность появления циклических ссылок. В скриптовых языках использующих подсчет ссылок для контроля жизни объектов специально для решения этой проблемы периодически запускают специальный код отыскивающий мертвые циклы в ссылках и прибивающий "подвисшие" объекты. Этот код крив и не очень то эффективен. Тот же ЖЦ Явы намного более эффективное решение.

В общем согласен.

Спасибо. Особенно за R#. Я видел эту статью раньше, но почему-то не обратил внимания. Мысли там очень правильные.

Здравствуйте, FDSC, Вы писали:

FDS>Ладно, убедили: Аду на свалку, мне — подучить языки.

FDS>Но своё то можно предложить. Как улучшить языки, почему C# лучше C++ (это к VladD2) и т.п.

FDS>Считаю, что дальнейшее сравнительное обсуждение конкретных языков Ада и C++ не приведёт ни к чему. Просто тут Аду некому защищать (профессионально), надо адвоката.

Господа! Вы Обероны забыли! Господин Губанов, где вы! АУУУ!!!

Здравствуйте, Mr. None, Вы писали:

MN>Господа! Вы Обероны забыли! Господин Губанов, где вы! АУУУ!!!

Re[5]: Частота ошибок в зависимости от языка: что делать?

Автор: Сергей Губанов
Дата: 14.06.05

Здравствуйте, FDSC, Вы писали:

FDS>Здравствуйте, Cyberax, Вы писали:

FDS>Логических ошибок времени исполнения не бывает. Компилятор должен указать мне, что такая возможность у пользователя есть, иначе мне придётся искать её самому (это тяжело, правда).
Для этого придуманы различные паттерны. Если у вас два объекта требуют согласованного конфигурирования — сделайте класс "согласованный конфигуратор". Или примените шаблоны С++, чтобы попытка присвоить несовместимый вход к выходу была ошибкой компиляции.
Если подобных паттернов становится много, и их трудно контролировать — посмотрите в сторону DSL.
FDS>Тут прикол в том, что я рад бы от него вообще избавиться. Assembler никогда не стоит выносить в отдельный файл. Если ассемблера много — лучше сразу всё на нём написать с использованием внешних модулей (я так делал).
Ассемблер вообще не нужен.
FDS>Amd64 то же совместимый с Intel x86. С Itamium наши пользователи никогда не работают. Да и Delph то же.
FDS>В этом и прикол, нужно, что бы можно было оптимизировать код не уродуя его и прямо в нём.
Не нужно. Ты в курсе, почему из С++ убирают слово register? Да потому, что ранние компилеры забивали на него — не умели оптимизировать. А новые компиляторы забивают на наго потому, что у них больше информации об использовании переменной, чем у программиста. И они принимают значительно более обоснованные решения.
Что это означает? Что вместо возможности принуждать компилятор к определенному поведению, лучше наоборот — научить компилятор корректно оптимизировать. Современное состояние оптимизации настолько далеко ушло от знакомых мне со школы решений типа "выноса инварианта за цикл"... Сейчас компиляторы ухитряются инлайнить виртуальные вызовы!
FDS>В некотрых приложениях сплошь и рядом (всё равно редко, но очень значительно). Особенно в Delphi.
Я, честно говоря, не понимаю вас. Если производительность критична — выкинь Delphi. Современные компиляторы промышленного уровня оптимизируют так, что ты запаришься их догонять. При этом все время рискуя вылететь за пределы кросс-процессорной совместимости, или внести трудноуловимую ошибку. Возможности оптимизации в Delphi находятся в противозачаточном состоянии. Поэтому работа с ним вредна для разработчиков time-critical приложений: они привыкают не доверять компилятору.

Не так давно я имел спор с таким Delphi/Asm специалистом. Его мнение о С++ было ниже плинтуса. Я предложил ему продемонстрировать это. Ок, он попытался нарисовать на асме банальный поиск в массиве интов: while(a[i++]!=test && i<length); return i. Конечно, VC++ 7.1 написал более длинный цикл. Ручной асм-код смотрелся намного красивше. Увы, при замерах скорости VC победил с разгромным счетом.

Что это означает? Что асм применяют сейчас почти только те, кто пользуется некачественным компилятором. Ребята, возьмите нормальный компайлер. Это сэкономит вам сотни часов бессмысленно потраченного времени.