Comparing chars in C

I try to figure this stuff out for myself, but I've been spending the last 3 fucking hours on this. According to stack overflow my shit is correct, so hopefully ya'll can shed some light.

I'm trying to compare a single value in a string to a char. I'm doing this like
if (instr[i]== "b")
However, it keeps passing everything no matter what. I've tried everything at this point, even moving it into a string and comparing those, but that just causes it to fail everytime.

Can anyone shed some light on this bullshit?

Attached: shampoo commercial.gif (384x288, 1.86M)

Other urls found in this thread:

en.cppreference.com/w/c/language/operator_comparison
twitter.com/SFWRedditVideos

Seriously, is there anything I'm missing here? Am I just being retarded?

Tried &instr[i] and *instr[i] to see if it was a pointer issue, nothing works

Why is char character in double quotes? That makes it a C string and C will convert that to a pointer address during the comparison, i think. You need single quotes around the b instead of double.

This. There's a hidden null terminator that's included.

You've got to be kidding me! Can't believe I missed that, I just use double quotes out of habit. Fml

Thank you all for the help

Replace
"b"
with
code]'b'
That might work. Single quotes tell C you're specifying a char.

>There's a hidden null terminator that's included.
ehhhhh

I don't think this is what is happening. I think the value of a character in a string is being compared to the address of literal "b". Can we see the full function, OP?

It actually was just that, a stupid null terminator. Originally I thought I had screwed up the for loop somehow, but it was just a char classified as a string the whole time.

When you compare it to a char you need to use single quotes, as user said. Chars always use single quotes.

if (instr[5] == 'c')

You shouldn't believe everything you hear. The cause of this is double quotes, but it's not because of null terminator, but because you are comparing a char (on the left) to an address in memory (4 or 8 bytes depending on arch) where the string "b" is regardless of whether it has null terminator or not.

Double quotes mean string literals aka pointer to preallocated array somewhere aka 0x02F29ABE
Single quotes mean character literals aka temporary 1-byte variables interpreted as ASCII symbols.

I just checked.

en.cppreference.com/w/c/language/operator_comparison

> expressions that

> both have any arithmetic types (including complex and imaginary)
> both are pointers to objects or functions of compatible types, ignoring qualifiers of the pointed-to types

The problem is a char to char comparison is of the first kind where both are arithemetic types. But once you have a char and a char pointer comparison, C will treat that comparison as if you were comparing both the addresses, which is the second kind mentioned.

The compiler literally emits a warning that it's a comparison between pointer and integer.

Attached: firefox_2018-11-06_09-45-59.png (1537x579, 58K)

Double quotes is syntax for a string. When you compare that, you are comparing the value of the char to the pointer of the string (and the string itself is two chars, BTW, because of the null terminator).
Yes it is.
Also this. Don't you read your warnings?
Keep learning OP.

OP back, I did read the warning, but that is absurdly vague. I thought it was originally an issue of handling the string incorrectly, not putting the wrong quotes on a char.

>strange love
classic

a good habit is too always use single quotes for chars and double for strings even if the language supports vice-versa

What, even in languages where distinction between single and double quotes is completely different? Don't think so, user.

Hey OP enable -Wall, use valgrind and learn to use gdb!

Or use an interactive debugger and you don't have to learn. Hm......

Does gdb work on Windows? I've been using Visual Studio but after all this nonsense I want something new. My next laptop is going to be Linux anyway.
Lol glad you like it my dude
Yeah I know, I've definitely got to build better habits. Will save a ton of time in the long run, as its always those little things that get you

You're not getting a better debugger than the one shipped with Visual Studio. What nonsense are yo even talking about?

I mean it does, but getting it set up is a pain in the fucking ass. Do yourself a favour and install Ubuntu (The installer is super user friendly) and figure that out. C feels better on a proper system anyway!

If you have hardware issues and a decent box, just spin up a VM and install it in VirtualBox or something. Alternatively if you don't mind the command line, you could spin up a instance on GCE for free (they give you a 300$ sign up credit)

>feels
It must be so sad for FOSS when the best argument they can come up with is feels...

Aight, well if you wan't the best goddamn feel you write C and Go for Plan 9 and set up a bunch of shared resources.

C was built with a Unix env in mind, best to run it on something that it at least POSIX compliant. Hell, a defunct version of Solaris would be a better platform.

>inb4 WSL

You could argue that Linux has better mechanisms for async sockets, and I would probably agree, but OP is nowhere near this level.

OP struggles to compare two characters. Switching OS at this point is completely unnecessary and counter-productive.

I'm not saying switch OS's because of C, what I'm saying is get used to alternative systems that will make your life easier. A great example is trying to do any microcontroller work on Windows, shit's all over the place and outdate/incompatible. avr-gcc and required/dependancies are all in the repos to save you some massive headaches.

It's more of a get on that when you can kind of thing.

You can do that any time you like. If he's motivated to study C, he should be studying C, not exploring operating systems.

I'd make an argument for gradual and interconnected learning but I'm way too fucking high right now.

>You could argue that Linux has better mechanisms for async sockets
It doesn't. I/O completion ports on Windows completely trounce epoll (and by extension everything else) on Linux.

Any documented comparisons?

Don't have one to hand, but readiness-based synchronous I/O (threaded or forked) fundamentally can't outperform asynchronous I/O with completion events. One tells you you can do something you expressed the intent of doing, the other states your request is already done (or failed). When epoll gives you a socket to read from all you know is there is data to read - maybe; you don't know how much or even what the socket's state is. With IOCPs you get notified when data is already in your buffer ready for use or something happened with the socket, and you only had to prepare for it once.

epoll can get close to IOCPs only if used properly (and really close with specific network hardware), requiring EPOLLET which can be really difficult to pull off. It's too easy to end up with an implementation that barely outperforms select/poll, ends up starving workers, or worse, missing events some of the time but not always. The whole thing just feels incomplete.

That's not to say IOCPs have a great API either, definitely a learning curve there too, but at least it scales really well.

ishygddt

OP back, I've actually handled async sockets before, just in Java. I'm not a complete novice in general, just to C, because it handles strings shittier than any other language I've used. Hell, isn't one of the big improvements in C++ better string support? Even the devs saw confusion could arise.

It was a stupid mistake, but it wouldn't cause an segmentation error in the other languages I've worked with, or a lot of the time any error whatsoever.
I should've clarified, I wasn't just talking about a debugger, but a better IDE in general. Most people I know who code C don't do it on Visual Studio