Re: [boost] [xint] Fourth release, requesting preliminary review again

Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Marius Stoica (letto2_at_[hidden])
Date: 2010-06-02 17:53:23

On Wednesday 02 June 2010 22:24:40 Chad Nelson wrote:

> > The documentation got a bit harder to read since it redundantly
> > repeats the template arguments. Can something be done about that?
> 
> I've thought the same thing, and I don't yet know what to do about it.
> The only way I can think to fix it is to rewrite all of the functions as
> non-templates, purely for documentation purposes.
> 

Not worth the effort... and what would be the purpose of using doxygen then ?
I was thinking there migth be some doxygen option to disable this ? I would 
think this is not the only library to have this issue. Maby make a feature 
request to the doxigen bug tracker ? Frankly it's not that big an issue.

> 
> > Related to that maby you can consider using boost parameter for the
> > template parameters?
> 
> Would that make the documentation easier to read? I don't see any other
> benefit to using it here; there are only three optional parameters, and
> two of them have the same type (bool) so they couldn't benefit from
> Boost.Parameter's automatic deduction.
> 

Why not ? As the parameter docs points out having two bool parameters can get 
confusing. And i don't like having to specify the allocator every time .
Of course is't just some syntactic sugar.

> > I think you should make clear in the documentation what threadsafe
> > means. If it still only means that you can't use copies of xints
> > across threads then some could still want to use them in
> > multithreaded code.
> 
> That's still what it means. I've added further documentation on it, and
> modified the copy constructors to allow optional thread-safe copying of
> non-thread-safe objects; I've uploaded those changes to the sandbox now,
> if you want to see them.
> 

It seems to be missing threadsafe.html

> > From an user's point of view making nothrow just a template argument
> > would make sense .
> 
> Would it? Though similar, they act very differently in the face of
> errors. The nothrow version also needs to support the Not-a-Number
> value, which requires a couple functions that don't make sense for the
> other types.
>

It's just a compile-time option like the other ones.

> > I consider using size_t for size in bits a little
> > confusing/annoying. Maby you should typedef size_t bits_t; ?
> 
> I'm not sure I understand the complaint. size_t is the standard type for
> sizes. Wouldn't introducing a new type, which is just an alias for an
> existing and well-known type, be more confusing to people?
> 

It's just that the size_t is used to count in bytes everywere. That's how you 
usually count syze.

> > Also i'm interested wath do you think about the performamce when
> > using small numbers. I've seen claims that gmp is "only 5% slower "
> > than using plain ints in such cases. I'm thinking that such
> > situations would be quite common in a lot of applications.
> 
> I hadn't considered that usage. I'm not sure how the speed compares to
> plain ints, but I'd be very surprised if it were anything near that
> fast. To make it faster, I'd have to eliminate some of its abilities. Or
> add assembly-language functions, which would break portability.
> 
> > data_t seems quite a bloated class to me .
> 
> It's the central class of the entire library. Reducing its size would
> just mean moving the complexity somewhere else. Most of its size is due
> directly to the requirement that it support allocators, which I was told
> is necessary to be accepted as a Boost library.

I was thinking of maby doing something like this.

bitfield flags;
union {
        intmax_t val;
        data_t* data;
}

and use a flag to see if it's using a val or data. that should make sure that 
small values don't use any allocatin and use little memory.
some of the bools in data_t could be put in the bitfield.