[Gtkradiant] [Bug 1109] Wrong calculationofBEZIERCURVETREE_MAX_INDEX

[Joseph, William]

The value also has to be a power of two - the largest representable
power of two.
The way you're using numeric_limits makes a (possibly safe) assumption
that numeric_limits<size_t>::max() will be (2^n - 1). If it's not, then
the result won't be a power of two.
Bit-shifting is the obvious way to calculate 2^n at compile-time.

This is the way I would do it:
std::size_t(1) << ((sizeof(std::size_t) * 8) - 1)

this compiles on x86:
std::size_t(1) << 31 // 2^31

and on x86_64:
std::size_t(1) << 63 // 2^63

To test that the value is correct, create a patch cyclinder. If it looks
curved, then it's working.

-SPoG

-----Original Message-----
From: gtkradiant-bounces at zerowing.idsoftware.com
[mailto:gtkradiant-bounces at zerowing.idsoftware.com] On Behalf Of
namespace
Sent: 12 September 2006 16:43
To: GtkRadiant developer discussion
Subject: Re: [Gtkradiant] [Bug 1109] Wrong
calculationofBEZIERCURVETREE_MAX_INDEX

> The calculation uses size_t because BEZIERCURVETREE_MAX_INDEX is
> supposed to be the largest integer representable with a native type on
> whatever architecture you're compiling for - if it was supposed to be
> the same on all architectures then it would just be:
>
> const std::size_t BEZIERCURVETREE_MAX_INDEX = 2147483648;
>
> Though it never really needs to be that big anyway =).
>
> -SPoG

So it just needs to be the numeric max of size_t, ok I didn't knew that.
Are there any special reasons why it was done with bitshift magic?
The STL way looks clearer to me.

namespace

-- 
Home: www.codecreator.net |
GPG: http://www.codecreator.net/gpg-public.asc | 0xD4BD516D