Where do you put your asterisks?

on the identifier where it fucking belongs

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

>>57947879
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.

>>57947924
only a fool declares multiple variables on one line

>>57947879
/thread

>>57947879
>>57947943
/thread

>>57947942
Then how come the compiler doesn't warn you?

>>57947994
only a fool relies on compiler warnings

>>57947879
>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.

>>57948002
>only a fool relies on compiler
ftfy

File: 2016-12-11-172807_592x855_scrot.png (174KB, 592x855px) Image search: [Google]

174KB, 592x855px

>>57948033
Straight from K&R

>>57947964
>>57947879
>>57947943
/thread

>>57948082
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.

>>57947932
>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 *.

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

>>57948138
>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.

>>57948281
Thank you
/thread

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

>>57948228
>*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.

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

>>57947861
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.

File: 1469698232130.png (74KB, 802x561px) Image search: [Google]

74KB, 802x561px

>>57948281
>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 <stdio.h>

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.

>>57948435
>%d

you disgust me

File: 6a00d8341c5a0553ef015390755e91970b-800wi.jpg (68KB, 640x486px) Image search: [Google]

68KB, 640x486px

>>57948321
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.

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

>>57947861
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

>>57948435
>>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.

>>57948281
>>57948138
>>57948082

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]

>>57948568
>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.

>>57948549
this

std::unique_ptr<void> ptr;

>>57948594
>>57948281
>>57948138
>>57948082

I obviously mean:

void *ptr;

>>57948630
Why is C++ syntax so fucking awful?

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

>>57948549
>>57948620

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

>>57948549
>>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.

>>57948435
>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.

>>57948630
Legitimately disgusting

>>57948690
>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.

>>57948647
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.

>>57948619
>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.

>>57948740
>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.

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

>>57948783
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.

>>57948784
https://en.wikipedia.org/wiki/Argument_from_authority

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

>>57948801
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.

>>57948803
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.

>>57948815
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?

>>57948838
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 >>57948281.

>>57947924
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.

>>57948878
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.

>>57948740
>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?

>>57948925
>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).

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

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

>>57947924
>>57947879
IT'S A FUCKING POINTER.

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

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

>>57949023
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).

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

>>57949214
lol triggered

>>57949182

(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.

>>57949214

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.

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

///thread

>>57949344
>>57949484
Thank you. Definitive answers.

/thread

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

>>57949547
++i

>>57949603
Elaborate, please

>>57949622
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).

>>57947942

VBScript for life!

>>57949678
Is coding based on compiler behavior predictions considered good practice?

>>57949678
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.

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

>>57949756
I was thinking of a context like that of >>57949678

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

File: 1280px-D_Programming_Language_logo.svg.png (314KB, 1280x970px) Image search: [Google]

314KB, 1280x970px

it's part of the type senpai

>>57949772
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.

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

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

>>57949873
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?

>>57949724
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.

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

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

>>57949722
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.

>>57947861
I switches to

void *ptr;

a while ago.
But what do I use when returning pointers?

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

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

>>57950055
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".

>>57948033
>>57949214

Spotted the pajeets who learned java before C

>>57949933
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

>>57950127
>>57950055
How about a pointer to a function returning a pointer to a function returning an int?

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

Is there a better way?

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

void *src, *dest;

>>57947861
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.

>>57949678
This is certainly interesting knowledge, but this is a very good example of premature optimization. Most compilers will likely optimize this away, and it *does* make the code slightly less readable.

int *a;

But for functions:

void f(int* x);

>>57948740

You can't dereference *str as a char and than "put" a multi byte string "in it".

You can however assign the starting address of a string to a char pointer str.

>>57952996

same poster:

sorry meant to reply to another post. obviously I'm with you

>>57952771
>But for functions:
>void f(int* x);

No, that's nonsense. There is no reason whatsoever to do it. The asterisk always belongs with the variable/function identifier, NEVER with the type identifier.

>>57947879
Thanks for the input Linus

#define MAKE_PTR(x) typedef x* x##_ptr;
MAKE_PTR(void);

//...

void_ptr x, y;

>>57953340
what the fuck

>>57948740
you are assigning "aaa" to *str you dolt. "aaa" is a pointer to the first a in 'a','a','a','\0'.

>>57953371
It's the Proper(tm) way of doing things.

There is no ambiguity. Just define your types ahead of time.

MAKE_PTR(int);
MAKE_PTR(void);
MAKE_PTR(some_struct);

int main()
{
    int_ptr x, y;
    scanf("%d,%d", x, y);
    printf("%d,%d\n", *x, *y);
}

>>57953387
"aaa" is a pointer to ['a', 'a', 'a', '\0'], so it's assigned to str, not *str.

>>57947861
Doesn't matter because each is undefined behavior.

>>57947861
When declaring pointers and functions returning pointers, I use >>57947879. But when casting, I use

(void*) x

.

>>57948815
The "argument from authority" is only invalid when it's actually an argument from (irrelevant) authority.

>>57953534
Wouldn't this segfault? You haven't allocated any storage for x or y, and they're both pointing to random addresses.

>>57953909
lol no they're not

Inside your mother

they belong to the left in my opinion, but because of the way C handles those the first option is correct

it's a variable of type pointer to void, so the * stating that it's a pointer should be part of the type, not the identifier

>>57948740
>the only case where it doesn't work is when you're declaring multiple vars on one line
umm... about that...
not exactly true

>>57953819
It is not a pointer to ['a', 'a', 'a', '\0'], it is a pointer to 'a'. There is not concept of array and string size in C. The compiler just puts 'a', 'a', 'a', '\0' somewhere is memory and passes you a pointer to it.

>>57949921
not that anon, but i++ is essentially two steps: evaluating i, then incrementing it. ++i is just the second step. obviously any compiler worth its weight in salt isn't going to notice a difference

void *ptr;
(char *)ptr;
char *argv[];
void *(*threadFunction)(void *);

>>57948817
Reality considers you to be a retard.

void * x looks nicest

Just finished an assignment on pointers. It was nightmare fuel and I have taken java and Python prior to this. Dynamic memory allocation just makes my head swirl.

>>57947861
In whichever way my employer's coding standard tells me to.

>>57947861
ostensibly it depends on what kind of thing I'm working with, but usually I end up putting them directly in front of the variable name because that's the first style I learned and it stuck

>>57948630
using greater than and less than as fucking angle brackets was a mistake, every single time, because they're not angle brackets and no one actually uses angle brackets

on the type since it is a pointer to that type

int* p

>>57949344
the C standard is trash, it leaves huge gaps just to account for systems that aren't even being used any more, because old devs are autistically sentimental about some theoretical future compiler that adheres to modern standards being written for them

File: teller.jpg (80KB, 900x900px) Image search: [Google]

80KB, 900x900px

>>57947861

For C++:

void* ptr;

For C:

void *ptr;

in C++ i can imagine seeing the pointer as a "type" being convenient, and it also prevents awkward spacing for things like vector, for example:

std::vector<something *> vec;

looks fucking awful

that being said, in C you also cast pointers a lot, which results in the same spacing issue

thing = (something *)(malloc(sizeof(something)));

which is still ugly but either way it works
just use whichever one makes more sense to you

>>57947861
the first one is the only correct one, apart from having two spaces for no reason.

>>57956482
>that being said, in C you also cast pointers a lot
No you don't.
Only fucking idiots cast malloc.

>>57954701
care to explain?

>>57956482
>in C you also cast pointers a lot
You're doing something horribly wrong if you're casting pointers a lot. It's rare to see pointer casts used for anything other than casting from the subclass to the base class when dealing with polymorphism.

>>57959002
>polymorphism
>C

>>57959484
There is a hacky way you can do it.
However, it's pretty fucking stupid to do, and it's unclear whether its undefined behaviour or not.

Pointers are a meme, using them is a sure way to get a segmentation fault error from hell.

>>57947861

//for vars
void *meme;

void* meme();

>>57958740
REEEEEEEEEEEEE

Don't you know you ALWAYS CAST malloc()?
1. You tell dev what the intention of malloc is
> what type?
2. It makes the code compatible with C++ and older compilers.

>>57960920
>You tell dev what the intention of malloc is
99.99% of the time, the type is right next to where malloc is being used:

int myarray = malloc(sizeof *int * 100);

It also violates the DRY principle.
>2. It makes the code compatible with C++ and older compilers.
My code already isn't compatible with C++ and older compilers. I'm not some fuckit that limits myself to the subset of C89 and C++98 for no fucking reason.

>>57960944
>sizeof *int
That was a mistake, but you get the point.

>>57959799
Then explain why I'm using pointers all the damn time and I don't even remember the last time I got a segfault.
Oh I know why, it's because I'm not retarded.

>>57960944
DRY principle considered harmful

>>57955358
>nicest

C isn't your safe space.

void *x

is the correct way, anything is irrelevant.

>>57956243
Then be glad you learned the actually correct way, unlike the other cucks here trying to argue a moot point.

>>57956311
No. Read the fucking thread (or, even better, the fucking C standard).

File: 220px-Ken_n_dennis.jpg (8KB, 220x143px) Image search: [Google]

8KB, 220x143px

>>57956328
>the C standard is trash

Hahahahaha, nigga. What you believe is more relevant?

>>57954215
>C
>my opinion

Choose one.

>>57954984
This. That's the way to do these things. Screw those who do

char **argv

(or, even worse,

char** argv

), obfuscating the fact that it's an array of pointers (rather than just a pointer to a pointer) that is getting passed.

>>57958740
>Only fucking idiots don't cast malloc (which, by it's nature, returns a (void *)).

>>57947861
put them at *args and **kwargs

>>57959002
>C
>classes

>>57959503
>it's unclear whether its undefined behaviour or not

Wow, that's like what, (undefined behaviour)^2?

>>57960944
You assign the return value of malloc() to an int? That's interesting.

>>57954984
This is the correct answer.

You should follow the grammar of the language. If you don't, the result will be misleading. For example consider this:

char*  a,b,c;

The way the spacing is done, it (incorrectly) implies that all three variables will be pointers. That code is misleading for exactly the same reason this code is misleading:

int x = a+b  *  c+d;

File: domney.png (126KB, 315x357px) Image search: [Google]

126KB, 315x357px

void*nospace;

>>57948321
Just name your fucking variables better. It isn't hard.

int *pSize, iSize, *pCount

Slightly more detail would be even better, such as maybe piSize for pointer to ints, pd for pointer to double, etc. Most importantly all programmers participating follow the same naming standard.

Who had the bright idea of using the multiplication symbol for both multiplication and pointers?

>>57967569
The symbol itself is an asterisk. It's not inherently a "multiplication symbol". The function of any symbol is entirely context-dependent. The dereference operator is a unary operator, while the multiplication operator is a binary operator. Both are represented by the asterisk symbol (0x2A).

void *const ptr;

>>57967569
>00101010
>"muh multiplication symbol"
>projecting this hard

>>57967721
>>57968951
Why reuse the same symbol for two operations though?

>>57968993
I am more triggered by whoever decided to use = for assignment

>>57969018
You'd rather use := ?

>>57968993
Why not if they cannot be confused with with each other by anyone with half a brain? Can you provide any example where the symbol's meaning would be really ambiguous (i.e. you couldn't tell if there is a multiplication or a dereference to be performed)? Why don't you have a problem with the ampersand being used for both bitwise-AND and reference (i.e. "address-of"), or the comma used as both an operator and just punctuation elsewhere (declarations, variadic fuction parameter lists etc.)? Would you prefer having to use some outlandish non-ASCII symbols for operators because of having ran out of symbols to represent them?

>>57947924

This.

>>57947861
I usually put it on the variable name, but sometimes I'm a naughty boy and put it on the type :3

Please spank me!! Oh i am naughty!!!!!

std::unique_ptr<T> ptr

>unscoped raw pointers in the year of our lord two-thousand sixteen

>>57970415

>taking all the fun out of C++

Yuck. Just take up Java, already.

File: computer.jpg (38KB, 380x250px) Image search: [Google]

38KB, 380x250px

>>57947861
I am black so I do this

void * pointizzle_ma_nizzle;

>>57970469

    void                                                            *
  ptr;

>>57969958
←, <-, :=, pretty much anything

>>57970760
Why? Assigment is equality as well. It's just imperative equality (the side effect of "foo = 5;" being "MAKE foo equal to 5") as opposed to interrogative equality (the expression "foo == 5" evaluating to the answer to the question "IS foo equal to 5?").

This is making me think of the tadpole operator:

x = (y + 1) % 10;
x = (y + 1) * (z - 1);
x = (wcslen(s) + 1) * sizeof(wchar_t);

becomes:

x = -~y % 10;
x = -~y * ~-z;
x = -~wcslen(s) * sizeof(wchar_t);

https://blogs.msdn.microsoft.com/oldnewthing/20150525-00/?p=45044

>>57949023
Typedef my own type, like a fucking proper programmer.

>>57947861
What's the asterisk symbol for?
(Web programmer here.)

>>57971438
>Web programmer
It's nothing you should worry about. Move along.

>>57948033

int* const ptr; //doesn't do what you think it does
int const *ptr; //exactly what you think it does
int const * const ptr; //exactly what you think it does

maybe you should just stick with a language more your speed like javascript or php

>>57971494
OK. Thought it's some cool feature I should learn about.

>>57948740
>it looks like I'm assigning "aaa" to *str
Because you are. str is just a location, *str is where your string is.

Let's start a const placement argument?

const char *constAlwaysComesFirst;

>>57971649
>const always comes first
except when it doesn't.
const is read right to left.

http://man.openbsd.org/OpenBSD-current/man9/style.9
https://www.freebsd.org/cgi/man.cgi?query=style&manpath=FreeBSD+10.3-RELEASE+and+Ports