.

The '*' is not a part of the type declaration (suprisingly), so

 void *ptr; 

And that's because of

 void *a, *b, *c;

((void (*)(void))void)();

>>61015267
It feels like it should be a part of the type declaration though. It feels like I should be making a "void pointer" data type, not a "void" type but then saying "actually I want a pointer that'll dereference into that type".

>>61015234
>void *ptr

What is this? 1975?

>>61015267
You shouldn't declare multiple variables on one line regardless

>>61015296
>it's X but it should have been Y
C has some awful design flaws, that we've been forced to live with since the 70s.

>>61015267
I'm not a huge fan of multiple declarations, because
1) variables should be initialised on declaration to avoid potential mistakes
2) with C99 and newer, variables should be declared first when needed (minimal scope declarations)

char a, *b, **c

The type of a is char.
The type of *b is char.
The type of **c is char.

>>61015351
How many compilers don't actually support C99 at this point?

>>61015502
It's not so much about compiler support, but more about what legacy projects still use. If you write Linux LKMs for example, they will spit out warnings if you don't declare your variables C89-style.

As for actual compilers, MSVC doesn't support anything newer than C89. But it does support C++ though.

void
*
ptr
;

>>61015296
>MUH FEELINGS
Well its a good thing we are working in a logic language and not a feeligns language.
You are declaring a void. Deal with it.

>>61015310
Its part of the standard. There is nothing wrong with it.
can you explain why you have an issue with it?

>>61017861
If void* isn't the type, then explain to me why this isn't valid:

void a;

>>61017884
fuck you

>>61015234
None.

Because using pointers in the current year is retarded and only old farts who still think they are relevant will use a programming language that allows this sort of garbage.

typedef void* void_ptr;

:^)

>>61017918
>I am afraid of memory management.

>>61017948

typedef void * pointer_to_an_unspecified_region_of_memory_t;

>>61017953
>reinventing the wheel
Of course your time is not important, you're either a NEET or an old fucker on verge of death.

>>61017884
void *a is generating a memory address without bullshitting around with type limitations

void a is obviously retarded. If this were python or something without types then it would be normal I guess. Why would you ever want a type of "void" if you arnt working with memory addresses?

>>61018120
>void *a is generating a memory address without bullshitting around with type limitations
Really? No limitations, you say. Then explain to me why this is illegal then:

void* a = "hello, world\n";

>Why would you ever want a type of "void" if you arnt working with memory addresses?
My point is that the pointer-type (aka void*) is clearly the type, not void.

>>61018293
gcc doesn't even give me any warnings for that

>>61018293
My guess would be that "Hello, world\n" is a string made up of an array of memory addresses which would be equilivant to char a[14];. It wouldnt fit into a single memory address.

>>61018327
Well, that's why you shouldn't rely on compilers to identify (potential) undefined behaviour.

void* a = "hello, world\n";
char* b = a;
b[5] = 'c'; // this is UB

>>61018354
Why is that undefined?

>>61018345
That's not the problem. The problem is that "hello, world\n" is a string literal. String literals are by definition const memory, meaning that any decent compiler will put them into read-only section of memory. This assignment casts away the const modifier, and can potentially lead to undefined behaviour (see >>61018354)

>>61018374
See >>61018388

b points to a string literal.

>>61017884
If *void is the type, then explain to me why this is valid:

void func(){/*some code*/}

>>61018388
Yea, I saw that example.

void* a = "hello, world\n";

is basically a buffer overflow, is it not?
would something like the following work? Im not compiling shit for a 4chan debate

void *a[14] = "hello, world\n";

Each character takes one memory address. That is the reason your example is invalid. You cant fit a sentence into the space of a single letter.

>>61015234
First one, since indirection is not part of the type, but rather part of the relationship between the type and the variable.

>>61018479
It would have to be

void a[14] = "hello, world\n";

and you can't declare an array of voids

>>61017884
Void isn't a type. It indicates the absence of a variable.

>>61018354
That shouldn't be any more undefined than casting a char * to a void *.

>>61018479
>is basically a buffer overflow, is it not?
No

>Each character takes one memory address.
No

>That is the reason your example is invalid. You cant fit a sentence into the space of a single letter.
char* points only to the address of the first byte. You're confusing pointers and arrays. String literals are not char arrays, they are memory references to read-only memory.

printf("%zu %zu %zu\n", sizeof(void*), sizeof(int*), sizeof(long long int*)); // these should all be the same size

>>61018533
The string literal "hello, world\n", which a points to, is located in read-only memory. Trying to modify that region of memory is undefined behavior.

>>61018479
>>61018511
No, it wouldn't be a buffer overflow, since a string on the right side of an initialization statement is creating a string literal. In C, a void may point to a string literal without any casting.

>>61018533
You're missing the point. The undefined behaviour is GCC implicitly casting away the const modifier, without even providing a warning.

>>61018557
Well yeah, modifying a string literal is illegal obviously. I meant using a string literal to initialize a void pointer.

>>61018511
>void a[14] = "hello, world\n";
This doesn't compile.

>>61018592
>and you can't declare an array of voids

>>61018572
I'm pretty sure C doesn't require string literals to be declared const, it just states that modifying them may invoke UB. It's C++ that complains if you initialize a pointer-to-non-const-char with a string literal.

>>61018581
>I meant using a string literal to initialize a void pointer.
The string literal is just a memory reference (aka an address) to where the actual content is stored.

>>61018511
>and you can't declare an array of voids
Well then that seems like the issue.
You should be using "char a" instead anyway.

But you asked why you cant fit a string into a char and I explained that.

While on this subject, seeing your example I am reminded of something that was done like

char *a[14] = {'h','e','l','l','o',',',' ','w','o','r','l','d','\n'};

Its been a long time since I have programed anything and its eluding me, what is the difference in this and the way you put it

>>61015573
>As for actual compilers, MSVC doesn't support anything newer than C89
What? For real??

>>61018603
That's because void isn't a type.

>>61018612
>I'm pretty sure C doesn't require string literals to be declared const, it just states that modifying them may invoke UB.
I'm not entirely sure, I thought that even just casting away the const was UB. But maybe I'm mistaken.

>>61018439
What the fuck is *void

>>61018640
Yes, for real.

>>61018616
This is also undefined behaviour:

char* a = "hello, world\n";
a[5] = 'c'; 

>what is the difference in this and the way you put it
Well, first of all your example is invalid. You have declared a as an array of char pointers, but you're initialising it as an array of chars.

Secondly, pointers and arrays are not the same thing. In C, arrays are contiguous memory areas. Pointers are memory references. HOWEVER, and this is important, a pointer MAY point to a contiguous memory area (aka it may reference an array).

>>61018613
A string literal isn't JUST an address, it's an expression that A) constructs* a string in potentially non-writable memory and B) returns a pointer to the first character. It's basically a compile-time equivalent of a constructor (in the C++ sense).

*I think C implementations are allowed to do string interning if the same string literal is used multiple times, since you're required to treat them as immutable anyways

But in any case, a char * can be assigned to a void * variable without issues, so logically using a string literal to initialize a void pointer should be fine.

File: string_representation.jpg (14KB, 560x191px) Image search: [Google]

14KB, 560x191px

>>61018692
>so undefined behaviour:
Been drinking and forgot to edit the astrict out.
I was focusing on everything after the = sign.

In your example you are declaring it as if it was a string, but what I was remembering is declaring the array using = { "H", 'e', ...}; with the brackets and everything.

>>61018640
In practice it supports a lot of C99 features, simply because those features are part of C++ (and MSVC is primarily a C++ compiler). But it doesn't make any attempt to meet any official C standards beyond C89. You might get away with using C99 constructs is MSVC, but that's purely incidental.

>>61015234
Option 1, but with only one space.

>>61019150
>he doesnt use tab in the middle of declaration

>>61015351
You can initialize on declaration with the single-line style though.

>>61017918
Anon, you cannot use a scripting language like Javascript, Python, or Lua, unless you understand what a pointer is. Otherwise you'll be terribly confused by the behavior of objects, lists, dicts, etc.

>>61019200
https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/

File: 1495596089113.jpg (67KB, 720x715px) Image search: [Google]

67KB, 720x715px

>>61015234
Do whatever the hell you want but at least be consistent about it.

>>61019435
Higher-level languages honestly confuse me more than C because I never know whether it's copying the object or just passing a reference

>>61019535
It's almost always a reference because that's the only behavior that makes sense from a performance standpoint.

>>61019643
For aggregate types*

>>61015310
I've always been fine declaring multiple things on one line if they were effectively the same sort of thing in the code (not just the type).

For example, if I have am declaring both row major order arrays, as well as just another general array for something else, I might do this.

double *a, *b, *c; // Matrices
double *x; // Other array

I do agree that declaring all of those one line would be bad practice, though.

void* ptr;

because it makes sense and all that old documentation that shows otherwise is wrong.

Tabs are also better than an arbitrary number of whitespaces you fuck.

>>61019692
>Tabs are also better than an arbitrary number of whitespaces you fuck.

I'd wager that 90%+ of developers who use spaces agree that tabs for indenting and spaces for alignment is objectively the best way to apply white space to your code. However, close to 100% of competent developers who program in a professional environment also realize that it only takes one fuckup to start pressing tab for alignment that fucks up the entire system. Forcing spaces on everyone fixes this. Similarly, 100% of competent developers are too busy making actually programming, and just have a checkbox marked in there IDE/Editor that says "Expand tab into spaces", and don't worry about trivial shit like this.

>>61015234

void *ptr

This is the best way to define pointers. If you pretend that the * is actually part of the name, you can use it just like any other variable name.

>>61015234
void* ptr

Be the change you want to see in C.

>>61019745
>tabs for indenting and spaces for alignment
Nobody agrees that mixing tabs and spaces is a good idea. Fuck off.

Other points are accurate though

>>61019692
>>61019745
>>61019769
I don't like the idea of one character having a different width than every other character

>>61015234
>>61015296
int *p

* is the dereference operator. You declare a variable p that dereferences to an integer.
(dereference) p is an int

>>61019765
> There are people in the world who advocate putting the star with the type, but who also advocate the "p" hungarian notation prefix.
Really makes you think.

File: 1476130917511.png (4KB, 100x116px) Image search: [Google]

4KB, 100x116px

>>61019787
but it doesn't anon, it's a single character. You can tell your text editor to replace it with whatever you want, including how wide it is. I like 3 space width, but that's just how my text editor is rendering it.

I actually render tabs like this, so I know they're tabs and not whitespaces.

>>61019769
>Nobody agrees that mixing tabs and spaces is a good idea. Fuck off.

You might be retarded if you use tabs for alignment. What do you do if you want dont want to align your text in some factor of the tabwidth? What will you do when someone opens your file and displays tabs a different width, and suddenly all your alignment is off? There are literally zero good reasons to ever use tabs for alignment.

File: 1487599720333.png (116KB, 800x600px) Image search: [Google]

116KB, 800x600px

>>61019857
im retarded anon forgive me, sublime also has a cool way to show the difference between tabs and spaces.

>>61019886
Which is why no one should ever use tabs under any circumstances ever.

>>61015267
/thread.

the multiple declarations are just a symptom of the issue, not the core of it.

people who write

void* ptr;

and similar are trying to make a language into something it is not, which just makes them look stupid.

>>61020009
Multiple declarations are a useful and intuitive way to group logically-related variables together, not a "symptom."

>>61019745
If you're going to use tabs, you might as well be writing code in Microsoft Word. Since the width of tabs can vary between environments, they're basically incompatible with a column count limit. And many editors treat a tab as a single character, which will mess up your column counts anyways.

>>61019835
It's not a Hungarian prefix, since "tr" isn't meaningful on its own. It's literally just naming what the variable is, that has nothing to do with Hungarian.

>>61019846
Not all editors have that feature.

>>61015234
The first in C and C++, the second in C#

>>61015267
This

>>61020182
>Not all editors have that feature.
editing tab width is like the _most basic_ of text editor features.

File: 1467203526952.gif (835KB, 280x189px) Image search: [Google]

835KB, 280x189px

>>61015267
wait, so if you just had

void *a, b, c;

b and c wouldn't be pointers?

>>61020299
Yes. But the worst part is in

void* a, b, c;

b and c won't be pointers as well.

>>61015234
the second one. It's a void pointer not a ptr pointer.

File: 1483374457300.gif (387KB, 269x270px) Image search: [Google]

387KB, 269x270px

>>61020330
oh god I've been doing it all wrong, I need to go.

>>61020299
Strictly speaking, that's not legal C at all. But on some old compilers you end up with b and c as chars.

>>61020344
In C, you declare variables the way you will invoke them. That guides how you place the stars, brackets, etc.

>>61020408
>In C, you declare variables the way you will invoke them
There's no standard requiring this. Unless you follow hungarian notation, this makes no sense to me.

>>61020441
It's the way C's variable declaration syntax was designed and intended.

>>61020468
There isn't a syntax, man. You choose to do it that way or you don't. And if it's the way K&R says it should be, that doesn't mean it's set in stone.

File: gnome-mpv-shot0001.jpg (283KB, 1920x1080px) Image search: [Google]

283KB, 1920x1080px

>>61020512
It's a mnemonic that makes sense.

>>61015234
2 is the LOGICAL way, but it's not how it works. 1 simply to not shoot yourself in the foot in the future.

>>61020560
I don't follow. when you declare an int or a char or a byte, you don't do anything to the variable name. Why would you do anything differently for pointers?

Actually thank you, you helped me realize it doesn't matter what way it's done. I like my way but who cares?

>>61015234

auto &thing = another_thing;

>>61020606
You declare a pointer like this:

int *x;

and you deref it like this:
*x
Therefore the declaration exactly mirrors the way the variable is accessed.

The same rule applies to typedefs:

typedef int **type_t[12][3];
type_t x

you get an int back out of that using

**x[0][0]

>>61020645
>you deref it like this
exactly you deref it with *. Which is a separate symbol than declaring a pointer. They really should have used carets or some other symbol to indicate a dereference over a pointer.

>>61020705
They chose not to because declarations in C mirror the way you access the variable. It's a choice that's designed into the language. It is the same symbol on purpose.

>>61018374
b points to the "hello world\n" in the data section. In this case it has nothing to do with the fact that a is a void*. If you wrote

void* a = strdup("hello, world\n");

instead, then it would be well defined

>>61020768
>>61018374
I think this part is well-defined:

void *a = "hello world"

Dereferencing a (after casting it) and reading from it are also well-defined. But trying to write to the destination of a is undefined. Could be a segfault, could modify just that string, could modify _anywhere_ that uses the string literal "hello world" if it gets deduplicated (or just everywhere in the same translation unit.) I have observed multiple different behaviors on different compilers/platforms.

>>61015296
Thats because you are thinking about it wrong.
* gets the value of the representation of the pointer.
So by doing int *ptr, the thing "*ptr" is an int, "ptr" is a pointer to an int

>>61020829
that's what I just said (>>61020768)

>>61020299
>he's been making first-year CS mistakes all along
bruh

>>61015234
>2017
>C instead of asm

>>61015234
it's not a matter of debate, 1st is the correct one

"Declaration follows usage" is a retarded design decision, and it falls apart as soon as you start initializing your variables too.

char *a = malloc(sizeof a);
*a = malloc(sizeof a); // pure nonsense. Initialization does not follow the same rules as assignment.

There's a good reason every language that came after C tried to bury this mistake.

>>61024336
>There's a good reason every language that came after C tried to bury this mistake.
This.

>>61024336
It's "usage," not initialization.

File: 1478235803588.jpg (15KB, 388x341px) Image search: [Google]

15KB, 388x341px

>>61020360
I made that mistake in the past. I guess I'm retarded.

>>61026434

I guess usage doesn't extend as far as assignments.

>>61015234
The last one is so utterly retarded I'm pretty sure if I grepped the leaked NT source code I'd find a bunch of it.

>>61026878
I've never looked in the NT source myself,

>>61026827
It's a fair point, but the reason for "declaration follows usage" is mainly to give you a way to know how to place your stars and brackets. If you used a completely different set of symbols and rules as suggested by >>61020705 then remembering how to declare something like an array of pointers would be more difficult.

>>61027164
myself, but I've heard it's not too bad.*

>>61027164

I'm not saying replace all the special characters, that's pointless.

I don't think it would be difficult to make declarations for complicated types if the pointer and array symbols were moved out of the declarator and into the tpe specifier. You simply have to pop the operations off one at a time right to left.

char*[n][m]* foo; // pointer to m sized array of n sized array of pointer to char

>>61027427
So you want the order of indexes when accessing a 2D array to be backwards from the order of indexes when declaring it? That sounds dangerously confusing.

>>61027483
That's actually a very good point. Doesn't Go do it the other way around? That seems too ugly though.
Or I suppose you could simply move the "declaration follows usage" style into the type specifier itself, but that doesn't sit right either.

*((*char)[n][m]) foo; //left ()s because I can't immediately remember the precedence rules

>>61015267
this

>>61015234
The first one I prefer, I think most people will agree that the middle is the worst.

>>61027943

The first one is the most rational, but not perfect.
The second one is either ignorant or wishful thinking.
The third one is retarded.

>>61027592
Go declares arrays like

[]string

but accesses them (although technically its a slice, not an array)

string[0]

It's really weird, I don't know why they designed it like that.

>>61028149
>It's really weird, I don't know why they designed it like that.
Because of C legacy.

>>61028176

what does Go have to do with C?

>>61015267
fpbp

>>61028176
But C doesnt declare arrays with the brackets as a prefix though?

>>61028250
If you look at who made Go, you'll realise that there's a bunch of familiar names: Rob Pike, Brian Kernighan, Alan Donovan etc... These were all to a point involved in C's development, and they've forced their archaic "UNIX philosophy" onto Go and practically ruined it. Kernighan is even the coauthor of K&R.

>>61028307
Go arrays (or slices) are more like pointers, because they're dynamic resizable. The [] in front reflects that.

>>61028110
Well at least we can agree the first is the best, Most IDE's use the first, which pretty much confirm this.

>>61017918
>I am a web developer

>>61019942
There's a reason, and is this:

if (hurr){
  broken()
         arbitrary = 'retarded alignment';
    derp();
 }

People not respecting indentation because adding the right amount of spaces is too hard a concept.

>>61017971
enterprise

>>61019535

Fucking this. Reference semantics should coincide with reference syntax. Just let make dereferencing explicit.

File: 1494023346114.jpg (113KB, 940x629px) Image search: [Google]

113KB, 940x629px

this thread is fucking autistic

in C:

void *ptr

in c++ and c#

void* ptr

>>61015234
a void pointer with the name ptr
void* ptr;

File: 563847.jpg (26KB, 390x344px) Image search: [Google]

26KB, 390x344px

>>61029168
>not being autistic enough to enjoy this thread

>>61020869
In turn I could say that to me "int* ptr" looks like ptr is a pointer to an int, which holds up as long as you don't declare multiple variables on one line.
It just depends on how your mind interprets it.

>* gets the value of the representation of the pointer.

This is nitpicking but that's not worded right, the representation of the pointer is platform specific.

e.g 32 bits address on x86, 64 bits address on x86_64

>>61015267
how would you do
void * volatile * ptr?