Pár otázok na C++

[Wrána diskuze]

nóó ale stejně je takový zajímavý žeto c++kový '\n' je schodný zrovinka se zakončením řádku v linuxu. bych se taky jako mohla zeptat proč jinde potřebujou mit něco extra a jestli to jako dneska ještě vůůůbec dává nějakej smysl

Jestli dneska ještě něco vůbec dává smysl je vedlejší, protože zpětná kompatibilita, žeáno. Wokna mají CRLF protože to tak měl DOS a ten, protože to tak mělo CP/M a ten, protože to tak chtěly staré teletextové mašiny. Jabčáci měli původně CR, ale ti se nekompatibilních změn evidentně nebojí, tak přešli na Unixové LF. U Microsoftu změna nehrozí, tam občas neopravují ani bugy ale přidávají nová rozhraní, protože by opravou rozbili háky, co ty bugy obcházejí.

tak u woknářů je ještě možný že to je určitej záměr podkopávat zájemnou kompatibilitu nezi win-jinej systém nebylo by to nic překvapivýho si myslim nóó třeba se pletu ale celkem mi to k nim štimuje
notepad nebo něco takovýho prej texťák s jiným koncem řádků než windowsovým při otevírání rovnou konvertuje a na nic se uživatele neptá ani
nadruhou stranu je asi jako fakt pravda že poměr mezi zanedbatelnejma výhodama získanejch vyměněním toho ukončovadla řádku a novejch problémů který to vyvolá asi jako nebude zrovinka moc výhodnej

[Reklama]

[Tomas-T]

Zrovna Windows a Microsoft bych z téhle nekompatibility neobviňoval.
CR+LF používal už systém CP/M od Digitalu.
Od něj to zdědily DOSy (PC DOS, MS DOS) s ním následně Windows 3.x a Widnows 95/98 (=nadstavby DOSu) a další verze už neměly důvod na tom něco měnit.

[neregistrovany]

Zrovna Windows a Microsoft bych z téhle nekompatibility neobviňoval.

Jsou lidi kteri si do MS kopnou kdykoliv, jen ze vzteku ze linux ma desktopu furt jen to procento

[BoneFlute]

Zrovna Windows a Microsoft bych z téhle nekompatibility neobviňoval.

Ten problém přeci není v nekompatibilitě. Problém je v té knihovně, že se chová zmateně.

[Jiří Havel]

Zrovna Windows a Microsoft bych z téhle nekompatibility neobviňoval.

Ten problém přeci není v nekompatibilitě. Problém je v té knihovně, že se chová zmateně.

Ale ona se nechová zas tak zmateně. fwrite v C prostě u souborů otevřených v textovém režimu převádí '\n' na platformně závislé konce řádků a fread zase zpět. Pokud ten převod nechci, tak otevřu ten soubor jako binární. No a iostreamy v C++ se chovají stejně, aby v tom nebyl zmatek.

[Reklama]

[BoneFlute]

Zrovna Windows a Microsoft bych z téhle nekompatibility neobviňoval.

Ten problém přeci není v nekompatibilitě. Problém je v té knihovně, že se chová zmateně.

Ale ona se nechová zas tak zmateně. fwrite v C prostě u souborů otevřených v textovém režimu převádí '\n' na platformně závislé konce řádků a fread zase zpět. Pokud ten převod nechci, tak otevřu ten soubor jako binární. No a iostreamy v C++ se chovají stejně, aby v tom nebyl zmatek.

Tomu já rozumím. Ale přeci jen, čistě pocitově, když zadám \n, že to bude převádět - ok. Když zadám \x0A, že to bude převádět, to už je takové...

Ale chápu. Prostě to \n se převede na byte, a pak se teprve to číslo (podle módu) překládá. Zmatený to není, uznávám.

[Jiří Havel]

Zrovna Windows a Microsoft bych z téhle nekompatibility neobviňoval.

Ten problém přeci není v nekompatibilitě. Problém je v té knihovně, že se chová zmateně.

Ale ona se nechová zas tak zmateně. fwrite v C prostě u souborů otevřených v textovém režimu převádí '\n' na platformně závislé konce řádků a fread zase zpět. Pokud ten převod nechci, tak otevřu ten soubor jako binární. No a iostreamy v C++ se chovají stejně, aby v tom nebyl zmatek.

Tomu já rozumím. Ale přeci jen, čistě pocitově, když zadám \n, že to bude převádět - ok. Když zadám \x0A, že to bude převádět, to už je takové...

Ale chápu. Prostě to \n se převede na byte, a pak se teprve to číslo (podle módu) překládá. Zmatený to není, uznávám.

A jaké jsou pocity z toho, že \x41 znamená v ascii stringu to samé co A? Taky je to divný pocit, nebo to dělají jen speciální znaky?

[BoneFlute]

Zrovna Windows a Microsoft bych z téhle nekompatibility neobviňoval.

Ten problém přeci není v nekompatibilitě. Problém je v té knihovně, že se chová zmateně.

Ale ona se nechová zas tak zmateně. fwrite v C prostě u souborů otevřených v textovém režimu převádí '\n' na platformně závislé konce řádků a fread zase zpět. Pokud ten převod nechci, tak otevřu ten soubor jako binární. No a iostreamy v C++ se chovají stejně, aby v tom nebyl zmatek.

Tomu já rozumím. Ale přeci jen, čistě pocitově, když zadám \n, že to bude převádět - ok. Když zadám \x0A, že to bude převádět, to už je takové...

Ale chápu. Prostě to \n se převede na byte, a pak se teprve to číslo (podle módu) překládá. Zmatený to není, uznávám.

A jaké jsou pocity z toho, že \x41 znamená v ascii stringu to samé co A? Taky je to divný pocit, nebo to dělají jen speciální znaky?

Počkej počkej, to je naopak. \x41 je to samé jako A. Ale třeba \s není " ", že jo. Že by má deformace z reqexpr?

[Wrána diskuze]

Zrovna Windows a Microsoft bych z téhle nekompatibility neobviňoval.

Jsou lidi kteri si do MS kopnou kdykoliv, jen ze vzteku ze linux ma desktopu furt jen to procento

dokavaď nebude mit linux na desktopu aspoň 10000000000000% tak nebudu mit klidný spaní!!!!!!!!!!!!!!!!

........ne fakt je mi to upřímě u tatrče jak si to jako windowsáci řešej když se jim to takle líbí a sou nato zvyknutý sem ráda že používám system kterej podobný divný votázky nevyvolává 

..............................
..............
A jaké jsou pocity z toho, že \x41 znamená v ascii stringu to samé co A? ...........

lepší rozhodně

[Kit]

CRLF má svůj původ u dálnopisů, kde měl svůj význam. Jehličkové tiskárny dodnes vyžadují oba znaky, jinak tisknou blbě. Je fajn, že C umí pracovat se všemi variantami a je fajn, že se to dá vypnout.

[Tomas-T]

........ne fakt je mi to upřímě u tatrče jak si to jako windowsáci řešej když se jim to takle líbí a sou nato zvyknutý sem ráda že používám system kterej podobný divný votázky nevyvolává 

Stačí si do Windows jako hlavní textový editor dát Notepad++ a vybrat si v konfiguraci default zakončení řádku dle vlastního uvážení (Win/Linux/Mac).
Jen si nejsem jistý, zda to třeba po editaci hosts pochopí systém (třeba ano). 

[Jiří Havel]

Zrovna Windows a Microsoft bych z téhle nekompatibility neobviňoval.

Ten problém přeci není v nekompatibilitě. Problém je v té knihovně, že se chová zmateně.

Ale ona se nechová zas tak zmateně. fwrite v C prostě u souborů otevřených v textovém režimu převádí '\n' na platformně závislé konce řádků a fread zase zpět. Pokud ten převod nechci, tak otevřu ten soubor jako binární. No a iostreamy v C++ se chovají stejně, aby v tom nebyl zmatek.

Tomu já rozumím. Ale přeci jen, čistě pocitově, když zadám \n, že to bude převádět - ok. Když zadám \x0A, že to bude převádět, to už je takové...

Ale chápu. Prostě to \n se převede na byte, a pak se teprve to číslo (podle módu) překládá. Zmatený to není, uznávám.

A jaké jsou pocity z toho, že \x41 znamená v ascii stringu to samé co A? Taky je to divný pocit, nebo to dělají jen speciální znaky?

Počkej počkej, to je naopak. \x41 je to samé jako A. Ale třeba \s není " ", že jo. Že by má deformace z reqexpr?

Aha, tak takováhle deformace. Tohle jsou escape znaky, které s regexem nemají společného vlastně nic. Ve výsledném stringu žádné lomítko nebude. Je to prostě jenom způsob, jak zapsat do stringu i kontrolní znaky. C žádné \s ani nezná.

Ale osobně se tomuhle zmatení docela divím. Všechny programovací jazyky, co znám mají escape znaky stejné nebo hodně podobné Cčku. Java, Python, nebo třeba i Haskell. Při každém použití regexu z kódu jsem musel ty regexová lomítka psát právě přes escape sekvence nebo přes raw stringy.

V jakém jazyce to programujete, že vás první pokus o použití regexu nemilosrdně nevyškolil právě v použití těch escape znaků?

[BoneFlute]

C žádné \s ani nezná.

Já vím.

V jakém jazyce to programujete, že vás první pokus o použití regexu nemilosrdně nevyškolil právě v použití těch escape znaků?

Nerozumím.