Char *str_array[]

char *str_array[]

Cfags will defend this

Other urls found in this thread:

ideone.com/d4A8WP
twitter.com/NSFWRedditImage

ITT: very high effort

It's a stack array of char * pointers.

What is there to defend?

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

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.

I won't. camelCase.

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

I'm a college dropout btw~

>when the language has proper strings

.png well played kind sir

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

>camelCase for locals
You deserve the worst.

camelCase for variables
UPPERCASE for constants
PascalCase for types

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

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

This is the true way

functions are variables like any else

they're pointers to data

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?

jesus christ i fucking hate C.

warning: initialization from incompatible pointer type

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.

>systems hungarian
Gross.

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.

Whoops, my mistake. I think it's clear what I was going for here.
int *a = malloc(sizeof(int));
char *b = (char *)a;

I agree, was just an example.

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.

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

>using pointers for primitive data types

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

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.

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.

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.

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;

Not a bad style either.

Who is this qt

Kouchin from Oreshika

>all pointers are the same size
found the webshit

>On some processors
there are no processors

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

#include
#include

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

dude what?

ideone.com/d4A8WP

you mean they are named memory addresses

Are you saying that it does?

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

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

do you know what the word
>should
means?

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

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

Congratz user

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

String[] array = builder.requestNewStringArray();

Java fags will defend this

You stole my repeating digits

>Implying similar C++ code doesn't exist

property([]).__init__()


Pythonshits will defend this.

>assertion failed
hello, jscuck

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

The standard doesn't guarantee this. See

How come compiles and executes then?

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?

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

something something implementation defined

you only tested one implementation

@60055852
I slapped your mouth tho

C tards BTFO

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.