Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
Ahoj, chcem sa spytat na nazory na tieto dva jazyky, v com sa lisia, ktory z nich je z hladisa vykonu na tom lepsie a podobne veci. Dakujem.
Řešení dotazu:
Takze, co jsem zjistoval oba jsou objektove a rozsirenim jazyka C. Obejctive C se v soucasnosti pouziva na MacOS projektu GNUstep..C++ je oproti tomu velice rozsireny. Takze pokud nebudes programovat pro MacOS tak C++, jinak osobne C++..
NN
Nikto nema skusenosti?
v com sa lisia, ktory z nich je z hladisa vykonu na tom lepsie a podobne veci
Přijde mi to jako celkem zbytečná otázka, protože odpověď Ti stejně nic nedá, jelikož žádná jednoznačná odpověď neexistuje, stejně tak jako svět není binární tj. neexistuje jen absolutní dobro versus absolutní zlo. Záleží totiž na více faktorech:
Jak již bylo řečeno Objective C je ryze Mac OS X záležitost. Co se týče Unixů, tak tam je to zase o čistém C, případně C++, záleží o jaký SW jde. Třeba takový Blender, to jsou mraky kódu v čistém C a "trošku" v C++.
Jinak objektivní názor Ti nikdo většinou neřekne, protože každý je zastáncem toho "svého" jazyka. Ovšem na jazyku vůbec nezáleží, ten je třeba vybrat s ohledem na to jaký problém se řeší a s čím už má člověk zkušenost. Třeba v C jde vyřešit úplně všechno, byť to může být formou napsání dalšího "jazyka" specifického pro vyřešení daného problému. 
)
Mě se třeba moc nelíbí zbytečné obalování. Příklad: Mám železo se kterým se komunikuje na low-level úrovni. Tak borec komunikaci v C obalí C++, to obalí Javou a v ní napíše GUI. Opravdu úžasné řešení, s velice "potřebnými" mezivrstvami navíc. Jsou z toho pak desítky tisíc řádků, i když se řešení problému dá narvat do ani ne 10 000 řádků hezky přehledně v čistém C včetně multiplatformního GUI, které může být ostatně klidně v čemkoliv jiném pokud se problém rozdělí na dvě části a to klient + server.
Takže případně popiš jaký problém chceš řešit, a určitě se najde někdo kdo Tě nasměruje k tomu "nejvhodnějšímu" nástroji.
Pokud se ptáš zda-li použít na multiplatformní vývoj, případně na vývoj v Linuxu, Objective C nebo C++, tak jednoznačná odpověď je C++, má mnohem větší zázemí a např. ve spojení s Qt může dost zpříjemnit multiplatformní vývoj.
No ja som cital take veci, ze C++ je dost nepodarene objektove rozsirenie c-cka, kdez to Objective C je objektove rozsirenie ako ma byt. K Objective C som sa este nedostal, tak sa pytam, ludi ktory maju skusenosti z oboma jazykmi o ich nazor. Nejde mi o riesenie ziadneho problemu, iba ma to zaujima. Uvediem priklad: napisem kod v C++ bude mat ovela viac riadkov ako kod v Jave, ale v Jave pobezi pomalsie.
Podívej se do Umeni_programovani_v_Unixu_EN.pdf, konkrétně by Tě mohla zajímat zmíňka o C++ na straně 249.
No ja som cital take veci, ze C++ je dost nepodarene objektove rozsirenie c-cka
Na tom názoru se mi nelíbí slovní spojení nepodarene objektove rozsirenie, protože to pak vypadá jako kdyby se Bjarne Stroustrup's snažil o to, aby C++ bylo "OO jazyk se vším všudy". Kdyby mu o to šlo, tak C++ dnes vypadá úplně jinak.
Pak je také podle mě třeba rozlišovat "akademické" debaty od praxe. Protože právě praxe ukazuje co je životaschopné i mimo akademickou půdu. Hodně se mluví o tom jak jsou OO jazyky úžasné, moderní, šetřící práci, všechno v nich jde "samo" atp. To je, ale jen taková módní vlna, ve skutečnosti vůbec nezáleží na tom zda-li je jazyk OO nebo čistě funkcionální, protože o jeho kvalitách a použitelnosti rozhodují jiné faktory. Zkrátka to, že je jazyk OO != "kladná vlastnost a důvod pro jeho použití".
ale v Jave pobezi pomalsie
Podle mě to nejde říct takhle katerogicky, protože ne vždy musí být kód v Javě pomalejší.
Zkrátka jazyk není vpodstatě důležitý, důležité je především množství kvalitních knihoven a okruh problémů, které dokáží řešit.
9.6.2009 17:08
Vykook | skóre: 23
| blog: Tomas
No Java je IMHO pomala akorat na desktopu diky Swingu. Mimochodem za behu analyzuje kod a vypocetne narocne casti preklada primo do strojoveho kodu. V nekterych pripadech muze proto byt i rychlejsi nez C++. Jestli se pletu, tak mne nekdo opravte
Hypopeticky dokaze v nejkterych pripadech JAVA za behu(ne behem kompilace) vyloucit lookup do tabulky virtualnich metod a provadek kod metody inline. V takovych syntetickych pripadech je JAVA rychlejsi nez optimalizovany C++ kod.
Staticky C kompilator musi ponechat virtualnu vazbu vsade, kde nevie pocas prekladu rozhodnut, ktora konkretna implementacia sa puzije. Napr. preto, lebo sa jedna o kod kniznice a konkretna implementacia bude v klientskom kode. Java vie za behu zistit, ze sa pouziva konkretna finalna implementacia a moze virtualnu vazbu nahradit priamym volanim.To je pekna blbost. V mnoha pripadech je zrejme ktera metoda se bude volat a toto rozhodnuti je mozne provest v dobe kompilace.
Staticky C kompilator nevie robit Dead Code Elimination zalozeny na podmienkach, ktore nie je mozne vyhodnotit v case kompilacie; Java ano.Ano, tohle jsem uz videl. Kdyz budeme v C++ dynamicky detekovat informace, ktere jsou dostupne staticky, tak Java provede lepsi optimalizace. Veskery Dead Code Elimination (ktery je smysluplny) dokaze C++ kompilator provest v dobe kompilace. Komplexnejsi vyhazovani mrtveho kodu je absolutne nesmyslne.
Staticky C kompilator nevie robit Escape Analysis; Java ano.Tohle mi pripada jako dost Java-only zalezitost, resp. zalezitost pro jazyky s nejakym typem spravy pameti. Klidne se necham vyvest z omylu. Pokud jde o ztotozneni pametoveho mista promenne do ktere se uklada navratova hodnota volani a promenne, ktera se predava jako navratova hodnota, tak to je pomerne bezna optimalizace (C++0x pro to ma myslim podporu primo v jazyku).
Staticky C kompilator nevie robit dynamicky inlajning a loop unfolding; Java ano.OK, dobre, tady uznam ze to je jedina optimalizace, ktera by mohla ciste hypoteticky zvednout rychlost vykonavani programu. Ted je otazka jestli to ma nejaky meritelny dopad a zda budou vubec tyto optimalizace kodu trvat kratsi dobu nez je cas, ktery usetri. (v porovnani se statickym inlajningem samozrejme)
Tvrdenie "C je rychle, Java je pomala" per-se je FUD; dynamicky optimalizator moze vzdy optimalizovat kod ovela ucinnejsie ako akykolvek dobry staticky kompilator. A HotSpot v modernej Jave je velmi dobry.Ano, ale jaky kod. A kolik ty optimalizace stoji? To ze Java muze provest jiste typy optimalizaci ktere jsou pro C++ kompilatory nedostupne je pomerne jasne. Problem je v tom, ze tyto optimalizace vetsinou jenom castecne eliminuji vynucenou neoptimalitu kodu. Ano na vecech jako jsou matematicke vypocty, kde se provadi 1:1 mapovani na instrukce procesoru je Java stejne rychla jako C nebo C++ (ale tam jaksi nema proc by neoptimalni zadny jazyk ktery se nejakym zpusobem kompiluje). Jediny rozumny benchmark jazyku mi dava za pravdu: http://shootout.alioth.debian.org
Podla Teba su vsetci architekti v Sun-e blbci a do Javy implementovali uplne zbytocne veci, ktore robia viac skody ako uzitku?WTF? Co ma tohle proboha spolecneho s rychlosti vysledneho binarniho kodu? Podle tehle logiky jsou blbci snad uplne vsichni.
Komplexnejsi vyhazovani mrtveho kodu je absolutne nesmyslne.DCE v Jave je ovela komlexnejsia ako ta, ktoru je mozne vykonat staticky v case prekladu. Takze podla Teba v Sun-e implementovali absolutne nezmysly.
Staticky C kompilator musi ponechat virtualnu vazbu vsade, kde nevie pocas prekladu rozhodnut, ktora konkretna implementacia sa puzije. Napr. preto, lebo sa jedna o kod kniznice a konkretna implementacia bude v klientskom kode. Java vie za behu zistit, ze sa pouziva konkretna finalna implementacia a moze virtualnu vazbu nahradit priamym volanim.Nemluve o tom, ze po zjisteni realne adresy nema duvod (pokud neni dana promenna volatile) zjistovat adresu znovu, dokud nedojde k prepsani promenne.
No ja som cital take veci, ze C++ je dost nepodarene objektove rozsirenie c-cka, kdez to Objective C je objektove rozsirenie ako ma byt. K Objective C som sa este nedostal, tak sa pytam, ludi ktory maju skusenosti z oboma jazykmi o ich nazor.Tak zkuste k tomu čtení navíc něco dělat prakticky a brzo poznáte co Vám sedne a co ne. Názor někoho jiného je tady platný jak boty ušité na cizí nohu.
Uvediem priklad: napisem kod v C++ bude mat ovela viac riadkov ako kod v Jave, ale v Jave pobezi pomalsie.Kritériem pro použitelnost jazyka by v žádném případě neměl být počet řádků. Rychlost výsledného programu nemá s jazykem nic společného, spíše s případným překladačem nebo interpretem.
Jazyk ovšem implikuje množinu používaných překladačů a interpretrů, i když se jistě najdou nějaké obskurní kombinace :)Ne, to je právě mylný pohled. Kvalitu překladače / interpretu především implikuje poptávka. Jazyk maximálně usměrňuje způsob implementace a to nikoliv ve stylu lepší-horší ale ve stylu "tak nebo jinak".
sed -e "s/Asi jsem to/Asi jste to/" post sleep(21600)
podívejte se na konkrétní používané produktyvs.
nikoliv že musíme mluvit o konkrétních implementacích překladačů??? Každopádně tohle není o ekonomice (i když někde v pozadí asi ano), ale o prostém počtu a kvalitě lidí, kteří se věnují nějakému konkrétnímu překladači. Řešit překlad z javy do c++ asi nemá smysl (nikdo to nechce), ale existují svižné imlementace jvm i dobré překladače c++.
Java je pořád ještě o nějaké to procento pomalejší než C/C++, ale pomalá, to sotva. U Swingu bych to bral, tam se asi musí opravdu umět, aby rychlost GUI za něco stála, ale zbytek už pro téměř všechna použití naprosto nepředstavuje výkonnostní problémy.
How can we benchmark a programming language? We can't - we benchmark programming language implementations. How can we benchmark language implementations? We can't - we measure particular programs.Což znamená přesně to co to znamená a nic jiného. Pro nechápavé: benchmarkujeme konkrétní programy na konkrétním překladači, nikoliv jazyky. Pokud se na to podíváte podrobně, tak u různých programů jsou pořadí velmi různá a to i v rámci různých implementací v témže jazyce. Mimochodem, některé ty implementace jsou dokonce paralelní. Za druhé, nevím jak jste na základě toho došel k názoru, že nejrychlejší kód produkují překladače Fortranu :D Pokud něco, tak Fortran se používá pro matematické úkoly zejména z historických důvodů: většina dobrých implementací (např. LAPACK) tu totiž je již 20-30 let a pouze se optimalizují. Za třetí, kdybyste si přečetl ty benchmarky a i ty zdrojové programy pořádně, tak dojdete k názoru, že v závislosti na tom, co skutečně ve výsledku dělají s hardwarem naprosto odpovídají očekávání. Je stěží překvapující, že Java zaostává v programech, kde používá dynamickou alokaci nebo řetězce pomocí třídy místo statické alokace a char*; nebo že Ada zaostává v programech, kde intenzivně kontroluje výsledky aritmetických operací vůči rozsahu jejich typu. Pokud by použité implementace tyto vlastnosti nevyužívaly (nebo některé jiné je využívaly), jistě by to dopadlo jinak. Na druhou stranu se zamyslete nad tím, zda Vaše účetní aplikace skutečně vyžaduje, aby výsledek byl o 10% času (typicky pár sekund) dříve, nebo aby neudělal z -1 na něčí faktuře něco jako dvě miliardy. Jinými slovy, Vaše kydání hnoje na Javu je naprosto mimo... né že bych se zastával Javy, ale Váš přístup má víc děr než ten nejlepší ementál...
), mohli bychom se ptát, jak moc průkazný ten benchmark je, a tak dál. Mně ten výsledek prostě přijde dobrý. Plain C tam má například výrazně větší rozptyl než Java.
Což znamená přesně to co to znamená a nic jiného. Pro nechápavé: benchmarkujeme konkrétní programy na konkrétním překladači, nikoliv jazyky. Pokud se na to podíváte podrobně, tak u různých programů jsou pořadí velmi různá a to i v rámci různých implementací v témže jazyce. Mimochodem, některé ty implementace jsou dokonce paralelní.Coz je ale presne to o cem se tady bavime. Co je jazyk? Jazyk sam o sobe neni nic, to je jenom specifikace. Celou dobu se tady bavime o implementacich jazyka, protoze o nicem jinem se nema smysl bavit.
A pomohlo to? 
To bude ten problém. Spíš bys měl pracovat na sobě než na majitelích Alcatelů.
Mně třeba jsou Mercedesy a Alcately úplně volný.
Z toho nic. Já jsem jen blbeček. Nic víc.
Můj příspěvek výše byla jen zvrhlá a zavrženíhodná ironie.
Proto jsem napsal tu kravinu.
"rešení problému dá narvat do ani ne 10 000 řádků"
tohle je teda úchylka na n-tou. Frameworkách či jiných jazycích než C jste neslyšel? S největší pravděpodobností váš problém půjde vyřešit na méně než sto řádek, pokud použijete odpovídající nástroje.
O multiplatformním software si nechte klidně dál zdát. Právě na jednom pracuji (od z/Linuxu až po Windows). Většina zdrojáku se skládá z #ifdef ....
a) Ne vždy jsou na danou činost k dispozici odpovídající nástroje, a ne vždy se vyplatí použít "univerzální řešení". Dost často je výhodnější "řešení na míru", vše má pak člověk pod kontrolou a těch 10 000 řádků je to sakumprásk se vším všudy.
b) Ono když #ifdef ... přesuneš na nejnižší vrstvu a nad ní vystavíš vrstvu platformě nezávislou, tak se velice brzy dopracuješ do stavu, kdy tuto nenižší platformě závislou vrstvu odladíš tak, že do ní nemusíš zasahovat a používáš jen multiplatformní vrstvu nad tím.
Zkrátka svět není čenobílý a problémy jsou někdy dost specifické...
Objective-C: já si s tím hrál. Pokud nemáš Mac OS X, tak si ho buď pořiď, nebo na něj zapomeň.
Objective-C je blíž Javě než C++, takže pokud nemáš rád Javu, tento jazyk si nezamiluješ.
Jo — a bez těch Applích frameworků to nemá smysl. Maximálně tak na konzolový Hello World. A možná ani to nebude fungovat. Nevím, na zkoušení Open Source a Objective-C jsem neměl odvahu.
Tak to mas spis hodne spolecnyho Java s C++, nez Java s Objective-C :) Pokud nemas OS X, tak muzes pouzit GNUStep, Cocotron a X opensource knihoven. Navic jde Objective-C michat s C++.
Tak to mas spis hodne spolecnyho Java s C++, nez Java s Objective-C :)
Jen pár otázek:
Na to ti neodpovim, v C++ nedelam a v Objective-C jen par dni. Beztak jsem myslel hlavne podobnou syntaxi, u niz je podobnost Javy a C++ pomerne dost nepopiratelna.
V pohodě. Já měl na mysli objektový model. Java (a Objective-C) používá model Interface—třída s "jednoduchou" dědičností, zatímco C++ interfacy nemá a má mnohonásobnou dědičnost.
Přeji hodně štěstí s Objective-C.
Mimochodem: zkoušel jsi ty free frameworky? Jaká je jejich kvalita? Co vše uměj?
Teda ne že bych neměl rád javovská rozhraní (typ versus třída… ), naopak.
Vzhledem k tomu ze jedu na OS X, tak zatim nebyla potreba. Z Cocotronich stranek sem vycetl ze minulej rok pridali castecnou podporu Objective-C 2.0, vic sem z jejich stranek bohuzel nevycetl. Podle meho nazoru se bude clovek muset hodne krotit a kontrolovat aby s tim clovek v Xcode udelal aplikaci co pojede i jinde...
Vícenásobná dědičnost z C++ je v jistém smyslu ekvivalent pro ObjC protocol. Problém je ve vícenásobné dědičnosti a je znám pod jménem diamantový problém en.wikipedia.org/wiki/Diamond_problem. V objektovém programování má potomek schopnost hrát roli předka. V obrázku na odkazu ve wikipedii třída D nemůže plnohodnotně roli C protože přepsané metody z A se budou vyhledávat ve třídě B nikoliv v C. V C++ je problém ještě složitější, protože veřejné attributy jsou identifikovány jako relativní pointer vůdči počátku třídy a metody jsou pak indentifikovány jako číselný index do tabulky virtuálních metod (VMT). Při vícenásobné dědičnosti dochází ke konfliktům mezi těmito offsetty resp. indexy. Vícenásobná dědičnost prostě přináší spoustu problémů. Řešením problému pro attributy je zákázání vícenásobné dědičnosti. Řešením problému pro metody je opuštění identifikace metod pomocí číselných indexů ve VMT a nahrazením celé VMT hash tabulkou s klíčem typu string [jméno metody + typový seznam parametrů]. Tento klíč se jmenuje selector. Takovýto přístup Vám dá úplnou volnost pro dědění, ale jen pro metody. Dokonce můžete v ObjC implementovat metodu se stejným selektorem nezávisle ve dvou různých objektech a tyto objekty se pak budou chovat jako potomci jednoho (virtuálního) objektu, ze kterého dědí tuto metodu. Koncept protokolů v ObjC je pak jen pomocnou berličkou nad tímto mechanismem selektorů ( protokol = sada selektorů/metod ). Řešení se selektory přináší zase jiné problémy. Např. jak řešit kolize stejných selektorů pocházejících z různých protokolů a další.
Nyní se můžeme vrátit k Vaší otázce.
Protocol implementovaný v C++ by byla abstraktní třída bez jakýchkoli attributů. A tato třída by ve všech potomcích musela být děděna jako virtual aby se vám ve VMT objevovala jen jednou. ( class A : public virtual Protocol : public virtual Protocol ... versus class A : public Protocol : public Protocol ... )www.cprogramming.com/tutorial/virtual_inheritance.htmlBrr no fuj. Interface, ktery je implementovan castecne ve dvou ruznych tridach, ktere jsou pak podedene do spolecne tridy. Vetsi humus jsem uz dlouho nevidel.
Dalsi moznosti jak implementovat protokol/interface je pomoci sablon. Viz Andrei Alexandrescu: Modern C++ programing
Akorat to buhuzel ze zdrojaku neni nijak zrejmy ze se jedna to tento design pattern.
http://www.mujmac.cz/serial179.html
http://www.netmania.cz/iphone-uvod-do-objective-c
http://www.linuxzone.cz/index.phtml?idc=671&ids=2
http://funktion.eu/objective-c_cs.html
http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/ObjectiveC/Articles/ocCPlusPlus.html
http://www.ocs.cz/text/Cocoa/Objekty.html
http://www.ocs.cz/text/Cocoa/ObjectiveC.html
Ta zásadní informace je - Objective-C je sice podporován gcc, ale (!!!) libobjc, tj. ta nejzákladnější knihovna je pevně v rukou Apple, který vypouští pouze Mac OS verzi. Existuje sice GNU verze, která je ale hóóódně pozadu za specifikací a lepší to nejspíše nebude.
Takže - pokud máš Mac OS, tak rozhodně doporučuji. Jako objektová nadstavba + frameworky okolo je to neskutečně vymakané. Pokud nemáš Mac OS a chceš programovat na linuxu, tak se připrav na životní strádání a útrapy. Pokud chceš programovat na Windows, tak na to zapomeň.
Existuje nějaký Cocotron, ale v praxi jsem to nezkoušel www.cocotron.org/
Jinak ale souhlas s tím, že to má Apple fakt dobře vymakané.
A existuju v Mac OS X aj nieake vymakane frameworky pre C++ nieco podobne ako cocoa?
Cocoa můžeš používat i z C++. Přímých wrapperů je tam podporováno několik.
Carbon, jenze jeho vyvoj uz nepokracuje a za par let uz v OS X vubec byt nemusi...
No od Cecka rozhodne daleko neni a uz vubec nic nema spolecnyho s JavaScriptem. Jedna se v podstate o cisty C s objektovou omackou ze SmallTalku. Jde to dokonce tak daleko, ze zdrojak napsanej v cistym C jde zkompilovat Objective-C kompilatorem.
Jestli je teda něco FUD a slátanina, tak je to váš příspěvek. Na tohle nemá ani cenu odpovídat
Reknu ti to takhle. Ten kdo se v tom vyzna, ti tady nebude odpovidat, vsechno co se tady dozvis jsou naprosto FUDy.Souhlas. Například že Objective C má něco společného s Javascriptem. Dva dny jsem o tom přemýšlel a nepřišel jsem na nic. Oba jazyky používají složené závorky, ale to C a C++ také.
Jinak obecne Objective-C je pomerne cisty objektovy, vyrazne dynamicky jazyk. Od Cecka i C++ je dost daleko, spis ma bliz k Javascriptu.
S objective-c mám nějaké zkušenosti. Jazyk ma zajímavé fičury, ale přijde mi dost neohrabaný. Napsat v objective-c pitomý singleton je k posrání. Samozřejmě člověk ho napíše jendnou a potom jenom kopíruje, případně si udělá makro, ale v porovnání s luxusem v Jave to je utrpení. Dlouho jsem si zvykal na syntaxi a nemyslím si, že bych si úplně zvykl.
Frameworky od Applu v tomto jazyce napsané jsou ale výborné, to vidím jako jediný důvod proč tenhle jazyk používat.
Aha, takže jasně definovaný vícevláknový memory model a garbage collector v Javě? To je docela velká výhoda, odstraňuje spoustu problémů (lépe řečeno přenáší je na bedra toho kdo implementuje JVM).Jo, je přece lepší když se udělá pořádně JVM, ušetří se tak práce mnoha programátorů. Programátor rád přenese své problémy na bedra někoho jiného :).
Jinak mi přijde luxusnější Objective C, protože má metody třídy. Plus další feature, které se v Javě řeší reflexivní magií.Metody třídy jsou snad i v Javě, třeba v tom singletonu metoda getInstance.
Metody třídy jsou snad i v Javě, třeba v tom singletonu metoda getInstance.V Javě existují tzv. "statické metody", které skutečně na první pohled vypadají jako metody třídy. Ve skutečnosti jsou to ale jen obyčejné funkce (procedury) v namespace patřičné třídy. "Pravé" metody třídy jsou skutečné metody, které má objekt té třídy - instance metatřídy (tady by to asi chtělo obrázek). Prakticky řečeno: metody třídy se dají dědit a přetěžovat, stejně jako normální metody. Statické metody se dědit nedají (je možné v potomkovi definovat metodu znovu, ale jsou to pak zcela nezávislé procedury). Teď jenom doufám, že mě nešálí nespolehlivá paměť a všechno toto prakticky platí i o Objective C (přeci jen, je to už deset let).
Zkuste se na to podívat z pohledu volání metody. Buď v době překladu přesně víte jakou funkci zavolat. Pak se jedná o statickou metodu / metodu třídy. Typickým příkladem jsou konstruktory objektů. Pokuď nejste schopen určit jakou funkci volat (nevíte na ní ukazatel), pak musíte jít hledat do prototypu objektu (= třída) a jedná se o tvz. virtuální metodu/metodu objektu.
Z ohledem na tento pragmatický pohled se mi jeví konstrukce "pravé metody třídy" s možností dědičnosti a přetížení poněkud nesmyslná. Funkcionalita "pravé metody třídy" se totiž úpně překrývá s druhým uvedeným modelem volání a jednalo by se pak o běžnou virtuální metodu.
A _současný_ Objective-C snad nemá garbage collector?
Ano, Objective C může mít garbage collector, právě proto ten rozdíl nepovažuji za tak markantní.
I Java má metody třídy. Říká jim statické metody. Viz např. java.sun.com/docs/books/tutorial/java/javaOO/classvars.html.
To co mi v Javě oproti ObjC chybí je možnost akceptovat vpodstatě libovolnou zprávu (= libovolné volání metody). Příklad en.wikipedia.org/wiki/Objective-C#Forwarding
V ObjC mi zase chybí jmenné prostory.
I Java má metody třídy. Říká jim statické metody.To bych přirovnal k vepřovým špekáčkům z Lidlu za 20Kč/kg. Něco jsem napsal výše, něco je také zde.
To co mi v Javě oproti ObjC chybí je možnost akceptovat vpodstatě libovolnou zprávu (= libovolné volání metody). Příklad en.wikipedia.org/wiki/Objective-C#ForwardingAno, od toho bylo vytvořeno invokeDynamic. I když, pravda, ne do Javy jako jazyka.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
8.6.2009 21:02
14.6.2009 09:42
16.6.2009 15:11