Typedefs & Linus
lkml.indiana.edu
lkml.indiana.edu
But don't do this in high-level code. There, you should use types that are as descriptive as possible, as that will greatly improve readability and maintainability.
A C compiler will generally keep you from forgetting that just fine.
p = q + offset
*p = *q + offset
Consider:
unsigned long addr_t = &x;
warning: initialization makes integer from pointer without a cast
Without explicit casts, the compiler won't let you confuse pointers with integers without a warning or an error.
Of course C will also let you treat pointers as integers and vice versa, especially if you explicitly tell it to, by casts. But in the general case, it will whine and, in fact, reducing unnecessary whining is one of the reasons to not go hog-wild with useless typedefs. I'm not sure how we got here, I think one person here doesn't know C very well and the rest of us got into a little and completely tangential C nerdfest.
Hmm that's fair. I also think I started entering kernel-dev mode where you have to carefully watch everything that you do, whereas most people probably have C experience with the benefit of things like the C standard library.
For whatever it's worth, I was seeking to reference the idiom where you store an address as an integer in order to do some hardware operations. You have to keep semantic knowledge of that integer as really being a pointer even though it's, for the moment, stored as an integer. In cases like this the C compiler is no help whatsoever.
$ cat test.c
int x;
unsigned long addr_t = &x;
$ cc test.c
test.c:2: warning: initialization makes integer from pointer without a castThe fact that the Linux kernel works on such disparate architectures also works against your point.
If you know how to make
__asm__ __volatile__(...)
portable I'd love to hear it.
That's a point in favor of Ruby's "the most readable solution is the most elegant" philosophy over, say, Perl's inverse: It's cool to feel like a member of the club, but if writing that extra line means a beginner (or even a child) can more easily figure out what it does, and she gets interested in programming because of it, that's a lot better for the hacking community as a whole.
Most of the times you see Perl hackers celebrate some kind of complex syntax expression, it's mostly not the syntax they're enjoying, but the expressed principle. You could still hide it behind a DSL, which most of the time makes sense anyway in production code; DRY and all that. But that would also hide the principles and implementation that was used. So, in generally the Perl community will communicate ideas and concepts via short Perl snippets, and Perl's freedom of syntax makes that easily possible even on Twitter or IRC.
In Perl, expressiveness was always very important. It was just done by the use of symbols and syntax instead of words. It's always a trade-off between being able to read an algorithm without knowing the language, and being able to express your ideas concisely. Personally, I have more troubles with sigil-less variables than with any implementation that uses any kind of symbol to identify them. Others find them distracting. It's a personal choice.
If you have complex nested expressions in Python that do lots of things, you should put it in a function and call it by name. It's the same thing in Perl.
Log message: the_t world_t would_t be_t a_t better_t place_t if_t some_t people_t did_t not_t feel_t the_t need_t to_t typedef_t everything_t
> And never _ever_ make the "pointerness" part of the type. People who
> write
> typedef struct urb_struct * urbp_t;
> (or whatever the name was) should just be shot. I was _soo_ happy to see
> that crap get excised from the kernel USB drivers.
Why?
However, for simple types like int and float, there's no performance advantage to passing the value as a reference. It generally takes as long to construct the temporary reference as it does to copy the value.
For more complex types like structures or objects, then yeah, you're better off passing by reference.
Read my response. I'm not talking about performance, you shouldn't be copying around large structs or strings no matter what, I'm talking about code readability.
In general, your compiler will optimize the crap out of primitive type copies (and most struct copies too, these days) anyway, so it's less of a performance argument as it used to be.
I don't want to read your function call that looks like it passes a whole object and have to check the function header to see that it's actually a reference getting passed, I'd rather see the address taking right at the function call.
[1] http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...
I really don't understand what you are complaining about. Earlier you said you didn't like references being modified by functions to which they are parameters. Now you are complaining about the use of pointers as parameters? In a language like C++, it's pretty difficult to do neither.
http://lkml.indiana.edu/hypermail/linux/kernel/0206.1/0843.h...
My usual rule is to not inline anything that calls a full fledged function, and to only explicitly inline things that are truly on high performance paths. Basically, trust that the compiler will inline or not inline the rest as appropriate. But this is another interesting metric to consider.
That's pretty much correct. Keep in mind, though, that inline has different consequences in a header file. There are good and bad reasons for that kind of usage.
Just do this: printk("count: " COUNTER_T_FORMAT_SPECIFIER "things", c);
printk("subtotals: a %d, b %d, c %d, total %d\n", a,b,c,a+b+c);
you have
printk("subtotals: a " COUNTER_T_FORMAT_SPECIFIER ", b " COUNTER_T_FORMAT_SPECIFIER ", c " COUNTER_T_FORMAT_SPECIFIER ", total " COUNTER_T_FORMAT_SPECIFIER "\n", a,b,c,a+b+c);
and soon you (1) can't read your code at all because 60% of it is shouty stuff in your calls to printk and (2) even the printk calls are awkward to read because your eyes have to skip over all the shouty stuff to work out what the output's actually going to look like.
(Perhaps that was your point, in which case I apologize for thinking it needed spelling out more explicitly.)
However, if printk would be declared with __attribute__((format(printf, 1, 2)) (I don't know if it is), gcc would warn if the format string contains specifiers which do not match the given types, regardless of any typedefs.
http://lkml.indiana.edu/hypermail/linux/kernel/0206.1/0398.h...
"We actually have real _problems_ due to this in the kernel, where people use "off_t", and it's not easily printk'able across different architectures (we used to have this same problem with size_t)."
I see the problem with printk, but giving up the ability to typedef architecture-dependent types such as size_t because of it? The proper reaction, IMO, would have been to fix printk. Given that gcc already checks compatibility between format strings and arguments, it should not be that hard to add a special format character (say %?), and have the compiler replace it by a correct character for the argument passed.
"We should also have some format for printing out "u32/u64" etc, but that's another issue and has the problem that gcc won't understand them, so adding new formats is _hard_ from a maintenance standpoint. "
do they not use inttypes.h for that?