You're viewing a single thread.
The fact it's a pointer is part of the type, not part of the variable name. So
int* pis the way.You would think so, but
int* a, bis actually eqivalent toint* a; int b, so the asterisk actually does go with the name. Writingint* a, *bis inconsistent, soint *a, *bis the way to go.Yeah, and I'd say that's a design flaw of the language as it is unintuitive behaviour.
When people say “pointers are hard”, they mean “I have no idea where the star goes and now an ampersand is also implicated”.
That's the part where you give up and randomly shove/unshove symbols in until the code works.
I've definitely never been guilty of this. /s
While technically true, that's also one of the worst 'features' of the language and I personally consider it a bug in the language. Use two lines and make it clear and correct.
Don't declare more than 1 pointer per line. This resolves that, badly.
Alright, I'll never, ever write something this way now. Good to know.
This is true in C, but not in D.
Then again, at least in C, the mantra is "declaration follows usage". Surely you don't write pointer dereferences as
* ptr? Most likely not, you most likely write it as*ptr. The idea behind theint *ptr;syntax is basically that when you do*ptr, you get anint.And with this idea, stuff like function pointers (
int (*f)(void)), arrays of pointers (int *a[10]) versus pointers of arrays (int (*a)[10]) etc. start making sense. It's certainly not the best way to design the syntax, and I'm as much a fan of the Pascal-styled "type follows the identifier" syntax (e.g.let x: number;) as anyone, but the C way does have a rhyme and a reason for the way it is.int* i, jThe C syntax is just messed up.
I don't get it. What's wrong with this?
It's part of the type yet it's also a unique identifier. That's the whole thing with east or west
const.const int *is aimmutablemutable pointer that points tomutableimmutable memory.int *constis amutableimmutable pointer that points toimmutablememory.int const *is the same type as the first example, aimmutablemutable pointer that points tomutableimmutable memory.Same stuff applies to references which makes it easier to think of the variable owning the
*or&as if you want that pointer or reference to beconstit has to go after.Edit:I am a moron who managed to get it exactly backwards :|
Found the guy that can probably do function pointers!
I wrote a couple unholy lines of C++ the other day using the ternary conditional operator to select a class member function to be called with a fixed argument.
I think my teammates were too scared to call me out on it.
KISS, my guy.
It's actually simpler than doing it the "right" way, but I wanted to see how much I could make C++ pretend it was Python.
Lol yeah. I don't even really write C++ but I sure as shit know a bunch of syntax and junk haha
I think you've got it backwards. I learned to read pointer decls from right-to-left, so
const int *is a (mutable) pointer to an int which is const whileint *constis a const pointer to a (mutable) int.Fuck me man that's what I get for writing that just before bed
I always read it right to left and it seems to make sense to me.
I do this in my code because it looks better and makes more sense...until I decide to declare 2 vars on one line and then I use the very cursed
int* a, *bI just wouldn't do that.
tbh I always think about it as 'p' is a pointer to int
therefore *p is an int
therefore I should call it int *p;
however, of course, you should use what your team prefers. Having good yet inconsistent style is worst than mid consistent style.
I don't code much C++, but then I'd lose alignment with:
x = *p;and I feel that would bug me.I'm looking at Google Style Guide for my next project and it says either is fine, just don't declare more than one per line.
And yet the default clang formatter gets it wrong.