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

V>>Выглядело, что речь шла о как таковой возможности разрабатывать на Си под iOS.
G>Кроссплатформенный код

Угу, угу. И видимо наше старое управляющее ПО, написанное на C++ и отлично себя чувствующее (причём оно с GUI!) под Windows/MacOS/Linux/Android/iOS работает исключительно какой-то таинственной магией...

Здравствуйте, vdimas, Вы писали:
V>Т.е. объясняю одному недостаточно зрелому коллеге, почему он здесь ошибается:
V>

V>то ей будет ничуть не сложнее вычитать эти же символы из модулей

Ну так это так и есть. Вы зачем-то предположили, что структура модулей будет совпадать со структурой .LIB, а не со структурой .h.
С чего вы это взяли — решительно непонятно. Сами себе придумали проблему; сами же придумали ей решение (хоть и не сразу), а вот догадаться, что если бы С++ был с модулями, то вся картина реализации стандартной библиотеки была бы другой, вы не можете.

V>>>Например, вся немаленькая современная стандартная библиотека С++ подключается одним модулем.
S>>Всё зависит от того, как именно модули реализовывать.

V>Зачем оно?
Бесполезное бла-бла-бла — это "если бы в С++ были модули, то в начале 2000х ему для работы не хватало бы памяти".

S>>Предкомпиляция в С++ вообще штука крайне сложная. У самого она адски глючила и падала под виндой — и вовсе не из-за нехватки памяти.
V>И из-за глючной одно время технологии инкрементной компиляции, но это поправили ближе к концу 90-х.
Совершенно верно. ЕМНИП, поправили это ближе к концу 2000х, но я уже не застал — к моменту, когда VC научился более-менее прилично работать с pch, я с С++ уже ушёл. Я свой последний проект на плюсах доделывал аккурат под прямой эфир из NYC, 9/11.

S>>Сожрать модулями слишком много памяти — это какой-то феерический факап реализации системы модулей.
V>Дык, готовое бинарное описание ничего не экономит в сравнении с исходным текстовым после зачитки тех и тех, там в лучшем случае требуется та же память, в худшем чуть большая — ввиду дополнительного мета-описания символов с т.з. расположения тех в модулях.
В лучшем случае требуется меньше памяти, т.к. можно хранить результат анализа, а не AST в ожидании окончания компиляции. В худшем — столько же, т.к. "расположение в модулях" занимает плюс-минус столько же места, сколько информация о расположении в .h файлах. Ну, то есть меньше — т.к. нам не нужно вплоть до строчки и колонки.
V>Неразрешимой проблему никто не называл (очередной тебе минус за враньё), я пояснял, почему технология не обязательно вызовет экономию ресурсов и ускорение процессов.
Ещё раз: если у вас технология модулей не вызывает экономию ресурсов и ускорение процессов, то что-то очень сильно не так с проектированием и реализацией технологии модулей.
V>Чаще будет ровно наоборот, бо зачитка текстового кода происходит не сильно медленней и текстовый код может быть порой компактней бинарного описания, а скорость компиляции сейчас часто зависит от скорости чтения с диска, т.е. от размеров исходников.
В среднем бинарное описание значительно компактнее текстового. Если у вас не так — вам нельзя писать компилятор, найдите кого-то, кто умеет. Вы, похоже, путаете бинарное описание с бинарным кодом. Вот код на целевой архитектуре может запросто раздуться сильнее, чем текстовый исходник. А вот описание символов — не должно. Посмотрите, для примера, на устройство метаданных того же дотнета.
Я знаю, вы предпочитаете аргументированные утверждения — так вот, в исходнике у вас какой-нибудь bool Generate(const std::string& filepath, const std::string& configpath);, который вы разворачиваете в дерево с текстовыми узлами. А в бинаре у вас вместо строк — ссылки на готовые метаданные. При подъёме в память эти токены превращаются в банальные указатели, и тратят в разы меньше места по сравнению с AST-узлами.
Про зависимость скорости компиляции от скорости чтения исходников — это вы хорошо пошутили. Попробуйте-ка скомпилять какой-нибудь chromium, потом вместе посмеёмся. Сколько там у него, полгига исходников? Надо полагать, за пару минут соберётся.

V>Удобство модулей — это уменьшение вероятности потенциальных конфликтов имён промежуточных сущностей, фигурирующих сейчас в открытом виде в h-файлах.
V>Т.е. сами те сущности из модулей никуда не денутся, ес-но, но теперь их имена не будут вызывать конфликтов.
Как интересно. А что за промежуточные сущности — можно пример?

V>За злоупотребление такими вещами, которые ты себе позволяешь, увольняют откуда угодно.
Ещё ни разу при мне не уволили человека за технические вопросы, какими бы они ни были.
Даже за привычку переводить общение на личность собеседника — ну, вроде как у вас — и то не увольняли.

V>То, что ревью делать некому, походу. ))
Да при чём тут ревью. Вы просто годами игнорируете то, что вам пишут.
V>Т.е. из твоего положения тебе вообще выступать не следовало бы, бо ты в некотором смысле в вакууме работаешь, судя по высказываемому тобой, общаясь с коллегами через публичное АПИ их и своих поделий.
Я уже не знаю, каким вам шрифтом писать. Я — вообще не программист. Мне деньги платят не за строчки кода
Поэтому все эти ваши детские наезды — мимо тазика.

V>У меня сотни библиотечных типов одновременно было в разработке/портировании с С++, без оперативного оперирования зависимостями там можно было бы застрять надолго, т.е. выполнять работы "пошагово" можно было бы бесконечно.
Ну так это вырожденный случай — кстати, самый комфортный и удобный. Портирование — это же тупая механическая работа. Если бы исходным языком был не С++, то её вообще можно было бы автоматизировать. И, кстати, там всё очень легко делать инкрементально.

Я просто почему-то представлял себе обычный процесс разработки, который идёт с нуля. Или, наоборот, есть какой-то проект с предысторией, в котором "бурное кодирование" закончилось годы назад.
Мне такое счастье, как портирование, в последний раз доставалось году эдак в девятом. И то так — рядом постоять. Поправить мелкие косяки автоматизированного перевода.
А в предпоследний раз — в 2002 году. Мечта была, а не проект. Попадание в предварительные оценки с точностью до 1%; test code coverage = 100.0%. Заказчик на радостях премию выплатил.

С учётом подробностей — ок, я впечатлён вашей способностью эмулировать поведение плюсов в C# и msbuild. Толково придумано, я бы не допёр.

V>- в плюсах у меня единицы компиляции независимы (т.е. независим каждый cpp-файл);
V>- поэтому я могу работать над конкретным cpp-файлом независимо от компилябельности других cpp-файлов, т.е. хотя бы проверять на компиллябельность;
V>- если мне компиляции недостаточно, я могу линковаться в произвольных сочетаниях с отдельными obj-файлами, которые получаются из отдельных cpp-файлов.
V>- или могу сложить те obj-файлы, которые считаются рабочими, в одну либу одной командой и добавлять очередные obj-файлы в эту либу по мере готовности и т.д. и т.п.
V>То бишь, в плюсах изкаробки доступна произвольная декомпозиция зависимостей до одного файла.
V>Вплоть до того, что можно все методы одного объекта раскидать по разным файлам.
V>Или создать в разных cpp-файлах разные варианты реализации одного и того же метода, и выбирать нужный вариант на этапе линковки.
V>(просто сделай паузу и помедитируй в этом месте, бо мне уже надоело ждать, когда ты включишь соображалку)
Ну... ок. Мне такое практически никогда не бывает нужно, но если вы так говорите, то наверное да, оно так и надо.

V>Но стоит тебе отказаться от познания нового, экспериментаторства и т.д. и начать пропихивать куда надо и куда не надо свой старый опыт — туши свет, кидай гранату. ))
Не, я всегда открыт чему-то полезному. Но вот конкретно из вас что-то полезное выжать крайне сложно — вы слишком много времени тратите на оскорбления, наезды, напускание туману и намёки на всякое.
Когда перестаёте кривляться и начинаете писать, ничего не предполагая — можно читать.

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

C>Справедливости ради, С++ постепенно эволюционирует в сторону CMake для стандартной системы сборки. Пакетная система пока ещё находится на стадии флюктуаций, но Conan больше всего похож на лидера.

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

C>Так что возможно, что лет через 5 в С++ будет де-факто стандартный стек в Conan + CMake.

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

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

V>Только не лока, а семафора.
V>Да, критиковал реализацию асихронного имеющегося семафора и утверждал, что если требуется только асинхронная часть его функциональности, то можно сделать намного легковеснее (слишком очевидно).
Было бы интересно посмотреть на код.

V>И если это было в этом же обсуждении, то там лишь одна твоя отсылка к примеру создания потоков vs тасков и тебе найти эту ссылку не сложнее, чем мне.
Не, не в том же. Нашёл я это обсуждение.
V>Вернее, ссылка от НС, ты дал ссылку на пост НС в кач-ве "доказательства", кароч, вы оба облажались.
V>И всё бы ничего, повторюсь, если бы не менторская позиция... Ну мало ли кто где ошибся?
Да, я там невнимательно посмотрел на ссылку — на первый взгляд показалось, что там реально запускается 5000 потоков.

V>Под ссылкой НС я привёл свою версию без лажи исходного лажового примера от того MS MVP (или кто он там в этом обезъяннике?), а так же на порядок отличающиеся результаты измерений.
V>Т.е., не согласен — претензии мне можно запросто оформить в виде претензии к моему показанному коду.
V>Свои претензии к исходному варианту я там же доступно раскрыл.
V>Но, судя по отсутствию реакции, ты и НС были согласны. ))
Ну да — просто у парня из МС получалось, что "синхронный" вариант в сто раз медленнее асинхронного, а у вас — что в десять.
За НС сказать не могу, а я не увидел опровержения основной идеи "не надо запускать 10000 потоков для 10000 задач" в вашем посте, и ничего писать не стал.

S>>А то. Как же без вас-то.

V>Без нейтива в этом мире никуда, ес-но.
V>Но почему у тебя от этого НАСТОЛЬКО пригорает?
У меня пригорает не от С++ или нейтива, а от вашего личного нарциссизма.

V>Наверно, единственные остались "непримиримые борцуны" на этом сайте, остальные давно забили на этот нелепый спор.

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

_>Данный инструмент называется bazel. Он совсем не новый (лично я писал о его применение прямо на этом форуме ещё пару лет назад) и совсем не маргинальный (его разработку ведёт Google и использует для всех своих внутренних процессов). Так что нельзя свалить не знание этого на какую-то необычность инструмента. Особенно для того, кто с таким знающим видом делает такие громкие заявления по данному вопросу.

Большое спасибо. Вот такое соотношение пользы к объёму участия в топике я могу только приветствовать.
Моё незнание инструмента напрямую связано с тем, что сам я на плюсах ничего не писал (и практически ничего не читал) с начала 2000х.


_>P.S. Небольшая заметочка для местных троллей, давно считающих меня яростным адептом C++. Не стоит путать хорошее знание вопроса и неадекватную фанатскую "любовь" к инструментам (как у многих моих старых оппонентов тут). Если что, моя компания уже год как занята миграцией всех продуктов с C++ на Rust. Только вот данное решение было принято совсем не в связи с лучшими инструментами разработки (cargo намного слабее bazel) и даже не в связи с мифом о вроде как большей безопасности Rust'а (на самом деле для профессионала в C++ программирование на Rust вообще ничем не отличается — просто все правила хорошего тона C++ там прошиты в компилятор и всё), а в связи с другим, совершенно неожиданным вопросом, даже никогда не всплывавшем с подобных обсуждениях на этом (да и на многих других) форуме.

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

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

V>>>Выглядело, что речь шла о как таковой возможности разрабатывать на Си под iOS.
G>>Кроссплатформенный код

_>Угу, угу. И видимо наше старое управляющее ПО, написанное на C++ и отлично себя чувствующее (причём оно с GUI!) под Windows/MacOS/Linux/Android/iOS работает исключительно какой-то таинственной магией...

Можешь ссылку дать? Чтобы и на винде и на ведроиде, и на iOS и чтобы из одних исходников собиралось.

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

_>>Угу, угу. И видимо наше старое управляющее ПО, написанное на C++ и отлично себя чувствующее (причём оно с GUI!) под Windows/MacOS/Linux/Android/iOS работает исключительно какой-то таинственной магией...
G>Можешь ссылку дать? Чтобы и на винде и на ведроиде, и на iOS и чтобы из одних исходников собиралось.

На наше естественно не могу, т.к. оно с закрытыми исходниками. Но тебе же важно не конкретное ПО, а любой прецедент, правильно? Вот https://github.com/Larpon/DeadAscend например такое ПО, с исходниками и даже находится во всех магазинах.

P.S. Вообще то мы как раз ушли от этой технологии и перешли на WebAssembly (собственно с появлением в браузере набора технологий wasm+webgl+websocket+webwokers, потребность в написание клиентских десктопных и мобильных приложений отпала в принципе). Но то, что появились технологии удобнее, совсем не означает, что обсуждаемая технология не рабочая (или вообще невозможная, как утверждал ты ).

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

V>>Без нейтива в этом мире никуда, ес-но.
V>>Но почему у тебя от этого НАСТОЛЬКО пригорает?
S>У меня пригорает не от С++ или нейтива, а от вашего личного нарциссизма.

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

Я и в реале совершенно неприметен, когда вокруг всё спокойно, но на хамов/быкующих и т.д. агрюсь за доли секунды.
Кто-то же должен их к ногтю, верно? ))

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

C>>Справедливости ради, С++ постепенно эволюционирует в сторону CMake для стандартной системы сборки. Пакетная система пока ещё находится на стадии флюктуаций, но Conan больше всего похож на лидера.
_>CMake — одна из худших систем сборки в мире C++, как минимум своим максимально убогим внутренним языком.
CMake реально работает. Язык как раз адекватен для системы сборки, не надо туда лишнее просто пихать.

_>Пакетный менеджер для бинарных сборок вообще противопоказан такому языку, как C++. Ну а в качестве куммулятивного репозитория исходников Conan просто не нужен (с этим лучше справляется грубо говоря гитхаб).
Смысл Conan'а в том, что он приводит все эти библиотеки на гитхабе к единому виду с помощью системы патчей. Так что не надо разбиратсья как там подключать в проект очередной libprotobuf. Бинарный склад артефактов — это уже просто побочный плюс.

C>>Так что возможно, что лет через 5 в С++ будет де-факто стандартный стек в Conan + CMake.
_>Это конечно возможно, т.к. индустрия далеко не всегда выбирает технически лучшие решения. Но это будет крайне печально для сообщества C++ и я надеюсь (хотя лично мне уже это не принципиально) что такого не случится.
А что лучше-то?

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

V>>Т.е. объясняю одному недостаточно зрелому коллеге, почему он здесь ошибается:
V>>

V>>то ей будет ничуть не сложнее вычитать эти же символы из модулей

S>Ну так это так и есть. Вы зачем-то предположили, что структура модулей будет совпадать со структурой .LIB, а не со структурой .h.

Сам себе противоречишь. ))
Экономию времени и памяти будет давать только совпадение со структурой LIB.


S>Бесполезное бла-бла-бла — это "если бы в С++ были модули, то в начале 2000х ему для работы не хватало бы памяти".

В реальной жизни для компиляции на линухах порой имеющихся двух стандартных метров на борту не хватало.
С модулями вообще не взлетело бы.


S>Совершенно верно. ЕМНИП, поправили это ближе к концу 2000х, но я уже не застал — к моменту, когда VC научился более-менее прилично работать с pch, я с С++ уже ушёл. Я свой последний проект на плюсах доделывал аккурат под прямой эфир из NYC, 9/11.

9/11 — это 2001-й, а не конец 2000х.
Который тогда был VC — он вышел в 1998-м, следующие плюсы вышли уже не отдельным продуктом, а в составе студии 2002, т.е. речь может быть о компиляторе из 98-го.

Следующий от 2002-го жутко глючил в течении года, что народ (в т.ч. и я) подключал туда VC от предыдущего VC, а уже в Студии 2003 компилятору полегчало.

Плюс случилось главное — стало можно писать кроссплатформенный код не только на Си, но и на С++, т.к. компиляторы покрыли официальным стандартом С++03 и теперь они стали воспринимать плюсы плюс-минус одинаково.

До этого писать на плюсах кроссплатформенный код было мукой, бо каждый компилятор имел своё видение, т.е. приходилось обыгрывать не только разночтение даже в POSIX-подмножестве АПИ осей (тогда в ходу было много плохосовместимых *никсов, не только Linux), но и разночтения компиляторов.
Уверен, тут полно коллег, которым в конце 90-х и почти все нулевые приходилось, как и мне, писать в т.ч. под спарки/солярис.


S>В лучшем случае требуется меньше памяти

Да не меньше никак.
Потому что вообще всё, что видно из h-файла, должно быть видно из модуля.

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


S>В худшем — столько же, т.к. "расположение в модулях" занимает плюс-минус столько же места, сколько информация о расположении в .h файлах. Ну, то есть меньше — т.к. нам не нужно вплоть до строчки и колонки.

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


V>>Неразрешимой проблему никто не называл (очередной тебе минус за враньё), я пояснял, почему технология не обязательно вызовет экономию ресурсов и ускорение процессов.
S>Ещё раз: если у вас технология модулей не вызывает экономию ресурсов и ускорение процессов, то что-то очень сильно не так с проектированием и реализацией технологии модулей.

Это потому что ты вырос на паскалевских TPU.
Но где Паскаль и где С++?

Ключевое там "не обязательно вызовет экономию ресурсов".
Для современных template-only библиотек скорее всего не вызовет или экономия будет незначительной (единицы процентов прибавки к скорости компиляции в сравнении с прошлыми ср-вами, типа stdafx.h).


V>>Чаще будет ровно наоборот, бо зачитка текстового кода происходит не сильно медленней и текстовый код может быть порой компактней бинарного описания, а скорость компиляции сейчас часто зависит от скорости чтения с диска, т.е. от размеров исходников.
S>В среднем бинарное описание значительно компактнее текстового.

Когда компилишь либы с опцией link-time code generation, то бинарники таких библиотек резко больше исходников получаются.
А это примерно оно и есть.

Еще навскидку — с 7-мибитным кодированием целых типов обычно не заморачиваются, бо это тоже некоторые тормоза при кодировании/раскодировании.
А при фиксированной их ширине, как оно есть в большинстве бинарных форматов файлов, — никакой экономии.
Где в тексте 1-2 символа, там в бинарнике честные 4.

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

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


S>Если у вас не так — вам нельзя писать компилятор, найдите кого-то, кто умеет.

Это ты сейчас с кем разговаривал?


S>Вы, похоже, путаете бинарное описание с бинарным кодом.

Я сейчас нон-стоп зеваю, если по-чеснаку.

Плохо, Синклер.
Очень плохо.
Принципы трасляции С++ кода весьма просты, я бы даже сказал — примитивнейшие.
Как там можно умудряться плавать?

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

В общем, я еще не уверен, но скорее всего отваливаюсь, бо это беспросветно...

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

C>>Справедливости ради, С++ постепенно эволюционирует в сторону CMake для стандартной системы сборки. Пакетная система пока ещё находится на стадии флюктуаций, но Conan больше всего похож на лидера.

_>CMake — одна из худших систем сборки в мире C++, как минимум своим максимально убогим внутренним языком.

У меня было подобное мнение, наблюдая его действительно кривой убогий язычок — кто эти ламеры разработавшие этот ужас и почему их вообще допустили в IT. И что авторов всех подобных приблуд надо вначале учить писать что угодно на LISP (уже второй вопрос — каком именно) в рамках ничем не ограниченных S-expressions.

Но потом я увидел некоторые ну очень странные вспомогательные скрипты на нём, вспомнил собственный тезис, что в DSL не столько важно, что он умеет, сколько — что он не позволяет делать, и усомнился.

Вроде, какие-то методы задания предела возможностей вложенным функциям тут были бы неплохи, но практика постоянных вылезаний из браузерных песочниц показывает, что не всё коту масленица.

В любом случае, этот кошмар стал фактическим стандартом надолго и с этим фактом сложно что-то сделать.

_>Пакетный менеджер для бинарных сборок вообще противопоказан такому языку, как C++.

Тут безусловно да.

C>>Так что возможно, что лет через 5 в С++ будет де-факто стандартный стек в Conan + CMake.

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

Ну если от всех платформ останется полдесятка (грубо говоря, RHEL+потомки/x86, Debian+потомки/x86, Windows/x86 и Android/AArch64) — то у такого были бы шансы.
Но сейчас я вижу, что нет, фиг там. Вон новые ISA вроде RISC-V приходят, ARM отъедает серверный рынок, и прочая.

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

V>Когда компилишь либы с опцией link-time code generation, то бинарники таких библиотек резко больше исходников получаются.
V>А это примерно оно и есть.

Это не "примерно то", это совсем иное — фактически вшиты распарсенные исходники (ну, возможно, во всяких IR).

V>Еще навскидку — с 7-мибитным кодированием целых типов обычно не заморачиваются, бо это тоже некоторые тормоза при кодировании/раскодировании.
V>А при фиксированной их ширине, как оно есть в большинстве бинарных форматов файлов, — никакой экономии.
V>Где в тексте 1-2 символа, там в бинарнике честные 4.

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

V>Где в тексте операция использует окружающий контекст, сопровождающирй операцию различными признаками, там в бинарнике к каждой операции привязывают уже вычисленные аттрибуты/признаки.

Которые обычно сведены в вызов конкретной функции.

V>Где в исходнике при вызове шаблонного метода используется автовыводимый тип аргумента, который явно нигде не упоминается, там в бинарнике многоэтажное декорированное имя типа выражения присутствует явно.

В секции имён, на которую стоит смещение (пусть 8 байт всегда). Или в COFF иначе?

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

V>>>Ну вот мы и пришли к сути, которую все и так знают, в общем-то.
V>>>В кач-ве редактора блокнотик, в кач-ве отладчика — примитивные devtools браузера.
I>>Для разработки простых вещей ни в одном ЯП не нужно ничего, кроме блокнота и компилятора-интерпретатора.

V>Теперь мы подошли к сути этой сути.

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

Раз ты не согласен, расскажи подробно, как ты реализуешь такой кейс:
Надо помочь юзеру, сделать ему хот-фикс на месте так, что бы он мог дохромать до полноценного обновления.
У юзера есть баг, который портит его данные. У тестеров и разрабов не воспроизводится.
Доступ к юзерскому компу закрыт.
Данные юзер дать не имеет права.
PDB и прочей отладочной инфы нет и не будет.
Пермишнов "запустить отладчик", "подменить сертификат" у юзер нет.
Инсталировать, копировать к себе на комп любой софт юзер не имеет права.
Ремотдесктоп запрещен.
Все что юзер может — запускать софт из тех ярлыков, что для него добавлены админом.
Юзер не технарь, а потому может выполнять только простые действия "нажми вон ту кнопку"

Итого — для JS это реализуется сравнительно небольшим количеством усилий.

ДевТулс браузера при своей простоте позволяют:
1. проверить DOМ, поиграться с ними на живом кейсе
2. проверить стили, поиграться с ними на живом кейсе
3. REPL, котого в плюсах никогда не будет
4. очень продвинутый сетевой сканер-профайлер
6. профалер для памяти
7. профайлер для CPU
8. состояние стораджа, куков, бекграундных активностей и тд.
9. Через плагины легко добавляется возможность работать со state management приложения, например, отлистать состояние назад на N действий пользователя и повторить, но уже под отладкой.

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

Все это доступно, не считая браузер
1 в мобильном приложении
2 в десктоп
3 в node
итд.

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

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

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

I>Итого — для JS это реализуется сравнительно небольшим количеством усилий.

I>ДевТулс браузера при своей простоте позволяют:

О как. То есть админ не закрыл эти самые devtools, дав зловредному юзеру возможность сделать реально что угодно с приложением в браузере, включая варианты:
— Подсунуть кривые или несовместимые данные
— Нарисовать ложную картину на экране и сделать с неё скриншот
— "Доработать" куки и сохранённые данные
— Запустить майнер

и т.д.

И ты считаешь, что этой возможностью надо гордиться?

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

I>Все это доступно, не считая браузер
I>1 в мобильном приложении
I>2 в десктоп
I>3 в node
I>итд.

И соответственно масса каналов утечек...

I>Соответсвенно, удаленная отладка ни разу себе не сложность. Можно хоть кастомные хот-фиксы накатывать. Юзер нажал кнопку, дал добро на выход в интернет, прислал тебе токен, ты зашел на свой сайт по токену и посмотрел, что там не так, фиксанул и юзер теперь сможет работать до полноценного апдейта.

И заодно получил пару троянчеггов от разработчика.

I>Собственно для плюсов нет ни одной полноценной замены. По отдельным функциям можно много чего найти помощнее. Одна проблема — что бы забесплатно закрыть всё это вобщем ничего нет.
I>То есть, встраиваемый мощный отладчик, которые предоставляет все 10 пунктов выше — для нативного кода такое похоже на сказку.

И пусть сказкой и остаётся.

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

I>У юзера есть баг, который портит его данные. У тестеров и разрабов не воспроизводится.

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


I>Итого — для JS это реализуется сравнительно небольшим количеством усилий.

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


I>ДевТулс браузера при своей простоте позволяют:
I>1. проверить DOМ, поиграться с ними на живом кейсе
I>2. проверить стили, поиграться с ними на живом кейсе
I>3. REPL, котого в плюсах никогда не будет

У одного нет пакетных менеджеров в С++, у другого нет репла.
Дикари-с...


I>4. очень продвинутый сетевой сканер-профайлер
I>6. профалер для памяти
I>7. профайлер для CPU

На зачаточном уровне всё перечисленное.
Профайлера GPU нет, в самом профайлере непонятно, где user-space время, а где ядерное, т.е. тупо цифры, а что с ними делать — да ХЗ, т.е. в каком направлении оптимизировать — делать кол-во системных вызовов реже, обрабатывая за раз более крупные пачки, или на своей стороне алгоритм допиливать?
Не вижу ни false sharing, ни затрат на поддержание кеша в когерентности ни вообще трафика кеша (степень охлаждения данных и кода).

Это что-то типа, каким мог быть профайлер для VBA в до-дотнетную эпоху? ))


I>То есть, ты можешь отлаживать почти всё, что предоставляет браузерный движок. То есть, всё, что необходимо приложению для работы.

И? Для того же дотнета в Студии есть хотя бы представление тасков и их последовательностей в человеческом виде, а в хромовых якобы девтулзах у тебя только сырые цепочки вызова колбэков, нагромождения нагромождений. ))

Это всё уровень начала нулевых (повторяю тезис, с которого пошёл спор, а то забываешься, смотрю).

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

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

V>>Когда компилишь либы с опцией link-time code generation, то бинарники таких библиотек резко больше исходников получаются.
V>>А это примерно оно и есть.
N>Это не "примерно то", это совсем иное — фактически вшиты распарсенные исходники (ну, возможно, во всяких IR).

О чем и речь, в модулях будет аналогично, иначе как ты шаблонные/инлайные/auto-функции сохранишь в модуле?


V>>Где в исходнике при вызове шаблонного метода используется автовыводимый тип аргумента, который явно нигде не упоминается, там в бинарнике многоэтажное декорированное имя типа выражения присутствует явно.
N>В секции имён, на которую стоит смещение (пусть 8 байт всегда). Или в COFF иначе?

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

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

Собсно, при реализации известной "модульной" технологии на С++ — COM, они с похожим столкнулись сразу же в плане vtable, что MS даже ввела в С++ __declspec(selectany), чтобы подавлять ругань линковщика на бесконечные доступные варианты одного и того же.

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

_>>CMake — одна из худших систем сборки в мире C++, как минимум своим максимально убогим внутренним языком.
N>У меня было подобное мнение, наблюдая его действительно кривой убогий язычок — кто эти ламеры разработавшие этот ужас и почему их вообще допустили в IT.

+100500


N>Но потом я увидел некоторые ну очень странные вспомогательные скрипты на нём, вспомнил собственный тезис, что в DSL не столько важно, что он умеет, сколько — что он не позволяет делать, и усомнился.

Это да, в плане функциональности, но при чём тут синтаксис?
Вернее, его отсутствие. ))

Походу, разработчики CMake не в курсе как писать синтаксические анализаторы, поэтому синтаксис в языке CMake отсутствует.
В языке допустима лишь конструкция одного вида: fn([args ...]).

Поэтому даже if() else() endif() выглядят так как выглядят.

Т.е. это что-то вроде лиспа, где первая скобка стоит не там, поэтому всегда требуются даже пустые скобки, бгг.


N>В любом случае, этот кошмар стал фактическим стандартом надолго и с этим фактом сложно что-то сделать.

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


_>>Это конечно возможно, т.к. индустрия далеко не всегда выбирает технически лучшие решения. Но это будет крайне печально для сообщества C++ и я надеюсь (хотя лично мне уже это не принципиально) что такого не случится.
N>Ну если от всех платформ останется полдесятка (грубо говоря, RHEL+потомки/x86, Debian+потомки/x86, Windows/x86 и Android/AArch64) — то у такого были бы шансы.
N>Но сейчас я вижу, что нет, фиг там. Вон новые ISA вроде RISC-V приходят, ARM отъедает серверный рынок, и прочая.

Да.
Поэтому, выиграет та технология, которая предложит больше для всех ниш и даром, такая технология автоматически окажется для индустрии важной.
И это будет не Conan на JFrog, бо слишком консервативные/закрытые, их потерю индустрия даже не заметит. ))

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

Помнишь, Google составил критерии и согласно им перечислил проекты, который являются критически-важными для IT?
VCPKG там присутствует, Conan нет.
https://www.opennet.ru/opennews/art.shtml?num=54242

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

I>Senior JavaScript Developer, от 5 000 до 7 000 USD на руки
I>https://hh.ru/vacancy/46563887
I>Надесь, доллары в рубли переведешь. Или помочь?

Да не поможет.
В требованиях:

- Отличные разговорные навыки на английском языке

Это 99% наших фронт-девелоперов отлетают, в т.ч. ты.

- ГОТОВНОСТЬ РАБОТАТЬ ПО ВРЕМЕНИ GMT + 8

Это пекинское время, т.з. европейского программера — это режим упоротого "жаворонка", т.е. 99.9% программистам опять не подходит.

Вот так с тобой всегда — от тебя или бред, или ложь.
Бо вакансия по этой ссылке — та самая разновидность лжи.


V>>На других вакансиях тимлидов цифры даже не указаны, по понятной причине — на этом уровне ЗП обычно не светят.
I>На фронте как минимум не хуже. Тимлид это уже менеджер, ему платят не за личный перформанс, а за перформанс команды.

Тимлид — это старший над 3-10-ю в среднем разработчиками, т.е. ничего сверхестественного.

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

V>Да не поможет.
V>В требованиях:
V>

V>- Отличные разговорные навыки на английском языке

V>Это 99% наших фронт-девелоперов отлетают, в т.ч. ты.

Ваших, и тебя включая — возможно. Наших — без внятного английского берут только на русскоговорящие проекты, коих мизер.
Так уже 10 лет назад было. Каждая внятная контора имеет свои курсы, где ведут люди из ИнЯз или International house, или оплачивает такие курсы.

V>Это пекинское время, т.з. европейского программера — это режим упоротого "жаворонка", т.е. 99.9% программистам опять не подходит.

Есть и другие вакансии на такую же зп. Даже выбор — react, node, просто javascript.

I>>На фронте как минимум не хуже. Тимлид это уже менеджер, ему платят не за личный перформанс, а за перформанс команды.

V>Тимлид — это старший над 3-10-ю в среднем разработчиками, т.е. ничего сверхестественного.

Именно. И платят не за доблесть в кодинге, а эффективность команды в целом.

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

I>>У юзера есть баг, который портит его данные. У тестеров и разрабов не воспроизводится.

V>Обычная ситуация в мире динамических языков.

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

V>Чтобы на них писать, объем тестов должен превышать в разы объем полезного кода, но вряд ли у вас так.

еще один мерятель тестов строчками.

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

upd: — для интересу, посмотрел количество кода в тестах и целевой части, по доступным вещам доходит до 500%. Похоже, ты снова про себя, про свою боль

I>>Итого — для JS это реализуется сравнительно небольшим количеством усилий.

V>Да не сказал бы.

Ты так и не рассказал, как решить кейс на плюсах. Ну или дотнете.

V>В JS вообще всё реализуется довольно большим кол-вом усилий.

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

Собственно, ты много написал, но так и не рассказал, как решить проблему на плюсах.

I>>ДевТулс браузера при своей простоте позволяют:
I>>1. проверить DOМ, поиграться с ними на живом кейсе
I>>2. проверить стили, поиграться с ними на живом кейсе
I>>3. REPL, котого в плюсах никогда не будет

V>У одного нет пакетных менеджеров в С++, у другого нет репла.
V>Дикари-с...

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


I>>4. очень продвинутый сетевой сканер-профайлер
I>>6. профалер для памяти
I>>7. профайлер для CPU

V>На зачаточном уровне всё перечисленное.
V>Профайлера GPU нет, в самом профайлере непонятно,

Это и не нужно — шейдеры на жээсе не пишут. Пока. Как начнут — появится.

>где user-space время, а где ядерное, т.е. тупо цифры, а что с ними делать — да ХЗ, т.е. в каком направлении оптимизировать — делать кол-во системных вызовов реже, обрабатывая за раз более крупные пачки, или на своей стороне алгоритм допиливать?

Какие еще системные вызовы в таком классе приложений?

Девтулс раскладывает тебе вообще все, с указанием времени какая функция сколько отработала и это визуализируется для тебя забесплатно.

V>Не вижу ни false sharing, ни затрат на поддержание кеша в когерентности ни вообще трафика кеша (степень охлаждения данных и кода).

Потому, JS это не нужно. Включи уже голову. Это же не отладчик внутренностей браузера.


I>>То есть, ты можешь отлаживать почти всё, что предоставляет браузерный движок. То есть, всё, что необходимо приложению для работы.

V>И? Для того же дотнета в Студии есть хотя бы представление тасков и их последовательностей в человеческом виде, а в хромовых якобы девтулзах у тебя только сырые цепочки вызова колбэков, нагромождения нагромождений. ))

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

V>Т.е. я НЕ отрицаю наличия для JS некоторых помощников для разработки, но их уровень отстаёт от оного для менстримовых языков лет эдак на 15-20.

Покажи на сегодня как решить обозначеный кейс на плюсах.