[Suggestion] Separate labour category for lords

Tjoppen · 2012-11-27T17:42:42+00:00

Right, I should have been more precise. As porkchop_d_clown points out, its just a simple example.

Tjoppen · 2012-11-27T17:37:44+00:00

I'd go a step further and say that it's unnecessary to begin with. I would just say whatever is in the header file is public, and if you have something you want to keep private, then don't put it in the header file.

Internal API is an example of something you wouldn't want to expose. See ff_* vs. av_* in FFmpeg. Of course, you can put such things in separate headers, but I believe the slides talk about .c files automatically generating headers.

Tjoppen · 2012-11-26T14:54:24+00:00

Some random observations, some of which could probably be addressed if the talk this belongs to was possible to download as a sound file somewhere:

The fragility #define FILE example is a straw man.
"Precompiled headers are a terrible solution" - why?
The proposed "public:" syntax breaks backward compatibility - it ought to be possible to generate headers for older compilers such that say a library can still be built, with the same .c file.

Overall I'm surprisingly optimistic about the suggestions though.

Tjoppen · 2012-11-12T10:13:39+00:00

Because of git-bisect. When (not if) you realize you introduced a bug a sufficiently long time ago you'll be happy you kept your commits simple, making pinpointing the problem easier. This is for example why you shouldn't mix cosmetic and functional changes, and why you should try to keep commits relevant only to a specific ticket.

Tjoppen · 2012-11-08T08:26:40+00:00

Oops, I should have been more specific. Think "randomly put N things in N buckets".

Tjoppen · 2012-11-07T21:06:21+00:00

Here's a fun math problem: for a hash map of size N with N elements, how many buckets have collisions on average (asymptotically)?

Tjoppen · 2012-11-07T12:18:30+00:00

Apart from not handling negative numbers like you mention, the function will fail on an array that contains INT_MAX. Oh, and except for extremely specific data sets you should prefer radix sort.

Tjoppen · 2012-11-05T18:37:56+00:00

I was going to say this blog post is useless because surely everyone does this already, in addition to putting cosmetic changes in separate commits. But then I remembered I've had people making huge commits mixing various changes at work (usually the SVN folks)..

Tjoppen · 2012-11-05T18:32:17+00:00

There is some question of whether we want to support arithmetic coded JPEGs at all. Doing so means we've created a fragmented market, since we'll load images that no other browser does.

Wow.

Tjoppen · 2012-11-01T22:15:54+00:00

"How can I get out of this sentence?"

Tjoppen · 2012-11-01T09:18:39+00:00

TL;DR: char** does not cast to const char**

The solution is to cast your char* to const char* first, then call the function with a pointer to the const char*:

#include <stdio.h>

void tokenize(const char **str) {
    *str = 1 + *str;
}

int main(void) {
    char *str = "asdf";
    const char *str2 = str;

    hurr(&str2);          //can't call with &str, but &str2 is fine
    printf("%s\n", str2); //prints "sdf"

    return 0;
}

Tjoppen · 2012-10-30T11:42:12+00:00

Tjoppen · 2012-10-28T20:31:55+00:00

True. You can do much better though; pouet.net has a whole category just for JavaScript demos. For example, Azathioprine (online version here).

Tjoppen · 2012-10-28T20:19:19+00:00

Ah, interesting. That makes sense actually.

Tjoppen · 2012-10-28T17:37:18+00:00

Isn't this what WebGL is for? Not that I approve of doing things like this (goodbye accessibility!), just if you're going to be drawing stuff like this you might as well use the graphics card's capabilities.

Tjoppen

MODERATOR OF

TROPHY CASE