georgef · HackerTrans

قبل 12 سنةdiscuss

I'm reminded here that JPEG includes arithmetic encoding as part of the standard, but almost everyone uses Huffman because up until a couple years ago arithmetic encoding was patent-encumbered (the patents are expired now). Is anyone aware of a study like Mozilla's that considers JPEG-with-arithmetic-encoding? Or perhaps it does, and I failed to notice?

Most competing file formats seem to beat JPEG by only a slim margin, and what I've read on arithmetic encoding suggests it gives a ~5-10% gain, which would make that difference slimmer still, perhaps vanishing into the uncertainty of the usefulness of these quality benchmarks. Of course, there would be inertia to overcome to support it, as with a new format, but recompiling everyone's libjpeg is surely less work than adding support for whole new file formats. At the very least, it seems there might be a better effort/payoff ratio.

georgef

قبل 12 سنةdiscuss

It varies a lot, though. My T1D supplies (as a college student on my parents' insurance) cost more like $50-$75 a month.

georgef

قبل 12 سنةdiscuss

POSIX make really does make auto dependencies hard, but GNU make actually solves this fairly cleanly by adding an include directive. As long as you have a script or program to process a file and spit out its dependencies in make style (e.g., GCC does this for C and C++ with its -M flags), you can just include the outputs of that process and make will do the rest.

For example, here's how I handle a simple C project.

    CSRC := [list .c files here]
    DEPS := $(CSRC:.c=.d)
    
    [standard statements for building go here]
    
    %.d: %.c
            gcc -MM -MF $@ $<
    
    -include $(DEPS)

Poof. Automatic dependency handling. You can see how any sort of dependency that can be detected by some sort of preprocessor can be plugged in here.

georgef

قبل 13 سنةdiscuss

Less typing is exactly the benefit, and with it less chance of error because of less repeated code. It is also another way of showing parallelism in your code.

And again, the wrong impression is conveyed (that you are declaring a variable of type char* instead of a pointer type that dereferences to a char).

With more complex types, not understanding what is really going on makes code incredibly opaque (and that typographical style ad hoc). What would you do with this:

    char *((*func)(char *));

That isn't a char pointer at all. It's a pointer to a function that takes a char pointer as an argument and returns (i.e., evaluates to) a char pointer. It looks incredibly dense (to me, at least), unless I think of it in the way I talked about above (in which case it all makes sense and is kind of cool).

With the convention used in the article, the declaration would be something like this:

    char* ((* func)(char*));

Which doesn't make clear why the outside parentheses are needed, or why there is a dereference (or multiplication?) operator in front of the variable name.

The idea of a variable declaration being an expression that evaluates to a basic type is actually the reason why the same symbol * is used in the declaration and in the dereferencing of pointers: they mean the same thing.

Basically, what I am trying to say is that the typographical practice used in the article is at odds with the actual meaning of the statement (and the explanation he gives shows he clearly does misunderstand the statement), which can only lead to confusion in the long run, especially when you encounter code written by other people. Or, as with your example, it can lead to eschewing a useful feature of a language simply because it doesn't look pretty according to your arbitrary whitespace conventions.

georgef

قبل 13 سنةdiscuss

When I first started programming in C, I did the same thing with pointers (i.e.,

    char* str;

instead of

    char *str;

).

Unfortunately, this creates the wrong impression that

    char* str1, str2;

creates two pointer-to-char variables, whereas actually str1 is a char pointer and str2 is simply a char. Indeed, I was confused on this point myself when I was a newbie, which led to great confusion later on.

The clearest way I've ever found to think about C declarations (ironically, I think I read this in some article maligning C's syntax in favor of Go's), is that each declaration is of the format

    [type] [expressions--one for each new variable--that equate to type];

Thus, the way I think of declaring a char pointer is

    char [de-referencing the variable (which is a char pointer) to arrive at the char];
    char *str;

(Obviously, not everyone is going to agree that that is simple, but it works for me and my brain.)

Anyway, the point is that while typography is great, it can be just as harmful as helpful if you communicate the wrong impression to the reader. And to be fair, it really looks like the author is not at home in C: besides his misconception about pointer declaration, he didn't bat an eye at the old-style argument-declaration syntax that has been obsolete since ANSI C.

Also, I hope I never write a for loop that looks so massively bloated--a matter of opinion I guess.

comments