Re[25]: А С++ то схлопывается...
От: Denis Ivlev  
Дата: 03.11.19 12:04
Оценка: -1
Здравствуйте, CreatorCray, Вы писали:

CC>Ты походу штанеля забыл снять когда хотел на нас насрать, потому и капает оттуда.


Взрослая публика — взрослая аргументация (нет)
Re[23]: А С++ то схлопывается...
От: Denis Ivlev  
Дата: 03.11.19 12:04
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Страдай!


Ок
Re[27]: А С++ то схлопывается...
От: Denis Ivlev  
Дата: 03.11.19 12:06
Оценка:
Здравствуйте, CreatorCray, Вы писали:

DI>> Все в белую, интересуют мидлы с прицелом на сеньора, готов предложить от 200 на руки.

CC>Так уж и быть тут я удержусь от подколок.

Не сдерживай себя
Re[23]: А С++ то схлопывается...
От: Denis Ivlev  
Дата: 03.11.19 12:06
Оценка:
Здравствуйте, CreatorCray, Вы писали:

DI>>Омг, ты еще одаренней, чем мне сначала показалось

CC>Тебе много чего кажется
CC>Доклад видимо тоже галлюцинация

Ок
Re[23]: А С++ то схлопывается...
От: Denis Ivlev  
Дата: 03.11.19 12:07
Оценка:
Здравствуйте, Pzz, Вы писали:

DI>>Про пользу для себя от данного форума я скоро раскрою отдельным сообщением, следите за новостями.


Pzz>Думаешь, нам шибко интересно?


Еще один прискакал рассказать мне как я ему безразличен
Re[4]: А С++ то схлопывается...
От: Basil2 Россия https://starostin.msk.ru
Дата: 03.11.19 12:39
Оценка:
Здравствуйте, yoyoyo, Вы писали:

B>>Хорош, но я надеюсь переползти на Rust.


Y>Думаю, что в будущем, когда С++ схлопнется еще сильнее, то что от него останется будет больше, чем то во что разрастается Rust. Если говорить про сегодняшний день, вакансий на Rust меньше чем вакансий на Delphi/Pascal. Мы на работе пытались некоторые сервисы писать на Rust, но потом отказались от этой идеи, слишком высок уровень вхождения, а тратить полгода на то, чтобы человек набил руку никто не хочет. В итоге все переписали на Go на котором уже через неделю можно программировать на приемлемом уровне.


С какого языка вы переходили? Сколько лет опыта было у переходивших?
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Re[28]: А С++ то схлопывается...
От: so5team https://stiffstream.com
Дата: 03.11.19 12:47
Оценка: +6
Здравствуйте, Denis Ivlev, Вы писали:

S>>С производительностью.


DI>Чего?


А вы с какой целью интересуетесь?

S>>Так с кем встречаться-то? С вымышленным Денисом Ивлиевым?


DI>Игра с голубем в шахматы становится весьма скучной.


Вполне предскауемо повторяете славный путь smeeld.

S>>Анонимный нонейм может что-то предложить? Рассмешили.


DI>Посмейся, для адекватных людей я сказал достаточно — пишите, кому интересно.


Думаете, что адекватных людей заинтересует предложение от неизвестно какой конторы, высказанное неизвестно кем с замашками гопника?

Так все-таки, на какой доклад на этом Highload++ стоит обратить внимание. Очень уж хочется увидеть, как будет делать доклад человек, позволяющий вести себя подобным образом здесь.
Re[19]: А С++ то схлопывается...
От: alex_public  
Дата: 03.11.19 12:52
Оценка:
Здравствуйте, Denis Ivlev, Вы писали:

_>>Кстати, в контексте данной дискуссии довольно забавно, что там не мало докладов по C++ тематике. Я и не думал, что C++ имеет существенное распространение в данной области за пределами таких специфических монстриков как Гугл, Яндекс и т.п.

DI>Это какие? За плюсы традиционно Леха Милодивов с Кликхаусом топит, но он как раз из Яндекса

Ну ссылка то на страницу есть выше. Открой её, нажми Ctrl+F, набери C++ и посмотри число вхождений...
Re[17]: А С++ то схлопывается...
От: alex_public  
Дата: 03.11.19 12:57
Оценка:
Здравствуйте, Pzz, Вы писали:

M>>Например, в зависимости от используемых оптимизаций оптимальными могут быть разные варианты

Pzz>Тут народ призывает целые числа хранить в обертках, которые при каждом присваивании проверяют диапазон и исключениями кидаются. А ты говоришь про какой-то очень тонкий файнтьюнинг, эффект от которого не на каждом бенчмарке заметишь.
Pzz>Все-таки, очень, очень разные у людей представления об оптимизации

Ну тут всё же надо однозначно отметить, что у C++ (а так же у Rust, D и им подобным) цена такой обёртки нулевая. Т.е. нет никаких накладных расходов (проверка — это не накладные расходы, т.к. она будет в любом случае на любых языка, только просто написана руками) от того факта, что используется специальный тип, а не int. А вот скажем на языках типа Java такую автоматическую проверку просто невозможно сделать без накладных расходов, поэтому там или всё руками или очень медленно.
Re[10]: А С++ то схлопывается...
От: alex_public  
Дата: 03.11.19 13:06
Оценка: 1 (1) +1
Здравствуйте, Marty, Вы писали:

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

M>А можно ссылочки на сравнения? А то что-то свежего ничего не гуглится, всё что нашел — пятилетней и более давности.

Я и сам измерял на многочисленных тестах (кстати, я не раз публиковал их на этом форуме, правда совсем в другом формате — сравнения разных языков. Но для того, чтобы получить результат теста для C++, естественно требовалось в начале определить лучший компилятор для данного теста) и чужие измерения видел (на habr'е помнится была хорошая статья на эту тему пару лет назад).

Общий результат тестов я бы подвёл так: icc и gcc (причём включая MinGW!) приблизительно равны. Не в том смысле, что выдают одинаковый результат, а в том смысле что где-то на половине тестов лучше один, а на второй половине лучше другой.

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

Clang ещё хуже по оптимизации, чем MSVC. Правда багов у него не видно. Но оно и понятно. Т.е. если взять например тот случай с багом в MSVC, то у gcc и icc в данном коде есть отличная оптимизации. У MSVC есть явная попытка сделать оптимизацию, но с багом (приводящем к просадке на порядки). А у Clang'а на этом же коде просто вообще нет даже попытки сделать оптимизацию (поэтому и багов очевидно быть не может).

Вот как-то так.
Re[12]: А С++ то схлопывается...
От: alex_public  
Дата: 03.11.19 13:13
Оценка:
Здравствуйте, Marty, Вы писали:

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

M>А мы не сдаемся, мы давно поняли, что на йух эту сишечку. Печалит только то, что armcc поддерживает только 11 стандарт, и то — только в той части, за которую отвечает компилятор. Стандартные либы остались от 03го. Но, по мелочам тырим нужное из gcc, благо компилеры во многом совместимы

Ммм, непонятно. ) Какой ещё только 11 стандарт? Я уже давно работаю с ARM исключительно на C++17 и планирую переход на C++20 в ближайшее время. Базовые библиотеки (типа STL) для МК — это да, проблема, но они часто и не нужны вообще. А так я даже Boost прикручивал (некоторые математические библиотеки в заголовочных файлах) без проблем.
Re[22]: А С++ то схлопывается...
От: alex_public  
Дата: 03.11.19 13:21
Оценка: +2
Здравствуйте, Denis Ivlev, Вы писали:

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

DI>Насрать на вас — в массе тут вы никто и звать никак. Вот ты, Александр Мартынов, чем известен?

Это уже прям какой-то комплекс неполноценности во всей красе. )))
Re[22]: А С++ то схлопывается...
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 03.11.19 13:25
Оценка:
Здравствуйте, Denis Ivlev, Вы писали:

DI>>>Честно говорю — глубоко насрать на мнение анонимов, да и сам я здесь аноним. Глубоко ушибленным надо быть чтобы говорить о какой-то репутации среди анонимов.


M>>Вообще-то тут большинство вполне реальные люди


DI>Насрать на вас — в массе тут вы никто и звать никак. Вот ты, Александр Мартынов, чем известен?


О, опять культура попёрла
Маньяк Робокряк колесит по городу
Re[21]: А С++ то схлопывается...
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 03.11.19 13:26
Оценка:
Здравствуйте, CreatorCray, Вы писали:

M>>Кстати, Артемка, как профи — вроде вполне таки.

CC>А в чём он хоть профи то?

Хз, вроде как Вовка Морковка примерно
Маньяк Робокряк колесит по городу
Re[11]: А С++ то схлопывается...
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 03.11.19 13:28
Оценка:
Здравствуйте, alex_public, Вы писали:


_>Clang ещё хуже по оптимизации, чем MSVC. Правда багов у него не видно. Но оно и понятно. Т.е. если взять например тот случай с багом в MSVC, то у gcc и icc в данном коде есть отличная оптимизации. У MSVC есть явная попытка сделать оптимизацию, но с багом (приводящем к просадке на порядки). А у Clang'а на этом же коде просто вообще нет даже попытки сделать оптимизацию (поэтому и багов очевидно быть не может).


_>Вот как-то так.


А ссылки-то будут?
Маньяк Робокряк колесит по городу
Re[13]: А С++ то схлопывается...
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 03.11.19 13:30
Оценка:
Здравствуйте, alex_public, Вы писали:


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

M>>А мы не сдаемся, мы давно поняли, что на йух эту сишечку. Печалит только то, что armcc поддерживает только 11 стандарт, и то — только в той части, за которую отвечает компилятор. Стандартные либы остались от 03го. Но, по мелочам тырим нужное из gcc, благо компилеры во многом совместимы

_>Ммм, непонятно. ) Какой ещё только 11 стандарт? Я уже давно работаю с ARM исключительно на C++17 и планирую переход на C++20 в ближайшее время. Базовые библиотеки (типа STL) для МК — это да, проблема, но они часто и не нужны вообще. А так я даже Boost прикручивал (некоторые математические библиотеки в заголовочных файлах) без проблем.


armcc в составе кейла поддерживает только одинадцатый стандарт
Маньяк Робокряк колесит по городу
Re[18]: А С++ то схлопывается...
От: alex_public  
Дата: 03.11.19 13:41
Оценка: +1
Здравствуйте, Pzz, Вы писали:

Pzz>Я, честно говоря, не очень понимаю, зачем нужны замыкания в языке без сборки мусора. Замыкания нужны для упрощения нотации, и особенно полезны они, когда тема сложная, поскольку позволяют упростить вещи. Переменную со стека просто так в замыкание не унесешь, потому что стек кончится, а замыкание останется.


И вот тут ты можешь открыть для себя семантику перемещения. )

Pzz>Я понимаю, что всякие там умные указатели в C++ отчасти автоматизируют управление памятью. Но она не становится от этого концептуально проще.


Вообще говоря становится.

Pzz>Все равно, программист должен понимать, кто владеет памятью, как это владение передается и т.п. В сочетании со сложностью темы это переполняет мозги.


Это да. Но это в сравнение с управляемыми языками (типа Java и т.п.). А если сравнивать с C, то там точно так же надо знать все эти нюансы.

Т.е. грубо говоря можно явно выделить 3 основных вида управления памятью:

1. Ручное. Программист должен знать о времени жизни всех объектов. И руками расставлять все выделения/освобождения памяти. Тут у нас обитают все старые языки, типа Fortran, Pascal, C и т.п.

2. Автоматическое. Программист должен знать о времени жизни всех объектов и сообщить об этом компилятору с помощью соответствующих типов данных. Всё остальное компилятор делает сам (и он естественно не может ошибиться и поставить лишний вызов free или забыть его где-то поставить). При этом относительно ручного варианта привносится ровно 0 накладных расходов (машинные коды получаются ровно те же самые, только добавляет их компилятор, а не человек). Примерами тут являются такие языки как C++, Rust.

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

Так вот, я понимаю, что в зависимости от условий задачи с точки зрения бизнеса может быть выгоднее вариант 2 или вариант 3. Но я совсем не понимаю по каким причинам можно выбрать вариант 1. Разве что только от банального незнания...
Re[12]: А С++ то схлопывается...
От: alex_public  
Дата: 03.11.19 13:59
Оценка:
Здравствуйте, Marty, Вы писали:

_>>Clang ещё хуже по оптимизации, чем MSVC. Правда багов у него не видно. Но оно и понятно. Т.е. если взять например тот случай с багом в MSVC, то у gcc и icc в данном коде есть отличная оптимизации. У MSVC есть явная попытка сделать оптимизацию, но с багом (приводящем к просадке на порядки). А у Clang'а на этом же коде просто вообще нет даже попытки сделать оптимизацию (поэтому и багов очевидно быть не может).

_>>Вот как-то так.
M>А ссылки-то будут?

Ну вот https://rsdn.org/forum/flame.comp/6729734
Автор: alex_public
Дата: 20.03.17
пример одного из тестов. А вот https://rsdn.org/forum/cpp/6722631
Автор: alex_public
Дата: 11.03.17
темка про тот баг (там кто-то в дискуссии как раз задал вопрос про Clang и выяснилось что в нём нет ни данного бага, ни оптимизации вообще). Дальше уже лень искать свои сообщения по форуму. Ну а чужие статьи (типа той, что была на Хабре) ты я думаю и сам сможешь найти. )
Re[14]: А С++ то схлопывается...
От: alex_public  
Дата: 03.11.19 14:02
Оценка: +1
Здравствуйте, Marty, Вы писали:

M>armcc в составе кейла поддерживает только одинадцатый стандарт


Keil? Кому сейчас нужно это недоразумение, сделанное в те времена, когда мир программирования электроники жил совершенно отдельно от мира "взрослого" программирования? Сейчас для работы с МК без проблем доступны полноценные мощные IDE (QtCreator, VisualStudio и т.д.), а не эти убогие пережитки 90-ых.
Re[19]: А С++ то схлопывается...
От: Pzz Россия https://github.com/alexpevzner
Дата: 03.11.19 14:29
Оценка:
Здравствуйте, alex_public, Вы писали:

Pzz>>Я, честно говоря, не очень понимаю, зачем нужны замыкания в языке без сборки мусора. Замыкания нужны для упрощения нотации, и особенно полезны они, когда тема сложная, поскольку позволяют упростить вещи. Переменную со стека просто так в замыкание не унесешь, потому что стек кончится, а замыкание останется.


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


Я понимаю про семантику перемещений. Синтаксис, разумеется, не знаю, но стоящие за ней идеи понимаю хорошо.

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

Pzz>>Я понимаю, что всякие там умные указатели в C++ отчасти автоматизируют управление памятью. Но она не становится от этого концептуально проще.


_>Вообще говоря становится.


Вообще говоря, нет. Можно, конечно, делать вид, что присваивание/передача строк по значению работает так же, как присваивание/передача целых чисел по значению. Там же семантика перемещений, ага, лишних аллокаций на куче почти и не видно. Только когда их вдруг становится видно, то получается хуже даже, чем в языке, в котором все руками — потому что в чем дело умному понятно (а дураку и это не понятно, ему же всю жизнь внушали, что внутренний мир объекта его не касается), а что делать не очень-то понятно, внутрь объекта особенно-то и не пускают.

_>Т.е. грубо говоря можно явно выделить 3 основных вида управления памятью:


Давай сойдемся на том, что мы оба квалифицированные люди, и очевидные вещи понимаем одинаково хорошо
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.