Здравствуйте, Nuzhny, Вы писали:
NB>>>2. если до того как указатель перехватят будет исключение, то получим утечку S>>Для этого qa есть. Чинить последствия вместо причины — такое себе. N>А как qa будет обрабатывать ситуацию, когда на сервере в продакшене, например, кончится память? Как то так
N>Или возникнет любая другая штатная проблема, которую нормальный код должен обрабатывать
Проэмулировать можно много чего. Давай ситуации.
И да, каждый чих испытывать конечно никаких ресурсов не хватит. Надо добавлять тесты к qa исходя из того что творится на проде.
А лечение выдуманных ошибок как и преждевременная оптимизация — такое себе.
Здравствуйте, B0FEE664, Вы писали:
BFE>Почему у TCopyTableRPC голый указатель, а не std::unique_ptr<IRequestOpCtx> ?
А зачем?
Если известно время жизни объекта, то нафига дополнительные сущности? Чтобы было? Так модно?
Здравствуйте, Sheridan, Вы писали:
BFE>>Почему у TCopyTableRPC голый указатель, а не std::unique_ptr<IRequestOpCtx> ? S>Если известно время жизни объекта, то нафига дополнительные сущности? Чтобы было? Так модно?
Хотя бы для того чтобы если во время конструирования объекта возникнет
исключение не получить утечку памяти
Здравствуйте, night beast, Вы писали:
S>>Если известно время жизни объекта, то нафига дополнительные сущности? Чтобы было? Так модно?
NB>1. по приведенному коду совершенно не ясно время жизни. более того, в корегайдлайн голые указатели значат невладеющие.
Спасибо, кэп. По коду не видно много чего бывает. А вот автор наверняка знать будет.
NB>2. если до того как указатель перехватят будет исключение, то получим утечку
Для этого qa есть. Чинить последствия вместо причины — такое себе.
Здравствуйте, Sheridan, Вы писали:
S>>>Если известно время жизни объекта, то нафига дополнительные сущности? Чтобы было? Так модно? NB>>1. по приведенному коду совершенно не ясно время жизни. более того, в корегайдлайн голые указатели значат невладеющие. S>Спасибо, кэп. По коду не видно много чего бывает. А вот автор наверняка знать будет.
Код пишут не для писателей, а для читателей. Мало ли что там автор "знает". Вот придёт завтра на смену одного автора другой и что он будет делать?
Здравствуйте, Sheridan, Вы писали:
BFE>>Почему у TCopyTableRPC голый указатель, а не std::unique_ptr<IRequestOpCtx> ? S>А зачем? S>Если известно время жизни объекта, то нафига дополнительные сущности? Чтобы было? Так модно?
1. по приведенному коду совершенно не ясно время жизни. более того, в корегайдлайн голые указатели значат невладеющие.
2. если до того как указатель перехватят будет исключение, то получим утечку
Здравствуйте, night beast, Вы писали:
BFE>>>Код пишут не для писателей, а для читателей. Мало ли что там автор "знает". Вот придёт завтра на смену одного автора другой и что он будет делать? S>>Делать все подряд указатели умными?
NB>как минимум поставить gsl::owner
Ровно тот-же вопрос: Зачем? Так — модно? Или что?
Здравствуйте, Sheridan, Вы писали:
S>Напомни, для чего тесты делаются? S>Напомни, виртуалками в проде пользуюся?
Вот твой код с голым указателем тесты и не пройдёт. Потому что не умеет обрабатывать исключения в конструкторе.
S>Именно так. Дадут подзатыльник и пойдёшь исправлять. Правда, некоторы под "исправлением" понимают "а, оберну в умный указатель — падать не будет, течь не будет да и модно-молодёжно".
Тогда тебе придётся писать велосиед. На код-ревью его завернут с формулировкой "пытался завелосипедить unique_ptr". Самое смешное, что этому "модно-молодёжно" в С++ уже лет 30, в 1994 году их уже предлагали в стандарт как раз для exception safety кода. Их ввели, потом улучшили, а ты до сих пор думаешь, что умные указатели используют те, кому лень отслеживать время жизни объекта. Ну, такое
Здравствуйте, B0FEE664, Вы писали:
S>>... Отвечальщик ответил и объект больше не нужен. BFE>И? Что с этим объектом стало? Объект больше не нужен — кто его удалит? Вызывающий? Вызванный? Или его надо поместить в специальную очередь на удаление?
delete this?
BFE>Прошёлся по исходникам и (если я по пути негде не заблудился) что я вижу тут? BFE>
BFE>О май гад! BFE>Снова unique_ptr! BFE>А если request — это объект на стеке,
А точно он может быть объектом на стеке?
А то подобных предположений этот срач и начался.
S>>Зачем тут умные указатели — непонятно. BFE>Чтобы видеть, кто владеет объектом. BFE>Не, я понимаю, что для большинства умные указатели — непонятно, сложно и невозможно. Ну так и не используйте, раз не умеете!
Понятно, несложно и возможно. Но использовать бездумно везде — такое себе.
Здравствуйте, B0FEE664, Вы писали:
S>>>>... Отвечальщик ответил и объект больше не нужен. BFE>>>И? Что с этим объектом стало? Объект больше не нужен — кто его удалит? Вызывающий? Вызванный? Или его надо поместить в специальную очередь на удаление? S>>delete this? BFE>Откуда это известно?
Что известно? Ты спросил кто удалит и предложил пару вариантов, оба неудобные. Я написал третий вариант, удобный.
BFE>>>Снова unique_ptr! BFE>>>А если request — это объект на стеке, S>>А точно он может быть объектом на стеке? BFE>А что ему помешает?: BFE>RequestCtx req(_some_args_); BFE>TCopyTableRPC tbl(&req); BFE>
Это ты в коде взял?
Здравствуйте, smeeld, Вы писали:
BFE>>Вот что будет, если pred() выбросит исключение? S>Ну, тут не совсем справедливо. Понятно, что передать можно что угодно, но ожидается таки некий примитивный предикат в духе bool fn(){ return a != b; }
А почему не написать:
template <typename P>
inline bool WaitD(TMutex& m, TInstant deadline, P pred) noexcept(noexcept(pred()))
...
Здравствуйте, B0FEE664, Вы писали:
BFE>Код пишут не для писателей, а для читателей. Мало ли что там автор "знает". Вот придёт завтра на смену одного автора другой и что он будет делать?
здесь тот самый случай, когда бесполезно что-то доказывать
Здравствуйте, Sheridan, Вы писали:
S>... Отвечальщик ответил и объект больше не нужен.
И? Что с этим объектом стало? Объект больше не нужен — кто его удалит? Вызывающий? Вызванный? Или его надо поместить в специальную очередь на удаление?
Прошёлся по исходникам и (если я по пути негде не заблудился) что я вижу тут?
О май гад!
Снова unique_ptr!
А если request — это объект на стеке, то будем иметь крэш в неопределённом месте. Но: тссс! Ни слова читателю кода, чтобы он не догадался, кто владеет объектом!
Вот что сложного было бы в передаче std::unique_ptr по ссылке? Или ссылка на указатель слишком сложно для мозгов? Тогда не надо ленится и везде прописать std::move...
S>Зачем тут умные указатели — непонятно.
Чтобы видеть, кто владеет объектом.
Не, я понимаю, что для большинства умные указатели — непонятно, сложно и невозможно. Ну так и не используйте, раз не умеете!
Здравствуйте, Sheridan, Вы писали:
N>>Вот твой код с голым указателем тесты и не пройдёт. Потому что не умеет обрабатывать исключения в конструкторе. S>Это если там вообще могут исключения возникнуть.
Тут уместно вспомнить историй падения одного европейского спутника. Там был написан код для одной ракеты и он был предельно выверен и корректен. Проверок не было в том месте, в котором математически всё контролировалось. Но потом кусок кода без изменений ерекочевал в другую ракету, в которой вдруг возникла ситуация с переполнением.
И тут все правы: писатели кода для первой ракеты правы, писатели для второй же просто перенесли корректный кусок кода.
Также и у тебя: ты вроде бы всё контролируешь в твоём конкретном случае, но по стандартам пишешь плохой код, который потенциально не переносится и требует ручных проверок. По факту совершаешь ещё одну ошибку — преждевременную оптимизацию на спичках.
Ты можешь спорить и доказывать, но современный надёжный CI/CD требуют уже других правил наисания кода, эти практики написаны на ошибках профессионалов (и эти ошибки уже 30 лет как очевидны в С++).
Здравствуйте, Zhendos, Вы писали:
Z>Хотя бы для того чтобы если во время конструирования объекта возникнет Z>исключение не получить утечку памяти
Да вообще пофиг что происходит во время разработки. Оно по факту вообще может не работать. В прод такое тащить зачем?
Здравствуйте, Sheridan, Вы писали:
NB>>2. если до того как указатель перехватят будет исключение, то получим утечку S>Для этого qa есть. Чинить последствия вместо причины — такое себе.
А как qa будет обрабатывать ситуацию, когда на сервере в продакшене, например, кончится память? Или возникнет любая другая штатная проблема, которую нормальный код должен обрабатывать
Здравствуйте, B0FEE664, Вы писали:
NB>>>1. по приведенному коду совершенно не ясно время жизни. более того, в корегайдлайн голые указатели значат невладеющие. S>>Спасибо, кэп. По коду не видно много чего бывает. А вот автор наверняка знать будет. BFE>Код пишут не для писателей, а для читателей. Мало ли что там автор "знает". Вот придёт завтра на смену одного автора другой и что он будет делать?
Делать все подряд указатели умными?
Здравствуйте, Sheridan, Вы писали:
BFE>>Код пишут не для писателей, а для читателей. Мало ли что там автор "знает". Вот придёт завтра на смену одного автора другой и что он будет делать? S>Делать все подряд указатели умными?
Здравствуйте, B0FEE664, Вы писали:
BFE>Код пишут не для писателей, а для читателей. Мало ли что там автор "знает". Вот придёт завтра на смену одного автора другой и что он будет делать?
Код пишут, чтобы работал и бабло шло. Пользователям вообще похеру, какие указатели там используются.
Здравствуйте, Sheridan, Вы писали:
BFE>>Код пишут не для писателей, а для читателей. Мало ли что там автор "знает". Вот придёт завтра на смену одного автора другой и что он будет делать? S>Делать все подряд указатели умными?
Так в том и дело, что не понятно, что с этим кодом делать, так как из контекста совершенно не ясно какой указатель должен быть передан в конструктор TCopyTableRPC.
Здравствуйте, night beast, Вы писали:
BFE>>>Почему у TCopyTableRPC голый указатель, а не std::unique_ptr<IRequestOpCtx> ? S>>А зачем? S>>Если известно время жизни объекта, то нафига дополнительные сущности? Чтобы было? Так модно? NB>1. по приведенному коду совершенно не ясно время жизни. более того, в корегайдлайн голые указатели значат невладеющие.
10 минут ползанья по репозиторию тупо из вебморды гитхаба:
TCopyTableRPC сваливается вниз по дереву наследования до TThrRefBase, у которого описание "Atomically reference-counted base with a virtual destructor.".
То есть оно само по себе чтото типа умного указателя.
Глубже не копал.
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Код пишут не для писателей, а для читателей. Мало ли что там автор "знает". Вот придёт завтра на смену одного автора другой и что он будет делать? S>>Делать все подряд указатели умными? BFE>Так в том и дело, что не понятно, что с этим кодом делать, так как из контекста совершенно не ясно какой указатель должен быть передан в конструктор TCopyTableRPC. https://rsdn.org/forum/flame.comp/8261416.1
Здравствуйте, B0FEE664, Вы писали:
IM>>Код пишут, чтобы работал и бабло шло. Пользователям вообще похеру, какие указатели там используются. BFE>Это вы сейчас про код в открытом доступе с лицензией Apache?
А как это мешает?
Здравствуйте, Sheridan, Вы писали:
BFE>>>>Почему у TCopyTableRPC голый указатель, а не std::unique_ptr<IRequestOpCtx> ?
S>10 минут ползанья по репозиторию тупо из вебморды гитхаба: S>TCopyTableRPC сваливается вниз по дереву наследования до TThrRefBase, у которого описание "Atomically reference-counted base with a virtual destructor.". S>То есть оно само по себе чтото типа умного указателя. S>Глубже не копал.
О чём я и говорю: механизм владения объектом совсем не очевиден, к тому же вопрос не про TCopyTableRPC, а про IRequestOpCtx...
Здравствуйте, Sheridan, Вы писали:
IM>>>Код пишут, чтобы работал и бабло шло. Пользователям вообще похеру, какие указатели там используются. BFE>>Это вы сейчас про код в открытом доступе с лицензией Apache? S>А как это мешает?
А зачем исходники, которые легче переписать, чем прочитать?
Здравствуйте, Sheridan, Вы писали:
S>10 минут ползанья по репозиторию тупо из вебморды гитхаба: S>TCopyTableRPC сваливается вниз по дереву наследования до TThrRefBase, у которого описание "Atomically reference-counted base with a virtual destructor.". S>То есть оно само по себе чтото типа умного указателя.
оно само типа умного указателя не бывает. оно может содержать данные (интрузивный счетчик ссылок), которые используются умным указателем.
но это не важно.
речь шла об аргументе конструктора, который внутри через несколько вызовов присваивается унику.
Здравствуйте, B0FEE664, Вы писали:
S>>10 минут ползанья по репозиторию тупо из вебморды гитхаба: S>>TCopyTableRPC сваливается вниз по дереву наследования до TThrRefBase, у которого описание "Atomically reference-counted base with a virtual destructor.". S>>То есть оно само по себе чтото типа умного указателя. S>>Глубже не копал.
BFE>О чём я и говорю: механизм владения объектом совсем не очевиден, к тому же вопрос не про TCopyTableRPC, а про IRequestOpCtx...
Ну так это вообще объект про запрос, на который надо ответить. Наличие методов внутри WriteAndFinish само про себя как бы говорит. То бишь пришол запрос, для него сгенерили объект, который помогает ответить и сроутили объект отвечльщику. Отвечальщик ответил и объект больше не нужен.
Зачем тут умные указатели — непонятно.
Здравствуйте, night beast, Вы писали:
S>>10 минут ползанья по репозиторию тупо из вебморды гитхаба: S>>TCopyTableRPC сваливается вниз по дереву наследования до TThrRefBase, у которого описание "Atomically reference-counted base with a virtual destructor.". S>>То есть оно само по себе чтото типа умного указателя.
NB>оно само типа умного указателя не бывает. оно может содержать данные (интрузивный счетчик ссылок), которые используются умным указателем.
И что мешает самоуничтожиться при достижении нуля?
NB>речь шла об аргументе конструктора, который внутри через несколько вызовов присваивается унику. https://rsdn.org/forum/flame.comp/8261526.1
Здравствуйте, Sheridan, Вы писали:
N>>А как qa будет обрабатывать ситуацию, когда на сервере в продакшене, например, кончится память? S>Как то так
А твой код в это время будет вести себя неадекватно. Понятно.
N>>Или возникнет любая другая штатная проблема, которую нормальный код должен обрабатывать S>Проэмулировать можно много чего. Давай ситуации.
Так это и есть ситуации. Под Windows есть AppVerifer, под никаким санитайзеры. Вот так и разрабатывают. Твой код будет падать, память потечёт, тебе дадут по голове, чтобы исправил. Вот тебе и ситуация. Никто не будет смотреть, известно ли тебе время владения объектом или нет, если память под санитайзерами будет течь.
S>И да, каждый чих испытывать конечно никаких ресурсов не хватит. Надо добавлять тесты к qa исходя из того что творится на проде. S>А лечение выдуманных ошибок как и преждевременная оптимизация — такое себе.
Ты живёшь в прошлом. Память у тебя кончится ещё под тестами, тестируют таким образом проекты уже все нормальные конторы. Ещё запускают статические анализаторы. Если твой код выполняет свою задачу, но не проходит все этапы верификации, то он не рабочий просто по определению правильно поставленного процесса разработки. Почему процессы ставят именно так? Чтобы оно не повторилось в продакшене.
Здравствуйте, Sheridan, Вы писали:
NB>>оно само типа умного указателя не бывает. оно может содержать данные (интрузивный счетчик ссылок), которые используются умным указателем. S>И что мешает самоуничтожиться при достижении нуля?
ничто не мешает. просто счетчик тупо изменяется снаружи (умным указателем)
NB>>речь шла об аргументе конструктора, который внутри через несколько вызовов присваивается унику. S>https://rsdn.org/forum/flame.comp/8261526.1
если посмотришь внимательно код, то увидишь, что там используются умные указатели (в базовом классе именно туда аргумент и кладется)
зачем нужны умные указатели, когда есть классный ручной делете -- это тема для другого обсуждения.
Здравствуйте, Nuzhny, Вы писали:
N>>>А как qa будет обрабатывать ситуацию, когда на сервере в продакшене, например, кончится память? S>>Как то так N>А твой код в это время будет вести себя неадекватно. Понятно.
Напомни, для чего тесты делаются?
Напомни, виртуалками в проде пользуюся?
N>>>Или возникнет любая другая штатная проблема, которую нормальный код должен обрабатывать S>>Проэмулировать можно много чего. Давай ситуации.
N>Так это и есть ситуации. Под Windows есть AppVerifer, под никаким санитайзеры. Вот так и разрабатывают. Твой код будет падать, память потечёт, тебе дадут по голове, чтобы исправил. Вот тебе и ситуация. Никто не будет смотреть, известно ли тебе время владения объектом или нет, если память под санитайзерами будет течь.
Именно так. Дадут подзатыльник и пойдёшь исправлять. Правда, некоторы под "исправлением" понимают "а, оберну в умный указатель — падать не будет, течь не будет да и модно-молодёжно".
S>>И да, каждый чих испытывать конечно никаких ресурсов не хватит. Надо добавлять тесты к qa исходя из того что творится на проде. S>>А лечение выдуманных ошибок как и преждевременная оптимизация — такое себе. N>Ты живёшь в прошлом. Память у тебя кончится ещё под тестами, тестируют таким образом проекты уже все нормальные конторы. Ещё запускают статические анализаторы. Если твой код выполняет свою задачу, но не проходит все этапы верификации, то он не рабочий просто по определению правильно поставленного процесса разработки. Почему процессы ставят именно так? Чтобы оно не повторилось в продакшене.
Мой косяк. Стейж конечно. Руки сами "прод" напечатали
Здравствуйте, Nuzhny, Вы писали:
S>>Напомни, для чего тесты делаются? S>>Напомни, виртуалками в проде пользуюся? N>Вот твой код с голым указателем тесты и не пройдёт. Потому что не умеет обрабатывать исключения в конструкторе.
Это если там вообще могут исключения возникнуть.
Здравствуйте, Sheridan, Вы писали:
S>>>... Отвечальщик ответил и объект больше не нужен. BFE>>И? Что с этим объектом стало? Объект больше не нужен — кто его удалит? Вызывающий? Вызванный? Или его надо поместить в специальную очередь на удаление? S>delete this?
Откуда это известно?
BFE>>Снова unique_ptr! BFE>>А если request — это объект на стеке, S>А точно он может быть объектом на стеке?
А что ему помешает?: RequestCtx req(_some_args_);
TCopyTableRPC tbl(&req);
S>А то подобных предположений этот срач и начался.
А вот если конструктор будет принимать unique_ptr, то такая фигня уже не скомпилируется: TCopyTableRPC(std::unique_ptr<IRequestOpCtx> p);
или TCopyTableRPC(std::unique_ptr<IRequestOpCtx>& p);
S>Понятно, несложно и возможно. Но использовать бездумно везде — такое себе.
Вот именно это мы и наблюдаем.