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

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

Хыхы, я тут с тобой согласен. Но хочу заметить, что такие маньяки всё же имеются. Причём это не какие-то извращенцы из мира IT, а вполне себе солидные люди — CERN. Просто у них там достаточно специфические задачи (точнее требуемая для них вычислительная мощность), так что их совершенно не смущает идея скриптов (у них там полноценный REPL создан) на C++. Вот https://root.cern.ch можешь полюбоваться.

VD>В конкретных случаях всегда можно придумать более интересные решения. Вот для тех же матриц можно придумать вот такое:
VD>http://omega.sp.susu.ru/books/conference/PaVT2011/full/117.pdf
VD>Можно такое сделать на С++ или Питоне?

Хм, ну вообще то в gcc уже давно добавили поддержку намного более высокоуровневой абстракции для реализации подобных вычислений. Смотри OpenACC (идеологический наследник OpenMP, но уже для GPU, а не CPU). Это если говорить именно на уровне языка, а не каких-то специализированных библиотек.

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

VD>Плюс такие люди тормоза того же дотнета всегда списывают на GC, что по сути — миф. Более того они видят недостатки GC там где их нет. А о реальных недостатках или не догадываются, или не берут их в расчет. Так основная проблема GC вовсе не мифические паузы при сборке мусора, а разные мемори-барьеры, требуемые для инкрементального сбора мусора.

Интересно а кто тут писал что тормоза .net'а от GC? ) Я что-то не помню таких. Проблемы классических реализаций GC следующие: stop-the-world и недетерминированное время сборки. И указанные вещи являются проблемой не для быстродействия (грубо говоря числодробилке это не принципиально), а для реалтаймовых и Low Latency задач.

VD>Ну, а 90% тормозов дотнета связаны даже не с этим, просто с посредственной кодогенерацией и в отсутствие возможностей управлять процессом кодонерерации для всех этих мемори-барьеров.

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

Кстати, в .net native рефлексия считай убита. И есть разговоры об инструментах размещения любых данных на стеке. Вот если к такому решению приделать нормальный кодогенератор (что кстати в MS и собираются сделать, взяв свой бэкенд от C++), то уже можно получить более менее приемлемое быстродействие. Только это уже будет решение имеющее мало общего с современным большим .net'ом. )))

VD>Далее проблемы пауз при работе GC (которые во многом надуманы) опять же связаны с тем, что GC глобальный. Если ввести в язык возможность использования множества маленьких GC и дать программисту явно указывать какие объекты в них должны попадать и когда лучше собирать мусор в каком из них, то эффективность GC может оказаться сильно выше, чем ручного управления памятью. А вот затраты сил и времени на такие аннотации могут быть куда меньше чем на ручное управление (я говорю о дестркуторах и прочих смартпоинтерах). И главное, в такой модели будет контроль и безопасность такой же как в языках с глобальным GC.

Вообще то как раз то, что ты описал — это и есть ручное управление. В гораздо большей степени, чем в C++.

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

VD>Уверен, что и Питоне тоже самое. Ты можешь даже не знать, что некоторая фича сделана через МП, но ты можешь ее использовать.

Нет, в Питоне вообще не особо развиты средства для работы с МП. Метаклассы, декораторы, больше даже и не припомню с ходу что ещё может быть использовано для МП (традиционную для всех скриптовых языков функцию eval мы естественно не упоминаем — это "плохое" МП). Так что в большинстве обычных библиотек можно вообще не встретить ни одного применения МП.

VD>Если получится хорошо бы вообще сделать шаблоны как расширение дженериков. Типа дописываем к описанию дженерик-типа ключевое слово template и получаем недостающее поведение:
VD>

VD>template class A<T>
VD>  where T: _+_ // T поддерживает бинарный оператор сложения
VD>{
VD>  public Sum(a : T, b : T) : T
VD>  {
VD>    a + b
VD>  }
VD>}
VD>...
VD>def x = A().Sum(40, 2);              // OK x == 42
VD>def x = A().Sum(36, 0.6);            // OK x == 36.6
VD>def x = A().Sum("Hello ", "World!"); // OK x == "Hello World!"
VD>def x = A().Sum("Hello ", 42);       // Error: нет неявного приведения между числом и строкой
VD>def x = A().Sum(A<int>(), A<int>()); // Error: A<T> не поддерживает оператор "+"
VD>

Выглядит не плохо. Правда в таком виде оно всё равно будет уступать по лаконичности и Питону (где Т вообще не надо) и Хаскелю (где T не указывается программистом (но существует) потому что ограничения на него выводятся компилятором самостоятельно по коду функции). Но лично мне подходит.

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

VD>Кому нужны расчеты на матрицах написанные на Питоне?

Безотносительно к основной дискуссии не могу не заметить, что именно это является крайне популярным явлением в научном мире. Значительная часть вычислений проходит на Питоне, потому что он весьма удобен как язык (особенно для не айтишников) и имеет крайне эффективные библиотеки (написанные естественно на C/C++) в этих областях. Т.е. набор Python+NumPy+SciPy+SymPy+Matplotlib — это сейчас во многих местах практически стандарт де-факто научного рабочего места. )))

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

WH>Ускорять разработку за счёт большого количества низкоквалифицированных программистов идиотизм.
Ага, точно так же как писать на динамических языках. Погоди ка...

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

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

WH>>Ускорять разработку за счёт большого количества низкоквалифицированных программистов идиотизм.
DE>Ага, точно так же как писать на динамических языках. Погоди ка...
Именно. Никто так и не показал задачу на которых они дают преимущество.

DE>Ну а если серьёзно, то (практически?) в любом масштабном проекте найдутся участки как более сложные, так и более простые и рутинные. Не думаю, что даже самый чудесный ДСЛ сможет ситуацию принципиально поменять: кто-то будет писать и поддерживать ДСЛ, кто-то использовать. Собственно, Go можно считать таким специфическим языком (пусть и "общего назначения") для определённых целей.
И для какой же задачи это образцовое убожество является ДСЛем?

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

VD>Я с тобой полностью согласен, но на практике это не так. На практике люди освоившие молоток С++ используют его для решения всех проблем. В том числе и тех, что лучше решать на языке с GC.

Не спорю, но опять же, это не только с С++ работает. JavaScript во всякие ардуины по той же причине тащат.

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

И тут спорить не буду, но справедливости ради, затраты на смартпоинтеры не такие большие, как кажется. Если бы в С++ ещё и везде именно они вместо обычных указателей использовались, то было бы ещё проще. Плюс в ряде моментов когда придётся к таким аннотациям прибегать, то в C++ объекты создадутся тупо на стеке.
Проблемы возникают как раз в сложных случаях когда начинают городить shared_ptr и да, тут легко можно наделать такого, что оно будет тормозить хуже любого GC.

Но вообще пример с аннотациями выглядит интересно.

VD>Скорее это говорит о том, что нет особого смысла отключать GC. Надо тебе жить без него — используй объекты размещаемые на стеке.

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

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

_> Так вот из нативных (т.е. не требующих отдельной установки специального рантайма и позволяющих эффективно работать с системным API на любой платформе) языков у нас к мейнстриму сейчас относятся наверное всего четыре: C, C++, Go, Swift. Но Swift вычёркиваем сразу, если мы не хотим ограничиться мирком Apple. Из оставшихся: Go — имеет слабую кроссплатформенность и быстродействие, C — неудобный и небезопасный язык. И оба они отстают от C++ по набору библиотек и возможностям языка. Так что выбор как бы очевиден.

Ты же понимаешь, что вводишь ряд дополнительных ограничений? "Необходимость установки специального рантайма" далеко не всем мешает. Если что, пишу я именно на С++ и совсем от этого не страдаю, но прекрасно понимаю почему могут выбирать C#, джаву и т.д.
"Вменяемые команды" — это, опять же, упор на эмоции.

Опять же, не имеет смысла сравнивать в глобальном плане Go и С++ — вполне себе найдутся задачи, где первый подойдёт и нужные библиотеки будут в наличии.

Ну и Swift работает даже на виндовс. Не то чтобы призываю использовать и понятное дело, что есть нюансы, но это совсем не категоричное "ограничиться мирком Apple".

_>Не надо там ничего отключать. Достаточно его просто не использовать и всё.

Это никак не отменяет сказанного мной. "Не использование GC ведёт к невозможности использовать многое из стандартной библиотеки". Стало лучше?

И "просто не использовать" не получится — это не какой-нибудь shared_ptr, который надо использовать явно. Приходится именно идти на дополнительные ухищрения, скажем, выделять память не через new и т.д.

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

WH>Именно. Никто так и не показал задачу на которых они дают преимущество.

И тем не менее, их продолжают широко использовать.
Если что, я не агитирую за динамику.

WH>И для какой же задачи это образцовое убожество является ДСЛем?

Написание сравнительно эффективного параллельного кода без утечек и расстрелов памяти после прочтения коротенького мануала.

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

DE>И тут спорить не буду, но справедливости ради, затраты на смартпоинтеры не такие большие, как кажется.

Я говорю не о производительности кода, а о затратах интеллектуальных на организацию и поддержку непротиворечивого управления памятью. Чем больше программа и чем она сложнее, тем больше эти затраты. И тем проще сделать ошибку.

DE>Если бы в С++ ещё и везде именно они вместо обычных указателей использовались, то было бы ещё проще.

Ну, да. Если лихие джигиты начинают орудовать голыми указателями (void** наше все), то пиши пропало.

DE>Проблемы возникают как раз в сложных случаях когда начинают городить shared_ptr и да, тут легко можно наделать такого, что оно будет тормозить хуже любого GC.

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

DE>Но вообще пример с аннотациями выглядит интересно.

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

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

VD>>Скорее это говорит о том, что нет особого смысла отключать GC. Надо тебе жить без него — используй объекты размещаемые на стеке.

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

Есть огромная разница в возможности жить без ЖЦ и в необходимости его отключать. Ведь, чтобы жить без ЖЦ достаточно не занимать в нем памяти.

DE>Иначе это отключение чисто для галочки существует, если сразу приходится делать кучу вещей вручную.

А оно и не нужно в общем-то. Нужно в критичных местах иметь возможность перйти на ручное управление. Плюс в местах хорошо ложащихся на стек, тоже можно обоийтись без ЖЦ-объектов. А когда объем управляемых ЖЦ объектов не велик, то и ЖЦ летает.

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

VD>Я говорю не о производительности кода, а о затратах интеллектуальных на организацию и поддержку непротиворечивого управления памятью. Чем больше программа и чем она сложнее, тем больше эти затраты. И тем проще сделать ошибку.

Так я тоже об интеллектуальных затратах говорю. В простых/средних случаях всё легко: написать make_unique не сложнее чем new. В сложных случаях, конечно, всё непросто, но и с GC можно напортачить и оставить висеть в памяти ненужные объекты, хоть и сложнее. То есть, думать всё равно приходится.

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

DE>Так я тоже об интеллектуальных затратах говорю. В простых/средних случаях всё легко: написать make_unique не сложнее чем new. В сложных случаях, конечно, всё непросто, но и с GC можно напортачить и оставить висеть в памяти ненужные объекты, хоть и сложнее. То есть, думать всё равно приходится.

С ЖЦ напортачить это еще надо умудриться. Если только какие-нибудь события (не явно создающие обратные ссылки) использовать. Или сложить все в статическую переменную.

Но при этом ты будешь терять память, но все будет работать. Ссылочная целостность все же гарантирована.

А отдельные кучи, как раз и позволили бы контролировать такие вещи как подвисшие ссылки и прочие логические ошибки.

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

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

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

Дык это же в компилятор добавили. Ты прочти внимательно эту статью и поймешь, что там речь идет о том, что ты сам можешь расширить компилятор нужным образом. Не ждать милости от природы, а взять ... Короче, ты понял.

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

_>Проблемы классических реализаций GC следующие: stop-the-world и недетерминированное время сборки. И указанные вещи являются проблемой не для быстродействия (грубо говоря числодробилке это не принципиально), а для реалтаймовых и Low Latency задач.

Надуманные это проблемы для 99% случаев применения. Ты сам то хард-реалтайм системы пишешь? Вот поверь, что у меня ни разу не было проблем с латентностью. Вот скорость вычисления хотелось иногда по выше иметь, а с латентностью проблем нет.

Основное время собираются эфемерные поколения. Живых объектов там мало. Сборка проходит за микросекунды. Задержку в миллисекунды ты все равно не заметишь.

В итоге все упирается в алгоритмы. Довольно по фигу ЖЦ у тебя или дестркуторы, если ты пытаешься обсчитать объем данных, который нельзя обсчитать за приемлемое время.

VD>>Ну, а 90% тормозов дотнета связаны даже не с этим, просто с посредственной кодогенерацией и в отсутствие возможностей управлять процессом кодонерерации для всех этих мемори-барьеров.

_>Нет, не верно.

Ты производил исследования? С чего такая уверенность? Ты хотя бы в дизассемблере код смотрел?

_>Если ты перенесёшь .net как он есть на кодогенерацию с помощью LLVM, то вряд ли увидишь какое-то существенное увеличение быстродействия.

Именно, что увидишь. Только надо еще от мебори-барьеров избавиться и прочих по натыканных по коду проверок.

_>Основные тормоза .net связаны с излишней косвенностью (размещение данных не на стеке, ссылочные типы и т.п.)

Ну, вот откуда ты эту ерись берешь? Какой еще косвенности? Чем указатель в плюсах отличается от указателя в ЖЦ-куче?

_>и рантаймовой рефлексией.

Слушай, ну ты такую чушь несешь, что это даже обсуждать несерьезно. Рефлексия не поднимается пока ты ее явно не позавешь. ЖЦ живет за счет знания универсального устройства объектов. Ему рефлексия вообще не нужна.

Сказал бы хотя бы о джите. Но рефлексия? Она тупо отирает память в борке. Но не более того.

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

Ты живешь в мире фантазий. Просто задай себе вопрос. Откуда в твоей голове взялись эти представления? Ты досконально изучал вопрос? Ты сидел в дизасемблере? Ты читал блоги разработчиков ЖЦ?

Вот я все это делал. И у меня нет сомнений, что ты заблуждаешься. Природа тормозов (которые ты тоже скорее всего преувеличиваешь) кроется в следующих факторах:
1. Для поддержки низкой латентности ЖЦ JIT и ngen забивают код кучей перехватчиков (мемори-барьеров) и прочего непроизводительного года.
2. Генератор кода в дотнете далек от идеала. Многие предположения, что делаются в плюсах не делаются в дотнете из соображений безопасности.
3. Для работы ЖЦ стэк должен иметь определенный формат. Опять же оптимизации его могут сломать.
4. Дотнет делает кучу рантайм-проверок. Даже при вызове метода он всегда делает проверку на ноль, чтобы сгенерировать осмысленное, легко отлаживаемое исключение, а не AV. Далее идут проверки выхода за пределы массива. Оптимизации для их делаются только для очень простеньких паттернов перебора.
5. В дотнете сделан овердизайн при обработке массивов. Они допускают ко/контр-вариантность. Это требует новых проверок в рантайме. Есть сопособы обойти это, но мало кто этим заморачивается.
6. Объект в дотнете имеет некоторый оверхэд. В С++ он тоже есть, но дотнетный объект все же по пушистее. В общем-то это копейки, но свою толику вносит.
7. Вот интерфейсы в дотнете действительно добавляют излишнюю косвенность. Но можно их не использовать, да и "тормоза" из-за этого не видно и в микроскоп. Новые процессоры (а где теперь взять старые?) сильно сглаживают этот недостаток за счет умного предсказания переходов
8. Была проблема с делегатами, но ее устранили. Сейчас лямбды делегаты быстрее интерфейсов.
9. ФП в Шарпе (и Немерле) приводит к созданию объектов в куче. Это можно было бы оптимизировать для множества случаев, но это не сделано.
10. Компилятор (JIT) халтурно относится к выравниванию. Иногда перестановка операторов местами дает двукратное изменение времени выполнения.
11. Дженерики в дотнете объектны. Это иногда (хотя далеко и не всегда) приводит к оверхэду. Есть мутные косяки с дженериками в статических типах. Особенно серьезные косяки с дженерик-интерфейсами. Тут есть ряд случаев, которые просто таки втыкают. В Немерле их, кстати, меньше, так как он использует сбоственные функциональные объекты и умудрился не повторить кое какие косяки Шарпа.
12. Дотнет часто манипулирует данными в хипе, хотя их можно было бы разместить в стеке. Тут бы помог эскейп-анализ и прочие оптимизации, но МС умудрился их не сделать за 15 лет.

Как видишь это совсем не то, что ты себе представлял.

_>Кстати, в .net native рефлексия считай убита.

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

_>И есть разговоры об инструментах размещения любых данных на стеке.

Рассуждения есть, а размещения скорее всего нет.

Для этого нужен анализ. Он осложняется тем, что данные запаковываются в объекты и т.п.

По жизни у Нэйтива менее навороченный ЖЦ. Это создает проблемы с теми самыми паузами (хотя опять же не критично), но уменьшает объем поддерживающего кода.

И если ты думаешь, что нэйтив уж так сильно быстрее, то ты ошибаться. Там дашь на дашь.

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

_>Вот если к такому решению приделать нормальный кодогенератор (что кстати в MS и собираются сделать, взяв свой бэкенд от C++), то уже можно получить более менее приемлемое быстродействие. Только это уже будет решение имеющее мало общего с современным большим .net'ом. )))

Команда С++ уже писала кодогенератор для дотнета. Получилось не очень. Там нужны оптимизации другого рода. А на них МС боится замахнуться. Это большой объем работ. При этом чем занимается команда ЦЛР-а — не ясно. 15 жуют сопли.

_>Вообще то как раз то, что ты описал — это и есть ручное управление.

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

_>В гораздо большей степени, чем в C++.

Как ты умудряешься делать такие выводы?

Вот писал я на плюсах. Для ускорения кода вместо обычного хипа использовал пул. Потом грохал пул залпом. Единственная проблема, которая при этом возникала — это то, что грохнув пул я не был на 100% уверен, что где-то не остался указатель в этот пул, который потом может грохнуть всю программу. А тут у меня тоже самое, но с полным котролем. Ни один указатель не подвиснет. Я могу или выявить такие указатели и сгенерировать исключение, или просто пометить их нулом.

В чем тут сложность?

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

можно получить более менее приемлемое быстродействие. Только это уже будет решение имеющее мало общего с современным большим .net'ом. )))

VD>Команда С++ уже писала кодогенератор для дотнета. Получилось не очень. Там нужны оптимизации другого рода. А на них МС боится замахнуться. Это большой объем работ. При этом чем занимается команда ЦЛР-а — не ясно. 15 жуют сопли.

Сейчас 2 Силара второй Core c .Net Native

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

DE>И тем не менее, их продолжают широко использовать.
DE>Если что, я не агитирую за динамику.
Миллионы мух не могут заблуждаться.

DE>Написание сравнительно эффективного параллельного кода без утечек и расстрелов памяти после прочтения коротенького мануала.
Ну это просто не правда. Ничто не мешает там накосячить с многопоточностью.

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


_>Кстати, в .net native рефлексия считай убита. И есть разговоры об инструментах размещения любых данных на стеке. Вот если к такому решению приделать нормальный кодогенератор (что кстати в MS и собираются сделать, взяв свой бэкенд от C++), то уже можно получить более менее приемлемое быстродействие. Только это уже будет решение имеющее мало общего с современным большим .net'ом. )))
Ну рефлексия не убита, а ограничена возможными типами. Нечего огульно ресурсы расходовать.

Большому .Net в большинстве задач и не нужно быстродействие. Нужны удобство и гибкость.
На самом деле .Net это компромисс между скоростью выполнения и удобством и скоростью написания кода.
Заметь C++ тоже совмещают скорость и динамику в виде Питона.

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

Но в Net Native там даже не скорость нужна, а энергосбережение для мобильных устройств и обфускация для десктопного кода

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

DE>>Ну а если серьёзно, то (практически?) в любом масштабном проекте найдутся участки как более сложные, так и более простые и рутинные. Не думаю, что даже самый чудесный ДСЛ сможет ситуацию принципиально поменять: кто-то будет писать и поддерживать ДСЛ, кто-то использовать. Собственно, Go можно считать таким специфическим языком (пусть и "общего назначения") для определённых целей.
WH>И для какой же задачи это образцовое убожество является ДСЛем?

Для любых околосетевых задач, особенно если в команде относительно неопытный народ. Я вот сейчас прям не нарадуюсь просто, что у нас проект на смеси Go (где это возможно) и C++ (где Go использовать невозможно), так как это мне позволит переключиться при необходимости (которая ощутимо намечается) с Go части на C++ часть с достаточно легкой заменой куда как менее опытным программистом. Будь весь проект на C++, такого фокуса провернуть было бы нельзя.

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

VD>Однако С++ все равно только могила исправит. И в принципе замена ему нужна.

Ну не знаю даже... 14 – прекрасен, 17 – вообще конфетка, а 20... надеюсь они сделают то, что обещают, хотя, на данный момент, у меня есть в языке почти всё, что я хочу. Не совсем всё есть в библиотеках – хотелось бы хоть один стандартный, кроссплатформенный пул потоков и какую-то систему CSP, не менее кроссплатформенную и не менее стандартную (ну хотя бы в BOOST).

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

_>> Так вот из нативных (т.е. не требующих отдельной установки специального рантайма и позволяющих эффективно работать с системным API на любой платформе) языков у нас к мейнстриму сейчас относятся наверное всего четыре: C, C++, Go, Swift. Но Swift вычёркиваем сразу, если мы не хотим ограничиться мирком Apple. Из оставшихся: Go — имеет слабую кроссплатформенность и быстродействие, C — неудобный и небезопасный язык. И оба они отстают от C++ по набору библиотек и возможностям языка. Так что выбор как бы очевиден.
DE>Ты же понимаешь, что вводишь ряд дополнительных ограничений? "Необходимость установки специального рантайма" далеко не всем мешает. Если что, пишу я именно на С++ и совсем от этого не страдаю, но прекрасно понимаю почему могут выбирать C#, джаву и т.д.

Ну ключевое тут как раз про системное API. ) На всяческие JNI и P/Invoke без слёз не взглянешь. Не говоря уже о том, что даже запустив это, непонятно что делать с частью данных (т.к. системное API обычно основано на указателях).

DE>"Вменяемые команды" — это, опять же, упор на эмоции.

Это скорее не эмоции, а взгляд со стороны бизнеса, а не программиста (который всегда рад попробовать новые интересные игрушки, пусть даже и маргинальные).

DE>Опять же, не имеет смысла сравнивать в глобальном плане Go и С++ — вполне себе найдутся задачи, где первый подойдёт и нужные библиотеки будут в наличии.
DE>Ну и Swift работает даже на виндовс. Не то чтобы призываю использовать и понятное дело, что есть нюансы, но это совсем не категоричное "ограничиться мирком Apple".

Ну так все четыре языка в мэйнстриме, так что понятно что находятся орды работающих на них. ))) Тут я уже высказал свою оценку, почему из этих четырёх я выбираю C++.

_>>Не надо там ничего отключать. Достаточно его просто не использовать и всё.
DE>Это никак не отменяет сказанного мной. "Не использование GC ведёт к невозможности использовать многое из стандартной библиотеки". Стало лучше?
DE>И "просто не использовать" не получится — это не какой-нибудь shared_ptr, который надо использовать явно. Приходится именно идти на дополнительные ухищрения, скажем, выделять память не через new и т.д.

Я говорю скорее о возможности написать "scope c=new C();", а так же указать "@nogc" у любого своего потока. )

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