Re: basic [OFF]
Éppen ezeket kellene kerülni. Persze nem a Linux kernelben, mert azt kifejezetten gcc-re írják. Nyilván van rá ok - ezt nem tudom. Persze, hogy van rá ok. A szabvány nem dogma rendszer, hanem olyan szabályok összesége, ami (elméletben) biztosítja a hordozhatóságot, és a nyelv működését. Pont ezért nem tilthatnak, vagy szabályozhatnak mindent, mert az akár nyelv használhatóságát is veszélyeztetné egyes platformokon, vagy akár összeségében is. Például a szabványokban legtöbbször egyes algoritmusokra (mint rendezés, keresés), csak az van megszabva, hogy milyen gyors legyen, és nem maga a megvalósítás. Ezzel lehetőséget adnak a fordítók íróinak, hogy platformtól, esetleg helyzettől függően más és más megvalósítást használjanak, ami a program hordozhatóságát, sebeségét igen csak javítja, de akár ugyan ennyi gonddal is járhat. Na meg a szabványban is vannak kiskapuk, és még ahol nincsenek, ott is lehet máshogy értelmezni a leírtatkat. Nem nagyok a fordítók közötti különbségek, és ha ismerünk egy ilyen problémát, akkor nem tart a legtöbbször öt percnél tovább átírni a kódot. Elég ritka, hogy keresztplatformos fejlesztésen kívül máshol is megjelenének konkrét problémaként ezek kivételek, bár a legtöbb fordító (lásd gcc) pontos listát vezet róluk. Attól, hogy valahol találunk egy új lehetőséget, még nem kell okvetlenül használni. Csak komoly indokkal. Minden új lehetőség visszafelé inkompatibilitást okoz. Nem csak új nyelvi elemekre vannak ilyen kivételek. Például Cpp-ben a sablonok feldolgozására több model is létezik, és nem ma került a sablon a nyelvbe. Khraath _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: basic [OFF]
Szia A TP 6.0 (~1997) mar tudott OOP-t. Lehet, hogy nem tanitottak, vagy tanultak, de mar tudta. En is C/C++ -t hasznalok (most), de azert igaz, ami igaz. Hogy a GNU Pascal tudja-e, az passz. Dolgoztam Delphis cégnél, és akkor Object Pascalt is megnéztem. Én voltam a hülye, mert nem írtam, hogy az OOP alatt én a Simulás viselkedés alapú OOP-t értem(lásd C++), márpedig az Object Pascal nem ezt a szemléletet követi. Tényleg csak egy réteg a strukturált rész felett. A viselkedés alapú szemlétet lényege pont az, hogy egy objektumot NEM az adattagok, hanem a viselkedése(függvényei) határoznak meg. Ezért lehet a C++-ban elrejteni az adatagokat még a gyermek osztályok elől is (igaz, nem teljesen),ami egy bázis osztálynál nagyon jól jöhet, és persze ezért lehet függvényobjektumokat létrehozni. Khraath _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: basic
Mert? Pascalban is van pointer, ha jól emlékszem, szóval olyan rekordokat kell tárolni a veremben, aminek egyik mezője tárolja a típust, a másik az értékre mutató pointert. Persze Java-ban sokkal egyszerűbb lenne megcsinálni, mert van reflection - viszont nem a reflection-nel kell elkezdeni a programozás tanítását. Igen. Akár C-ben, de hol az adat biztonság fordítási időben? Persze futás időben lehet hiba üzenetet írni, ha mégis valami gond van, de attól gond nem múlik el. Ha egy repülőtéri irányító rendszerhez kellene írnom egy hasonló szerkezetet, akkor biztosan nem választanám ezt a módszert, hanem valami olyan megoldást keresnék, ami nem lenne egyenes út a Repülő katasztrófák sorozatba. Itt nem a példa megoldása volt a lényeg, hanem, hogy még az általánosan használható nyelvek, mint a Pascal, sem mindenhatóak. Ne is beszéljünk az olyan nyelvekről, mint a Prolog. Mert? Pascalban is lehet rávezető feladatot adni, struktúrális nyelven is lehet objektum-orientáltan programozni, a f(object, data); és a object-f(data); Nagyon sok a különbség a kettő között. Lehet, hogy nem látod, de sok van. Az, hogy írás módban nagyon hasonlít, és a végeredmény azonos lesz, nem jelenti, hogy a működés is megegyezik. Itt van rá egy példa: f(object, data) Eddig jó, de ha mondjuk több Object típus is létezik (pl GUI-ban több féle widget is van), akkor vagy megírsz egy külön függvényt mindegyikhez, vagy mutatót adsz át. Na már most, a kód használóját mi akadályozza meg, hogy Objectként adjon át egy nem Objectet? Semmi. A fordító se fog szólni. Persze f-ben ellenőrízheted a dolgot, de szinte biztos, hogy egy hiba üzenet lesz és kész. De még f hívása előtt se mész semmire azzal, hogy tudod, hogy nem Object. Megoldani nem tudod, csak jelezni a problémát. Másik oldal: mi garantálja, hogy f nem vágja tönkre objectet? Honnan tudom, hogy csak a data mezőhöz nyúlt? Cpp-ben például ez(f(data)) egy virtuális függvény lesz, ami egyrészt biztosítja, hogy bármely Object leszármazott saját megvalósítást adjon f-nek, és persze garantált, hogy object egy Object (vagy leszármazottja). Ha véletlenül (vagy hanyagságból) benézed mégis a dolgot, akkor a fordító biztos leáll hibával. Mivel az object saját f-jét hívtad, így nagyon valószínű, hogy nem rontja el magát. Tanúság: jól megirt osztály szerkezet nem csak a végfelhasználótól, hanem még a karbantartótól, és más kód felhasználóktól is véd (azaz magadtól ;)). Khraath _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: basic [OFF]
Mire gondolsz? A C nyelv 1974-ben jelent meg fordító és a Unix forrásprogram formájában. 1976-ban pedig az első C könyv (Kernighan-Ritchie), amit kvázi szabványnak lehet tekinteni. 1989 végén az ANSI szabvány, . Változó láthatóságban nem volt különbség, legfejlebb a függvénydeklarációk bővültek ki felfelé (majdnem) kompatibilisen, és a változó deklarációk egy kicsit (pl. const). Azért voltak ott más változások is, és sajnos a szabvány csak egy dolog. Például a // nem volt benne a szabványban (talán most sincs), és mégis szinte minden fordító ismeri. A hangsúly a szintén van. Persze ott a -, és a . operátorok kérdése. Ezek jelentése is változik fordítónként. Aki fejlesztett kereszt-platformra, és több fordítót is kellett használni, biztos találkozott ilyen hibával. Számunkra nem jelentős egyik sem, de képzeld magad egy első programot író középiskolás helyébe, aki nem tudja, hogy miért nem működik a könyvbeli példa. Gondolj bele, hány órát ültünk az első időben egy hiba felett, mert nem tudtuk, hogy a fordító éppen miért sír. A C fordítók sokszor félrevezető hiba üzenetet adnak, és sok tapasztalat kell, hogy tudjuk, mikor miért jelenik meg egy hiba üzenet. Ezen a levelező listán is minden 5-6 szállból egy valami fordítási hibával foglalkozik. Szinte minden forrásból telepítésnél vannak figyelmezezések (a kernelben is). Sokkal jobb egy olyan nyelven kezdeni, ahol nincsenek ilyen kezdő buktató problémák. Első időben amúgy sem a gyors, megbízható program az elsődleges cél, hanem a működkő program. Első programomnál nem nagyon foglalkoztatott, hogy 0.1 másodpercet javíthatnék rajta, ha más rendezést használok, vagy nem szabadítottam fel magam után megfelelően az erőforrásokat (nem tudtam róla :)). Most meg 3 napig nézegetek egy láncolt listát, hogy hogyan lehetne még gyorsabb a létrehozás, meg a szürés, és miként tudnék még néhány kilobyte memóriát spórolni a new hívásokból, hogy biztosan elég legyen a memória az összes elemnek. Vagy milyen új memória kezelőt készítsek, hogy ha elfogy mégis tudjak valamit felszabadítani. Khraath _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: basic [OFF]
Ez szerintem csak elony. Lehet hogy a nyelv kesobb konvertal ide/oda, de indulaskor legyen tisztaba a kulonbozo formatumok elonyeivel es hatranyaival. Kulonosen azzal, hogy valassza ki a feladathoz illot. Előny, ha olyan nyelvre lépsz tovább, ahol ez fontos, mint a C, vagy Java, de mi van azokkal, akik PHP-val folytatják? Nekik fontos tudni, hogy a C-ben csak a blokk elején deklarálhatsz változót? Vagy, egy C-snek, hogy a Javaban hogyan vezetünk be egy új függvényt, és hogyan kell megadni a kivételeket? Vagy melyik stream átalakítás után mi lesz az eredmény? Vagy egy Java programozó tudja, hogy az enum-ok hogy kerülnek a memóriába Cpp-ben? Vagy, hogy a bitset hogyan működik, és hogyan lesz tárolva? Természetes, hogy egy függvénynek a használat előtt legalább deklarálva kell lennie, vagy a változók sem a semmiből tűnek elő, de a többit elég később megtanulni az adott nyelvnél. Teljesen igazad van, ha egy adott nyelvet, és annak oktatását nézzük, de álltalánoságban nem várhatod el még azt sem, hogy az ősnyelvek viselkedését ismerjék a programozók, vagy a piacon éppen felfutott nyelvek minden apró szeszélyével tisztába legyenek. Szerintem a tanár dolga, hogy az adott nyelv ilyen sajátoságait elmondja, vagy általánosan beszéljen arról, hogy az általában minden nyelvben megtalálható típusok (char, int, float) közül egy adott problémánál mit érdemes használni. Fejlődni meg gyakorlással, forrás olvasással, és a referencia bújással lehet. Referenciában ott a szabály, a forrásokban pedig különböző megoldások, a gyakorlat meg eldönti, hogy éppen mi a jó. Khraath _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: basic [OFF]
Mire gondolsz? Nem találkoztam ilyennel. Minden C könyvben benne van, hogy x - yugyanaz, mint (*x).y Ha jól emlékszem (régen volt, még nem mingw-t használtam és volt Windows a gépemen) a Visual Studio 6 alatt volt gondom. Szerinte nem, és át kellett írnom az összes x-y-t (*x).y -ra. Sajnos a hiba üzenetre nem emlékszem. Amúgy is mindegy, mert a könyveket a fordítók készítői nem olvassák, csak mi, és sajnos a könyvek írói sokszor a fordítókat nem használják, amiket mi... Csak azért ezt írtam, mert mély nyomot hagyott bennem, hogy éjjel kettőkor reboot után az elvileg kész programmal még volt egy jó félórás köröm. De, ha jobban megnézed, akkor most is van, hogy nem csak platform, hanem fordítóhoz kapcsolódó függőségek/makrók vannak a programok kódjában. Vagy info gcc-ben szét nézzel. Sok helyen előfordúl (főleg Cpp-s részekben), hogy a Borland modelt követjük, vagy éppen ATT-t. Már pedig valami különbségnek kell lennie, ha különböző modelek létetznek a szabványra. Khraath _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: basic [OFF]
Igen :) Most magyaraztam valakinek, hogy miert kerul egy sql tabla varchar mezojebe 0, amikor a bemeno ertek _51... Nem ertette, hogy a php-ban egy kifejezesben a string atalakul integer-e, majd vissza. Nem tudom min not fel, de foleg a php miatt nem volt tisztaban a tipusok jelentosegevel. Sajnos ez igaz, de akár Pascal alatt is nevelkedhetett, mert ezt már a php dokumentációban kellett volna megnéznie, és nem tette, ami ugye valamit elárúl :D. A masik ilyen klasszikus hiba, amire pl a C forditok haklisak, ha inicializalatlan valtozokat hasznal. Ez ez is hordozhatosag, mert senki nem garantalja, hogy az uj valtozo csupa 0 bitekbol fog allni. Hát ez nagyon igaz. Én is -Wall -pedantic -kal fordítok, amíg fejlesztek. Jogosan is szól, már volt nekem is ilyen hibám figyelmetlenség miatt. Oktattal mar? En foleg egyetemistakat es felnoteket tanitottam/tanitok. De nagyon massziv idokorlatok vannak. Ha jol kitalalt feladatot kap, akkor gyakorolni fog oran kivul is. De nagyon nehez am jol kitalalt tanpeldat csinalni: ne legyen tul mesterkelt, hajanal fogva elocibalt, de ne is legyen tul bonyolult... Megnyugtatok mindenkit, hogy csoportokat még nem vezettem téves ösvényekre. De tanított már egy-tíz tanár, és kevesebben voltak a jók, mint a rosszak. Gondolom ezért se akartam soha órát tartani. Túl nagy a felelőség, és nem hiszem, hogy jól tudnék oktatni. Abban viszont igazad van, hogy kevés az idő. Egy gyakorlatnak 2-4 órásnak kellene lennie, mint más szakokon a laboroknak, de nekünk csak 50 perc jutott (minusz katalógus). Ez nagyon sok idot igenyel a tanartol is, es sajnos neki is egyre kevesebb van. 80-100 diakbol 2-nek annyira kell a tanar, hogy felevente fel orat beszelgessenek, es ekkor a tanar tereli, kesz. Ok ugyis tudnak programozni. A tarsasag 60%-a az eletben nem fog tudni programozni (bar esetleg programozo lesz...), de legalabb erzi, hogy milyen nehezseges vannak, es mesterember szinten megoldja/elkeruli/el tudja mondani masoknak, hogy mi a baj. Sajnos több, mint 60%. Mível rövid a gyakorlat, és a zh sok helyen gépnél van, vagy definiciókat, meg hasonlókat kell vissza böfögni (aminek persze lenne értelme, ha lenne gyakorlati kérdés is). Öszintén bevalom, hogy én is írtam másnak kötelező programot, és nem titok, hogy egyes kollégisták gyakorlatilag kötelező program írásával szerzik a sörre valót, így minden diákokon múlik, ha nem akar tanulni, akkor nem is kell, mert egy jó puskával, és egy kis anyagi befektetésel meg lehet a féléve (és van pofájuk jobb jegyet szerezni, mint aki készült rendesen :@). Khraath _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: basic
Ha mindenféle típust lehet betenni a verembe, akkor minden nyelven le kell kezelned ezt a hibát. Nem voltam elég pontos. A mutató átalakításból adódó hibát megspórolhatod, és ezt a hibát mindig programozó követi el, és nem a fordítója, vagy a felhasználója. Például Cpp-ban, ha kicsit ügyes vagy, akkor megoldható, programozói hanyagságból (rossz dokumentálás, vagy annak figyelmetlen olvasása) ne tuszkolj be valami olyan dolgot, ami nem oda való. Pontosabban megpróbálhatod, de valószínűleg egy hiba üzenet lesz a jutalmad. Javaban ehhez hasonlót még nem csináltam, de gondolom ott is van valami jelzés. Pedig az általános nyelv pont attól általános, hogy mindenfélét lehet benne írni :-) Persze nem célszerű mondjuk Fortranban írni adatbázist, de lehet. Pont erre gondoltam én is :P. Megírok különböző függvényeket és mutatókat adok át. Nézd meg pl. a GTK-t, grafikus objektum orientált library C-ben. Nem szép, de működik. Köszönöm, nézem folyamatosan, bár ha tehetem inkább a gtkmm-et nézem ;). Ráadásul nem csak működik, hanem nagyon jól is működik. Mióta használom nincs GUI problémám, ha Windowson is működnie kell a programnak. Az API rondának ronda, de vannak rondábak is. Miért Object-et kellene elfogadni? Az említett GTK-ban pl. GtkWidget* típust lehet átadni, vagy GtkButton* típust, vagy amit akarsz. Hát igen... Amit akarsz... Múltkor is csináltam egy ilyen bakit, és nem nagyon értettem, hogy miért nem működik úgy, ahogy én szeretném :P. Nem figyeltem oda, és a nagyon_hosszu_sok_parameteres_fuggvenynek egy phulye_nevu_valtozo_mert_meg_ez_nem_volt adtam át, és egy másik hasonlót kellett volna :D. Nagyon jó a Gtk-s megoldás, csak éppen igen nagy a kódja, és annyit nem akartam írni, és a problémát csak részben oldja meg. C-ben is el lehet rejteni az struktúra mezőit. Teljesen igaz, de ha Gtk megoldást összehasonlítod a gtkmm-es wrapper megoldással, akkor látni fogod, hogy a kettő közül a gtkmm a jobb ebből a szempontból :D (főleg a dialógusoknál, mint a FileChooser). Abban viszont teljesen igazad, hogy lehet jó objektum orientált könyvtárat írni egy struktúrált nyelvben is, de ha nem muszáj, akkor nem próbálkoznék vele. Iszonyatos lusta vagyok, és nem bonyolítom az életem, ha nem muszáj. Ahol sebeség kell, oda írok egy C függvényt, ahova egy jó adatbázis, oda egy Cpp-s osztály szerkezetet. Szerencsémre ezt a két nyelvet jól lehet kombinálni (extern, szállkezeléssel, processzekkel). Khraath _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: basic
Szia! a logo-t nem ismrem tulzottan, meg alapozashoz talan a basic a legjobb. Régen tényleg így volt, de ma már inkább a Pythont ajánlanám a tényleges alapozáshoz. Nagyon egyszerű rajta tanulni, és az objektum orientált programozást is lehet vele oktatni. Persze, ez igaz a PHP-ra, vagy Delphire is, de szerintem (és ez tényleg személyes vélemény) ezeken a nyelveken nem lehet a megfelelő viselkedés alapú gondolkodást elsajátítani(pl. PHP3), ami a későbbi C++-hoz szükséges (már ha ebbe az irányba haladnátok tovább). Plusz a Pythont oktatásra találták ki :P. Ja, grafikus megoldás lehet a PyGtk, ami persze (mint minden Gtk változat/wrapper) keresztplatformos. Ha nagyon kicsikről van szó, akkor én is a logot ajánlom. Linuxon elég sok megvalósítás van. pl. a KTrutle (KDE base-ben van elvileg, ovisoknak), vagy a lhogho - http://lhogho.sourceforge.net/, végül a usblogo - http://www.cs.berkeley.edu/~bh/logo.html Khraath -- khraath [EMAIL PROTECTED] _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: basic
Szia! Hmm. Az ovisok nemhogy angolul nem tudnak, de olvasni se. A python meg jó oktatásra, de NAGYOBBAK oktatására. Nem volt korcsoport kikötve. Bár a basic miatt általános iskolára tippelnék. Valóban nem tudnak az ovisok olvasni. De angolul biztosan nem kell megtanulni senkinek. A python.hu-n olyan jó leírások, és referenciák vannak magyarul, hogy erre semmi szükség. Bár cpp-ből lennének ilyen jó anyagok! Amúgy meg, aki tud gépelni, az pont annyira olvasni is tud. Ez az egy biztos, mert Spectrummal kezdtem (pontosabban a bátyám), és én is tudtam használni. Sőt! Azon írtam meg az első programomat... A KTrutle inkább játék, mint igazi nyelv. Nem hiszem, hogy a krumplifej bácsi és a pingvin öltöztető mellé egy bonyolult magas absztrakciókra képes nyelv került... Bár lehet, hogy tévedek, sose használtam. A legjobb az lenne, ha a közép iskolák átálnának Pascalról Pythonra, vagy Javara, mert valljuk be a Pascal felett eljárt az idő... Magasabb absztrakciókra alkalmatlan sajnos. Középiskolában én is szerettem, de azóta sokat tanultam, főleg azt, hogy nagyon sok rossz szokást a Pascal miatt vettem fel, amiről nehezen szoktam csak le... Ezért se szoktam kezdésnek a Javat, vagy Pascalt ajánlani, mert a kezdők egyből felveszik a rossz szokásokat, mint az interfacek halmozása, öröklés használata ott is, ahol beágyazást is használhatna, na és persze a kedvencem: Repül a kivétel: ki tudja hol áll meg? Ki tudja hol áll meg s kit hogyan talál meg? El is szokás kapni, amit eldobtunk. Ez az első, amit mindenki elfelejt, pedig nem véletlenül kell megadni a kivételeket a deklarációban... -- khraath [EMAIL PROTECTED] _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: basic
Ez ugye vicc? Amit pascalban nem lehet megírni, azt egyátalán nem lehet megírni... Légy szives, ha lehetne, definiálj egy absztrakt tárolót. Mondjuk egy sima vermet, amiben bármilyen számtípust tárolhatsz. Futtás időben legyen a feltöltés valós, egész, és mondjul komplex számokkal véletlenszerűen. Persze feltétel a helyes visszaolvasás (helyes típusba). Valószínüleg ki lehetne préselni a megoldást, de egy jó darabig eltartana, és az adatbiztonsággal is gondok lennének, ami ebben az esettben a legfontosabb. Nem vagyok Pascal ellenes. De objektum orientáltság vagy generál programozás oktatására alkalmatlan. Mível a vezető nyelvek objektum orientáltak, magas színtű elvonatkoztatásra képesek, így elég nehéz Pascal után hirtelen váltani. Egyre inkább kimarad a C, mint ugró deszka, és ez sokszor meg is látszik (a fennti példa C-ben egy jó félóra alatt megoldható). Nekem nem gond, de amíg sokan kardoskodnak a Pascal mellett, főleg olyanok, akik nem programozó, hanem más, mérnőki szakra járnak/jártak (nekik tényleg nagyon hasznos a Pascal), addig sokkal nehezebb lesz a váltás. Nem túl kellemes első évesen Pascal után Objektum orientáltságot, generál programozást tanulni. Főleg, mint tudjuk a mai egyetemi oktatás: tanulj otthon, 45 perc gyakorlat, 5 perc késés (tanár), 10 perc katológus, többi meg Windows start. A legyen Pascal, ne legyen Pascal vita egyetlen vesztese az, aki elvileg a legérintettebb: a programozó, és így később a felhasználói. A C nyelv nem kezdőnek való, a gyerek sem vadász késsel tanul meg enni. A Delphit pedig meg kell fizetni ugye. Mert komponensek nélkül valahogy nem az igazi... Amúgy is a Pascalos Hanoi tornyai hagyományt követve elég sok hiba van a függvénykönyvtárban... :D oriasi hibat kovetnek el azzal, hogy matekoznak az info oran Nem olyan nagy hiba a matekozás. Az a baj, hogy matematikailag vezetnek le mindent. Az algoritmusok nagyon fontosak, és ezekhez kell a matematika. Minden program szívében ott van egy adatbázis, néhány számítás, és valójában ez határoza meg egy program minőségét, és nem a 3D-s csilogó külső. Jó példák erre a játékok. Ha jól van megírva a motor, akkor a minimum követelményen is szépen fut (Imperium Galactica, Haegemonia, stb.), ha meg szar, akkor szagat, sír még az optimum alatt is. Elég sokat optimalizálok, de még soha nem kezdtem a fájl menüben :D. Az lenne a jó, ha nem a sin függvényt kellene elkészíteni, hanem egy tetszőleges rekurziv trigonometrikus függvényt megoldása lenne a feladat. Tárolók készítéséhez, és adatok feldolgozásához, szűréséhez elengedhetetlen az alapvető adatszerkezetek, és algoritmusok ismerete. Khraath _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: basic
tart az emberke fejeben. Egy java vagy c++ class-ban mar elveszik a sok
hatterinfo mellet a lenyeg.
Javaban igazad van, de C++-ban nem, csak éppen az MSDN-hez vagytok szokva.
Jól megirt osztályok mellett pont a lényegre lehet koncentrálni. Csak
arra kell figyelni, hogy mire készül az osztály (konténer, bázis, konkrét,
stb.), és a minimális osztály felületre.
pl:
void Database::refresh_tables()
{
std::for_each(tables_.begin(),tables_.end(),std::mem_fun(Table::refresh));
}
Ennél elvonatkoztatottaban, tömörebben nehéz fogalmazni, és szerintem a lényeg
elég jól látszik.
Ugyanez C-ben (Gtk-hoz hasonló módszer):
int refresh_database_tables(Database* db)
{
int ret = 0;
for(int i = 0; i get_tables_size(db); ++i) {
if ((ret=refresh_table(get_databse_table(db,i)))!=0)
return ret;
}
return ret;
}
Természetesen mindent meg lehet objektum orientált programok, vagy nyelvek
nélkül oldani, még mindig az asm a legjobb nyelv. A jól megirt OO program segít
a fejlesztőnek munka közben. A gond csak az, hogy C++-ban is sokszor látom,
hogy ugyanúgy egy függvényben van minden összezsúfolva, mint
régen a rosszul megirt C programokban. 200 soros függvények mellett
nem csoda, hogy nem lehet átlátni az egészet.
Módszer igen egyszerű: az alacsony színtű műveleteket próbáljuk meg kezelő-
osztályokban elrejteni, és később ezeket használni, és a megfelelő függvény-
objektumokat.
Sokat használok C-t, de ha egy programomban adatbázisra van szükségem, akkor
biztosan C++-ban kezdek neki. Persze soha nem fogok C++-ban drivert írni,
vagy stream titkosítót, de az nagyon is valószínű, hogy a titkosítóhoz
készítek valami wrappert, és használni fogom a C++-os adatbázisomban
titkosításra.
Pascal tényleg jó első nyelvnek, csak utána nem Javara, vagy C++-ra kellene
ugrani, hanem egy kis C-t, Pythont esetleg PHP tanulni, és úgy váltani.
Megfeletkeztél a görgetősávról! Az nagyon fontos! Már első órán le kell
diktálni a gyerekek vonalas füzetébe! ;) De utáltam ezeket a marhaságokat.
Néha nagyon hiányzik a magnó dörmögése, na meg a kék képernyő, amit még
akkor senki se utált.
Első Linuxomat is azért raktam fel (gcc-s kötelező programok mellett), hogy
egy kis sebeséget leheljek a gépembe és elüzzem a kék halát. Két tányér
levest benyomtam, mire volt egy startmenüm, most meg egy pohár teát sincs
időm behozni (ugyanaz a gép még mindig, csak 5 év telt el :D).
Khraath
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: xdm nem jelentkeztet be
On Fri, 23 Mar 2007 07:12:27 +0100
Kispál Zsolt [EMAIL PROTECTED] wrote:
Sziasztok!
Nemrég telepítettem magamnak egy Gentoo-t (2006.1) és az a probléma,
hogy grafikus bejelentkezésnél
az xdm bekéri a felhasználónevet és a jelszót de nem jelentkeztet be.
Egy pillanatra elsötétül a képernyő
majd újra feldobja a jelszókérő panelt üresen.
Ha lelövöm az X szervert és bejelentkezek parancssorba, majd onnan
startx akkor semmi gond, indul a
windowmanager.
Biztos, hogy nem a jelszóval van probléma mert a parancssorba elsőre be
tudok lépni :-)).
Gentoo fórumon találtam is hasonló problémával küzdő embert, de az ott
javasolt beállítások nekem mind
megvannak a probléma mégis jelentkezik.
http://forums.gentoo.org/viewtopic-t-456222-highlight-xdm.html
K7S8X ~ # equery l -i sessreg
[ Searching for package 'sessreg' in all categories among: ]
* installed packages
[I--] [ ] x11-apps/sessreg-1.0.0 (0)
K7S8X ~ # cat /usr/lib/X11/xdm/Xsetup_0
#!/bin/sh
# $Xorg: Xsetup_0,v 1.3 2000/08/17 19:54:17 cpqbld Exp $
#xconsole -geometry 480x130-0-0 -daemon -notify -verbose -fn fixed
-exitOnFail
K7S8X ~ # cat /etc/X11/xdm/Xservers
# $Xorg: Xserv.ws.cpp,v 1.3 2000/08/17 19:54:17 cpqbld Exp $
#
# Xservers file, workstation prototype
#
# This file should contain an entry to start the server on the
# local display; if you have more than one display (not screen),
# you can add entries to the list (one per line). If you also
# have some X terminals connected which do not support XDMCP,
# you can add them here as well. Each X terminal line should
# look like:
# XTerminalName:0 foreign
#
:0 local /usr/bin/X vt7
K7S8X ~ # cat /etc/conf.d/xdm
# Tell X to always start on VT7. Otherwise it autodetects the first
available
# VT, which means it has to wait until all gettys are started so it
doesn't suck
# up a VT that should have had a login prompt (very slow).
# If XSTATICVT is on, the login manager will start as soon as possible
during
# the boot process. If you want X to dynamically start on the first
unoccupied
# VT after all gettys have started and you are using xdm, also remove
the vt7
# from /etc/X11/xdm/Xservers.
XSTATICVT=yes
# What display manager do you use ? [ xdm | gdm | kdm | entrance ]
# NOTE: If this is set in /etc/rc.conf, that setting will override this one.
DISPLAYMANAGER=xdm
Ráadásul a logokban se látok olyan hibaüzenetet amire tudnék keresgélni
a neten.
K7S8X ~ # cat /var/log/xdm.log
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/K7S8X:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
X Window System Version 7.1.1
Release Date: 12 May 2006
X Protocol Version 11, Revision 0, Release 7.1.1
Build Operating System: UNKNOWN
Current Operating System: Linux K7S8X 2.6.19-gentoo-r5 #1 SMP Fri Mar 16
11:55:02 CET 2007 i686
Build Date: 15 March 2007
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: /var/log/Xorg.0.log, Time: Fri Mar 23 07:25:50 2007
(==) Using config file: /etc/X11/xorg.conf
xkb_keycodes { include xfree86+aliases(qwerty) };
xkb_types { include complete };
xkb_compatibility { include complete+ledscroll(group_lock) };
xkb_symbols { include pc(pc104)+us+group(toggle) };
xkb_geometry { include pc(pc104) };
FreeFontPath: FPE /usr/share/fonts/misc refcount is 2, should be 1;
fixing.
xkb_keycodes { include xfree86+aliases(qwerty) };
xkb_types { include complete };
xkb_compatibility { include complete+ledscroll(group_lock) };
xkb_symbols { include pc(pc104)+us+group(toggle) };
xkb_geometry { include pc(pc104) };
K7S8X ~ #
Minden ötlet jól jönne.
Köszönettel
Kispál Zsolt
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
Lehet, hogy meg se próbál bejelentkezni :D?
Van a $HOME-ban .xsession? Mert az xdm nem .xinit-et használ.
Amúgy, ha az Xsetup_0 -ban az xconsole elől kiveszed a commentet, akkor
biztosan lesz egy terminálod:
#!/bin/sh
# $Xorg: Xsetup_0,v 1.3 2000/08/17 19:54:17 cpqbld Exp $
xconsole -geometry 480x130-0-0 -daemon -notify -verbose -fn fixed
-exitOnFail
[EMAIL PROTECTED]
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
