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

Х>язык C++ в своей молодости тоже бурно развивался, почитай D&E, только вот когда количество программистов на нём выросло до миллионов, количество платформ и компиляторов до десятков, то тут уже начинает главенствовать принцип "не навреди". C#, дай бог ему здоровья, если обретёт такой же ареал то будет развиваться тоже не шустро, уж поверь.

Не возьмусь оценить точные проценты применения, но почему-то мне кажется, что C#, а уж тем более Ява применяется гораздо чаще на сегодняшний день. И объясняется это тем, что он применяется для автоматизации предприятий и создания сайтов в интернет. В этих областях есть много нюансов и написать единый коробочный софт для них в принципе невозможно. А это ниша для огромных стад разработчиков. С++ же используется в последнее время больше частью для создания высокотиражных продуктов где стоимость разработки не так важна, так как окупается количеством продаж (т.е. — игры, ОС, офисные приложения), а меньшее потребление компьютерных ресурсов может увеличить объем продаж.

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

VD>>>2. Без GC толку от этого будет не много.
ГВ>>ИМХО, ты ошибаешься.
VD>Да? Объясни тогда оду простую вещь. Для эффективного использования замыканий сами замыкания и все на что они замкнуты (т.е. имеют ссылки) должно жить столько сколько живет само замыкание. А замыкание может быть передано в ФВП которая так же может передать его в другие ФВП. Как не имея системы автоматического управления памятью реализовать безопасные (не приводящие к UB ошибкам времени выполения) замыкания?

Замыкать можно ещё и значения. Значения указателей — в том числе и т.д., и т.п.

VD>>>Ошибаешься! Такие как ollv по незнанию или из фанатических побуждений применяют С++ там где ему совсем не место и в условиях где он противопоказан.
ГВ>>Это слишком сильное утверждение, насчёт незнания и фанатизма. Так что, тут я согласиться не могу.
VD>Что в нем сильного? Оно не противоречит утверждению, что есть люди использующие С++ осознанно и для задач где он является конкурентно-способным.

Вот это: "Такие как ollv". Если бы ты сказал "некоторые", я бы согласился. А так ты едва ли не прямо сомневаешься в квалификации ollv, что порицается правилами форума.

ГВ>>Не надо переворачивать с ног на голову. Сайты бывают разные, и требования — тоже разные.
VD>Ага. Не надо. Не надо разглагольствовать о разных задах сайтов. С++ там по любому не место. Если только в виде какого-то там драйвера или мелкого компонента вроде ISAPI-фильтра.

Место ему там или нет — оставь решение этой задачи самим разработчикам сайтов. Полагаю, что их квалификации вполне достаточно для такого выбора. Ты скажи, ты сам много сайтов на C++ написал, а потом переписал их на что-то ещё, чтобы уверенно утверждать, что C++ не даёт никаких преимуществ?

ГВ>>MS и IBM (как и все остальные) вольны поступать так, как им заблагорассудится.
VD>Ага. И выбирают для сайтов Яву и дотнет.

И что с того? Выбрали и выбрали. Как это должно сказываться на выборе, который делают совсем другие люди?

ГВ>> И кроме всего прочего, слишком мало критериев для отсечения C++: "в кратчайшие строки получить надежное решение, когда денег на разработку нехватает". Он запросто может оказаться наилучшим выбором с учётом других факторов.
VD>Ага. Но другим фактором может быть только крайняя нужда в достижении высокой вычислительной производительности путем ручной оптимизации.

Отнюдь. Решающим фактором может оказаться всё, что угодно, вплоть до наличия под рукой подходящих библиотек и доступности программистов. А ещё фактором может оказаться, например, необходимость тащить .Net FW.

ГВ>> Тут проблема в другом: почему-то те, кто ругают C++ приписывают ему какую-то имманентную глюкавость, запредельную трудоёмкость и т.п. чуть ли не по всем аспектам, тогда как на самом деле это а) не так и б) зачастую обусловлено тем же контекстом, т.е. постановкой задачи, анализом требований и т.п.
VD>Глюкавость приписывают не языку, а коду на нем написанном. И не почему-то, а исходя из общирного опыта и объективных логических рассуждений. Язык не типобезопасен, возлагает на программиста массу ответственности.

Э... Не так. C++ допускает опасные операции. Но вовсе не требует. А ответственность везде в цене, это от языка не зависит.

VD>Есть такое умное высказывание (не помню чье) — человек не должен делать работу которую может сделать машина. А С++ заставляет человека делать работу которую можно возложить на машину.

Не так. C++ позволяет человеку влезть в то, чем обычно занимается машина.

VD>Все остальное последсвия. Ну, и С++ как раз очень сильно сковывает программиста в выборе абстракции. По сути, большинство С++-программистов, начинают решать все задачи с помощью шаблонов.

Опять двадцать пять.

1. Ограничения на выбор допустимых абстракции есть у любого языка программирования. Так уж они, засранцы, устроены.
2. Шаблоны широко используются в программировании на C++. Не понятно, ты считаешь это негативной чертой? Или — ограничителем в выборе абстракции?

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

Нередко производительность является составляющей интегральной характеристики "качественно".

VD>Многие защитники С++ приводят в качестве примера 3D-игры. Мол, "почему их пишут на С++?". А стоило бы посмотреть на другой аспект. Почти все эти игры безбожно глючат. Играть в некоторые до выхода патчей просто невозможно. Большая часть ошибок в этих играх могла бы быть попросту не допущена, будь программа написана на более качественном языке.

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

ГВ>>AFAIK, на данный момент Lisp примерно на 5-20% проигрывает C++, пробегало где-то на www.franz.com.
VD>Твой AFAIK. Высосан из пальцев. В прочем я не Лиспер и дать тебе точных данных не могу. Но я проверял их данные и скорее соглашусь с ними, а не с тобой. Кстати, проигрышь в 20% это вообще смешно. Отдельные компиляторы С++ проигрывают друг-другу в разны на разных задачах.

Не понял. Чьи данные ты проверял?

ГВ>>Да нет, она эмоциональная по сугубо формальным признакам. find_if и Co вполне решают свои задачи в рамках STL/C++. Понятно, что это не filter/fold, но тем не менее.
VD>Офтоп — Люблю русский "да нет".
VD>Если понятно, то лучше помалкивать про find_if и компанию. И уж точно не заикаться о "применимости к объектам разного класса" или как там?...

О чём не заикаться? Я тебя не понимаю что-то. fold, в общем, до какой-то степени эмулируется accumulate+boost::bind, а у find_if — своё, вполне определённое назначение и она вполне применима к широкому набору типов. Шаблон же, однако.

ГВ>>>>Забавно, что как раз использование "побочных эффектов" и делает C++ столь привлекательным по критерию производительности программиста при сохранении производительности продукта.
VD>>>Забавно, что ты даже не понимаешь о чем идет речь. Речь же идет о побочных эффектах воплощения шаблонов. Эти эффекты позволяют заниматься метапрограммированием во время компиляции. Но как и все, что достигается не предусмотренными для этого средствами, данное решение является очень неудобным и ограниченным.
ГВ>>Удивительно, но именно шаблоны я и имел в виду.
VD>Да? Иди прочти еще раз свои слова. Если ты говорил о шаблонах, то они вообще теряют смысл.

Так... Тогда объясни, что ты считаешь "прямыми", а что "побочными" эффектами шаблонов?

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

Real World, The.

VD>Если знаком (с МП на Lisp и Nemerle — ГВ.), то должен понимать, что это как небо и земля. В случае шаблонов С++ трудоемкость офигительная, сложность высокая, результат так себе и при этом все еще совсем плохо по ресурсам потребляемым компилятором. А в результате метапрограмма деже не может выдать сообщение об ошибке или обратиться к внешнему файлу. Ну, куда это годится?

А зачем метапрограмме на C++ обращаться к внешнму файлу, если эта самая метапрограмма "работать"-то может только во время компиляции? Что до сообщений об ошибках, тут согласен — подчас их весьма сложно анализировать. Ну и различия в МП мне тоже вполне понятны. Только я не согласен с тем, что результат — так себе. Вполне себе нормальный результат.

ГВ>>Да ну?! Вроде как я обычно доказываю прямо противоположное. Мозг как раз нужен и теоретическая подготовка — тоже. Так что, что-то ты перепутал.
VD>Я перепутал? Ну, не знаю. Я тебя читал.

Просто любопытно: из чего ты сделал вывод, что я считаю, что "мозг не нужен" и "главное — трясти"?

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

ГВ>Замыкать можно ещё и значения. Значения указателей — в том числе и т.д., и т.п.

Ты бы лучше не говорил о том в чем не разбираемый. А то такой бред несешь, что просто смешно.
Замыкать значения невозможно. Это просто глупость. Значения на то и значения чтобы копироваться. Суть замыканий как раз в том, чтобы иметь доступ к значениям видимым в лексической области видимости. При этом все переменные и поля которые попали в замыкание должны жить не меньше чем область в которой они объявлены и не меньше чем живет замыкание. Любой указатель должен быть верным до момента когда замыкание перестанет существовать.
Это приводит к тому, что образуется граф взаимно-связанных объектов время жизни которых крайне сложно отследить. При наличии GC следить за и не надо. Если GC нет, то требуется или накладывать ограничения, которые сузят область применения ФП и ухудшат удобство пользования им, или вводить какие-то другие механизмы отслеживания времени жизни связанных объектов. Если исключить GC, я знаю только одну такую — подсчет ссылок.

ГВ>Вот это: "Такие как ollv". Если бы ты сказал "некоторые", я бы согласился. А так ты едва ли не прямо сомневаешься в квалификации ollv, что порицается правилами форума.

А я и не сомневаюсь. Он продемонстрировал свою квалификацию самым прямым образом. Прямо и неприкрыто показал, что кроме С++ ничего в жизни толком и не видел.

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

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

ГВ> Ты скажи, ты сам много сайтов на C++ написал, а потом переписал их на что-то ещё, чтобы уверенно утверждать, что C++ не даёт никаких преимуществ?

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

ГВ>>>MS и IBM (как и все остальные) вольны поступать так, как им заблагорассудится.
VD>>Ага. И выбирают для сайтов Яву и дотнет.

ГВ>И что с того? Выбрали и выбрали. Как это должно сказываться на выборе, который делают совсем другие люди?

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

ГВ>>> И кроме всего прочего, слишком мало критериев для отсечения C++: "в кратчайшие строки получить надежное решение, когда денег на разработку нехватает". Он запросто может оказаться наилучшим выбором с учётом других факторов.
VD>>Ага. Но другим фактором может быть только крайняя нужда в достижении высокой вычислительной производительности путем ручной оптимизации.

ГВ>Отнюдь. Решающим фактором может оказаться всё, что угодно, вплоть до наличия под рукой подходящих библиотек и доступности программистов. А ещё фактором может оказаться, например, необходимость тащить .Net FW.

Изумительная логика. Согласен, что на практике именно ею и руководствуются очень многие, но она в корне порочна. Вот представь себе, что речь идет о разработке новой марки автомобиля. Представь себе, что за разработку его берутся не инженеры специализирующиеся на автомабилях, а скажем ракетчики. Они кончено тоже знакомы с аэродинамикой, механикой, физикой, математикой и т.п. и потенциально могут сравиться с задачей. Мало того. В качестве инструментов они берут не заточенные под автомобили кады и т.п., а то на чем они проектировали вертолеты. Вместо двигателей внутреннего сгорания используют ГТД или вообще реактивный двигатель, вместо железа — алюминий и титан и так во всем. В результате автомобиль конечно у них скорее всего получится, но вместо года они потратят пять лет и вместо экономного и относительно недорого автомобиля у них получится монстр который никому не будет нужен на практике.
Маразматическая ситуация? Да, не несомненно! Но почему же такую же ситуацию в сфере разработки ПО ты считаешь само собой разумеющейся?
Если те кто пишет софт берутся за область где С++ не подходит должным образом, то они обязаны владеть альтернативными технологиями. В противном случае им просто не следует браться за выполнение этой работы.
А у нас получается, что людям в лом изучить другие языки, другие технологии, но они все равно берутся за разработку софта в любой отрасли и виде деятельности.
Слава Богу, что такого маразма все меньше и меньше. Но зачем же его защищать?

ГВ>Э... Не так. C++ допускает опасные операции. Но вовсе не требует. А ответственность везде в цене, это от языка не зависит.

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

VD>>Есть такое умное высказывание (не помню чье) — человек не должен делать работу которую может сделать машина. А С++ заставляет человека делать работу которую можно возложить на машину.

ГВ>Не так. C++ позволяет человеку влезть в то, чем обычно занимается машина.

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

ГВ>1. Ограничения на выбор допустимых абстракции есть у любого языка программирования. Так уж они, засранцы, устроены.

Действительно современные языки предоставляют выбор и довольно широкого круга вариантов. С++ же застрял в 80-ых. ООП и шаблоны. А далее голимый кривой С.

ГВ>2. Шаблоны широко используются в программировании на C++. Не понятно, ты считаешь это негативной чертой? Или — ограничителем в выборе абстракции?

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

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

ГВ>Нередко производительность является составляющей интегральной характеристики "качественно".

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


VD>>Многие защитники С++ приводят в качестве примера 3D-игры. Мол, "почему их пишут на С++?". А стоило бы посмотреть на другой аспект. Почти все эти игры безбожно глючат. Играть в некоторые до выхода патчей просто невозможно. Большая часть ошибок в этих играх могла бы быть попросту не допущена, будь программа написана на более качественном языке.

ГВ>С чего ты это взял?

Что? Что написаны на С++? Из слов тех кто это приводит к качестве доказательства того, что все подряд надо на С++ писать.

ГВ>Например, известно, что крутоглюкавый Сталкер (который без кучи патчей вылетает в самых неожиданных местах) написан с использованием Lua.

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

ГВ>Известна также душещипательная история о скоростной резке Сталкера перед выходом (часть карт порезана, часть выброшена и т.д.) Думается, что вторая причина посущественнее остальных будет.

Внимание, вопрос если бы в Сталкере логика игры писалась бы на С++, а не на скрипте, то код игра стала бы надежнее или наоборот?

ГВ>Не понял. Чьи данные ты проверял?

Лесперов которые кидали ссылки на тесты. Зайди в Декларативное программирование и спроси. Тебе тоже ссылок накидают.

ГВ>О чём не заикаться? Я тебя не понимаю что-то. fold, в общем, до какой-то степени эмулируется accumulate+boost::bind, а у find_if — своё, вполне определённое назначение и она вполне применима к широкому набору типов. Шаблон же, однако.

Уродства получаемого в итоге стыдиться. Сравни.
Вот пример использования find_if:

#include <iostream>
#include <algorithm>
#include <vector>

using namespace std;

bool IsOdd (int i) 
{
  return i % 2 == 1;
}

int main () 
{
  vector<int> myvector;
  vector<int>::iterator it;

  myvector.push_back(10);
  myvector.push_back(25);
  myvector.push_back(40);
  myvector.push_back(55);

  it = find_if (myvector.begin(), myvector.end(), IsOdd);

  cout << "The first odd value is " << *it << endl;

  return 0;
}

А вот тоже самое на более современном языке:

using System;
using System.Console;

module Program
{
  Main() : void
  {
    def myvector = Collections.Generic.List([10, 25, 40, 55]);
    
    def it = myvector.Find(x => x % 2 == 1);
    
    WriteLine($"The first odd value is $it");
  }
}

И это простой случай без замыкания. С замыканием разница начинает расти намного сильнее.

ГВ>Так... Тогда объясни, что ты считаешь "прямыми", а что "побочными" эффектами шаблонов?

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

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

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

E>>Да, так бывает. И не только в ПО. И не только сейчас, но и раньше было.
E>>То, что ты не умеешь искать такие позиции, всего лишь говорит что-то о тебе, а не об окружающем мире...
E>>Можешь подумать над значением слова "подмастерье"...

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


Очень просто. Профессия программиста стоит особняком. У Макконнела ("Совершенный код") написано что программистами становятся 40% (боюсь тут соврать) не профильных программистов. А физиков сколько непрофильных? Химикив? Вот и ответ. Если речь идет о системных программистах, то да — это серъезно, а в остальном случае важнее может оказаться иная специальность. Мне кажется, что в большинстве случаев важнее математические способности или физические или экономические, так как сам, решая задачи медленно но верно из освоения технологии скатываюсь к книжкам по алгоритмам. Язык программирования и технологии вторичны.
Про подмастерья не согласен. Надо учить и платить. И чем талантливее ученик, тем больше платить. А то, что я слышу, это просто отголоски честолюбия и высокомерия. Вот только должно быть по Фаусту — "Наследовать достоин тот, кто сам способен дать наследство." Я так считаю.

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

ГВ>>Замыкать можно ещё и значения. Значения указателей — в том числе и т.д., и т.п.
VD>Ты бы лучше не говорил о том в чем не разбираемый. А то такой бред несешь, что просто смешно.
VD>Замыкать значения невозможно. Это просто глупость. Значения на то и значения чтобы копироваться. Суть замыканий как раз в том, чтобы иметь доступ к значениям видимым в лексической области видимости. При этом все переменные и поля которые попали в замыкание должны жить не меньше чем область в которой они объявлены и не меньше чем живет замыкание. Любой указатель должен быть верным до момента когда замыкание перестанет существовать.

Ты бы за логической связью последил. Если копирование — это не один из приёмов, который может использоваться для построения замыкания, то... То я прям, не знаю, даже.

VD>Это приводит к тому, что образуется граф взаимно-связанных объектов время жизни которых крайне сложно отследить. [...] Если исключить GC, я знаю только одну такую — подсчет ссылок.

Это всё понятно, и никто с этим не спорит. Равно как никто и не пытается объявить C++ "чистым ФЯ".

ГВ>>Вот это: "Такие как ollv". Если бы ты сказал "некоторые", я бы согласился. А так ты едва ли не прямо сомневаешься в квалификации ollv, что порицается правилами форума.
VD>А я и не сомневаюсь. Он продемонстрировал свою квалификацию самым прямым образом. Прямо и неприкрыто показал, что кроме С++ ничего в жизни толком и не видел.

Оснований для такого утверждения нет. Мораль? Тебе это всё показалось.

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

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

ГВ>> Ты скажи, ты сам много сайтов на C++ написал, а потом переписал их на что-то ещё, чтобы уверенно утверждать, что C++ не даёт никаких преимуществ?
VD>Я не идиот чтобы заниматься таким маразмом. На С++ я пописал не мало, так что имею полное моральное право судить о его возможностях и недостатках. Как говорится не надо быть курицей, чтобы иметь права рассуждать о вкусе яичницы.

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

ГВ>>>>MS и IBM (как и все остальные) вольны поступать так, как им заблагорассудится.
VD>>>Ага. И выбирают для сайтов Яву и дотнет.
ГВ>>И что с того? Выбрали и выбрали. Как это должно сказываться на выборе, который делают совсем другие люди?
VD>Никак, хотя и сказывается на практике. Это просто демонстрирует, что даже компании с слабо ограниченными ресурсами не выбирают С++ для не не тиражных серверных решений.

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

ГВ>>Отнюдь. Решающим фактором может оказаться всё, что угодно, вплоть до наличия под рукой подходящих библиотек и доступности программистов. А ещё фактором может оказаться, например, необходимость тащить .Net FW.
VD>Изумительная логика. Согласен, что на практике именно ею и руководствуются очень многие, но она в корне порочна.

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

VD>Вот представь себе, что речь идет о разработке новой марки автомобиля. Представь себе, что за разработку его берутся не инженеры специализирующиеся на автомабилях, а скажем ракетчики. Они кончено тоже знакомы с аэродинамикой, механикой, физикой, математикой и т.п. и потенциально могут сравиться с задачей. Мало того. В качестве инструментов они берут не заточенные под автомобили кады и т.п., а то на чем они проектировали вертолеты. Вместо двигателей внутреннего сгорания используют ГТД или вообще реактивный двигатель, вместо железа — алюминий и титан и так во всем. В результате автомобиль конечно у них скорее всего получится, но вместо года они потратят пять лет и вместо экономного и относительно недорого автомобиля у них получится монстр который никому не будет нужен на практике.
VD>Маразматическая ситуация? Да, не несомненно! Но почему же такую же ситуацию в сфере разработки ПО ты считаешь само собой разумеющейся?

Действительно, ситуация неоднозначная. Из-за вагона логических ошибок в твоём рассуждении. Например, ты не учитываешь, что проектирование автомобиля и проектирование вертолёта выполняется в рамках определённых массогабаритных, прочностных и прочих технических и нетехнических ограничений, накладываемых на конечный продукт. Если вертолётчики спроектируют автомобиль, то так или иначе они будут вынуждены вписаться в ограничения, заданные для автомобиля — хоть с титаном, хоть с алюминием, хоть с пластилином. Какие CAD они будут использовать — дело десятое, хоть на счётах вычислять. Это только программисты могут считать, что конечные характеристики автомобиля решающим образом определяются используемым CAD.

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

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

ГВ>>Э... Не так. C++ допускает опасные операции. Но вовсе не требует. А ответственность везде в цене, это от языка не зависит.
VD>Допускать уже достаточно. Но он не только допускает, но и провоцирует их. А зачастую не предоставляет других путей как небезопасные.

Это — проблема и ответственность самих "спровоцировавшихся". Подвержен провокациям — не зямай C++.

VD>К тому же чтобы создать относительно безопасные решения требуется весьма высокая квалификация и немалые силы на выработку стратегии и контроль ее соблюдения. Заметь я не говорю, что речь идет о инструменте в руках ламеров. Он и весьма квалифицированным программистам надевает гандикап.

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

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

VD>>>Есть такое умное высказывание (не помню чье) — человек не должен делать работу которую может сделать машина. А С++ заставляет человека делать работу которую можно возложить на машину.
ГВ>>Не так. C++ позволяет человеку влезть в то, чем обычно занимается машина.
VD>Нет. Он заставляет заниматься человека тем, что может контролировать машина. Он не предаставляет возможности не думать об упрвлении памятью даже если программист этого очень хочет. Он не предоставляет гарантий типобезопасности. Эти аспекты требуется контролировать вручную!

Прям, не язык, а монстр. (отсмеяшись) Знаешь, где самые страшные монстры? В воображении!

ГВ>>1. Ограничения на выбор допустимых абстракции есть у любого языка программирования. Так уж они, засранцы, устроены.
VD>Действительно современные языки предоставляют выбор и довольно широкого круга вариантов. С++ же застрял в 80-ых. ООП и шаблоны. А далее голимый кривой С.

ООП, между прочим, несколько более молодая концепция, чем ФП.

ГВ>>2. Шаблоны широко используются в программировании на C++. Не понятно, ты считаешь это негативной чертой? Или — ограничителем в выборе абстракции?
VD>Они средством затычкой с помощью которой люди пытаются обойти ограничения. Но результат неудовлетворительный. И только те, кто кроме С++ ничего не видел, считают это в порядке вещей.

А если без эпитетов и метафор? Если ты полагаешь шаблоны ограничивающим фактором, то уточни, пожалйста, каков характер накладываемых ограничений?

VD>>>Причем очень распростронено мнение, что производительность важнее качества.
ГВ>>Нередко производительность является составляющей интегральной характеристики "качественно".
VD>Я бы скорее сказал — не часто. Но дело даже не в этом. Решение проблем производительности только путем работы на низком уровне — это не вреный подход. Выигрыш от выбора более оптимальных алгоритмов куда более существеннен нежели от ковыряния в указателях.

Есть ещё abstraction penalty. AFAIK, Java и .Net на данный момент справляются с ним несколько хуже, чем C++. Возможно, что когда-нибудь ситуация изменится, я это вполне допускаю. Только не надо читать мне лекцию по JIT-компиляции и возможностях этого подхода, я их отлично представляю.

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

Угу: в частности, если в приложении есть много тупых... Далее по тексту.

VD>>>Многие защитники С++ приводят в качестве примера 3D-игры. Мол, "почему их пишут на С++?". А стоило бы посмотреть на другой аспект. Почти все эти игры безбожно глючат. Играть в некоторые до выхода патчей просто невозможно. Большая часть ошибок в этих играх могла бы быть попросту не допущена, будь программа написана на более качественном языке.
ГВ>>С чего ты это взял?
VD>Что? Что написаны на С++? Из слов тех кто это приводит к качестве доказательства того, что все подряд надо на С++ писать.

Нет, вот это: "Большая часть ошибок в этих играх могла бы быть попросту не допущена"? Откуда такая уверенность?

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

И что характерно — она глючит похлеще движка. Если прикинуть, то ИМХО, плотность глюков на единицу скриптового кода получается поболе, чем в движке.

ГВ>>Известна также душещипательная история о скоростной резке Сталкера перед выходом (часть карт порезана, часть выброшена и т.д.) Думается, что вторая причина посущественнее остальных будет.
VD>Внимание, вопрос если бы в Сталкере логика игры писалась бы на С++, а не на скрипте, то код игра стала бы надежнее или наоборот?

Я думаю, что на этот вопрос нет ответа. Единственно, что будь игровая логика написана на C++, её было бы не так легко модифицировать моддерам.

ГВ>>О чём не заикаться? Я тебя не понимаю что-то. fold, в общем, до какой-то степени эмулируется accumulate+boost::bind, а у find_if — своё, вполне определённое назначение и она вполне применима к широкому набору типов. Шаблон же, однако.
VD>Уродства получаемого в итоге стыдиться. Сравни.
VD>Вот пример использования find_if:

[skip overquoting]

VD>И это простой случай без замыкания. С замыканием разница начинает расти намного сильнее.

Синтетика не показательная. Например, что касается C++-ного фрагмента, то он может быть и вот таким:

it = find_if (myvector.begin(), myvector.end(), _1 % 2 == 1);

Это с примитивными, в общем-то, бустовыми лямбдами. А то, что find_if не внесён в vector, так это хорошо есть и хорошо весьма.

ГВ>>Так... Тогда объясни, что ты считаешь "прямыми", а что "побочными" эффектами шаблонов?
VD>Прямой эффект — это параметрически полиморфизм, т.е. то ради чего шаблоны были введены. А вот вычисления во время компиляции основанные на том факте, что раскрытие шаблонов идет итеративно и может быть остановлено человеком описавшим частный случай шаблона — это использование побочного эффекта.

Понятно. Хотя, наличие таких побочных эффектов естественно следует из логики разворачивания шаблонов.

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

Ну и что?

P.S.: В предыдущем постинге я тебя спросил:

Просто любопытно: из чего ты сделал вывод, что я считаю, что "мозг не нужен" и "главное — трясти"?

Вопрос остаётся в силе.

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

ГВ>Кто это тут защищал использование C++ там, где он не подходит должным образом? По-моему, тебе померещилось. Разговор идёт о гротескной преувеличенности недостатков C++ и о том, что в некоторых ситуациях он оказывается наилучшим выбором.
Очень мало таких ситуаций. На практике оказывается что там где подходит С++ на самом деле нужно что-то вроде C_ _ классами. Высокоуровневые абстакции С++ идут лесом, упор делается на вычисления.

ГВ>Ты, почему-то, додумываешь, что это является призывом использовать C++ где ни попадя, вопреки здравому смыслу.
Ну попытка использвания C++ для сайтов или High-load сценариев — вопреки здравому смыслу.
Хотя многие тут уверены в обратном.

ГВ>>>Не так. C++ позволяет человеку влезть в то, чем обычно занимается машина.
VD>>Нет. Он заставляет заниматься человека тем, что может контролировать машина. Он не предаставляет возможности не думать об упрвлении памятью даже если программист этого очень хочет. Он не предоставляет гарантий типобезопасности. Эти аспекты требуется контролировать вручную!
ГВ>Прям, не язык, а монстр. (отсмеяшись) Знаешь, где самые страшные монстры? В воображении!
Сарказм здесь не уместен. C++ действительно заставляет программиста работать на очень низком уровне, даже если ему этого не хочется.
Это огромная проблема для языка.

ГВ>Есть ещё abstraction penalty. AFAIK, Java и .Net на данный момент справляются с ним несколько хуже, чем C++. Возможно, что когда-нибудь ситуация изменится, я это вполне допускаю. Только не надо читать мне лекцию по JIT-компиляции и возможностях этого подхода, я их отлично представляю.
О каком конкретно abstarction penality идет речь?

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

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

ГВ>И что характерно — она глючит похлеще движка. Если прикинуть, то ИМХО, плотность глюков на единицу скриптового кода получается поболе, чем в движке.
Только глюк в движке на С++ приведет к AV и падению, а глюк в игрологике может остаться незамеченным совсем.

ГВ>>>Известна также душещипательная история о скоростной резке Сталкера перед выходом (часть карт порезана, часть выброшена и т.д.) Думается, что вторая причина посущественнее остальных будет.
VD>>Внимание, вопрос если бы в Сталкере логика игры писалась бы на С++, а не на скрипте, то код игра стала бы надежнее или наоборот?
ГВ>Я думаю, что на этот вопрос нет ответа. Единственно, что будь игровая логика написана на C++, её было бы не так легко модифицировать моддерам.
На самом деле на С++ она не была бы написана никогда.

ГВ>Синтетика не показательная. Например, что касается C++-ного фрагмента, то он может быть и вот таким:
ГВ>

ГВ>it = find_if (myvector.begin(), myvector.end(), _1 % 2 == 1);
ГВ>

А если выражение лямбды работает не с числами?

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

ГВ>>Кто это тут защищал использование C++ там, где он не подходит должным образом? По-моему, тебе померещилось. Разговор идёт о гротескной преувеличенности недостатков C++ и о том, что в некоторых ситуациях он оказывается наилучшим выбором.
G>Очень мало таких ситуаций. На практике оказывается что там где подходит С++ на самом деле нужно что-то вроде C_ _ классами. Высокоуровневые абстакции С++ идут лесом, упор делается на вычисления.

http://en.wikipedia.org/wiki/Objective-C — во многих смыслах замечательное решение, а с недавних пор еще и автоматическая сборка муссора появилась (опционально).

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

ГВ>>Кто это тут защищал использование C++ там, где он не подходит должным образом? По-моему, тебе померещилось. Разговор идёт о гротескной преувеличенности недостатков C++ и о том, что в некоторых ситуациях он оказывается наилучшим выбором.
G>Очень мало таких ситуаций. На практике оказывается что там где подходит С++ на самом деле нужно что-то вроде C_ _ классами. Высокоуровневые абстакции С++ идут лесом, упор делается на вычисления.

По чьей практике так оказывается?

ГВ>>Ты, почему-то, додумываешь, что это является призывом использовать C++ где ни попадя, вопреки здравому смыслу.
G>Ну попытка использвания C++ для сайтов или High-load сценариев — вопреки здравому смыслу.
G>Хотя многие тут уверены в обратном.

Вероятно, нужно обратиться к тем, кто использует C++ для high-load. Тогда всё станет на свои места.

ГВ>>Прям, не язык, а монстр. (отсмеяшись) Знаешь, где самые страшные монстры? В воображении!
G>Сарказм здесь не уместен. C++ действительно заставляет программиста работать на очень низком уровне, даже если ему этого не хочется.
G>Это огромная проблема для языка.

Скажем так, это неотъемлемая черта языка — возможность работы с низким уровнем. Надо это делать или нет — зависит от.

ГВ>>Есть ещё abstraction penalty. AFAIK, Java и .Net на данный момент справляются с ним несколько хуже, чем C++. Возможно, что когда-нибудь ситуация изменится, я это вполне допускаю. Только не надо читать мне лекцию по JIT-компиляции и возможностях этого подхода, я их отлично представляю.
G>О каком конкретно abstarction penality идет речь?

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

ГВ>>И что характерно — она глючит похлеще движка. Если прикинуть, то ИМХО, плотность глюков на единицу скриптового кода получается поболе, чем в движке.
G>Только глюк в движке на С++ приведет к AV и падению, а глюк в игрологике может остаться незамеченным совсем.

Ну да! Ещё как замеченным!

ГВ>>Я думаю, что на этот вопрос нет ответа. Единственно, что будь игровая логика написана на C++, её было бы не так легко модифицировать моддерам.
G>На самом деле на С++ она не была бы написана никогда.

О! Свежая мысль.

ГВ>>Синтетика не показательная. Например, что касается C++-ного фрагмента, то он может быть и вот таким:
ГВ>>

ГВ>>it = find_if (myvector.begin(), myvector.end(), _1 % 2 == 1);
ГВ>>

G>А если выражение лямбды работает не с числами?

Да на здоровье. Можно и ссылки, и указатели запихнуть.

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

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

ГВ>>>Кто это тут защищал использование C++ там, где он не подходит должным образом? По-моему, тебе померещилось. Разговор идёт о гротескной преувеличенности недостатков C++ и о том, что в некоторых ситуациях он оказывается наилучшим выбором.
G>>Очень мало таких ситуаций. На практике оказывается что там где подходит С++ на самом деле нужно что-то вроде C_ _ классами. Высокоуровневые абстакции С++ идут лесом, упор делается на вычисления.
ГВ>По чьей практике так оказывается?
По практике общения здесь в первую очередь.
Все "защитники" С++, если хоть немного разбираются в managed языках, упор делают а performance в C++.
Причем с++ обеспечивает быстродействие в числомолотильных алгоримтах в первую очередь. Там где требуется активная работа с памятью, сложными структурами данных, С++ без приседаний с аллокаторами сливает.


ГВ>>>Ты, почему-то, додумываешь, что это является призывом использовать C++ где ни попадя, вопреки здравому смыслу.
G>>Ну попытка использвания C++ для сайтов или High-load сценариев — вопреки здравому смыслу.
G>>Хотя многие тут уверены в обратном.
ГВ>Вероятно, нужно обратиться к тем, кто использует C++ для high-load. Тогда всё станет на свои места.

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

ГВ>>>Прям, не язык, а монстр. (отсмеяшись) Знаешь, где самые страшные монстры? В воображении!
G>>Сарказм здесь не уместен. C++ действительно заставляет программиста работать на очень низком уровне, даже если ему этого не хочется.
G>>Это огромная проблема для языка.
ГВ>Скажем так, это неотъемлемая черта языка — возможность работы с низким уровнем. Надо это делать или нет — зависит от.
Не надо подменять понятия, в С++ это не возможность, а необходимость.

ГВ>>>Есть ещё abstraction penalty. AFAIK, Java и .Net на данный момент справляются с ним несколько хуже, чем C++. Возможно, что когда-нибудь ситуация изменится, я это вполне допускаю. Только не надо читать мне лекцию по JIT-компиляции и возможностях этого подхода, я их отлично представляю.
G>>О каком конкретно abstarction penality идет речь?
ГВ>Да он почти всегда к одному сводится: к куче вложенных вызовов "абстрактных слоёв".
И что? 2-3 виртуальных вызова вообще незаметны будут ни при каком раскладе.
Давай конкретно, о каком penality идет речь?

вот насчет abstarction gain — оно есть в .NET. Одно из проявлений — динамическая кодогенерация. Я недавно писал runtime-генератор конечных автоматов по описанию. В С++ такое в принципе невозможно.

ГВ>>>Синтетика не показательная. Например, что касается C++-ного фрагмента, то он может быть и вот таким:
ГВ>>>

ГВ>>>it = find_if (myvector.begin(), myvector.end(), _1 % 2 == 1);
ГВ>>>

G>>А если выражение лямбды работает не с числами?
ГВ>Да на здоровье. Можно и ссылки, и указатели запихнуть.
Ну и как быдет выглядет "лямбда" на C++, в которой вызывается метод объекта-параметра и его результат сравнивается к чем-либо?

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

ГВ>>Вероятно, нужно обратиться к тем, кто использует C++ для high-load. Тогда всё станет на свои места.
G>
G>Если кто-то пишет High-load на С++, то это не означает что так надо делать. Кроме того некоторые системы могут бть написаны на С++ по историческим причинам.
G>Вообще аппеляции к тому что "кто-то так делает" не показывают равильность такого применения.

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

G>>>Это огромная проблема для языка.
ГВ>>Скажем так, это неотъемлемая черта языка — возможность работы с низким уровнем. Надо это делать или нет — зависит от.
G>Не надо подменять понятия, в С++ это не возможность, а необходимость.

Э... Тогда поясни, что имеется в виду под низким уровнем? __asm, void*, арифметика указателей или вообще любые упоминания указателей?

ГВ>>>>Есть ещё abstraction penalty. AFAIK, Java и .Net на данный момент справляются с ним несколько хуже, чем C++. Возможно, что когда-нибудь ситуация изменится, я это вполне допускаю. Только не надо читать мне лекцию по JIT-компиляции и возможностях этого подхода, я их отлично представляю.
G>>>О каком конкретно abstarction penality идет речь?
ГВ>>Да он почти всегда к одному сводится: к куче вложенных вызовов "абстрактных слоёв".
G>И что? 2-3 виртуальных вызова вообще незаметны будут ни при каком раскладе.
G>Давай конкретно, о каком penality идет речь?

Ну, во-первых, к 2-3 виртуальным вызовам абстракции редко сводятся, а во-вторых, здесь мне надо поискать отдельно. От ответа не отказываюсь, просто нужно кое-какие детали восстановить.

G>Ну и как быдет выглядет "лямбда" на C++, в которой вызывается метод объекта-параметра и его результат сравнивается к чем-либо?

class Foo {
  public:
    int foo(){...};
};

std::vector<Foo*> vec;

find_if (myvector.begin(), myvector.end(), bind(&T::foo, _1) != 42);

Это опять таки — бустовая примочка.

class Foo {
  public:
    int foo(){...};
};

std::vector<Foo*> vec;

find_if (vec.begin(), vec.end(), bind(&T::foo, _1) != 42);

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

Тут снова вопрос производительности поднялся

Автор: void29091988
Дата: 29.04.09

.
Обращение не конкретно к ГВ, а к тем, кто пожелает защитить честь неуправляемого кода, или просто помочь человеку разобраться с тем, что он делает не так.

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

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

G>Если кто-то пишет High-load на С++, то это не означает что так надо делать. Кроме того некоторые системы могут бть написаны на С++ по историческим причинам.
G>Вообще аппеляции к тому что "кто-то так делает" не показывают равильность такого применения.

Хм, а на что тогда опираться? на победные реляции сан и микрософт? Критерий истины — практика

ГВ>>Да он почти всегда к одному сводится: к куче вложенных вызовов "абстрактных слоёв".
G>И что? 2-3 виртуальных вызова вообще незаметны будут ни при каком раскладе.
G>Давай конкретно, о каком penality идет речь?

Так скажем, не будут заметны в большинстве случаев. Однако, опираясь на практику как критерий истины :), я могу однозначно сказать, что не только виртуальные, но и обычные вызовы влияют на производительность. Проверяется это очень просто — я интенсивно использую инлайны в проектах на C++, так вот время отклика для релизной версии в несколько раз (если не на порядок) лучше чем в отладочной — скажем 40-50 мс и 300-400 мс. Что это значит для пользователя я думаю объяснять не надо. Да что там говорить, достаточно почитать рекомендации по написанию производительного кода на яве или .нет — как можно меньше маленьких функций, объектов, все вычисления выносить в одну большую простыню, тогда может jit что-то и сделает. На C++ так извращаться не надо — в итоге программы получаются эффективными, но асбсолютно не теряют в читаемости. В принципе, это была изначальная цель при создании C++ и она с успехом достигнута.

У C++ конечно есть недостатки и наверное можно придумать язык лучше, но по моему проблема в том, что вместо лучшего навязывается другое. Скажем, лисп — это отличный язык, но он не лучше и не хуже C++, он просто другой. То же самое с C# и явой.

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

S>Тут снова вопрос производительности поднялся

Автор: void29091988
Дата: 29.04.09

.
S>Обращение не конкретно к ГВ, а к тем, кто пожелает защитить честь неуправляемого кода, или просто помочь человеку разобраться с тем, что он делает не так.

Это не сравнение управляемого и неуправляемого кода, а тестирование подсистем ввода-вывода :)

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

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

S>>Тут снова вопрос производительности поднялся

Автор: void29091988
Дата: 29.04.09

.
S>>Обращение не конкретно к ГВ, а к тем, кто пожелает защитить честь неуправляемого кода, или просто помочь человеку разобраться с тем, что он делает не так.

COF>Это не сравнение управляемого и неуправляемого кода, а тестирование подсистем ввода-вывода

Дело не в том как написано и что тестируется и даже не в конкретном экспериментаторе (который думает что разница в контроле типов в рантайме), а в интерпретации результата.
Победил C# — недоумение
Победил С++ — значит C# — тормоз

Притом человеку не важно, что тесты заняли около 3х секунд, если бы и 30 в обоих случаях, он бы не удивился. Ему важно что на такой синтетике (10 тыс. раз по 10 тыс символов) что-то быстрее, притом что он гораздо больше потеряет в эффективности принимая непутевые решения.

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

S>Дело не в том как написано и что тестируется и даже не в конкретном экспериментаторе (который думает что разница в контроле типов в рантайме), а в интерпретации результата.
S>Победил C# — недоумение
S>Победил С++ — значит C# — тормоз

Не, ну все правильно. Победил C# значит надо разбираться где в C++ коде косяк :)

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

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

G>>Если кто-то пишет High-load на С++, то это не означает что так надо делать. Кроме того некоторые системы могут бть написаны на С++ по историческим причинам.
G>>Вообще аппеляции к тому что "кто-то так делает" не показывают равильность такого применения.
COF>Хм, а на что тогда опираться? на победные реляции сан и микрософт? Критерий истины — практика
Факторы, влиящие на практическе применение, зачастую очень далеки от технических.


ГВ>>>Да он почти всегда к одному сводится: к куче вложенных вызовов "абстрактных слоёв".
G>>И что? 2-3 виртуальных вызова вообще незаметны будут ни при каком раскладе.
G>>Давай конкретно, о каком penality идет речь?

COF>Так скажем, не будут заметны в большинстве случаев. Однако, опираясь на практику как критерий истины , я могу однозначно сказать, что не только виртуальные, но и обычные вызовы влияют на производительность. Проверяется это очень просто — я интенсивно использую инлайны в проектах на C++, так вот время отклика для релизной версии в несколько раз (если не на порядок) лучше чем в отладочной — скажем 40-50 мс и 300-400 мс. Что это значит для пользователя я думаю объяснять не надо. Да что там говорить, достаточно почитать рекомендации по написанию производительного кода на яве или .нет — как можно меньше маленьких функций, объектов, все вычисления выносить в одну большую простыню, тогда может jit что-то и сделает. На C++ так извращаться не надо — в итоге программы получаются эффективными, но асбсолютно не теряют в читаемости. В принципе, это была изначальная цель при создании C++ и она с успехом достигнута.
Думаешь разница в скорости между release и debug достигается инлайнингом?
Кстати JIT сам умеет инлайнить, прчием начиная с 3.5SP1 весьма неплохо.

COF>У C++ конечно есть недостатки и наверное можно придумать язык лучше, но по моему проблема в том, что вместо лучшего навязывается другое. Скажем, лисп — это отличный язык, но он не лучше и не хуже C++, он просто другой. То же самое с C# и явой.
Lisp — не mainstream, изначально по причине медленности, впоследствии из-за своего синтаксиса.

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

G>>>>Это огромная проблема для языка.
ГВ>>>Скажем так, это неотъемлемая черта языка — возможность работы с низким уровнем. Надо это делать или нет — зависит от.
G>>Не надо подменять понятия, в С++ это не возможность, а необходимость.
ГВ>Э... Тогда поясни, что имеется в виду под низким уровнем? __asm, void*, арифметика указателей или вообще любые упоминания указателей?
1)Ручное управление памятью, надо следить чтобы указатель нигде не повис. Использовать умные указатели или следить чтобы везде вызывался delete
2)Арифметика указателей, надо следить чтобы использовались STL-ные итераторы вместо указателей
3)Даже с бустом сложные лямбды надо формировать кучей методов bind.
4)Небезопасные приведения типов
продолжать можно долго...

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

G>Думаешь разница в скорости между release и debug достигается инлайнингом?
G>Кстати JIT сам умеет инлайнить, прчием начиная с 3.5SP1 весьма неплохо.

В определенных местах практически только им

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

G>Я писал такой тест в этой теме, смотри выше, C++ слил в 3-6 раз. Это без шаред птр
G>А потом прибежали другие и начали рассказывать что они динамическую память не выделяют и создают все на стеке
Ты мерял там на самом деле разницу в производительности GC и WinAPI функции HeapAlloc.
А никак не работу с shared ptr.

G>Ответь на вопрос, нафига MAPI в .NET?
Вот хочется ему. Представь что он заказчик и ему надо именно MAPI.

G>Возьми DLL, скомпилированную Intel C++ Compiler и напиши в visual studio код, который создает объект из этой либы — придет понимание.
ICC манглит имена так же как и визжалка. Так что никаких проблем не ожидается.