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

IM>Код пишут, чтобы работал и бабло шло. Пользователям вообще похеру, какие указатели там используются.

Это вы сейчас про код в открытом доступе с лицензией Apache?

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

Автор: Sheridan
Дата: 21.04.22

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

IM>>Код пишут, чтобы работал и бабло шло. Пользователям вообще похеру, какие указатели там используются.
BFE>Это вы сейчас про код в открытом доступе с лицензией Apache?
А как это мешает?

Здравствуйте, Ip Man, Вы писали:
IM>Респект за работающий проект. Есть планы монетизировать?
Я думаю, у хозяев проекта с монетизацией всё в порядке

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

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

N>>А как qa будет обрабатывать ситуацию, когда на сервере в продакшене, например, кончится память?
S>Как то так

А твой код в это время будет вести себя неадекватно. Понятно.

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

Так это и есть ситуации. Под Windows есть AppVerifer, под никаким санитайзеры. Вот так и разрабатывают. Твой код будет падать, память потечёт, тебе дадут по голове, чтобы исправил. Вот тебе и ситуация. Никто не будет смотреть, известно ли тебе время владения объектом или нет, если память под санитайзерами будет течь.

S>И да, каждый чих испытывать конечно никаких ресурсов не хватит. Надо добавлять тесты к qa исходя из того что творится на проде.
S>А лечение выдуманных ошибок как и преждевременная оптимизация — такое себе.

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

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

NB>>оно само типа умного указателя не бывает. оно может содержать данные (интрузивный счетчик ссылок), которые используются умным указателем.
S>И что мешает самоуничтожиться при достижении нуля?

ничто не мешает. просто счетчик тупо изменяется снаружи (умным указателем)

NB>>речь шла об аргументе конструктора, который внутри через несколько вызовов присваивается унику.
S>https://rsdn.org/forum/flame.comp/8261526.1

Автор: Sheridan
Дата: 21.04.22

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

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

N>>>А как qa будет обрабатывать ситуацию, когда на сервере в продакшене, например, кончится память?
S>>Как то так
N>А твой код в это время будет вести себя неадекватно. Понятно.
Напомни, для чего тесты делаются?
Напомни, виртуалками в проде пользуюся?


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

N>Так это и есть ситуации. Под Windows есть AppVerifer, под никаким санитайзеры. Вот так и разрабатывают. Твой код будет падать, память потечёт, тебе дадут по голове, чтобы исправил. Вот тебе и ситуация. Никто не будет смотреть, известно ли тебе время владения объектом или нет, если память под санитайзерами будет течь.
Именно так. Дадут подзатыльник и пойдёшь исправлять. Правда, некоторы под "исправлением" понимают "а, оберну в умный указатель — падать не будет, течь не будет да и модно-молодёжно".


S>>И да, каждый чих испытывать конечно никаких ресурсов не хватит. Надо добавлять тесты к qa исходя из того что творится на проде.
S>>А лечение выдуманных ошибок как и преждевременная оптимизация — такое себе.
N>Ты живёшь в прошлом. Память у тебя кончится ещё под тестами, тестируют таким образом проекты уже все нормальные конторы. Ещё запускают статические анализаторы. Если твой код выполняет свою задачу, но не проходит все этапы верификации, то он не рабочий просто по определению правильно поставленного процесса разработки. Почему процессы ставят именно так? Чтобы оно не повторилось в продакшене.
Мой косяк. Стейж конечно. Руки сами "прод" напечатали

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

S>... Отвечальщик ответил и объект больше не нужен.
И? Что с этим объектом стало? Объект больше не нужен — кто его удалит? Вызывающий? Вызванный? Или его надо поместить в специальную очередь на удаление?

Прошёлся по исходникам и (если я по пути негде не заблудился) что я вижу тут?

...
    TRpcRequestWithOperationParamsActor(TRequestBase* request)
        : Request_(request)
    {
    ...
    }
    ...

    std::unique_ptr<TRequestBase> Request_;
...

О май гад!
Снова unique_ptr!
А если request — это объект на стеке, то будем иметь крэш в неопределённом месте. Но: тссс! Ни слова читателю кода, чтобы он не догадался, кто владеет объектом!
Вот что сложного было бы в передаче std::unique_ptr по ссылке? Или ссылка на указатель слишком сложно для мозгов? Тогда не надо ленится и везде прописать std::move...

S>Зачем тут умные указатели — непонятно.
Чтобы видеть, кто владеет объектом.
Не, я понимаю, что для большинства умные указатели — непонятно, сложно и невозможно. Ну так и не используйте, раз не умеете!

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

S>Напомни, для чего тесты делаются?
S>Напомни, виртуалками в проде пользуюся?

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

S>Именно так. Дадут подзатыльник и пойдёшь исправлять. Правда, некоторы под "исправлением" понимают "а, оберну в умный указатель — падать не будет, течь не будет да и модно-молодёжно".

Тогда тебе придётся писать велосиед. На код-ревью его завернут с формулировкой "пытался завелосипедить unique_ptr". Самое смешное, что этому "модно-молодёжно" в С++ уже лет 30, в 1994 году их уже предлагали в стандарт как раз для exception safety кода. Их ввели, потом улучшили, а ты до сих пор думаешь, что умные указатели используют те, кому лень отслеживать время жизни объекта. Ну, такое

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

S>>Напомни, для чего тесты делаются?
S>>Напомни, виртуалками в проде пользуюся?
N>Вот твой код с голым указателем тесты и не пройдёт. Потому что не умеет обрабатывать исключения в конструкторе.
Это если там вообще могут исключения возникнуть.

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

S>>... Отвечальщик ответил и объект больше не нужен.
BFE>И? Что с этим объектом стало? Объект больше не нужен — кто его удалит? Вызывающий? Вызванный? Или его надо поместить в специальную очередь на удаление?
delete this?

BFE>Прошёлся по исходникам и (если я по пути негде не заблудился) что я вижу тут?
BFE>

BFE>...
BFE>    TRpcRequestWithOperationParamsActor(TRequestBase* request)
BFE>        : Request_(request)
BFE>    {
BFE>    ...
BFE>    }
BFE>    ...

BFE>    std::unique_ptr<TRequestBase> Request_;
BFE>...
BFE>

BFE>О май гад!
BFE>Снова unique_ptr!
BFE>А если request — это объект на стеке,
А точно он может быть объектом на стеке?
А то подобных предположений этот срач и начался.


S>>Зачем тут умные указатели — непонятно.
BFE>Чтобы видеть, кто владеет объектом.
BFE>Не, я понимаю, что для большинства умные указатели — непонятно, сложно и невозможно. Ну так и не используйте, раз не умеете!
Понятно, несложно и возможно. Но использовать бездумно везде — такое себе.

Здравствуйте, 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>Понятно, несложно и возможно. Но использовать бездумно везде — такое себе.
Вот именно это мы и наблюдаем.

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

S>>>>... Отвечальщик ответил и объект больше не нужен.
BFE>>>И? Что с этим объектом стало? Объект больше не нужен — кто его удалит? Вызывающий? Вызванный? Или его надо поместить в специальную очередь на удаление?
S>>delete this?
BFE>Откуда это известно?
Что известно? Ты спросил кто удалит и предложил пару вариантов, оба неудобные. Я написал третий вариант, удобный.


BFE>>>Снова unique_ptr!
BFE>>>А если request — это объект на стеке,
S>>А точно он может быть объектом на стеке?
BFE>А что ему помешает?:
BFE>RequestCtx req(_some_args_);
BFE>TCopyTableRPC tbl(&req);
BFE>
Это ты в коде взял?