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

VD>>... есть такие фишки как escape analysis…

_>Вот собственно говоря это "продвинутое" решение, которое иногда может сработать в некоторых реализациях на Java и является полным аналогом стандартной работы с памятью в C++. )))

Ага. Разница только в том, что в С++ для этоготприходится брать управление памятью в свои руки, а тут это происходит автоматически и безопасно.

И не "в некоторых", а в основной яав–машине авторов явы которую использует большинство пользователей.

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

VD>И что? Ну написали в МС 100500 тонн кода решающих базовые проблемы силами 100500 программистов, а не пяти. Это их проблемы.

VD>Там где решение в виде библиотек получается хреновым немерл предоставляет макросы.

Ну так собственно и вопрос — уже по всех подобным местам они имеются? ) К примеру как насчёт linq?

VD>Например, то же IO не плохо запихивается в библиотеки без макросов, GUI отлично ложится на ООП, а вот замены буст.спорит–а в дотнете просто нет. Но в немерле мы имеем Nemerle.PEG и Nitra, которые реализованы на макрах и рвут спирит как Тузик грелку.

С IO тоже есть большие вопросы. Кстати, я пока этот вопрос не прояснял... А как у Nemerle с реализацией await/async?

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

VD>Более того. Любой код можно написать без МП. Вопрос лишь в трудозатратах. Корпорации типа МС могут выбрасывать мегобаксы на ветер. Низкое КПД компенсируется высоким качеством результата и пиаром (брендом).

Всё верно (ну кроме рассуждений о затратах, но бизнес вопросы лучше не будем с тобой затрагивать). Но в таком случае становится не очень понятно позиционирование Nemerle. Т.е. он базируется у нас платформе ориентированной как раз на простоту работы (с соответствующей ценой за это), но при этом предлагает сложные профессиональные инструменты. Тебе не кажется, что тут что-то не так? Или же ты можешь чётко сформулировать нишу для Nemerle? )

У того же C++ и МП в нём всё в порядке в этом смысле. Тут и сама платформа не простая, рекомендуемая к использованию только профессионалами, так что МП вполне гармонично вписывается.

VD>Это пример твоей слабой осведомленности и терминологическоц путанницы. Мы не называет макросы библиотекой. Макро–библиотеки немного другое дело.

Ну это ваше личное определение и не надо навязывать его всем окружающим. Или может макросы у вас вынесены в отдельные файлы другого типа и обрабатываемые другими инструментами?

Кстати, в том же Boost'е большая часть библиотек как раз может называться "макро-библиотеками" в твоей терминологии, т.к. они сами по себе вообще не компилируются в объектные файлы.

VD>Они есть и их не так мало. Больше чем для С++, по крайней мере. Точнее так, большая часть шаблонного метапрограммирования закрывает дыры в языке, в то время как в немерле предоставляет DSL–и вроде спирита. Вот где С++-библиотеки для хмл–литерало (чтобы можно было формировать хмл из тегов, а не черт знает чего или возможность декларативно описать конечные автоматы? А строки в плюсах почему формируются допотопными средствами?

Декларативные конечные автоматы в бусте имеются. Как раз недавно кому-то тут приводил пример их симпатичной реализации. А про xml и строки не понял. Что за формирование допотопными средствами? )

И возвращаясь к Nemerle. Библиотека парсера, конечных автоматом и т.п. — это конечно очень хорошо и правильно. Но как с самыми базовыми вещами? У того же C++ самая базовая библиотека (STL) пронизана шаблонами.

VD>Свифт — это немерл без макросов, перегрузки методов и с подсчетом ссылок вместо полноценного ЖЦ.

О как) Кстати, кажется ещё совсем недавно ты спрашивал про разницу в устройстве памяти с C# (да, а ты в курсе про хитрые нюансы этого подсчёта ссылок? Там совсем не обычная реализация). Сейчас ты это уже усвоил, но за вычетом этого по прежнему считаешь эти языки одинаковыми... Похоже потребуется много подобные итераций, чтобы ты разобрался с этим языком.

VD>Он не более системный чем шара, например. В прочем и на шарпе написана ОС (Сингулярити). На Обероне — тоже. Так, что деление на системный и нет — это маркетинговый булшит и каша у тебя в голове.

Сингулярити написана на Sing#, а не на C#. Не надо сказок. ) А в Обероне возможность системного программирования заложена изначально.

VD>Вот что в Википедии написано о Rust:
VD>

VD>Основная задача Rust — быть удобным языком для написания больших клиент-серверных приложений, работающих в сети Интернет.

VD>Позвольте, не это ли предназначение явы, дотнета и всех скриптовых языков?

Вот похоже у тебя все знания о других языках почерпнуты из подобных источников. ) А на сайт самого языка не пробовал заходить? ) Здесь http://www.rust-lang.org указано следующее:

Rust is a systems programming language that runs blazingly fast, prevents almost all crashes*, and eliminates data races.

VD>Что за ниша то? Какие ограничения то?
VD>Вы тут все драйвера пишите, кодеки или ОСы?
VD>Еще раз спрашиваю — что за софт вы пишите на С++.

Вот представь себе и ОС и кодеки и драйверы в одном проекте. ))) А поверх всего этого ещё сложная логика и красивый GUI. Причём всё это работает не на одном устройстве, а на многих (разных типов, на разных ОС и только часть с GUI), объединённых сетью (не интернетом) и должно работать без единой задержки.

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

_>У тебя постоянная путаница между C и C++. Про C++ написано верно, а вот C библиотеки как раз частенько передают в скомпилированном виде. Собственно в этом смысле C# как раз ближе к C, чем к C++. А вот Nemerle с его макросами уже ближе к C++, т.к. без исходников просто не выйдет.

1. Прекрати делать аналогии из мира (из уютного мирка ) С++. Они здесь не работают.
2. Если библиотека решает свою задачу, зачем ее переписывать?
3. Минусуют, а сами на сообщения не отвечают — дак устали уже. Толку 0. Этакий Шеридан, если ты понимаешь о чем я. Ты из раза в раз пишешь ерунду вроде вышеотквоченной. Причем это выдает твое незнание дотнета, а заниматься ликбезом в форуме никто не будет.

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

_>Ну так собственно и вопрос — уже по всех подобным местам они имеются? ) К примеру как насчёт linq?

Линку костыли не требуются он и так работает.

Где нужны были аналоги их давно сделали. Языку уже 10 лет.

Есть вещи которые вы себе и представить не можете. Например computation expressions (билдеры монад) или оператор структурного присваенич.

_>С IO тоже есть большие вопросы. Кстати, я пока этот вопрос не прояснял... А как у Nemerle с реализацией await/async?

Есть аналог на computation expressions. Он чутка медленнее, но сильно гибче. Есть еще макры для многопоточности, но я их не использовал.

_>Всё верно (ну кроме рассуждений о затратах, но бизнес вопросы лучше не будем с тобой затрагивать). Но в таком случае становится не очень понятно позиционирование Nemerle. Т.е. он базируется у нас платформе ориентированной как раз на простоту работы (с соответствующей ценой за это), но при этом предлагает сложные профессиональные инструменты.

Ты малость достал. Давай договоримся, что на этом форуме все программисты профессионалы. И все инструменты проффесиональные.

_>Тебе не кажется, что тут что-то не так? Или же ты можешь чётко сформулировать нишу для Nemerle? )

Nemerle это средство повышения продуктивности программиста. Он не делает чедес. Он просто удобнее многих других языков в своей базе и позволяет сделать его еще более удобным для конкретной задачи.

Ни С++, ни Nemerle не сделают за тебя дизайн, не выберут оптимальный алгоритм, не заменят 30 проффесионалов. Это средство поднять КПД хорошего программиста. От применения Nemerle человек профессиональней не становится. Он просто получает более мощьный инструмент.


_>У того же C++ и МП в нём всё в порядке в этом смысле. Тут и сама платформа не простая, рекомендуемая к использованию только профессионалами, так что МП вполне гармонично вписывается.

СП в не дерьмовое. Тормозное, ограниченное. Не профессиональное, одним словом. Все потому, что организовано на побочных эффектах от шаблонов, а не специальными средствами.

_>Ну это ваше личное определение и не надо навязывать его всем окружающим.

Общее определение библиотек МП не подразумевает.

_>Или может макросы у вас вынесены в отдельные файлы другого типа и обрабатываемые другими инструментами?

Они вынесены в отдельные сборки используемые только во время компиляции. Как тут уже тебе говорили макросы — это плагины к компилятору.

Библиотеки же сущность рантацмная.

_>Кстати, в том же Boost'е большая часть библиотек как раз может называться "макро-библиотеками" в твоей терминологии, т.к. они сами по себе вообще не компилируются в объектные файлы.

Я уже задавал этот вопрос, но ты его проигнорировал. Что кроме спирита в бусте нуждается в МП (не путать с обобщенным кодом) и при этом не является костылями для плюсов?


_>Декларативные конечные автоматы в бусте имеются. Как раз недавно кому-то тут приводил пример их симпатичной реализации.

А импортировать описания из систем моделирования КА они умеют?

_>А про xml и строки не понял. Что за формирование допотопными средствами? )

https://github.com/rsdn/nemerle/wiki/XML-literals

_>И возвращаясь к Nemerle. Библиотека парсера, конечных автоматом и т.п. — это конечно очень хорошо и правильно. Но как с самыми базовыми вещами? У того же C++ самая базовая библиотека (STL) пронизана шаблонами.

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

В дотнете куча своих контецнеров (коллекций в дотнет–терминологит). Плюс в стандартной библиотеке немерла есть ряд имютабл–коллекций удобных при использовании ФП.

VD>>Свифт — это немерл без макросов, перегрузки методов и с подсчетом ссылок вместо полноценного ЖЦ.

_>О как) Кстати, кажется ещё совсем недавно ты спрашивал про разницу в устройстве памяти с C#

Я спрашивал о том что ты подразкмеваешь под этим термином. Не надо выдымывать.

_>(да, а ты в курсе про хитрые нюансы этого подсчёта ссылок?

Не в курсе. Зато в курсе о проблемах этого подхода и что все кто может расстаются с ним в пользу ЖЦ.

_>Там совсем не обычная реализация).

Много где не обычная реализация. Рояги это не играет. Все плюсы и минусы остаются на месте.

_>Сейчас ты это уже усвоил,

Опять менторский тон и надменная спесь? Мое мнение о тебе стремительно ухудшается.

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

Лучше сбей свою спесь. В противном случае я просто брошу общаться.

Прими за данность, что ты можешь быть не прав.

_>Сингулярити написана на Sing#, а не на C#. Не надо сказок. )

И в чем отличие этих языков ты знаешь? Sing# — это шарп в который встроинпаттерн обмена сообщениями. В самом компиляторе джит заменен на компиляцию во время установки (аналог ngen). Это все. GC на месте. Никаких других изменений нет.

Так, что не недо ляля.

_>А в Обероне возможность системного программирования заложена изначально.

И какиеже, позволю узнать? Не указатил ли?

_>Вот похоже у тебя все знания о других языках почерпнуты из подобных источников. )

Ды ты рассуждая о дотнете и туда не удосужился заглянуть.

А на сайт самого языка не пробовал заходить? ) Здесь http://www.rust-lang.org указано следующее:
_>

Rust is a systems programming language that runs blazingly fast, prevents almost all crashes*, and eliminates data races.

И чем этот рекламный булшит противоречит процитированному мной? Мы уже выяснили, что systems означает "наличие указателей" гы–гы.


_>Вот представь себе и ОС и кодеки и драйверы в одном проекте. )))

Не, не представляю. Хотелось бы прямой ответ услышать. Как–то глупо красивый гуй поверх драйверов выглядит.

Если вы пишите утилиты для ОС, то так и скажи. За одно скажи для какой, а лучше прямо "какие".

_>А поверх всего этого ещё сложная логика и красивый GUI. Причём всё это работает не на одном устройстве, а на многих (разных типов, на разных ОС и только часть с GUI), объединённых сетью (не интернетом)

Это одна софтяра или несколько?

_>и должно работать без единой задержки.

Без задержки даже одна инструкция процессора не исполняется. Ты это обязан знать.

Стало быть речь идет о предсказуемых задержках, ака гарантированном времени отклика, ака риалтайм или о просто быстро коде.

Я так и не понял о чем речь.

Гуй на С++ пишете?

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

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

VD>Что, за исключением спорита (превосходящих его аналогов макросов сразу два) , есть в тесте, что нет в библиотеках дотнета или в самом дотнете? Только конкретно.

Ты снова не понимаешь или притворяешься? Я же уже несколько раз повторил, что речь не о библиотеках, которых вообще нет в .net, а о библиотеках, переписывание которых с помощью МП позволяет добиться более эффективных результатов.

_>>Для всего этого надо:
_>>1. Целенаправленное желание
_>>2. Ресурсы для реализации
VD>А можно узнать реализации чего ты ждешь?

То, что предложил человек, которому я отвечал. )

_>>И насколько я вижу у Nemerle и C++ тут совсем разные расклады.
VD>А можно о расскладах по по подробнее?

Ну например размер команды работающей над языком у Nemerle и у C++ весьма разный. Это по поводу пункта 2. Ну и с первым пунктом разница видна уже по этой темке.

VD>Вот нормальная IDE для плюсов за 30 лет уже появилась?

Под винду есть 4 штуки, под линух тоже 4 (других), под мак 3 вроде. ) Это без учёта всяких там бета-версий и т.п. )

VD>А когда буст.спирит дотянет хотя бы до немерле.ПЕГ? А когда Qt дотянет до WPF?

А по какому конкретно параметру спирит должен дотянуться до PEG? ) Можно увидеть какие-то таблицы со сравнительным тестированием и т.п.? Кстати, заметь, я совсем не утверждаю что кто-то из них лучше в чём-то. У меня просто нет информации о подобном сравнение. Но и верить тебе на слово как-то сомнительно после многих очевидных проколов в данной дискуссии. Так что хотелось бы увидеть результаты тестов.

Qt лично мне не нравится. Но wpf ещё более сомнительное решение.

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

EP>В Nemerle библиотека с макросами — это фактически плагин к компилятору, распространяемый в виде динамической библиотеки (бинарной).

Так к компилятору то какому, не C# же (или каком-то другому из .net). Тут же речь шла о невозможности использования кода с макросами из безмакросового языка. Так же как из языка без шаблонов (ну т.е. C) не получится использоваться большую часть Boost'a.

Здравствуйте, alex_public, Вы писали:
_>Ну так я же вроде как указал, что это требуется только для достаточно редкой ситуации. Т.е. в большинстве случаев стандартные средства и так быстрее всех.
Ну откуда они могут быть "быстрее всех", когда за каждое убийство объекта приходится платить вставкой в список свободных?
Объекты фиксированного размера со стековым временем жизни в дотнете делаются на структурах и работают с той же скоростью, что и в С/С++.
А объекты динамического размера (строки, массивы) при детерминистической финализации таки проигрывают практически любому современному GC.

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

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

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

VD>Это ты тоже от незнания говоришь. (ну как тут не говорить о твоей компетенции?)

VD>У немерла есть библиотеки, которые обратно совместимы с дотнетными и есть макро–библиотеки, которые уникальны для немерла. Так вот, библиотеки дотнета являются для немерла родными. Никаких приседаний для их использования делать не надо. Аналогия с С/С++ не верна. И об этом тебе сказали даже ярые противники немерла (и мои).

Так в Nemerle код с макросами обязательно должен быть выделен в специальные файлы или же нет? Если нет, то я всё правильно написал. А если да, то тогда это получается какой-то внешний препроцессор и всё. )


VD>С и С++ имеют разный набор поддерживаемых парадигм. В С нет классов и шаблонов. Естественно это приводит к дизайну либ не свойственному плюсам.

VD>В Шарпе же (на котором пишется подавляющее большинство либ) есть и клаввы, и дженерики и функци высшего порядка. В нем нет только макросов и не принято писать код в функциональном стиле. Это усложняет написание кода, но этотне проблема для их использования.

Ну так и не проблема использовать C библиотеку в C++ коде. Собственно мы некоторые даже используем, т.к. их аналогов на C++ не найти (например определённая реализация Пролога). Но лучше бы C++ библиотеку. Так же как лучше родную Nemerle библиотеку (сам же сказал, что "усложняет написание").

VD>Их очень много. Мне за твое образование не платят. Да и как домысел вроде "в немерле дотнетные библиотеки не родные и их нужно переписать, потому что я имел опыт с С и С++ говорящий об этом" можно опровергнуть ссылкой? Это очевидный бред, но очевидно он только тем кто серьезно использовал, хотябы, шарп. Рассказывать кучу мелких деталей устройства дотнета, чтобы переубедить одного некомпетентного человека — явный оверкил.

Переписать очевидно не все, а только те, которые будут заметно эффективнее при использование Nemerle. Если же таких совсем мало, то как бы получается вывод что просто Nemerle — не нужен...

VD>По поводу "системности" языка я попросил от тебя определение. Ты сказазал, что системный язык — это язык с указателями. Я тебе ответил, что они есть в шарпе и немерле.

Я такого не говорил. Это ты домыслил за меня. Ещё одна черта к твоему стилю ведения дискуссии.

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

VD>Казалось бы вопрос исчерпан, но ты продолжаешь гнуть линию не приводя ни одного разумного аргумента. Не считать же чешь вроде "Не забудь ещё отправить в топку обязательный сборщик мусора" аргументом? С какого перепуга надо выбрасывать сборщик? Как это опровергает факт поддержки указателей в дотнетных языках?

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

Ты для начал покажи, где я ввёл такое определение. )

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

VD>Ага. Разница только в том, что в С++ для этоготприходится брать управление памятью в свои руки, а тут это происходит автоматически и безопасно.

О да, написать "A a;" это конечно же намного сложнее, чем написать "A a=new A;". )

VD>И не "в некоторых", а в основной яав–машине авторов явы которую использует большинство пользователей.

Под некоторыми здесь подразумевалась не jvm, а ситуация в которой сработает этот анализ. В отличие от C++ (и ему подобных), где это чётко детерминировано.

Вообще, если говорить о сборщика мусора в современном программирование, то есть вот такая http://habrahabr.ru/post/188580/ очень полезная статья. Заголовок и вступление вроде как не про GC, но где-то с середины начинается самое интересное... )

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

DS>1. Прекрати делать аналогии из мира (из уютного мирка ) С++. Они здесь не работают.
DS>2. Если библиотека решает свою задачу, зачем ее переписывать?
DS>3. Минусуют, а сами на сообщения не отвечают — дак устали уже. Толку 0. Этакий Шеридан, если ты понимаешь о чем я. Ты из раза в раз пишешь ерунду вроде вышеотквоченной. Причем это выдает твое незнание дотнета, а заниматься ликбезом в форуме никто не будет.

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

Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Я думаю это дело даже можно частично автоматизировать — если после копии ref-counted куда-то, он больше не использовался — то достаточно move'а.
О, ещё немного — и вы изобретёте escape analysis.

EP>>>Поделись соображениями. С одной стороны у нас редкие wait-free inc/dec,
WH>>Про то, что они редкие это исключительно твоя спекуляция.
EP>Причём достаточно чтобы счётчик прошёл только следующую последовательность состояний: "1, 2, 1, 0". А вот передёргивать при переходе, например, от состояния "получаем" к "отправляем" — нет никакой необходимости, достаточно move — так как эстафета передаётся.
И как компилятор гарантирует нам отсутствие обращений к источнику после move?

EP>Раз он точный, то память уплотнить (и обновить указатели) не проблема, но ограничения определённые есть. При решении каких-то затейливых задач с жёсткими циклами — вполне себе вариант.
Точный GC в реальный C++ воткнуть не удастся. Потому что в нём 99% библиотек написаны в стиле "если сейчас луна в ущербе, то lParam — это указатель на cтруктуру; а если зима — то это идентификатор ресурса. Тип структуры определяется полем length".

EP>Но доступность-то не гарантированна, значит нет надёжности
EP>А вот что в случае бага вылетит — AV или исключение — рояли не играет. Баг есть баг.
Конечно же это играет роль! Детерминированный крэш однозначно выигрывает у UB. С учётом того, что в 99.99% UB — это вовсе не AV, а всего лишь инкремент чего-то не того. Type safety нету от слова совсем, а с битами манипулировать можно как угодно.
Классическая штука — я вызываю FileClose() на том, что считаю хэндлом файла. Если я использую поле от убитого объекта, у меня есть хорошие шансы скормить в FileClose мусор.
И иногда программа будет падать с ошибкой, а иногда будет просто закрывать валидный хэндл. А в жире годами будет висеть бага "иногда запись в файл самопроизвольно прерывается", а девелоперы будут считать, что глючная винда имеет наглость раз в иногда принудзакрывать файл, в который пишет активный процесс.

EP>Грубо говорят если из-за бага в алгоритме он вышел за пределы диапазона, но кинул исключение — работу свою он не выполнил, постусловий не достиг, перевёл программу в неопределённое состояние.
В том то и дело, что программу он перевёл в определённое состояние. Это гораздо, гораздо лучше неопределённого состояния, которым так гордятся программисты C++.

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

VD>Линку костыли не требуются он и так работает.

Хреново он работает, небыстро. Народ костыли наподобие LinqOptimizer делает, чтобы адекватную производительность получить. В немерле же сделать linq на макросах сам Б-г велел.

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

subj: Nemerle через 5 лет — выстрелит или скончается?
если выстрелит, то это не значит, что не скончается.

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

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

Они были, но ты их как-бе не заметил. Были, но ровно один раз, в отличии от Влада, который тебе повторяет по 100 раз.

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

VD>Линку костыли не требуются он и так работает.

Если руководствоваться правилом "и так работает", то в общем то и Nemerle вообще не нужен, т.к. C# вообще то тоже вполне "и так работает".

А вот если всё же пытаться что-то улучшить, то можно увидеть что IEnumerable является очень бледной тенью Range из D. Причём как раз Nemerle (ну судя по тому, что ты о нём говоришь — я то его не изучал пока) мог бы легко поправить это.

VD>Где нужны были аналоги их давно сделали. Языку уже 10 лет.

Точно вот прямо все сделали? )

VD>Есть вещи которые вы себе и представить не можете. Например computation expressions (билдеры монад) или оператор структурного присваенич.

Гмм... И кто это только что говорил о самомнение, снисходительном отношение и т.п? )))

VD>Есть аналог на computation expressions. Он чутка медленнее, но сильно гибче. Есть еще макры для многопоточности, но я их не использовал.

Я правильно понял, что C# код с await/async в Nemerle сейчас работать не будет? А как тогда реализована работа с IOCP?

VD>Nemerle это средство повышения продуктивности программиста. Он не делает чедес. Он просто удобнее многих других языков в своей базе и позволяет сделать его еще более удобным для конкретной задачи.

Это не разговор. Нужна целевая ниша. Я вполне понимаю где выгодно применять Java/C#, где выгодно C++, а где Python и т.п. Так вот для Nemerle у меня нет такого же понимания. Потому как базируясь на платформе ориентированной на снижение цены разработки, он наоборот требует повышенной квалификации от программиста.

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

Ты периодически как-то извращённо понимаешь мои слова. Когда я говорю о профессиональных инструментах, то совсем не подразумеваю, что использование этого инструмента сделает человека профессионалом, как ты почему-то подумал. Откуда такая странная мысль? Я под этим подразумеваю, что для использования этого инструмента требуется повышенный уровень знаний, т.е. что имеется большой порог вхождения. И это как бы минус в условиях современного бизнеса, который должен обязательно чем-то компенсироваться.

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

VD>Они вынесены в отдельные сборки используемые только во время компиляции. Как тут уже тебе говорили макросы — это плагины к компилятору.

Про плагины я давно видел. Но я так и не понял, имеется ли какое-то чёткое формальное разделение nemerle кода с макросами и без?

VD>Я уже задавал этот вопрос, но ты его проигнорировал. Что кроме спирита в бусте нуждается в МП (не путать с обобщенным кодом) и при этом не является костылями для плюсов?

Насчёт костылей тут очень тонкий вопрос... Потому как многие вещи имеют реализацию в .net, но при этом исключительно времени исполнения. В то время как в Boost'е имеется аналогичные реализации, но времени компиляции. Я думаю ты не станешь спорить о том, какая реализация эффективнее (тем более, что на Nemerle можно сделать как раз как в C++ и даже лучше)? Так вот если учитывать такие вещи, то можно сразу гору библиотек накидать. Ну а если нет, то конечно же их сильно меньше будет. С ходу кроме Spirit'a вспоминаются Boost.Unit, Boost.Xpressive, Boost.MSM. Это из тех, что я сам трогал, а это естественно далеко не все.

Ну а вообще для программирование на Nemerle я бы поискал образцы скорее в стандартной библиотеке D, а не в Boost'e. Всё же в C++ МП слабенькое...

_>>А про xml и строки не понял. Что за формирование допотопными средствами? )
VD>https://github.com/rsdn/nemerle/wiki/XML-literals

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

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

VD>В дотнете куча своих контецнеров (коллекций в дотнет–терминологит). Плюс в стандартной библиотеке немерла есть ряд имютабл–коллекций удобных при использовании ФП.

Я правильно понял, что ты считаешь, что с помощью МП улучшать в контейнерах .net'a нечего? )

VD>Не в курсе. Зато в курсе о проблемах этого подхода и что все кто может расстаются с ним в пользу ЖЦ.

Там счётчик и кое-какие флаги хранятся в самом указатели (на 64-ёх битных процессорах естественно).

VD>Прими за данность, что ты можешь быть не прав.

Готов принять, если и ты готов. )

VD>И в чем отличие этих языков ты знаешь? Sing# — это шарп в который встроинпаттерн обмена сообщениями. В самом компиляторе джит заменен на компиляцию во время установки (аналог ngen). Это все. GC на месте. Никаких других изменений нет.

VD>Так, что не недо ляля.

Цитирую из твой любимой википедии (http://en.wikipedia.org/wiki/Spec_Sharp):

Sing Sharp (or Sing#) is a superset of Spec Sharp. Microsoft Research developed Spec#, and later extended it into Sing# in order to develop the Singularity operating system. Sing# augments the capabilities of Spec# with support for channels and low-level programming language constructs, which are necessary for implementing system software.

Так что там про ляля? )

VD>И чем этот рекламный булшит противоречит процитированному мной? Мы уже выяснили, что systems означает "наличие указателей" гы–гы.

Мдааа. )


VD>Это одна софтяра или несколько?

Это программно-аппаратный комплекс, состоящий из нескольких взаимодействующих модулей. )

VD>Без задержки даже одна инструкция процессора не исполняется. Ты это обязан знать.

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

Да, местами реалтайм (это в микроконтроллерах), а местами просто быстрый код (это в "кодеках").

VD>Гуй на С++ пишете?

Да)

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

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

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

VD>>Что, за исключением спорита (превосходящих его аналогов макросов сразу два) , есть в тесте, что нет в библиотеках дотнета или в самом дотнете? Только конкретно.

_>Ты снова не понимаешь или притворяешься?
Да сколько можно...

_> Я же уже несколько раз повторил, что речь не о библиотеках, которых вообще нет в .net,
В смысле нет? Весь дотнет это огромный конгломерат библиотек — dll-ек. Плюс мульон сторонних библиотек.

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

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

S>Ну откуда они могут быть "быстрее всех", когда за каждое убийство объекта приходится платить вставкой в список свободных?
S>Объекты фиксированного размера со стековым временем жизни в дотнете делаются на структурах и работают с той же скоростью, что и в С/С++.

О, т.е. мы можем взять экземпляр любого класса и разместить его в стеке или как?

S>А объекты динамического размера (строки, массивы) при детерминистической финализации таки проигрывают практически любому современному GC.

Только при условие бесконечной памяти. Я уже кинул Владу ссылку на полезную статью на эту тему. Ну повторю на всякий случай: http://habrahabr.ru/post/188580/. Причём в статье рассматривается ситуация с мобильными устройствами — там вообще мрак. Но и на больших системах память всё равно не бесконечна.

P.S. В C++ строки далеко не всегда хранятся в куче. Ну это я так, просто мелкий штришок к сведению. )

Здравствуйте, alex_public, Вы писали:
_>О да, написать "A a;" это конечно же намного сложнее, чем написать "A a=new A;". )
Вы мне лучше расскажите, что будет, если я потом напишу

return &a;

Вся штука escape-анализа — в том, что он сам определяет, передаю ли я ссылку за пределы скоупа, или можно обойтись стеком. С гарантиями.
А у вас в реальном коде будут постоянно развлечения на ровном месте. Для примитивных типов, понятное дело, семантика копирования заменяет вообще всё и решает все проблемы.
Вот только в дотнете для них же имеем ровно ту же реализацию.
А как только вы выйдете за их пределы и начнёте работать хотя бы со строками, вот тут и начнётся веселуха — либо беспричинные копирования со штрафом O(N), либо шансы нарваться на обращение к уничтоженному объекту, либо рефкаунты. А escape analysis позволяет программисту не думать о том, какие строки у него временные, а какие — надолго.
То есть уже 20 лет GC позволяет не думать об этом; EA всего лишь даёт дополнительную возможность снизить нагрузку на GC для алгоритмов с большим количеством временных объектов, в которых можно заменить new на stackalloc.

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

_>>О да, написать "A a;" это конечно же намного сложнее, чем написать "A a=new A;". )
S>Вы мне лучше расскажите, что будет, если я потом напишу
S>

S>return &a;
S>

А зачем мне так писать? ) Я напишу:

return a;

И сразу замечу, что никакого копирования тут не будет (начиная ещё с C++11). Точнее оно и до C++11 могло сработать без копирования (RVO), но это была просто возможная оптимизация. А теперь это 100% гарантия на базе конструкции языка (move constructor). Точнее опять же может сработать просто RVO (и тогда вообще никаких действий не производится), а если не сработает, то гарантированно отработает мгновенный move constructor.

S>Вся штука escape-анализа — в том, что он сам определяет, передаю ли я ссылку за пределы скоупа, или можно обойтись стеком. С гарантиями.

Да, иногда определяет. )

S>А у вас в реальном коде будут постоянно развлечения на ровном месте. Для примитивных типов, понятное дело, семантика копирования заменяет вообще всё и решает все проблемы.
S>Вот только в дотнете для них же имеем ровно ту же реализацию.
S>А как только вы выйдете за их пределы и начнёте работать хотя бы со строками, вот тут и начнётся веселуха — либо беспричинные копирования со штрафом O(N), либо шансы нарваться на обращение к уничтоженному объекту, либо рефкаунты. А escape analysis позволяет программисту не думать о том, какие строки у него временные, а какие — надолго.

Move semantics позволяет всё тоже самое, только ещё более эффективно (потому как детерминировано).

S>То есть уже 20 лет GC позволяет не думать об этом; EA всего лишь даёт дополнительную возможность снизить нагрузку на GC для алгоритмов с большим количеством временных объектов, в которых можно заменить new на stackalloc.

Если бы все эти плюшки GC были бы совершенно бесплатными, то никто бы и не спорил (собственно тогда бы наверное не осталось языков без GC).

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

_>А зачем мне так писать?
Затем, что у вас в сигнатуре — A*.

) Я напишу:
_>

_>return a;
_>

_>И сразу замечу, что никакого копирования тут не будет (начиная ещё с C++11). Точнее оно и до C++11 могло сработать без копирования (RVO), но это была просто возможная оптимизация. А теперь это 100% гарантия на базе конструкции языка (move constructor). Точнее опять же может сработать просто RVO (и тогда вообще никаких действий не производится), а если не сработает, то гарантированно отработает мгновенный move constructor.
Ок, я был недостаточно убедителен.
Отлично — вы пишете

auto b = someOtherCoolFunction(a);

Как будет работать move constructor? Я так понимаю, что без inlining-а у компилятора маны не хватит на замену copy на move.
А если вы обнаружите, что стоимость копии a здесь чрезмерна, то попробуете передавать его по ссылке.
Но у вас нет никакой гарантии на то, что эту ссылку someOtherCoolFunction не прикопает ещё где-то — например, не передаст её в другой поток.
То есть мы опять возвращаемся к ручному управлению временем жизни и надежде на то, что "авось не стрельнет".
_>Move semantics позволяет всё тоже самое, только ещё более эффективно (потому как детерминировано).

Расскажите вкратце, как move semantics определяет, где её можно использовать, а где — нельзя.

_>Если бы все эти плюшки GC были бы совершенно бесплатными, то никто бы и не спорил (собственно тогда бы наверное не осталось языков без GC).
Зависит от задачи. Понятно, что если у вас адски ограниченный memory footprint, то GC — не ваше всё.