From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 22 Jun 2021 12:26:25 +0300 (MSK) From: Ivan Zakharyaschev To: ALT Linux Team development discussions In-Reply-To: <5768583a-43dc-da5c-3609-8e7d15c50ee6@altlinux.org> Message-ID: References: <5768583a-43dc-da5c-3609-8e7d15c50ee6@altlinux.org> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1807885841-944326747-1624353985=:22813" Subject: Re: [devel] test a new build of APT, packagekit, synaptic, apt-indicator, aptitude, perl-AptPkg X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 09:26:25 -0000 Archived-At: List-Archive: List-Post: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1807885841-944326747-1624353985=:22813 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8BIT Hello! On Thu, 17 Jun 2021, Aleksei Nikiforov wrote: > По поводу packagekit: > > Прошу убрать коммит > 3cca5d3c17fa231a8e8917913ce5604051171d42: хотя оказывается C++ такое > позволяет, я бы предпочёл чтобы объявление и реализация функции имели > одинаковый вид. Тем более в ea8efac4dd0a8b2cc82ce9e303d6a2d50f393682 эта > разница убирается. (ea8efac4dd0a8b2cc82ce9e303d6a2d50f393682 я всё же в итоговой версии хочу пропустить, как я писал.) Можно ещё, чтобы был одинаковый вид и было формально зафиксировано свойство реализации (что в реализации функции эти переменные менять не приходится), добавить const в объявление в header-е. > Коммит a8eae29920917fac7eb2cb2f90eaa0a0493b33d6: вызов "_error->Discard();" > будет лучше перенести в деструктор класса AptCacheFile. В коммите > 75268b692844314957875c0f8cd365086467fe6d добавляется ещё одно место, где > удаляется и пересоздаётся инстанс AptCacheFile, а вот вызов > "_error->Discard();" там не добавили. Т.е. получается потеряли? Справедиливое замечание, что можно сказать, что его потеряли. Или не обработали ошибки. Просто раньше как бы вообще была неправильная реализация поведения в этом месте, и там ни Close(), ни деструктор не вызывался, не было эффекта и ошибки не обрабатывали. С одной стороны, я так написал, чтобы было больше возможностей следить за ошибками извне -- из вызывающего кода, а это не было жёстко вписано в деструктуры, конструкторы, методы... Может, там какая-то интересная ошибка, вызванная не деструктором, а чем-то ещё случившимся раньше. С другой стороны, согласен, что проще сделать это в этом деструкторе, раз там в коде нет более тонкого подхода к отслеживанию ошибок. Так и сделаю сейчас, если ты не скажешь, что у тебя предпочтения поменялись. Потому что так тоже можно в качестве эквивалента старого кода. > Есть ли смысл оставлять коммит 7ca8eaec9829820841d49c15d36c0520f1faf58b с > учётом наличия 75268b692844314957875c0f8cd365086467fe6d? Я думаю, стоит его > тоже просто удалить. Согласен. Заодно переупорядочиваю коммиты, чтобы исправление ошибки было ближе к upstream-у и можно было его отправить. -- Best regards, Ivan --1807885841-944326747-1624353985=:22813--