Здравствуйте, Nuzhny, Вы писали:
N>По факту — он ускорился. Но там одновременно и массово внутренность многих функций была переписана на SSE, AVX, NEON. N>Удобнее использовать, кстати, стало всем. Появились нормальные биндинги на Питон и Java. Существует постоянное сторонее API для С# — Emgu CV. Если ранььше библиотека была достаточно страшной со всех сторон (во времена Интела), глючила безбожно, текла память, то сейчас это очень качественная вещь. Пользоваться реально удобно.
Это все может быть результатом переписывания. Не факт, что переписывание на том же С не дало бы таких же результатов. Просто люди произвели грамотную модернизацию. Примеров говна написанного на С++ море.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nuzhny, Вы писали:
N>Да, стоит. Внутри того же OpenCV, который невольно стал примером тематической библиотеки на С++, тоже есть expression templates для матриц. Я могу написать читабельное выражение для любого математика типа: Y = A * X + B. И правая часть выполнится ОДНОЙ (!!!) специализированной функцией. Вот это и есть применение С++, которое улучшает понимание кода, делает его проще без ущерба для скорости.
Это возможно не только на С++.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ее выгоднее делать на видеокартах. И как не странно есть не мало решений на высокоуровневых языках для этого.
Нормального доступа из высокоуровневых языков к технологиям общения с картами как не было так и не ожидается. Поэтому проще взять C++.
K>>* Игрушки. Не тетрис на флеше, а настоящие 3D игры. Геймеры любят красивую графику, и не любят когда игра лагает. VD>В игрушках на С++ пишутся движки. А их очень не много, если осмотреться. А вот основной код игрушек пишется на голимейших скриптах.
Не на таких уж и голимых скриптах. С повсеместным Unity — это C#/.NET. А вот Lua и иже с ними — подвинулись.
Здравствуйте, VladD2, Вы писали:
VD>Типобезопасность
VD>В С++ возможна прямая и ничем не ограниченная работа с памятью. Это как преимущество, так и недостаток.
Просто для полноты — C# имеет честные указатели. Единственное тут различие — культура их не-использования. В C++ мы чаще имеем дело с ними, поэтому конечно потенциальных ошибок больше. Но принципиальных отличий нет.
В свете последнего опыта с C++ я почти всегда стараюсь его критиковать. Меня конечно понять сложно т.к. не обладаю талантом выражать мысли максимально понятно.
Тем не менее последние наблюдения меня вводят в некоторое уныние.
1. Типы и Undefined Behavior
Я не понимаю почему в стандарте наконец не определят бихейвор. Я не понимаю каким образоп оптимизаторы начали вдруг эксплуатировать UB. Оно всё равно в 99% случаев не имеет практического смысла под собой. Это ещё дополняется людьми — поборниками стандарта.
Ну не возможно блин определить человеку ошибку, особенно, если она попадает в UB, или implementation-defined.
Вот возьмем ODR (one definition rule). На него все десятилетиями болт ложили и ложат досихпор. Но с ростоп популярности и необходимости LTCG/LTO (link time code generation) — это правило стало из слабо нужных чуть ли не в одно из первых.
Мы встретились (я встретился) с этим впервые что билд CEF не работал на целевой машине... потому что там не было AVX. Раскопки (мли копания) позволили всё таки MSVS слинковать так что бы SSE2 код не получал пенальти, и вообще работало бы без AVX (как и должно). Да-да — причина — нарушение ODR. Я решил это перестановкой порядка объектных модулей поставляемых линкеру (спасибо людям котопые дают постфиксы в именах). В хроме в след за нами решили эту же проблему путём энфорсинга инлайнинга для методов, они конечно потупили немно но потом наткнулись на это всё равно. А что делать — ведь с GPU на это нельзя наступить. Так или иначе, на сколько я знаю — ни одна из библиотек до сих пор не решила свои проблемы с ODR in first place. (Хром страдал от skia, но библиотеки оптимизированные под avx — обычно видео декодеры — тоже потенциально страдают этим).
Репорт в MS собственно и указал что это ODR. Но, на все мои попытки указать что линкер просто читерит (вместо инлайнинга SSE2 кода он из SSE2-модуля вызывает AVX-код) — они справедливо отмолчались. Ведь это нарушение ODR. Но средств диагностики нет.
Проблема ещё в том, что на проце с AVX — сгенерированный код — неэффективная ахинея, но без пристального профайлинга — заметить невозможно.
gcc/clang тут нисколечко не лучше. Они более аггресивно инлайнили методы и это спасало от проблем. И всё. Аггрессивный инлайнинг != лучше.
Я как-то хотел бы видеть стандарт, а не набор рекомендаций для разработчиков и пользователей языка. Так что — C++ — субъективно лузер. Хотя и безальтернативный.
Короче, поинт в том — что UB не место в стандарте. А с размерами типов можно и определится наконец. Легаси при этом не помеха — один фиг ключи подавай компилятору, и очень много!
2. Шаблоны и Метапрограммирование
Это просто смешно, после рассмотрения языков уровнем повыше. Помните как пёрл называли птичим языком — тут тоже самое, тока имена длиннее. Я не против шаблонов как таковых. Просто их безальтернативность скрывает более простые решения. Я думаю нужны и шаблоны (ну т.е. рефлексированные дженерики), но и взрослые макросы в виде инжекта в компайл пайплайн. Без этого — это издевательство над своим мозгом и мозгом окружающих. Более того — серьёзные работы ж есть. Не нравится N... есть же ж другие. Он, дисер какойинтересный недавно тут был (сорри, забыл ник).
3. Забыл
Забыл, что хотел написать, пока писал вышеперечисленное.
Здравствуйте, Mystic Artifact, Вы писали:
VD>>Ее выгоднее делать на видеокартах. И как не странно есть не мало решений на высокоуровневых языках для этого. MA> Нормального доступа из высокоуровневых языков к технологиям общения с картами как не было так и не ожидается. Поэтому проще взять C++.
Где лучше доступ ещё вопрос. http://rsdn.org/forum/nemerle/4220330.flat
Здравствуйте, WolfHound, Вы писали:
VD>>>Ее выгоднее делать на видеокартах. И как не странно есть не мало решений на высокоуровневых языках для этого. MA>> Нормального доступа из высокоуровневых языков к технологиям общения с картами как не было так и не ожидается. Поэтому проще взять C++. WH>Где лучше доступ ещё вопрос. WH>http://rsdn.org/forum/nemerle/4220330.flat
Не совсем ясно на что именно ты дал ссылку (что конкретно имел ввиду). Сорри.
С учётом того что всё появляется в первую очередь в виде C/C++ хидеров...я полагал это не будет даже смысла обсуждать.
Смотри:
Я думаю, что язык X просто должен уметь инклюдить хотя бы C хидеры (и иметь достаточно гибкую систему типов что-бы обслужить их). Ты никогда не заставишь выпускать windows sdk или linux-headers в другом виде. Более узкие вещи — тем более.
Возможность использовать и просто брать и использовать это достижимые цели с ценой работы отличающейся на порядки (в одном из случаев — просто ничего не надо делать дополнительно).
Если речь про Nemerle и .NET в частности, то прости, managed->native transition и обратно имеет весьма не нулевую цену. В итоге народ делает calli в нативный код без этого, но это годится далеко не везде.
Если я мимо, объясни в кратце и конкретно плиз.
ADD: Привет полуношникам!
UPD: Ссылка на статью у меня не вызывает никакого вау. Я читал нечто подобное буржуйское. В обоих случаях пока это далековато от практики, хотя я абсолютно согласен, что спец языки могут дать нечто интересное для обработки графики. Какой-то есть и так и не в виде статьи. Но, это совершенно ортогонально к топику: если мы хотим иметь отзывчивую графику — мы обязаны избавится от всех лишних расходов, особенно — если разработчик разрабатывает не middleware, а настоящий frontend в виде библиотеки или приложения.
UPD2: В общем в итоге я думаю, что я понял что ты имел ввиду. И в общем — я категорически не согласен: введение новых языков слишком убивает flexibility, всё то же самое делается ровно так же на C++. От программиста — нужно в обоих случаях хорошее погружение в тему, после котрого инструмент перестаёт быть значимым. Применение специализированных абстрактных языков в стратосфере ведёт к бесконечной эыюффективности. Но это из области хотелок, а не реального мира. В реальном мире интероперабельность (совместимость) без потери эфыективности, выходит на первое место. Как только спец язык станет распространён — тогда иной разговор. А до тех пор этоине практично со всех точек зпения, увы.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, ksandro, Вы писали:
K>>Тут соглашусь, чистый С на сегодняшний день единственный конкурент С++.
VD>Вы просто жертвы мэйнстрима. В реальности альтернативы есть: VD>1. Rust.
Это верно, но пока рановато. VD>2. D.
Это смешно. VD>3. Ocamle.
Тредов тонет, скорее кидайте ему спасательный круг! VD>4. Создание DSL-ей генерирующих тот же С/С++.
Можно и из Scheme сгенерировать C. Только производительность у этого кода будет не как у вручную написанного C, а как у питона.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, lpd, Вы писали:
N>Например, STL. Разобраться легко, шаблоны есть, "С с классами" нет. Работает хорошо.
Только std::max возвращает не ту ссылку в случае равных значений. А так да, хорошо.
Здравствуйте, so5team, Вы писали:
S>Когда нужен тонкий ручной тюнинг, то это делается на C++ так же, как и на C. Доё Справедливости ради, в стандартном C есть restrict, а в C++ — нет. (Впрочем, все нужные компиляторы понимают __restrict)
Мелкое замечание, с Вашим утверждением я не спорю.
Здравствуйте, Dair, Вы писали:
D>В некоей гарантии стандартом и вот этим всем, что то что ты написал примерно вот одинаково будет работать.
Честно говоря, не очень понятно...
Например, стандарты есть и на другие языки: С#, Java — да у них немного другая схема выработки стандарта, но тем не менее, она есть.
С другой стороны — у того же C++ весьма не редкие (это я сужу по периодически возникающим обсуждениям на RSDN) случаи различий в поддержке стандарта разными версиями компилятора (и компиляторов от разных поставщиков). Т.е. сам факт наличия стандарта это еще не гарантия единообразия. Нужно еще и единство реализации, а для такого сложного языка как C++, это очень непростая задача.
Здравствуйте, VladD2, Вы писали:
VD>Но влезать в эти С++-ные срачи желания. Нет. Оставайтесь при своих заблуждениях и далее. VD>Для всех остальных есть возможность попробовать и сравнить все самостоятельно.
Влад, мне чуть больше чем 22 года и я вполне неплохо владею несколькими языками программирования. В эти языки входят, помимо C++ и Objective-C, Java, python, ruby. Я писал (хотя меньше чем профессиональный программист) на C#. В прошлом писал на perl.
Лично мне наплевать на язык. Язык — это инструмент. Не наплевать мне на задачи, которые мне надо каким-либо способом решать. Основываюсь я на собственном опыте. Опыт мне говорит, что для моих задач (а это чаще всего кроссплатформенная разработка, среднекритичная к производительности) подходит именно C++. Это не значит, что C++ лучше всех, нет. Я вот для себя веб-приложуньки пишу на Ruby on Rails, и даже не пытаюсь писать их на C++.
Опять же, у меня в опыте поддержка (а) фреймворкового кода, который производитель фреймворка перестал поддерживать и привет. (б) фреймворкового коода, на котором просто и быстро разрабатывалось до какого-то момента, а потом мы упёрлись в то, что производитель фреймворка сказал "не, а вот этого мы не сделали и не сделаем в ближайшие два года".
В идеале, я бы хотел язык с двумя парадигмами распределения памяти — ручной и GC, чтобы разработчик мог выбирать, что ему надо (примерно это решено в Objective-C с его ARC, хотя механизм другой чем GC — работает ровно как на Java/C#, когда не думаешь про выделение памяти).
Я бы хотел язык, для которого есть компилятор в нативный код (x86/x64/arm/arm64/...), но есть и, например, компилятор в JVM или CLR — это дало бы гибкость.
Здравствуйте, Михаил Романов, Вы писали:
D>>В некоей гарантии стандартом и вот этим всем, что то что ты написал примерно вот одинаково будет работать. МР>Честно говоря, не очень понятно... МР>Например, стандарты есть и на другие языки: С#, Java — да у них немного другая схема выработки стандарта, но тем не менее, она есть. МР>С другой стороны — у того же C++ весьма не редкие (это я сужу по периодически возникающим обсуждениям на RSDN) случаи различий в поддержке стандарта разными версиями компилятора (и компиляторов от разных поставщиков). Т.е. сам факт наличия стандарта это еще не гарантия единообразия. Нужно еще и единство реализации, а для такого сложного языка как C++, это очень непростая задача.
Ты контекст потерял. Вне контекста я с тобой согласен.
:
D>>>>>>> Общий компонент программного обеспечения, работающего как на обычных компьютерах Windows/Linux, так и на мобильных устройствах под управлением iOS/Android.
Здравствуйте, Mystic Artifact, Вы писали:
MA> Нормального доступа из высокоуровневых языков к технологиям общения с картами как не было так и не ожидается. Поэтому проще взять C++.
Было сто лет назад, но не на мэйстним языках. На языках с макросами это не проблема.
По сравнению с даже с какой-нибудь Явой — на очень голимых скриптах.
MA>С повсеместным Unity — это C#/.NET. А вот Lua и иже с ними — подвинулись.
Это только в последнее время. Да и скрипты еще не очень то подвинулись.
Я еще 10 лет назад говорил, что довольно глупо не использовать управляемые языки (особенно такие как Nemerle, Scala и F#) для разработки игр. Но все идут по пути наименьшего сопротивления. Производительности хватает и ладно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
: D>>>>>>>> Общий компонент программного обеспечения, работающего как на обычных компьютерах Windows/Linux, так и на мобильных устройствах под управлением iOS/Android.
Т.е. если я правильно понял — дает более предсказуемый результат (даже в контексте озвученных мною проблем "компиляторы от разных поставщиков"), для случая кросс-платформенной разработки, чем конкурирующие языки и технологии (у которых всё еще хуже)?
Так?
И если я правильно понял, то можете ещё подсказать с какими аналогами/конкурентами идет сравнение (и есть ли такие вообще)?
Здравствуйте, Mystic Artifact, Вы писали:
MA>Просто для полноты — C# имеет честные указатели. Единственное тут различие — культура их не-использования. В C++ мы чаще имеем дело с ними, поэтому конечно потенциальных ошибок больше. Но принципиальных отличий нет.
Это не полнота, а заблуждения. Указатели в Шарпе отнюдь не полноценны. Они сильно ограничены. Их можно использовать только в специальном режиме и только помеченной области. Ну, и главное, что они вообще не нужны для написания программ. Они используются только как средство оптимизации.
В 7-й версии создали безопасный указатель. Они тоже сильно ограничен. Но еще больше уменьшают потребность в указателях.
Так что сравнивать это не надо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
: D>>>>>>>>> Общий компонент программного обеспечения, работающего как на обычных компьютерах Windows/Linux, так и на мобильных устройствах под управлением iOS/Android.
МР>Т.е. если я правильно понял — дает более предсказуемый результат (даже в контексте озвученных мною проблем "компиляторы от разных поставщиков"), для случая кросс-платформенной разработки, чем конкурирующие языки и технологии (у которых всё еще хуже)? МР>Так?
Да.
Понятно (как я уже Владу в другой ветке написал), что не надо писать вебприложение на C++ — на более языках более высокого уровня сделано всё достаточно хорошо — C#, Java, python, ruby.
МР>И если я правильно понял, то можете ещё подсказать с какими аналогами/конкурентами идет сравнение (и есть ли такие вообще)?
Щупал руками:
Unity (C#), React Native (Javascript), Xamarin (опять С#), Qt (C++, да, но в случае Android, например, даёт плохой результат).
Здравствуйте, prezident.mira, Вы писали:
VD>>1. Rust. PM>Это верно,
Мне нравится учительский тон.
PM>но пока рановато.
Ты всю жизнь прождешь и будешь поговаривать "пока рановато". Я это уже на том же D наблюдал.
VD>>2. D. PM>Это смешно.
Смешно это менторский тон и безапелляционные заявления. Меж тем D обладает всем, что есть в С++ и многим, что в нем нет. А главное, что на нем куда проще писать код.
За последние годы С++ несколько подтянулся и разрыв стал не столь очевиден. Но вот уже более 10 лет такие как ты используют довольно убогий С++ приговаривая "пока рановато". А сейчас вот появились и те кто говорит "смешно". Причем без единого аргумента.
VD>>3. Ocamle. PM>Тредов тонет, скорее кидайте ему спасательный круг!
Он уже лет 25 тонет. Все никак потонет. А разные крикуны не написавшие на других языках ни строчки кода навешивают ярлыки "тонет", "смешно", "рановато"...
VD>>4. Создание DSL-ей генерирующих тот же С/С++. PM>Можно и из Scheme сгенерировать C. Только производительность у этого кода будет не как у вручную написанного C, а как у питона.
Ты сначала сам попробуй, а потом трепись. К слову я этим треть жизни занимаюсь. Разницы между вручную написанным кодом и сгенерированным не наблюдаю. Его всегда можно сделать аналогичным.
Ну, и не нужен везде идеальный код. А Питону может проиграть по скорости разве что... э... ну, Руби, т.е. такой же в доску шэштабличный язык.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Я как-то хотел бы видеть стандарт, а не набор рекомендаций для разработчиков и пользователей языка. Так что — C++ — субъективно лузер. Хотя и безальтернативный.
