Hozzászólások
-
SzerzőBejegyzés
-
bár nem nekem szólt azért én is „beleszólok”, ha lehet 🙂
szerintem is jó tipp a Java (amugy prg nyelv választását a feladat _erõsen_ befolyásolja)
a C# sajnos ms specifikus dolog (bár a mono jó probálkozás)
java-hoz ingyenes ide netbeans (tud graf felületet is tervezni)
(ja és javaban van Bitset így nem kell foglalkoznod a bitek állítgatásával 🙂 )
Vérszagra gyûl az éji vad… 🙂
;P
„
„az,hogy egy int típus hány bájtos az a cputól,fordítótól,oprendszertõl függ!!”
Kizárólag a fordítótól:”na ja csak esetleg nem fog futni a target cpu-n 🙂
„nézhet ki így, tök mindegy, hogy milyen vas, vagy os van alatta (32 bites szegmenssel):”
tehát mégsem mind1…..
„na ezzel valóban az a helyzet, hogy 16 bites processzoron nem fut, bár attól, lehetne az int/longint 32 bites, de sokkal nehezebben lehetne bánni vele, mivel nincs általános célú 32 bites regiszter”
hoppá tényleg nem fut…. tehát megint csak nem mind1
„- az int deffiniciót az általános regiszterek méretéhez igazították”
tehát cpu függõ… ugye az os ezen nem tud változtatni…„de könyörgöm mutass már egy 16 bites processzorral ellátott pc-t? a 386-os processzor már 32 bites…”
nem csak a pckben van processzor amit programozni lehet….
„a gcc-ben pedig az int mindig 32 bites és azonos méretû, mint a long int, amíg a short int 16 bites, tök mindegy milyen rendszer alatt…”
persze bizonyos arch alatt a gcc-nek is van olyan kapcsolója amivel választani lehet hogy int 16 vagy 32 bites legyen (de alap a 32)…
„de, ha más fordítóval is ugyanazt a kódot kell elõállítani a short intet, vagy a long intet kell használni. az elõbbi mindig 16 bites, az utóbbi mindig 32 bites (ha jól tudom)”
sajnos nem pl embedded vc INT32 ami mindig 32 bit….
„Nos, most már belátható, hogy a cpu-tól csak praktikussági okok miatt függhet(ne), „
az bõven elég!„De a lényeg az, hogy a fordító olyan gépikódot generál, amilyet akar. „
ez biztos 🙂
„(Legfeljebb erõforrás pazarló lesz.)”
vagy nem fog futni 🙂 pl generálhat a fordító egy risc procira gépi kódot aztán futtasd x86-on 🙂
A little-endian big-endian számábrázolásbeli külömbségérõl tudok én is, de ez itt nem fog bezavarni.
[align=right][snapback]138431[/snapback][/align]tudom, azt nem is azért írtam, csak arra, hogy hogy néz ki egy szám a memóriában
Na szóval, amit írni akartam:
„Bocs de azt nem értem. A másik gép lehet pl egy windowsos gép vagy a SPARC is, ezért kéne a kikötés.”
– Az, hogy egy bizonyos változó típus mekkora helyet kap az a fordító specialitása, nem a oprendszeré. Pl. egy asm/gépikódú byte, mindig 8 bit, egy szó mindig 16 bit stb. lesz.[align=right][snapback]138091[/snapback][/align]
az,hogy egy int típus hány bájtos az a cputól,fordítótól,oprendszertõl függ!!
„The size of a signed or unsigned int item is the standard size of an integer on a particular machine. For example, in 16-bit operating systems, the int type is usually 16 bits, or 2 bytes. In 32-bit operating systems, the int type is usually 32 bits, or 4 bytes. Thus, the int type is equivalent to either the short int or the long int type, and the unsigned int type is equivalent to either the unsigned short or the unsigned long type, depending on the target environment. The int types all represent signed values unless specified otherwise.
„az, hogy a memóriában, hogy néz ki egy több bájtos valami az meg aztán pláne nem egyértelmû 🙂 (little-endian, big-endian)
Tisztelt
Sziasztok!
Nálam egy ideje m?ködik a mencoder-es felvétel, és id?zítés, de…
Hogyan lehet elérni, hogy egyszerre menjen a felvétel, és lássam is a TV m?sort?
Videolejátszóról történ? felvétel esetén nagyon pocsék lesz a min?ség hasonló parancssorral, pedig composit bemenet van. Mit kell másképp csinálni?
TiLK
[align=right][snapback]137299[/snapback][/align]mencoder -o rec.avi -meg amilyen opciókkal felveszel
másik konzol:
mplayer rec.avién még nem tudok hozzászólni — guest vagyok a portálon.
csak a fórum ismeri fel a sütimet.
[align=right][snapback]136931[/snapback][/align]szintén így járok már pár napja, gondoltam majd elmúlik, de mostmár orvoshoz fordulok 🙂
akkor az eredeti kérdéshez visszatérve (bár már írtak rá válaszokat)
Sziasztok!
Suse Linux 8 alatt szeretnék java forást fordítnai. Van a szerveren jdk 1.3. Szeretném úgy fordítani a java forrást hogy felmásolom a webszerverre majd belépek egy ssh klinesen keresztül (putty) távolról a szerverre és a konzolon keresztül lefutatom javac paranccsal a forrást. A gond az hogy Command not foun -al megáll sejtésem szerint path környewzeti változót kellen beállítani hogy hol keresse ezt a parancsot. Azt szeretném kérdezni hogy hol tudom ezt beállítnai.
Esetleg érdekelne bármilyen más lehetsõg is amellyel távolról szerveren tudom java forrást fordítani illetve azt követõen elindítani futatni.
A Válaszokat elõre is köszönöm Kampfer
[align=right][snapback]136595[/snapback][/align]path beállítása:
export PATH=$PATH:/ami/hiányzikde e nélkül is el kell tudni indítani a java-t, susen nem tudom pontosan hova települ
de valahol /usr/java környékén keresnémamúgy nem kell újra fordítani, megy az linuxon is ugyan úgy, meg solarison meg pocketpc-n meg …. 🙂
lehet, hogy ***-ul elfogult vagyok, de van rá okom, amikor többször tapasztatuk, hogy valami lin-en, meg mac-en tökéletesen kompatibilis winen meg mondjuk nem megy, esetleg, ha jól megfizeted
[align=right][snapback]136838[/snapback][/align]na igen, de itt javaról volt szó….
ha winen (sun féle) javac.EXE -vel 😛 lefordított progi nem futna linuxban az elég érdekes lenne (ráadásul semmi köze a microsofthoz 😛 , (bár mostmár van valami de ebbe ne menjünk bele))na mind1 részemrõl le van zárva fõleg mivel egyre kevesebb szakmai rész van a hozzászólásodban…
Szerintem egyik távoli asztal sem biztonságos….
[align=right][snapback]136255[/snapback][/align]ssh x11 forwarding -al van winre is X
-
SzerzőBejegyzés
legutóbbi hsz