Здравствуйте, 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.

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