Gajdalager wrote: > В теории .Нет кроссплатформенный, а моноплатформенность .Нета происходит > не от каких-либо просчетов в архитектуре или спецификации, а из-за > политики МС.
Вообще-то, я уже как-то флеймил, что из-за некоторых предположений в
модели памяти .NET — его будет сложно портировать на nccNUMA-машины
(когда они появятся ).
Здравствуйте, Hobot Bobot, Вы писали:
R>>Никого же не удивляет, что очень сложно строить мосты и небоскрёбы.
HB>Очень сложно на этапе проектирования — непосредственно делают опалубку и заливают бетон простые рабочие.
Некорректная аналогия: роль "простых работяг", выполняющих элементарные действия, играют не программисты, а компилятор.
"Залить бетон" это как "перегнать вот эту функцию в машинный код" или типа того.
Программист всегда остается "проектировщиком".
HB>И в строительстве (как, наверное, в любой другой отрасли) одно из направлений развития — именно упрощение элементарных операций.
А в разработке ПО элементарные действия принято вообще автоматизировать
Здравствуйте, FR, Вы писали:
K>>Нет, с Немерле не справились бы. Как бы они вывод типов написали бы?
FR>Интересно как вывод типов в продукте может зависеть от языка реализации этого продукта? По твоему трансляторы пролога тоже невозможно на C/C++ написать?
Возмножно, но весьма сложно. В принципе, можно браться за любой сложности задачу, однако, когда сложность превышает все возможные пределы, можно сказать, что решить задачу невозможно (на самом деле, экономически невыгодно).
K>>А вот компилятор C++ на Немерле написать — проще некуда. Только всё равно на 100% поддержку C++ сделать нельзя, как говорится, by design.
FR>выделеннное
Такая же гипербола, как и выделенное ниже:
L_L>>>Ну-ну, вон три человека сумели компилятор С++ с экспортом шаблонов написать, да еще и на С. Наверное, справились бы и с немерле.
А вообще, рад, что развеселил. Смех продляет жизнь. Приятно сделать доброе дело
Здравствуйте, eao197, Вы писали:
K>>Вообще, алгоритмически нетривиальные вещи на C++ неудобно решать.
E>Пример можно?
Как показала моя личная практика, утилита, называемая compiler-compiler, даже на C# пишется гораздо проще, чем на C++. Сейчас экспериментирую с Nemerle. Уже полностью готовы синтаксический и семантический анализаторы входного файла. Вот, ИМХО, написание семантического анализатора и есть нетривиальная алгоритмическая задача. Отмечу, что входной файл для утилитки имеет гораздо более сложную структуру, чем входной файл для yacc. Там нужно обойти и проанализировать AST, сделать подстановки, проверить, чтобы не было рекурсивных подстановок. Потом генерируются совокупность регулярных выражений по описанию лексического анализатора и формальная КС-грамматика по описанию синтаксиса.
Тут можно возразить, что это сделает любой школьник и что есть же более сложные задачи — например, факторизация числа. Но тут рулит не С++ и даже не Nemerle, а метематика (а реализовать можно хоть на ассемблере, Кнут так и делает). Кстати, то же относится и к системе вывода типов в Nemerle. Правда, там есть как математическая составляющая, так и просто сожный в реализации алгоритм. Вот пример того, что на C++ решать неудобно.
E>Именно алгоритмической нетривиальности (а то приводящиеся обычно в качестве демонстрации pattern matching-а разборы синтаксичеких конструций такими назвать довольно сложно).
Всё познаётся в сравнении. Есть задачи, очень неудобно решаемые в императивном стиле, зато удобно решаемые в функциональном. Бывают задачи, обладающие обратным свойством. Очень хорошо, если язык позволяет легко и эффективно решать и тот и другой класс задач. Из известных мне языков таким полезным свойством обладают Nemerle и в меньшей степени Python и Lisp.
Здравствуйте, Alxndr, Вы писали:
A>Некорректная аналогия: роль "простых работяг", выполняющих элементарные действия, играют не программисты, а компилятор.
Однозначного отображения процесса строительства на процесс программирования нет и, ясен пень, быть не может. Впрочем, думаю, что между рядовым строителем и программистом, пишущим код по подробной спецификации, общего достаточно для проведения аналогий.
HB>>И в строительстве (как, наверное, в любой другой отрасли) одно из направлений развития — именно упрощение элементарных операций.
A>А в разработке ПО элементарные действия принято вообще автоматизировать.
Ну так и раствор нынче не лопатами замешивают. По крайней мере, если речь не идет о постройке погреба на даче.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, konsoletyper, Вы писали:
K>>>Вообще, алгоритмически нетривиальные вещи на C++ неудобно решать.
E>>Пример можно?
K>Как показала моя личная практика, утилита, называемая compiler-compiler, даже на C# пишется гораздо проще, чем на C++. Сейчас экспериментирую с Nemerle. Уже полностью готовы синтаксический и семантический анализаторы входного файла. Вот, ИМХО, написание семантического анализатора и есть нетривиальная алгоритмическая задача. Отмечу, что входной файл для утилитки имеет гораздо более сложную структуру, чем входной файл для yacc. Там нужно обойти и проанализировать AST, сделать подстановки, проверить, чтобы не было рекурсивных подстановок. Потом генерируются совокупность регулярных выражений по описанию лексического анализатора и формальная КС-грамматика по описанию синтаксиса.
Реализацией compiler-compiler я сам когда-то занимался в свободное от работы время. На C++, естественно. Никакой алгоритмической сложности там не было -- просто был взят алгоритм генерации правил подстановки Флойда (выслушенный когда-то на курсе системного программирования в университете) и закодирован на C++. Самый сложный кусок -- выделение типов правил грамматики и генерация правил подстановки Флойда занимает всего около 700 строк. И сложности там нет, только объем за счет for-ов.
Так что пример мимо кассы.
Ладно бы вы приводили примеры из области расспознавания образов или речи. Говорят там действительно C++ (как, думаю и другие императивные языки) не у дел.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Андрей Хропов, Вы писали:
АХ> Очень много чего напихали (и еще больше хотят) и теперь попробуй-ка напиши для этого дела компилятор. Я уж не говорю, что он жутко медленным будет.
Самое забавное, что line-by-line компилятор от Microsoft для C++ быстрее, чем их же компилятор для C# Проблема компиляции C++ не столько в сложности языка, сколько в модели включения. Собственно, главный бич C++ и есть (включая проблемы ODR и т.п.). Благо, это понимает большое количество народу, и есть шансы, что дело исправится, возможно, даже до выхода следующего стандарта.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
K>>Как показала моя личная практика, утилита, называемая compiler-compiler, даже на C# пишется гораздо проще, чем на C++. Сейчас экспериментирую с Nemerle. Уже полностью готовы синтаксический и семантический анализаторы входного файла. Вот, ИМХО, написание семантического анализатора и есть нетривиальная алгоритмическая задача. Отмечу, что входной файл для утилитки имеет гораздо более сложную структуру, чем входной файл для yacc. Там нужно обойти и проанализировать AST, сделать подстановки, проверить, чтобы не было рекурсивных подстановок. Потом генерируются совокупность регулярных выражений по описанию лексического анализатора и формальная КС-грамматика по описанию синтаксиса.
E>Реализацией compiler-compiler я сам когда-то занимался в свободное от работы время. На C++, естественно. Никакой алгоритмической сложности там не было -- просто был взят алгоритм генерации правил подстановки Флойда (выслушенный когда-то на курсе системного программирования в университете) и закодирован на C++. Самый сложный кусок -- выделение типов правил грамматики и генерация правил подстановки Флойда занимает всего около 700 строк. И сложности там нет, только объем за счет for-ов.
Кстати, алгоритм получения канонической LR-системы вообще занимает менее 300 строк. Это далеко не самая сложная штука. Нужно распарсить и проанализировать входной файл (а это не так просто в моём случае). Нужно сгенерировать код. Можно ещё поэкспериментировать с нормальным error reporting в алгоритме LR, компиляцией магазинного автомата, автоматизированным построением AST и т.д. Собственно, есть уже формализованные алгоритмы построения КК и здесь главную роль играет не язык, а математика.
E>Ладно бы вы приводили примеры из области расспознавания образов или речи. Говорят там действительно C++ (как, думаю и другие императивные языки) не у дел.
Тут тоже математика, языки ни при чём. Однако, думаю, для таких задач есть свои языки (Lisp, Prolog и т.д.), на которых реализация будет читабельнее
WolfHound, это сюда слил чтобы было удобнее ногами это дело бить? Или чтобы бригада была по ударнее?
А воооще, с идей то как раз можно согласиться. Конечно примитивный язык вряд ли хорош для решения сложных задач. Но вот С++ язык не сложный, а не интуитивный и запутанный. А это, как говорят в Одессе, две большие разницы.
К тому же термин "сложный" не очень хорошо здесь подходит. Я бы его заменил на выразительный.
Так что если фразу заменить на:
"Для решения сложных задач нужен выразительный и гибкий язык.", то я бы с удовольствием под ней подписался. Только С++ отнюдь не выразителен и не так гибок как хотелось бы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>а то я вас не знаю
Люди меняюстя. Меняюстя их привычки и привязанности. Откровенно говоря после занкомства с Nemerle смысл в использовании C# я вижу исключительн из-за того, что у него лучше поддержка в разного рода визардах, технологиях и IDE.
Если в сравнении с C# 2.0 С++ и может еще что-то противопоставить, то в сравнении с Nemerle он сливает по всем пунктам кроме скорости и потреблению памяти в конечных приложениях. Но и тут он не так уж и сильно впереди. И что самое главное с ростом производительности железа и оттачичанием технологий С++ становится все менее и мее актуальным.
В области, прикладного программирования в С++ уже сосем мало тлка. Скоро очередь дойдет и до относительно системного ПО. Первыми будут компиляторы и IDE, а там и до всяких вордов не далеко.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, remark, Вы писали:
R>Какие интересно задачи не позволяет решать С++? Имхо, если С++ сегодня не позволяет, то ни один язык сегодня не позволяет её решить.
Ой, всего лишь одну. Писать надежный и хорошо читаемый код.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Например компилятор nemerle. Написать его на С++ настолько сложная задача что справится с ней не сможет даже мелкософт с его гигабаксами. Меж тем на nemerle его ниписали два студента.
Да ладно тебе. С мегабаксами можно все. Можно и на ассемблере его написать. Создадут отдел планирования, распишут все на фунции по 20 байт. Потом создадут по департаменту для кодирования каждой фичи и в итоге получат нужный результат. Ну, лет так за 5.
Конечно это будет сопоставимо с тем, что два студента могут залудить за 3 года на другом средсве, но все же более чем возможно.
WH>И больше всего у них проблем возникает с ошибками в CLR который сам понимаешь кем и начем написан. А ведь мелкософт может позволить себе нанять элиту.
Видили мы код их элиты.
WH>Что уж говорить о конторах помельче...
А вот это да. Думаю, не видать нам РеШарпера как своих ушей если бы его пришлось писать на С++.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, remark, Вы писали:
WH>>>>А для абсолютно сложных задач нужно что-то попроще и помощьнее. R>>>Под complex он подразумевает не сложный (как алгоритм), а скорее комплексный. Т.е. некая real-world задача с неким абсолютно непредсказуемым набором нефункциональных требований, и которые могут непредсказыемым образом эволюционировать. WH>>И как тут поможет С++?
R>У него нет семантической пропасти.
Ой, так любопытно. Объясни, плиз, что такое "семантическая пропасть"?
Если можно, с примерами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
R>Copyright (c) 2003, 2004 The University of Wroclaw.
R>Всё ясно R>Диплом/кандидатскую кто-то видимо защитил
Это еще что... Прикинь, а Страуструп PhD на С++ заработал.
R>А если серьёзно, то — да как хочешь она будет выглядеть. R>Есть просто надо ограниченный набор структур сериализовать — то просто перечислением полей в функции сериализации. R>Если сериализовать действительно много — то можно подумать о генераторе кода — perl/самописный/готовый — asn.1 или ещё что-то. R>Можно препроцессор подпрячь. R>Можно описать список полей на template metaprogramming, тогда получится compile-time рефлекшн. R>Можно ввести базовые классы для классов и полей, что б автоматически собирать информацию о структуре. R>... R>В общем несколько хватит фантации и какие требования.
Понятно. Ты молодец. Твоя фантазия очень правильно работает. Главное не использовать для этого сам С++. Потому как получится, ну, очень запутанно и неудобно. +100
Ради хомхмы, попробуй любыми перечисленными тобой средствами сделать так чтобы можно было просто пометить тип (один из тысячи) каким-то образом как сериализуемый, и чтобы автоматом, при компиляции, создался код сериализации для всего на что этот тип ссылается (потентциально для всей тысячи классов).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, konsoletyper, Вы писали:
L_L>> Ну-ну, вон три человека сумели компилятор С++ с экспортом шаблонов написать, да еще и на С. Наверное, справились бы и с немерле.
K> Нет, с Немерле не справились бы. Как бы они вывод типов написали бы?
Повторно использовали бы код, делающий то же самое для операнда sizeof() и перегрузки функций?
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, eao197, Вы писали:
E>Главным образом я хочу получить ответ на свой вопрос: E>
E>Вот тут не очень понял. Ты имеешь ввиду, что сложные кроссплатформенные системы нельзя писать на C++? Или что тем, кто не пишет сложных кроссплатформенных систем, C++ с его фичами не нужен?
E>поскольку твою фразу о разработке сложных кроссплатформенных систем я не понял
Мне кажется, он имел в виду, что на С++ очень сложно писать переносимый код. Сложно потому, что стандарт реально почти никем не реализован. Сложно потому, что сложно качесвтенно портировать компиляторы. Сложно потому что много UB. Сложно потому, что язык в угоду оптимизации создает массу сложностей вроде платформно-зависимых типов...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Пример можно? E>Именно алгоритмической нетривиальности (а то приводящиеся обычно в качестве демонстрации pattern matching-а разборы синтаксичеких конструций такими назвать довольно сложно).
Мне кажется замечательным примером могут являться компиляторы Ди и Немерле. Их фронтэнды примерно равны по объему, но по возможностям различюатся в разы. По времени написания тоже. Ди раза в два-три страше.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Константин Л., Вы писали:
КЛ>хм...Издеваешься? Нормальный человек бы описание хоть привел, что тут должно делаться. И то, что ты его не привел — твоя проблема. И не удивляйся, что нико не захочет тебе на это отвечать.
Ну, нормальный человек и так прочесть может . Здесь очевидно разбирается некий язык токены которого лежат в списке decls.
).
