Здравствуйте, Cyberax, Вы писали:
C>FDSC wrote:
>> ANS>Это легко проверить. Вот ты пользователь компиляторы. Возьми и >> расскажи чего бы ты хотел /улучшить/. >> /*Отвечаю.*/ >> 1. IDE снабжается системой создания автоматизированных заглушек для >> ещё ненаписанного кода. Это возможно: >> 1.1. Программист делает пометки несозданных функций в созданном коде — >> компилятор автоматически делает шаблон (это легко, можно сделать и как >> надстройку)
C>Смотри IDEA (http://www.intellij.com/) или Eclipse C>(http://www.eclipse.org) — там это есть уже много лет.
насчёт IDEA не знаю, а то что легко я и написал из-за Eclipse.
>> 1.2. Компилятор рассматривает код, находя функции, выход которых не >> является корректным (т.е. объект разрушаеся или не создаётся, или >> т.п.). Далее идёт создание пустых шаблонов объектов, исходя из >> формальной безошибочности работы следующих функций.
C>Бессмысленно. Просто нужно разработать нормальную семантику C>использования объектов (как в С++) или использовать GC и не иметь таких C>проблем вообще.
Не понял. Причём тут семантика? Имеются ввиду незаконченные функции и частичная отладка всего проекта без них.
>> 2. IDE снабжается возможностью проектирования процесса разработки ПО: >> т.е. помагает программисту выявить последовательность разработки >> методов и классов приложения с учётом применения итеративной разработки.
C>Рефакторинг в IDEA, Eclipse, Reshaper.
Жаль, не знаю. Спасибо, посмотрю (меня этому не учили, немного не та область).
>> 3. IDE позволяет задавать граф возможных и запретных >> последовательностей вызовов методов (инциализация -> применение, >> create -> Init -> загрузка из сети данных пользователя -> .. но не >> наоборот ). Идёт контроль за обнулением инициализированных полей. Поля >> объекта можно делать константными в пределах блока кода (или наоборот, >> изменяемыми)
C>Нафиг такое не нужно, так как это принципиально невозможно проверить в C>общем случае и, вдобавок, обходится грамотным проектированием.
Не понял, что нельзя проверить в общем случае?
Если речь идёт о действиях внешних субъектов, то система всё равно должна блокировать вызовы запрещённых методов, какие-бы эти действия не были. А если порядок вызовов методов нельзя предусмотреть заранее, значит нужно их реализовывать соответствующим образом; тогда их и проверять не надо и в граф заносить то же.
Что значит "обходится грамотным проектированием"? Создавать полные графы естественно не нужно.
Часто встречаю ошибки типа: пользователь не инициализировал переменную и пытается с ней работать, связывается с микроконтроллером и пошёл (и не только это). Много проблем возникает из-за этого. А самому проверять нудно и трудно. Вот уж "обходится грамотным проектированием", наоборот, проектировать и проверять легче.
>> 4. IDE реализует сам код, как граф. Названия методов даются как >> справочная информация для программиста, могут меняться автоматически.
C>Было такое в Together и Rational Rose — успешно провалилось как C>неудобное и неюзабельное решение.
Не знаю Together, но в Rational Rose такого не было никогда. RR не позволял писать полномасштабный код как граф, среда вообще предназначена для UML-проектирования.
Между прочим, лично знаю людей, которые используют эти продукты.
Кстати, я ещё писал: "Код отбражается как граф, дерево или ещё что-нибудь удобное". А как же давнишние '+', позволяющие свернуть функции в MS VS.
Кстати в этом направлении сейчас есть движение — в частности, для UML-спроектированного приложения создаётся шаблон кода. Я, в том числе, и это имел ввиду.
>> 5. Конкретный синтаксис языка определяет программист. Основа языка >> позволяет писать классы и функции (в т.ч. вложенные), а использование >> тех или иных обозначений (возможно, математических) зависит от области >> работы компонента. В том числе речь идёт о сокрытии непосредственной >> объектно-функциональной структуры языка -> записывается сам алгоритм >> (не знаю как это сделать).
C>Это в область DSL — сейчас она развивается достаточно активно.
Где почитать, подскажи!!!
>> 6. Библиотеки позволяют работать с приватными методами и полями в >> отдельных заявленных функциях других классов (а не во всём классе). >> (см. так же 3).
C>А смысл?
Смысл простой. В Delphi, например, вообще нельзя работать из другого класса с private-членами. Protected — только в текущем модуле. Допустим я хочу поправить (дополнить) чужой класс (в любом языке), зачем мне делать доступными приватные члены для всех методов, когда мне нужен, возможно, только один? Зря возможность ошибочного вызова делать.
>> 7. Компилятор позволяет работать низкоуровнево без использования >> ассемблера и с гарантией совместимости низкого кода с высоким (речь >> идёт об ограничении применения регистров CPU и т.п. в пределах работы >> низкого кода. Ограничениях для компилятора, а не для программиста).
C>А нафиг??
Мне, например, надобилось.
Привожу примеры:
Один алгорит с 7 вложенными циклами Delphi компилирует так, что переписанный на asm работает в 7,5 раза быстрей, но при смене проекта всё заново писать приходиться. Муторно.
В RSDN непомню кто, писал про обёртку для вызова функций из внешний DLL. Для этого он написал 13 классов-шаблонов C++ — по одной на количество аргументов. Я видел решение его задачи на Delphi 2-мя функциями (с использованием asm). По моему так гораздо лучше.
C>Вообще, рекомендую выучить пару-тройку языков (например: С++, Java и C>OCaml) — многие вопросы отпадут сами.
Я знаю нормально Dlephi, C++, assembler. Кстати, Java не так уж и отличается от C++ (программировал я на ней чуть-чуть, правда Eclipse сильно отличается от того, что мне приходилось видеть).
OCaml — никогда не слышал!!! Что это?
Выходит, Вас устраивают существующие компиляторы?
Re[2]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FDSC, Вы писали:
VD>Ада давно устарела. Ява, Шарп, Васик (и другие управляемые языки), а так же некоторые типизированные функциональные языки обеспечивают не меньшую чем в Аде защиту при этом являсь полноценными и современными ООЯ.
Не согласен. Приложения для систем управления на ней часто пишут. Защита, хорошо, а по поводу поддрежки многопоточности?
Кстати, что бы не быть голословным: Ада используется фирмой BEA.
VD>Буквально и понимать. С++ имеет море возможностей приводящих к скрытию ошибок и к ошибкам второго порядка (наложенным... портишь память в одном месте, а программа падает в другом).
Спасибо, понял.
FDS>> и почему C++ более распространён чем АДА? Переходим на АДА???
VD>Ада это мертворожденное дитя. Она может и более надежна, но это откровенно тяжеловестный и неудобный язык программирования. С++ же является приемником С и на него переходила целая толпа С-шников которые хотели получить ОО-возможности.
Незнаю, вообще, Ада-программисты говорят, что она хорошо читается. Хотя я думая иначе. Наверное это зависит от опыта программирования на Ада.
FDS>>Можно ли разработать ещё более экономичные языки?
VD>А причем тут экономичность? Речь же шала о надежности и безопастности. Да и экономить можно разные. Можно экономить память, можно время программиста, а можно количество символов в исходном файле.
Речь шла не только о надёжности, но и о времени и стоимости проектирования.
VD>Если говорить о надежности, то управляемые языки и функциональные статически типизированные языки обладают довольно высокими показателями защищенности. При разработке на том же шарпе тратишь на отладку на порядок меньше времени чем программируя на С++.
Видимо, это зависит от квалификации. Я слышал и другие мнения.
VD>Если говорить о том как это достигается, то все очень просто. С одной стороны ЯП проектируется так чтобы не допускать ошибок (до запуска программы на исполнение). Если требования гибкости заставляют отложить проверки до времени выполнения, то проверки перекладываются на рантайм. Тут безусловные видеры управляемые среды и скриптовые языки. Их рантаймы контролируют все действия во время работы программы. Например, в С++ можно легко привести любой блок памяти к любому (даже не совместимому) типу. Это может легко привратиться в ошибку. Уравляемые же среды и скритовые языки недопускают пдобного или требуют специальной декларации своих намерений в виде пометки части кода как небезопастного (в таких участках возможны такие же ошибки как и в С++-коде).
Об этом много пишут в учебниках, однако я таких ошибок никогда не встречал (видать простые программы были). По моему ошибки обычно больше логического характера возникают. Очень спорный вопрос.
Вообще, я пытался провести статистику ошибок у себя и некоторых знакомых и пришёл к выводу, что константность, приватность и контроль за преобразованием типов сами по себе исключают довольно малое количество ошибок (по крайней мере в Delhi, в С++ думаю ситуация такая же).
VD>С одной стороны ЯП проектируется так чтобы не допускать ошибок (до запуска программы на исполнение).
А можно допустить ошибки без запуска программы?? Синтаксические что-ли? Я не понял, поясните пожалуйста.
Простите, если несколько узко образован.
Re[4]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FDSC, Вы писали:
FDS>>1. По статистике (честно говоря, незнаю как это получается) количество ошибок не зависит от квалификации программиста (не помню откуда, могу поискать).
VD>Чтобы понять, что это миф не нужно смотреть статистических сборников. Достаточно поглядеть на код написанный более опытным программистом и начинающим юнцом. Уверяю тебя, что не вооруженным взглядом будет видно, что юнец ошибается в сотни раз чаще и ошибки его в сотни раз банальнее.
В общем-то да. Кстати, по этой же статистике, ошибки опытных программистов труднее искать. В любом случае статистика действительно очень странная.
VD>Ошибки бывают разные. Бывают по невнимательности. И тут тоже у разных людей все по разному. Один более уситчев и делает меньше ошибок... Бывают просчеты дизайна. Тут (если вообще горректно говорить об умении программиста) все вообще зависит от опыта. Ну, и логические ошибки чаще появляются у менее опытных прграммистов.
VD>В общем, там где опытный программист пару раз ошибется не опытный просто завалит проект.
Я думаю это связано больше с ошибками проектирования и уверенностью в себе.
FDS>>3. Квалифицированный программист, который совершает в 10 раз меньше ошибок (см. пункт 1) стоит, наверное, во столько же раз дороже. Как же по поводу уменьшения стоимости разработки на Ада?
VD>Проблема в том, что нельзя взять миллион обезьян и заставить написать их сложный софт. К тому же есть очень отвественные задачи в которых стоимость ошибки очень велика. Тут защищенные языки и рантаймы позволяют понизить вероятность ошибки и, стало быть, снизить риски и стоимость.
Ну, получается, что если Ада такая нечитаемая и вообще, мертворождённая, то программисты должны стоить дорого и проект то же. Я и спрашиваю: как так?
VD>Кстати, одна ошибка на той самой Аде привела к потере ракетоносителя со спутником на борту.
Всяко бывает.
По моему мы несколько ушли от темы.
Re[5]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, FDSC, Вы писали:
FDS>В общем-то да. Кстати, по этой же статистике, ошибки опытных программистов труднее искать. В любом случае статистика действительно очень странная.
Искать их не по статистике сложнее. А потому что просто ошибки более опытных людей более сложны по своей сути. Ну, глупо ошибаться если задача пустяк. Просто любой разум имеет придел. И если для опытного разума это просо ошибка, то для менее опытного это жуткий ребус. Короче опытный программист с трудом находит свои мудренные ошибки, а менее опытный свои более простые. Но востприятие ошибок практически одинаковое. До их обнаружения они не понятны и не объяснимы.
FDS>Я думаю это связано больше с ошибками проектирования и уверенностью в себе.
Возможно. Весма возможно.
FDS>Ну, получается, что если Ада такая нечитаемая и вообще, мертворождённая, то программисты должны стоить дорого и проект то же. Я и спрашиваю: как так?
Ада и стоит не мало. На столько не мало, что по сравнению с менее одиозными языками вроде Шарпа или Явы еще бабушка на двое скажет что дешевле. Но по сравнению с С++ кое что есть. Все же Ада позволяет с высокой долей увереннсоти говорить о корректности. А С++ — это надежда на крутость программиста и вера в проведение.
VD>>Кстати, одна ошибка на той самой Аде привела к потере ракетоносителя со спутником на борту.
FDS>Всяко бывает. FDS>По моему мы несколько ушли от темы.
Да, нет. Это все к вопросу о цене ошибки. Если одна ошибка стоит миллионы долларов. То применение С++ в таких проектах — это по хлеще чем топка помещений ассигнациями.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, FDSC, Вы писали:
FDS>Не согласен. Приложения для систем управления на ней часто пишут.
Часто? А где статистика?
FDS> Защита, хорошо, а по поводу поддрежки многопоточности?
Тут безусловно рулят функциональные языки. А Ада нервно курит. Причем по бональным соображениям. В ФЯ легко достигается неблокирующий режим работы. Так что контролировать нечего. А учитывая отсуствие побочных эффектов у функций распараллеливание становится намного более простой задачей.
FDS>Кстати, что бы не быть голословным: Ада используется фирмой BEA.
Это что тукседо пишут?
FDS>Незнаю, вообще, Ада-программисты говорят, что она хорошо читается. Хотя я думая иначе. Наверное это зависит от опыта программирования на Ада.
Ада не является полноценным ООЯ. По сему полноценное программирование в ней затруднено. Обобщенное программирование в ней тоже не сахар. В общем, защищенность в ней конечно на уровне. Но в остльном — это продукт концелярского мышления.
Я не спец в этом языке, но даже отдаленного знакомства хватило чтобы понять насколько это странное порождение.
FDS>Речь шла не только о надёжности, но и о времени и стоимости проектирования.
Э... Что толку от времени проектирования если ты заранее обречен играть в угадайку в отношении надежности? Ада была разработана как надежный язык. В ней куча защит и т.п. Но скорость проектирования... тут она пожалуй не лучший выбор. В общем, выбор Ады — это выбор брони. Да ехать будешь не быстро, но доедишь в целости (с большой долей вероятности). А писать однозначно лучше на более современных языках.
VD>>Если говорить о надежности, то управляемые языки и функциональные статически типизированные языки обладают довольно высокими показателями защищенности. При разработке на том же шарпе тратишь на отладку на порядок меньше времени чем программируя на С++.
FDS>Видимо, это зависит от квалификации. Я слышал и другие мнения.
Все в этой жизни зависит от квалификации. А мнений бывает очень много. Причем большинство из них диамитрально-противоположенные.
FDS>Об этом много пишут в учебниках, однако я таких ошибок никогда не встречал (видать простые программы были). По моему ошибки обычно больше логического характера возникают. Очень спорный вопрос.
Ну, если ты не встречал такие ошибки, то с вероятностью в 99% ты просто имешь малый опыт. Ну, или ты крут как вареные яйца. У тех же парней из МС или тех что делают Линуксы и т.п. подобных проблем хоть отбавляй. От банальных AV, до переполнений буферов. В общем игра в усидчивость на гигабайтах кода.
FDS>Вообще, я пытался провести статистику ошибок у себя и некоторых знакомых и пришёл к выводу, что константность, приватность и контроль за преобразованием типов сами по себе исключают довольно малое количество ошибок (по крайней мере в Delhi, в С++ думаю ситуация такая же).
Интересно было бы посмотреть на эту статистику. Я так просто пользуюсь контролем типов как железным щитом. Любой серьезный рефакторинг в конце концов заканчивается подправкой ошбок компиляции которые на 90% выливаются в ошибки связанные с типами. Более того. Стараюсь проектировать все так, чтобы ошибки как можно чаще выливались в ошибки типов ловимые компилятором.
VD>>С одной стороны ЯП проектируется так чтобы не допускать ошибок (до запуска программы на исполнение).
FDS>А можно допустить ошибки без запуска программы??
Легко. Чем больше контроль компилятора. И чем более грамотно проектируется ПО, тем больше ошибок вылавливается еще до стадии отладки.
FDS> Синтаксические что-ли? Я не понял, поясните пожалуйста.
Синтаксис, семантика. Это очень не мало. Если ты умешь грамотно формулировать мысли, то семантический контроль позволяет отлавливать очень много ошибок.
Прстой пример из недавнего опыта. Представь себе редактор у которого есть представление данных в документе, и представление данных во View. И там, и там хронятся строки. Но в первом случае они хранятся просто так, а во втором перенесенными на страницу. Так вот если хранить их как строка/символ в строке в обоих случаях и не разделять тиы, то ошибочно посунув вместо индекса перенесенной линии индекс линии из документа ты будешь долго ловить ошибку в отладчие. Если же ввести понятие виртуальных и реальных координат, то контроль за правильностью действий возмет на себя компилятор. Другими словами грамотное проектирование переносит отвественность за качество на безошибочный компилятор. Так что даже на не супер идельном ЯП можно существенно улучшить защищенность программы, а стало быть уменьшить время затрачиваемое на отладку, и ускорить поизводство ПО. А есди сам язык и рантайм помогают тебе держать типы в целости и сохранности, твоя задача существенно упрощается.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, FDSC, Вы писали:
FDS>Извини, что такое GCC?
GCC — это С++-компилятор созданный на базе открытого фронтэнда ГНУ.
FDS>Сначало надо знать, что этой за зверь — свой язык, а потом уже писать что-то. Я уже 3 года со знакомыми программистами общаюсь, у каждого своё мнение по поводу удобств языков и IDE.
Извини, но похоже ты пересидел с Дельфи. Тебе нужно изучить мир за пределами Борланда. IDE это всего лишь инструмент. И Борланд на сегодны далеко не законодатель мод.
FDS>Потом, очень много требуется именно от IDE — по крайней мере разделение (действительно разделение, а не как сейчас) архитектуры, кода, обработки ошибок, проверок отладки.
А как сейчас где?
FDS> Система должна воспринимать недопустимую последовательность вызовов методов (например, деструктор раньше конструктора) и т.п.
Открою тебе сикрет. В передовых на сегодня технологиях уже давно отказываются от самого понятия деструктора. А ручной вызов уже давно считается чем-то не приличным.
FDS>Может это смешно делать, кодга половину всего этого сделала Microsoft (пусть даже не всё для других), но мне надоело писать на том, что не нравится, а MS никогда нормальный компилятор с моей точки зрения не выпустит. Можно конечно в NASA устроиться... .
Нда. Ты еще и пары компиляторов МС не видел, а уже судишь и столь котигорично. Поверь на слово. МС один из лидеров в компиляторостроении. Есть конечно и другие лидеры. У них есть достойные продукты. Но компиляторы МС — это очень и очень достойные родукты.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, FDSC, Вы писали:
C>>MS C++ 7.1 и MS C++ 8.0 — вполне приличные компиляторы.
FDS>Смотря для каких целей. Между прочим, Microsoft, NASA и т.п. не используют такие компиляторы, или используют их с существенными надстройками.
Да? Ну, насса использует черта лысого. С ним отдельно. А на чем по-твоему пишутся продукты МС? И какие-такие надстройки используют в МС?
FDS>Компиляторы приличные, да вот нехватает их возможностей. (см. выше написал сообщение с заголовком "Предложения по улучшению"). Не приятно на них программировать (если конечно сроки поставлены и начинаешь нервничать).
Ты бы луче ссылку дал.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, FDSC, Вы писали:
FDS>Под компилятором в данном случае я подразумевал не только IDE, но и весь пакет программ Visual Studio или Delphi Studio.
Завязывай ты с Дельфи. А то не равен час под компилятором начнешь понимать редактор кода и комплит-ворд.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Частота ошибок в зависимости от языка: что делать?
FDSC wrote:
> C>Ха. Вы думаете Microsoft не использует собственный компилятор? > Я сказал не использует, или с *надстройками*.
Не используют они никаких настроек. Вся Винда сейчас у них компилируется
на VC7.1, старые версии Винды (до XP SP2) компилируются на VC6.
> C>А в NASA используют GCC, или родной VxWorks'овский. > Откуда такие сведения?
http://www.windriver.com/ Кроме того, сами насовцы достаточно много
писали о Роверах и спутниках.
> В NASA вообще на данный момент используют автоматическую генерацию > кода (90-97% автоматически).
С чего бы это? Чтобы код генерировать нужно иметь:
1. Генератор
2. Шаблоны
Отладка обоих может быть намного дороже написания кода вручную.
> C>Часть возможностей просто не нужна для нормального языка, а другая > часть > C>должна быть в IDE, а не компиляторе. > Под компилятором в данном случае я подразумевал не только IDE, но и > весь пакет программ Visual Studio или Delphi Studio.
А, ну понятно — наследие Delphi. Нужно различать: язык, компилятор с
данного языка и IDE для данного языка.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[3]: Частота ошибок в зависимости от языка: что делать?
FDSC wrote:
> VD>Ада давно устарела. Ява, Шарп, Васик (и другие управляемые языки), > а так же некоторые типизированные функциональные языки обеспечивают не > меньшую чем в Аде защиту при этом являсь полноценными и современными ООЯ. > Не согласен. Приложения для систем управления на ней часто пишут. > Защита, хорошо, а по поводу поддрежки *многопоточности*?
Давно уже есть везде. А что в этом такого суперэкзотичного?
Есть еще и специализированые решения для очень многопоточных приложений:
ACE (Adaptive Communication Environment), язык Erlang и т.п.
> Кстати, что бы не быть голословным: Ада используется фирмой BEA.
BEA сейчас в основном продает WebLogic, написаный на Java.
> VD>С одной стороны ЯП проектируется так чтобы не допускать ошибок (до > запуска программы на исполнение). > А можно допустить ошибки без запуска программы?? Синтаксические > что-ли? Я не понял, поясните пожалуйста.
Естественно Все ошибки в программе закладываются во время ее
написания. Задача компилятора — помочь их выловить еще на этапе компиляции.
Здравствуйте, Cyberax, Вы писали:
>> 4. IDE реализует сам код, как граф. Названия методов даются как >> справочная информация для программиста, могут меняться автоматически.
C>Было такое в Together и Rational Rose — успешно провалилось как C>неудобное и неюзабельное решение.
FDSC wrote:
>>> 1.2. Компилятор рассматривает код, находя функции, выход которых не >>> является корректным (т.е. объект разрушаеся или не создаётся, или >>> т.п.). Далее идёт создание пустых шаблонов объектов, исходя из >>> формальной безошибочности работы следующих функций. > C>Бессмысленно. Просто нужно разработать нормальную семантику > C>использования объектов (как в С++) или использовать GC и не иметь таких > C>проблем вообще. > Не понял. Причём тут семантика? Имеются ввиду незаконченные функции и > частичная отладка всего проекта без них.
Это я про деструкторы — в нормальных языках они вызываются почти всегда
автоматически, а в других языках деструкторов нет вообще. Простейшие
ошибки типа _возможного_ обращения по нулевому указателю давно умеют
отслеживать статические верефикаторы в C#/Java.
>>> 3. IDE позволяет задавать граф возможных и запретных >>> последовательностей вызовов методов (инциализация -> применение, >>> create -> Init -> загрузка из сети данных пользователя -> .. но не >>> наоборот ). Идёт контроль за обнулением инициализированных полей. Поля >>> объекта можно делать константными в пределах блока кода (или наоборот, >>> изменяемыми) > C>Нафиг такое не нужно, так как это принципиально невозможно проверить в > C>общем случае и, вдобавок, обходится грамотным проектированием. > Не понял, что нельзя проверить в общем случае?
Что последовательность вызовов будет нужно.
> Если речь идёт о действиях внешних субъектов, то система всё равно > должна блокировать вызовы запрещённых методов, какие-бы эти действия > не были. А если порядок вызовов методов нельзя предусмотреть заранее, > значит нужно их реализовывать соответствующим образом; тогда их и > проверять не надо и в граф заносить то же.
Принципиально нельзя построить статический граф вызовов методов с
временными метками (могу даже доказательство привести).
> Что значит "обходится грамотным проектированием"? Создавать полные > графы естественно не нужно. > Часто встречаю ошибки типа: пользователь не инициализировал переменную > и пытается с ней работать, связывается с микроконтроллером и пошёл (и > не только это). Много проблем возникает из-за этого. А самому > проверять нудно и трудно. Вот уж "обходится грамотным > проектированием", наоборот, проектировать и проверять легче.
Смотри С++, а именно идиому RAII — Resource Acquisition Is
Initialization и smart pointer'ы. То есть для работы с микроконтроллером
нужно взять на него хэндл, в конструкторе которого производится нужная
предварительная инициализация.
> C>Было такое в Together и Rational Rose — успешно провалилось как > C>неудобное и неюзабельное решение. > Не знаю Together, но в Rational Rose такого не было никогда. RR не > позволял писать полномасштабный код как граф, среда вообще > предназначена для UML-проектирования.
Позволяет, причем в RR можно писать полностью весь код. Году в 2000 я
пробовал применить это на практике сначала на RR, потом на Together.
Результат такой — уж проще руками все писать.
> Кстати в этом направлении сейчас есть движение — в частности, для > UML-спроектированного приложения создаётся шаблон кода. Я, в том > числе, и это имел ввиду.
Нету его в реальном мире, как показывает практика — ничего таким макаром
нормально сделать не получается.
> C>Это в область DSL — сейчас она развивается достаточно активно. > Где почитать, подскажи!!!
Отсюда http://en.wikipedia.org/wiki/Domain-specific_language и по ссылкам.
> C>А смысл? > Смысл простой. В Delphi, например, вообще нельзя работать из другого > класса с private-членами. Protected — только в текущем модуле. > Допустим я хочу поправить (дополнить) чужой класс (в любом языке), > зачем мне делать доступными приватные члены для всех методов, когда > мне нужен, возможно, только один? Зря возможность ошибочного вызова > делать.
В С++ есть механизм friend'ов, который позволяет открыть приватные члены
для избранных классов или функций. Хотя необходимость использования
такого механизма показывает на неправильное проектирование — другой
класс не должен лезть в приватные данные класса.
> C>А нафиг?? > Мне, например, надобилось. > Привожу примеры: > Один алгорит с 7 вложенными циклами Delphi компилирует так, что > переписанный на asm работает в 7,5 раза быстрей, но при смене проекта > всё заново писать приходиться. Муторно.
И что? Выносите ассемблер в отдельные файлы, компилируйте отдельным
ассемблером, а потом линкуйте в проект.
Не понимаю я, зачем в язые нужно вводить низкоуровневые хаки, которые
вдобавок лишат его кроссплатформенности (которая часто гораздо важнее
небольших выигрышей в производительности).
> В RSDN непомню кто, писал про обёртку для вызова функций из внешний > DLL. Для этого он написал 13 классов-шаблонов C++ — по одной на > количество аргументов. Я видел решение его задачи на Delphi 2-мя > функциями (с использованием asm). По моему так гораздо лучше.
В С++ можно вызывать функции из DLL без всяких "оберток". Скорее всего
требовалось что-то другое (типа делегатов или хука).
> C>Вообще, рекомендую выучить пару-тройку языков (например: С++, Java и > C>OCaml) — многие вопросы отпадут сами. > Я знаю нормально Dlephi, C++, assembler. Кстати, Java не так уж и > отличается от C++ (программировал я на ней чуть-чуть, правда Eclipse > сильно отличается от того, что мне приходилось видеть). > OCaml — никогда не слышал!!! Что это?
Функциональный язык, достаточно популярный: http://www.ocaml.org
> Выходит, Вас устраивают существующие компиляторы?
Да. Естественно, место для улучшений есть, но ничего принципиально
нового не хочется.
Дарней wrote:
>>> 4. IDE реализует сам код, как граф. Названия методов даются как >>> справочная информация для программиста, могут меняться автоматически. > C>Было такое в Together и Rational Rose — успешно провалилось как > C>неудобное и неюзабельное решение. > очень интересно. а можно подробнее?
А чего особого? Рисовалась диаграмма классов, к методам делались
аннотации в виде их кода (можно еще было их генерировать из диаграммы
состояний). Работало все криво и неудобно.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[14]: Частота ошибок в зависимости от языка: что делать?
VD>Извини, но похоже ты пересидел с Дельфи. Тебе нужно изучить мир за пределами Борланда. IDE это всего лишь инструмент. И Борланд на сегодны далеко не законодатель мод.
Согласен. Только не знаю, кто законодатель.
FDS>>Потом, очень много требуется именно от IDE — по крайней мере разделение (действительно разделение, а не как сейчас) архитектуры, кода, обработки ошибок, проверок отладки.
VD>А как сейчас где?
Не понял. Не видел ещё кода (и не слышал, наверное по неопытности), где совершенно отдельно хранится сам код и проверки ошибок к нему. По поводу средств проверок, согласен, хранятся отдельно.
FDS>> Система должна воспринимать недопустимую последовательность вызовов методов (например, деструктор раньше конструктора) и т.п.
VD>Открою тебе сикрет. В передовых на сегодня технологиях уже давно отказываются от самого понятия деструктора. А ручной вызов уже давно считается чем-то не приличным.
Если по поводу .NET — заню. Это был только пример. Не встречал ошибок, где деструктор вызывается перед конструктором.
VD>Нда. Ты еще и пары компиляторов МС не видел, а уже судишь и столь котигорично. Поверь на слово. МС один из лидеров в компиляторостроении. Есть конечно и другие лидеры. У них есть достойные продукты. Но компиляторы МС — это очень и очень достойные родукты.
Как раз два компилятора я видел: MS VS 6 Standard Architect и MS VS .NET 2003 EA.
Причём на 6-ой пришлось попрограммиовать. .NET конечно гораздо лучше.
> >>В RSDN непомню кто, писал про обёртку для вызова функций из внешний >>DLL. Для этого он написал 13 классов-шаблонов C++ — по одной на >>количество аргументов. Я видел решение его задачи на Delphi 2-мя >>функциями (с использованием asm). По моему так гораздо лучше. > > > В С++ можно вызывать функции из DLL без всяких "оберток". Скорее всего > требовалось что-то другое (типа делегатов или хука). >
Кажется, всё было именно простейшей обёрткой для функции, динамически
находимой по названию.
Posted via RSDN NNTP Server 1.9
Re[14]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, Cyberax, Вы писали:
C>http://www.windriver.com/ Кроме того, сами насовцы достаточно много C>писали о Роверах и спутниках.
>> В NASA вообще на данный момент используют автоматическую генерацию >> кода (90-97% автоматически).
C>С чего бы это? Чтобы код генерировать нужно иметь: C>1. Генератор C>2. Шаблоны
C>Отладка обоих может быть намного дороже написания кода вручную.
Уже есть. Прочитал перевод статьи "NASA's Mission Reliable", Patrik Regan, Scott Hamilton, IEEE Computer, jan 2004. Впрочем, они не из NASA. Ссылку дать не могу .
C>А, ну понятно — наследие Delphi. Нужно различать: язык, компилятор с C>данного языка и IDE для данного языка.
Различаю, этому меня точно учили. Это была терминологическая неточность, виноват, исправлюсь. Однако написать слово "компилятор" несколько проще, чем объяснять, что имеешь в виду целый пакет программ разработки (который не входит в IDE). В любом случае — уже не по теме.
C>А чего особого? Рисовалась диаграмма классов, к методам делались C>аннотации в виде их кода (можно еще было их генерировать из диаграммы C>состояний). Работало все криво и неудобно.
Это не то, о чём я говорил. Работает это действительно не самым лучшим образом, но скорее от неудачной реализации.
Re[15]: Частота ошибок в зависимости от языка: что делать?
FDSC wrote:
> C>Отладка обоих может быть намного дороже написания кода вручную. > Уже есть. Прочитал перевод статьи "NASA's Mission Reliable", Patri*c*k > Regan, Scott Hamilton, IEEE Computer, jan 2004. Впрочем, они не из > NASA. Ссылку дать не могу .
Они используют не генерацию, а автоматическое выделение модели кода, с
последующей формальной верефикацией:
This application proved a few important claims for the technology,
including that it could extract models from source code automatically.
> C>А, ну понятно — наследие Delphi. Нужно различать: язык, компилятор с > C>данного языка и IDE для данного языка. > Различаю, этому меня точно учили. Это была терминологическая > неточность, виноват, исправлюсь. Однако написать слово "компилятор" > несколько проще, чем объяснять, что имеешь в виду целый пакет программ > разработки (который не входит в IDE). В любом случае — уже не по теме.
Однако, это очень большая разница. Тут большинство под словом
"компилятор" все же понимают именно компилятор в отдельности, а среду
разработки+компилятор называют IDE.
> Лучше предложи что-нибудь своё — а я отыграюсь .
У меня, в основном, практические идеи по небольшим улучшениям
существующих языков.
FDSC wrote:
> C>А чего особого? Рисовалась диаграмма классов, к методам делались > C>аннотации в виде их кода (можно еще было их генерировать из диаграммы > C>состояний). Работало все криво и неудобно. > Это не то, о чём я говорил. Работает это действительно не самым лучшим > образом, но скорее от неудачной реализации.
За 10 лет развития UML так ничего удачного и не предложили, так что
можно про этот подход забыть. Кстати, до UMLя тоже были попытки
графического представления программ (с тем же результатом).
Я не понял, поясните пожалуйста.
.
.