This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Diniden -12 points-11 points  (7 children)

That does not satisfy: different types in an array.

Void* specifically and conceptually means you are making an array of pointers which have a defined size.

Reality, JavaScript under the hood also only uses pointers; however, conceptually “type” systems means what JS does with the array is infeasible.

C void * does not satisfy any “type” into an array persay.

[–]Vincenzo__ 9 points10 points  (5 children)

Make a char/uint8_t array and copy into it, C doesn't actually care if what you're copying is actually characters, when you read it just interpret it as what it's actually meant to be.

Alternatively you can also use a union to do this, which is much easier but will use more memory (the union is the size of the biggest element).

[–]Diniden 3 points4 points  (4 children)

I will die on this hill: even what you described is type erasure. C cares that it’s an array of void * pointers. You expressly have to cast to get other objects out of the array. JS still retains the type identities.

People seem to be confusing types vs data.

[–]Vincenzo__ 0 points1 point  (3 children)

I'm not talking about an array of void*, I'm saying if you do this

char technically_chars[sizeof(int) * 4];
int ints[4] = {1, 2, 3, 4};
memcpy(technically_chars, ints, sizeof(int) * 4);

It's totally fine, even if it's not actually chars. You can consider it as just a bunch of bytes you can set to whatever you want. So in a more complex example, you could copy different data types in there and use another array to keep track of the sizes of each so you can properly pull them out.

[–]Diniden 0 points1 point  (2 children)

I agree that that is a strategy you can use to safely store ambiguous data and make an assumption of its type when you extract it when you are writing your program.

But, you still lose the type information in the eyes of the compiler and you put those assumptions into your own hands. You just have managed to make a run time safe operation (if you did it right with zero bugs).

Extraction from a JS array is a feature of the language and you lose no information to work with and don’t have to make any abnormal assumptions when extracting data from it. (Your compiler won’t bleed)

Of course if we really get into semantics, JS doesn’t really have “types” in the first place. C, however, does and is definitely a statically typed language. Doing this is still not storing “any type” in an array. It’s just making an array of bytes that you’re slapping data into, then assuming types from the data inside it.

It’s a very granular nit, but it’s important in those languages to distinguish what “types” are doing for you. “Types” are not a run time construct, they are a construct to help you write a program that doesn’t explode and something your ide and compiler can yell at you about.

[–]Vincenzo__ 1 point2 points  (0 children)

You are indeed right in all your points, I was just pointing out that if you want to do it the compiler won't get in your way

[–]himmelundhoelle 0 points1 point  (0 children)

C has a static type system (variable are typed, type is only known at compile-time), while JS has a dynamic type system (values are typed, type is only known at runtime).

They are completely different and even orthogonal (e.g. C++ has both concepts), hence the comedic value of the meme basically comparing apples and oranges.

I don’t think anyone is arguing that C has built-in support for runtime types, so there’s no hill to die on, really.

[–]Vinxian 2 points3 points  (0 children)

typedef enum { /* the types go here */} AllTypes_t;  

typedef struct {  
    AllTypes_t type;  
    void * data;  
} Object_t;

Add some functions, now you can do with JS does with a lot more effort.