Where do you put your asterisks?

Where do you put your asterisks?

Other urls found in this thread:

en.wikipedia.org/wiki/Argument_from_authority
twitter.com/SFWRedditGifs

on the identifier where it fucking belongs

Depends whether I'm working with const pointers to consts or not.

This, so you don't end up with shit like this
void* foo, bar;

The one the project already uses, or to what my IDE auto formats. Which is most of the time with the star to the name of the var. I don't personally like it.

only a fool declares multiple variables on one line

/thread

/thread

Then how come the compiler doesn't warn you?

only a fool relies on compiler warnings

>this fucking retarded
It's a pointer to a void you nigger, not a void you might decide to dereference later.
void* ptr is the patrician choice. When declaring pointers, you should do them on multiple lines anyway.

>only a fool relies on compiler
ftfy

Straight from K&R

/thread

Just cause it was written down in K&R doesn't mean it's the correct way of doing it. Same for the Linux code style. It's fucking retarded and doesn't accurately reflect what the type is.

>The one the project already uses

In real life, this unfortunately. If you join a team and start wanting to change some fundamental things around then (even if you are objectively right) you'll be garnering hate and will probably relatively soon be forced out one way or another.

I use void * ptr;. *ptr looks like I'm dereferencing ptr and void* looks like a typo. Just like I separate my modifiers from types, unsigned int, const char, typedef whatever symbol, I like to separate the *.

I just figured maybe the person involved in creating the language had a reason to write it like that.

>Just cause it was written down in K&R doesn't mean it's the correct way of doing it. Same for the Linux code style.

Fuck you, heretic.

>It's fucking retarded and doesn't accurately reflect what the type is.

If you don't understand why it's the correct way to do, then apparently it's you who's the retarded one.

int *foo, bar, *baz;
Here bar is an int while foo and baz are pointers to int, because their identifiers are prepended by an asterisk. Now let's try to use your silly style:
int* foo, bar, * baz;
You have to put another asterisk there anyway, which appears to "hang in mid air".

The asterisk in declarations is acting on the variable identifier, NOT on the type identifier. That's why "int *foo" is the only logical style. Using "int* foo" doesn't change in the least how it works but only makes it messy and confusing.

Thank you
/thread

If you declare multiple pointers on one line like that, you're an asshole.

>*ptr looks like I'm dereferencing ptr

No, it doesn't. The asterisk's meaning in declarations is different from what it means in statements (remember that declarations are NOT statements in C). There is nothing wrong with the style used in K&R - quite to the contrary, it's the example of perfect C style to this day. If you try to argue that it's not, you're bound to have misunderstood something.

1. void*
2. one instruction per line
3. typedef

Anything else is unacceptable.

The first one, because it looks right and more legible.

The first one makes sense because *ptr is type void.
The second one makes sense because ptr is type *void.
The third one doesn't make any god damn sense and anyone who uses it is a fucking retard.

>you should do them on multiple lines anyway.
>can't fucking read
>gets confused by simple things cause he insists on using one line for all of his declarations

>You have to put another asterisk there anyway, which appears to "hang in mid air".
>implying you can't do int* foo, bar, *baz
Try it out faggot.
#include

int main() {
int* foo, bar, *baz;

printf("sizeof foo %d\nsizeof bar %d\nsizeof baz %d", sizeof(foo), sizeof(bar), sizeof(baz));
return 0;
}


>The asterisk in declarations is acting on the variable identifier, NOT on the type identifier.
This is probably the stupidest thing I've ever read. So if a int* isn't actually a pointer to an int, what, pray tell, is it?

>Using "int* foo" doesn't change in the least how it works but only makes it messy and confusing.
You say potato, I sat potato. Except my potato is clearly better than yours.

>%d

you disgust me

Whether "declaring multiple pointer on one line like that" is good practice or not is an entirely different issue. Here it was used to illustrate that the "int* foo" style is wrong. As said before, the asterisk in a declaration ALWAYS acts on the variable identifier and NOT on the type identifier. Using "int* foo" style is a silly way to pretend it works another way (by abusing C's loose whitespace parsing rules).

>asshole
Huh, that's a tough one indeed, thanks a lot. Pic related.

DAE take philosophy 101 and tell all their friends the logical fallacies they're committing to sound smart

I use
void* ptr;
because it's more intuitive to me to say
>ptr is a void pointer
rather than
>the content ptr points to is type void

>>implying you can't do
>int* foo, bar, *baz

Yes, you can, but that obviously forces you to suddenly abandon your "I'll attach the asterisk to type identifier" style, doesn't it? On the other hand, being consistent with the "I'll attach the asterisk to the variable identifier allows you to stay, well, consistent.

It IS the correct way of doing it. Lexically, the * is part of the declarator, not the specifier-qualifier list. Thus, the lexically correct way to declare it is actually:

[char]void *ptr;[/code]

>but that obviously forces you to suddenly abandon your "I'll attach the asterisk to type identifier" style, doesn't it?
Only cause you insist on using one line multi-declarations. This would not be an issue if you declared things on multiple lines. I had to use your filthy niggerstyling to exemplify your misunderstandings that you "have to put another asterisk there anyway" which would somehow "hang in mid air", which it clearly doesn't need to thanks to loose whitespace rules. Praise be unto compiler writers.
>On the other hand, being consistent with the "I'll attach the asterisk to the variable identifier allows you to stay, well, consistent.
So does using multiple lines for declarations.

this

std::unique_ptr ptr;

I obviously mean:

void *ptr;

Why is C++ syntax so fucking awful?

Where-ever my team's mandated coding styles tell me to put it, because I'm not a jobless neet like most of you.

The latter is the correct way to think about it though.

>>the content ptr points to is type void
It's not to be understood that way. As said above, declarations are not statements in C, and it so happens that the asterisk operator functions differently in declarations. In statements it dereferences a variable, in declarations it marks the variable a pointer to the type denoted a the beginning of the line. That's all. The fact that your reasoning kinda works is just coincidence.

>This is probably the stupidest thing I've ever read. So if a int* isn't actually a pointer to an int, what, pray tell, is it?

Have you ever read the actual C standard? What you're doing with "int*" is just playing round with C being forgiving about whitespace. If it wasn't, this thread would never have existed, because "int*" would be syntactically invalid in the first place.

>You say potato, I sat potato. Except my potato is clearly better than yours.
Write an email to Brian Kernighan and tell him this.

Legitimately disgusting

>and it so happens that the asterisk operator functions differently in declarations
Which is stupid. If I do
char *str = "aaa";
it looks like I'm assigning "aaa" to *str rather than str.
char* str = "aaa";
is more intuitive, and the only case where it doesn't work is when you're declaring multiple vars on one line, which you can easily avoid.

It needs to be (mostly) backwards compatible to C. This together with a very powerful template metaprogramming language means that the syntax is going to look super funky.

>This would not be an issue if you declared things on multiple lines.
As said above, whether this is good practice or not is an entirely different thing at all, it's not so much about style itself but good practices. But the way that I can be consistent with one way but not the other surely tells a lot (not that it's even decisive though, the real reason why "int *" is correct is pointed out elsewhere).

On the type because it is part of the type.

>Which is stupid.

No, it's not. If you still believe it is then try contacting Brian Kerninghan and/or Ken Thompson (probably your best bets given that Dennis Ritchie has passed away) about that. There's not much more to say really.

Yes it is. Even if it's correct that doesn't make it not stupid.

No, precisely not. The asterisk in a declaration denotes the VARIABLE identifier to be a pointer to the type. This is a fact, read the C standard if unsure.

void * peeps reply to this post.

en.wikipedia.org/wiki/Argument_from_authority

I consider a pointer to a type to be a separate type from the type itself

Nobody here designed the language. If you still feel that way, contact Mr. Kernighan or Mr. Thompson, as advised above. Nobody here is going to change the C standard just for you, nor can explain any further why things are the way they are. You got some explanations, if they don't satisfy you then there's nothing else to learn for you in this thread.

That's the way it's parsed, yes, but it's more intuitive to think of the asterisk as modifying the type rather than the variable.

They are (after Dennis Ritchie) the closest to actually designing the language. Who else is more competent to explain the rationale behind why one style is correct and the other not quite?

Not really. As said above, it's just abuse C's easy-going treatment of whitespace to pretend certain things work differently than they actually do, and this easily leads to problems in edge cases like demonstrated in .

This.

There's a difference between how you think a language should work and how it does work.

I agree that type* variable is more intuitive, but that just isn't how it works. It's a deliberate abuse of whitespace leniency.

If I do
void* ptr;
instead of
void *ptr;
I'm not "pretending certain things work differently than they actually do". Both statements are functionally the same. Who cares how they're parsed?

As for your edge *case*, it's easily avoided by declaring variables on their own lines.

>Which is stupid. If I do

No-one cares how stupid you think it is. str is not of type char*, but str _points_ to a char. A pointer can't really even be classified as a type in C. char is the type that str points to and this only tells the compiler how many bytes it should read when reading str[0].

So how do void* ptr retards declare function pointers?

>I'm not "pretending certain things work differently than they actually do"

Yes, you do (as explained above).

>As for your edge *case*, it's easily avoided by declaring variables on their own lines.

The way the language itself works does not discourage initialization of multiple variables on a single line, it's a matter of practice. There is no abuse of any of the language's features either to facilitate it (as opposed to pretending the asterisk creates different types rather than denoting a specific identifier being declared as a pointer).

They probably either never heard of them, or are afraid of using them anyway.

What if the function returned a pointer? Checkmate, atheists.

IT'S A FUCKING POINTER.

void*
int*
float*
//etc...


THAT'S IT'S TYPE. WHY PUT IT ON THE FUCKING IDENTIFIER? FUCK OFF

The right way to declare a foo as a pointer to a function taking an int argument and returning an int is int (*foo)(int), while the right way to cast foo to a pointer to int is (int *)foo. You could also go ahead and use int(* foo)(int) and (int*) foo, but it's just tomfoolery which tries hard to go against the language's actual logic (according to which the asterisk acts on the variable/function identifier rather than the type identifier).

No, it's not. You fuck off and read the actual C standard.

lol triggered

(void *)(*foo)(void)

Note how both asterisks "stick" to the function identifier, the parentheses serve to denote that one of them denotes foo itself as a pointer, while the other denotes that a pointer is returned when whatever function foo points to in called.

This is incorrect. The pointer is not a part of the type and it's not a part of the specifier-qualifier list either.

If I write this:

const unsigned int* arr[]

Then the specifier-qualifier list will be:

const unsigned int

And the variable declarator will be:

*arr[]

This is objectively true and specifically stated in the C standard.

This. Anyone who refuses to accept this and tries to continue arguing isn't really worth to be wasted time on.

///thread

>const

Thanks, now we can put the final stake through the (void*) foo cuck's heart.

How do you declare foo as a const pointer to int? It's

int const *foo[/cod]

That's literally the only way. The "const" qualifier now separates the type identifier from the asterisk, no more whitespace tomfoolery possible. The end.

Thank you. Definitive answers.

/thread

Now that the discussion is over, i++ or ++i for loop increment?

++i

Elaborate, please

If I'm not mistaken ++i used to compile to somewhat faster machine code than i++. The difference might have become irrelevant with modern compilers though - if that's the case, then I guess picking either is ok for as long as you're consistent with it (i.e. use one of them when just incrementing with pre-fix vs. post-fix being irrelevant).

VBScript for life!

Is coding based on compiler behavior predictions considered good practice?

I know how those are used for prefix and postfix but how would ++i make it faster if it's on a single line by itself? Where did you hear this from? Just curious because I've never heard that before.

This question is grossly overgeneralizing. Just follow credible formatting guides and you'll be fine.

I was thinking of a context like that of

If the increment statement is on its own then there's no reason to use i++ over ++i.

it's part of the type senpai

If you're asking if you should attempt to program in a way that will compile in old compilers than it really depends on the situation (as everything does in programming). Will the people using it always have the version of c++ needed? If no, is it worth making them update to implement said code? It varies. Idk if this is what you meant though.

But why specifically is ++i better? Not just hurr durr it compiles better.

That's the only reason. Otherwise they're the same.

Is there a reason for it though? Why is i++ less efficient? Does it have something to do with the order the compiler sees the variable in memory and increments?

The difference between i++ and ++i is that i++ needs to store the old value of i, which means i++ has an extra instruction for storing the old value in a register or something. An older, shittier compiler might retain that extra instruction even when it's not necessary to store the old value of i.

This is the answer I was looking for, thanks senpai.

Is this true for all c based languages? Or java?

Irrelevant but related point, most CPUs use behavior predictions for branches and jumps anyway so I'd imagine that doing what you suggest is probably not that stupid.

But I wouldn't bother unless you had a crazy efficiency requirement/being embedded.

I switches to void *ptr; a while ago.
But what do I use when returning pointers?

int* foo();
int * foo();
int *foo();

I would assume so. That's how the pre/post-increment operators work.

The last one.
int *foo() means "foo is a function returning a pointer to int", while int (*foo)() means "foo is a pointer to a function returning an int".

Spotted the pajeets who learned java before C

I would imagine that any reasonable compiler from the past 10 years will not store the result of the post-increment if the value isn't being used in the same statement. Still, good post for the double dubs

How about a pointer to a function returning a pointer to a function returning an int?

int (*(*ptr)())();

Is there a better way?

That's indeed the way you do it, there isn't a "better way".

void *src, *dest;

I put in on the identifier, simply because it does not modify the type and obfuscates meaning when people see:
char* ptr_a, val_b;


Though, I would expect any competent C developer to see the problem, and Compilers will output a warning/error if you proceed to treat val_b as a pointer. Regardless, making meaning more obvious is always good.