On 10/22/2012 12:34 PM, Doug Baskins wrote:
Tim:
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.
http://stackoverflow.com/questions/126279/c99-stdint-h-header-and-ms-visual-studio#2628014
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.
#else
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.
#endif
#endif
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:
http://stackoverflow.com/questions/84404/using-visual-studios-cl-from-a-normal-command-line
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 inretirement. Judy is still my passion and I
am actively working on a much fasterversion.
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
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel
