So, C(++) aficionados here.
Look at this code:#include <stdio.h>
int main(void) {
int I = 3;
char C = '3';
if(I==C){
printf("Kek, Works!");
}else{
printf("Type-system surely doesn't completely suck, but why does this compile?");
}
return 0;
}
>> Type-system surely doesn't completely suck, but why does this compile?
Or do the C++ variant where you do std::cout stuff.
Why does this even compile? It is because char is for some (probably ASCII related) reason an integer. And the compiler doesn't check if you really wanted to compare that Char and Int.
Go returns a mismatched error, Rust some trait-related error (because the traits doesn't specify that Chars and Ints should be compared). This is just shit. A good functioning statically typed language should just flip the finger and return errors.
Your language is shit, and you're a complete retard if in 2016 you are still starting a C(++) project that isn't dependent on huge old codebases or small resource hardware.
Your language is a shit
You're way to used to higher level languages, or just retarded
A char is just an 8-bit integer, now fuck off retard.
>>53106448
Kek, Works! for me.
>>53106448
>It is because char is for some (probably ASCII related) reason an integer.
please kill yourself immediately.
>ow duz da cumpooter store fings?
seriously how did you find enough braincells to rub together to post this
absolutely incredible.
>>53106448
A char is just an integer that can only contain numbers between 0 and 255
>>53106448
every type evaluates to a value
"==" compares values
nothing wrong
>>53106448
>if(0b00000011 == 0b00110011)
WHY DOES THIS EVEN WORK LOL LIKE HOW'S THIS VALID MATH XDDDD
>>53106448
>Why does this even compile?
you can literally look this up in wikipedia you dipshit
>>53106900
>implying 3 in the ascii table is equal to 0x03
kek
>>53106850
Stop being a condescending dick.
>>53106906
forgot image fuckm e
>>53106448
>stdio.h
Ehhhhhhhh???
If you write 'C' then youre writing the decimal number 67. Look at this asci table.
test it by doing printf("Muh number: %d",C);
C doesnt care how you write 0s and 1s.
F.e. You can use "void *kek = &C;" (a pointer that points on a not (void) specified value)
then do
printf("Muh number: %c",(char)C);
printf("Muh number: %d",(int)C);
printf("Muh number: %g",(float)C);
>>53106906
>literally
As in 'opposed to practically or figuratively' literally, or is it 'I'm a newfag' literally?
>>53106941
Spic sandnigger detected
>>53106995
ayyyyyyyyyyyyyy hue
>>53106930
op wasn't just ignorant it was abusive
I stand by my response, i believe it is proportionate.
If op had asked instead of trying to ridicule i would have replied differently
>>53106448
i'm sure this has already been said but, chars are actually just integer values that the compiler checks against a character set. you can do arithmetic on them and use them for anything you would otherwise use an int for. I will never == C, but(C -= '0') == Iwoudl return true
#include <stdio.h>
positive_return_value_integer main(void) {
positive_number_integer I = (positive_number_integer) 3;
byte_ascii_character C = (byte_ascii_character) '3';
if(I==(positive_number_integer) C){
print_to_standard_output((byete_ascii_character_string) "Kek, Works!");
}else{
print_to_standard_output((byete_ascii_character_string) "Type-system surely doesn't completely suck, but why does this compile?");
}
return (positive_return_value_integer) 0;
}
explicit enough for you OP?
OP here, I knew I was getting these responses.
>>53106906
>>53106850
You guys are the ones retarded. I explicitly stated why it compiles. It's because a char is considered an integer type.
Which I think is a load of bullshit and even unsafe.
All you guys seem to hammer on "Oh you are not 1337 enough to get C" while completely missing the semantic point I was making. It does compile, and I know why it compiles, I just think a nice statically typed language shouldn't compile and thus Char shouldn't be considered an integer.
For instance:
Go:func main() {
var C rune = '3'
var I int = 3
if C == I {
fmt.Println("A")
} else {
fmt.Println("B")
}
}
//invalid operation: C == I (mismatched types rune and int)
Rust:fn main() {
let i = 3; //int
let c = "3"; //char
if i==c{
println!("A");
}else{
println!("B");
}
}<anon>:6:8: 6:12 error: the trait `core::cmp::PartialEq<&str>` is not implemented for the type `_` [E0277]
<anon>:6 if i==c{
^~~~
>>53107030
You are just fucking retarded. Look at the fucking line after "Why does this even compile?"
>Rhetorical Questions 101
>>53106984
what do you think?
>>53107136
how exactly would you store a char value in binary if not as an integer?
>>53107136
Whoops that was a string, but Char errors fine too:
<anon>:6:11: 6:12 error: mismatched types:
expected `_`,
found `char`
(expected integral variable,
found char) [E0308]
<anon>:6 if i==c{
>>53107136
You WERE abusive, and selectively quoting doesn't change that.
>Your language is shit, and you're a complete retard
You clearly have no interest in learning why this happens.
>>53107136
oh, you're actually just here to shill rust. wish you'd said that at the beginning so i could hide your thread
>>53107136
oh i got it now sorry
i dont know, maybe back when C was getting standardized they thought that since an char is an "implicit" int and you type declared everything you'd know what you were doing. i dont think you're getting any serious answer here anymore, plus your question seems like a thinly veiled "C is shit because of reasons".
char was just the generic type for bytes in C89 and before. Then (u)int8_t was added.
However, making this no longer work would invalidate leagues of legacy code. These types of errors are better saved for being caught by static profiling and style tools than compilers.
But you don't ACTUALLY want to learn why this happens, you're just interested in shitting on the language and berating the users here to reinforce your opinions.
>>53107161
It's not how you store it. It's about what you allow to compile. There are many good reasons why you wouldn't allow the programmer to compare integers and characters without making the type conversion explicit.
>>53107185
That's because I know why it happened, I even wrote that down in the OP, and thus shouldn't have to learn it.
And yes, you're a complete retard if you still use these languages for new projects outside the two use cases I stated in the OP.
Outside those use cases, and graphics stuff, there is no reason to pick C or C++ above any other system language, besides that "it is easy because I already know it, so lets use pointer arithmetic everywhere" or showing off your /g/-Street-Cred.
>>53107228
I've actually never made something in Rust, I was just comparing it to modern statically typed languages. Rust and Go are static and typed.
>>53107136
>Which I think is a load of bullshit and even unsafe.
well don't use C then. pretty simple.
>Oh you are not 1337 enough to get C
if you need your hand held then don't use C. comparing different types is incredibly convenient and efficient.
please don't look at ASM unless you want to give yourself a heart attack.
>>53107136
>Look at the fucking line after
>this is what other languages do
C is not go or rust
if you need a compiler to tell you what you wrote then i feel sorry for you.
you should know what you wrote and not have to rely on others to pick up your mistakes.
do you drive around in a car with your eyes closed because they have air bags?
do you actively seek out gay men who are HIV positive because you are going to wear a condom?
>>53107136
The standard defines a "char" as an 8-bit value.
The "char" is comparable to an integer because a char is an unfortunately-named integer value. You can think of it as a "byte" type.
This feature does more good than harm.
>>53107313
>That's because I know why it happened
No you don't.
>It is because char is for some (probably ASCII related) reason an integer.
This is wrong.
It's merely a generic byte type. Nothing to do with ASCII or integers. Please see here for why it still happens.
>>53107296
>>53107136
>Which I think is a load of bullshit and even unsafe.
The C programming language views the programmer as a sane and responsible person that knows what hes doing.
The other programming languages think the programmer will shit all over the keyboard anyway so its better avoid the worst by not allowing it in the first place.
>>53107328
>if you need a compiler to tell you what you wrote then i feel sorry for you.
>you should know what you wrote and not have to rely on others to pick up your mistakes.
This is what compilers do, they return errors based around the errors you made.
Or would you like a world where every compiler just returned "ERROR! GO FUCK YOURSELF" when you made a mistake?
This clearly shows you never made anything besides FizzBuzz.
>>53107136
>Which I think is a load of bullshit and even unsafe.
>I just think a nice statically typed language shouldn't compile and thus Char shouldn't be considered an integer.
Just stay in your shitty managed language
>>53107176
I understand what you're saying but I think that you are misinterpreting what chars actually are in C.
Chars are just small integers, therefore you can also use them to store small numbers.
Also because of the way ASCII works you can also do arithmetic operations on them, which is actually useful, for example for making uppercase letters.
In Go and other languages characters are probably stored in an encoding that wouldn't make any sense if interpreted as a number, that's why the errors.
>>53107340
>standard defines a "char" as an 8-bit value
false
>>53107400
>The C programming language views the programmer as a sane and responsible person that knows what hes doing.
It doesn't, the compiler does a lot of handholding work.
Also, C++ Programmers aren't sane or responsible.
>>53107410
No, that is not at all what compilers do. You're thinking of profiling tools.
A compiler is a translator. Its only job is to tell you when what you wrote is syntactically incorrect or ambiguous to a certain degree.
There is nothing ambiguous about comparing a generic byte type to an integer type. That's clearly a valid comparison, since the generic byte type could be treated as a number.
The only time this could be a mistake is if the writer wrote the wrong variable name, in which case it's the programmer's job to catch the mistake in profiling tools or debuggers. This is the same for every other time the programmer writes the wrong variable. Anything else is misplaced guessing in a compiler.
>>53107467
>what is undefined behavior
>>53107462
You're right. Technically, a char should be as long as the "basic execution character set", which is generally always plain ASCII, even in overseas computer systems.
My point still stands, though, because the standard ALWAYS refers to char as in integral type. OP seems to assume that a C char is not really an integer, when that's exactly what it is.
>>53106448
ISO/IEC 9899:1999 specification, TC3
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
>>53107438
Thanks for reading!
See you tomorrow when I talk about "C being weak: pointers" where you will see all kinds of nice runtime errors, that are completely unmanageable in big projects.
>>53107602
If you can't do it right, then you should stay in whatever shit language you're using.
test
>>53107410
>This is what compilers do, they return errors based around the errors you made.
>i don't really understand what you are trying to do
is very different from
>i know what you think you want to do but i want you to be absolutely clear about it because i don't trust you.
>>53107410
>never made anything besides FizzBuzz.
no need to get personal kid.
I've never written fizzbuzz, back when i had 'practical' interviews the questions were actually interesting.
>>53107602
Oh please, enlighten us on your ignorance concerning pointer operators, failure to learn profiling tools, and inability to encapsulate behaviour inside structures and functions.
>>53107558
>My point still stands, though, because the standard ALWAYS refers to char as in integral type. OP seems to assume that a C char is not really an integer, when that's exactly what it is.
Every sane person would firstly, without knowing anything about C or programming, assume that a character isn't an integral type.
Naturally comparing the Letter A to Number 3 doesn't make sense.
Of course, if you look at the standard and know that A gets stored as a number it is understandable. But I just think it is semantically wrong, and I don't really like it.
>>53107700
Do you make a thread about every stupid opinion based on ignorance you have that no one cares about?
>>53107700
Well, yes, first assumptions don't necessarily reflect reality accurately.
I agree, if someone knows nothing about programming, then comparing 'A' to 3 makes zero sense, but the C programming language isn't targeted at those users.
Basic knowledge of information encoding and storage is vital to learning and using C. If a beginner learns about how ASCII and UTF-8 work and how strings are actually stored under the hood, comparing 'A' to 3 will make perfect sense.
I agree that it looks semantically wrong at first glance, but I also don't think it's right for complete beginners to program with C.
>>53107700
>I just think it is semantically wrong, and I don't really like it.
Im pretty good at C and all I thought at the beginning of learning C was that the dude who wrote it was insane. But when you understand C better youre able to do thing you wasnt able to do in any other programming language. You also can troll people on the internet when you know about undefined behaviour.
>>53107136
>rune
>>53107787
>but I also don't think it's right for complete beginners to program with C
why not? these concepts aren't complicated. i think people give "beginners" too little credit -- or maybe too much. at a certain point you need to stop pandering to the lowest common denominator, or we'll keep churning out generation after generation of future /g/ posters who get CS degrees, work at mcdonalds, and spend their free time refining and arguing about their fizzbuzz algorithm on 4chan. if someone is going to succeed at programming, they are the kind of person who would find it fucking cool that chars are actually integers. i think fostering that kind of minor epiphany is more important than shuttling another busload of future webdevs onto the python train.
>>53107862
Rob Pike is actually a big fan of le trashman.
>>53107872
That's right, but on the other hand, if newbies feel rushed to start out with C too quickly, they will quickly encounter things like in the OP and get confused fast.
At my university, the freshman CS students start out with the usual python and java. After that, there is a mandatory "intro to system architecture" course, in which they first learn about logic gates and memory, and program a basic 16-bit CPU with assembly. Then they are introduced to C in the later part of the semester, and by that point, all the small "discrepancies", such as a char actually being an integer, are already clarified after doing a lot of assembly programming, and they don't have these types of questions while learning and using C.
I feel that some sort of system architecture background is very important before someone pursues C.
>>53107787
>Basic knowledge of information encoding and storage is vital to learning and using C. If a beginner learns about how ASCII and UTF-8 work and how strings are actually stored under the hood, comparing 'A' to 3 will make perfect sense.
>I agree that it looks semantically wrong at first glance, but I also don't think it's right for complete beginners to program with C.
OP here, I actually think it is an OK beginner language, when you add a good book or some lectures. Especially for the reasons you stated, you'll only can completely `get` programming if you're familiar with the low-level data-structures and types. Almost every language learning after C will be a breeze, simply because often it is based on the things C did great and improved with features that make programming a little nicer.
I just think you shouldn't really touch it afterwards besides the two use-cases I described in the OP + Graphics.
>>53107964
I just read Code by Petzold and K&R
>>53107999
You forgot low level I/O and manual memory management.
>>53108072
You are right on the low level I/O
>manual memory management
If on low-resource hardware, which I described in the OP.
Or something that needs to be extremely optimized for some reason, yeah ok, but most of the time non-manual memory management is better.
>>53106921
I is the int numbskull.
>>53107700
>without knowing anything about C or programming, assume that a character isn't an integral type
in other words
>i want to magically understand things without having to learn
back to memejs, pajeet!
>>53108699
It's semantically illogical, I can see the reason why C implemented it. That C++, being more high-level, just copied it is retarded.
There is a reason other languages don't do this.
>>53108750
C++ is compatible with all C code, it was one of the things intentionally done when the language was designed
>>53109085
All c code? Nope.#include <stdio.h>
int main() {
int class = 5;
printf("%d\n", class);
return 0;
}
Valid in C but not C++ because class is a keyword.
There's a whole bunch of other stuff that doesn't work as well.
>>53106448
Historically char is used as a synonym for "byte".
>>53109320
That's great, when you are currently interested in writing historically accurate code.
>>53106448
Two things could have happened here
1.) You genuinely believe what you posted, in which case.
>You're retarded
2.) You put a lot of effort into blatant bait.
>You're still retarded
Stop using high level languages with the mindset that it's genuine programming.
A char is an 8-bit integer.
int I = 3; // 00000011 (3 = binary 3)
char C = '3'; // 00110011 (51 = ASCII '3')
The character 3 is not synonymous with binary/mathematical 3.
>>53110189
Thanks for explaining something I already understand.
From now on I will code all my applications in bare metal C, because else it isn't 'genuine' programming.
Because all these high-level structures that obfuscate my chars.
See a new language where I can't implicitly compare the letter A and number 0?
>into the trash it goes
See a new language where I can't just do this:double *d = &a;
int *b = (int*)d;
>into the trash it goes
>>53106448
char is a byte
int is a dword
>>53107136
c is not a safe language anon
