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

[Michal 'vorner' Vaner]

Hello

On Thu, Jun 20, 2013 at 07:45:17PM +0900, fujiwara at jprs.co.jp wrote:
> > 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.
> 
> C++ JSON output code is used at commands output or statistics output
> on current codes.

Yes, what I mean, this is not performance-sensitive code. We don't need to count
separate instructions there.

> > 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.
> 
> Statistics value is unsigned.
> If we choose 32bit intElement, we cannot carry 32bit unsigned value.
> If we choose 64bit intElement, we cannot carry 64bit unsigned value.
> 
> We must prepare unsigned Element.

That's something I don't agree with. If you use only the positive half of signed
64bit integer, you can store unsigned numbers there. I don't think it is
possible to exhaust that 63 bits of number. The maximum number of signed 64bit
integer is 9223372036854775807, which looks huge enough. If it isn't, that one
more bit won't help.

My opinion here is it is safe to use signed 64bit integer for statistics counter
and saves us trouble with the conversions.

Do we need the doubles anyway? Wouldn't it be just better to use int64_t
everywhere? It would be definitely less work and possibly even introducing less
traps for developers.

> If we add uint64Element, we cannot distinguish positive integer value
> and unsigned integer value.

I don't believe we want to have both signed and unsigned values here (after all,
whole java programming language doesn't have unsigned numbers, and that's
supposed to be general-purpose programming language, not a light-weight
transport for configuration and commands).

> Evaluating doubleElement in integer context is useful.
>   intValue("1.1") == 1

Huh. Scary! Does this evaluate as true?

I would say we don't want this kind of thing. I think it should be sufficient to
use something like static_cast<int>(DoubleElement("1.1").doubleValue()) == 1. I
think this kind of thing is rare.

And I still don't see where we need the doubles in our code. Is it just for
completeness?

With regards

-- 
Anything is possible, unless it's not.

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/4077c9f1/attachment.bin>