Mi is az a C#?
2004-03-16T20:51:09+01:00
2004-03-18T10:54:43+01:00
2022-07-27T13:37:49+02:00
  • A forráskódból fordítás eltartana egy ideig,

    na ja, a gent.... is vagy 2 napig fordul

    csak annyit a védelmemre: ittennék alább applikációról beszéltünk.

    Most akkor bővebben kifejtem:
    a leírt módszer kétségtelenül avítt, sok-sok éve találták ki, amikor talán még kisfiúk voltunk mindannyian. A gondolat lényege: mivel annyira különböző a proci, mindent forráskódban adunk (FIGYELEM! semmi köze nincsen a linux/GNU/GPL-hez! Ezek keményen piaci áron értékesített termékek voltak), aztán ha a usernek van egy alaprendszere, akkor semmi gond.
    Ebbe a körbe akár a Delphi nnnn (és akármilyen egyéb csodabigyó)is beleférne, ha mondjuk a VCL-jét vagy mi van neki lehetne forrásban terjeszteni
    Mutasd a teljes hozzászólást!
  • Ezt a kérdést már megválaszoltuk itt is:
    nem lehet megoldani.
    Mutasd a teljes hozzászólást!
  • Feltettem a kerdest a tudastarban.
    Mutasd a teljes hozzászólást!
  • Nem rossz ötlet. A kis linux distribemben van úgy 1500 csomag most feltelepítve. A forráskódból fordítás eltartana egy ideig, nem véletlen hogy a linux distrók közül is csak a nagyon elvetemültek próbálkoznak ilyesmivel.
    Ráadásul erősen kétlem hogy az az end user akinek az is kihívás ha a zip fájlt ki kell csomagolni örülne ha forrásból kellene felraknia a programomat. Arról nem is szólva hogy ehhez először vennie kellene egy Delphi 7-et vagy Kylix3-mat ami kissé megdrágítaná a programot
    Mutasd a teljes hozzászólást!
  • Mint mondtam lehet több binárist kiadni, de ha ma kiadsz egy binárist akkor azt nem tudod a holnapi procikhoz fordítani.


    Forrás kiadás?
    úgymint: ./configure; make ; make install;
    Mutasd a teljes hozzászólást!
  • Ha a 2 opcionális paraméter típusa megegyezik, akkor utolsó paraméternek megadhatsz paramétertömböt (szabadfordítás :)). Aztán ennek elemszámától függően tudod, hogy mennyit kaptál.

    És ha megkérhetlek legközelebb Tudástárba az ilyen kérdést :). .Net és C# pontokat szívesen gyűjtök.
    Mutasd a teljes hozzászólást!
  • Az fasza, mert nekem 4 parameterem van, abbol 2 nek kene default ertek.
    Akkor az 4 fuggveny.
    Mutasd a teljes hozzászólást!
  • Nem lehet. Két külön függvényt kell csinálni, az egyik paraméterlistájából kihagyod a paramétert, és meghívod belőle a másikat:

    void a(string x, int y) {
    ...
    }

    void a(int y) {
    a("", y);
    }
    Mutasd a teljes hozzászólást!
  • Illetve nem opcionalis parametert, hanem default erteket parameternek.
    Mutasd a teljes hozzászólást!
  • Szevasztok!

    Itt keresgelek, hogy a p..-ba deklaralok fuggveny opcionalis parameteret c#-ban.
    Mivel a Basic.net ben is es a c-ben is van, gondolom a c#-ba is betettek.

    Ha tudja valaki a megoldast, (bar lehet addig megtalalom) irja mar le.

    Vagy marad az overloading?
    Kosz
    Mutasd a teljes hozzászólást!
  • Olyan tavol vagyunk ezektol az emberektol, mint Mako Jeruzsalemtol.
    Mutasd a teljes hozzászólást!
  • Ha már itt tartunk:
    Ha jól emléxem akkor a PathFinder hibáját meg úgy javították ki, hogy miután többnapi kínzás után sikeresen előidézték a fagyást a Földön is, kiderült, hogy a "priority inversion"nal állnak szemben. mivel debug infokkal volt futtatva az éles rendszer is, így megtudták azt a memóriacímet, ahol a priority inheritance bekapcsolását jelző paraméter átadódik, és közvetlenül megcímezve a területet bekapcsolták :). Azért ez is jó móka.
    Most jut eszembe:
    talán nem is debug infókról volt szó, hanem egy C interpreterrel ment a rendszer. Ez még jobb :).
    Mutasd a teljes hozzászólást!
  • A PathFinder oprendszere VxWorks volt. A QNX nekem is szimpi, de a NASA-nak valószínüleg mások a szempontjai.
    Mutasd a teljes hozzászólást!
  • Hat gondolom a NASA mernokei egy kicsivel a vilag elott jarnak. El nem tudom kepzelni, hogy tudtak rendbe hozni a spiritet, mikor a memoriai meghibasodtak. Majd talan egyszer mi is megtudjuk, hogy kell es mivel lehet ilyen hibaturo rendszereket csinalni. Bar ha a most elerheto rendszereket nezem, qnx-re tippelnek mint realtime system, ada-ra mint nyelv.


    A roverek nem tulsagosan hibaturoek, van bennuk egy kozponti rendszer es egy biztonsagi alrendszer. A biztonsagi alrendszer a forendszer meghibasodasa eseten a low gain antennarol kepes ujratolteni a rendszert. (kb. 300 bit/sec) Ezen kivul kepes irni/olvasni a fo rendszer memoriajat es hattertarait.

    A hattertarak ket flash kartyat jelentenek, amiken sajnos fat filerendszer van. Ezeket kellett leformazni, hogy a rosszul megirt fat driver ne egye meg a memoriat a rendszer inditasakor. (ez azert van mert a gyors elereshez felepit egy leirotablat, amiben minden file benne van, es ezert bizonyos szamu file folott ettol lehal a rendszer)

    Ilyen szervizprocesszor volt mar a vax vms mainframe cluster-ekben is a 60-as evekben, es hasonlo modon mukodnek a mai fallback bios-ok is, amik hibas bios frissites eseten floppyrol irjak ujra a biost. Annyi valtozott, hogy itt hiba eseten a folrol jovo radioadas az uj adatok forrasa.

    Viktor
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Hat gondolom a NASA mernokei egy kicsivel a vilag elott jarnak.
    El nem tudom kepzelni, hogy tudtak rendbe hozni a spiritet, mikor a memoriai meghibasodtak.
    Majd talan egyszer mi is megtudjuk, hogy kell es mivel lehet ilyen hibaturo rendszereket csinalni.
    Bar ha a most elerheto rendszereket nezem, qnx-re tippelnek mint realtime system, ada-ra mint nyelv.
    Bar tudja a fasz.
    Kicsi vagyok en ehhez.
    Mutasd a teljes hozzászólást!
  • csak szvsz keveset és lassan.


    Mint ahogy a .Net is lassan terjed. Szeritnem még nem ijedt be eléggé a SUN. Majd ha kicsit megnő a .Net-es fejlesztések száma...
    Mutasd a teljes hozzászólást!
  • Persze hogy csak natívra tud fordítani. De a te saját géped tulajdonságainak megfelelően. Akár arra is optimalizálhat hogy mennyire gyors a memóriád vagy a processzorod. Persze a mai JIT-ek ilyenekkel nemigen foglalkoznak, de idővel megtehetik.

    Mint mondtam lehet több binárist kiadni, de ha ma kiadsz egy binárist akkor azt nem tudod a holnapi procikhoz fordítani. Arról nem is szólva hogy jönnek a 64 bites procik és nem biztos hogy minden egyes új verzió kiadásakor kedved van 5-10 binárist csinálni a különböző platformokra.
    Mutasd a teljes hozzászólást!
  • 1.5-ös nem vezette be a propertit?


    Hát nem. És nekem az a legnagyobb bajom az egésszel hogy Pl. a property-k már réges-régen, már jóval a java megjelenése előtt léteztek, meg még egy rakás más dolog is ami nincs a java-ban, Pl. operator overloading, stb. Ráadásul már időtlen idők óta probléma hogy desktop oldalon minden java alkalmazás külön JVM-et indít, de az 1.5-ig a SUN-ék erre is magasról tettek. Most hogy megjelent a konkurrencia már kezdenek fejlesztgetni, a swing sem annyira lassú már mint anno (ezzel együtt is rohadt lassú de valamit tényleg gyorsult). Azaz most elkezdődött valami fejlesztés, csak szvsz keveset és lassan.
    Mutasd a teljes hozzászólást!
  • Erről már hallottam. Utána kéne már olvasnom. Érdekelnek a realtime rendszerek, és ez azért elég nagy érdekesség ezen a területen (mint mondjuk a PathFinder fagyásai anno).
    Mutasd a teljes hozzászólást!
  • JIT akár gyorsabb is lehet majd mint a natív kód:


    Ez azért lenne csak furcsa, merthát a JIT sem tud mást tenni, mint natívra fordítani. Amit a késöbbiekben írtál, az szerintem azért nem állja meg a helyét, mert egyrészt:
    386-osra ma már nem illik fordítani egy progit, főleg ha XP-re vagy NT-re írtad :).
    Másrészt:
    Ha valóban számít a sebesség, akkor a natív progiból is kiadsz 2-3 változatot és megint te vagy a jobb (elvégre nem 2-3 CD-t kell kiadni, csak a binárisokból kell több változat az 1 CD-re).
    Mutasd a teljes hozzászólást!
  • Gondolom a
    spirit, es opportunity marsjarokon.
    De nem is a sebessegukrol hiresek.
    :)
    Mutasd a teljes hozzászólást!
  • Elnézést, én fogalmaztam rosszul. Csak reméltem, hogy az előzmények tükrében helyesen értitek majd. UGyanis amire válaszoltam, ott a következő állt:
    Azert kivancsi lennek mikor allna neki egy csapat jit compilerrel egy olyan proginak, ahol a sebesseg a fontos.


    Ez nem sebességkritikus, hanem "a sebeség fontos" típusú alkalmazások. Természetesen hard realtime rendszereket nem kellene .Net-ben programozni (bár realtime jáváról hallottam már, de nem tudom hol használták már).
    Mutasd a teljes hozzászólást!
  • Hat a java talan pont egy ilyen pelda.
    Nekem nem ugy nez ki.

    Termeszetesen majd a jovo eldont mindent.
    Mutasd a teljes hozzászólást!
  • Ugyanez igaz a java esetén is...


    1.5-ös nem vezette be a propertit? Ha rosszul emléxem, akkor is biztos lehecc benne, hogy a következő verzióba beteszik.

    hanem hogy komplex rendszereket tudj tervezni (gyakorlatilag nyelvfüggetlenül)


    Azért a tervezési fázisban is illik figyelembe venni az eszközt, ami majdan megvalósítja a tervet. Lehet nyelvfüggetlenül tervezni, de azért valamivel könnyebb és szebb lehet a végeredmény, ha a nyelv erősségeit kihasználjuk a tervezés során. Magasabb absztrakciós szint esetében pedig a környezet adta lehetőségeket kell figyelembe venni, amik különbözőek a Java eszközök és a .Net eszközök esetében.
    Mutasd a teljes hozzászólást!
  • Én olyasmiről is hallottam, hogy olyan JIT compiler technológiákon dolgoznak, amelyek vizsgálják az adott függvény hatékonyságát, és figyelembe véve annak előéletét újrafordíthatja a JIT compiler, hogy még hatékonyabb kód álljon elő.
    Mutasd a teljes hozzászólást!
  • Ez mind igaz!
    Harmadjara mondom, hogy a feladat dont el mindent, hogy miben kell megoldani.

    Eskuszom nem ertem. Most en vagyok hulye, vagy nem tudok fogalmazni.

    Nem akarok en sem (ha mar sarkositunk) assemblyben dolgozni a napi programozasi munkaknal, amire meg egy Visual Basic is barmikor tokeletes.

    Ne kotekedjunk mar egymassal legyszi.
    peace
    Mutasd a teljes hozzászólást!
  • Amúgy szvsz hosszú távon a JIT akár gyorsabb is lehet majd mint a natív kód: gondolj bele hogy ha csinálsz egy programot azt egy adott kódra fordítod. Azaz vagy i386-ra, vagy i486-ra, vagy i686-ra. Na most, ha i386-os procira fordítasz akkor az i686-on nem lesz az igazi, ha meg i686-ra akkor nem fog futni az i586-on. Ha ez a specializáció tovább folyik (AMD, Intel, stb) akkor vagy minden procihoz csinálsz egy binárist (mint egyes linux disztribekben van a kernellel) vagy csinálsz jó kis i386-os kódot. A JIT viszont akár kimondottan Intel P4-es kódot is tud fordítani. És mivel ez a technológia is fejlődik, előbb-utóbb lehet hogy jobbat mint a te kis C++ fordítód...
    Mutasd a teljes hozzászólást!
  • Akkor ezt nézd meg:

    C# 2.0 specification
    Mutasd a teljes hozzászólást!
  • De ha mar kotekedunk egymassal, akkor sebbeseg kritikus alkalmazasnal meg a win se jonne szoba, nem hogy just in time compiler.
    Vagy egy office teszem azt sebbeseg kritikus neked?
    Ne szivassuk mar egymast ilyen hulyesegekkel.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd