Здравствуйте, alex_public, Вы писали:
_>Кстати, а как задавил? С помощью кастомного аллокатора или как?
Шоб я помнил...
_>Ууу, это значит что у тебя там что-то совсем печальное в коде было. Хотя конечно базовые операции со строками в скриптовых языках всё равно реализованы на C++ и не отличаются по производительности от самого C++. Но если у тебя там было много разнообразных данных (а не одна гигантская строка), то динамический код по любом должен был отставать из-за повышенной косвенности и лишних данных в массивах (если это конечно родные массивы динамического языка, а не что-то типа numpy).
У перла, возможно, до освобождения просто не доходило.
Здравствуйте, alex_public, Вы писали:
S>>>Потому что вы так и не смогли ответить на вопрос о том, каким боком соотносятся виртуальные функции и динамическая аллокация. BFE>>Виртуальные функции без динамической аллокации не нужны.
_>Я же показывал очевидный пример, в котором виртуальные функции используются без динамического выделения памяти. Причём в десктопном ПО (где с памятью нет проблем).
_>И да, на самом деле они там конечно же не нужны (вне зависимости от видов памяти), но ты расскажи об этом авторам Qt. Или некоторым фанатам динамического полиморфизма на пустом месте из данной темке.
_>А т.к. при всё убожестве внутренней архитектуры Qt, лучшей GUI библиотеки в индустрии просто не существует, то приходится писать вот такой вот странный код...
Здравствуйте, alex_public, Вы писали:
M>>>Вот поверишь, или нет, я тут как-то налабал кой-какой ДСЛ, там только работа со строками практически и используется. Ну, еще вектора строк, мапы строк, сеты строк, строк и структур классов, содержащих в т.ч. строки. Я точно не успеваю заметить, 0.3 секунды она отрабатывает, или 0.4. И мне на это наплевать. Pzz>>И я вот как-то примерно в этом духе написал програмку. Так вот, она, зараза, 10 секунд отрабатывала. А когда я тупо задавил освобождение строк, стала укладываться в полсекунды. 10 секунд как-то несколько раздражает, когда програмку зовут из Makefile.
_>Кстати, а как задавил? С помощью кастомного аллокатора или как?
Pzz>>Кстати, аналог этой програмки, написанный на перле, отрабатывал за те же полсекунды, безо всякой нужды отламывать перловый аллокатор.
_>Ууу, это значит что у тебя там что-то совсем печальное в коде было. Хотя конечно базовые операции со строками в скриптовых языках всё равно реализованы на C++ и не отличаются по производительности от самого C++. Но если у тебя там было много разнообразных данных (а не одна гигантская строка), то динамический код по любом должен был отставать из-за повышенной косвенности и лишних данных в массивах (если это конечно родные массивы динамического языка, а не что-то типа numpy).
Ну, на пёрле это мог быть один большой регэксп, например. На грани того, что еще может быть написан человеком. Прекомпилируешь его, потом натравливаешь на данные — профит. Тут плюсики и в правду не нужны
_>>Ууу, это значит что у тебя там что-то совсем печальное в коде было. Хотя конечно базовые операции со строками в скриптовых языках всё равно реализованы на C++ и не отличаются по производительности от самого C++. Но если у тебя там было много разнообразных данных (а не одна гигантская строка), то динамический код по любом должен был отставать из-за повышенной косвенности и лишних данных в массивах (если это конечно родные массивы динамического языка, а не что-то типа numpy).
Pzz>У перла, возможно, до освобождения просто не доходило.
Наверное. Думаю, куча прибивалась системой при выходе. Но это не плюс языка
Здравствуйте, Anton Batenev, Вы писали:
k>> Для инженеров есть https://julialang.org Взлетит?
AB>Не взлетит — они придумывают себе несуществующие проблемы и героически их решают. Начиная с феменитивного названия языка:
AB>
AB>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.
Зато у них небось феминистки на ролях главных инженеров, и правительство делает скидки по налогам за трудоустройство убогих.
Это дорогого стоит
Здравствуйте, Basil2, Вы писали:
B>А о том, что С++ повторяет судьбу С и постепенно сужается в узкие вышеозначенные области. Причем последние две области будут, скорее всего, относительно динамично переползать на Go и Rust. И только графика и ML, в силу мощных устоявшихся библиотек, еще долго будут тащить за собой C++.
Здравствуйте, smeeld, Вы писали:
S>Всё ровно наоборот, судя по тому, что вижу вокруг (а это вполне жирные продуктовые софтверные корпорации), С++ отползает в не просто маргинальную нишу, а становится, так называемой, некротой, кодом, который поддерживается, но не развивается. Всё новое и перспективное пишут на Go, lisp подобных, Java, python. За предложение писать что-то с нуля на плюсах посмеиваюся и крутят у виска. Это из реальной реальности, а не нафантазированной, как у Вас.
Вот смешат меня подобные забавные товарищи. Они думают, что круто троллят всех, а на самом деле лишь демонстрируют своё дикое невежество.
В IT индустрии у языков программирования есть вполне однозначные ниши. И не бывает в принципе, чтобы язык из одной ниши вытеснил язык из другой. Вот внутри одной ниши этот процесс происходит постоянно (например когда-то царившие в нише скриптовых языков Perl и PHP, сейчас явно заменены на Python и JS). Так вот в нише универсальных (не заточенных под одну платформу/железо) системных языков, в которой сейчас царит C++, в данный момент вообще очень маленький выбор — есть всего 3 языка, полноценно решающих эту задачу. А именно: C (устаревший язык, на котором написаны в основном библиотеки и продукты с длинной историей), C++ (текущий лидер ниши, на котором написаны почти все компоненты современной инфраструктуры) и Rust (возможное потенциальное будущее ниши, если сумеет не остановиться в развитии и занять место C++).
Т.е. если когда-нибудь C++ и потеряет свои лидирующие позиции, то это произойдёт из-за его замены Rust'ом (который кстати является как раз развитием идей современного C++, только пошёл ещё дальше, жёстко зафиксировав в синтаксис то, что в современном C++ считается негласными правилами написания нормального ПО), а не "Go, lisp подобных, Java, python".
Да, а если какой-нибудь неадекват захочет вдруг пофантазировать на тему того, что в будущем пропадёт сама ниша системных яызков, то я даже не буду перечислять бесконечные ряды инфраструктурного ПО, а сразу зайду с банальных (но от этого не становящихся слабее) козырей: спрошу, а на каком языке будет написан рантайм (JVM, CLR, CPython, V8 и т.п.) его языка будущего?
S>С сишечкой как раз ничего не случится, она как была, так и будет занимать ключевую роль в разработке системного промышленного софта, ибо оракелы, линуксы и всё-всё, что крутит индустрию-это на 95% именно Си, что бы тут всякие неадекваты не пытались доказать, ибо факты и статистика вещь упрямая.
Ты это, давай для начала предложишь адекватную замену, написанную на C, хотя бы тому самому приложению, в котором ты набивал эти свои больные фантазии для данного форума. Тогда и поговорим, о 95% ПО крутящего индустрию.
__>>>>При чем тут статическая интроспекция? Pzz>>>Пытаюсь понять, насколько она вообще полезна. __>>alex_public уже написал — для сериализации данных. К конкретному формату это отношения не имеет.
_>Причём сериализация — это всего лишь один из многих примеров полезности данной функциональсти. Хотя наверное самый очевидный и нужный почти везде.
Это самый холиварный пример использования интроспекции (классный "повод поболтать"). Используй уже сейчас генераторы на основе cppast или голой libTooling и получишь тот же результат, только более эффективный. Для сериализации на основе интроспекции нужна POD структура, в которой будут хранится эти данные, а если ее нет, или одно сообщение генерируется на основе нескольких, или часть сериализуемых полей вычисляется тут от интроспеции толку будет мало. Кроме того, сериализацию полезно делать на основе аттрибутов. Хоть одно предложение по интроспекции умеет работать с аттрибутами?
IMHO, для статической интроспекции в C++ полезно сделать отдельный стандартизованный инструмент для кодогенерации на основе libTooling или подобного. Он и гибче будет и язык усложнять не станет.
Впрочем, для примитивных случаев, типа отладочного вывода имен enum вместо чисел — довольно удобная штука.
P.S. В языках с интроспекцией для таких задач, кстати, также используют в том числе и кодогенерацию (на Android, например).
Здравствуйте, alex_public, Вы писали:
_>А именно: C (устаревший язык, на котором написаны в основном библиотеки и продукты с длинной историей), C++ (текущий лидер ниши, на котором написаны почти все компоненты современной инфраструктуры) и Rust (возможное потенциальное будущее ниши, если сумеет не остановиться в развитии и занять место C++).
Формально говоря, есть еще и Ada. На котором реального кода для embedded-а и системщины, полагаю, написано и эксплуатируется пока сильно больше, чем на Rust-е.
Здравствуйте, Masterspline, Вы писали:
M>IMHO, для статической интроспекции в C++ полезно сделать отдельный стандартизованный инструмент для кодогенерации на основе libTooling или подобного. Он и гибче будет и язык усложнять не станет.
Тут либо "стандартизированный", либо "на основе", одно из двух.
Здравствуйте, Anton Batenev, Вы писали:
AB>Не взлетит — они придумывают себе несуществующие проблемы и героически их решают. Начиная с феменитивного названия языка:
Ну не совсем. Основная проблема, которую хотят решить, как я понял, — необходимость использовния нескольких ЯП в околонаучных расчетах. Типа, ученые не хотят связываться с программистами и программистскими ЯП типа С++, а софт хотят писать и для расчетов и чтобы грамотно было, а не вычислил->опубликовал->выкинул. Чтобы была скорость Fortran, и простота использования Matlab/Python, и современная система типов и вообще современные фичи компилируемых ЯП. Другое дело, что для этой проблемы адекватного технического решения может не существовать.
_>Т.е. если когда-нибудь C++ и потеряет свои лидирующие позиции
Где Вы увидели лидирующие позиции C++? Во всех рейтингах которые только есть он стоит после Java, Python, Си. Причём в числах, С++ от Cи отстаёт в два раза.
Здравствуйте, alex_public, Вы писали:
_>Да, а если какой-нибудь неадекват захочет вдруг пофантазировать на тему того, что в будущем пропадёт сама ниша системных яызков, то я даже не буду перечислять бесконечные ряды инфраструктурного ПО, а сразу зайду с банальных (но от этого не становящихся слабее) козырей: спрошу, а на каком языке будет написан рантайм (JVM, CLR, CPython, V8 и т.п.) его языка будущего?
Рантайм Go написан, чуть менее, чем полностью, на Go.
Здравствуйте, Sharov, Вы писали:
S>Чем обосновывают не питон, не спрашивали? Про matlab понятно, но почему julia вместо питона? Т.е. тоже понятно, но кол-во библиотек и т.д....
Питон у нас используется очень активно для мелких прикладных задач, для отработки алгоритмов можно использовать любой разумный инструмент, в основном это Matlab, но один ученый предпочитает julia. Почему бы и нет? Адаптировать основной фреймворк и CI для поддержки julia (Win/OSX/Linux) заняло примерно 2 недели, по деньгам это, наверное, сравнимо с лицензией на Matlab. Про количество библиотек ничего не скажу, т.к. сам ничего активно не делаю в этой области.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, kaa.python, Вы писали:
KP>>Вот и в нише системной разработки, своего рода последнего оплота C++, есть интересные подвижки: https://twitter.com/jdub/status/1192535757291847681?s=19
Pzz>Мда, Микрософт постепенно превращается в IBM.
А можно уточнить что именно имелось ввиду? При всей моей любви к C++ я не могу не признать разумность замены C++ на Rust, когда есть такая возможность.
Здравствуйте, Marty, Вы писали:
M>Но вот например, забагованное до нельзя поделие — GCC — написано от и до на чистой сишечке, а качественный компилятор с человеческим лицом (clang/llvm) — на C++
Ну вообще-то если сравнить количество багов в багзиле с коэффицентом времени
жизни обоих кодовых баз, то сложно сказать кто из них более забагованный.
Плюс gcc давно переехал на C++, погуглите "GCC's move to C++"
Здравствуйте, kaa.python, Вы писали:
Pzz>>Мда, Микрософт постепенно превращается в IBM.
KP>А можно уточнить что именно имелось ввиду? При всей моей любви к C++ я не могу не признать разумность замены C++ на Rust, когда есть такая возможность.
Микрософт раньше использовал только все свое. Теперь у них движок бровсера от гугля, язык программирования от мозилы, на серверах у них линух стоит, и исходники, поди, в гите держат.
