3 ms·
> And never _ever_ make the "pointerness" part of the type. People who > write > typedef struct urb_struct * urbp_t; > (or whatever the n
by leif 16y ago
> 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.
Amen. And people who use ampersand pass-by-reference in C++ ( foo(int &i) ).
- jamesaguilar 16y ago> And people who use ampersand pass-by-reference in C++ ( foo(int &i) ). Why?
- gryan 16y agoI don't know what the OP's beef is. There's nothing semantically wrong or confusing about this. 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.
- leif 16y agoYeah, I didn't mean "int" to be the offensive part. 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.
- leif 16y agoBecause it gives you no more power than passing a pointer. If you're handling pointers, it's better to be totally explicit about what you're doing. 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.
- jamesaguilar 16y agoA decent point. Google uses the pointer-ness or const-reference-ness of a parameter to signal what the parameter is going to be used for [1]. But at the end of the day reference modification is the kind of basic language feature that you should expect to see people using. [1] http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...
- leif 16y agoThis actually bothered me to no end at google. At the API level, it's great, I can learn a lot about what your function is going to do just by looking at the signature, but when reading code that uses an API I don't know, it's hell. For me, the extra help you get by looking at a function signature really isn't that great, when I should have the same information available in the documentation that had damn well better accompany the function signature in your header.
- jamesaguilar 16y agoHeader documentation and pointer-as-output conventions are both typically available in the Google libraries I've used. 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.
- leif 16y agoNo, I'm not opposed to references being modified by functions, I'm opposed to the "ampersand" syntax of C++. I am fully in support of just passing a pointer and being straightforward about it.
- Locke1689 16y agoI completely agree with you. Worse, if at some point you actually need a pointer of the object to do arithmetic you end up grabbing a pointer of the reference which just puts everything to hell.