Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
, teda jestli jsem se nekde neprehlidnul.
26.9.2007 11:45
satanatas | skóre: 14
| blog: vše co můžete s klidem hodit za hlavu ze světa linuxu i jiných světů
| Graveyard
24.9.2007 11:19
andree | skóre: 39
| blog: andreeeeelog
24.9.2007 14:23
michich | skóre: 51
| blog: ohrivane_parky
Jen me proste zaujalo, ze vyvojare "prekvapuje", ze distributori kladou duraz na zajmy svych zakazniku. Sokujici
24.9.2007 16:26
Jardík | skóre: 40
| blog: jarda_bloguje
V cecku to m.j. jde taky. Vzpomente si na vousaty priklad aplikace napsane jako prikaz for. Kultura a zdravy rozum zpusobuji, ze podobne vystrelky uz dnes vidime zridka. Zato v C++ se zkonstruovani objektu aplikace s overloadovanym operatorem funkcniho volani (misto volani main) povazuje nekterymi jedinci stale jeste za dobry (a jediny mozny) styl prace. Je to tim ze C++ je mladsi a slozitejsi. Ale lepsi se to.
Za spatnou povest C++ muzou prave silenci, kteri si mysli, ze musi vyuzit vsecky ficury uz v Hello World.
Jenže C++ opravdu není "C s featurami". Je to samostatný jazyk s odlišnou filosofií. Pokud napíšete Hello World jako
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
#include <stdio.h>
int main()
{
printf("Hello, world!\n");
return 0;
}
pak to sice C++ překladačem přeložíte, dokonce to bude i správně fungovat, ale není to programování v C++.
Proč myslíte? Mně na tom nic umělého nepřipadá:
#include <iostream>
int main()
{
std::cout << "Hello, world!\n";
return 0;
}
Svým způsobem je to možná i srozumitelnější než v tom C - hlavně pokud bychom pokročili kousek dál a do výstupu chtěli zahrnout třeba hodnoty nějakých číselných proměnných.
rozhodně nevznikne přirozenou cestou - musíte znát rozdíly a snažit se o to
xor jako identifikátor nepoužil v žádném jazyce, protože mi nestojí za to pamatovat si, ve kterém jazyce je to rezervované slovo a ve kterém ne, tak taková potenciálně nebezpečná jména nepoužívám raději nikde.
double bz;
void main() {
struct bz { int fn;}
printf("%d",sizeof(bz));
}
vypise v C i v C++ neco jineho akorat v mem pripade to bylo ve velkem programu a zasmodrchane.
-Wall.
Ten člověk, co psal, že C je bez problému C++ zdroják musel mít řádně vypito z láhve, a nebo - což je pravděpodobnější - věděl o tom hovno.
Bez ohledu na vaše silné výrazivo je to ovšem v naprosté většině případů pravda. Vážně byste jednou mohl zkusit argumentovat věcně, bez urážení oponentů a neustálého zdůrazňování, jaké jsou to nuly a jak ničemu nerozumějí. Pokud jste toho tedy schopen…
Přesná citace to sice je, ale ne z mého příspěvku. Takže pokud nemáte jinou, je mi líto…
Co se velkého kvantifikátoru týká, v běžné řeči nebývá zvykem ho implicitně používat v plném rozsahu. Nebo snad podle vás každý, kdo si povzdechne "lidi jsou svině", tím automaticky myslí všech šest miliard včetně sebe a toho, komu to říká? Asi ne… Proto také, pokud chceme v běžné řeči opravdu použít velký kvantifikátor, používáme pro zdůraznění každý, všichni apod. Ale to je stejně jedno, jak už jsem upozornil, příspěvek, na základě něhož mne pranýřujete, jsem nepsal já.
Jaké invektivy?
Už v dřívějších diskusích jsem si všiml, že nedokážete udržet diskusi ve věcné rovině a jakmile si s vámi někdo dovolí nesouhlasit, a co hůř, i po prvním okřiknutí si drze dovolí stát za svým názorem, okamžitě prokládáte své příspěvky poznámkami naznačujícími, jaký je ten člověk blbec, jak ničemu nerozumí, jak nikdy nic pořádného nenaprogramoval atd. Možná si to ani neuvědomujete, ale vězte, že je to nedůstojné a nechutné. Prosím vás proto, abyste toho nechal.
Ale já už si všiml, že jakmile někdo napíše, že C a C++ je totéž jen s malými rozdíly - že to znamená, že onen člověk prostě neumí pořádně ani C, ani C++. C a C++ jsou velmi odlišné jazyky s odlišnou filozofií, které jen stavěji na společném syntaktickém základu.
Nic takového jsem ovšem nenapsal. Pouze jsem napsal (nebo spíš podpořil kolegu, který to napsal první), že C je z hlediska syntaxe téměř podmnožinou C, protože těch odlišností, kdy se céčkový program nedá přeložit jako C++, je docela málo. A že vznikají buď tak, že se úmyslně snažíte takový program zkonstruovat, nebo že máte zatracenou smůlu (a mnohdy si za to můžete sám - jako třeba ve výše uvedené ukázce). To je prostě fakt - a kolik takových umělých ukázek tu zkonstruujete, to na věci nic nezmění.
Zajímavé. Proč mne tedy místo uvedení věcných argumentů hned na začátek příspěvku napadáte, že jsem nikdy nenapsal nic většího než pár řádků? A to se mi ani nechce dohledávat všechny ty povýšené pošklebky na mou adresu v minulé diskusi, kdy jsme se neshodli.
Stěžujete si, že tu na vás byli oškliví a že vás uráželi daleko hůř. Tomu docela dobře věřím. Ale dělal jsem to já? Zpochybňoval jsem snad vaši odbornou erudici? Psal jsem, že jste jakživ nic netriviálního nenaprogramoval? Nejsem si toho vědom. Takže pokud nejste schopen doložit že ano, znovu vás prosím, abyste se takových výpadů v komunikaci se mnou zdržel. Zkuste urážet a zesměšňovat jen ty, kdo se k vám chovají stejně, nedělejte to preventivně.
Protože bylo okamžitě z Vašich argumentů zřejmé, že obhajujete přístup, který lze použít jen u malých projektů.
Mně se osvědčil i u větších. Za prvé se snažím, aby těch globálních objektů bylo co nejméně (ne víc, než je nezbytně nutné). Za druhé zastávám zásadu, že každý modul by měl navenek poskytovat jen to, co je opravdu potřeba. Za třetí ten (programátor), kdo ty deklarace includuje, by se měl seznámit s tím, co includuje a na kolize dávat pozor. Za čtvrté se snažím udržet nějaké jmenné konvence, které by měly v co největší míře eliminovat možnost kolize mezi objekty různých typů (třeba proměnná vs. typ resp. tag struktury); ne že bych byl příznivcem takových těch prefixových orgií (t_ pro typy, m_ pro metody apod.), ale myslím si, že není takový problém najít rozumný kompromis. Myslím si, že jsou to poměrně rozumné zásady, které se dají uplatnit i u projektů, na kterých se podílí větší počet programátorů, a IMHO jsou v takových případech ještě důležitější než u projektu, který je dílem jednotlivce.
cc a zkusím je přeložit, u kolika se mi to podle vás povede? Podle toho, co tu píšete, by to vypadalo, že tak s bídou deset. Já tvrdím, že spíš od devadesáti výš. A kdyby to bylo všech sto, ani trochu by mne to nepřekvapilo.
char* buffer;
buffer = malloc(20);
by Vám v C prošlo, ale v C++ to nepřeložíte.
Dále prototypy funkcí v C a v C++ mají jiný význam:
třeba
int funkce();
int main()
{
...
a = funkce();
...
};
projde v C bez varování a C to pochopí jako dostatečnou informaci, zatímco C++ si bude stěžovat.
A tak bych mohl pokračovat dál a dál - je toho opravdu dost, kde jsou rozdíly mezi C a C++. Takže záleží na tom, co je konkrétně ve zdrojovém kódu, zda budete mít problémy s přeložením, a nebo (což je daleko záludnější) s jinou funkčností téhož v C a v C++.
Proto říkám, že já osobně bych si neodvážil udělat překlad C zdrojového kódu naslepo do C++ - očekával bych zde záludné chyby a to i v případě, že by to bezchybně prošlo C++ kompilací.
Proto říkám, že já osobně bych si neodvážil udělat překlad C zdrojového kódu naslepo do C++ - očekával bych zde záludné chyby a to i v případě, že by to bezchybně prošlo C++ kompilací.
Sice jsem to výslovně nenapsal, ale to bych se samozřejmě neodvážil ani já. Jedna věc je (akademická) otázka, zda typický C zdroják funguje i jako C++, ale vzít cizí céčkový zdroják a vrazit ho bez kontroly coby C++ kód do C++ projektu, to je samozřejmě něco úplně jiného. Vzhledem k tomu, že se u vlastních zdrojákům určitým zavánějícím praktikám vyhýbám i v C (třeba té ukázce s implicitním přetypováním pointerů), řekl bych, že u mých zdrojáků by to zase takové riziko nebylo (ale zkontroloval bych je stejně). Ostatně kdo píše střídavě v C i C++, ten si ve vlastním zájmu zvykne se takovým problémovým konstrukcím vyhýbat.
Ta druhá ukázka v C++ projde, ale asi tuším, co jste měl na mysli - že v C ta deklarace reprezentuje jakoukoli funkci vracející int, zatímco v C++ jen funkci bez parametrů.
Mimochodem, kdybyste si místo urážení oponentů ráčil přečíst, co píší, třeba byste si všiml, že prakticky totéž jako
C a C++ jsou velmi odlišné jazyky s odlišnou filozofií, které jen stavěji na společném syntaktickém základu.
jsem tu před pár hodinami napsal i já. Ale ono je jednodušší si honit triko, jak oponent nikdy nic nenapsal a vůbec nechápe, že je C++ něco jiného než C, že?
"struct bz" a "bz" jsou pojmenovány jinak. To že C++ ke každému struct/class dělá i zbytečný a pomýlený typedef (a nestará se o to co tím rozbije) je pak logicky jenom jeho problém...
Spíš ho neumíte vy. Jinak byste věděl, že klíčové slovo struct rozhodně nelze považovat za součást jména a identifikátorem je zde samotné bz, i když samo o sobě nemůže sloužit jako specifikace typu.
P.S.: koukám, že jste převzal argumentační styl pana Ponkráce (když už nemůžeme oponenta přesvědčit argumenty, prohlásíme ho aspoň za blbce), tímto mu gratuluji ke skvělému pedagogickému úspěchu.
25.9.2007 21:11
bz a struct bz jsou každý v jiném namespace.
Takový C programátor by spíš měl vědět, že
struct bz' není identifikátorPatche přidaly téměř 430 000 řádků, ale odstranily 406 000, což znamená, že jádro povyrostlo o 23 000 řádků
30.9.2007 04:14
David Watzke | skóre: 74
| blog: Blog...
| Praha
Tiskni
Sdílej:
