On 10/22/2012 12:34 PM, Doug Baskins wrote:

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:

#ifndef _WORD_T
#define _WORD_T
#ifndef _WIN64
typedef unsigned long    Word_t, * PWord_t;  // expect 32-bit or 64-bit words.
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 _WIN64.

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 wait.

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
development path.  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, too.

PS.  If I remember correctly, Windows does not pack structures by default.  Make
sure that the struct jp_t is 8 or 16 bytes in size with 32 and 64 bit compiles respectively. 
I.E. assert(sizeof(jp_t) == 16); assert(sizeof(Word_t) == 8);  in the 64bit compile.
Will do.

Tim Margheim
Neuric Technologies, LLC