Здравствуйте, CreatorCray, Вы писали:
DI>> Все в белую, интересуют мидлы с прицелом на сеньора, готов предложить от 200 на руки. CC>Так уж и быть тут я удержусь от подколок.
Здравствуйте, CreatorCray, Вы писали:
DI>>Омг, ты еще одаренней, чем мне сначала показалось CC>Тебе много чего кажется CC>Доклад видимо тоже галлюцинация
Здравствуйте, Pzz, Вы писали:
DI>>Про пользу для себя от данного форума я скоро раскрою отдельным сообщением, следите за новостями.
Pzz>Думаешь, нам шибко интересно?
Еще один прискакал рассказать мне как я ему безразличен
Здравствуйте, yoyoyo, Вы писали:
B>>Хорош, но я надеюсь переползти на Rust.
Y>Думаю, что в будущем, когда С++ схлопнется еще сильнее, то что от него останется будет больше, чем то во что разрастается Rust. Если говорить про сегодняшний день, вакансий на Rust меньше чем вакансий на Delphi/Pascal. Мы на работе пытались некоторые сервисы писать на Rust, но потом отказались от этой идеи, слишком высок уровень вхождения, а тратить полгода на то, чтобы человек набил руку никто не хочет. В итоге все переписали на Go на котором уже через неделю можно программировать на приемлемом уровне.
С какого языка вы переходили? Сколько лет опыта было у переходивших?
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, Denis Ivlev, Вы писали:
S>>С производительностью.
DI>Чего?
А вы с какой целью интересуетесь?
S>>Так с кем встречаться-то? С вымышленным Денисом Ивлиевым?
DI>Игра с голубем в шахматы становится весьма скучной.
Вполне предскауемо повторяете славный путь smeeld.
S>>Анонимный нонейм может что-то предложить? Рассмешили.
DI>Посмейся, для адекватных людей я сказал достаточно — пишите, кому интересно.
Думаете, что адекватных людей заинтересует предложение от неизвестно какой конторы, высказанное неизвестно кем с замашками гопника?
Так все-таки, на какой доклад на этом Highload++ стоит обратить внимание. Очень уж хочется увидеть, как будет делать доклад человек, позволяющий вести себя подобным образом здесь.
Здравствуйте, Denis Ivlev, Вы писали:
_>>Кстати, в контексте данной дискуссии довольно забавно, что там не мало докладов по C++ тематике. Я и не думал, что C++ имеет существенное распространение в данной области за пределами таких специфических монстриков как Гугл, Яндекс и т.п. DI>Это какие? За плюсы традиционно Леха Милодивов с Кликхаусом топит, но он как раз из Яндекса
Ну ссылка то на страницу есть выше. Открой её, нажми Ctrl+F, набери C++ и посмотри число вхождений...
Здравствуйте, Pzz, Вы писали:
M>>Например, в зависимости от используемых оптимизаций оптимальными могут быть разные варианты Pzz>Тут народ призывает целые числа хранить в обертках, которые при каждом присваивании проверяют диапазон и исключениями кидаются. А ты говоришь про какой-то очень тонкий файнтьюнинг, эффект от которого не на каждом бенчмарке заметишь. Pzz>Все-таки, очень, очень разные у людей представления об оптимизации
Ну тут всё же надо однозначно отметить, что у C++ (а так же у Rust, D и им подобным) цена такой обёртки нулевая. Т.е. нет никаких накладных расходов (проверка — это не накладные расходы, т.к. она будет в любом случае на любых языка, только просто написана руками) от того факта, что используется специальный тип, а не int. А вот скажем на языках типа Java такую автоматическую проверку просто невозможно сделать без накладных расходов, поэтому там или всё руками или очень медленно.
Здравствуйте, Marty, Вы писали:
_>>Вообще то gcc уже давно перешли на C++. Ну и да, архитектурно clang конечно на порядки лучше. Только вот при этом он пока является худшим в производительности генерируемого кода среди всех основных компиляторов. Так что я конечно же надеюсь когда-нибудь полностью перейти на него (хороши когда сообщения об ошибках человеческие и всё такое), но до этого времени ещё очень далеко (им ещё работать и работать над оптимизатором). M>А можно ссылочки на сравнения? А то что-то свежего ничего не гуглится, всё что нашел — пятилетней и более давности.
Я и сам измерял на многочисленных тестах (кстати, я не раз публиковал их на этом форуме, правда совсем в другом формате — сравнения разных языков. Но для того, чтобы получить результат теста для C++, естественно требовалось в начале определить лучший компилятор для данного теста) и чужие измерения видел (на habr'е помнится была хорошая статья на эту тему пару лет назад).
Общий результат тестов я бы подвёл так: icc и gcc (причём включая MinGW!) приблизительно равны. Не в том смысле, что выдают одинаковый результат, а в том смысле что где-то на половине тестов лучше один, а на второй половине лучше другой.
MSVC уверенно занимает место за ними, правда с существенно худшим результатом. И ещё у него бывают дичайшие баги (причём которые не исправляются годами) как раз в оптимизаторе, способные замедлить работу в сотни раз на некоторых сценариях. Я лично таких находил и демонстрировал на этом форуме.
Clang ещё хуже по оптимизации, чем MSVC. Правда багов у него не видно. Но оно и понятно. Т.е. если взять например тот случай с багом в MSVC, то у gcc и icc в данном коде есть отличная оптимизации. У MSVC есть явная попытка сделать оптимизацию, но с багом (приводящем к просадке на порядки). А у Clang'а на этом же коде просто вообще нет даже попытки сделать оптимизацию (поэтому и багов очевидно быть не может).
Здравствуйте, Marty, Вы писали:
S>>Поэтому, когда речь заходит о коммерческих проектах, в которых сроки и бюджеты не резиновые, C++ уже много десятилетий уверенно обходит чистый C. Сдаются даже разработчики эбмедеда, которые сопротивляются вытеснению чистого С сильнее всего. M>А мы не сдаемся, мы давно поняли, что на йух эту сишечку. Печалит только то, что armcc поддерживает только 11 стандарт, и то — только в той части, за которую отвечает компилятор. Стандартные либы остались от 03го. Но, по мелочам тырим нужное из gcc, благо компилеры во многом совместимы
Ммм, непонятно. ) Какой ещё только 11 стандарт? Я уже давно работаю с ARM исключительно на C++17 и планирую переход на C++20 в ближайшее время. Базовые библиотеки (типа STL) для МК — это да, проблема, но они часто и не нужны вообще. А так я даже Boost прикручивал (некоторые математические библиотеки в заголовочных файлах) без проблем.
Здравствуйте, Denis Ivlev, Вы писали:
DI>Здравствуйте, Marty, Вы писали: DI>Насрать на вас — в массе тут вы никто и звать никак. Вот ты, Александр Мартынов, чем известен?
Это уже прям какой-то комплекс неполноценности во всей красе. )))
Здравствуйте, Denis Ivlev, Вы писали:
DI>>>Честно говорю — глубоко насрать на мнение анонимов, да и сам я здесь аноним. Глубоко ушибленным надо быть чтобы говорить о какой-то репутации среди анонимов.
M>>Вообще-то тут большинство вполне реальные люди
DI>Насрать на вас — в массе тут вы никто и звать никак. Вот ты, Александр Мартынов, чем известен?
_>Clang ещё хуже по оптимизации, чем MSVC. Правда багов у него не видно. Но оно и понятно. Т.е. если взять например тот случай с багом в MSVC, то у gcc и icc в данном коде есть отличная оптимизации. У MSVC есть явная попытка сделать оптимизацию, но с багом (приводящем к просадке на порядки). А у Clang'а на этом же коде просто вообще нет даже попытки сделать оптимизацию (поэтому и багов очевидно быть не может).
_>Вот как-то так.
S>>>Поэтому, когда речь заходит о коммерческих проектах, в которых сроки и бюджеты не резиновые, C++ уже много десятилетий уверенно обходит чистый C. Сдаются даже разработчики эбмедеда, которые сопротивляются вытеснению чистого С сильнее всего. M>>А мы не сдаемся, мы давно поняли, что на йух эту сишечку. Печалит только то, что armcc поддерживает только 11 стандарт, и то — только в той части, за которую отвечает компилятор. Стандартные либы остались от 03го. Но, по мелочам тырим нужное из gcc, благо компилеры во многом совместимы
_>Ммм, непонятно. ) Какой ещё только 11 стандарт? Я уже давно работаю с ARM исключительно на C++17 и планирую переход на C++20 в ближайшее время. Базовые библиотеки (типа STL) для МК — это да, проблема, но они часто и не нужны вообще. А так я даже Boost прикручивал (некоторые математические библиотеки в заголовочных файлах) без проблем.
armcc в составе кейла поддерживает только одинадцатый стандарт
Здравствуйте, Pzz, Вы писали:
Pzz>Я, честно говоря, не очень понимаю, зачем нужны замыкания в языке без сборки мусора. Замыкания нужны для упрощения нотации, и особенно полезны они, когда тема сложная, поскольку позволяют упростить вещи. Переменную со стека просто так в замыкание не унесешь, потому что стек кончится, а замыкание останется.
И вот тут ты можешь открыть для себя семантику перемещения. )
Pzz>Я понимаю, что всякие там умные указатели в C++ отчасти автоматизируют управление памятью. Но она не становится от этого концептуально проще.
Вообще говоря становится.
Pzz>Все равно, программист должен понимать, кто владеет памятью, как это владение передается и т.п. В сочетании со сложностью темы это переполняет мозги.
Это да. Но это в сравнение с управляемыми языками (типа Java и т.п.). А если сравнивать с C, то там точно так же надо знать все эти нюансы.
Т.е. грубо говоря можно явно выделить 3 основных вида управления памятью:
1. Ручное. Программист должен знать о времени жизни всех объектов. И руками расставлять все выделения/освобождения памяти. Тут у нас обитают все старые языки, типа Fortran, Pascal, C и т.п.
2. Автоматическое. Программист должен знать о времени жизни всех объектов и сообщить об этом компилятору с помощью соответствующих типов данных. Всё остальное компилятор делает сам (и он естественно не может ошибиться и поставить лишний вызов free или забыть его где-то поставить). При этом относительно ручного варианта привносится ровно 0 накладных расходов (машинные коды получаются ровно те же самые, только добавляет их компилятор, а не человек). Примерами тут являются такие языки как C++, Rust.
3. Сборщик мусора. Программисту не надо точно знать время жизни всех объектов — сборщик мусора решит проблему сам. Но ценой этого является большой дополнительный расход памяти, проблемы с быстродействием и латентностью.
Так вот, я понимаю, что в зависимости от условий задачи с точки зрения бизнеса может быть выгоднее вариант 2 или вариант 3. Но я совсем не понимаю по каким причинам можно выбрать вариант 1. Разве что только от банального незнания...
Здравствуйте, Marty, Вы писали:
_>>Clang ещё хуже по оптимизации, чем MSVC. Правда багов у него не видно. Но оно и понятно. Т.е. если взять например тот случай с багом в MSVC, то у gcc и icc в данном коде есть отличная оптимизации. У MSVC есть явная попытка сделать оптимизацию, но с багом (приводящем к просадке на порядки). А у Clang'а на этом же коде просто вообще нет даже попытки сделать оптимизацию (поэтому и багов очевидно быть не может). _>>Вот как-то так. M>А ссылки-то будут?
темка про тот баг (там кто-то в дискуссии как раз задал вопрос про Clang и выяснилось что в нём нет ни данного бага, ни оптимизации вообще). Дальше уже лень искать свои сообщения по форуму. Ну а чужие статьи (типа той, что была на Хабре) ты я думаю и сам сможешь найти. )
Здравствуйте, Marty, Вы писали:
M>armcc в составе кейла поддерживает только одинадцатый стандарт
Keil? Кому сейчас нужно это недоразумение, сделанное в те времена, когда мир программирования электроники жил совершенно отдельно от мира "взрослого" программирования? Сейчас для работы с МК без проблем доступны полноценные мощные IDE (QtCreator, VisualStudio и т.д.), а не эти убогие пережитки 90-ых.
Здравствуйте, alex_public, Вы писали:
Pzz>>Я, честно говоря, не очень понимаю, зачем нужны замыкания в языке без сборки мусора. Замыкания нужны для упрощения нотации, и особенно полезны они, когда тема сложная, поскольку позволяют упростить вещи. Переменную со стека просто так в замыкание не унесешь, потому что стек кончится, а замыкание останется.
_>И вот тут ты можешь открыть для себя семантику перемещения. )
Я понимаю про семантику перемещений. Синтаксис, разумеется, не знаю, но стоящие за ней идеи понимаю хорошо.
И вот представь себе, я проектирую сложную структуру данных (структуру не как struct, а структуру, представляющую сложную хрень. Ну, например, географическую карту, или промежуточное представление программы между синтаксическим анализом и кодогенерацией, с чем работает оптимизатор), и мало того, что моя структура данных сама по себе сложна, я еще должен думать про семантику перемещений. Знаешь, извини, моя голова в этом месте будет занята связами в графе, а не владением памятью.
Pzz>>Я понимаю, что всякие там умные указатели в C++ отчасти автоматизируют управление памятью. Но она не становится от этого концептуально проще.
_>Вообще говоря становится.
Вообще говоря, нет. Можно, конечно, делать вид, что присваивание/передача строк по значению работает так же, как присваивание/передача целых чисел по значению. Там же семантика перемещений, ага, лишних аллокаций на куче почти и не видно. Только когда их вдруг становится видно, то получается хуже даже, чем в языке, в котором все руками — потому что в чем дело умному понятно (а дураку и это не понятно, ему же всю жизнь внушали, что внутренний мир объекта его не касается), а что делать не очень-то понятно, внутрь объекта особенно-то и не пускают.
_>Т.е. грубо говоря можно явно выделить 3 основных вида управления памятью:
Давай сойдемся на том, что мы оба квалифицированные люди, и очевидные вещи понимаем одинаково хорошо
