Hi Anders,

Thanks for your comments! These are some good points!

About auto_ptr, it’s true it’s never used in Calitko because, I admit, I wasn’t aware of its power before. I plan to post a separate post that addresses memory management related issues, including usage of auto_ptr. I’d expect some of you guys would have some comments there.

I agree that one should prefer to use functions of the standard library instead of self-coded alternatives. However, in that specific case I don’t think it makes much of a difference. Does anybody think that we should better be stricter and require standard library functions to be used wherever possible?

I would agree about [4].

About [5], well… I’m not sure whether we need to because an error item will be returned if parsing fails due to corrupt bencoded data, from which there is no way to recover as far as I know. A bad implementation on our side should cause an assertion to fail. I can’t imagine how putting more info in BErrorItem will be useful to user code of the class BDecoder. Other opinions? It would make sense though to write some infos in the debug log. Anybody familiar with a good debugging/logging framework? Something that allows managing something like per object/group of objects log, etc.?

About [6], you are right. As far as I remember the variables were needed outside the while in a previous version, which is not the case anymore. Declaring them only in the smallest scope where they are used is better style anyway.

About exception and error handling… It’s true that we have very little exception handling, if any, in Calitko source code. The other extreme would be writing try/catch block all over the place. I’m not an exceptions expert, and that’s the reason why I’m careful using any. I’ve seen people overuse them and the result I didn’t like! I’ll be glad to learn some exception handling tips and tricks though ;-).

And here is why we do asserts so often: we assert specific conditions which show our code is broken anyway. I prefer an assertion to fail and directly show which condition was violated than to silently ignore by returning, which may result in a more serious crash later with less info about the cause. This goes a bit in direction Design by Contract and my opinion is that we should start to explicitly document and assert pre and post conditions as well as class invariants.

Regards,

Peter