VladD2 wrote:

> C>Не используют они никаких настроек. Вся Винда сейчас у них
> компилируется
> C>на VC7.1, старые версии Винды (до XP SP2) компилируются на VC6.
> Сдается мне, что на VC6 компилировалась NT 4. А винды компилируются на
> чем попалао (например, на исследовательских версиях компиляторов). Ну,
> а релизы винды компилируются на текущем релизе VC. Хотя тут я ничего
> утверждать не могу. Это только догадки.

Релизы всех виндов до SP2 компилируются VC6 — это можно посмотреть в
отладочных символах ядра.

С XP SP2 начали пользоваться для компиляции ядра VC7.1 у которого другой
формат отладочных символов. Все пользователи VC6 побежали жаловаться в
МС и в VC8 формат снова изменили на VC6-compatible и пообещали
перекомпилить Винду

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

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

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

type MyType=Integer;

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

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

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

Т>>В Аде можно

T>Рыба вобла! А пример кода можно?

type MyType is INTEGER;

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

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

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

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

Не надо . Здесь все элементарно просто. В статье, что ты привел, речь идет не о С++, а о С. Разница огромна, и дело не в том, что в С++ есть слово "класс". С++ — строготипизирован. А С — нет. Более того. Ошибка типизации в С, которую так легко допустить, мало того что не ловится компилятором, так она еще и приводит к повреждению памяти, что увеличивает цену исправления дефектов и увеличивает время обнаружения и исправления дефектов — в рантайме вовсе не обязательно будет креш.

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

Так чего вы хотите? Сравнили нетипизированный С (считай, ассемблер) с параноидальной Адой, выяснили, что плотность ошибок на выходе у последней меньше (кстати, всего в полтора раза). Ну да. Так и должно быть. У С++ плотность ошибок тоже будет меньше чем в С.

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

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

struct PositionInString{int Value;};

Оно?

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

FDS> Что такое "Оберон" я вообще не знаю (по моему что-то очень старое...).

Язык программирования созданный Никлаусом Виртом и Юргом Гуткнехтом параллельно с создание операционной системы тоже носящей имя Оберон. Потомок от языков Pascal/Modula. (Имеет сборку мусора, модульную структуру, допускает высокоэффективную компиляцию даже без специальных ухищрений разработчиков компиляторов, а уж с ухищрениями — вообще улёт.)

Породил целое семейство языков — Обероны:

Pascal (1970) -->-- Modula 2 (1979) -->-- Oberon (1987) -->-- Oberon 2 (1992) -->-- Component Pascal (1997), Active Oberon (2000), Zonnon (2005)
+ многие другие


Скоро в России школьников будут учить языку Component Pascal вместо устаревшего Turbo Pascal.

Сергей Губанов wrote:

> Скоро в России школьников будут учить языку Component Pascal
> <http://www.inr.ac.ru/%7Einfo21/&gt; вместо устаревшего Turbo Pascal.

Когда же прекратят издеваться над школьниками....

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

Здравствуйте, Cyberax.

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

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

FDS>>>>Потом, очень много требуется именно от IDE — по крайней мере разделение (действительно разделение, а не как сейчас) архитектуры, кода, обработки ошибок, проверок отладки.

...

VD>Ну, ты говоришь "действительно разделение, а не как сейчас". Вот и интересно про что ты ведешь речь? Где это "как сейчас"?

FDS>> Не видел ещё кода (и не слышал, наверное по неопытности), где совершенно отдельно хранится сам код и проверки ошибок к нему.

VD>Странно. Даже дельфи имееть структурированную обработку исключений. А языки типа Efil имеют так же пред- и пост-условия, ну, и другие фишки. Есть так же плагины для C# превросящие декларативный контроль ошибок в этот язык.

Слышал.
Я говорю про то, что контроль ошибок как код можно было бы скрыть когда надо, а когда надо — показать, причём в соответствующем контексте, скрывая ненужные алгоритмические подробности.
Насколько я знаю, в настоящее время, код пост- и предусловий существует отдельно, а исключения — прямо в коде (ну, конечно, это лучше, чем if IORESULT <> 0, но ненамного).



FDS>>Если по поводу .NET — заню. Это был только пример. Не встречал ошибок, где деструктор вызывается перед конструктором.

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

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

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

VD>К логическим? Т.е. если я где-то неверно тип привел, то это логическая ошибка? Ну, да, допустим, что для С++ это можно назвать логической ошибкой. Но как обяснить тот факт, что на Яве или C# (в безопастном режиме) таких ошибок вообще невозможно сделать? Вообще!

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

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

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

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

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

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

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

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

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


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

Я об этом и говорю. Но стремиться нужно к полной автоматизации кодирования (интересно, меня тогда уволят? Я ведь кодировщик, типичный).
Со сборщиками мусора я в C# то же намучился, но кажется понял — легко и удобно, но очень убого. Уж тогда бы сразу на аппаратном уровне сделали. Мне, как assembler-программисту, пусть и микроконтроллеров, жутко на это смотреть.

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

Здравствуйте, Gaperton.

Я просил не спорить больше об Ада и С++.

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


C>Beagle 2 лучше было не приводить в пример.


Так и знал...

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

C>FDSC wrote:

>>>> 1.2. Компилятор рассматривает код, находя функции, выход которых не
>>>> является корректным (т.е. объект разрушаеся или не создаётся, или
>>>> т.п.). Далее идёт создание пустых шаблонов объектов, исходя из
>>>> формальной безошибочности работы следующих функций.
>> C>Бессмысленно. Просто нужно разработать нормальную семантику
>> C>использования объектов (как в С++) или использовать GC и не иметь таких
>> C>проблем вообще.
>> Не понял. Причём тут семантика? Имеются ввиду незаконченные функции и
>> частичная отладка всего проекта без них.

C>Это я про деструкторы — в нормальных языках они вызываются почти всегда
C>автоматически, а в других языках деструкторов нет вообще. Простейшие
C>ошибки типа _возможного_ обращения по нулевому указателю давно умеют
C>отслеживать статические верефикаторы в C#/Java.

Тут про деструкторы ни слова.

>>>> 3. IDE позволяет задавать граф возможных и запретных
>>>> последовательностей вызовов методов (инциализация -> применение,
>>>> create -> Init -> загрузка из сети данных пользователя -> .. но не
>>>> наоборот ). Идёт контроль за обнулением инициализированных полей. Поля
>>>> объекта можно делать константными в пределах блока кода (или наоборот,
>>>> изменяемыми)
>> C>Нафиг такое не нужно, так как это принципиально невозможно проверить в
>> C>общем случае и, вдобавок, обходится грамотным проектированием.
>> Не понял, что нельзя проверить в общем случае?

C>Что последовательность вызовов будет нужно.

Чушь.

>> Если речь идёт о действиях внешних субъектов, то система всё равно
>> должна блокировать вызовы запрещённых методов, какие-бы эти действия
>> не были. А если порядок вызовов методов нельзя предусмотреть заранее,
>> значит нужно их реализовывать соответствующим образом; тогда их и
>> проверять не надо и в граф заносить то же.

C>Принципиально нельзя построить статический граф вызовов методов с
C>временными метками (могу даже доказательство привести).

Никто и не предлагает его строить.

>> Что значит "обходится грамотным проектированием"? Создавать полные
>> графы естественно не нужно.
>> Часто встречаю ошибки типа: пользователь не инициализировал переменную
>> и пытается с ней работать, связывается с микроконтроллером и пошёл (и
>> не только это). Много проблем возникает из-за этого. А самому
>> проверять нудно и трудно. Вот уж "обходится грамотным
>> проектированием", наоборот, проектировать и проверять легче.

C>Смотри С++, а именно идиому RAII — Resource Acquisition Is
C>Initialization и smart pointer'ы. То есть для работы с микроконтроллером
C>нужно взять на него хэндл, в конструкторе которого производится нужная
C>предварительная инициализация.

Неправильно понял. Привожу пример:
Уже есть предварителбная инициализация.
Пользователь устанавливает в программе диапазон измерений АЦП — 10 В, ЦАП — 5 В.
Далее он замыкает АЦП на ЦАП и хочет проверить, всё ли правильно. Естественно нет. Никакая инициализация тут просто так не поможет. "Умные указатели" тут вообще не причём.
Программа должна обрабатывать эту ошибку пользователя, а такиз вариантов масса.


>> C>А смысл?
>> Смысл простой. В Delphi, например, вообще нельзя работать из другого
>> класса с private-членами. Protected — только в текущем модуле.
>> Допустим я хочу поправить (дополнить) чужой класс (в любом языке),
>> зачем мне делать доступными приватные члены для всех методов, когда
>> мне нужен, возможно, только один? Зря возможность ошибочного вызова
>> делать.

C>В С++ есть механизм friend'ов, который позволяет открыть приватные члены
C>для избранных классов или функций. Хотя необходимость использования
C>такого механизма показывает на неправильное проектирование — другой
C>класс не должен лезть в приватные данные класса.

Представь, что класс, в который ты хочешь лезть неправильно спроектировали. Собственно ты правильно понял.

>> C>А нафиг??
>> Мне, например, надобилось.
>> Привожу примеры:
>> Один алгорит с 7 вложенными циклами Delphi компилирует так, что
>> переписанный на asm работает в 7,5 раза быстрей, но при смене проекта
>> всё заново писать приходиться. Муторно.

C>И что? Выносите ассемблер в отдельные файлы, компилируйте отдельным
C>ассемблером, а потом линкуйте в проект.

И что? Всё так же останется. Ещё и компилировать отдельно придётся.

C>Не понимаю я, зачем в язые нужно вводить низкоуровневые хаки, которые
C>вдобавок лишат его кроссплатформенности (которая часто гораздо важнее
C>небольших выигрышей в производительности).


"Хаки" в приложении работают на любой системе, совместимой с Intel x86.
Ничего себе небольшие — час или 15 минут!

FDSC wrote:

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

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

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

Здравствуйте, Cyberax, Вы писали:
C>В чем в С++ проблема с runaway inheritance я не понимаю (вообще в первый раз такой термин слышу), больше похоже, что их местные программисты чего-то не так задизайнили.
Именно об этом они и говорят. По их наблюдениям, "местные программисты" любят наследоваться только от известных им классов поближе к всеобщему корню, наколбашивая десятки братьев-близнецов вместо выделения общей функциональности и минимизации copy/paste кода. Кроме того, те же программисты слабо владеют шаблонами, потому любят плодить свои личные контейнеры вместо параметризации stl.
Впечатление такое, что парни сфотографировали хаос — разработку без проектирования, где никто не следит за reuse, и порождение классов выполняется как в голову ударит. Конечно никто не станет рисовать красивые иерархии — класс соседа по качеству на порядок ниже, чем библиотечный, так что проще отнаследоваться от корня и скопировать 90% поведения, чем унаследоваться от соседа (особенно если он private и protected разбрасывает аки Воробъянинов бублики). А раз за разработку своих контейнеров никто по рукам не ударит — будет велосипедалить очереди и стеки (благо основное, чему их научили на пятидневных курсах — это именно очереди и стеки на С++, а вовсе не паттерны проектирования бизнес-классов). Потом, припертый к стенке, он начнет кричать про критическую неприменимость stl для его целей, мотивируя то неясными багами в методе reserve, то чиста своим заточенным мемори менеджером...

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

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

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

FDSC wrote:

> Неправильно понял. Привожу пример:
> Уже есть предварителбная инициализация.
> Пользователь устанавливает в программе диапазон измерений АЦП — 10 В,
> ЦАП — 5 В.
> Далее он замыкает АЦП на ЦАП и хочет проверить, всё ли правильно.
> Естественно нет. Никакая инициализация тут просто так не поможет.
> "Умные указатели" тут вообще не причём.
> Программа должна обрабатывать эту ошибку пользователя, а такиз
> вариантов масса.

Ну и в чем тут компилятор поможет? Чистая логическая ошибка времени
исполнения.

> C>И что? Выносите ассемблер в отдельные файлы, компилируйте отдельным
> C>ассемблером, а потом линкуйте в проект.
> И что? Всё так же останется. Ещё и компилировать отдельно придётся.

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

> C>Не понимаю я, зачем в язые нужно вводить низкоуровневые хаки, которые
> C>вдобавок лишат его кроссплатформенности (которая часто гораздо важнее
> C>небольших выигрышей в производительности).
> "Хаки" в приложении работают на любой системе, совместимой с Intel x86.

А если у меня PPC? Или Amd64 или Itanium?

> Ничего себе небольшие — час или 15 минут!

Крайне редкий случай — обычно выигрыш в десятки процентов.

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

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

C>FDSC wrote:

>> Неправильно понял. Привожу пример:
>> Уже есть предварителбная инициализация.
>> Пользователь устанавливает в программе диапазон измерений АЦП — 10 В,
>> ЦАП — 5 В.
>> Далее он замыкает АЦП на ЦАП и хочет проверить, всё ли правильно.
>> Естественно нет. Никакая инициализация тут просто так не поможет.
>> "Умные указатели" тут вообще не причём.
>> Программа должна обрабатывать эту ошибку пользователя, а такиз
>> вариантов масса.

C>Ну и в чем тут компилятор поможет? Чистая логическая ошибка времени
C>исполнения.

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

>> C>И что? Выносите ассемблер в отдельные файлы, компилируйте отдельным
>> C>ассемблером, а потом линкуйте в проект.
>> И что? Всё так же останется. Ещё и компилировать отдельно придётся.

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

Тут прикол в том, что я рад бы от него вообще избавиться. Assembler никогда не стоит выносить в отдельный файл. Если ассемблера много — лучше сразу всё на нём написать с использованием внешних модулей (я так делал).

>> C>Не понимаю я, зачем в язые нужно вводить низкоуровневые хаки, которые
>> C>вдобавок лишат его кроссплатформенности (которая часто гораздо важнее
>> C>небольших выигрышей в производительности).
>> "Хаки" в приложении работают на любой системе, совместимой с Intel x86.

C>А если у меня PPC? Или Amd64 или Itanium?

Amd64 то же совместимый с Intel x86. С Itamium наши пользователи никогда не работают. Да и Delph то же.
В этом и прикол, нужно, что бы можно было оптимизировать код не уродуя его и прямо в нём.

>> Ничего себе небольшие — час или 15 минут!

C>Крайне редкий случай — обычно выигрыш в десятки процентов.

В некотрых приложениях сплошь и рядом (всё равно редко, но очень значительно). Особенно в Delphi.

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

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

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

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

Класс..

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

FDS>А вообще фрагмент, по моему, правильный, по поводу ООП и C++. Может я это .. не понимаю в программировании на C++ чего-то??? (я сам прогр. Delphi / assembler, C++ только правлю и дополняю, и то не очень часто).

Ну вот и ещё один полез что-то доказывать вне области собственных знаний...