Have any of you run into this before?

Windows's Command Prompt apparently can't handle 8 bit integer limiting, signed or unsigned

Use Windows PowerSnail instett.

PowerShell?

thats the point, faggot.
if you dont like it, dont use it.
or is that something your autistic mind cant comprehend because your mommy and daddy babied you until you were in your 30s?

Don't need to sperg out just because I made an observation

so pointing out common knowledge needs attention?

so sperging out over inconsequential bullshit necessary?

Are you using Visual Studio to compile the C code?

powershell is cmdline 2.0 for windows.
microshit didnt want to change their original commandline but knew it was obsolete... so they did the only reasonable thing... create a new commandline and name it powershell.

No, CodeBlocks, I had VS 2015 for a bit, but it was way too bloated for my purposes when I just needed C++ anyway

It's due to the way stdint.h works. int8_t casts to char. If you want accurate output of 8-bit ints, learn to use printf and inttypes.h

>can't handle 8 bit integer limiting, signed or unsigned

WTF are you trying to say?

Or maybe, WTF do you *think* you're trying to say?

I don't think you have any idea what you're showing in that screenshot.

Windows can't output 8-bit ints correctly because it's a shit OS

Literally no different than a Linux snob.

You don't understand streams. And tell me exactly how the OS comes into play here.

>cmd can pipe things
>shift+f7 displays history

Holy shit you are stupid.

shift+f7 doesn't work like that though, only for user entered commands

How much is nutella paying you to shill here?

>fell for the namespace meme

>apparently can't handle 8 bit integer limiting, signed or unsigned

I still want to know how you arrived at that wording.

Like, what do you think "integer limiting" is? And how is it relevant to the OS? And how is it that you think your screenshot indicates this?

better than typing std:: every time you need an iostream function

>windows

Not really, no.

Sorry, what are you trying to say? Use your words, Bobby.

Speaking of Visual Studio, do you see that it's compiling telemetry code into everything built with it.

Congrats user. Most people aren't brave enough to showcase their ignorance in such a puboic forum.

No.
PowerShell is VBScript replacement.
You use it to run script.
Nobody use PowerShell interactively like cmd thanks to verylongfunctionnamebutithinkpeoplewillunderstandwhenreadingmyscript.

strange though, I'd think the shell would interpret them as separate bytes, so a 2-byte value would be printed as 2 single byte ones so for example, 0x4141 would print AA. But it instead prints the values as integers... Doesn't make sense

...

Shell has literally nothing to do with this, dumbass. Neither does virtual terminal. It's your program that outputs single characters in first case, and series of numbers in second case. The same binary will work the game way on linux too, with linux shell and linux virtual terminal.

Ffs, can we give OP a break.

So then why does it enter an infinite loop if I use char instead of uint8_t?

Because char can never be greater than 254

...

> I'd think the shell would interpret them as separate bytes, so a 2-byte value would be printed as 2 single byte ones so for example, 0x4141 would print AA

cout > 8) & 0xFF)

OP, please post Java code for better bait.
Sup Forums will sure blame Java for that.
Next, some user will claim C# won't have such problem.
After that, another user will agree on C# user with unrelated positive remarks.

Sup Forums in a nutshell.

>things that literally did not happen
>Sup Forums in a nutshell

Ironically, it happen

Constructive discussion with only few comments not on topic. I wonder if you have some filter that hides everything but shiposts?

C++'s

>how cmd renders unicode (if possible).

It doesn't. You can copy and paste Unicode, but CMD itself can't output Unicode.

In my opinion, the actual rendering of the buffer is MBCS, not UCS-2 or Unicode. People have argued with me about this, but in my opinion the behavior is consistent with MBCS output. It's only the copy functionality that copies Unicode, and that has nothing to do with what's rendered on-screen aside from getting buffer coordinates.

Here's some example code I have sitting in one of my folders:

// WriteUTF8.cpp : Defines the entry point for the console application.
//

#include

#include
#include

#include "stdafx.h"

#pragma execution_character_set( "utf-8" )

int wmain(int argc, wchar_t argv[])
{
// All translations courtesy of Google, no accuracy implied.
const wchar_t *Russia = L"Poccия";
const wchar_t *Japan = L"日本国";
const wchar_t *Vietnam = L"Việt Nam";

int oldMode = _setmode(_fileno(stdout), /*_O_U8TEXT*/_O_WTEXT);

std::wcout

Try chcp 65001

Yeah, play around with that. You'll find that it doesn't actually do anything.

Then again, neither does _setmode...

...

someone double check this

I think this guy is right

You're an idiot.
uint8_t is typedef'd to char, and std::cout using namespace std;
Kill yourself.

Yeah, the middle one didn't print correctly. Why? Because it's not really UTF-8.

It's not printed correct because of font issues - not because of unicode support issues.
I can copy it:
const wchar_t *Russia = L"Poccия";
const wchar_t *Japan = L"日本国";
const wchar_t *Vietnam = L"Việt Nam";
This was copied from console. Which means console outputted characters correctly and only used wrong font.

cast to a bigger int

Because you're an idiot that doesn't know how programs print things.

you mean 127
Char is signed.

I mean 254.

>It's not printed correct because of font issues - not because of unicode support issues.

Nooooooooooooope. Or to put it another way: WHY do you think there's a font issue? Why is it that you can't select a font with full Unicode support? Here's why: because CMD's display window isn't Unicode.

>This was copied from console. Which means console outputted characters correctly and only used wrong font.

No. People commonly claim this, but the ability to copy means jack shit. There's no magical connection between what's on the screen and the copy buffer. CMD can literally put anything it wants into the buffer. So, what's it do? It looks at the coordinates of what you selected, cross-references that to its internal buffer, and copies that.

The CMD window itself is MBCS.

What encoding is it? It outputs Russian as well Vietnamese letters. There is no encoding save for variations of unicode that have both these characters in them.

>its internal buffer
Its internal buffer is exactly contents of the virtual terminal. Thing you see on screen is only a visual representation of this buffer.

>as well Vietnamese letters

Look into what Vietnamese characters are.

>There is no encoding save for variations of unicode that have both these characters in them.

Sorry, what?

1) "Variations of Unicode"? Unicode is Unicode. Are you trying to talk about code pages?

2) How is that relevant, since as I said, it's MBCS output, not Unicode?

>Thing you see on screen is only a visual representation of this buffer.

...Uh, yeah? That's my point? It's got Unicode (well, probably UCS-2) internally, and displays MBCS.

>Sorry, what?
>1) "Variations of Unicode"? Unicode is Unicode. Are you trying to talk about code pages?

lol
Unicode is the standard.
There are various sets of character encodings that represent texts made out of characters defined by unicode standard as series of octets. Among them are utf8, ucs2le, ucs2be, ucs4.
You don't even know basics, user.

>2) How is that relevant, since as I said, it's MBCS output, not Unicode?
It is relevant, because since it uses MBCS, it has to work with one particular character encoding. Since you're claiming it's not one of unicode encodings, I'm asking you which one it is - which encoding has both я and ệ in them.

>Look into what Vietnamese characters are.
Done! Very educational. My point still stands.

Dunno what you're lol'ing about, your sentence made zero sense.

>There are various sets of character encodings that represent texts made out of characters defined by unicode standard as series of octets. Among them are utf8, ucs2le, ucs2be, ucs4.
You don't even know basics, user.

I don't know the basics despite already mentioning UCS-2. Okay.

So, to answer your (poorly worded) question: yet again, it's not fucking Unicoce. It's MBCS. I honestly don't know why you keep asking about Unicode.

>It is relevant, because since it uses MBCS, it has to work with one particular character encoding.

You don't appear to know what MBCS is on Windows. Go read up on it.

>Since you're claiming it's not one of unicode encodings, I'm asking you which one it is

It's MBCS.

I think you're confusing "multi-byte character sets" with MBCS. MBCS on Windows isn't Unicode.

Yes, in general terms Unicode encodings are multi-byte character sets, but Windows MBCS isn't Unicode.

No, you mean 127.

>No, you mean 127.

Retard, the original statement is still true:

>Because char can never be greater than 254

OP's code tested against 254, hence the explanations.

Jesus, if you can't understand the thread well enough to follow this, then you don't belong on Sup Forums.

Here's a tip: next time your nerdy sense tingles and you feel the urge to point out something obvious, stop and ask yourself if you're missing something.

>It's MBCS.
MBCS is not a charater encoding.
When something uses MBCS, it means it uses one of character encodings supported by windows, and they are usually referred to by their code page number.
MBCS implies that one particular character encoding is used. I asked which character encoding it is twice, and you still can't answer.

>I don't know the basics despite already mentioning UCS-2. Okay.
You don't know basics because you got confused by unicode encodings.
Your "Sorry, what?" means that you are clueless.
You still failing to answer my simple question means that you are clueless.

>>Because char can never be greater than 254
Implies that it can be equal to 254, which is just plain untrue.
Also, no, unsigned char CAN be greater than 254, you stupid fucking retard, do you know how numbers work?
The maximum value an unsigned char is 255, and the maximum value of a signed char is 127.

Holy shit, kill yourself you fucking retard.

>Implies that it can be equal to 254
It does not imply that. That's your interpretation of it and you're pretty stupid if you interpret it this way.

Yes, it's a VB replacement, but it's also a shell replacement. Not everything it runs is a script.

No, YOU are fucking stupid for not interpreting it my way. My way is the correct way.
When someone says that x can't be greater than y, then that usually means that x can be smaller or equal to y.
Kill yourself.

I'm sorry for causing you this amount of grief.
It's fine.
I'm sure you can still have a normal life even if you interpret greater sign like this.

> != >=

What's the problem with namespace STD again? It seems like a lot of arrogance communing of thinking you're doing any better by doing a little extra work

Fucking autocorrection

>a shell replacement
Such as ?

Here in cmd
dir /s /b


Here in PowerShell
Get-ChildItem -Recurse | Select-Object -ExpandProperty FullName
gci -r | select -exp FullName

Tell me how many of you gonna type the whole shit just to view current directory under certain sorted format.