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

EP>Ты так говоришь, как-будто проблемы утечек не существует для языков с GC.
EP>Да и вообще, для критичных проектов нужен fault-tolerance в той или степени, и не важно на чём написаны
Fault tolerance начинается с fault detection. И управляемые среды в этом смысле дают хорошие гарантии. А С++ — это лотерея.
Ещё раз подчеркну: проблема не в том, что можно написать программу с ошибкой. Проблема — в том, что эта ошибка останется незамеченной, а к моменту, когда она будет обнаружена, у неё будут последствия неизвестной разрушительности.

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

S>По прежнему не вижу определения понятия "пустой объект".

он имеет в виду объект, *из* которого мувнули.

You will always get what you always got
  If you always do  what you always did

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

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

но тема кода пишется ручками и МП при этом не сильно помогает.

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



_>>А вот на Nemerle уже вполне можно. Только вот где оно готовое?


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

Эдак любой язык с фигурными скобками будет "немерл без ххх"

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

_>>Это не разговор. Нужна целевая ниша.

VD>Не нужна. Достаточно знать ограничения платформы.

Что бы достичь цель, скажем, N процентов от целевой аудитории нужно учитывать особенности эти ниши и аудитории.

Вот тот же JS — язык распространился даже вопреки Микрософту, который боролся с ним в то самое время, когда у IE было 90% аудитории.
Фич около нуля, циклы и те не смогли внятно сделать. Дыр столько, что десяток сайтов навроде wtf.js не могут все это описать. Любые приседания требуют нативных решений.
Однако все сложилось очень даже хорошо — JS распространился и под него запилили столько всяких разных API, что сейчас он практически эталон продуктивности.

Здравствуйте, jazzer, Вы писали:
J>он имеет в виду объект, *из* которого мувнули.
Прекрасно. Что происходит с объектом, из которого мувнули? Он становится пустым. А что такое "пустой объект"? Это объект, из которого мувнули.
Вы Лема недавно перечитывали, да?
Вот, например, в дотнете есть понятие "дефолтной инициализации" — это когда все поля объекта заполняются нулями.
Т.е. все ссылки показывают в null, все целочисленные поля и перечисления содержат 0, вся плавающая запятая — 0.0.
Составные типы — рекурсивно. Именно так гарантированно инициализируется объект в начале жизенного цикла — хоть на стеке, хоть в куче.
Несмотря на это, кстати, сишарп всё ещё требует указывать инициализацию руками — см. тж. definite assignment.
В сишарпе есть даже специальное ключевое слово default, чтобы подчеркнуть, что дополнительной инициализации объекту не требуется.

В С++ я сходу не нашёл понятия "пустой объект".

В справочнике, что характерно, про "пустой объект" ничего нету.
Зато есть сносящая мне крышу штука про то, что аргументом мув-конструктора является rvalue.
Как же так? То есть, если я сделаю так: auto a = std::move(1); то единица превратится в "пустой объект типа int", что бы это ни значило?

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

S>Здравствуйте, jazzer, Вы писали:
J>>он имеет в виду объект, *из* которого мувнули.
S>Прекрасно. Что происходит с объектом, из которого мувнули? Он становится пустым. А что такое "пустой объект"? Это объект, из которого мувнули.
S>Вы Лема недавно перечитывали, да?
Да нет никакого "пустого объекта", он просто некорректно выразился, а ты докопался. Есть понятие "moved-from state".
Так что объект, из которого мувнули, переходит в состояние moved-from. Каким оно будет? Таким, как ты напишешь перемещающее присваивание/конструирование.

S>Вот, например, в дотнете есть понятие "дефолтной инициализации" — это когда все поля объекта заполняются нулями.
S>Т.е. все ссылки показывают в null, все целочисленные поля и перечисления содержат 0, вся плавающая запятая — 0.0.
S>Составные типы — рекурсивно. Именно так гарантированно инициализируется объект в начале жизенного цикла — хоть на стеке, хоть в куче.
S>Несмотря на это, кстати, сишарп всё ещё требует указывать инициализацию руками — см. тж. definite assignment.
S>В сишарпе есть даже специальное ключевое слово default, чтобы подчеркнуть, что дополнительной инициализации объекту не требуется.

В С++ тоже есть понятия default/value/zero initialization, только тут это рояли не играет.

S>В С++ я сходу не нашёл понятия "пустой объект".
Потому что его нету. Это была кривая формулировка alex_public (или не кривая, а чтоб не грузить дотнетчиков плюсовой терминологией).

S>В справочнике, что характерно, про "пустой объект" ничего нету.
S>Зато есть сносящая мне крышу штука про то, что аргументом мув-конструктора является rvalue.
S>Как же так? То есть, если я сделаю так: auto a = std::move(1); то единица превратится в "пустой объект типа int", что бы это ни значило?

Ни во что она не превратится. Перемещение для фундаментальных типов — это копирование.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:
J>Да нет никакого "пустого объекта", он просто некорректно выразился, а ты докопался. Есть понятие "moved-from state".
А, ок.
J>Так что объект, из которого мувнули, переходит в состояние moved-from. Каким оно будет? Таким, как ты напишешь перемещающее присваивание/конструирование.
Вопрос-то в том, как его нужно писать. Например, в дотнете хеш-код любого объекта — это, по определению, результат вызова GetHashCode(). Такой, каким его напишешь.
Но есть определённые ожидания — например, GetHashCode() должен возвращать одинаковые результаты для объектов, у которых Equals() возвращает true.
J>Ни во что она не превратится. Перемещение для фундаментальных типов — это копирование.
А для нефундаментальных? Я всю жизнь считал rvalue чем-то таким, куда нельзя ничего присваивать.
Однако, выходит так, что move как раз рассчитывает на то, что можно успешно убить оригинальный объект.
В моей картине мира явно наблюдается пробел.

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

I>>Самые проблемные вещи в перформансе
I>>0. кривые алгоритмы и структуры данных, включая встроеные во фремворк
...
S>Ну так с моей точки зрения, единственный способ борьбы с п.1 — это повышение уровня абстракции

Это слишком очевидно. Здесь был конкретный вопрос "Создание лямбды и её вызов ничтожны по сравнению с асинхронной операцией."
Влад был с этим несогласен, а я привел свой 'хитпарад' что бы показать, на каком месте реально находятся проблемы с лямбдами. 'хитпарад' составлен после нескольких лет профилирования большого проекта, в котором перформанс на первых местах.

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

S>Здравствуйте, jazzer, Вы писали:
J>>Да нет никакого "пустого объекта", он просто некорректно выразился, а ты докопался. Есть понятие "moved-from state".
S>А, ок.
J>>Так что объект, из которого мувнули, переходит в состояние moved-from. Каким оно будет? Таким, как ты напишешь перемещающее присваивание/конструирование.
S>Вопрос-то в том, как его нужно писать. Например, в дотнете хеш-код любого объекта — это, по определению, результат вызова GetHashCode(). Такой, каким его напишешь.
S>Но есть определённые ожидания — например, GetHashCode() должен возвращать одинаковые результаты для объектов, у которых Equals() возвращает true.

Ну, самое главное требование для состояния moved-from — для него должен корректно срабатывать деструктор.
В принципе, можно этим и ограничиться, но обычно требуют еще и чтоб можно было в него присвоить что-нибудь (и тем самым "вернуть" к жизни), потому что тогда move-swap становится тривиальным:

template< typename T >
void swap(T& a, T& b)
{
  T temp(std::move(a)); // a в moved-from state
  a = std::move(b);     // b в moved-from state, а ожил
  b = std::move(temp);  // temp в moved-from state, b ожил
} // temp (moved-from) выходит из области видимости и умирает, срабатывает его деструктор

J>>Ни во что она не превратится. Перемещение для фундаментальных типов — это копирование.
S>А для нефундаментальных? Я всю жизнь считал rvalue чем-то таким, куда нельзя ничего присваивать.
S>Однако, выходит так, что move как раз рассчитывает на то, что можно успешно убить оригинальный объект.
S>В моей картине мира явно наблюдается пробел.

Если у тебя функция возвращает что-то по значению — это rvalue. Но если она вернула неконстантный объект какого-то класса, у него можно звать неконстантные функции, включая operator=:

std::string f() { return "asd"; }
std::cout << (f() = "zxc");

Это было и в С++98.

You will always get what you always got
  If you always do  what you always did

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

S>В моей картине мира явно наблюдается пробел.

Ну ты хоть признаёшь это. ) В отличие от некоторых товарищей, которые так же как и ты давно перешли на .net, но утверждают, что вполне себе знают C++. )

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

I>

Сам такой.

I>Эдак любой язык с фигурными скобками будет "немерл без ххх"

Ему для этого 100500 фич нужно иметь. Вот Шарп или С++ этим похвастаться не могут, например.

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

I>Вот тот же JS — язык распространился даже вопреки Микрософту, который боролся с ним в то самое время, когда у IE было 90% аудитории.

МС был не первым на рынке. И JS стал к тому времени безальтернативным. МС его поддержал, а VBS никто не поддержал. 90% у IE никогда не было. Максимум было 70% и на не очень большом промежутке времени.

С JS многие стонут, но это единственны доступный везде язык в вебе.

I>Фич около нуля, циклы и те не смогли внятно сделать.

Это ты глупость сморозил. Фич у него хватает. Лябмды, замыкания, прототипное ООП, JSON и много чего еще. Хотя продвинутых возможностей вроде паттерн-матчинга не хватает, но их и в С++ с Шарпом нет.

А, вот что реально плохо, так это кривость языка, отсутствие модульности и дизайн не заточенный на компиляцию. Отсюда тормоза, баги, плохая поддержка IDE.

I>Дыр столько, что десяток сайтов навроде wtf.js не могут все это описать.

+1

I>Любые приседания требуют нативных решений.

Что?

I>Однако все сложилось очень даже хорошо — JS распространился и под него запилили столько всяких разных API, что сейчас он практически эталон продуктивности.

Любой язык завоюет рынок, если алтернативы у него не будет. Яву не включили в броузеры. VBS не поддержали производители браузеров.

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

I>>Вот тот же JS — язык распространился даже вопреки Микрософту, который боролся с ним в то самое время, когда у IE было 90% аудитории.

VD>МС был не первым на рынке. И JS стал к тому времени безальтернативным. МС его поддержал, а VBS никто не поддержал.

Значит, ты не в курсе, что Микрософт усиленно хоронила JS, все хотела заменить его vbs ?

>90% у IE никогда не было. Максимум было 70% и на не очень большом промежутке времени.

А ты, в теме.

was the most widely used web browser during its tenure (surpassing Internet Explorer 5.x), attaining a peak in usage share during 2002 and 2003 in the high 80s, and together with other versions up to 95%.

I>>Фич около нуля, циклы и те не смогли внятно сделать.

VD>Это ты глупость сморозил. Фич у него хватает. Лябмды, замыкания, прототипное ООП, JSON и много чего еще.

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

VD>А, вот что реально плохо, так это кривость языка, отсутствие модульности и дизайн не заточенный на компиляцию. Отсюда тормоза, баги, плохая поддержка IDE.

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

I>>Любые приседания требуют нативных решений.

VD>Что?

Вроде по русски написано. Ты внятно скажи, с чем не согласен.

I>>Однако все сложилось очень даже хорошо — JS распространился и под него запилили столько всяких разных API, что сейчас он практически эталон продуктивности.

VD>Любой язык завоюет рынок, если алтернативы у него не будет. Яву не включили в броузеры. VBS не поддержали производители браузеров.

У MS, когда IE занимал 95% рынка, не хватило мощи продавить свой VBS.

Кстати говоря, по фичам VBS был ничем не хуже джаваскрипта того времени.

Более того — VBS был реализован не меньшим количеством контор, нежели JS. Ты ведь про это совершенно не в курсе, правильно ?

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

_>Почему высокомерное отношение то? Если я сам не раз писал, что C# великолепно справляется с задачами в своей нише

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

_>(хотя Java в той же нише пожалуй ещё лучше, по сумме параметров).

Лучше она разве что переносимостью. В остальном сравнимо. В яве лучше джит (ХотСпот). У дотнета лучше возможности по ручной оптимизации (честные дженерики, вэлью-типы, ансэйф).

_>Угу, по аналогичной причине D перестал быть так популярен (не в реальных проектах, где его и не было, а в мечтах о будущем) в последние годы.

Не надо тешить себя сказками и мифами.

Ди не стал популярным. И не стал в те времена когда С++11 еще не было и не ясно будет ли. Причина тут та же что с Немерлом. Отсутствие брэнда с кучей ресурсов (амин, пиар, бабла).

_>Что касается LINQ, то он как раз не прекрасен, а ужасен, если вспомнить о быстродействие. Я это лично замерял несколько лет назад вместе с местными спецами по .net. Так вот там код с linq отставал от C++ аналогов не на традиционные для C# значения, а намного больше. Т.е. дело явно не в недостатках платформы .net, а в реализации самого linq. Ну или если не веришь мне, то вот тебе уже в этой темке коллеги подтвердили. )

Скорость не всегда самое главное. Замыкания и делегаты создаются в хипе, и никаких оптимизаций не делается, так что код с ФВП получается медленнее чем аналогичный императивный. Но обычно его скорости за глаза хватает для большинства применений, а там где не хватает есть императив.

В общем, фича удобная и приемлемая для многих задач.

_>Да, а насчёт лямбд... На C# уже можно написать код аналогичный такому http://coliru.stacked-crooked.com/a/ce0de866fa9e05bc ?

Я не очень понимаю что ты имеешь в виду. Возможность выражения монад или использование дженериков с переменным числом аргументов типов? Если первое, то — да. Если второе, то — нет, так как они не поддерживаются. Вместо этого (как в С++03) придется создать дцать перегрузок.

В немерле для монадных игрушек сделан ComputationExpressions.

Ну, и с переменным число параметров в макросах тоже никаких проблем. Так что твой примерчик переписывается на макрах в разы проще. Я правильно понимаю, что он тупо объединяет кортежи (или что-то на них похожее) в один кортеж?

VD>>Так что можно и производительность улучшить за счет перегрузок, и от использования интерфейсов избавиться.

_>Можно и сделано — это очень разные вещи. )

Главное что есть возможность. В плюсах тоже много чего не сделано. Ты же не расстраиваться от этого?

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

_>Ну если говорить о какой-то "нашлёпке" к C#, то безусловно смысла нет. Если же говорить об отдельном новом языке, то совсем другое дело.

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

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

VD>>Все и так не плохо. Хотя идея не лишина смысла. Можешь заняться. Будет еще один плюс и ещё одна альтернатива. Лично меня более–менее устраивает дотнетный подход и есть куча других задач.

_>Не раньше чем Nemerle оторвётся от .net'a. )

Сдается мне, что всю клиенскую часть вы спокойно могли бы писать на дотнете и Моно (если вам важна поддержка Линукса и Макоси).

_>А есть какой-то общий известный каталог таких библиотек для Nemerle? ) Интересно посмотреть что там уже наделали... )

https://github.com/rsdn/nemerle/tree/master/snippets
Правда класть туда проекты не является обязательным, по этому ряд больших проектов лежит в отдельных репозиториях.

_>С F# не игрался, а с Haskell'ем игрался... )

В Хаскеле работа с монадами встроенная но к ней нельзя свой синаксис. В гибридных языках вроде F# и Немерла работа с модадами получается в виде паттернов. Компьютейшон экспрешены позволяют автоматизировать этот процесс и сделать красивый синтаксис.

_>Т.е. получается, что Nemerle всё же не является надмножеством C# (как например у того же C->C++) и не может компилировать его код?

Нет. Есть много общих моментов, но синтаксис другой и фичи не все воспроизведены. Например, не поддерживаются шарповские варианты и те же асинки. В немерле есть альтернативные решения возникшие за долго до появления аналогичных фич в шарпе. Нет особого смысла воспроизводить все фичи шарпа 1 в 1. Хотя в немерле есть плагин шарпа который съедает 95% кода на шарпе бзе каких либо изменений. Так что в проект на немерле можно споконой подключить C#-файл и описанные в нем типы и функции будут доступны в проекте. Сами этим иногда пользуемся. Например, вот кусок кода взятый из шарповского проекта.

_>Как раз главное преимущество реализации этого в C# в том, что позволяет пользоваться этим довольно не простым (внутри) инструментом даже не понимая, как оно в реальности работает.

В немерле тоже самое. Просто пишешь плоский код и он работает. Только в Шарпе это реализовано на базе конечных автоматов, а в немерле на базе монад и прочего CPS.

_>Для небольшого проекта при таких условиях я бы точно выбрал Питон. )

Динамически типизируемый язык для больших проктов? Гы-гы. Разве что проект состоит из кучи мелких слабо связанных друг-другом скриптов (как в вебе).

_>Специализация тоже о многом говорит. ) К примеру если один дизайнер "специализируется" в Фотошопе, а другой в Paint'е, то... )))

Вот это и есть надменность. По факту же Шарп сложнее плюсов. Для того чтобы писать качественный код на нем нужно так же быть профессионалом. при этом у шаприста профессионала будет куда более высока производительность нежели у профи плюсовика. Да, МП нет. Код, при использовании одинаковых алгоритмов, получится чуть быстрее на плюсах. Потребление памяти в разы больше чем на плюсах. Но проект будет сдан значительно раньше (опять же при равном его качестве).

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

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

Ну, вот и не тешь себя сказками, что те кто выбирают другие языки менее профессиональны и у них там какие-то проблемы с порогом вхождения в унылый С++. Таких проблем нет. Просто есть языки на которых мы в разы эффективнее, так как они спроектированы в разы лучше плюсов. Для МП в них применяются специально предназначенные для этого вещи. Память управляется автоматически. Получить неиниализированные данные невозможно в принципе. Типизация строже. Так что ошибок в коде становится намного меньше. Все это позволяет больше времени уделять алгоритмам и фичам. В итоге вместо примитивного Spirit-а мы имеем офигительные Nemerle.PEG и Ninta.

_>Я не про это. Я про организацию кода. Вот на C++ мы можем смешать любые макросы, шаблоны, обычный код в одном файле. Можем конечно и раскидать по отдельным, но это как ты понимаешь будет исключительно наше разделение, а не формальное правило. С другой стороны, в том же упоминаемом выше T4 ситуация обратная и это как раз формальное требование. Так вот вопрос как у нас этим в Nemerle? )

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

_>Соответственно если в Nemerle ситуация с макросами как и в C++, то я не вижу особого смысла в каком-то выделение Nemerle библиотек, содержащих макросы. Ну разве что как раз в том смысле, что их нельзя использовать из других языков... )

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

В общем, плюсы следующие:
1. Код получается не отличимый по быстродействию от кода компилятора.
2. Есть четкое разделение на мета-код и обычный код.
3. Код можно отлаживать штатными средствами (отладчиком).
4. Можно генерировать исходники для отладки порождаемого кода.

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

_>Не, речь о других вещах. Например различные техники работы с Tuple. В C++ то это всё во время компиляции отрабатывает.

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

_>Так что тут именно тонкий вопрос. Я например могу сказать что ничего подобного в C# нет вообще и буду абсолютно прав.

Вообще-то кортежи есть в стандартной библиотеки дотнета. Но работать с ними так же не удобно как и на С++, так как для удобной работы с ними нужен паттерн-матчинг.

_>С другой стороны ты можешь сказать что tuple в C# имеется (только работает во время исполнения, что вообще скучно) и к нему даже не нужные какие-то специльные инструменты. И тоже будешь в какой-то степени прав. )))

Буду.

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

_>А там всё тоже самое, но по другому. ) Я хочу сказать, что там реализована в общем то обычная функциональность стандартной библиотеки языка, но с изначальной заточкой на использование МП, вычисления во время компиляции и т.п. Итог получился очень приятный.

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

_>А вот в D вполне используют. )

Там где ни хрена нет, там и используют.

_>Хотя от МП там всего лишь "static if" и нужен. )

Гы-гы.

_>А ты статью, на которую я кидал тебе ссылку, посмотрел? ) Ну там где про мобильную разработку и ужасы сборщика мусора в ней...

Статья твоя о JS. Все что там сказано о GC — это, что что для его хорошей работы нужно много памяти, которой на старых айфонах нет.

Там же сказано, что на десктопах системы с GC работают так же как нативные или даже быстрее. Ты сам то статью внимательно читал?

_>Про разные мелкие косяки в дискуссии со мной (типа как с Sign# и т.п.) умолчим.

Не надо умалчивать. Если у тебя есть что возразить, приведи доказательства. Я знаю о чем говорю.

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

У меня к этим людям нет особого доверия. Они имеют однобокий опыт в отличии от меня и тех людей мнению которых я доверяю.

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

Давай ты мне ссылок дашь подтверждающих эти домыслы обо мне. Выводы я делаю исключительно на опыте разработки софта и фактах. Все наши приложения работали достаточно быстро и на C, и на C++, и на C# и на Nemerle. Если это было не так, мы брали в руки профайлер и добивались необходимой производительности.

Я не догматик, и если это нужно могу перейти и на небезопасный режим, и на С/С++. Но пока производительности хватает или ее можно улучшить алгоритмически, я это делать не буду. И, о ужас, за последние 10 лет я почти всегда обходился алгоритмическими улучшениями. Так что потребность не очень велика.

И не надо мне пытаться внушить, что у меня задачи какие-то не требовательные. Почти все мои задачи были требовательны к производительности. Даже код пакета подготовки статей для РСДН будучи переписан с С++-ных регекспов и вордовских сктиптов стал в 100 раз быстрее будучи переписаым на немерле. Но не из-за того, что немерл какой-то супер быстрый, а потому, что вместо того чтобы вынимать данные из вордовский файлов через атомйшон, я тупо распарсил его ХМЛ-ник и вынул все нужные данные. Получилось гибче и в сто раз быстрее.

_>Не только, но что можно на скриптах (в каком-то смысле). Дотнету в любом случае тут делать нечего. )

А чего же нечего то? Уверен, что на плюсах вы пишете куда больше чем нужно. Да и у скриптов преимуществ нет.

_>Ммм, там не примитивно, просто как раз там сидят самые нагруженные по быстродействию вещи (те самые "кодеки", вывод на экран и т.п.).

Вывод на экран ни разу не проблема для дотнета. Даже, при использовании WPF, может и по круче получиться. Ну, а "кодеки", если там реально нужны разные SIMD-инструкции и т.п., конечно лучше на плюсах или видеокарте реализовывать. Это то где их ниша пока что свободна.

_>Ну т.е. понятно, что у окружающих "кнопок" никакой нагрузки нет, но это уже совсем извращением будет написать остальной gui на каком-то другом языке и потом как-то интегрировать его с окнами от C++ в единое целое.

А зачем нужны окна от С++? Кодек — это по сути тупая функция. А писать нужно на том, что сокращает твое время и улучшает результат. WPF на винде — это то что доктор прописал для подобных задач. Глядишь и кодеки не придется писать, так как там много всего из коробки поддерживается.

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

Хреновенький и простенький — возможно. Но с WPF-ом его вряд ли можно сравнить. Плюс пишете вы уже все равно не на С++, а на каком-то другом языке. То что с него генерируется уже рояли не играет.

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

I>Значит, ты не в курсе, что Микрософт усиленно хоронила JS, все хотела заменить его vbs ?

Не. Не в курсе... Потому что этого не было. Я в те времена как раз все это видел сам. МС поддерживал и VBS, и JS. Их JS малость отличался (так как бы на их сктиптовом рантайме сделан), но это был именно JS. VBS они предлагали лишь как альтернативу. Заменой они его не делали ни разу.

I>А ты, в теме.
I>

I> was the most widely used web browser during its tenure (surpassing Internet Explorer 5.x), attaining a peak in usage share during 2002 and 2003 in the high 80s, and together with other versions up to 95%.

Думаю, что это некорректные вычисления. Как раз в это время мы мониторили броузеры на РСДН и никаких 90% не был и в помине. В прочем, возможно это специфика ресурса.

Не важно. Важно, что JS уже был в Нетскейпе и на всех парах тащился в стандарт. А VBS был частной игрушкой МС.

I>JSON, к слову, не везде доступен, прикинь ?

JSON — это сабсет JS описывающий JS-объекты. Он не может быть где-то не доступен, так как это просто часть JS.

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

Весь JS тормозной. Но на безрыбье и раком рыбу. И к отсутствию фич это отношения не имеет. Шарп в те времена замыканий и лямбд не имел, в отличии от.

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

Конечно! Альтернативы то нет.

I>>>Любые приседания требуют нативных решений.

VD>>Что?

I>Вроде по русски написано. Ты внятно скажи, с чем не согласен.

Я не понял о чем речь. Какие на фиг нативные решения в броузерах? Что за приседания?

I>У MS, когда IE занимал 95% рынка, не хватило мощи продавить свой VBS.

Какой смысл одно и тоже повторять? Даже если у них когда-то было 95%, то они давно и безвозвратно кончились. А не долгое лидерсво не дало им ничего. JS был и в Нетскейпе (он там первым появился), и в ИЕ. А VBS только в ИЕ. На практике он так никогда и не использовался. То что было названо "dynamic HTML" раскрутилось уже когда МС начал сдавать свои позиции. Хотя я лично еще VBS использьовал в те времена, так как знал васик лучше чем JS.

I>Кстати говоря, по фичам VBS был ничем не хуже джаваскрипта того времени.

Кое чем он отставал. Например, регексы были не встроенными в язык, а во внешенй библиотеке, но не мудренно, что языки были похоже, они же были реаливаны на одном и том же движке WSH. Причем в JS его уши торчали неприкрыто. Внешние объекты были АктивХ-ами и создавались через специальную функцию. Это было не совместимо с Нетскейпом. Так что даже JS у МС был не стандартный и людям приходилось писать обертки. А тогда никаких джейквери еще не было.

I>Более того — VBS был реализован не меньшим количеством контор, нежели JS. Ты ведь про это совершенно не в курсе, правильно ?

VBS был реализован только МС. Это их игрушка. Не придумывай. И ни один браузер кроме ИЕ не поддерживал его.

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

EP>>С чего это вдруг O(N)?
EP>>Вот например swap двух строк, это какая сложность по-твоему?
S>В зависимости от того, попали ли мы в SSO — либо о(N),

Имелось в виду O(N)? Если да, то N — это что? Константное и малое значение?

S>либо o(1) + затраты на перещёлкивание ref_count.

При move перещёлкивание ref_count не нужно.

S>Или у нас есть какая-то магия компилятора, которая отличает swap от s3=s1; s1=s2; s2=s3 для произвольных типов?

О чём речь? Под swap, разумеется, имеется в виду не дефолтная реализация, а специальная версия для строк.

S>И благодаря чему здесь компилятор ухитрится соптимизировать move? Вот у меня банальный код вызова:
S>

S>void test()
S>{
S>  string s("test"); // байты для 't','e','s','t','\0' хранятся в stack frame этой функции благодаря SSO
S>  s = f(true);
S>  cout << s; // здесь в SSO-области s уже лежат байты 'f','i','r','s','t','\0'. Каким образом они тут оказались?
S>}
S>

Для SSO (когда строка не превышает threshold), или например std::array<int, N> — move действительно ничем не помогает. Но SSO ведь SSO — то есть там малая константа, что-то вроде нескольких слов. Тебя копия нескольких машинных слов смущает?

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

I>>Значит, ты не в курсе, что Микрософт усиленно хоронила JS, все хотела заменить его vbs ?

VD>Не. Не в курсе... Потому что этого не было. Я в те времена как раз все это видел сам. МС поддерживал и VBS, и JS. Их JS малость отличался (так как бы на их сктиптовом рантайме сделан), но это был именно JS. VBS они предлагали лишь как альтернативу. Заменой они его не делали ни разу.

Ты просто не в курсе. Микрософт рассматривала именно VBS как основной язык, и из IE в планах было выбросить JS.

I>>

I>> was the most widely used web browser during its tenure (surpassing Internet Explorer 5.x), attaining a peak in usage share during 2002 and 2003 in the high 80s, and together with other versions up to 95%.

VD>Думаю, что это некорректные вычисления. Как раз в это время мы мониторили броузеры на РСДН и никаких 90% не был и в помине. В прочем, возможно это специфика ресурса.

Надо понимать пример корректности это экстраполяция рунета на весь инет ?

I>>JSON, к слову, не везде доступен, прикинь ?

VD>JSON — это сабсет JS описывающий JS-объекты. Он не может быть где-то не доступен, так как это просто часть JS.

Ты бы посмотрел, как этот JSON поддерживается. Ключевой функции для него может и не быть в движке, представь себе весь ужас. Скажем, всего месяц назад я писал плагин кое для чего именно на таком движке. В силу проблем с безопасностью eval, JSON.xxx тупо недоступны.

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

VD>Весь JS тормозной. Но на безрыбье и раком рыбу. И к отсутствию фич это отношения не имеет. Шарп в те времена замыканий и лямбд не имел, в отличии от.

Это усугубляет отсутствие фич. Ты наверное забыл, но JS существенно ускорился совсем недавно. До того там даже простейшие вычисления безбожно тормозили. И ничего — все равно проник, даже с тормозами.

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

VD>Конечно! Альтернативы то нет.

По твоему на сервере нет альтернанивы ? Смотри выделеное. Тебе только браузер мерещится, а JS уже давно работает вне браузера.

VD>>>Что?

I>>Вроде по русски написано. Ты внятно скажи, с чем не согласен.

VD>Я не понял о чем речь. Какие на фиг нативные решения в броузерах? Что за приседания?

В браузере вообще всё нативное. Не знал ?

VD>Какой смысл одно и тоже повторять? Даже если у них когда-то было 95%, то они давно и безвозвратно кончились. А не долгое лидерсво не дало им ничего.

Важно, что они хотели выбросить JS из браузера.

I>>Кстати говоря, по фичам VBS был ничем не хуже джаваскрипта того времени.

VD>Кое чем он отставал.

Принципиально ни в чем не отставал.

I>>Более того — VBS был реализован не меньшим количеством контор, нежели JS. Ты ведь про это совершенно не в курсе, правильно ?

VD>VBS был реализован только МС. Это их игрушка. Не придумывай. И ни один браузер кроме ИЕ не поддерживал его.

Придумываешь пока что ты сам. Я, к слову, сказал про языки, а не про браузеры. Вот, скажем, Sax Basic — тот же язык, только от другого производителя. Таких решений было пруд пруди. Все сдохли, что характерно.

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

EP>>Во-вторых, совершенно без разницы. Я показываю, что EA тут не даёт никакой type safety. Эта type safety в управляемых языках есть и без EA, а в C++ возможна без EA.
S>Я понимаю, что вы показываете. Я вам пытаюсь объяснить, что подход управляемых языков — "давайте начнём с корректной программы (т.е. с type safety), а затем сделаем её быстрой (например, снизим нагрузку на GC путём EA)".

По факту же, когда нужно "сделать быстрой", нагрузку с GC снимают off-heap'ом или подобными костылями. То есть escape в прямом смысле, от слов "рвём когти"
Причём со всеми атрибутами вида "объект под указателем(индексом) уничтожен, и запись по указателю портит новый объект"

S>А в С++ подход "давайте начнём с быстрой программы (т.е. дадим пользователю самому управлять временем жизни объектов), а потом безуспешно будем пытаться сделать её корректной".

Почему безуспешно то? Это какой-то уж совсем жёсткий bias, настолько жёсткий — что даже совсем не интересно

Вообще, это уже пошли попытки натянуть совуEA на глобусtype safety, вместо того чтобы просто признать, что изначальный тезис на поверку оказался неверен:

S>О, ещё немного — и вы изобретёте escape analysis.

EP>>Ты говоришь про общий случай. Для общего случая в C++ возможен только conservative GC, что уже обсуждалось выше по топику.
S>Ну, вот и договорились.

С этим никто и не спорил.

S>>>Разговор о том, что у вас нет никакой гарантии, что "GC использован только для части приложения", из-за потенциальной возможности прикопать указатель где угодно.
EP>>Теоретически.
EP>>А практически, для таких сценариев и при необходимости гарантий (например при невозможности достижения их одними guidelines) — можно запретить брать raw указатели на такие GC объекты — частично языком + простейшим внешним верификатором.
S>У нас с вами противоположные понятия о "теоретически vs практически". Я считаю, что ваша идея про необходимость гарантий — это чистая теория, не подтверждённая на практике. А практика — это наличие а) компиляторов, которые неспособны запрещать брать указатели на особые объекты, в том числе и непреднамеренно,

К Clang'у легко делаются plugin'ом, которые pattern match'ат куски AST. Реализовать PM по использованию конструкций std::addressof и т.п. на gc_ptr<T> — там относительно просто.
А отсутствие готового или малая известность — скорей всего от низкой востребованности

S>б) библиотек, которые несовместимы с такими ограниченными объектами, и с) наработанной прикладной кодовой базы на основе компиляторов и библиотек, которую никто не возьмётся переписывать в светлое будущее ради того, чтобы получить хоть какие-то гарантии в одном крошечном кусочке нашего проекта с 15-летней историей.

То есть проект 15 лет работал себе, без необходимости гарантий, а тут вдруг понадобились?
В любом случае, precise GC — это не единственный способ получить их. Например достаточно упомянутых выше region'ов

EP>>>>По-хорошему, нужно и минимизировать баги, и их последствия. В разных приложениях естественно нужен разный баланс.
S>>>Совершенно верно. Юмор в том, что С++ не позволяет ни того, ни другого.
EP>>А кто тогда позволяет? ObjectDisposed и OutOfBounds?
S>Конечно.

И как они помогают минимизировать баги?

WH>В случае C# пользователь иногда будет получать сообщение: "Извыни дарагой. Нешмагла. У програмыст рука кривой. В него ужа патинка полетел."

И кстати, на счёт ObjectDisposed — с помощью ref-counted подобная ситуация

Автор: Evgeny.Panasyuk
Дата: 08.10.14

разгуливается элементарно. Как бы сделать это на C#?

EP>>Так это реальный C++, удовлетворяющий стандарту, а не аналог
S>Покажите мне этот "реальный C++". Увы — он существует только в вашем воображении.

Смотри valgrind и sanitizer'ы.

EP>>shared state — это ref counted объект, грубо говоря std::shared_ptr<bool>. На него ссылаются и сам объект и все указатели.
EP>>При разрушения объекта, он всего лишь записывает в этот флаг false.
S>Да, так будет работать. Интересно, отчего эта техника не применяется в управляемых средах?

От того что там применяется другая техника, с другими характеристиками: "продление жизни объекта до тех пор пока на него есть последняя ссылка", а не "даём возможность узнать при доступе по ссылке — мёртв он или нет".

Точнее для IDisposable — там как раз что-то подобное и применяется. Только считай что shared sate встроен в объект, со всеми вытекающими. Например объект уже Disposed, а память занимаемая им всё ещё держится, так как есть ссылки
Для C++, кстати, тоже можно так сделать, необязательно отдельный shared state — но так будет излишний перерасход памяти

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

J>>Так что объект, из которого мувнули, переходит в состояние moved-from. Каким оно будет? Таким, как ты напишешь перемещающее присваивание/конструирование.
S>Вопрос-то в том, как его нужно писать. Например, в дотнете хеш-код любого объекта — это, по определению, результат вызова GetHashCode(). Такой, каким его напишешь.
S>Но есть определённые ожидания — например, GetHashCode() должен возвращать одинаковые результаты для объектов, у которых Equals() возвращает true.

Стандартная библиотека описывает эти требования: MoveConstructible, MoveAssignable. И в тех местах где они требуются — указывается явно, например в std::rotate.
http://en.cppreference.com/w/cpp/concept/MoveConstructible
http://en.cppreference.com/w/cpp/concept/MoveAssignable

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

EP>Сглаживание последствий багов, никак не отменяет того что это баг.

Зато позволяет не потерять все незаписанные данные от того, что в реализации фичи вызываемой по кнопке закрался баг.

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


EP>Да, для некоторых классов багов, языки с GC и выключенным unsafe — дают определённые гарантии, которых нет в C++ без внешних тулз

WH>>Знаешь, как в яндексе борются с утечками памяти и проездами по памяти?
WH>>Рестартом демона по таймеру. Ну, или по факту выпадения в кору.

EP>Да и вообще, для критичных проектов нужен fault-tolerance в той или степени, и не важно на чём написаны

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

EP>Баги есть везде. И да, C++ на некоторые классы багов отвечает очень жёстко, самым низкоуровневым образом. Но это же очевидно, и с этим никто не спорил.

Типобозопасные языки существуют уже более 50 лет.