Új hozzászólás Aktív témák
-
válasz 7600 GS #1194 üzenetére
codeblocks, az valami compiler?
kb a következőt kéne csinálnod:
először bekéred a két számot (mondjuk int jó lesz, esetleg rárakhatsz egy ifet ellenőrizni a számokat). aztán megállapítod, melyik a nagyobb.
ha ez megvan, ciklusosan 1től a kisebb számig menj végig az összes számon. ha osztója az egyiknek (másképp: egyik mod iterátor == 0) és a másiknak is, akkor kiiratod, egyébként meg nem. ha eléred a kisebb számot, ott már több osztó nem lesz.
ez a naív implementáció, csúnya, de működik.
második implementáció: bekéred a két számot, megállapítod hogy szabványosak e (if (input >=10 && input < 100)), megtalálod melyik a kisebbik és nagyobbik, aztán nyomsz rájuk egy euklideszi algoritmust. ha nehezen érthető nézd a példát, vagy az angol oldalat.
miután euklides lefut, meglesz a legnagyobb közös osztó. azt lehet prímfelbontani amiből meg előállíthatók az osztók. ez lehet hogy gyorsabb lenne (tippre alacsonyabb lesz a lépésszám, de nem vagyok teljesen biztos), viszont a kód sokkal bonyolultabb lesz (pl 40 és 80ból lesz egy GCD 40, ami 2^3 * 5, amiből osztók 2, 4, 8, 5, 10,20,40).ha ez egy beadandó: sürgősen kezd el tanulmányozni a könyvet/jegyzetet, ez egy eléggé egyszerű procedurális feladat (értsd, amennyi idő alatt összeraktam a bejegyzést, ment volna a kód is), vizsgán pedig nem hinném, hogy egyszerűbbet fogsz kapni. ha tényleg nincs ötleted, akkor jobb megoldás nem nagyon van. ajánlott pl a madaras stroustrup könyv (programming practice and principle in c++), az remek, de az elején a bevezetőt ugord át és kezd a hello worldos fejezetnél. aztán ülj le, és csináld a feladatokat. magyar könyvek közül én a programozzunk c++ nyelvennel találkoztam (csapongó, száraz és előbb vezeti be a dynamic castet, mint a classokat), illetve az OO c++al, de az meg inkább classokra fókuszál, itt meg inkább procedurális tudás kéne.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz WonderCSabo #1201 üzenetére
hát, első beadandó szerintem lehet. vagy egy egyszerűbb vizsgafeladat, bár szerintem jobb akkor már külön tesztelni, hogy a diák ismeri-e a cin, for, if utasításokat.
nyelv vs programozás: szerintem nagyon is közel állnak egymáshoz. még tétel is van rá, hogy az emberi nyelvek Turing nehezek. Turing pedig nyelvész volt. svédnél konkrétan ki is használtam ezt a fajta gondolkodást: időm nyelvi automatizmusokra nem volt, ellenben logikából és memóriából alapfokig eljutottam, kb procedurális módon (ha kérdőmondat, első output megfelelő állítmány). formális nyelveket nem véletlenül hívják így. felépítésben is van hasonlóság, mind program-, mind élő nyelveknél megfigyelhető, hogy minél feljebb haladunk, annál kevésbé lesz hangsúlyos a szintaxis és annál inkább a struktúra/stílus. ahogy egy fogalmazásnál sem már a nyelvtanon van a lényeg (mennie kell, ugyanakkor összefüggőnek is kell lennie), ugynígy design patterneknél sem az a kérdés, hogy lefordul e, hanem hogy tényleg megoldást kínál e az adott magasabb szintű problémára. élő nyelveknél ugyan nagyobb a hibatűrés, viszont másik részről sokkal de sokkal nagyobb a variancia is.
Don't dream it, be it. // Lagom amount.
-
válasz WonderCSabo #1213 üzenetére
20-30 részfeladatos vizsgán simán lehet egy ilyen az egyszerűbb példák között, ha a tanár a tantárgyi követelményekre reflektáló (pl egyszerű procedurális kódot tud írni részre) vizsgát akar. ettől függetlenül nálunk is kb az első héten volt ez az anyag.
viszont mindkettőt csak használva lehet megtanulni, mindkettőhöz nagyon masszív betanult háttértudás kell ha az ember jól akarja csinálni, mindkettőhöz (logikusan) gondolkodni kell, mindkettőhöz szükséges pattern matching/szituációfüggő használat, és mindkettőhöz eszméletlen kitartás kell, mert több (tíz)ezer óra jól csinálni. mindkettőt aktívan kell használni (felejtés), mindkettő folyamatosan változik, és nagyon hasonló a betanulási görbe. minél több nyelvet beszél az ember, annál könnyebb a következő. és azáltal, hogy az emberi mondatok átkonvertálhatóak logikai kijelentésekké (és fordítva), és a logikai kijelentések megfeleltethetőek kódnak (és fordítva), megvan az átjárás.
svédet gyakorlatilag egy sor programozásban működő ötletet felhasználva tanultam meg. működött, mind. beállítottság érdekes dolog, én szeretem mindkettőt.dabadab igaz, Turing tényleg matematikus volt csak. másik dologgal kapcsolatban valszeg igazad van, összemosódik a terminológia.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
-
válasz Brianiac #1227 üzenetére
elvileg cin.get int bekérésre jó
.
írsz egy forciklust 1től nig. előtte kell egy int buff varians, ami ev[0] erteket kell megkapja meg a ciklus elott. aztan az ev erteket kell hasonlitani a buffall: ha buff a kisebb vagy egyelo, buffot megtartani, egyebkent ev(i) vel uppdatelni a buffot. amint lement a ciklus, buff erteke egyelo a legkisebb evvel ami az ev[]ben van, innentol a legidosebbet letarolja. ha nem csak az evszam kell, akkor az iteratort is le lehet a buffba tarolni, es az alapjan lekerdezni a cuccokat. egyébként mivel egy harom elemu elegge rondan definialt structrol van szo, szerintem hardcode megoldas is megoldható (mire kapsz pontot megnezni azert!).* szerintem csaladtag objectekkel kéne ezt csinálni, aztán akkor nem fordulhat elő, hogy a név meg az évszám elcsúszik egymáshoz képest. szerk: látom más már írta közben, hogy lenne normálisabb.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
-
válasz asuspc96 #1253 üzenetére
két tipp:
egyik: ha tényleg nagy számok kellenek, akkor lehet definiálni saját számábrázolási módszert, pl több long long összefűzésével. az elv hasonló, mint amikor az ember összeköt két 4bites összeadót carry bittel... csak kicsit bonyolultabb, de kb ez a lényeg. memóriaigény elszállhat.
másik: a naiv, végigpróbálom gyökXig és ha nem osztja semmi, akkor megyek következőre megoldás minden Xre gyökXet lép, tehát X*gyökX a futásideje. másképp exponenciális. gyorsabb prímtesztelési módszer van, pl a Katona/Recski/Szabó féle Számítástudomány alapjai ír gyorsabbat. bme info/elte mat ismerősnek biztos meglesz a könyv. eléggé elméletre fókuszál, de a lényeg benne van: polinomidőben prímtesztelés megy, ugyanakkor felbontást az ember nem kap.
namost, a másik probléma, hogy C++ban a szálkezelés fél éve jött be, itt meg lehet lehetne vele nyerni (prímkeresni több szálon nem próbáltam még, szóval nem biztos). ha csak egy szálon megy, akkor marad a kb 14%os max terhelés a procidon.
Don't dream it, be it. // Lagom amount.
-
igen, arra.
asuspc96: wikipedia cikkeket érdemes elolvasni, a foglalkozó magyar oldalak jórésze elte/bme jegyzetekkel elég nagy hasonlóságot mutat (említett könyvet mindkét intézményben használják). a gyakorlatban pedig néha a wikis oldalak néha lényegesen érthetőbbek, mint maguk a jegyzetek.
angol wikis oldalakat szintén érdemes átnézni, általában relevánsak és használhatóak, implementációt is találni.
nevezett könyv egyébként eléggé száraz és inkább elméletre megy rá, cserébe meg lehet belőle érteni és eléggé tömören fogalmaz.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz Jhonny06 #1266 üzenetére
elvileg fel kéne ajánlania a compilernek, hogy ha lát változást, akkor újra kell építenie.
ez az elmélet. a gyakorlat az, hogy unix környezetben (minix 3.1) már láttam olyat, hogy órákat szívtunk, mire észrevettük, hogy a C compiler nem lát egy változtatást és ezért még mindig a két órával előtti kernellel szívunk.
rebuild kell, ha azt nem csinálod, akkor nem fog fordítani. esetleg ha nagyon nem megy, akkor lehet rá nyomni egy clear+rebuildet, de azzal projekt méretének függvényében nagyon óvatosnak kell lenni.
én debug módban szoktam (jelenlegi beadásnál csináltam automatizált tesztet assert is, azt meg release módban elvileg nem is futtatja), rebuildelni meg akkor, ha outdatednek írja. ill néha clear+rebuild, ha valami nagyon nem stimmel.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz WonderCSabo #1268 üzenetére
hm, CPTből futtatás megoldható/nem túl macera?
Don't dream it, be it. // Lagom amount.
-
válasz WonderCSabo #1270 üzenetére
cpt: command prompt, másképp parancssor.
elsőre kicsit minimál (bár a négy párhuzamos parancssor+csomó segítség miatt meglepően gyors), de pl puttyolva egész használható (úgy már lehet másolni is róla).
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz Jhonny06 #1277 üzenetére
szerk, módosítás utánra: konstruktor megkaphajta pluszban inputnak a számot. azt viszont valamilyen módon követned kell, hogy hány darab cucc lett már létrehozva (létrehozó osztályba esetleg egy variáns amit megkap a konstruktor?), nem lenne egyszerűbb azt a változót használni létrehozni az új objektumokat?
ha pedig az aktuális számuk az objektumoknak is fontos, akkor a destruktorban még mindig meg lehet rakni egy hívást a container class felé.
ha meg akarod az objektumokat számozni, és mindegyiknek akarsz egy sorszámot, akkor legegyszerűbb és leggyorsabb megoldás még mindig egy container class szerintem egy globális változóval. ha törölni is akarod őket akkor a dolog bonyolultabbá válik, főleg ha a korábban foglalt de már szabad számokat is újból ki akarod tudni adni.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz Jhonny06 #1288 üzenetére
jaja, használd a függvényeket listát manipulálni.
próbálj valami ilyet listázni
std::vector<Hallgato*>::iterator i = lista.begin();
for(; i !=lista.end(); i++){
Hallgato *hallgato = *i;
cout << lista->getAzonosito() << endl;
}(rem nem írtam el semmit)
esetleg ha tolsz egy
typedef std::vector<Hallgato*> Hallgatok;
sort, azzal későbbiekben egy csomó kódot megspórolhatsz. pl elég a
Hallgatok::iterator i
is.(azért néha örülök neki, hogy a 7.5kredites c++ programkomponenteknek lassan vége, köv negyedévben meg megint javazunk)
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz Jhonny06 #1293 üzenetére
tényleg írj segédfüggvényeket szvsz manipulálni a listát.
a c++ ugyan nem dobál mindenféle fura hibaüzeneteket ha az ember megsérti az encapsulationt (ellentétben pl a netbeanssel), ugyanakkor a segédfüggvények sokkal de sokkal egyszerűbbé tudják tenni az ember életét.
vector access element
vector.at(i)
vector referencevannak példák is, azokat másolva el tudsz valahova indulni. csak pl vector<int> helyett vector<Hallgato*> kell (lehetne Hallgato is, de az lassabb).
Don't dream it, be it. // Lagom amount.
-
válasz proci985 #1291 üzenetére
csak elszúrtam.
cout << hallgato->getAzonosito() << endl;
kell, mert itt már egy adott objektum pointerével lesz meghívva a függvény, és nem magával a listával.
egyébként emlékeim szerint volt erre valami egyszerűbb megoldás is.
WonderCSabo: a pointer a gyorsabb, emlékeim szerint Lakos a Large-Scale C++ SW Designben konkrétan adott adatokat is, hogy mennyivel (nem találom az oldalt). lehet olyan eset, hogy jobban megéri teljes objektumokat átadni, de szerintem ez nem olyan.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz Jhonny06 #1311 üzenetére
izé, ezzel nem az a baj, hogy a második sor jobb oldala char típusú, a jobb oldalar meg char**?
egy char** meg persze hogy nem lehet egyelővé tenni egy charral. na és valszeg ezért panaszkodik a típuskonverzióra a compiler. a visual studio szokott adni errort is, abból is ezt elvileg ki lehetne bogarászni.
a const nem zavarhat be, az csak annyit jelenthet, hogy az y értéken keresztül az x nem megváltoztatható szvsz, legalábbis funkciólnál ez így van. egyébként meg ilyen kód szerintem valós esetben classon belül nem igazán fordulhat elő. ha ez nem így van, akkor is max azt jelenti, hogy a pointer értéke nem változtatható, de az se csinálhat compiler típus errort.
vagy a harmadik ötlet: ez így design szempointból szerintem minimum fura, minek constanssá tenni egy pointert, amikor class scopeon belül azért ennyire a dolgokat szerintem nem kell védeni (illetve ha kell az már bőven régen rossz, meg amúgy sem ér semmit mert úgyis kiszedhető ez a kódrész is, ha más hozzáfér), ha meg class scopeon kívülre akarja az ember használni, akkor úgyis kell egy funkció, akinél pedig egyszerűbb írni egy constantot a funkcióra. szóval értelme ennek így semmi.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz WonderCSabo #1324 üzenetére
sztornó, elnéztem.
na, akkor most nézem meg a hibaüzenetet.
ok, legegyszerűbb megoldás: hiányzó ; a második sor végén? ha nem az, akkor
"cannot convert from 'char **' to 'const char **'"
mégiscsak a const a hibás.
char** const y = &x működik
const char* x;
const char** y = &x;
szintén.[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
-
az tényleg túlzás. Bjarnenek van egy másik könyve is, a Programming Paradigms and Principles in C++. Kezdőknek az egy fokkal jobb, de ott is érződik, hogy amerikában oldalra fizetik a szerzőt és néha szó szerint elveszik a részletekben (bevezetőt és a kezdeti éveket nyugodtan át lehet ugrani, egyenesen a hello wordig). viszont ha van sok időd, jó lehet, minden fejezethez van több oldalas önkontroll, hogy mit érdemes lekódolni.
Computerbooksnak volt egy programozzunk c++ nyelvenje, az tömör, viszont eléggé átgondolatlan a felépítése (kezdő abból nem fog megtanulni kódolni).
Don't dream it, be it. // Lagom amount.
-
válasz zuzu000 #1439 üzenetére
Ct kevésbé használják mostanában, és pár tekintetben sokkal macerásabb a C++nál.
jó könyv... hm. amivel ne kezdj, arra tudok példát mondani. a "lehányt" programozzunk C/C++ nyelven könyveket hanyagold, kaotikusak és nagyon hullámzik a nehézségük. aztán van a "The C++ programing language", Stroustruptól, az szigorúan kerülendő, hiába a C++ atyja írta. a kiadó szerint kezdőknek jó, gyakorlatban pár év tapasztalt kell hozzá.
ami jó, az a Programming paradigms and principles using c++, szintén Stroustruptól, csak kezd a második fejezettől, mert az első lazán kapcsolódik és alapvetően architektúrával foglalkozik (ha foglalkoztál digitális technikával érdekes, egyébként nem ad pluszt). azért jó, mert tényleg az elejétől kezdi, és szépen lépésenként vesz mindent. tehát ha van sok időd, akkor jó, egyébként tutorialozz. ja és angol, bár szerintem ez előny.
Don't dream it, be it. // Lagom amount.
-
válasz zuzu000 #1442 üzenetére
esetleg php is jó lehet kezdeni szerintem. c++nál két fokkal javanal egy fokkal egyszerűbb, nagyon hamar lehet vele eredményt elérni. mellesleg használható is.
régebben még basicet és pascalt szokták mondnai kezdőnyelvnek, de alapvetően nem tudom, hogy mennyit nyernél velük, pascalt már nem nagyon használ senki, basicban se vagyok annyira biztos (bár excelnél még lehet használatban van pár helyen).
docnak egyébként valahol igaza van, C++ nem biztos, hogy jó kezdő nyelvnek, annak ellenére, hogy pár éve aktívan próbálgatják sok helyen ilyen szerepben. mondjuk szerintem kezdeni még mindig a C++ a jobb (pl az embernek nem kell saját dinamikus adattárolót építenie), bár mindkettő problémás. mindkettővel kb az a baj, hogy ahhoz, hogy az ember megértse, pontosan mi is történik, nem árt valamennyire képben lenni architektúrában/digitális technikában. valamint hibázni is elég könnyű velük, memóriakezelés mindkettőnél eléggé problémás lehet. java valamennyit elfed a problémákból, php meg még annál is többet.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz h1ght3chzor #1510 üzenetére
(memműveletekben annyira nem vagyok jó)
szerintem itt a getprojectmeret lesz a hunyó, elvileg az a Memory classhoz tartozik, és a projectméret által visszaadott változó nem lesz updatelve az új, egyel nagyobb értékre. magyarul a következő másolásnál elveszik az utolsó eleme a tömbnek..
vagy esetleg fel lehet még hozni a hungrish elnevezéseket, meg az elnevezési konvenciók figyelmen kívül hagyását (getProjectSize / get_project_size), bár valszeg nem azokra gondoltak
Don't dream it, be it. // Lagom amount.
-
szerintem lehet egyel nagyobb is az eredeti tömbméretnél. leírás alapján nekem ez egy Cben használt dinamikus tömb megoldásnak tűnik. más kérdés, hogy nem értem, hogy ez minek C++ alatt, amikor ott vannak a beépített funkciók.
h1ght3chzor:
Memory::tomb[k]=a;a az itt micsoda? honnan jön? mi a típusa? szerintem ez is lehet baj.
tippek:
- használj változóneveket angolul, konvenciókkal. pl class scope változóneveknél m előtag sokkal átláthatóbb kódot eredményez.
- a this és Class:: jó móka, de legyél velük koherens
- ha nem ez volt a lényeg, akkor használd a beépített C++ funkciókat. vannak szép dinamikus listák, ez nem C. ArrayListel egy sima add() meghívásával megoldható a problémád
- getProjektMeret redundanciát és több helyen tárolt változókat jelent, amiket pl a mutatott kód alapján nem is updateltél. szerencsésebb a tömb méretét nem letárolni külön, vagy létrehozni egy külön container classot, ha mndenképpen sajátot akarsz írni.
(másképp: ránézésre vizsgafeladatnak hittem a problémád, annyira spagettiszerű. ez hosszú távon nem jó)ArchElf: még azon gondolkodtam el, hogy a tömbnél a tárolás hogy van megoldva, mert a delete[] elvileg csak a mutatókat törli implementációfüggően. nem vagyok benne biztos, de ez nekem gyanús, hogy leakelni fog (pl saját operator= segítségével nem).
WonderCSabo: tippeltem, illetve tippelek.
temp1[i]=tomb[i];
this->tomb=new Project [this->getprojektmeret()+1];
Memory::tomb[k]=temp1[k];mivel egy dinamikus tömböt megvalósító funkcióról van szó arrayekkel, a két tombnek elvileg ugyanoda kéne kerülnie. a két kódrészlet futás után csak akkor egyezik, ha ugyan ahhoz a classhoz tartoznak. hacsak nem tomb egyszerre van deklarálva globális változóként és a Memory class változójaként (és a this miatt ebben az osztályban) is, de az azért erős lenne. ha viszont eléri a tomb[]ot innen, tomb[], Memory::tomb[] és this->tomb[] megoldásokkal is, akkor jelen pillanatban a Memory classban kell lennünk, másképp három különböző tömbről lenne szó. habár, a this->tomb sor kiakad, szóval lehet, hogy mégse így van. ebből következtettem, hogy ha ez így működik, akkor a Memory classban kell lenni.
getprojektmeretnek classfunctionnak kell lennie, ami eltárolja az elvárt projektméretet és nem a tomb méretét adja vissza (egyébként az új projektnél kiakadna).
Don't dream it, be it. // Lagom amount.
-
válasz h1ght3chzor #1524 üzenetére
teljes kód nem kell, pl egy tömb típusa, még az a is elég szvsz.
tipp: szeparáld a tárolóclasst a projecttől, és teszteld pl egy célra létrehozott classal külön. szerintem egyszerűbb lenne, hacsak nem valami minimálprojektről van szó, ahol nem éri meg mindent szétválasztani.
"Egyébként stl tárolót, nem használhatok"
beadandó?WonderCSabo: jogos, push_back pedig tényleg a legegyszerűbb.
Mindent van értelme dinamikusan kezelni, sokszor jól jöhet (bár nyilván ilyen kicsi feladatnál nem sok értelme van).
persze, de elnézve a kódot volt egy olyan sanda gyanúm, hogy itt valami egyéb követelmény is van a háttérben (tipikus c iskolapéldának tűnt)..Don't dream it, be it. // Lagom amount.
-
válasz Dave-11 #1579 üzenetére
kicsit kompaktabban és konyhanyelven:
a program leképezi a valós dolgot, innentől könnyebben elképzelhető, könnyebben használható. az emberi agy szeret kötni dolgokat valahova, tehát végereményben logikusabb lesz a felépítés.
ez azt is jelenti, hogy általában a dologok közötti egymásrahatások is átláthatóbbak, jól csinálva egyszerűbben átlátható lesz az architektúra (tehát a classok kapcsolata, egymásraépülése és végeredményben a program felépítése), tisztábbak lesznek az interfacek. a funkciók és változók szintén köthetőek lesznek a valós dologhoz, tehát könnyebben átlátható lesz, hogy mi miért kellhet, kevesebbet kell kommenteket/dokumentációt olvasni, emiatt könnyebben módosíthatóvá és megérthetővé válik a program. az ember kvázi építőkockákat kap, amik segítségével a nagy egész könnyebben feldarabolhatóvá (főleg design patternsek alkalmazásával), így könnyebben megérthetővé válik.
másik fontos szempont, hogy a dolgok elkülönülnek egymástól, tehát egy dolog nem több egységben (component/class) lesz megvalósítva, ez megint átláthatóbb kódot jelent. ami egyben azt is jelenti, hogy egyszerűbben átláthatóvá válik a programlogika. ez ismét a módosíthatóság/karbantarthatóság/megérthetőség hármast erősíti, illetve a tesztelhetőséghez is kell. htlmt generáló php+jquery+css+sqlnél pl elég vicces tud lenni, amikor az ember elkezdi keresni, hogy a 20+ fileból ugyanmár mi is felelős egy adott gomb működéséért, ha nincsen szépen megtervezve a rendszer (és persze a html útközben változik).
tesztelhetőséghez amiatt fontos, mert egyszerűbb egységek szintjén kezdeni, és általában minél kevesebb egység kell egy adott feladat kipróbálásához (elsősorban itt dependencykre kell gondolni), annál könnyebben lesz tesztelhető egy adott megoldás. a jól definiált interface szintén nagyban segíti a blackbox testinget. azt nem szabad elfelejteni, hogy az OO design egyben ronthat is a tesztelhetőségen, bizonyos design patternek (pl singleton vagy insulation classek) ilyen szempontból problémásak.
ami még lényeges, hogy az OO design nem igazán enged meg globális változókat, amik megintcsak nagyban rontják a későbbi karbantarthatóságot.
namost, ami az egésznek a lényege: a programok életciklusa hosszú lehet, ezalatt cserélődhet a teljes fejlesztői gárda, cserélődhetnek a célok, amiket az ember elvár a terméktől. az OO design ezekre a kérdésekre ad (részleges) választ és segít abban, hogy az a kód, amit az ember megír, később is használható legyen, amikor módosítani kell.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz kmisi99 #1601 üzenetére
üss fel egy könyvet és nézz utánna, vektort sokkal egyszerűbb használni, mint egy statikus tömböt szvsz. map is csak leírva hangzik bonyolultan.
alternatíva: szerintem egyszerűbb egy kétdimenziós tömb, aminél a nulladik tömbelem az angol, első a magyar. ha a szöveges állományt pl le lehet tárolni egy tömbben, és jól veszem ki, hogy nem feltétlenül kell fileból olvasgatni.
aztán forciklus, végigmész a tömb nulladik elemein, ha egyezik a beírt és a tömbben letárolt string, akkor pedig kiíratod a tömb[1] es elemet. csúnya megoldás, de szerintem ennél egyszerűbben nem megy. előny, hogy nem kell két tömb (macera őket egymáshoz láncolni), hátrány van sok, de alapvetően iskolapéldának lekódolni egyszerű.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz proci985 #1604 üzenetére
nem lett jó a formatálás.
a tömb[i][1] elemet kell kiiratni.
mégvalami: lineáris lépésszám: mind az n elemen át kell menni, száz elemnél ez 100 (nagyon leegyszerűsítve, egy matematikus itt sikítana).
logaritmikus lépésszám: száz elemre log100, tehát 10 lépés, tehát gyorsabb.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz WonderCSabo #1606 üzenetére
és log100(100) == 1.
persze, egy 11.be járónál inkább nem fejtettem ki az ordot, a lépésszámot, meg az egyéb kapcsolatos szépségeket.
Don't dream it, be it. // Lagom amount.
-
válasz cooldongo #1608 üzenetére
hm, miért kell typedef, nem elég egy class Kor, unsigned int r, unsigned int x és unsigned int y paraméterekkel? struct is működik, de akkor globálisak lesznek ezek a változók.
Kor.h
class Kor{
public:
Kor(unsigned int r, unsigned int x, unsigned int y);
unsigned int mR;
unsigned int mX;
unsigned int mY;
};Kor.cpp
#include "Kor.h"
Kor(unsigned int r, unsigned int x, unsigned int y){
mR = r;
mX = x;
mY = y;
}boolean egybeesik_a_kozeppont(Kor k1, Kor k2){
if((k1.mX == k2.mX) && (k1.mY == k2.mY)){
return true;
}
else return false;
}boolean c_kerdes(Kor k1, Kor k2){
Kor k11 = k1;
Kor k21 = k2;
if(egybeesik_a_kozeppont(k11, k21)){
cout << "egybeesik";
}
else{
cout << "nem esik";
}
}elvileg ennyi. tpusdefiníciót amiatt furálom, mert object köröket ezekután simán lehet használni. typedef akkor jó, ha egy külső classban van egy adatszerkezet definiálva, aztán az ember nem akarja minden alkalommal a KulsoClass::ValamiSpecAdatstruktura sort beirogatni. kódolvashatóságot typedef javíthatja, de később (amikor eljutttok OO programozásig) bőven lehet vele szívás.
apró gondolat: szerintetek belegondoltak a programozási feladatokat kiadók, hogy rászoktatják a diákokat a magyar fv/változónevekre, amikor azokat igazából messziről kerülni kéne? meg 2012ben struct C++ban?
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz WonderCSabo #1612 üzenetére
igaz.
Hol írtam én, hogy azt kellett volna tenned?
sehol, csak indokoltam a csúnya pongyola fogalmazásomat.és publikusak lesznek, arra gondoltam.
Chipi333: structnál inkább csak annyi, hogy erre a célra szerintem már változók kellenének. bizonyos feladatokra tényleg jó a struct, de erre a célra fura ez a design, aztán meg ezt szokják meg.
Don't dream it, be it. // Lagom amount.
-
válasz kmisi99 #1614 üzenetére
Cben vagy C++ban kell? van némi eltérés szintakszis tekintetében.
működőképesnek tűnik (közben látom mások is válaszoltak), de ez tényleg eléggé gány. rázd gatyába, ha eléggé érted, hogy be tudd mutatni, akkor módosítani is tudnod kell.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
-
-
válasz WonderCSabo #1631 üzenetére
jaja, az expressre gondoltam, csak nem jutott eszembe pontosan hogy hívják. Code:locksot nem ismerem.
ja, nekem is van egy ilyen rossz érzésem, de azért megkérdeztem, hátha...
Don't dream it, be it. // Lagom amount.
-
válasz WonderCSabo #1638 üzenetére
szerintem azért a fv és osztálykiegészítgetés remek, visual studioban pont azt imádtam, hogy ha az ember valamit elszúr, akkor azonnal látszik, mert az intellisense nem ajánl fel dolgokat.
VS express szerintem nem rossz: csomó szempontból tényleg overkill, de egyébként sokat segít (mondjuk a netbeans funkcióleírásait jobban szeretem).
másik oldalról meg ha a tanár ennyire inkompetens, és hosszú távon akár ezzel is akar programozni, akkor szerintem egész egyszerűen el kell kezdeni önképezni sajnos.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz WonderCSabo #1641 üzenetére
nálunk itt a kezdők VS2010el kezdenek, és meglepően jól megy nekik. első két gyak az ismerd meg a compilerről szól (pontosan mire kattints, hogy le is forduljon), utánna működik.
ha komolyabb hibára fut, akkor meg még mindig a hibakód alapján rá lehet jönni, hogy mi történt. szerintem sokkal egyszerűbb az elején, mint mondjuk amennyit én szívtam a dosos borland c++al.
ettől még ugyanúgy megtanulnak szépen kódolni.
papíron kódolásnak szerintem sok értelme nincs. nem tükröz valós felhasználást, ha meg tervezni kell valamit, akkor gráffal/automatával/flowcharttal, esetleg pseudokóddal szerintem jobb eredmény érhető el. megeshet persze, hogy az embernek szinte segítség nélkül kell kódolnia, de pl unix kernelt moddolni az elején még nem fog senki (és a compiler még ott is ad valamennyi visszajelzést ha az ember elszúrja, legalábbis minixnél biztosan).
Don't dream it, be it. // Lagom amount.
-
válasz dabadab #1646 üzenetére
empty projekt van, nem véletlenül írtam, hogy első két gyak arról szól slideokkal kiegészítve, hogy mire kell kattintani. pont a vuduk miatt.
refactoring tényleg hiányzik belőle.
WonderCSabo: empty projekt, lehet VSben is teljesen szabvány C++ kódot írni. grafikus felületre egy egyszerű, saját library van használva, szóval az a rész kb annyira nehéz, mint mondjuk javaban a gui. meg mellesleg a tanulók megtanulnak egy external libraryvel dolgozni, illetve kapnak egy képet, hogy miért jó az OO felépítés.
Borlandon pedig meglepődtem, hogy még használják valahol.
Högskolan i Skövde
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz dabadab #1649 üzenetére
arról nem is beszélve, hogy ember leírja, aztán az IDE azonnal szól is, hogy ez meg ez így nem lesz jó. szóval használat közben tanít. szerintem is remek feature, sokkal jobb, mint órákon át keresgélni, hogy mi a fenéért nem működik a kód rendesen, mert véletlenül a return mögé írt egy sort. kezdőként folyamatosan szívni a szintaxissal eszméletlenül irritáló.
más kérdés, hogy mivel az IDE szól, egy idő után szerintem jobban berögzül, hogy mi nem lesz jó, mivel azonnal van feedback.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz Sk8erPeter #1653 üzenetére
arról nem is beszélve, hogy a magyarul elérhető könyvek egy része úgy rossz, ahogy van. kedvencem a programozzunk c++ nyelven volt, ami a classok elmagyarázása előtt vezette be a dynamic cast fogalmát.
aztán később azokra a problémákra, amiket az IDE már nem szűr ki vannak egész jó könyvek. a Lakos féle Large-Scale C++ SW Design szerintem pl a célra tökéletes, gyakorlatias és érdekes leírás arról, hogy mire kell ügyelni és miért.
egyébként mostanában van pár weboldal, ahol programozói kurzusokat tartanak úgy, hogy a végén egy kis dobozba az embernek meg kell írnia a kódot. aztán a beírt kód után kapásból az ember feedbacket is kap, pont mint egy IDEnél. pl itt egy példa jqueryvel. említett tutorialt kb egy nap alatt toltuk le pár másik emberrel egy projekten belül, arra pedig teljesen elég volt, hogy utánna neki tudjunk állni jqueryben haxolni. ez az interaktív kikérdezgető nélkül nehezebb lett volna. alternatív megoldás a vadludas stroustrup féle, kb hagyj le egy betűt és nézd meg mit csinál variáns. egyetlen probléma, hogy ez az interaktív megoldás sokkal de sokkal gyorsabb. többiekkel beszéltük is, hogy ha nem találjuk meg ezt az oldalt, akkor valszeg sokkal nehezebb dolgunk lett volna. így meg nevetve konstatáltuk, hogy egész jól alakul a honlap, pedig kb azelőtt két héttel kb semmit nem tudtunk a jqueryről (minimális jscript tudásunk volt).
kmisi99: projekt mappája megvan? .c++ fileok tudod hol vannak?
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
válasz Sk8erPeter #1665 üzenetére
ez még egy lassan 10 éves könyv, általában emberek azért használták, mert nem volt jobb. tavaly megint megpróbáltam elolvasni, mert anno sokat nem értettem belőle... és rájöttem miért.
azt a könyvet már nem láttam, mostanra meg teljesen áttértem angol szakirodalomra.
nézd meg, remek kezdő kurzus, de eszméletlenül hatékony.
goto téma: bizonyos speciális esetekben tényleg értelmes lehet. hasonló vele a helyzet, mint az egyébként élénken tanított friend classokkal (megborítható velük az OO struktúra és ezzel a program folyása, de néha elkerülhetetlen). de typfedeffel, definíciókkal (#define private public, csak hogy egy extrém példát mondjak) és operator overloadinggal is lehet vicces dolgokat csinálni. vagy csak simán a konvenciók figyelmen kívül hagyásával (angol classnevek pl).
Don't dream it, be it. // Lagom amount.
-
válasz Sk8erPeter #1676 üzenetére
amelyiket linkelted simán lehet jó, köszi az ötletért, itt a topikban sincs nagyon ötlet, hogy mi lehet jó kezdőknek.
amelyik rossz volt, az a programozzunk c++ nyelven. félreérthető voltam azt hiszem
Don't dream it, be it. // Lagom amount.
-
válasz dabadab #1721 üzenetére
jaja, néztem is először, hogy ezt így hogy.
más: nyaralok, szóval találtam egy könnyű esti olvasmányt, Robert C Martin -- Clean Code című művét, ismeri valaki?
igazából ami nekem szöget ütött a fejembe, hogy az egy funkció - egy cél gondolatmenetet az extremitásig viszi, pontosabban nagyon rövid funkciókat ajánl. ami az olvashatóságot javíthatja, viszont sebesség szempontjából nekem eléggé problémásnak tűnik. másik oldalról persze az érthetőség/sebesség/kompaktság hármas korántsem egyértelmű problémakör, amíg elég gyors a program, addig igazából nincs baj.
persze a példákon keresztül (illetve saját tapasztalatok alapján is) indokolt a dolog, csak mégis... amire még gondoltam, hogy a compilerek elvileg eléggé sokat fejlődtek sebesség terén, funkcióhívások még mindig annyira kritikusak sebesség szempontjából, mint mondjuk 10 éve? elsősorban itt most nem olyan helyzetekre gondolok, ahol általában nincs szűk keresztmetszet a rendszerben végrehajtási sebesség szempontjából (tehát pl nem a grafikáért felelős részre egy játéknál).
Don't dream it, be it. // Lagom amount.
-
válasz WonderCSabo #1734 üzenetére
ezt én is így tudom, ahogy olvastam a compilerek ezen a téren eléggé sokat fejlődtek.
dabadab: köszi az észrevételeket, egy sor dologban megerősítettél.
sebesség tényleg lehet kritikus, az általad leírt probléma pedig különösen érzékenynek tűnik.
Vico87: köszönöm Neked is.
picit igazából rácsodálkoztam, hogy pár év alatt milyen hatalmasat változott a szemlélet, avagy az architektúra (és a különböző patternek) mennyire fontossá váltak. ugyanez a tesztelhetőségre is igaz.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
ha kattintgatós GUI kell, arra ne C++al kezdjél, a GUI rész c++al mérföldekkel nehezebb, mint bármi mással. ez a feladat leírás alapján php+csssel egész egyszerű, C++al lehetnek buktatók.
adatbázishoz használj külső libraryt. guihez is muszáj lesz.
Stroustruptól melyiket olvasod, a principles and paradigmst vagy a the c++ languaget? utóbbi nem kezdőknek való és abból nem fogsz megtanulni c++ programozni. az első egy fokkal jobb, tapasztalt programozóként mennie kell. ja igen: használd az angol könyvet, a magyar fordítások (a műszaki könyvkiadósok is) használhatatlanok.
tipp: elsőre csináld meg csak az adatbázist logikai részét, tehát se gui, se mysql (ha kell később külső libraryk formájában csatolhatod).
ha publikus pl postolj ide egy class diagramot, funkciókkal és változókkal, hogy hogy gondolod a felépítést, aztán utánna lehet kódolni és ha kész, akkor mehetsz tovább a gui és a dbs integrálás felé.
Don't dream it, be it. // Lagom amount.
-
oké, de igazából ha szépen megtervezed, akkor GUIt később tudod csatolni.
annyira nem veszélyes a másik nyelvezete sem.
igazából amiatt nem ajánlott kezdőknek, mert kegyetlenül csapongó: néhol nagyon szájbarágós, máshol pedig kell némi háttér HW architektúrában, hogy az ember megértse, miről van szó. utóbbi Neked valszeg ismerős, de mondjuk egy gimnazistának sok lenne, ahogy elmondja, hogy a pointer/referencia miért úgy lett megoldva, ahogy.
fura stílus tükörfordítás miatt is lehet.
olvasás egyébként jó, ha tapasztalt vagy, akkor lehet így fog menni a leggyorsabban.
Don't dream it, be it. // Lagom amount.
-
mobil platform symbian/oo C/android, vagy más volt? tehát akkor valamennyi OO/scipt tapasztalatod van.
na, akkor van segítség, remek.
tervezéshez gyakorlatilag bármelyik UML megteszi, elsőre érdemes elsőre csak a kapcsolatokat végiggondolni, aztán interfacet tervezni, aztán jöhetnek a belső függvények. ha igazán ügyesek akartok lenni, akkor minden class kaphat egy saját testclasst is, minden függvény pedig egy saját tesztfüggvényt, úgy gyorsabban kijön, ha valami nem azt az eredményt adja, amit kell (assert gyorsabb, standard outtal viszont láttok eredményt is). ha meg kész vagytok a könyvvel, a Gamma féle Design Patterns (vagy a wiki) ajánlott, legalább a facade/abstract factory/decorator/insulated concrete class/connector/singleton ajánlott átnézésre. m-n kapcsolat biztos lesz az adatbázisban, az pedig legegyszerűbben talán egy connector (esetleg singletonként) segítségével megoldható. legalábbis anno nekem nem volt jobb ötletem a circular dependency elkerülésére.
programnak az MS féle Visio jó, de én a Dia nevűt jobban szeretem, kevesebb megkötés és nekem picit jobban kézreáll.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
-
"beszél egy (OO) nyelvet, beszéli az öszeset", kaptam anno a választ több helyen egy hasonló kérdésre... túlozva, de erről van szó. ha tudsz Javat, akkor C, C++, PHP, C# is gyorsan megy, és kb ez minden irányba igaz iteratív OO nyelvek között. meg pascal és basic, de előbbit mostanában már nem nagyon láttam sehol.
ha a fizu a lényeg, akkor menj rá C++ra és banki tranzakciókra, aztán irány london city, tényleg remek C++ programozó kevés van, de az nem egy egyszerű nyelv, főleg nem magas szinten. alternatívaként ha jó vagy scriptben akkor menj rá ciscokra és irány norvégia sysadminnek. mindkettőhöz kell a folyékony angol (minimum CAE szint, de inkább fölötte), de ha tényleg el akarsz mélyülni egy nyelvben, akkor az angol amúgy is megkerülhetetlen.
trendek vátoznak, de aki valamiben tud jól programozni, az egyszerűen tanul másik nyelvet. pont, mint az élő nyelveknél.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
gyakorlatban: minden php előképzettség nélkül a harmadik nap már haxoltunk egy weboldalat. java/c++/c tudás volt, minden mást arra alapoztunk. az idő nagyrésze google volt, avagy melyik az a funkció phpben, ami ezt meg ezt tudja. nem lett szép a kód, de alapvetően spagettikódon kellett ügyködni... és nem tolhattunk teljes refactort.
c++ elmélyedés jó. sebességre egyébként c++ remek, de pl valósidejű rendszereknél ahogy látom a környékbeli cégek Adáról Javara térnek inkább át.
guideline link?
amit gondolsz, az pontosan úgy van, változónévbe nem kell berakni a típust, későbbi refactornál csak a baj lehet belőle. ha előtte van a típus, az úgyis látszik. hungarian notationsnak valaha volt értelme, de a jelenlegi fejlesztői környezetekkel csak problémákat szül.
postfix annotationt én még nem láttam, szerintem felesleges és végig kell hozzá az egyész FVnevet olvasni (nem látható át gyorsan), szal szerintem az értelmetlen.
prefix tekintetében eltérnek a vélemények. én pl c++ban szoktam m_ prefixet használni a class variableknek, szerintem annyival nem kell többet írni, mint amennyivel átláthatóbbá teszi a kódot. illetve ha a Car classnak van egy m_wheel private variableje, akkor az interfacen lehet a wheelt használni inputnak, így később kívülről az interface tisztábban tartható és nem lehet keveredés, hogy mi honnan jön. ugyanakkor SDKtól függően ez sem mindig kellhet.
egyébként ha érdekelnek a konvenciók, akkor a Lakos féle Large Scale C++ Design remek és zseniális darab, illetve szerintem a Martin féle Clean Code is remek, bár utóbbi inkább Java orientált, de C++ra is nagyrészt érvényes.
Don't dream it, be it. // Lagom amount.
-
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Bomba ár! Lenovo IdeaPad B50-50 - i3-5GEN I 4GB I 500GB I 15,6" I HDMI I Cam I W10 I Garancia!
- Bomba ár! Lenovo ThinkPad L380 - i5-8GEN I 8GB I 256SSD I 13,3" I HDMI I Cam I W11 I Gari!
- Bomba ár! Dell Latitude 3190 - N5030 I 8GB I 128GB SSD I 11,6" HD I HDMI I Cam I W11 I Garancia!
- Bomba ár! Dell Latitude E7450 - i5-5GEN I 8GB I 500GB I 14" HD I HDMI I Cam I W10 I Garancia!
- Bomba ár! Dell Latitude E7450 - i5-5GEN I 8GB I 128SSD I 14" FHD I HDMI I Cam I W10 I Garancia!