- Samsung Galaxy A34 - plus size modell
- iPhone topik
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Fotók, videók mobillal
- Samsung Galaxy S25 - végre van kicsi!
- Samsung Galaxy A54 - türelemjáték
- Középkategóriást mutatott be újra az Oppo
- Huawei Watch GT 5 Pro - egészség + stílus
- Hónap végén érkezik a Xiaomi Band 10, ára is van
- Samsung Galaxy S21 FE 5G - utóirat
Új hozzászólás Aktív témák
-
"process ütemezés, memória management, I/O is jól odaver a Windowsnak. Tisztességesen scriptelhető, parancssorból is jól használható"
OMG, semmi baj nincs azzal, ha van preferenciad, etc., de attol, hogy nem ismersz egy adott rendszert, az teged minosit, es nem a rendszert.
Mindket rendszer tokeletesen scriptelheto, parancssorbol hasznalhato, az I/O meg memoriamenedzsment dolgokat inkabb hagyjuk is.Azert tanulja meg a Linuxot, mert nagyon elterjedt szerveroldalon, van, amire kenyelmesebb hasznalni, es tagitja a latokort, ne pumpaljuk mar a hulyeseget a fejebe az elejen, hogy 'az jobb, es kesz'.
-
válasz
#56230144
#6770
üzenetére
Ne Java-val kezdj, teljesen felesleges. Nem tul egyszeru elindulni vele, van benne egy csomo olyan minta/tervezesi dontes, ami kb. a teljes ipar szerint nem szerencses, es ha tanulasrol van szo, akkor nem az szamit, hogy mennyi multicegnel hasznaljak... az osszes top egyetemen (Stanford, MIT, Berkeley, stb.) Python, Haskell meg Lisp az elso nyelv, amit tanitanak. Szoval ne Javaval kezdj, csinald meg eloszor ezt, peldaul.
Pythonban ha beirod, hogy 2+2, akkor kikopi, hogy 4, ehhez Java-ban legalabb letre kell hoznod egy osztalyt, importalni az alap namespace-eket, statikus Main fuggveny, leforditani a forrast, aztan elinditani a VM-et.. elso nyelvnel (is) nagyon fontosnak tartom, hogy legyen REPL.
-
#6717
emvy
félisten
kornyiktamas
#6716
válasz
kornyiktamas
#6716
üzenetére
Tudsz angolul olvasni?
-
#6606
emvy
félisten
WonderCSabo
#6605
válasz
WonderCSabo
#6605
üzenetére
Persze, ilyen trivialisan egyszeru esetben szol a compiler, ellenben attetelesebb szituaciokban nem feltetlen -- pl. mindenfele szerializacios esetekben.
-
#6599
emvy
félisten
WonderCSabo
#6598
válasz
WonderCSabo
#6598
üzenetére
Igazad van, a metaadatok koze bekerul, de runtime tipusellenorzes ettol meg sajnos nincs:
public class IntegerList extends ArrayList<Integer> {
}
public static void main(String[] args) {
IntegerList l = new IntegerList();
ArrayList<Integer> l2 = l;
ArrayList l3 = l2;
ArrayList<Object> l4 = l3;
l4.add("Hello World");
System.out.println(l.get(0)); // "Hello World" sztring az IntegerList elso eleme
}Ehhez kepest:
Ezek persze mind megszokhatoak, csak csokkentik a tipusbiztonsagot.
-
#6596
emvy
félisten
WonderCSabo
#6595
válasz
WonderCSabo
#6595
üzenetére
> class IntegerList extends List<Integer> {}
vegulis meg igy se, mert az IntegerList az egy sima List lesz csak, Objecteket fog tarolni..
-
En a generikus parameter tipusara gondoltam, nem ugy altalaban az RTTI-ra. Tehat arra, amit te is irsz. Hallottam mar a reflectionrol.
De gondolom mindenki irt mar olyan konstruktorokat, ami a generikus parameternek megfelelo osztaly objektumot is varta (kb. public SomeClass(T1 param1, T2 param2, Class<T1> clazz1, class<T2> clazz2, mert szukseg van ra .. -- egyszer irtam egy cuccot Hibernate fole, ami okos proxykat/wrappereket gyartott, amik a peldany getter/setter hivasait elkaptak runtime, na az tele volt ilyen hekkekkel).
-
#6587
emvy
félisten
Aethelstone
#6586
válasz
Aethelstone
#6586
üzenetére
Mint a ... ? A C++-al nem erdemes hasonlitani, mert ott nincsenek generikusok, csak templatek, az meg tok mas, a <> jelolesen kivul sok kozuk nincs egymashoz. A .Net-hez kepest miert kenyelmesebb a Java generikus-megvalositas?
-
#6585
emvy
félisten
Aethelstone
#6584
válasz
Aethelstone
#6584
üzenetére
Azert az, hogy runtime nem elerheto a tipusinformacio, nem annyira kenyelmes... meg ugye a boxing...
-
#6565
emvy
félisten
beleszólok
#6560
válasz
beleszólok
#6560
üzenetére
Az ArrayList az pont az, mint amit a dynamic array Pythonban, szoval ne szomorkodj tul sokat. Ugyanugy amortizalt O(1) az append, O(N) az insert, es O(1) az index..
-
#6564
emvy
félisten
beleszólok
#6560
válasz
beleszólok
#6560
üzenetére
A Scala sokkal fiatalabb nyelv. Egyébként terjed rendesen, a pénzügyi szférában már tolják rendesen. A compiler elég lassú még, a nyelv meg eleg nagy (komplex).
-
#6562
emvy
félisten
WonderCSabo
#6561
válasz
WonderCSabo
#6561
üzenetére
Egy a keves jo design döntés közül
(aki CPPben jaratos,az tudja, mirol beszelek...) Operator overloading + implicit konverziók = katasztrófa.. -
#6552
emvy
félisten
beleszólok
#6550
válasz
beleszólok
#6550
üzenetére
> RAM-ból 16G azt hiszem, mostanság már majdhogynem alap.
Ja, csak a nyomorult gyartok nem raknak ennyit a gepekbe.
-
#6527
emvy
félisten
beleszólok
#6526
válasz
beleszólok
#6526
üzenetére
Java-ban nincs igazabol globalis valtozo, talan a szingleton all hozza legkozelebb, de neked meg erre sincs szukseged. A main-t tartalmazo osztalyodban legyen egy publikus AtomicInteger, aztan kesz.
Bar tuti jon valaki, aki elmondja, hogy dependency injectionnel lesz igazi enterprajz megoldas
Masik kerdesedre: az int az tuti atomic, a long az vagy atomic, vagy nem. Az int 32 bites, a long 64, a VM implementacionak garantalnia kell az intek atomikus irasat/olvasasat, a longoket nem. Belemehetunk abba, hogy ez miert van -- elsosorban azert, mert 32 bites architekturakon a 64 bites ertekek atomikus irasa teljesitmenyvesztessel jar.
-
#6524
emvy
félisten
beleszólok
#6522
válasz
beleszólok
#6522
üzenetére
Ez konkretan ugy nez ki, hogy van egy concurrentlinkedqueue, amibe a file reader tolja a sorokat, a masik oldalon meg van egy executorservice thread pool, ami szedegeti ki az elemeket, es egy AtomicInteger novelgetsz.
Ez kb. a Concurrency 101 elso hetenek consumer-producer peldaja egyebkent.
-
#6523
emvy
félisten
beleszólok
#6521
válasz
beleszólok
#6521
üzenetére
Nem hivjak valtozonak, erteknek hivjak. Mindegy.
-
#6520
emvy
félisten
beleszólok
#6518
válasz
beleszólok
#6518
üzenetére
Hat, attol fugg, hogy es mit akarsz kommunikalni, szinkron vagy aszinkron, etc. Ott vannak pl. a ConcurrencCollection-ok, de akar hasznalhatsz sima osztott referenciakat is alapveto szinkronizacios mechanizmusokkal (lock, condition, stb.) -- mindegyik problemas, mas-mas szinten..
-
#6511
emvy
félisten
Aethelstone
#6510
válasz
Aethelstone
#6510
üzenetére
Itt szepen es erthetoen leirjak (az elso valaszban).
De akkor roviden en is leirom -- egy klasszikus pelda a megoldasra: Option tipus.
Ha van pl. egy fuggvenyed, ami Integer ertekkel ter vissza, akkor a fordito garantalja, hogy az Integer lesz, es nem null. Ha egy masik, alapvetoen Integert visszaado fuggvenyed nem mindig tud visszaterni Integerrel, mert pl. kivetelt dobhat, vagy ilyesmi, es nincs mit visszaadni, akkor a fuggvenyed visszateresi erteke legyen egy Option ertek, amit viszont nem tudsz Integerkent hasznalni, csak ugy, ha mindenkepp ellenorzod, hogy van-e erteke vagy sem.
Option ret = enFuggvenyem();
switch ret {
case None: print "Nincs visszateresi ertek"
case Integer(i): print "Az Integer ertek: " + i.toString()
}Sokfele megoldas van, a lenyege az, hogy nem kerulhetsz olyan szituacioba, ahol elfelejted ellenorizni, hogy valami null-e vagy sem, mert a compiler garantalja, hogy vagy tuti van ervenyes ertek, vagy leellenorizted.
Ahogy Hoare is mondja (akit gondolom nem kell bemutatni):
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement.A lenyeg, hogy a nullreferencia nem egy szukseges rossz, hanem igazabol tok felesleges, amit a korai nyelvekbe raktak bele, hogy kicsit egyszerubb legyen megirni a compilert, es itt ragadt velunk. Csomo nyelvben (akar JVM alapu nyelvekben is) megoldottak, hogy ne legyen.
-
#6509
emvy
félisten
Aethelstone
#6508
válasz
Aethelstone
#6508
üzenetére
Mindenkinek az a normalis, amit megszokott. Gondolom a topicban senki nem haborodik fel azon, hogy a Java-ban van null erteku referencia, pedig talan a legrosszabb design hiba az egesz C/Java/C#/etc. nyelvi hagyomanyban, minden nap milliok futnak bele, pedig tipusos nyelvben siman el lehetett volna kerulni a letezeset (es akkor egyszeruen nem lenne NullReferenceException...).
-
#6477
emvy
félisten
PumpkinSeed
#6476
válasz
PumpkinSeed
#6476
üzenetére
-
-
#6470
emvy
félisten
Aethelstone
#6469
válasz
Aethelstone
#6469
üzenetére
Persze, hasznaltam eleget, remes.
-
#6467
emvy
félisten
Aethelstone
#6466
válasz
Aethelstone
#6466
üzenetére
Tudom, hogy viccelsz
, de valojaban pont errol van szo. -
Szamomra egeszen elkepzelhetetlen, hogy valaki nem kedveli a lambdakat
A list comprehension meg a lambdak tenyleg olyan alapfogalmak a programozasban, mint az 'osztaly', csak aki epp a Java-ba no bele, es massal nem annyira talalkozik, annak fura.Az a vicces, hogy a lamdbak hianya miatt, kenyszerusegbol letrehozott patternek annyira beivodtak egy csomo (Java-)programozo fejebe, hogy mostmar az tunik furanak, amit helyettesiteni akartak vele
Kicsit olyan, mintha azt mondanad, hogy az "1+2" kod az fura, mert valojaban az kene, hogy Adder a = new Adder(1,2); a.doAdd(); mert az elso az olvashatatlan, es fogalmad sincs, mi tortenik List<Integer> ints = new ArrayList<Integer>();
for (String s : list) {
ints.add(Integer.parseInt(s));
}
val ints = list.map(s => s.toInt)A masodik (Scala pelda) az azt mondja, amit valojaban akarok csinalni: egy sztringeket tartalmazo lista minden elemebol intet csinalni. Ennyi. A felso peldaban rengeteg a 'zaj', amit mar persze megszokott a Java-s szem, de konkretan nem tartozik az uzleti logikahoz az, hogy pl. deklaralok egy ciklusvaltozot.
-
#6448
emvy
félisten
Oppenheimer
#6447
válasz
Oppenheimer
#6447
üzenetére
Azt akarom mondani, hogy az a lenyeg, hogy mit csinalsz, a nyelv az nem annyira fontos. Valtani meg ugyis csomoszor fogsz.
-
#6446
emvy
félisten
Oppenheimer
#6445
válasz
Oppenheimer
#6445
üzenetére
A programnyelv tokmindegy, a domain a kerdes.
-
#6315
emvy
félisten
WonderCSabo
#6314
válasz
WonderCSabo
#6314
üzenetére
En se ertem, foleg, hogy a for az egy while ciklus + nemi szintaktikus cukor.
> mutatóramutatómutatóttatalmazómutató
Hajaj, pedig ez az eletben is sokszor elofordul
-
válasz
MrSealRD
#6285
üzenetére
Nem arrol van szo, hogy nagyon hosszu lenne a forditasi ido, csak folyamatosan rebuildelek, mert kiserletezem valamivel -- viszont a hotswap bizonyos okok miatt nem mindig mukodik. Ergo ha valamin valtoztatok, akkor varnom kell kb. 15 masodpercet, amig latom az eredmenyet, es ez most sok (mert rengetegszer kell varialni -- nem is azzal van gond, hogy sok idot elvesz, csak idegesito -- olyan, mintha egy mobilon akadozna az UI).
De ugy latom, kicsit megvarialom a workflow-t, es atallok REPL-re.
(Amikor C++-t csinaltam, ott volt akkora (ill. olyan szenne template metaprogramozott) projekt, hogy a projektben resztvevo osszes ember desktopja egyben compile szerverkent is funkcionalt, es amikor valaki forditott, akkor egyszerre kapott kb. 150-200 CPU magot, es igy tartott negyed oraig. Ja, es az IntelliSense nem mukott az IDE-ben, tehat siman benezhettel egy zarojelet valahol, es akkor a negyed ora vegen kaptal egy hibauzenetet, hogy itt hianyzik egy zarojel, forditsd ujra. Egyebkent meglepo, hogy meg lehet szokni azt, hogy preciznek kell lenni, amikor gepelsz. Az IntellIJ meg kabe elore megmondja, hogy ot perc mulva milyen nevu konstruktorparametert szeretnel, es felajanlja
) -
válasz
MrSealRD
#6279
üzenetére
Dehogy alantasabb, en csak annyit mondtam, hogy ha szorakoztato feladatot akar ES van ra lehetosege, akkor erdemes mast nezni. Mashogy mondva: kevesebb embert erdekelne hobbibol a J2EE, mint mondjuk a dronvezerlo algoritmus
Ettol meg irtozatosan elterjedt es sikeres dolgok ezek. -
A Scala meg a JavaEE szerintem nem fuggenek jobban ossze, mint barmilyen mas Java-s technologia. Ha a Scala ennyire tetszik, akkor nezd meg az extrem oldalat, pl. a Scalaz-t. Ha most jonnek ki az egyetemrol, akkor tuti megprobalnam elkerulni a Springet meg a J2EE-t, ennel sokkal erdekesebb dolgok is vannak a vilagban, es penzt keresni massal is lehet.
-
#6275
emvy
félisten
WonderCSabo
#6274
válasz
WonderCSabo
#6274
üzenetére
> megőrjítene
Jah, kell egy kis ido, amig az ember atall - erre mondtam lent, hogy legalabb megprobalni erdemes, mert jobb fejleszto lesz beloled, ha tobb oldalrol is megnezed ugyanazt a problemat.
Kiszerkesztetted valami miatt a peldad, de ha ujra visszarakod, elmondhatom
(egyebkent ennyi: (range 1 5)). -
#6268
emvy
félisten
Aethelstone
#6260
válasz
Aethelstone
#6260
üzenetére
> "szakma krémje"
Azt irtam, hogy a szakma kremje dolgozik ezeken a problemakon, ezert valoszinuleg a problemak valosak.
-
#6267
emvy
félisten
WonderCSabo
#6266
válasz
WonderCSabo
#6266
üzenetére
Na, ez egyelore nem ment at.
NEM lehet felulirni semmit, mert a visszaadott lista is immutable. Azert mukodik az egesz, mert csak immutable (megvaltoztathatatlan) listaid vannak.
-
#6265
emvy
félisten
WonderCSabo
#6264
válasz
WonderCSabo
#6264
üzenetére
Nem kell, pl. a lancolt lista vegulis nem mas, mint egy head elem. Tehat pl. egy 'rest' fv. annyit csinal, hogy elorelep egyet, es az lesz a masodik lista. A defensive copy az vegulis egy kenyszermegoldas, es pont jo pelda a mutable objectek problemajara.
Szoval ha van egy vektorod, ami a memoriaban az X es X+k kozotti helyet foglalja el, es egy fuggveny ebbol kiveszi az elso elemet, es visszaadja a maradekot, akkor a visszaadott vektor X+1 es X+k kozott lesz -- defensive copy eseten lemasolod az egesz vektort valahova, es az arra mutato referenciat adod vissza.
Persze ezek implementacios kerdesek, a lenyeg, h feltetelezheted, hogy az immutable kollekciok eleg jo teljesitmenyuek.
-
Nem hagyja ki -- mindketto pont ugyanugy mukodik. A for loop harmadik resze egy kulonallo statement, ami eloszor vegrehajtasra kerul, es UTANA ertekelodik ki a kilepesi feltetel. Akkor lenne kulonbseg, ha a kilepesi feltetelben inkrementalnal, pl:
for i = 0; ; i++<10; // i = [0,10]
for i = 0; ; ++i<10; // i = [0,10)Viszont a lenti esetben tok ugyanazt fogja csinalni, pont ugyanolyan sebesseggel. C/C++-ban van kulonbseg, mert a prefix operator un. rvalue-t produkal, a postfix pedig lvalue-t. Elobbi gyorsabb par orajellel, ezert ha tenyleg csak inkrementalni akarsz, akkor ++i-t szokas hasznalni. Java-ban tehat nincs semmi kulonbseg.
-
#6259
emvy
félisten
WonderCSabo
#6258
válasz
WonderCSabo
#6258
üzenetére
Egy trivialis megoldas a copy on write es hasonlok. Egy pelda: funkc. nyelvekben nagyon jellemzo, hogy listakat hasznalunk adattarolasra -- most a lenyeg, hogy ertekek vannak egymas utan, nem az, hogy most vektorrol vagy lancolt listarol van szo. Ha pl. van egy olyan fuggveny, hogy 'rest', ami visszaadja a lista osszes elemet, kiveve az elsot, akkor ugye a fuggvenyhivas utan van mar ket listad: az eredeti meg egy masik, ami pont ugyanolyan, csak epp hianyzik az elso eleme. Az implementacio nyilvan okos, es nem fogja lemasolni a listat, az uj lista siman ugyanazokra az elemekre mutat, csak epp eggyel kesobbrol kezdi. Mivel az elemek ugyebar immutabilisak (nem irhatok), ezert ez teljesen biztonsagos, es gyors is.
A lenyeg, hogy alapesetben nem irsz felul semmilyen olyan erteket, amit valaki mashol meg hasznalhatna. Ha van egy erteked, az valtozatlan marad orokre. Tehat pl. nincs olyan, hogy for i = 0; i<10; i++ -- ilyen eszkozoket nem hasznalunk altalaban.
-
#6254
emvy
félisten
Aethelstone
#6253
válasz
Aethelstone
#6253
üzenetére
Nem hinnem
-- eleg intenziven foglalkozik ezekkel a szakma kremje az utobbi evtizedben, par apro dolog meg a Java-ba is beszivarog (lasd Java 8). Persze ugy nehez megitelni a dolog problematikussagat, ha mondjuk a Java-n kivul nem programoztal egyeb kornyezetekben. Ez az egyik oka, hogy erdemes kb. evente megtanulni legalabb alapfokon (egy kisebb projekt erejeig) egy uj nyelvet, szelesiti a latokort -- ha mondjuk senior fejleszto korodra mar irtal hasznalhato dolgokat legalabb 5-8 nyelvben, az mindenkepp hasznos. Csomo minden van, ami nem hianyzik addig, amig egyszer nem lattad -- pl. csomo Java-fejlesztot nem idegesit az, ahogy a generikusokat implementaltak a Java 5-ben, pedig egeszen elkepesztoen fajdalmas kb. minden mas implementaciohoz kepest. Ha viszont mittudomen, volt mar elotte C++ vagy C# tapasztalat, akkor legalabb tudod, hogy hogy kene mukodnie, ha rendesen meg van csinalva (es forditva is igaz, amig az ember pl. csak .Netet latott, addig nem ertekeli, hogy pl. a build rendszerek mennyivel jobbak JVM platformon; vagy a temahoz kapcsolodva: a mai napig ledobbenek, hogy 1000-1500 sornyi Java kod funkcionalitasa Scala-ban vagy Clojure-ben 50 sor, es vilagos, mint a nap).Tenyleg erdemes a lenti rovid eloadast (is) megnezni, meg esetleg megcsinalni az Odersky-fele (SZUPER) Scala-kurzust:
https://www.coursera.org/course/progfunSzerk.: egyeb pelda: ha valaki meg nem futott bele abba, hogy mekkora fajdalom a single dispatch, az hazudik
-
A klasszikus objektumorientalt programozasi stilusban az alapegyseg az 'identitas', kvazi a memoriaban elfoglalt hely. A mostanaban elkezdodott, modernebbnek mondhato felfogas szerint az alapegyseg az 'ertek'. Sajnos a Java sem tamogat igazan semmi mast, csak az identitasalapu programozast, barmennyire is probaljak megoldani a problemakat mindenfele patternekkel meg frameworkokkel.
Egy olyan vilagban, ahol nem referenciakat adogatsz, hanem ertekeket, hirtelen (majdnem) megoldodnak az olyan problemak, mint
- szinkronizacios problemak, adatkorrupcio
- (alacsonyszintu) deadlockok
- 3rd party libek kiszamithatatlan viselkedese (vajon mi tortenik a konteneremmel, ha odaadom ennek a fuggvenynek, aminek nem latok bele a forrasaba?)... satobbi. Erdemes nekiallni szerintem ennek a temanak, lesz piaca (meg egyebkent is nagyon szep dolog).
-
> Hiszen ha egy List is final, utána ugyanúgy lehetett a List-be elemeket tenni.
Jo meglatas - ami neked feltunt, az a 'constness', vagy immutabilitas koncepciojanak a (majdnem teljes) hianya a Java-ban. Az altalanos immutabilitas igazan hasznos lehetne, konkurens programozasnal (is) egy aldas, meg egyebkent is sokkal atlathatobb, bugmentesebb kodot lehet irni akkor, ha az ember ahol csak lehet, 'ertekkel' es nem 'identitassal' dolgozik.
-
-
válasz
plaschil
#6103
üzenetére
> public boolean kozeEsikE(Date aktualis, int teliKezdete, int teliVege) {
Ez egy eleg fura metodusnak tunik nekem, a masodik es a harmadik bemenoparameterrel nem kezdesz semmit.
> if (this.ertek.equals("HAZAI_KILEPESI")) {
Itt erdemes lenne forditva nezni az egyenloseget (("HAZAI_KILEPESI").equals ... ), hogy ne legyen problemad a null ertekekkel. -
Aha. Hat, multkor installaltam Windowst, aztan beirtam, hogy
C:\>cinst notepadplusplus 7zip java.jdk putty skype paint.net windirstat winscp greenshot git totalcommander conemu SourceTree foobar2000 kdiff3 Firefox poweriso IrfanView lighttable
... ittam egy teat, es mire vegeztem, ez mind fentvolt, magatol. A mysql, tomcat es tarsai ugyanigy felugranak, konzolbol. IntelliJ-t nyilvan nem tudsz repobol telepiteni te sem.
Szoval ezek a dolgok nagyreszt hozza nem ertesbol fakadnak es/vagy urban legendek. Lehet mindenen fejleszteni az esetek nagyreszeben. Van, ahol tenyleg jobb a Linux (peldaul Node.js-hez), van, ahol meg a Windows (nyilvanvaloan .Netes dolgokhoz).
-
#6066
emvy
félisten
Aethelstone
#6065
válasz
Aethelstone
#6065
üzenetére
Nem tudom, mit csinal az igazi ferfi, de az igazi mernok azt csinalja, ami a legegyszerubben elvezeti a celjahoz.
-
válasz
lakisoft
#6038
üzenetére
A helyedben csinalnek egy Java bevezeto-kurzust, vagy akar egy ilyesmit: [link], mert most itt elkezdhetjuk magyarazgatni, hogy mi az a stack trace, meg referencia, meg ilyesmi, de nem fog az mukodni, hogy a forumon tanitanak meg az alapokra.
A NullPointerException egyebkent egy eleg sulyos programnyelv-tervezesi hiba eredmenye
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. In recent years, a number of program analysers like PREfix and PREfast in Microsoft have been used to check references, and give warnings if there is a risk they may be non-null. More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965. (Hoare)
-
#6028
emvy
félisten
PumpkinSeed
#6027
válasz
PumpkinSeed
#6027
üzenetére
import java.util.Scanner; // ez megvolt a fajl elejen?
-
Jah, azon mar szerencsere tulvagyok, hogy trukkos kodokkal bizonyitgassam, hogy jol megy ez
Viszont ebben az esetben erdekes a kerdes: vegulis csak annyit csinalok, hogy generalok egy intervallumot a honap-nap-parbol, es megnezem, hogy a bemenodatum beleesik-e, majd invertalom az eredmenyt attol fuggoen, hogy a masodik datum kisebb-e, mint az elso. Nem feltetlenul kevesbe ertheto, mint a sok if-then.En az agyon-objektumorientalassal vagyok mostansag igy. Mindenkinek ajanlom a lentebb linkelt Scala-kurzust, Odersky szepen bemutatja, hogy van elet az objektumokon kivul is. A Clojure, amit most csinalok, az meg vegkepp egy revelacio, egyszeruen fenyevekre van a kifejezoereje a Java-hoz kepest, peldaul az STM-implementacioja gyonyoru, tenyleg.
Gondolom mar mindenki olvasta, de ha esetleg nem: Kingdom of Nouns
-
-
válasz
caindwan
#6009
üzenetére
Oke, jatszhatunk ezzel
Szabalyok:
- van hat bemenoparameter, m, d, m1, d1, m2, d2 -- kerdes, hogy m.d. datum m1.d1 es m2.d2. koze esik-e (hatarok beleertve). Ha m2.d2. az evben korabban van, mint m1.d1, akkor ugy vesszuk, hogy m2.d2. a kovetkezo evre esik.
- feltesszuk, hogy a bemenoadatok ertelmesek (validaltak)Tesztek:
m d m1 d1 m2 d2
1 1 2 3 4 5 => false
1 1 4 5 2 3 => true
4 5 4 5 2 3 => true
2 3 4 5 2 3 => true
3 4 4 5 2 3 => falseAz en nevezesem:
public static boolean isInside( int m, int d, int m1, int d1, int m2, int d2)
{ return ((m2-m)<<4+d2-d)*((m-m1)<<4+d-d1)*((m2-m1)<<4+d2-d1)>=0; } -
#5998
emvy
félisten
PumpkinSeed
#5997
válasz
PumpkinSeed
#5997
üzenetére
Fajlnevvel egyezik, nem programnevvel.
A jo valasz az, hogy 'csak', igy dontottek a nyelvet tervezok. Oriasi otlet volt.
-
#5990
emvy
félisten
Aethelstone
#5988
válasz
Aethelstone
#5988
üzenetére
Az nem baj feltetlenul, nem kell mindennek keresztplatformosnak lennie..
-
Most épp Clojure-t programozom, azelott cpp meg c# volt, azelott volt java, szoval időnként keveredik a fejemben, hogy aktuálisan hogy implementalunk interfészt
A lentit is mobilon írtam, bocs, ha nem tökéletes a szintaxis Szerk. : clj előtt Scala volt, el is felejtettem
-
#5934
emvy
félisten
Aethelstone
#5933
válasz
Aethelstone
#5933
üzenetére
interface IIf <TReturn> {
TReturn IfTrue();
TReturn IfFalse();
void Execute();
}abstract class If<TReturn> implements IIf<TReturn>{
private Callable<Boolean> statetement;
public AbstractIf(Callable<Boolean> statement)
{
this.statement = statement;
}public override Execute(){
if (statement.call())
IfTrue();
else
IfFalse();
}...
IIf if = new If(....)
esatobbi.
(ha valaki beirja, hogy rivjun nala nem menne ez at, akkor bannoltatom) -
#5797
emvy
félisten
RaPiDsHaRe
#5796
válasz
RaPiDsHaRe
#5796
üzenetére
Attol fugg, mit kellene csinalnia
-
válasz
cacattila
#5690
üzenetére
Erdekes kerdes, par eve mar irtam egy ilyen rendszert, de a messaging maga az LatencyBusters/Ultra Messaging alapokon ment, ami egy IP multicast alapu szuperalacsony kesleltetesu uzenetkuldo rendszer, asszem mostmar az Informatica arulja, tehat csak a gepenkenti elosztott in-memory adatbazist csinaltam. Akkor meg nem talaltam pont ilyen, kesz rendszert -- a messaging reszre van csomo alternativa. (Mi olyan napi par szazmillio uzenetig skalaztuk a dolgot, a nap az 7.5 orat jelentett, LBM/UMS siman megoldja a konkret uzenetkuldest.)
A te esetedben ugy latom, az offline felhasznalas a legtrukkosebb resze a dolognak, altalanos megoldas erre biztosan nincs. Az offline verziot csak olvasasra hasznalnad, ugye? (Ha nem, az elsore nem tunik trivialisnak, mert valamilyen policy kellene arra, hogy kezeld a konfliktusokat/inkonzisztenciat.)
-
Mindket rendszer tokeletesen scriptelheto, parancssorbol hasznalhato, az I/O meg memoriamenedzsment dolgokat inkabb hagyjuk is.
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- AKCIÓ! GIGABYTE AORUS MASTER RX 6800 XT 16GB videokártya garanciával hibátlan működéssel
- Több Lenovo Thinkpad x1 carbon gen 4 / 5 / 6 / 7 X1 Yoga gen3 6-9. gen i7, i5 procik
- DDR5 8/ 16/ 32GB 4800-5600MHz SODIMM laptop RAM, több db- számla, garancia
- AKCIÓ! Sapphire Nitro+ RX 6800 XT 16GB videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! Lenovo ThinkPad T14 Gen 4 üzleti notebook - i7 1360P 24GB DDR5 RAM 512GB SSD Iris Xe W11
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged