Здравствуйте, so5team, Вы писали:
S>Что такое автомувинг?
S>Зачем вам его обеспечивать вручную?
Автомувинг-это как раз когда мувинг запускается не вручную, а организовывается компилятором. А для этого нужно ряд условий, одно из которых, чтоб компилятор знал, что всё, что будет вызвано, есть noexcept. И для этого приходится их везде расставлять вручную, где нужно, чуть больше чем везде (привет всем, кто про рукопашку в Cи талдычил), и не дай бог где забыть (а это на порядки вероятней, чем забыть сделать free буферу или проверить его размеры)
Здравствуйте, B0FEE664, Вы писали:
BFE>На практике это только один из пунктов проверки. BFE>Помимо этого проводится ещё много каких проверок, в том числе проверка соответствия тестов требованиям, проверка корректности тестов, проверка самого кода, проверка соответствия hardware и software, интеграционное тестирование. И всё это стоит дорого и проводится сторонней организацией.
Здравствуйте, Marty, Вы писали:
M>А я вот думаю, что плюсики ждет ренесанс.
M>У плюсиков была проблема, что раньше а) комитет долго тупил, чтобы добавить необходимые фичи в язык, б) производители компиляторов — коих по факту долго было только два — MSVC и GCC — не торопились реализовывать стандарты, держа в приоритете добавление своих фичь.
"Любую проблему в Фотошоп можно решить добавлением нового слоя — за исключением проблемы слишком большого количества слоев".
С++ обрел новое дыхание после 11-го стандарта, это да. Но после 17-го года стало ясно, что язык распухает и распухает, и конца этому не видно. Причем новые возможности не только не уменьшают сложность языка, а наоборот добавляют ему подводных камней. То есть С++ тоже маргинализируется, причем, судя по тому как разошелся его комитет, достаточно динамично.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, Skorodum, Вы писали:
_>>Для инженеров есть https://julialang.org Взлетит? По тестам уделывает rust S>Кстати да, у нас ученые мужи его используют наряду с Matlab.
Чем обосновывают не питон, не спрашивали? Про matlab понятно, но почему julia вместо питона? Т.е. тоже понятно, но кол-во библиотек и т.д....
Здравствуйте, smeeld, Вы писали:
S>Автомувинг-это как раз когда мувинг запускается не вручную, а организовывается компилятором. А для этого нужно ряд условий, одно из которых, чтоб компилятор знал, что всё, что будет вызвано, есть noexcept. И для этого приходится их везде расставлять вручную, где нужно, чуть больше чем везде (привет всем, кто про рукопашку в Cи талдычил), и не дай бог где забыть (а это на порядки вероятней, чем забыть сделать free буферу или проверить его размеры)
Даже не знаю, как комментировать этот поток боли от непонимания. Компилятору вообще все равно, noexcept у move-операции или нет. Не бросающий move важен для каких-то вещей в стандартной библиотеке, например, в реализации insert-а в std::vector. Но расставлять noexcept-ы вручную приходится только если вы сами ручками выписываете для своего класса move constructor/operator.
Еще есть необходимость расставлять noexcept с точки обеспечения exception-safety. И, местами, с точки зрения подсказок компилятору для оптимизации. Но это все не имеет отношения к "автомувингу".
Так что ваши стенания, во-первых, опровергают ваши утверждения о том, что с современным C++ вы разобрались и, во-вторых, звучат как "слышал звон, но не знаю где он".
PS. А еще в C++17 нужно вручную nodiscard расставлять. А еще, о ужас, начиная с C++11 метку constexpr можно выставить только вручную, компилятор не может сам понять, что функция вычислима в compile-time. Кошмар-кошмар, то ли дело теплая ламповая сишечка, в которой даже пространств имен нет, вообще ни о чем беспокоится не нужно.
хъ
_>А вот скажем если сравнивать с современным C++ язык C или же C++98 (тут у нас похоже и такие любители водятся), то я считаю что плюсов у них не будет в принципе, а минусов множество.
Плюс в общем-то только один, но зачастую перевешивающий все остальное — C API. В виду этого зачастую получаются забавные конструкции — либа внутри плюсовая, поверх нее Сшный АПИ, поверх которого плюсовые врапперы прикладного уровня.
Здравствуйте, Basil2, Вы писали:
B>С++ обрел новое дыхание после 11-го стандарта, это да. Но после 17-го года стало ясно, что язык распухает и распухает, и конца этому не видно. Причем новые возможности не только не уменьшают сложность языка, а наоборот добавляют ему подводных камней. То есть С++ тоже маргинализируется, причем, судя по тому как разошелся его комитет, достаточно динамично.
А что же такого в 17ом так распухло, и, видимо, давит на тебя?
[a, b, c] = std::tuple(32, "hello"s, 13.9)
for (auto&& [key, value] : map) — декомпозиция при объявлении?
std::pair{10, "hello"} вместо std::make_pair(10, "hello")
std::lock_guard guard(mutex) вместо std::lock_guard<std::mutex> guard(mutex) — автоматический вывод параметров шаблонов?
Здравствуйте, kov_serg, Вы писали:
k> Для инженеров есть https://julialang.org Взлетит?
Не взлетит — они придумывают себе несуществующие проблемы и героически их решают. Начиная с феменитивного названия языка:
In particular, do not sexualize the term "Julia" or any other aspects of the project. While "Julia" is a female name in many parts of the world, the programming language is not a person and does not have a gender.
Здравствуйте, smeeld, Вы писали:
S>>Ну и да, пустозвонство местных плюсохейтеров уже просто надоело. Где же, блин, конкретные примеры, которые от вас просишь снова и снова?
S>Как мне избежать обмазывания всего кода (как дерьмом) вот этими костылями S>
А можно поинтересоваться, зачем вы обмазываете? А то, на мой взгляд, польза и необходимость этого находится примерно на уровне обмазывания фекалиями монитора, на котором отображается среда, в которой вы пишете код
Здравствуйте, Patalog, Вы писали:
_>>А вот скажем если сравнивать с современным C++ язык C или же C++98 (тут у нас похоже и такие любители водятся), то я считаю что плюсов у них не будет в принципе, а минусов множество.
P>Плюс в общем-то только один, но зачастую перевешивающий все остальное — C API. В виду этого зачастую получаются забавные конструкции — либа внутри плюсовая, поверх нее Сшный АПИ, поверх которого плюсовые врапперы прикладного уровня.
Это проблема исходит из того, что у C++ нет стандартного ABI и стандартных правил манглинга имен. Это всё тоже хорошо бы стандартизировать, тогда, глядишь, и всякие джавы тягали бы плюсовый код напрямую, без прокладок типа JNI
Здравствуйте, Pzz, Вы писали:
S>>Примеры применения есть тут, но это не самое актуальное, остальное — NDA. S>>Очевидно, что минимальный размер и энергопотребление (и излучение) это всегда плюс.
Pzz>А, так это ваши поделия включают в общественном туалете свет, когда туда входишь, и выключают его в самый интересный момент?
Не, ну ход беспроигрышный — просто взять и вылить ведро говна на голову оппонента. Могу только предположить, что ваши поделия вообще свет не включают
Здравствуйте, Pzz, Вы писали:
M>>Вот поверишь, или нет, я тут как-то налабал кой-какой ДСЛ, там только работа со строками практически и используется. Ну, еще вектора строк, мапы строк, сеты строк, строк и структур классов, содержащих в т.ч. строки. Я точно не успеваю заметить, 0.3 секунды она отрабатывает, или 0.4. И мне на это наплевать. Pzz>И я вот как-то примерно в этом духе написал програмку. Так вот, она, зараза, 10 секунд отрабатывала. А когда я тупо задавил освобождение строк, стала укладываться в полсекунды. 10 секунд как-то несколько раздражает, когда програмку зовут из Makefile.
Кстати, а как задавил? С помощью кастомного аллокатора или как?
Pzz>Кстати, аналог этой програмки, написанный на перле, отрабатывал за те же полсекунды, безо всякой нужды отламывать перловый аллокатор.
Ууу, это значит что у тебя там что-то совсем печальное в коде было. Хотя конечно базовые операции со строками в скриптовых языках всё равно реализованы на C++ и не отличаются по производительности от самого C++. Но если у тебя там было много разнообразных данных (а не одна гигантская строка), то динамический код по любом должен был отставать из-за повышенной косвенности и лишних данных в массивах (если это конечно родные массивы динамического языка, а не что-то типа numpy).
Здравствуйте, Pzz, Вы писали:
_>>Нуу ознакомься ещё и с этим https://en.cppreference.com/w/cpp/string/basic_string/to_string. И естественно тебе никто не мешает перегрузить эту функцию для любого числа своих типов. Pzz>Угу. А потом выясняется, что to_string нужен один для JSON, другой для XML, третий для ASN.1, и все они разные.
Ну добавлю to_string_asn, если очень надо будет и если вдруг почему-то сложно написать преобразование между разными строковыми форматами. В чём проблема то? И какое это имеет отношение к самой интроспекции?
Pzz>В принципе, это хорошо, конечно, что этих дебильных внешних форматов, в которые надо сериализовать, не так уж и много. Но как-то не очень-то generic получается. В общем, серебряной пули опять не получилось.
Причём тут серебряная пуля? Интроспекция — это просто очень нужный в любом современном языке инструмент. Она присутствует уже во множестве языков (правда в большинстве из них она реализована по убогому (в рантайме) и крайне плохо влияет на производительность) и на мой взгляд это сейчас вообще единственный пункт по которому C++ серьёзно уступает другим популярным языкам. Хотя я конечно же полностью согласен с тем, что по быстрому добавлять убогую рантаймую интроспекцию (рефлексию) в C++ было нельзя. И абсолютно верно, что комитет пилит статическую, причём свою, оригинальную. Только уж слишком долго — лучше бы просто содрали целиком с D. Ну ничего, вроде в C++23 уже есть серьёзные шансы на этот прорыв и тогда у C++ не останется откровенно слабых мест.
Здравствуйте, student__, Вы писали:
__>>>При чем тут статическая интроспекция? Pzz>>Пытаюсь понять, насколько она вообще полезна. __>alex_public уже написал — для сериализации данных. К конкретному формату это отношения не имеет.
Причём сериализация — это всего лишь один из многих примеров полезности данной функциональсти. Хотя наверное самый очевидный и нужный почти везде.
Здравствуйте, B0FEE664, Вы писали:
S>>Потому что вы так и не смогли ответить на вопрос о том, каким боком соотносятся виртуальные функции и динамическая аллокация. BFE>Виртуальные функции без динамической аллокации не нужны.
Я же показывал очевидный пример, в котором виртуальные функции используются без динамического выделения памяти. Причём в десктопном ПО (где с памятью нет проблем).
И да, на самом деле они там конечно же не нужны (вне зависимости от видов памяти), но ты расскажи об этом авторам Qt. Или некоторым фанатам динамического полиморфизма на пустом месте из данной темке.
А т.к. при всё убожестве внутренней архитектуры Qt, лучшей GUI библиотеки в индустрии просто не существует, то приходится писать вот такой вот странный код...
Здравствуйте, Skorodum, Вы писали:
_>>Для инженеров есть https://julialang.org Взлетит? По тестам уделывает rust S>Кстати да, у нас ученые мужи его используют наряду с Matlab.
Язык Julia вроде появился (кстати, если кто вдруг не в курсе, то Jupyter=JUlia+PYThon+R) как попытка писать одновременно удобный (как в Питоне) и производительный (как в C++) научный код. Однако именно этой связке он и проигрывает в реальности, т.к. не может превзойти каждый из них в их главном предназначение.
