On 10/22/2012 12:34 PM, Doug Baskins
As a rule or thumb, I
never use native C types (char, int, long, long long)
except when it simply
does not matter, such as the case you sited or when
there is no choice.
Ah, excellent. I appreciate that rule of thumb. Just to confirm,
you're saying you don't expect it to matter if those "long"
variables end up being 32-bits even in a 64-bit compile of Judy?
The definition of Word_t is the only one I should need to fix?
When Microsoft decided
to require a uint64_t to be "unsigned long long",
I figured they would fix that mistake eventually. At that
time an uint32_t and
uint64_t had not been defined in a consistant place. I
hope it is now in <stdint.h>.
I found a discussion on StackOverflow. Visual Studio 2003-2008
lacked a <stdint.h>, but it is now included in VS2010.
Are you saying it will be better for clarity if the Win64 Word_t
definition says "uint64_t" instead of "long long"? In other words:
typedef unsigned long Word_t, * PWord_t; // expect 32-bit or
typedef uint64_t Word_t, * PWord_t; // In 64-bit Windows, we need
to explicitly specify a 64-bit word, since "long" doesn't scale in
That looks like it should work, and I like the self-documentation of
an explicit "uint64_t".
While I am
reminiscing, I will mention some things about 1.0.5 Judy.
Thanks for those details.
The next version of
Judy does not use "byte" accesses and [...]
The faster version you're working on for future release? Can't
I would be willing to
make a version 1.0.6 of Judy, if someone would submit
(for Microsoft) the
fixes and test it. I do not have a Microsoft Windows
Last time I checked, I could not afford it.
I'm more than happy to do that. With the help of some of John
Skaller's suggestions, I'm working out a configuration that leaves
the source untouched (except for the Win64 tweak to the Word_t
definition in Judy.h), and allows for easy use with Visual Studio.
Ideally, any the Windows-specific or VS-specific files will be in a
separate sub-folder in the repository.
I think I can make a "vsbuild.bat" as an alternative to "build.bat",
using Visual Studio's command-line compiler. Along these lines:
I haven't worked with VS's command-line compiler before, so I'm
still figuring out the cleanest way to handle the *.lib and *.dll
files. I may be able to use your build.bat mostly as-is, or I may
need to make a *.sln solution/project file.
I am a one-person
developer in retirement. Judy is still my
passion and I
am actively working on
a much faster version.
And I greatly appreciate it. I hope this'll work out to make Judy
more easily-available to Windows developers.
I do have access to a couple test computers with Visual Studio 2003
and 2008 Express installed, so I'll be able to test it with them,
I remember correctly, Windows does not pack structures by
sure that the struct
jp_t is 8 or 16 bytes in size with 32 and 64 bit compiles
assert(sizeof(jp_t) == 16);
assert(sizeof(Word_t) == 8); in the 64bit compile.
Neuric Technologies, LLC