char *str_array[] Cfags will defend this

>>60051693
ITT: very high effort

It's a stack array of char * pointers.

What is there to defend?

>>60052007

There is no good reason type information should bind syntactically to the variable name instead of the type name.

>>60052114
Well that's good, because a pointer is not a type.
It's a pointer to a type.
For all practical purposes, all pointers are the same size, the only reason C even makes the distinction is so it can know what offset of bytes it needs to multiply by in order to retrieve array members.

>>60051693
I won't. camelCase.

This. Rust is the true anime language. Desuuuuuuuuuuinayyyyy ^.^

>>60052234
I'm a college dropout btw~

File: 1480754565613.png (40KB, 232x254px) Image search: [Google]

40KB, 232x254px

>when the language has proper strings

>>60051693
.png well played kind sir

>>60052162

>a pointer is not a type.
You cannot cast to something which is not a type.

>>60052196
>camelCase for locals
You deserve the worst.

>>60052347
camelCase for variables
UPPERCASE for constants
PascalCase for types

>>60052322
You're casting to a pointer of a type.
Pointers get special treatment.

>>60052375
PascalCase for types
UPPERCASE for macros
camelCase for functions
snake_case for variables and constants (that ain't macros).

This is the true way

>>60052437
functions are variables like any else

they're pointers to data

>>60052387

int *a = malloc(sizeof(int));
char *b = (int *)a;

In this code, what type does the cast operator take and what type does it return?

>>60052464
>>60051693
jesus christ i fucking hate C.

>>60052464
warning: initialization from incompatible pointer type

>>60052462
And? You don't call variables. You can make distinctions in whatever you want, just as if I want to use p_ for pointers m_ for memeber variables, etc... If you define a function, you name it with camelCase, otherwise is a variable and goes with snake_case.

>>60052521

>systems hungarian
Gross.

>>60052464
Takes an int*, and then returns an int*, but since the return value is of type char* an implicid cast is done resulting in a warning.

>>60052570

Whoops, my mistake. I think it's clear what I was going for here.

int *a = malloc(sizeof(int));
char *b = (char *)a;

>>60052548
I agree, was just an example.

>>60052590
Well you really don't need to know what was the original type, now it's a pointer to char and that's all that matters.

>>60052521
> You don't call variables
On some processors, you can. You could actually manually compile regexes to char array and call that. There's no need to overcomplicate stuff and introduce a new concept for a function. Functions are just variables.

File: 1444914295494.jpg (19KB, 250x250px) Image search: [Google]

19KB, 250x250px

>using pointers for primitive data types

>>60052627
>>60052570
>>60052570

>an int*
>of type char*
>a pointer to char
Cool, glad we're in agreement here. So now the question has to be asked, if the types of a and b are int* and char*, why should * bind to the variable name rather than the type name?

>>60052661
For fucking christ, it's systantic stuff, if you can or you can't is the less of my worries, what I want to know is what a fuck that name is, and just saying "data" doesn't usually help.

>>60052689
I usually write it like this:

int* a = malloc(sizeof(int));
char* b = (char*) a;

It makes more sense, but again this is sintax, just do what you feel better with.

>>60052766

That notation makes sense, but it can be easily misleading.

int* a, b, c; /* int* a; int b; int c; */

This is why * should bind to the type name rather than the variable name. Pointers are, after all, a type parameterized on another type.

>>60052818
This never happens to me becouse when I create a pointer either I initialize it with something, or I initialize it with NULL. That makes it always one line per variable.

int* a = NULL;
int* b = a;
int* c = nullptr;

if you want one-liner:

int* a = NULL; int* b = a; int* c = nullptr;

>>60052882

Not a bad style either.

>>60051693
Who is this qt

File: kouchin.png (518KB, 1200x800px) Image search: [Google]

518KB, 1200x800px

>>60053643

Kouchin from Oreshika

>>60052162
>all pointers are the same size
found the webshit

>>60052661
>On some processors
there are no processors

>>60052818
>This is why * should bind to the type name
and this is why you should learn c

>>60055390

#include <assert.h>
#include <stdio.h>

int main()
{
    assert(sizeof(void*) == sizeof(char*));
    assert(sizeof(void*) == sizeof(int*));
    puts("hello world!");
    return 0;
}

>>60055390

dude what?

>>60055452
https://ideone.com/d4A8WP

>>60052462
you mean they are named memory addresses

>>60055448

Are you saying that it does?

>>60055511
no, I'm saying you don't know how declarations work

>>60055491
Address width depends on the architecture. E.g. x86 vs x86_64.

>>60055448
do you know what the word
>should
means?

>>60055547

Do share. It's what the thread is for after all.

>>60055555

Of course, but a char* is the same size as an int* is the same size as a void* etc.

>>60055555
Congratz anon

>>60051693

EnterpriseObjectFactory.Builder builder = new EnterpriseObjectFactory.Builder(EnterpriseObjectFactory.STRING || EnterpriseObjectFactory.ARRAY);

String[] array = builder.requestNewStringArray();

Java fags will defend this

>>60055555
You stole my repeating digits

>>60055645
>Implying similar C++ code doesn't exist

>>60051745

property([]).__init__()

Pythonshits will defend this.

>>60055452
>assertion failed
>>60055496
hello, jscuck

>>60055577
>a char* is the same size as an int*
false
>is the same size as a void*
the char*, yes, the int* no

>>60055577
The standard doesn't guarantee this. See >>60055720

>>60055720

How come >>60055452 compiles and executes then?

>>60055769

I'm not surprised that the standard doesn't guarantee it but are there any real world cases where it doesn't work?

They are all just memory addresses, right?

>>60055775
it works on x86/x86_64 but isn't guaranteed to work on other architectures by the standard

>>60055775
something something implementation defined

>>60055775
you only tested one implementation

@60055852
I slapped your mouth tho

>>60051693
C tards BTFO

>>60052437
kebab-case for everything, as LISP intended. It's the most racially tolerant way.

If you dont like C style strings then use an library, or make you're own string library. Fucking brainlets.