On 18/02/2014, at 1:25 PM, John Meacham wrote:
> On Mon, Feb 17, 2014 at 10:59 AM, Alan Silverstein <[email protected]> wrote:
>>
> debugging. I use a JudyL array to associate meta-info with each memory
> location,this is much better than adding tag words to the blocks themselves
> as it doesn't change the layout at all which often can obscure bugs.
Yes, I do that too, its very nice.
> autoconf is great,
I beg to differ: IMHO its a heap of rubbish.
The whole concept is extremely bad. It's "suck it and see" concept
hides issues and can't work in a cross compilation context, or even
with multiple compilers (as I have).
Autoconf is also very annoying when it fails because to build
or upgrade a package you end up having to build or upgrade
autoconf too.
The way forward is standardisation.
> those things you don't appreciate how tricky it is to do portably until you
> come accross a non-autoconfed package you need to install.
You don't appreciate how utterly bad autoconf is until you have
to modify a build to make it work and you get presented with
a totally impenetrable mess. Even the help is a heap of crap,
letting you a whole lot of non-interesting rubbish and NOT telling
you the things you actually need to know for your specific package.
What you have to understand is the most code doesn't
require ANY configuration. Something like Judy, for example,
only needs ONE configuration parameter (32 or 64 bits).
I have a compiler with fairly extensive libraries that
provides platform independent stuff for most services
including async socket I/O, and some configuration is
certainly necessary. Surprising little though.
Autoconf has one (and only one) legitimate use:
building low level system tools (binutils) and of course
your compiler (gcc, clang, etc).
After that its the *compilers* job to provide a standard API.
> I always assumed the odd API was to conform to some internal HP coding
> standard created by someone who has a history with algol (hence the in/out
> arguments) I've seen odder ones forced on programmers out there.
The C API is not odd, its perfect. Every argument is more or less
exactly as it should be (give or take a casting which is the inevitable
result of using crap languages like C).
The MACRO API is crap. It hides where you need to use
an lvalue and where an rvalue will do. That's bad idea in C
(and an even worse one in C++).
> another is by using actual structures the compiler can do alias analysis.
> for instance
>
> foo(judyl_t *j, int *x) {
> if (jEmpty(*j))
> blah;
> *x = 0;
> if (jEmpty(*j))
> bar;
> }
>
> Since judyl_t and int are different types, the compiler can assume that x
> does not point to the same memory location as j, meaning it can combine both
> jEmpty calls into one caching the result and removing a load. It would not
> be able to do this with Pvoid_t values without explicitly checking if x == j.
Unfortunately, alias tests is compilers are really dangerous.
Because the type system is so weak people cast left right
and centre. In my compiler I do it systematically and I have
to put -fno-strict-aliasing. I wish I don't have to do this but
unfortunately C just doesn't have a good enough type system
or semantics to avoid it sometimes ;(
C++ is a bit better, but it's still a problem.
--
john skaller
[email protected]
http://felix-lang.org
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel
