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.