to funguje treba ve vscode se spravnym fontem pro C, C++, ze alternativne zobrazuje opratory, treba preskrtnute = misto !=
6. 6. 2024, 05:51 editováno autorem komentáře
Je to tak, kdyby to nekdo hledal, rika se tomu font ligatures.
K clanku obecne: kdyz jsem zacinal s Julii, ktera Unicode operatory podporuje, tak moje prva reakce byla, ze tohle je nesmysl ktery urcite nevyuziju, ale mylil jsem se. Citelnost kodu to zvysuje, tak proc ne.
Citatelnost kodu to zvysuje pre tych co ho pisu a poznaju, pre ostatnych nie. Napriklad nadmerne pouzivanie pretazenia operatorov spravilo peklo z C++.
to plati i pro soucasne operatory. Napriklad me neprijde operator @ pro maticove nasobeni citelny, protoze je uplne mimo resenou oblast. Klidne bych tady pouzil stary dobry × . Podobne zapis mod, in nebo vsechno s neg by klidne sel napsat operatorem a asi by to kazdej pochopil.
6. 6. 2024, 12:07 editováno autorem komentáře
tady bylo nejlepsi pouzivat bezne matematicke oprace, ale sam typ by si je implementoval.
integer, float, komplexni cisla, matice by si samy definovaly pro sebe +, -, / atd.
Nie nutne. Operátor tohto typu je iba skrátený zápis volania binárnej funkcie. Pre funkcie platia preťaženia a v množine preťažení jednoducho budú kombinácie (alebo permutácie?), kde budú alebo nebudú skalárne a vektorové operandy.
Už si rozumieme. Keď som to písal, mal som na mysli násobenie, keď jeden operand je skalár. Nenabehla mi lokálna terminológia pre "dot product" a "cross product". Tie sa ale významovo značne líšia, takže by nemali mať rovnaký operátor.
Ale to přece nedává smysl - "standardní" +/* jsou použité nad nějakým fieldem (grupou, ... jiným algebraickým objektem) - definovat je u objektů, které s danou operací okruh/grupu/těleso netvoří (jako ty jmenované vektory) moc smysl nedává a opravdu by bylo vhodné použít jinou syntaxi.
(jo, tam kde je to jednoznačné jako + u stringů, tak samozřejmě ano)
Napríklad tvorcom APL alebo Numpy to zmysel dáva. Keď jeden operand je skalár.
A naozaj to dáva zmysle pre reťazce? Podľa mňa iba v prípade, že je vo všeobecnom povedomí, že ide o pripojenie obsahu jedného objektu k obsahu druhého objektu a nie o sčítanie jednotlivých prvkov na zodpovedajúcej pozícii v jednotlivých sekvenciách, ako by si človek mohol prvoplánovo myslieť na základe zahmlených znalostí z matematiky.
Ale to je v poriadku, ide o to povedomie, toto špecifikum je známe ľuďom, ktorí s tým pracujú a podobne iné špecifiká sú známe iným ľuďom, ktorí s nimi pracujú. Alebo by aspoň mali byť.
C++ nepisu, das nejakej priklad? Matematicke operatory pretezuju hodne a prijde me to vyborny, ale nepoznam Tvuj kontext.
Predstvte si, ze uvidite takyto kod:
tmp << strm;
tmp += aEnd;
ked clovek nie je hlboko ponoreny v kode, tak to nema sancu pochopit, hlavne ked vsteky 3 premenne su nejake custom typy.
No bezne som videl aj horsie priklady ked tam bolo pomaly viac operatorov a metod.
Radsej by som tam videl normalne volania metod/funkcii, ktore maju zrozumitelne meno. Ale zas pretazenie operatorov, ktore sa bezne pouzivaju v algebre na zhodne algebraicke operacie je OK.
Lenže človek má byť hlboko ponorený v kóde, keď s ním chce pracovať.
Ten kód si teda predstavujem. Vidím, že strm je na pravej strane, prvoplánovo ma napadne, že je to buď nezmysel, a strm má byť na ľavej strane a operátor má byť otočený, ale radšej si pozriem dokumentáciu alebo zdrojový kód. V súčasnosti stačí často prejsť myšou nad niektorý z operandov a niečo sa zobrazí.
Operátory sú vynikajúci spôsob ako vytvoriť DSL a písať v ňom, teda vlastne písať špeciálnym jazykom v kóde vo všeobecnom jazyku, čím môže vzniknúť veľmi elegantný a prehľadný kód bez opakujúceho sa balastu, ktorý svojim objemom iba zatieňuje vzťahy medzi objektmi.
Samozrejme, dá sa to iba v rámci možností a pravidiel daného primárneho jazyka.
Pokiaľ to človek nerešpektuje a neobťažuje sa naštudovať si na čo sa vlastne pozerá, tak sa nedá čudovať, že neuspeje. Ale to nie je chyba toho jazyka.
A bez přetěžování operátorů by tam bylo co? Dokážu si představit třeba
tmp.set( strm );
tmp.add( aEnd );
Zákaz přetěžování operátorů rozhodně autora nedonutí k nějakému srozumitelnému pojmenovávání. Operátory jsou jen standardní krátká jména, která mají celkem ustálený význam. Když autor kódu použil ty operátory v jiném významu, tak to vypadá že se snažil šetřit znaky. Takže bych čekal, že bude šetřit znaky i u jiných jmen funkcí.
chcete pouzivat silene znaky v programovani?!
delejte v APL
6. 6. 2024, 12:46 editováno autorem komentáře
Šílené je spíš muset místo naprosto normálního ≤ nebo ≠ psát <= nebo !=
To je těžké. Ony se ty naprosto normální znaky sází dost blbě. Něco pokryje font s ligaturama, ale k normálnímu matematickému textu to má stále dost daleko.
A sice žijeme v unicode dobách, ale s mnohamilionovou zakázkou na krku a managerem za zády bude na 100% jisté, že ten kód bude třeba upravovat po nějakém prehistorickém terminálu. ;)
7. 6. 2024, 23:30 editováno autorem komentáře