raskin wrote:
>> В С++ можно вызывать функции из DLL без всяких "оберток". Скорее всего >> требовалось что-то другое (типа делегатов или хука). > Кажется, всё было именно простейшей обёрткой для функции, динамически > находимой по названию.
А шаблоны были взяты из Loki, скорее всего. Тогда ничего удивительного —
в С++ нету динамческой диспетчеризации, а в Дельфи она есть.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[4]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FDSC, Вы писали:
FDS>>Не согласен. Приложения для систем управления на ней часто пишут.
VD>Часто? А где статистика?
Нет статистики. Привожу примеры: система управления поездами линии метро Парижского метрополитена; автоматизированная станция документальной связи Мин. Обороны РФ; ПО спускаемого аппарата Beagle 2 европейской станции Mars Express.
FDS>> Защита, хорошо, а по поводу поддрежки многопоточности?
VD>Тут безусловно рулят функциональные языки. А Ада нервно курит. Причем по бональным соображениям. В ФЯ легко достигается неблокирующий режим работы. Так что контролировать нечего. А учитывая отсуствие побочных эффектов у функций распараллеливание становится намного более простой задачей.
FDS>>Кстати, что бы не быть голословным: Ада используется фирмой BEA.
VD>Это что, тукседо пишут?
Ошибся с названием фирмы. BAE. Виноват.
FDS>>Об этом много пишут в учебниках, однако я таких ошибок никогда не встречал (видать простые программы были). По моему ошибки обычно больше логического характера возникают. Очень спорный вопрос.
VD>Ну, если ты не встречал такие ошибки, то с вероятностью в 99% ты просто имешь малый опыт. Ну, или ты крут как вареные яйца. У тех же парней из МС или тех что делают Линуксы и т.п. подобных проблем хоть отбавляй. От банальных AV, до переполнений буферов. В общем игра в усидчивость на гигабайтах кода.
С вероятностью 0.99 я программирую в другой области (ну, опыт, в общем, то же не очень). По поводу переполнений буферов: по моему это как раз к логическим ошибкам на этапе алгоритмизации, и очень серьёзным. AV — это Access Violation? Туда же.
FDS>>Вообще, я пытался провести статистику ошибок у себя и некоторых знакомых и пришёл к выводу, что константность, приватность и контроль за преобразованием типов сами по себе исключают довольно малое количество ошибок (по крайней мере в Delhi, в С++ думаю ситуация такая же).
VD>Интересно было бы посмотреть на эту статистику. Я — так просто пользуюсь контролем типов как железным щитом. Любой серьезный рефакторинг в конце концов заканчивается подправкой ошбок компиляции которые на 90% выливаются в ошибки связанные с типами. Более того. Стараюсь проектировать все так, чтобы ошибки как можно чаще выливались в ошибки типов, ловимые компилятором.
Я только пытался её провести (статистику). Такая чушь получилась, если честно, не хочеться показывать, обсмеёте.
По поводу ошибок с типами — я стараюсь проектировать всё так, что бы преобразований типов не было вообще (с Вашей точки зения это, я думаю, неправильно).
Интересно, как я отловлю с помощью преобразования типов ошибку в коде построения сетевого графика, или в численном интегрировании краевой задачи (долго, помню, с ней мучился)? Нет уж, тут сидеть скорее над комментариями надо — чтоб без всяких верификаций несоответствие кода мат. алгоритму было понятно. И вообще, чтоб было понятно какому алгоритму.
VD>Синтаксис, семантика. Это очень не мало. Если ты умешь грамотно формулировать мысли, то семантический контроль позволяет отлавливать очень много ошибок.
Согласен, особенно Warnings помогают, процентов 50 ошибок отлавливают, причём довольно трудно находимых. Однако не все ошибки.
Ещё чуть-чуть и Вы от меня мокрого места не оставите. Предложите своё. Посмеюсь.
Здравствуйте, Cyberax, Вы писали:
C>За 10 лет развития UML так ничего удачного и не предложили, так что C>можно про этот подход забыть. Кстати, до UMLя тоже были попытки C>графического представления программ (с тем же результатом).
VD>>Тут безусловно рулят функциональные языки. А Ада нервно курит. Причем по бональным соображениям. В ФЯ легко достигается неблокирующий режим работы. Так что контролировать нечего. А учитывая отсуствие побочных эффектов у функций распараллеливание становится намного более простой задачей.
Ладно, убедили: Аду на свалку, мне — подучить языки.
Но своё то можно предложить. Как улучшить языки, почему C# лучше C++ (это к VladD2) и т.п.
Считаю, что дальнейшее сравнительное обсуждение конкретных языков Ада и C++ не приведёт ни к чему. Просто тут Аду некому защищать (профессионально), надо адвоката.
Re[5]: Частота ошибок в зависимости от языка: что делать?
FDSC wrote:
> VD>Часто? А где статистика? > Нет статистики. Привожу примеры: система управления поездами линии > метро Парижского метрополитена; автоматизированная станция > документальной связи Мин. Обороны РФ; ПО спускаемого аппарата Beagle 2 > европейской станции Mars Express.
FDSC wrote:
> VD>>Тут безусловно рулят функциональные языки. А Ада нервно курит. > Причем по бональным соображениям. В ФЯ легко достигается неблокирующий > режим работы. Так что контролировать нечего. А учитывая отсуствие > побочных эффектов у функций распараллеливание становится намного более > простой задачей. > www.embedded.com/story/OEG20021211S0034 > <http://www.embedded.com/story/OEG20021211S0034> > Взял остюда пример. По моему Ада вообще не курит. Курят Яву. > Listing 1 An Ada multitasking program
Обычная многотредовая программа, на С++/C#/Java будет выглядеть примерно
так же (с точностью до синтаксиса). _Абсолютно_ другой подход к
многопоточности можно посмотреть в языке Erlang
(http://en.wikipedia.org/Erlang):
Pid = spawn(Mod, Func, Args) % execute function Func as new thread
Pid ! a_message % send message to the thread (asynchronously)
receive % receive message sent to this thread
a_message -> do_something
end.
Здравствуйте, Cyberax, Вы писали:
C>За 10 лет развития UML так ничего удачного и не предложили, так что C>можно про этот подход забыть. Кстати, до UMLя тоже были попытки C>графического представления программ (с тем же результатом).
Ну это ты зря. Текущие проблемы — это только проблемы кривых реализаций
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[4]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, VladD2, Вы писали:
VD>Интересно было бы посмотреть на эту статистику. Я так просто пользуюсь контролем типов как железным щитом. Любой серьезный рефакторинг в конце концов заканчивается подправкой ошбок компиляции которые на 90% выливаются в ошибки связанные с типами. Более того. Стараюсь проектировать все так, чтобы ошибки как можно чаще выливались в ошибки типов ловимые компилятором.
Кстати, при знакомстве со SmallTalk меня больше всего вырубило, что его авторы считают этот механизм ненужным. Там всё на этапе исполнения проверяется.
VD> И там, и там хронятся строки. Но в первом случае они хранятся просто так, а во втором перенесенными на страницу. Так вот если хранить их как строка/символ в строке в обоих случаях и не разделять тиы, то ошибочно посунув вместо индекса перенесенной линии индекс линии из документа ты будешь долго ловить ошибку в отладчие. Если же ввести понятие виртуальных и реальных координат, то контроль за правильностью действий возмет на себя компилятор.
Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!
--
wbr, Peter Taran
Re[5]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, tarkil, Вы писали:
T>Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!
В Аде можно
Re[5]: Частота ошибок в зависимости от языка: что делать?
tarkil wrote: > Здравствуйте, VladD2, Вы писали: > > VD>Интересно было бы посмотреть на эту статистику. Я так просто пользуюсь контролем типов как железным щитом. Любой серьезный рефакторинг в конце концов заканчивается подправкой ошбок компиляции которые на 90% выливаются в ошибки связанные с типами. Более того. Стараюсь проектировать все так, чтобы ошибки как можно чаще выливались в ошибки типов ловимые компилятором. > > Кстати, при знакомстве со SmallTalk меня больше всего вырубило, что его авторы считают этот механизм ненужным. Там всё на этапе исполнения проверяется. > > VD> И там, и там хронятся строки. Но в первом случае они хранятся просто так, а во втором перенесенными на страницу. Так вот если хранить их как строка/символ в строке в обоих случаях и не разделять тиы, то ошибочно посунув вместо индекса перенесенной линии индекс линии из документа ты будешь долго ловить ошибку в отладчие. Если же ввести понятие виртуальных и реальных координат, то контроль за правильностью действий возмет на себя компилятор. > > Во-во. Влад, может быть ты знаешь языки, в которых можно без написания множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, ведёт себя совсем как int, только это совсем другой тип и использовать один вместо другого нельзя"? В горячо мною любимом C++ для этого надо определить класс и все операции вручную. В Java не лучше. Но хоть где-нибудь-то можно?!
Вопрос не мне, но всё же: чем не паскалевский древний
type MyType=type OldGoodType;
Для Integer — пойдёт на ура, насколько я помню.
Может быть у fpc это можно заставить корректно работать с объектами
Posted via RSDN NNTP Server 1.9
Re[15]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, FDSC, Вы писали:
FDS>Может, посветуете что-нибудь то же (для изучения).
Набор стандартный. Для расширения кругозора хорошо изучить:
1. Дотнет/Яву (а лучше обе технологии).
2. Какой-нибудь функциональный язык.
3. С++. Если не доводить его изучение до форм религии, очень помогает.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, Cyberax, Вы писали:
C>Не используют они никаких настроек. Вся Винда сейчас у них компилируется C>на VC7.1, старые версии Винды (до XP SP2) компилируются на VC6.
Сдается мне, что на VC6 компилировалась NT 4. А винды компилируются на чем попалао (например, на исследовательских версиях компиляторов). Ну, а релизы винды компилируются на текущем релизе VC. Хотя тут я ничего утверждать не могу. Это только догадки.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, FDSC, Вы писали:
FDS>Различаю, этому меня точно учили. Это была терминологическая неточность, виноват, исправлюсь. Однако написать слово "компилятор" несколько проще, чем объяснять, что имеешь в виду целый пакет программ разработки (который не входит в IDE). В любом случае — уже не по теме.
Ну, почему же? Как раз очень даже по теме. Ты видимо интуитивно вышел на верную тему.
Для контроля качества нужно применять некие средства анализа. Эти средства неминуемо потребуют наличия парсера. А парсер — это компонент одинаково необходимый как в компиляторе, так и в любых дополнительных средствах вроде IDE или анализаторе кода. Просто ты для себя смешал эти понятия, а они на самом деле имеют иерархическое отношение.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, VladD2, Вы писали:
VD>>Извини, но похоже ты пересидел с Дельфи. Тебе нужно изучить мир за пределами Борланда. IDE это всего лишь инструмент. И Борланд на сегодны далеко не законодатель мод.
FDS>Согласен. Только не знаю, кто законодатель.
На сегодня законодатель IDEA. Дальше как не смешно идет MS и Эклипс. И уже потом Борланд. Первенство МС и т.п. еще обсуждается, но IDEA пока что лидер в желотой майке. У конторы ее выпускающей есть отличное расширение для MS VS — ReSharper. С ним VS 2003 становится просто гипер-средой.
Вот кстати, что мало распространено в мире Борланад — это рефакторинг. Надыбай ReSharper или IDEA-ю и попробуй повозиться с ним. Напиши маленький прокт...
По-моему, рефакторинг является очень мощьным средством повышения качества кода и увеличения скорости разработки (при грамотном применении, коенчно).
FDS>>>Потом, очень много требуется именно от IDE — по крайней мере разделение (действительно разделение, а не как сейчас) архитектуры, кода, обработки ошибок, проверок отладки.
VD>>А как сейчас где?
FDS>Не понял.
Ну, ты говоришь "действительно разделение, а не как сейчас". Вот и интересно про что ты ведешь речь? Где это "как сейчас"?
FDS> Не видел ещё кода (и не слышал, наверное по неопытности), где совершенно отдельно хранится сам код и проверки ошибок к нему.
Странно. Даже дельфи имееть структурированную обработку исключений. А языки типа Efil имеют так же пред- и пост-условия, ну, и другие фишки. Есть так же плагины для C# превросящие декларативный контроль ошибок в этот язык.
Ну, и главное... все это не имеет никакого отношения к IDE. Подобноый контроль делается компиляторами. Конечно можно встроить его в IDE, но это будет частный случай.
FDS>Если по поводу .NET — заню. Это был только пример. Не встречал ошибок, где деструктор вызывается перед конструктором.
Значит ты еще не все встречал. встречал когда конструктор вызывался дважды, а деструктор раз десять, и все это для одного экземпляра. В общем, С++ рулит адназначна.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Частота ошибок в зависимости от языка: что делать?
Здравствуйте, FDSC, Вы писали:
FDS>Ошибся с названием фирмы. BAE. Виноват.
А. Ну, первая несколько известнее и как раз все время Яву испоьзует.
FDS>С вероятностью 0.99 я программирую в другой области (ну, опыт, в общем, то же не очень). По поводу переполнений буферов: по моему это как раз к логическим ошибкам на этапе алгоритмизации, и очень серьёзным. AV — это Access Violation? Туда же.
К логическим? Т.е. если я где-то неверно тип привел, то это логическая ошибка? Ну, да, допустим, что для С++ это можно назвать логической ошибкой. Но как обяснить тот факт, что на Яве или C# (в безопастном режиме) таких ошибок вообще невозможно сделать? Вообще!
FDS>Я только пытался её провести (статистику). Такая чушь получилась, если честно, не хочеться показывать, обсмеёте.
Не, ну, все же интересно...
FDS>По поводу ошибок с типами — я стараюсь проектировать всё так, что бы преобразований типов не было вообще (с Вашей точки зения это, я думаю, неправильно).
Не почему же. Это похвальное стремление. Малость максималистское, но все же. Есть все же безопасные приведения типов. Например int -> long или chat -> int. Ну, или любые понижения типов (down cast). При этом гарантированно проблем с типами не будет. Языки типа Явы и Шарпа делают такие приведения автоматически (не требуя явного на то указания). Причем даже если имеет место приведение типов оно контролируется в рантайме. Так что код в котором имеет место ошибка типов никогда не сможет повредить память и привести к появлению ошибок второго порядка (которые ой как не просто выловить).
FDS>Интересно, как я отловлю с помощью преобразования типов ошибку в коде построения сетевого графика, или в численном интегрировании краевой задачи (долго, помню, с ней мучился)?
Контроль типов — это заслуга языка и рантайма. Плюс от программиста требуется проектирование нацеленное на перекладывание контроля типов на компилятор. А задачи то тут в общем-то не причем.
FDS> Нет уж, тут сидеть скорее над комментариями надо — чтоб без всяких верификаций несоответствие кода мат. алгоритму было понятно. И вообще, чтоб было понятно какому алгоритму.
Ну, контроль со стороны компилятора и рантайма, а так же разные сборщики мусора только облегчает жизнь программисту, но никак не заменяют программиста. Писать алгоритмы и добиваться их верной работы прийдется все же самостоятельно.
FDS>Согласен, особенно Warnings помогают, процентов 50 ошибок отлавливают, причём довольно трудно находимых. Однако не все ошибки.
Все это было бы слишком просто.
FDS>Ещё чуть-чуть и Вы от меня мокрого места не оставите. Предложите своё. Посмеюсь.
Здравствуйте, VladD2, Вы писали:
VD>Значит ты еще не все встречал. встречал когда конструктор вызывался дважды, а деструктор раз десять, и все это для одного экземпляра. В общем, С++ рулит адназначна.
Я такое встречал только в багландовском компиляторе, а он известен тем что в нем очень много ошибок.
Короче не надо говорить про С++ то чего нет.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Частота ошибок в зависимости от языка: что делать?
tarkil wrote:
> VD> И там, и там хронятся строки. Но в первом случае они хранятся > просто так, а во втором перенесенными на страницу. Так вот если > хранить их как строка/символ в строке в обоих случаях и не разделять > тиы, то ошибочно посунув вместо индекса перенесенной линии индекс > линии из документа ты будешь долго ловить ошибку в отладчие. Если же > ввести понятие виртуальных и реальных координат, то контроль за > правильностью действий возмет на себя компилятор. > Во-во. Влад, может быть ты знаешь языки, в которых можно без написания > множества строк кода сказать: "у меня будет тип НомерСимволаВСтроке, > ведёт себя совсем как int, только это совсем другой тип и использовать > один вместо другого нельзя"? В горячо мною любимом C++ для этого надо > определить класс и все операции вручную. В Java не лучше. Но хоть > где-нибудь-то можно?!
В С++ пишешь:
typedef boost::strong_typedef<int> NumberOfSymbolInString;
