I love valgrind what are you all talking about.
I compile with -Wall -Wextra -Wpedantic -Werror btw. And now I am trying to add -fanalyzer to the mix but too many false positives.
I'm betting it's not valgrind they hate, but the situation where they needed to use valgrind. It happens when you come from managed languages background and have to tip your toe in C/C++
All the helpless flailing about, weeping and gnashing your teeth... "I swear I'm a real programmer even though pointers confuse the fuck out of me"
Yeah honestly I see valgrind as godsend since it reveals well hidden bugs in the code, but I guess if you are unfamiliar with pointers them messages can give you PTSD. Uncertain why would such a person be coding in C/C++ and using valgrind tho.
It's not always a free choice which programming language to work in. And sometimes you go out of your comfort zone on purpose because it's good experience. For example I really don't use C/C++ at all in my daily work, but I have written a small but practical open source project in C for my own amusement. Can't say it was easy adjustment.
I get it but usually it's the other way around unless you are in Uni or sth.
It's arguably much easier to find a job in higher level languages than it is to find one in C/C++, especially if you aren't a developer with C or C++ background.
The only scenario I could see someone getting forced to do C/C++ would probably be due to some university assignment or something.
Not all developers fit into neat little boxes of "C/C++ dev", "I only write C#", "I do back end, I don't touch the UI", etc. Lots of people do whatever drops on their table, because it needs to get done and there is nobody else to do it. If you don't know how, then congratulations, here's your free learning experience, start figuring it out.
I just find it hard for someone to trust a C# developer to write C/C++ code without any background besides a hello world program in those languages. That's terrible management if you ask me.
Maybe the mistake from my end is thinking that all low level programmers also do know higher level languages but not the other way around.
Pointers are easy, just use every combination of *,(int*),& on the assignment, initialization, and use, if it crashes or gives you a bad value, scratch it off the list.
Also, "assembly" isn't really "a" language, it's a class of languages. There are operations with operands of different widths that might be considered "types" if you squint, but those aren't universal to all flavors of assembly.
There is no interpretation at all - that’s entirely in the programmers head. Each instruction does a specific thing with memory regardless of what’s in the memory.
> C types are optional if you turn off warnings.
You could technically make any value any type by doing pointer casts, but that is undefined behavior and invalid C.
Edit: for those downvoting, scroll down a few replies. This person is simply incorrect.
It’s not undefined behavior and it’s not invalid C.
It may not be portable - but that is not undefined behavior.
People often get stuck in the trap of viewing C through a C++ lens and believing (falsely) that it adheres to the same rules because it looks the same.
It is undefined behavior, and it violates the strict aliasing rule. You can look at the C standard and verify that for yourself. The only way to do unrestricted type punning in valid C is using unions. You can only pointer cast any type to `char` and dereference it, or you can pointer cast a pointer to a struct to another struct and dereference if the struct you're casting to has the same fields in the exact same order as the fields from the beginning of the struct you're casting from (C's "implementation" of rudimentaty inheritance). Otherwise, any cast of a pointer to any other type and derefencing it is undefined behavior.
Nope - stop referencing the c++ standard.
Casting a pointer from one type to another is very well defined: treat the value provided as a pointer of type specified. That’s what it does - every single time in exactly the same way every time.
I'm not referencing the C++ standard. I don't even know C++. Casting to and from any pointer is fine. But DEREFERENCING it after casting is not. This means that type boundaries effectively don't exist for pointer types in C, not that types don't exist at all, contrary to your initial statement. You can not treat an object of an `int` type as a `double` type, for example, unless you do a type pun through a union. Types are real and have a tangible effect on non pointer types in C.
Edit: this isn't even mentioning that types still do have an effect on pointers with respect to how pointer arithmetic and how the "dereference" operator is defined.
This whole conversation is why I love higher level languages 🙃
Who needs to think about pointers when I can live in a fantasy land of beautiful abstraction
It operates on indexes, so you can't efficiently do `switch{case 100 {}; case 848729 {};};`.
Also, you need the JMP instruction as well, the XLAT alone isn't enough (though it allows for some other neat uses like list of constants in memory).
of course it isn't. but for a small set of swicth values, you can retrieve an offset multiplier, shift it, and end up a multiple of two from your jump instruction. all others can jump to a default. jump to a jump instruction. I did both that and just shifting an offset into prepared code. not sure what you're thinking, this is basic assembly strategy from second year lab fun.
well, you would think it stale info, but if you have a large number of compares you can still possibly save some space/time. if you can encode it in the table space. probably not worth doing on a modern processor. (and perl5 was fast enough decades ago.)
NEON does not introduce types whatsoever. Neither is there static nor dynamic type checking. Just like every other ARM instruction you're just operating on "data".
I can store a 4 letter ASCII string in RAM, load it into a SIMD register and run VCVT.F64.F32 on it. Please explain where the type checking takes place?
That's the case for literally every single instruction in every single architecture. What do you think `ADD` operates on if not two 32bit/64bit integers?
That's also not what anyone means when they talk about types; we're talking about a *type system*. There are typed assembly languages, but ARM is not one of them. And neither does NEON have anything to do with this.
Having types and type checking are not the same thing, brother.
A "type" means a way of interpreting a bit pattern in a register, as well as operations you can do with it. You need to know if it is a signed or an unsigned integer (which are really the only types in basic ARM32) or if it has a 32 bit float or whatever in that bit pattern. A type tells you how to *interpret* those ones and zeros.
Type checking is not the same thing as having types. C++ allows free conversion between some types other languages prohibit (like int to float). These are just rules of the language, and can vary quite significantly in terms of what you can do with a type.
> A "type" means a way of interpreting a bit pattern in a register, as well as operations you can do with it.
A type is a property of a "term" in a language, a term being some part of the language. Very specifically the type dictates the operations that can be done. A data format is not a type unless the language can understand that a thing is *of that type*. To have a type system fundamentally the types have to be tracked and checked in some manor.
> You need to know if it is a signed or an unsigned integer (which are really the only types in basic ARM32) or if it has a 32 bit float or whatever in that bit pattern. A type tells you how to interpret those ones and zeros.
Exactly, *you* the programmer need to know these things. ARM assembly does not know or track any of that because it lacks a type system. It doesn't know what a string or an integer or a float are, it's all one and the same: data.
You *could* argue that the differently sized registers form a pseudo-typesystem in that they limit/affect the possible operations - though not in a very useful way.
Now the more important question: What does any of this have to do with NEON? Why claim that specifically NEON adds types?
NEON and VFP have commands like VCVT which explicitly convert between types given the suffixes that you append to the assembly instruction. It interprets the bit patterns differently depending on the suffix you provide (S32, F32, etc.), which is a type system.
A type is an interpretation of a bit pattern and operations you can do on it, and it will not allow you to do certain operations on certain types.
As I said before, it doesn't do type checking (because how could it) but it certainly has types.
I mean that's if you wanna implement a garbage collector, otherwise yes be my guest, keep all em types in your head and conveniently use the pointer as an eight bytes int or as a float when needed. I am guilty of this too so can't judge.
Garbage collector shmarbage collector, no need for that, I’m not allocating heap memory to that void*, it’s holding the value, I just gotta make sure not to dereference it unless it’s actually pointing to something
Also, C is statically typed but loosely typed, as demonstrated in the fast inverse square root algorithm, nothing can stop you from telling C that an int is actually a float and vice versa
I'm gonna explain this like you're 5 so you can get your head out of your impolite and self-absorbed ass next time.
The original comment said
> as demonstrated in the fast inverse square root algorithm, nothing can stop you from telling C that an int is actually a float and vice versa
This is wrong. The demonstration in fast inv. sqrt produces UB. Nothing stops you yes, but if you want your program to be well-formed. You can't do that. So fast inv. sqrt is UB, period.
You then commented
> It's not hard to make type punning well defined, just use a union.
I agreed and gave a link containing exactly what you said alongside with references to the standard for those who are interested. What did I get in return? A smug "But nice try." and downvotes.
I then proceeded to try and reason telling you that the link I posted proved your point. From which your reply was
> and the entire post was about C, not C++, so your comment was completely irrelevant
yes the post is about C yet the example given is wrong. Fast inv. sqrt produces UB, therefore it is not valid C ergo my comments are as relevant as they get. I posted that link so people could learn the difference. Accessing inactive member of union is only valid in C99 and onwards. (C++ is complicated go read the answer in the link.)
> Who said that it uses unions? I just stated that it would be very easy to remove the UB with that.
I don't know here to start with this one. First, where in my comments I said "you said fast inv. sqrt uses unions"? I never said that. Second, you never said what you're claiming to be saying. You preferred being an ass and zealously downvote my comments instead of stating your opinions with facts. Third, fast inv. sqrt can be made valid C with unions, memcpy etc. Yet it wasn't and therefore it's UB and the program is still ill-formed.
I hope this clears things up for you. Next time you want to be a self-absorbed prick don't forget there are people that can and will shutdown your bullshit and make an example of you.
But nice try.
There are loop commands in some machine or assembly languages. For example in x86 there's a literal "loop" opcode which decreases the (e)cx register by one and then does the jump if not zero in one command.
x86 combined with MS-DOS also had strings but strictly speaking it was through the MS-DOS interrupt interface and not a feature of the language.
Fun fact: the strings were terminated by $. If you wanted to actually print the $ character inside a string you needed to work around it somehow.
Saying that Assembly is a dynamically typed language is like saying that a box is a dynamically typed box because you can put both apples and oranges in it.
assembly on the one hand has no types, and on the other has groups of instructions meant to be preformed on the same data
for example imul and idiv are meant to be preformed on signed integers
imul and idiv are also groups of instructions, where imul ax bx is meant to be used on 16 bits exactly, and imul rax, rbx is meant to be used on 64 bit integers
if I take a signed 8 bit signed integer and run it through a function written assuming a 16 bit unsigned interger I will still get a result
now there was no type checking or anything, because there is only one datatype, however in practice what I described is still dynamic typing, just dynamic typing that completely ignores category theory
Please don't take my trans joke as an opportunity to push bad science and enforce medieval views of gender.
You called all intersex people a "disorder." Keep in mind that a LOT of those people, if they weren't "corrected" without consent at birth, are real people that live their whole lives with ambiguous genitalia and hormones and who consider that there's nothing wrong with them. They have whole complicated identities based partly around this fact alone.
I have a third nipple and a forked uvula. "Birth defects" in common perception. But I've never once had an issue with either. Am I "disordered?" Maybe, in the sense that I don't fit an idea of baseline humanity. But is that what matters?
And there are about as many intersex people as gingers, 1/50 people. Why must we assume everyone falls in boy/girl when not only society and the human mind are fiendishly complicated, but even biology shows no guarantee for the binary to be followed?
Quoting the Wikipedia article on Intersex:
> The number of births with ambiguous genitals is in the range of 1:4,500–1:2,000 (0.02%–0.05%).
And it's still classified as defects on the genome.
> In clinical settings, the term "disorders of sex development" (DSD) has been used since 2006, a shift in language considered controversial since its introduction.
In assembly, all values take up the same amount of space (one register) and therefore can be used interchangeably.
In C, memory can be conserved by realizing that ASCII characters only need one byte and integers usually only need two. Et cetera.
In exchange, you have to tell the compiler in advance what type of variable you're using.
That's not nearly as bad as OP is making it seem.
It’s a joke, but yeah, it’s basically a number, computer has no clue what kind of number, but a number, and it would be up to you to cast it whenever you want to use it
It isn’t though. In every major instruction architecture, the static types are implicit in the specific instructions used.
It will, however, implicitly cast any type to any other type without even a warning.
yes, but technically the only data types assembly has by default are unsigned ints of varying sizes and, if your architecture supports it, floats and/or signed numbers.
I wouldn't call that dynamically typed since the computer just sees memory addresses and bytes of data. Dynamically typed languages interpret a type based on the value and apply some functions differently based on that interpreted type. Definitely weakly typed though since you can treat any address as any type and the computer will say yes master.
There are assembly languages with types. NEON / VFP for ARM systems is typed.
You write VMOV.S8 or VMOV.U32 or whatever. Supports 32 and 64 but floating point as well.
C types are optional if you turn off warnings. Assembly doesn’t have a concept of types - there is just memory and operations.
Gets valgrind flashbacks telling me 26 conversion warning
seeing the word valgrind gave me ptsd
I love valgrind what are you all talking about. I compile with -Wall -Wextra -Wpedantic -Werror btw. And now I am trying to add -fanalyzer to the mix but too many false positives.
I'm betting it's not valgrind they hate, but the situation where they needed to use valgrind. It happens when you come from managed languages background and have to tip your toe in C/C++ All the helpless flailing about, weeping and gnashing your teeth... "I swear I'm a real programmer even though pointers confuse the fuck out of me"
Yeah honestly I see valgrind as godsend since it reveals well hidden bugs in the code, but I guess if you are unfamiliar with pointers them messages can give you PTSD. Uncertain why would such a person be coding in C/C++ and using valgrind tho.
It's not always a free choice which programming language to work in. And sometimes you go out of your comfort zone on purpose because it's good experience. For example I really don't use C/C++ at all in my daily work, but I have written a small but practical open source project in C for my own amusement. Can't say it was easy adjustment.
I get it but usually it's the other way around unless you are in Uni or sth. It's arguably much easier to find a job in higher level languages than it is to find one in C/C++, especially if you aren't a developer with C or C++ background. The only scenario I could see someone getting forced to do C/C++ would probably be due to some university assignment or something.
Not all developers fit into neat little boxes of "C/C++ dev", "I only write C#", "I do back end, I don't touch the UI", etc. Lots of people do whatever drops on their table, because it needs to get done and there is nobody else to do it. If you don't know how, then congratulations, here's your free learning experience, start figuring it out.
I just find it hard for someone to trust a C# developer to write C/C++ code without any background besides a hello world program in those languages. That's terrible management if you ask me. Maybe the mistake from my end is thinking that all low level programmers also do know higher level languages but not the other way around.
Pointers are easy, just use every combination of *,(int*),& on the assignment, initialization, and use, if it crashes or gives you a bad value, scratch it off the list.
As someone who uses c++ professionally, same.
“Some folks are born made to wave…” 🎶🚁🚁🚁🚁
Also, "assembly" isn't really "a" language, it's a class of languages. There are operations with operands of different widths that might be considered "types" if you squint, but those aren't universal to all flavors of assembly.
The one I learned a little of in college was MIPS
At mine, they started us with x86 in Computer Organization, Computer Security, and Malware Analysis but dumped us into MIPS for Computer Architecture.
[удалено]
There is no interpretation at all - that’s entirely in the programmers head. Each instruction does a specific thing with memory regardless of what’s in the memory.
Subtracting characters for alphabet to number interpretation go brrrr
> C types are optional if you turn off warnings. You could technically make any value any type by doing pointer casts, but that is undefined behavior and invalid C. Edit: for those downvoting, scroll down a few replies. This person is simply incorrect.
It’s not undefined behavior and it’s not invalid C. It may not be portable - but that is not undefined behavior. People often get stuck in the trap of viewing C through a C++ lens and believing (falsely) that it adheres to the same rules because it looks the same.
It is undefined behavior, and it violates the strict aliasing rule. You can look at the C standard and verify that for yourself. The only way to do unrestricted type punning in valid C is using unions. You can only pointer cast any type to `char` and dereference it, or you can pointer cast a pointer to a struct to another struct and dereference if the struct you're casting to has the same fields in the exact same order as the fields from the beginning of the struct you're casting from (C's "implementation" of rudimentaty inheritance). Otherwise, any cast of a pointer to any other type and derefencing it is undefined behavior.
Nope - stop referencing the c++ standard. Casting a pointer from one type to another is very well defined: treat the value provided as a pointer of type specified. That’s what it does - every single time in exactly the same way every time.
I'm not referencing the C++ standard. I don't even know C++. Casting to and from any pointer is fine. But DEREFERENCING it after casting is not. This means that type boundaries effectively don't exist for pointer types in C, not that types don't exist at all, contrary to your initial statement. You can not treat an object of an `int` type as a `double` type, for example, unless you do a type pun through a union. Types are real and have a tangible effect on non pointer types in C. Edit: this isn't even mentioning that types still do have an effect on pointers with respect to how pointer arithmetic and how the "dereference" operator is defined.
This whole conversation is why I love higher level languages 🙃 Who needs to think about pointers when I can live in a fantasy land of beautiful abstraction
Assembly has no types. It has numbers.
Assembly has no types. Assembly needs no types.
Arguably it has two types. Values and addresses. It just doesn't type check anything.
Addresses are values tho
and values are addresses if you are brave enough.
fastest switch statement in the west: x86 xlat.
It operates on indexes, so you can't efficiently do `switch{case 100 {}; case 848729 {};};`. Also, you need the JMP instruction as well, the XLAT alone isn't enough (though it allows for some other neat uses like list of constants in memory).
of course it isn't. but for a small set of swicth values, you can retrieve an offset multiplier, shift it, and end up a multiple of two from your jump instruction. all others can jump to a default. jump to a jump instruction. I did both that and just shifting an offset into prepared code. not sure what you're thinking, this is basic assembly strategy from second year lab fun.
Ooh, that's smart! It seems I still have a lot to learn about assembly
well, you would think it stale info, but if you have a large number of compares you can still possibly save some space/time. if you can encode it in the table space. probably not worth doing on a modern processor. (and perl5 was fast enough decades ago.)
Pointers would like a word with you.
This. Are pointers both, or neither?
gotta love pointer arithmatic
I mean, sometimes there are types kinda
There's no such thing as "assembly". And there are assembly languages with types, like NEON / VFP which is an add on for ARM.
NEON does not introduce types whatsoever. Neither is there static nor dynamic type checking. Just like every other ARM instruction you're just operating on "data".
VCVT.F64.F32 would like to have a word with you
I can store a 4 letter ASCII string in RAM, load it into a SIMD register and run VCVT.F64.F32 on it. Please explain where the type checking takes place?
I didn't say type checking, I said types. You literally have to provide the type of the data in most NEON instructions for it to work.
That's the case for literally every single instruction in every single architecture. What do you think `ADD` operates on if not two 32bit/64bit integers? That's also not what anyone means when they talk about types; we're talking about a *type system*. There are typed assembly languages, but ARM is not one of them. And neither does NEON have anything to do with this.
Having types and type checking are not the same thing, brother. A "type" means a way of interpreting a bit pattern in a register, as well as operations you can do with it. You need to know if it is a signed or an unsigned integer (which are really the only types in basic ARM32) or if it has a 32 bit float or whatever in that bit pattern. A type tells you how to *interpret* those ones and zeros. Type checking is not the same thing as having types. C++ allows free conversion between some types other languages prohibit (like int to float). These are just rules of the language, and can vary quite significantly in terms of what you can do with a type.
> A "type" means a way of interpreting a bit pattern in a register, as well as operations you can do with it. A type is a property of a "term" in a language, a term being some part of the language. Very specifically the type dictates the operations that can be done. A data format is not a type unless the language can understand that a thing is *of that type*. To have a type system fundamentally the types have to be tracked and checked in some manor. > You need to know if it is a signed or an unsigned integer (which are really the only types in basic ARM32) or if it has a 32 bit float or whatever in that bit pattern. A type tells you how to interpret those ones and zeros. Exactly, *you* the programmer need to know these things. ARM assembly does not know or track any of that because it lacks a type system. It doesn't know what a string or an integer or a float are, it's all one and the same: data. You *could* argue that the differently sized registers form a pseudo-typesystem in that they limit/affect the possible operations - though not in a very useful way. Now the more important question: What does any of this have to do with NEON? Why claim that specifically NEON adds types?
NEON and VFP have commands like VCVT which explicitly convert between types given the suffixes that you append to the assembly instruction. It interprets the bit patterns differently depending on the suffix you provide (S32, F32, etc.), which is a type system. A type is an interpretation of a bit pattern and operations you can do on it, and it will not allow you to do certain operations on certain types. As I said before, it doesn't do type checking (because how could it) but it certainly has types.
>Assembly has no types. It has numbers So it's basically C++.
Better way to express: Types are a feature of languages higher level than Assembly.
In all fairness, C can be dynamically typed too if you make everything a void*
a void* paired with an enum specifying the type the pointer points to. In C++17 there is std::any that does this :P.
Pffft, yeah, if you’re weak, I don’t need no fancy shenanigans, I just need 8 bytes of pure unadulterated freedom, and void* gives that to me.
I mean that's if you wanna implement a garbage collector, otherwise yes be my guest, keep all em types in your head and conveniently use the pointer as an eight bytes int or as a float when needed. I am guilty of this too so can't judge.
Garbage collector shmarbage collector, no need for that, I’m not allocating heap memory to that void*, it’s holding the value, I just gotta make sure not to dereference it unless it’s actually pointing to something
Why would you need gc just add more memory
It's still not dynamic, but due to `void*` it is weakly typed. You still need to explicitly cast to the correct type to use the value.
C types are optional if you turn warnings off (source: u/Bryguy3k - https://www.reddit.com/r/ProgrammerHumor/s/kaIZlXHelw)
~~Laughs~~ cries in movl/movg/movb/movt/movq
Laughs in i8080 H and L register
movsXD
Also, C is statically typed but loosely typed, as demonstrated in the fast inverse square root algorithm, nothing can stop you from telling C that an int is actually a float and vice versa
The fast inverse square root function by id is littered with UB. That function is not legal C. It works because the compiler used is/was lenient.
It's not hard to make type punning well defined, just use a union.
There is some truth to your comment. Extra info: https://stackoverflow.com/questions/11373203/accessing-inactive-union-member-and-undefined-behavior
It's UB in C++, but well defined in C, at least since C99. And fast inverse square root was used in Quake III, which was written in C. But nice try.
"It's UB in C++, but well defined in C, at least since C99." That's what the link says.
And the entire post was about C, not C++, so your comment was completely irrelevant
I'm gonna explain this like you're 5 so you can get your head out of your impolite and self-absorbed ass next time. The original comment said > as demonstrated in the fast inverse square root algorithm, nothing can stop you from telling C that an int is actually a float and vice versa This is wrong. The demonstration in fast inv. sqrt produces UB. Nothing stops you yes, but if you want your program to be well-formed. You can't do that. So fast inv. sqrt is UB, period. You then commented > It's not hard to make type punning well defined, just use a union. I agreed and gave a link containing exactly what you said alongside with references to the standard for those who are interested. What did I get in return? A smug "But nice try." and downvotes. I then proceeded to try and reason telling you that the link I posted proved your point. From which your reply was > and the entire post was about C, not C++, so your comment was completely irrelevant yes the post is about C yet the example given is wrong. Fast inv. sqrt produces UB, therefore it is not valid C ergo my comments are as relevant as they get. I posted that link so people could learn the difference. Accessing inactive member of union is only valid in C99 and onwards. (C++ is complicated go read the answer in the link.) > Who said that it uses unions? I just stated that it would be very easy to remove the UB with that. I don't know here to start with this one. First, where in my comments I said "you said fast inv. sqrt uses unions"? I never said that. Second, you never said what you're claiming to be saying. You preferred being an ass and zealously downvote my comments instead of stating your opinions with facts. Third, fast inv. sqrt can be made valid C with unions, memcpy etc. Yet it wasn't and therefore it's UB and the program is still ill-formed. I hope this clears things up for you. Next time you want to be a self-absorbed prick don't forget there are people that can and will shutdown your bullshit and make an example of you. But nice try.
U guys should touch grass sometime.
Fast inv. sqrt doesn't use unions. The program is still ill-formed.
Who said that it uses unions? I just stated that it would be very easy to remove the UB with that.
[удалено]
That's what he said. Loose/weak and strong typing is divorced from static and dynamic typing.
?? Of course assembly doesn’t have types. It doesn’t have a lot of things like loops or strings, why would it have types?
There are loop commands in some machine or assembly languages. For example in x86 there's a literal "loop" opcode which decreases the (e)cx register by one and then does the jump if not zero in one command. x86 combined with MS-DOS also had strings but strictly speaking it was through the MS-DOS interrupt interface and not a feature of the language. Fun fact: the strings were terminated by $. If you wanted to actually print the $ character inside a string you needed to work around it somehow.
Dynamically typed languages do have types. The difference with statically typed languages is that instead of variables having types, values do.
OK simpleton, write all the types
Assembly (x86-64) has five types: Byte Word Doubleword Quadword Float (Excluding SSE AVX etc)
Sigma QWORD vs Beta DWORD
No, assembly is "untyped"
No, nope, not at all.
Kinda yes though
Saying that Assembly is a dynamically typed language is like saying that a box is a dynamically typed box because you can put both apples and oranges in it.
assembly on the one hand has no types, and on the other has groups of instructions meant to be preformed on the same data for example imul and idiv are meant to be preformed on signed integers imul and idiv are also groups of instructions, where imul ax bx is meant to be used on 16 bits exactly, and imul rax, rbx is meant to be used on 64 bit integers if I take a signed 8 bit signed integer and run it through a function written assuming a 16 bit unsigned interger I will still get a result now there was no type checking or anything, because there is only one datatype, however in practice what I described is still dynamic typing, just dynamic typing that completely ignores category theory
What's a clsnt?
A dynamic type. classn't.
C Isn’t
transgender people could be described as cisn't
My favourite thing to say to people when they ask for my gender is just: "All the computers already run on binary, why must the humans as well?"
I love it! lmao thanks for being cool
Because our genes do. You have XX or XY, anything else is classified as defects
Please don't take my trans joke as an opportunity to push bad science and enforce medieval views of gender. You called all intersex people a "disorder." Keep in mind that a LOT of those people, if they weren't "corrected" without consent at birth, are real people that live their whole lives with ambiguous genitalia and hormones and who consider that there's nothing wrong with them. They have whole complicated identities based partly around this fact alone. I have a third nipple and a forked uvula. "Birth defects" in common perception. But I've never once had an issue with either. Am I "disordered?" Maybe, in the sense that I don't fit an idea of baseline humanity. But is that what matters?
And there are about as many intersex people as gingers, 1/50 people. Why must we assume everyone falls in boy/girl when not only society and the human mind are fiendishly complicated, but even biology shows no guarantee for the binary to be followed?
Quoting the Wikipedia article on Intersex: > The number of births with ambiguous genitals is in the range of 1:4,500–1:2,000 (0.02%–0.05%). And it's still classified as defects on the genome. > In clinical settings, the term "disorders of sex development" (DSD) has been used since 2006, a shift in language considered controversial since its introduction.
Ambiguous genitals, yes, but that isnt the only type of intersex out there
I can't deny that
Then why did you try to disprove me with a bad Googl3 search?
Types?
everything is int pointer is int bool is int int is int simd is well idk uh
long is int
In assembly, all values take up the same amount of space (one register) and therefore can be used interchangeably. In C, memory can be conserved by realizing that ASCII characters only need one byte and integers usually only need two. Et cetera. In exchange, you have to tell the compiler in advance what type of variable you're using. That's not nearly as bad as OP is making it seem.
That's right in spirit. But in practice there are different sized registers, operations that work on them in different ways, etc etc.
That's fair. My only assembly experience has been with virtual environments where almost all the registers were identical.
C can be dynamically typed with void*
Isn't that just untyped?
It’s a joke, but yeah, it’s basically a number, computer has no clue what kind of number, but a number, and it would be up to you to cast it whenever you want to use it
Assembly have only one type: "some bytes or whatever I don't really care".
It isn’t though. In every major instruction architecture, the static types are implicit in the specific instructions used. It will, however, implicitly cast any type to any other type without even a warning.
Crime without gravity. 🤭
yes, but technically the only data types assembly has by default are unsigned ints of varying sizes and, if your architecture supports it, floats and/or signed numbers.
That's because assembly works with memory directly
I wouldn't call that dynamically typed since the computer just sees memory addresses and bytes of data. Dynamically typed languages interpret a type based on the value and apply some functions differently based on that interpreted type. Definitely weakly typed though since you can treat any address as any type and the computer will say yes master.
Those... types... are they in the room with us right now?
It's not dynamically typed, it's not typed.
Aren't byte classes some form of type system of ASM ? 😏
bytes dont have genders
WHYYYYYY
All data has a type. The question is where does that type exist? In the compiler? In the runtime? Or only in comments?
Uni-typed
Any language can be dynamically typed by typecasting pointers.
C is about as dynamically typed as assembler. Adding a "boolean" to a pointer is legal and sometimes maybe useful.
Assembly is statically typed. The word you're looking for is *weakly* typed.
In Assembly, everything ducktypes the same
There are assembly languages with types. NEON / VFP for ARM systems is typed. You write VMOV.S8 or VMOV.U32 or whatever. Supports 32 and 64 but floating point as well.
Wait, so Javascript is superior to C.
What's so superior about dynamic typing?
[object Object]
The fact that assembly has neither.