Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Služba Dropbox Sign (původně HelloSign) pro elektronické podepisování smluv byla hacknuta.
Byla vydána nová major verze 8.0 textového editoru GNU nano (Wikipedie). Podrobný přehled novinek a oprav v oznámení v diskusním listu info-nano nebo v souboru ChangeLog na Savannah. Volbou --modernbindings (-/) lze povolit "moderní" klávesové zkratky: ^C kopírování, ^V vložení, ^Z vrácení zpět, … Tato volba je aktivována také pokud binárka s nano nebo link na ni začíná písmenem "e".
Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
Byla vydána nová verze 12.0 minimalistické linuxové distribuce (JeOS, Just enough Operating System) pro Kodi (dříve XBMC) a multimediálního centra LibreELEC (Libre Embedded Linux Entertainment Center). Jedná se o fork linuxové distribuce OpenELEC (Open Embedded Linux Entertainment Center). LibreELEC 12.0 přichází s Kodi 21.0 "Omega".
Microsoft vydal novou velkou aktualizaci 2404.23 v září 2019 pod licencí SIL Open Font License (OFL) zveřejněné rodiny písma Cascadia Code pro zobrazování textu v emulátorech terminálu a vývojových prostředích.
OpenTofu, tj. svobodný a otevřený fork Terraformu vzniknuvší jako reakce na přelicencování Terraformu z MPL na BSL (Business Source License) společností HashiCorp, bylo vydáno ve verzi 1.7.0. Přehled novinek v aktualizované dokumentaci. Vypíchnout lze State encryption.
gcc -ansi -pedantic -Wall -Wextra -Weffc++
(nejnovejsi verze jsem nezkousel). Jeste prisernejsi byla podpora jazyka C, kdy dokonce bez varovani zkompiloval C++ konstrukce.
Kromě toho MS kompilátor v debug verzi má nacpanou do celé standardní C/C++ knihovny i do STL knihovny spousty kontrol - je tím doslova prošpikován a přijde Vám na kdeco - na memory leak, na špatné použítí zásobníku, na nekorektní použití STL (což se dá v STL, které je zticha pak řadu dní hledat), na to, že pouštíte několik threadů do místa, kde to nemáte threadově safe, nebo synchronizované a stovky dalších.Tohle GCC neumi, ani umet nebude, protoze na to jsou samostatne nastroje. Mozna jsou tohle nejake vychytavky posledni verze, nebo managed C++ ale nic z toho co pisete mi MS kompilator nehlidal.
Dále jak gcc, tak MS přeloží standardní C/C++ naprosto v pohodě. Oba kompilátory jsou zdarma. Pro běžná použití není jediný důvod, proč dát na Windows přednost GCC, máte-li standardní C/C++ zdroják. Proto také většina multiflatformních projektů (třeba jako Apache) na Windows překládá přes MS kompilátor.Intel C++ kompilator je taky zdarma. Jinak napriklad Opera pouziva GCC i pod Windows. Moje osobni zkusenost je ze prekladat primarne pomoci MS kompilatoru je nejhorsi mozne rozhodnuti. Finalni preklad je jina vec, ale i tam jsem narazil na podivne pady pri pouziti STL (i kdyz nektere verze GCC jsou na tom podobne).
Já tedy raději snesu kompilátor, který primárně najde závažné chyby v mém kódu a až na druhém místě mě bude oznamovat soulad se standardem. Já osobně nepotřebuji hlášky o souladu se standardem - za cca 10 let praxe v C a o trochu víc poté v C++ už z hlavy vím, jak psát, aby to bylo "ISO C++ compliant".No to je hezke a pak to neprelozim na dalsi verzi kompilatoru ani na vedlejsim pocitaci, nemluve o jine architekture. Btw. ty prepinace zapinaji slabou (na splint to nema) verzi static checkeru.
Ale když si začnu hrát se šablonami trochu víc - pak gcc je žalostné s hlášením chyb. To je víc o luštění šifer lezoucích z gcc. A jak říkám, ohlásit chybu na jiném řádku je u složitějších věcí pro gcc běžná praxe - MS to nedělá.Pravda, ale problem mi to opravdu nedela. Clovek jenom musi vedet kam koukat.
Jenže samostatné nástroje prostě jsou _jenom_ samostatné nástroje. Nemohou zastoupit situaci, kdy sama runtime knihovna C/C++ hlídá každou maličkost, kdy kompilátor generuje do strojáku kontrolní sekvence včetně testů všeho možného a nemůže už vůbec zastoupit kontrolu na takové úrovni, jaká je v STL v MS kompilátoru. Protože většina z toho je z pohledu samostatných nástrojů zcela v pořádku a žádnou chybu prostě nezjistí, protože nemají jak. A tyto kontroly jsou v MS kompilátorech odjakživa.Muzete hodit nejaky link co presne to hlida? Docela by mne to zajimalo.
Prosím tedy o odkaz na Intel C++ kompilátor pro Windows zdarma. Předem děkuji.http://www.intel.com/cd/software/products/asmo-na/eng/compilers/clin/277618.htm
Zvláštní, já jsem zatím vždy narazil na pády pouze z důvodu chyby v aplikaci - přesněji v mých zdrojácích. Mimochodem, když už jste to nakousnul, tak v GCC není v STL unicode verze stringů a streamů, ač to má každý normě vyhovující C++ kompilátor obsahovat. Takže třeba std::wstring prostě smolenka s gcc. Ano vím, podle návodu si můžete nějak zařídit - snad zkompilovat svojí vlastní STL, ale mě se to nikdy nepovedlo, asi něco dělám špatně. Ale tyhle problémy jsem s MS kompilátorem nikdy neměl.No, docela bych chtel videt nakolik ovladate standard. Treba takove nevinne
std::vector<int> x; x[0] = 10;
nemusi vubec fungovat.
Nevim co vam na wstring nefunguje, ale tenhle kod prelozim naprosto bez problemu a naprosto bez problemu take bezi.
#include <iostream> #include <locale> #include <string> using namespace std; int main() { locale::global(locale("cs_CZ.UTF-8")); wcout.imbue(locale()); wstring s = L"Ťuťu, ňuňu."; wcout << s << endl; }
Na další verzi kompilátoru to přeložíte pokaždé, pokud jde o slušný kompilátor. A hlavně programátor musí vědět co používá, ne kompilátor. Kompilátor je od toho, aby přeložil a chytal chyby. Varování o nesouladu se standardem je hezká věc, ale podružná.Jestli mi chcete tvrdit ze microsofti extenze prelozim ve vsech verzich MS kompilatoru bez uprav, tak fakt chci videt dukaz.
Pak jste lepší, než nejlepší machři v C++. Protože těm to problém dělá.Jediny rozdil ve vypisu je ten ze GCC na kazdem miste, kde se odkazuje na sablonu vypisuje jeji kompletni instanci. Duvod je jednoduchy, kdyz to chci zkratit, tak si to proste vyfiltruju (coz za mne udela IDE - napriklad Kdevelop), jinak dostanu kompletni informace.
Děkuji za odkaz, nicméně chápete, že slovo "for Linux" není kompilátor pro Windows?Nejak mne nenapadlo ze je to jenom pro Linux, takze jsem to dal nezkoumal. V tom pripade sorry.
Prostě ono je hezké, že tu máváte o tom, že gcc hlásí, že zdroják není v souladu se stnadardem, ale ono by bylo možná lepší, kdyby gcc ten standard na všech platformách alespoň ovládalo. Už to by byl pokrok.No, za prve, Windows neni podporovana platforma GCC. Program se prelozi, ale nic nevypisuje, az budu mit chvilku cas, tak se mrknu jestli to je spatne natavenym locale, nebo proc to konkretne nefunguje.
To já dobře vím, že tohle není ok. Ale když to použijete v gcc, tak gcc ani nepípne - maximálně se Vám může program složit. A hledej šmudlo. Když tohle pustíte v MS kompilátoru, máte okamžitě vyskočenou chybovou hlášku s přesným popisem, že tohle tedy ne včetně jména proměnné, řádku a daších detailních informací, kde jste tuhle věc napsal.Pri prekladu nevypise vubec nic. Jenom pri behu sleti na asserci. Jestli tohle je ta slibovana kontrola kodu, tak to jsem rad za GCC + externi nastroje, protoze ty funguji mnohem lip.
Jediný rozdíl je v tom, že nevíte co píšete a asi jste nic složitějšího neladil. Ale gcc forever za každou cenu musí být podle Vás nejlepší, i kdyby bylo nejhorší.Nejak vam dochazeji argumenty. Jelikoz se zabyvam metaprogramovanim tak si dovolim tvrdit, ze jsem prekladal i hodne slozite zalezitosti. MS kompilator mi vypise identickou chybu co GCC s tim ze instance sablon vysekne pred samotny vypis a nevypisuje instanciated from, coz GCC defaultne dela. To je cely rozdil.
Zvláštní, máte na to důkazy? Nezlobte se, ale evidentně si neověřujete fakta ani v základním levelu - a nevážíte slova, která pronášíte (viz Váš odkaz na Intel kompilátor pro Windows), takže já Vám implicitně bez důkazů nevěřím.Jaky dukaz? Vzal jsem port kompilatoru gcc pro Windows, a prelozil ten priklad, ktery uvadim nahore. Preklad probehl bez problemu, ale jak uz jsem napsal nic se nevypsalo. Az budu mit cas, prozkoumam proc.
Navíc velmi pochybuji, že GCC nějak zvlášť bude vynechávat Windows.GCC je vyvijeno pro posixove systemy (coz standardne Windows neni).
Tak jo, hýčkejte si dál svůj sen o Vašich dokonalých nástrojích a já se budu držet svého.Klidne se ho drzte, jenom priste nesirte bludy.
Znovu říkám, překonal jste nejlepší světové odborníky na C++. Ti vidí zcela rozdílné věci, než Vy - takže prostě jste dobrej.Neco konkretniho by nebylo?
Zvláštní, že gcc nic takového netvrdí. Ba právě naopak - když si čtete jeho interní materiály o interních kódovacích pravidlech (měl jsem kdysi zájem gcc vypomoci), tak jsou závislí pouze na C a jeho standardní knihovně - a to jejich podmínka je standardní C89 kompilátor.http://gcc.gnu.org/install/prerequisites.html
Já jsem tuto část debaty prostě ukončil, protože z Vaší strany nepadl jediný konkrétní argument, například příklad, kdy Vaše dokonalé nástroje jsou účinnější, takže nemá smysl debatovat o emocionálním a citovém vztahu, které máte k tomu kterému kompilátoru. Já raději fakta.Jasne, jako treba ze gcc neumi wstring, ze?
for (int i=0; i<whatever; i++) { } for (int i=0; i<whatever; i++) { }to pri tom druhom cykle vyhodilo že premenná i už je deklarovaná, a bez toho int pred ňou to šlo. V neskorších verziách je to ok, ale neviem či MS vydali aj nejaký fix pre 6.
(vždy ale lze v produkčním prostředí ponechat starší verzi)Tím bych si u uzavřeného SW nebyl tak jist.
obavam se, ze ode dneska za 5 let bych uz rad s programovanim nemel nic spolecneho ... Ale ja potrebuji neco naprogramovovat jen obcas a prijde mi zbytecny se diky tomu vzdy znovu ucit jazyk, protoze jsem v mezidobi zase vsechno zapomel.Já myslím že není o čem diskutovat - evidentně mluvíte o zcela odlišných situacích s odlišnými nároky a je jen přirozené, že je vhodnější jiný jazyk. Dokonce to sám M.P. v této diskusi minimálně jednou zmínil, ale asi to zapadlo.
Ne, takže nic s rezervou neberu - kompatiblita buď je, nebo není. A ve sféře C, Ady, Fortranu, Cobolu je 100% kompatiblitaAni v C neni kompatibilita 100%. Pri zmene vydani C99 doslo k zmenam, ktere mohlo rozbit par programu. Koneckoncu proto ma GCC parametr -std, aby se s nim dala urcovat verce C.
Dobře, a Vy máte pocit, že kompilátory nepodporují a nebudou podporovat verzi Céčka podle standardu z roku 89?Nic takoveho netvrdim, jenom jsem rozporoval onu 100% kompatibilitu *jazyka* (nikoliv jeho implementaci).
Python 3000 je hlavně záruka, že Python syntaxi zaručeně změní a na starou se vyprdne - abych to řekl jazykem sprostého lidu.A kdyby Rossum rekl, ze vyda novy jazyk ABC, mel by si kvuli tomu vyhrady vuci pythonu? Pokud ne, tak jaky je rozdil, kdyz ten novy jazyk se jmenuje Python 3000 ?
Jenže ona jedne verze Pythonu končí ... Ale Python 3000 není nový jazyk, je to killer dnešního Pythonu a tak se oněm jednáA na zaklade ceho tvrdis tohle? Pokud bude soucasny python nekoho zajimat, tak ho nekdo bude dal udrzovat a vyvijet. A v distribucich bude paralelne nekolik pythonu.
"Javovská virtuální mašina je 3 milióny řádků v C++ jazyce"Ale? Když jsem si naposledy stahoval trunk JRE 7, bylo to šest set tisíc, jestli se nepletu.
A dnes, když se projednává další verze C++ (zcela zpětně kompatibilní s předchozí jak je u seriózních jazyků zvykem)C++0x nebude zcela zpetne kompatibilni.
Tiskni Sdílej: