LINUX.ORG.RU

Рефлексия в плюсах - обойти все поля структуры в рантайм?

 ,


2

3

Хочется объявить поля в структуре/классе так, что бы потом иметь возможность обойти их в рантайм/иметь возможность обращаться по имени в рантайм. Ограничения:

  1. стандарт не свежее с++-17

  2. всякие толстые сторонние либы а-ля буст не подходят

  3. задание полей должно быть максимально простым, желательно что бы каждое поле упоминалось не больше одного раза.

  4. необходимо иметь возможность довешивать к полям комментарии (можно статические) и потом иметь к ним доступ в рантайм.

Хочется че то такое:

struct A{
    BEGIN();  // некий макрос
    int PAR(x, 0, "число рыбов");
    std::array<double, 2> PAR(y, {0., 0.}, "координаты главрыбы");
    END();
};

но как это сделать фантазии не хватает (есть варианты, но они все ужасно костыльные).

Можно легко сделать что то вроде

struct A{
   double x = 0;
   std::array<double, 2> y = {0., 0.};
   A(){ TABLE(x, "число рыбов")(y, "координаты главрыбы"); }
};

но нарушается п.3.

Можно на худой конец сделать

struct A{
   int x = 0; ///< число рыбов
   std::array<double, 2> y = {0., 0.}; ///< координаты главрыбы
};

и перед сборкой обрабатывать это питоньей утилитой, генерить хидер с какой то оберткой и его инклюдить, но выглядит несколько радикально…

Как бы такое сделать Ъ? @annulen, @fsb4000, @monk, @bugfixer


UPD. Решил чуть подробнее расписать зачем это нужно и что должно выйти в итоге. Есть приложение (HPC) в котором есть вычислительное ядро на плюсах. В ядре есть класс Model со 100500 параметров (входных и выходных содержащих результаты расчета) которые имеют значения по умолчанию, но нужно мочь их менять через конфиги/аргументы командной строки, куда то записывать (в json) и т.д. Если забиндить ядро в питон (через SWIG) то это все делается довольно легко, но такой биндинг не всегда возможен. Хочется иметь аналогичную функциональность на чистых C++. Т.е. в C++ я изначально пишу:

class Model{
...
   double J = 1;      ///< exchange integral
   double T = 2;      ///< temperature
   double c = 0.1;    ///< concentration
   double dt = 1e-2;  ///< time step
   double t = 0;      ///< time
...
   
   void init();
   void calc();
};

Пускач в питоне

model = Model()
config(model)  # это функция из моей либы накатывающая параметры из командной строки
model.init()
while model.t<t_max: model.calc()

при запуске я могу писать что то вроде

./run.py T=4 dt=1e3

хочется мочь писать аналогичный пуска на плюсах.

Для этого необходимо и достаточно иметь в плюсах некую обертку для модели которая:

  1. может перечислить все параметры
  2. может вернуть значение любого параметра в виде строки
  3. может задать значение любого параметра из строки
  4. бонусом (то чего в питоне пока нет, но хочется и туда пробросить) - может вернуть комментарий к любому параметру
★★★★★

Последнее исправление: AntonI (всего исправлений: 7)
Ответ на: комментарий от AntonI

Но ТЗ же адиеты пишут, которые ничего не знают и не понимают, да-да.

чо? Тебе прямо дают ТЗ и никаких шагов в сторону нельзя делать? Офигеть конторка. Страдай, чо.

машина на которой будет развертывание анально огорожена, софт собирается из сырцов, никаких дополнительных пакетов поставить низя, и конпелятор хорошо если не gcc4.8 а посвежее.

Вот о таком надо заранее узнать и не подходить к такой говноконторе на километр. А то потом геморроя не оберёшься. Надеюсь, тебе ОЧЕНЬ хорошо за это всё платят.

hateyoufeel ★★★★★
()
Ответ на: комментарий от Eulenspiegel

Дяденька, Вы не устали тут клоунаду разводить? Если у Вас проблемы с пониманием написанного, м.б. Вам для начала стоит их решить а потом уже что то комментировать?

AntonI ★★★★★
() автор топика
Ответ на: комментарий от guyvernk
Ответ на: комментарий от hateyoufeel

Я не очень понимаю любовь плюсистов к старым стандартам, если можно использовать новые.

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

Это не говоря про то, что поддержка самого свежего стандарта в самых свежих версиях компиляторов может сильно отличаться и то, что собирается VC++ не будет собираться GCC или Clang-ом (или наоборот), или же будет, но будет работать медленнее в разы, или будет натыкаться на баги в компиляторе.

В общем, это трудно объяснить празношатающимся по форумам, но жизнь такова, что в мире C++ по целому ряду как объективных, так и субъективных причин часть проектов принципиально живет на более старых стандартах (вроде C++17, C++14 или даже на C++11, а кто-то наверняка еще и на C++98/03). Такова жизнь.

eao197 ★★★★★
()
Ответ на: комментарий от aol

куте нет. Одна из причин изобретательства лисапедов на нашей полянке - очень часто на целевой машине развертывание чего то толстого сопряжено с кучей проблем;-(

Я пока что сильно задумался в сторону 3го варианта с предобработкой исходника своей простенькой утилитой учитывающей магические комментарии… это наверное можно считать куте вэем?;-)

AntonI ★★★★★
() автор топика
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от AntonI

то наверное можно считать куте вэем

типа того, да )) свой moc )

ну, на кишки copperspice тоже не помешает взглянуть, наверное. Они как-то решили всё, что даёт moc только силами компилятора и шаблонов. Никаких гарантий, что там будет меньше магии, конечно, не даю ))

aol ★★★★★
()

обрабатывать это питоньей утилитой, генерить хидер с какой то оберткой и его инклюдить

Чего ведь не придумают, лишь бы M4 не использовать :) Все удивлялся, нафига собирать плюсы тянут то жабу, то питон. В Unreal Engine вообще C# притащили. Ах вот для чего: истинные одепты избегания RTTI обречены переизобретать его при помощи костылей. Но да, кто тебя останавливает от написания этой твоей генерированной «DSL скриптухи» на плюсах, в т.ч. собственно генератора… м?

anonymous
()
Ответ на: комментарий от AntonI

Но меня захватила мысль о магических комментариях и внешней утилите… остановите меня!!!111;-)

Зачем так усложнять.

На xml/json/toml описал в отдельном файле, аля

<my_code_generator>
  <struct name="foo">
    <field name="x" type="int" default_value="3.1415926" comment="x is x" long_comment="x foo foo foo foo foo" .../>
    <extend>
      int calc();
    </extend>
...

и на python сгенерил по jinja2 шаблону нужные файлы.

З.Ы.: Ну нет пока в плюсах макросов уровня rust.

AlexVR ★★★★★
()
Ответ на: комментарий от AlexVR

Не. В данном случае первичен именно плюсовый код, пользователь пишет именно его а не какой то XML. В XML же дублировать описание которое уже есть в плюсовом коде это нарушать DRY, это неудобно

AntonI ★★★★★
() автор топика

Есть приложение (HPC) в котором есть вычислительное ядро на плюсах. В ядре есть класс Model со 100500 параметров

Задействуй toml в качестве конфига. В нём можно комментарии писать. Из того что пробовал, он больше всего мне понравился для подобного рода задач. Посмотри: https://github.com/marzer/tomlplusplus

Не отменяет предыдущего комментария про генерацию кода. На разу создашь default_config.toml.

AlexVR ★★★★★
()
Ответ на: комментарий от AntonI

В данном случае первичен именно плюсовый код

Поменяй направление.

Тебе надо по простому описанию пачку кода:

  • и объявление структуры,
  • и задание дефотных значений отличных от нуля,
  • и функции доступа к полям по имени,
  • и вывод комментария по имени,
  • и перечисление всех полей

Парсить комментарии объявления структуры, что получить пачку новых С++ файлов, который ты будешь как-то инклудить и компилировать. И всё это только ради того, что бы оставить призрачный struct Foo {int x...?

Отдели описание от кода.

В XML же дублировать описание которое уже есть в плюсовом коде это нарушать DRY

Генерь код по описанию. Весь. Включая описание структуры. Выше у меня получилось, что описание структуры такой же шаг, как и все остальные.

AlexVR ★★★★★
()
Ответ на: комментарий от AntonI

Для конфигов как правило достаточно формата вида

Как только появляется сторонний пользователь, становиться нужным описание конфига. В toml комментарии есть, в json - на уровне расширений или костылей.

AlexVR ★★★★★
()
Ответ на: комментарий от AlexVR

Поменяй направление…

Вот наглядный пример почему настоящие программисты не приживаются в HPC. Вы прекрасно умеете писать код, верю. Но Вы понятия не имеете какие там сложности, и, главное, Вы совершенно не умеете слушать какие именно задачи надо решать и почему их надо решать именно так…

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

Не надо так делать.

ЗЫ То что Вы предлагаете пытались делать в HPC разные люди (в т.ч. я) на значительно более высоком уровне. Не взлетело по ряду причин. Генерация плюсового кода в HPC иногда используется, но для совершенно других вещей.

AntonI ★★★★★
() автор топика
Последнее исправление: AntonI (всего исправлений: 3)
Ответ на: комментарий от AlexVR

становиться нужным описание конфига

a 1         # межатомное расстояние
b 2.5       # модуль какой то хрени
с 23 24 25  # размер сетки

это легко читается глазами, легко пишется и парсится на плюсах 20ю строчками кода без всяких сторонних либ.

AntonI ★★★★★
() автор топика
Ответ на: комментарий от AntonI

Можно описывать типы подлежащие рефлексии вообще не в плюсах, а в XML/JSON/YAML. А скриптом на питоне уже генерировать и реальные структуры и enum в C++, и метаинформацию о них (списки вариантов enum с их значениями, смещения полей в классе с их именами).

Какую-то сложную логику можно навесить через наследование от сгенерированных классов.

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от AntonI

Вот наглядный пример почему настоящие программисты не приживаются в HPC

Ушёл я из универа по другой причине.

HPC

  1. стандарт не свежее с++-17
  2. всякие толстые сторонние либы а-ля буст не подходят

Тут у меня вообще в голове не сходиться.

Что-то я считал, что в HPC за best practics использовать Environment Modules для выбора любых компиляторов, реализаций mpi и библиотек (в том числе последних версий). И для меня до сих пор лучшая сборочная система это https://easybuild.io/ , которая как раз для HPC кластеров. И сейчас EasyBuild предлагает gcc 14.2.0 в качестве крайней версии.

но Вы считаете что все надо делать по другому.

Я просто предложил вариант, и обосновал его. Выбирать то тебе (и тем кто подписался на тред).

Так или иначе, вариантов для твой задачи не так и много. Либо X-макросы, либо кодогенерация, либо ручками. Ещё раз, в плюсах нет макросов и derive как в Rust (или ещё в каком другом ЯП).

AlexVR ★★★★★
()
Ответ на: комментарий от AntonI

это легко читается глазами

a = 1            # межатомное расстояние
b = 2.5          # модуль какой то хрени
с = [23, 24, 25] # размер сетки

Тоже не плохо. Но на вкус и цвет…

без всяких сторонних либ

Для HPC нет проблем использования сторонних библиотек

module load gcc/14.2.0
module load tomlplusplus/3.4.0

Но вот найти тех, кто будет сопровождать модули на вычислительном кластере, может быть проблемой.

AlexVR ★★★★★
()
Ответ на: комментарий от eao197

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

А можно примеры таких платформ? Кроме Itanium какого-нибудь, поддержку которого выкинули из GCC, и прочих дохлых елбусов ничего в голову не приходит.

Я, в общем-то, серьёзно спросил, вдруг есть какие-то интересные ограничения о которых я не знаю. А мне тут начали лечить про якобы железные ТЗ и «потому что так надо».

В общем, это трудно объяснить празношатающимся по форумам, но жизнь такова, что в мире C++ по целому ряду как объективных, так и субъективных причин часть проектов принципиально живет на более старых стандартах (вроде C++17, C++14 или даже на C++11, а кто-то наверняка еще и на C++98/03). Такова жизнь.

Я видел такие проекты и в 98% случаев эти причины высосаны из задницы и легко решаются настройкой кросскомпиляции. Оставшиеся 2% – это всякие всратые истории типа как @firkax собирает софт в MSVS 5 выпуска 1997 года, потому что его контора поддерживает Windows 98 за каким-то чёртом.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от AlexVR

в HPC за best practics использовать Environment Modules для выбора любых компиляторов, реализаций mpi и библиотек (в том числе последних версий)

что на кластере стоит то и используешь, например

$ date
Пн окт 28 11:55:55 MSK 2024
$ g++ -v
...
gcc версия 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)

Для HPC нет проблем использования сторонних библиотек

$ module
-bash: module: команда не найдена

системы очень разные бывают;-)

AntonI ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Буквально в прошлом году у одного из Заказчиков стояло требование MVS2008. Железное требование - они действительно этим собирали и у них ничего другого не было. В этом году они уже c++17 поддерживать стали, и то хорошо.

Мир он как бы сильно сложнее и разнообразнее чем то что Вы у себя в конторе наблюдаете. Сидите все время на последней версии компайлера - рад за Вас искренне. А вот из ШПУ МБР Минитменен 10 дюймовые дисководы убрали не так давно;-)

AntonI ★★★★★
() автор топика
Ответ на: комментарий от AntonI

Мир он как бы сильно сложнее и разнообразнее чем то что Вы у себя в конторе наблюдаете.

Да я не сомневаюсь, извращенцы всякие есть. Вопрос в причине этого извращения: потому что реально нет компилятора, который бы умел платформу, или потому что просто кто-то дрочит. В подавляющем большинство случаев это второе.

А вот из ШПУ МБР Минитменен 10 дюймовые дисководы убрали не так давно;-)

Ага, но софт для них не пишут уже давно.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

А можно примеры таких платформ? Кроме Itanium какого-нибудь, поддержку которого выкинули из GCC, и прочих дохлых елбусов ничего в голову не приходит.

Самое неожиданное, с чем лично мне довелось столкнуться (20 лет назад, в начале осени 2004-го) – это HP NonStop. Там был какой-то вариант C++ного компилятора от Metrowerks. По счастью, с нормальной поддержкой C++98.

При этом про саму платформу NonStop до того момента я вообще ничего и никогда не слышал.

Я, в общем-то, серьёзно спросил, вдруг есть какие-то интересные ограничения о которых я не знаю.

Вы, блин, как типичный технарь, во всем ищете рациональное зерно.

Тогда как причины могут быть и крайне субъективные. Типа хватит нам приключений при частом обновлении компилятора. Вот есть у нас GCC 11, сидим пока на нем, пока молодые пионеры шишки с GCC 14 набивают.

Я вот некоторое время назад под Windows обновил VS и наткнулся на баг в VC++, которого не было в предыдущих версиях (не говоря уже про таковой в GCC или Clang-е).

В проекте для текущего заказчика основная работа пока идет под Windows, но эпизодически проверяется компилируемость кода под Linux/GCC. И по следам этих попыток видно, как код, который был написан с использованием свежих фич C++20/23 приходится править под возможности линуксовой версии GCC.

Я видел такие проекты и в 98% случаев эти причины высосаны из задницы и легко решаются настройкой кросскомпиляции.

Ну вот мы поддерживаем несколько библиотек и держим пару из них на C++17 для того, чтобы у пользователей, которые по каким-либо причинам не перешли на C++20 не было проблем.

По поводу кросскомпиляции – у кого-то люди даже с примитивным CMake разобраться не могут. Чтобы хотя бы под одну платформу собирать без приключений.

eao197 ★★★★★
()
Ответ на: комментарий от hateyoufeel

Вопрос в причине этого извращения

Самые разные. Начиная от непреодолимых формальных сложностей установки нового компилятора и заканчивая опасениями сломать старый код выполняющий какие то критические расчеты.

Далеко ходить не надо, вплоть до SWIG 4.0.2 код плюсовой обертки генерился нормально, начиная с 4.2 за каким то фигом они убрали «лишние» static_cast и некоторые вещи собираться перестали. Я какое то время специально ставил версию 4.0.2, но в конце концов под давлением общественности стал эти нехватающие static_cast втыкать питоновской утилитой.

Ага, но софт для них не пишут уже давно.

Не уверен…

AntonI ★★★★★
() автор топика
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от eao197

По поводу кросскомпиляции – у кого-то люди даже с примитивным CMake разобраться не могут. Чтобы хотя бы под одну платформу собирать без приключений.

Ну, то есть, ты мне сейчас рассказываешь, что у плюсистов всё настолько плохо что они сборку до сих пор не могут осилить? Может, не надо им тогда на C++ писать?

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

Я бы предложил не использовать общее понятие «плюсисты», т.к. уровень знаний и умений даже на той небольшой выборке, которая прошла мимо меня, варируется от «да ты чертов гений» до «ниже плинтуса».

Может, не надо им тогда на C++ писать?

Некоторым из тех, чей код попадал ко мне на сопровождение, вообще ни на чем не следовало бы писать. Тем не менее, они работают и заменить их на реальных проектах не могут.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Некоторым из тех, чей код попадал ко мне на сопровождение, вообще ни на чем не следовало бы писать. Тем не менее, они работают и заменить их на реальных проектах не могут.

Когда то давно работал я в университете Уппсалы (Швеция). Зовет меня коллега - прислали сишный код для расчетов молекулярной динамики, аффтор кода на минуточку нобелевский лауреат по той самой молекулярной динамике, че то не собирается. Бегу я в предвкушении - сейчас увижу нечто невообразимо прекрасное - а там 3тыс строк говнокода одним файлом, половина из которого кривой разбор аргументов командной строки.

Тем не менее автор того кода вполне заслуженный нобелевский лауреат, а из нас никто нобелевским лауреатом не является;-)

AntonI ★★★★★
() автор топика
Ответ на: комментарий от eao197

Может, не надо им тогда на C++ писать?

Некоторым из тех, чей код попадал ко мне на сопровождение, вообще ни на чем не следовало бы писать. Тем не менее, они работают и заменить их на реальных проектах не могут.

Почему не могут, если они пишут настолько чудовищный говнокод? Ей богу, не понимаю этой проблемы.

Кстати, забавно, что в других языках нет таких проблем со сборкой как в C/C++. Отсутствие модулей и дефолтной сборочной системы реально приводят к полному хаосу.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Почему не могут, если они пишут настолько чудовищный говнокод? Ей богу, не понимаю этой проблемы.

Потому что иногда важнее знание предметной области чем качество кода. Лучше работающий говнокод чем прекрасно написанный по всем канонам код который не работает. HPC как раз один из примеров.

AntonI ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Почему не могут, если они пишут настолько чудовищный говнокод?

Потому что других на рынке нет. У каждого работодателя свои возможности, в рамках которых он может получить не больше того, что может получить.

Кстати, забавно, что в других языках нет таких проблем со сборкой как в C/C++.

Так и немного вообще есть языков, у которых есть и стандарт, и несколько независимых его реализаций.

Отсутствие модулей и дефолтной сборочной системы реально приводят к полному хаосу.

Модули погоды не делают. А вот отсутствие стандартной сборочной системы – да. Но и Си, и C++ появились тогда, когда от ЯП не требовалось ни штатной системы сборки, ни штатного менеджера зависимостей.

Тому шо маемо, то и маемо.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Потому что других на рынке нет. У каждого работодателя свои возможности, в рамках которых он может получить не больше того, что может получить.

Окей, допустим. Хотя ИМХО это вопрос денег и лучше нанять трёх нормальных чуваков чем десяток долбодятлов.

Так и немного вообще есть языков, у которых есть и стандарт, и несколько независимых его реализаций.

А есть ли они у C/C++? Про стандарт смешно, потому что сишные программисты либо не читали стандарт, либо люто его ненавидят, потому что он мешает им программировать своим UB. Доказано пользователями этого форума, как минимум.

Независимость реализаций тоже под вопросом. Из актуальных я знаю только три сейчас, и две из них пытаются копировать друг друга по максимуму.

Модули погоды не делают.

Ещё как делают.

А вот отсутствие стандартной сборочной системы – да. Но и Си, и C++ появились тогда, когда от ЯП не требовалось ни штатной системы сборки, ни штатного менеджера зависимостей.

То, что было в 1980х, вообще не роляет никак сегодня. Тот же ML (SML, OCaml) и прочие Хачкели появились тоже не сегодня (хачкелю скоро 35 лет стукнет лол), но там эти штуки почему-то есть.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Хотя ИМХО это вопрос денег и лучше нанять трёх нормальных чуваков чем десяток долбодятлов.

Несколько последних заказчиков с которыми общался, жаловались, что сейчас вообще тяжело искать C++ников.

Кроме того, в любом проекте полно рутины, которую нужно кому-то делать. Опять же из своего опыта: для текущего клиента я сейчас делаю точеные работы, когда, образно говоря, нужно блоху подковать, потому что клиент считает, что давать мне какие-то обыденные задачи – это напрасная трата ресурсов.

А есть ли они у C/C++?

Да.

Про стандарт смешно

Вам смешно. Мне, например, нет. Ну и мне как-то похер на Си, а вот на стандарт C++ приходится оглядываться. Как и на его актуальные реализации. Особенно если нужно, чтобы код работал под любой из них.

Ещё как делают.

Сооомнительно, но Окааай.

То, что было в 1980х, вообще не роляет никак сегодня.

Да ладно. Вы попробуйте человеку, который в 1980-х ногу потерял, что сейчас это погоды не делает. Ага.

Тот же ML (SML, OCaml) и прочие Хачкели появились тоже не сегодня (хачкелю скоро 35 лет стукнет лол), но там эти штуки почему-то есть.

Потому что они и сейчас нахер никому в мейнстриме невперлись. Не говоря уже про 35 лет назад, когда этим Хаскелем интересовалось 35 человек по всей планете.

Когда у тебя экосистема для 20 инвалидов, то через 20 лет можно опомниться и запилить пакетный менеджер.

А вот для того же C++ проблема 15 конкурирующих стандартов стоит в полный рост. Никакому Хаскелю такое и близко не снилось.

В C++ даже когда надобность пакетного менеджера стала ну совсем уж очевидно все равно не смогли собраться вокруг чего-то одного. Есть и vcpkg, и conan, и еще полдюжины поменьше и пожиже. Не говоря уже про крики красноглазиков о том, что все это от лукавого и кроме святого rpm или deb ничего не надобно.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Несколько последних заказчиков с которыми общался, жаловались, что сейчас вообще тяжело искать C++ников.

А они не пробовали, ну я не знаю, больше денег платить? Одна из причин, почему я не пишу на C++ ради основного заработка и использую его только в впопенсорце, это как раз деньги. Плюсовых вакансий с деньгами внезапно не то чтобы очень много.

Вам смешно. Мне, например, нет. Ну и мне как-то похер на Си, а вот на стандарт C++ приходится оглядываться. Как и на его актуальные реализации. Особенно если нужно, чтобы код работал под любой из них.

Безусловно. Но ты являешься редким случаем. Подавляющее большинство программистов на сишечке с плюсиками на стандарт клали болт и пишут просто не приходя в сознание. Если работает, то и зашибись. Ты, в принципе, сам чуть выше об этом писал.

То, что было в 1980х, вообще не роляет никак сегодня.

Да ладно. Вы попробуйте человеку, который в 1980-х ногу потерял, что сейчас это погоды не делает. Ага.

Сравнивать программирование на C++ с отрыванием ноги – это просто топчик! Не, я согласен. Среднему плюсисту стопудов что-то точно оторвало, хотя и не факт что ногу.

Тот же ML (SML, OCaml) и прочие Хачкели появились тоже не сегодня (хачкелю скоро 35 лет стукнет лол), но там эти штуки почему-то есть.

Потому что они и сейчас нахер никому в мейнстриме невперлись. Не говоря уже про 35 лет назад, когда этим Хаскелем интересовалось 35 человек по всей планете.

Мои последние два работодателя с вами категорически несогласны :3

Когда у тебя экосистема для 20 инвалидов, то через 20 лет можно опомниться и запилить пакетный менеджер.

А стандарт на что нужен? Добавить в стандарт минимальный функционал этого самого пакетного менеджера и всё. Учитывая, что в плюсовом стандарте скоро 2000 страниц будет, это погоды ваще не сделает. Хуже точно не будет.

В C++ даже когда надобность пакетного менеджера стала ну совсем уж очевидно все равно не смогли собраться вокруг чего-то одного.

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

А они не пробовали, ну я не знаю, больше денег платить?

Я же сказал выше: «У каждого работодателя свои возможности, в рамках которых он может получить не больше того, что может получить.» По своим возможностям и получают.

А стандарт на что нужен?

Смею надеяться на то, чтобы писатели компиляторов и стандартной библиотеки делали так, чтобы пользовательский код на разных реализациях компилятора/стандартной библиотеки работал +- одинаково.

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

Добавить в стандарт минимальный функционал этого самого пакетного менеджера и всё.

Вроде бы в комитете сделали группу по тулингу, но пока я не слышал, чтобы она что-то родила.

А вот vcpkg и conan уже есть.

Вот поэтому стандарты без эталонной реализации и сосут.

Вы это сейчас здесь для чего пишите?

Я вот вижу мир в котором есть стандарт C++, где нет никакого пакетного менеджера. И есть три реализации этого стандарта, с которыми мне регулярно приходится иметь дело.

Это объективная реальность. От того, кто-то на LOR-е скажут, что это реализации сосут, наблюдаемая мной реальность не изменится.

eao197 ★★★★★
()
Ответ на: комментарий от AntonI

Кто генерирует описания структур - человек или компьютер - никак не влияет на performance этого вашего computing, не делая его ни high, ни low. Потому что кодогенератор может выдавать такой же код, код, как и человек. Было бы желание.

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

Я понимаю почему Qt тащить может создать дополнительные накладные расходы (в структурах будут дополнительные поля, в бинарник будет прилинкована огромная либа), но не кодогенерация. Потому что не может.

Кодогенерация может создать проблемы, если система сборки не поддерживает вызов дополнительных утилит перед сборкой. Или если нанятые программисты при виде чего-то кроме C++ кода сворачиваются калачиком на полу и начинают плакать и звать маму, роняя перформанс не кода, но его разработки.

И то, и другое можно объяснить в двух словах без выпендрежа «вы ничего не понимаете, это HPC».

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 3)
Ответ на: комментарий от KivApple

Ну и, кстати, ограничения системы сборки могут обходиться тем, что кодогенерация запускается самим программистом перед сборкой той самой Особой Системой Сборки. Хоть git precommit hook, хоть вообще резидентной утилитой мониторящей каталог с исходниками и реагирующей на каждый Ctrl + S в IDE.

Хотя если структуры меняются редко, то можно и руками запускать.

Всё равно сборка упадёт, если что.

Но всё ещё остаётся человеческий фактор, что кто-то может быть категорически против менять структуры в JSON, а не в H файле. Но это опять же история не связанная напрямую с HPC.

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 4)
Ответ на: комментарий от AntonI

-bash: module: команда не найдена

Говорит только об тупости ситуации и не настроенном кластере. Если нет на вычислительном кластере админа, то увы…, приношу соболезнования.

что на кластере стоит то и используешь, например

Что мешает собрать свой SDK (на кластере или своей машинке) и запускать бинарник со всеми необходимыми библиотеками? Как это делают все module-like решения?

Для EasyBuild не нужны права администратора.

Активировать окружение можно и скриптом source activate_my_sdk.sh.

AlexVR ★★★★★
()
Ответ на: комментарий от KivApple

Кто генерирует описания структур - человек или компьютер - никак не влияет на performance этого вашего computing, не делая его ни high, ни low.

Не делает. Но это банально неудобно по ряду причин и этим никто не будет пользоваться, включая меня.

И то, и другое можно объяснить в двух словах без выпендрежа «вы ничего не понимаете, это HPC».

Вы потратили гораздо больше двух слов, но приведенные Вами причины не являются основными.

AntonI ★★★★★
() автор топика
Ответ на: комментарий от KivApple

Но всё ещё остаётся человеческий фактор, что кто-то может быть категорически против менять структуры в JSON, а не в H файле. Но это опять же история не связанная напрямую с HPC.

Нет, это история связанная напрямую с HPC. Коды HPC достаточно специфичны, сложности которые там преодолеваются для других областей разработки нетипичны. И этот «человеческий фактор» не чья то блажь, а традиции обусловленные спецификой разработки (как и короткие имена переменных). Акценты совершенно по другому расставляются. Но объяснить это человеку не варящемуся в этой области довольно сложно, так же как HPC-шнику трудно объяснить зачем геттеры/сеттеры например.

AntonI ★★★★★
() автор топика
Ответ на: комментарий от AlexVR

Админ там есть. Не буду вдаваться в подробности.

Что мешает собрать свой SDK (на кластере или своей машинке) и запускать бинарник со всеми необходимыми библиотеками? Как это делают все module-like решения?

Лично я не знаю как это делается. Подозреваю что кто то с меньшим опытом просто не поймет о чем Вы говорите.

AntonI ★★★★★
() автор топика
Ответ на: комментарий от eao197

Скажите лучше, чем плохи магические комментарии в С++ (или еще где то) на основе которых какая то сторонняя утилита генерит доп. код. Я слышал что это типа плохая практика, но почему не пойму - казалось бы это полностью развязывает руки?

AntonI ★★★★★
() автор топика
Ответ на: комментарий от eao197

Вы нет, @annulen вроде утверждал;-) Меня общее направление развития интересует.

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

Еще похожая задача возникает в лайт-версионифицировании (не знаю как это правильно назвать). Т.е. есть код в котором на этапе разработки хочется быстро включать/выключать какие то фрагменты. Это быстрые изменения, в том смысле что их фиксировать и загонять под git бессмысленно, да и вариантов в итоге м.б. слишком много. Скажем здесь мы играем знаком (плюс или минус), там мы умножаем/не умножаем на константу, еще где то добавляем/убираем проверку - в итоге три места где мы что то меняем, 8 возможных комбинаций. Надо проверить их все, и м.б. иметь возможность повторить эти тесты когда нить потом.

Препроцессор тут слишком громоздок и неудобен получается, а вот магические комментарии + внешняя утилита самое то. Эдакий препроцессор имени себя, главное не увлекаться;-)

AntonI ★★★★★
() автор топика