[bind10-dev] numeric/integer size on CC channel

[Michal 'vorner' Vaner]

Hello

On Thu, Jun 20, 2013 at 05:34:03PM +0900, fujiwara at jprs.co.jp wrote:
> Question
> 
>   1. Do all systems have int64_t and uint64_t (64bit integers) ?

Not all systems, but all systems we support. We definitely use int64_t at some
places, I'm not sure about the uint64_T one, but if the first exists, it's
reasonable to expect the second too. So it is safe to use them.

>   2. Is there performance problem to use int64_t ?

Well, on 32bit machine 64bit numbers are slower (while on 64bit they should be
the same speed). They are twice as large, which may play role when storing many
of them (both for memory consumption and speed, because the data will be slower
to load and may not fit as many of them to cache).

But, compared with our use of virtual methods, several layers of ASIO, network
communication, etc, I think the use of 64bit integers is negligible overhead and
we don't have to worry. Especially if used in the JSON formatting ‒ that one has
much more overhead itself.

> Proposal
> 
>   1. Change type of intElement as int64_t

I'd be careful here. Someone should check nothing breaks because of that (eg.
look through the cases where it is used and check it doesn't break). But
generally, I agree.

>   2. Add uint64Element which holds uint64_t value.

Is there a reason to have int64_t one as well as uint64_t one? I'd like to see a
motivation before adding more data types to that.

>   3. Prepare automatic type conversion among intElement, uint64Element and
>      doubleElement.
>      If converted type cannot carry the value, exceptions will occur.

Again, with automatic conversion, we are stepping on thin ice. I'm not saying we
definitely don't want it, but I'd like to see the motivation/use case for that.

Thank you

-- 
XML is like violence. If it doesn't solve your problem, use more.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130620/c78fbaef/attachment.bin>