"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:4D7E2D5D.5050304@providere-consulting.com...
I don't think fixed size integers are necessary for a Boost bigint proposal to begin with.
Why? First, AFAIK a significant portion of 'bigint' usage falls into the realm of cryptography and encryption keys which usually have fixed power-of-two sizes and both 'fixed' and 'power-of-two' almost always translate to great simplification/efficiency improvements when one gets to the implementation level. This naturally translates to the question "why should I pay for usage of new, try, catch and throw if all I want is to construct a statically known fixed-size public RSA key and use it to verify a message"? Second, AFAICT they are trivial to implement (with the right internal design of course, which was demanded of XInt long time ago but it never happened).
However, since are provided, I'd like them to be handled as well as possible. Chad has already said that he expects support for them to improve and that's good enough for me, since it won't require breaking the interface.
Maybe I've missed it but I haven't seen concrete ideas as to how exactly Chad plans to do it (especially if he continues to stick with the current design and the attitude of not being bothered that dynamic memory allocation and exception handling are used where there is no really need for either).
Probably a fraction of the time spent arguing about it (and coming up with pointless arguments like that of a 'performant swap')...
Pointless?
Defending dynamic-memory allocation (as opposed to static-sized/stack storage) solely with the argument that it allows for faster swaps is pointless: who designs a class to have a fast swap while paying for it in almost all other operations (i.e. pessimizes real usage for the sake of an auxiliary operation)? Plus, swaping fixed-size integers (PODs) is still pretty trivial (a few rep movs or memcpy calls).
The fact that you refuse to listen to advice, even such 'ancient truisms' as 'decoupling is always right',
It isn't. If there's one thing I hate more than anything else, it's blindly applying rules, while forgetting the reason that the rules exist to begin with.
Juraj probably had a nice laugh seeing me accused of blindly following rules ;-) My statement may have been overly simple, but with all other things being equal (e.g. no efficiency compromises) decoupling can be seen as the opposite of writing spaghetti code, i.e. the opposite of something that is always wrong and in that sense right. It also need not imply an expanded public interface. -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman