- Yettel topik
- Fotók, videók mobillal
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- OnePlus 15 - van plusz energia
- Apple AirPods Pro (2. generáció) - csiszolt almaságok
- Google Pixel topik
- Samsung Galaxy Watch8 és Watch8 Classic – lelkes hiperaktivitás
- Motorola Moto G77 - kis motor, nagy karosszéria
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- iPhone topik
Aktív témák
-
Kkocos
tag
Sot mivel az OO-fanatikusok rendesen kiosztottak, pedig jeleztem hogy mas kornyezetben gondolkodtam, meg 1, csak hogy jobban az altalam forszirozott temaba vagjon (PLC, nem PC, nem gyozom hangsujozni), POP (Process Oriented Programming) vs szekvencialis programozas, es nem a feltunesi viszketegseg motoszkal bennem, csak tenyleg tanulni szeretnek masok tapasztalaibol (mondhatjuk hibaibol). Alaperv a secvencialis megoldashoz- nem kell figyelned az operator parancsaira, esetleg a nem lenyeges bejovetelekre, csak akkor koncentralsz rajuk amikor szugseg van ra. Alapszinten itt is megy a POP, csak epp a szekvencialis elvet kovetve, vezrlest csak akkor megengedve ha epp a megfelelo fazisban vagy!
-
S.P.Q.R.
csendes tag
Kezd ez a topic elég tanulságossá válni és ez jó
A századik hozzászólás jön pár nap alatt...
Nah DB-kről beszélünk?
Nem csak feltétlen sql alapú adatbázisokról, de érdekel a véleményetek a kül OO-s megoldásokról, illetve a mai világban egyre elterjedtebb(amit amúgy én is hazsnálok ahol tudok) XML-s megoldásokról.
Ki hogy látja ezek jövőjét? -
bambano
titán
Linuxban is lehet stackre programot rakni, mert egy-két dolgot másképp nem tud lefordítani a gcc (trampoline, vagy minek hívják, de annyira nem izgatott, hogy megjegyezzem).
Az mmap függvénynek meg meg lehet adni, hogy hogyan másolja be a lapot, tud readonly-t. Ennyi. Nem bonyolítják túl.
Az, hogy a linux lapoz olvasható lapokat is, még nem mond semmit arról, hogy hova.
open("/lib/tls/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240O\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1241392, ...}) = 0
mmap2(NULL, 1251484, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7de9000
mmap2(0xb7f11000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x127) = 0xb7f11000
mmap2(0xb7f18000, 10396, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f18000
close(3) = 0 -
P.H.
senior tag
Az lehet árulkodó jel, hogy az K10-es TLB-hiba Linux patch-e azt csinálja, hogy a lapozásból felhozott vagy újonnan allokált/feltöltött lapot a kernel automatikusan megjelöli Accessed-ként - ha csak olvasható a lap - vagy Dirty-ként - ha írható is az (ebből gondolom, eddig nem tette). Tehát eszerint a Linux lapoz csak olvasható memóriaterületeket is, ami lehet konstans-tábla vagy kód, más nem nagyon. Illetve még egy eset lehetséges: Linux és Windows egyaránt használ bizonyos spekulatív prefetch-algoritmusokat a HDD-re tárolt lapokra (más esetben kizárt, hogy visszaolvasott lap ne legyen legalább Accessed). Linux-ban nem vagyok járatos, a Windows nem különbözteti meg ezeket (sőt, a verem és a - dinamikus - adatterület is futtatható, én pl. használom is, futás közben létrehozott kódok - timer - esetén).
Továbbá az x86/x64 csak a fenti szinten nyújt hardware-es segítséget (Accessed+Dirty, DEB/NX ill. nem 'Present' lap esetén egy-egy megszakítás kiváltása), tehát ha ez így van, akkor az mégis külön táblázatok és software-es háttéradminisztráció létét feltételezi.
#92: az mmap()-et hogyan kell kiadni futtatható kódokra? (nézegetem pl. itt, méret is szükséges hozzá; a fordítók adják ezt?)
akosf: mindkét korábbi kód (@TRUNC és @ROUND) külön hívott belső Delphi eljárás, Delphi 4-ben kiírtam a disassembly-ablakból (a Delphi Enterprise Edition-ok mellé adják gyárilag a teljes fordítási forráskódot - VCL és runtime libraries -, a 4-es verzió felett még komplexebb a @TRUNC). Ha jól meggondoljuk, akkor gyorsabb truncate-sorozat a
Set8087CW($xxxx); + ...round() hívások sorozata
de ha valaki FPU control word-ot módosítgat, akkor már teheti assembly-ben is az egészet. De magas szinten is van gyorsabb 4-esben is, de ez meg ellentmond(?) a C-s szabványnak, hogy int_a=float_b mindig a kerekített értéket adja. -
#95904256
törölt tag
Ez valóban off-topic... így OFF on
Amit leírtál az eddig is ismert volt számomra, de nem egészen értek egyet a véleményeddel. Méghozzá itt:
- nem teljesen értelmes oprendszer: betölti diszkről a programkódot és a libeket, ezeknek foglal egy szép nagy adag ramot, és összelinkeli. Majd ha helyhiány van, akkor kipakolgat a swapre (amit helyesebb lenne page-nak nevezni, mert ez nem swappelés), ha megint van hely és kell a lap, visszatölt a swapről.
Azt megértem hogy furcsán hat hogy ugyanaz a programkód két helyen szerepelhet a merevlemezen, de ez nem feltétlenül jelent hátrányt. Amennyiben a memória kiterjesztését (virtuális memória mentés/töltés) automatikusan végzi a memóriakezelő úgy nem kell egy másodlagos adminisztációt elvégezni hogy az adott blokk honnan származik, az módosult-e már azóta. Persze mindenki döntse el maga hogy ez neki előny vagy hátrány. Annyit még hozzátennék hogy nem csak read-only programterület létezik. Ennek a mentős/töltögetős módszernek ez sem jelent plusz feladatot.
-
bambano
titán
válasz
#95904256
#85
üzenetére
Ezzel már offtopic vagyok, ha jól sejtem... sorry.
A kérdés nem az, hogy a legrégebbi vagy a legritkábban használt lapokat teszi-e ki a swap-re, hanem hogy egyáltalán kitesz-e bármit is.
A linux kernel úgy gondolja, hogy annak nulla értelme van, hogy egy programkódból két teljesen azonos szektortartalom keletkezzen (hogy két példányban legyen a vinyón, egyik példány az eredeti helye, ahonnan betöltődött, a másik példány a swap), ezért a linux egyáltalán nem pakol ki ilyet a swap-re.
Egész egyszerűen kihajítja a fenébe, majd ha megint kell, akkor betölti az eredeti helyéről.
Tehát konkrétan:
- nem teljesen értelmes oprendszer: betölti diszkről a programkódot és a libeket, ezeknek foglal egy szép nagy adag ramot, és összelinkeli. Majd ha helyhiány van, akkor kipakolgat a swapre (amit helyesebb lenne page-nak nevezni, mert ez nem swappelés), ha megint van hely és kell a lap, visszatölt a swapről.- linux: pontosan tudja, hogy a futtatni való program és a szükséges libek melyik része az, amit readonly módban is be lehet tölteni, melyik része az, ami változik (pl. a linkelési infók változhatnak, de a lib nagy része nem), és azt csinálja, hogy a nem változó részeket közvetlenül összerendeli a ram és a diszk között. A változó részeket meg összerakja ugyanúgy, ahogy mások. Ha memóriát kell felszabadítani, mivel tudja, hogy mely lapok nem változhattak, tudja, hogy pontosan ugyanezen lapok hol laktak eredetileg a diszken, ezért ezeket a lapokat nem vési ki a swapre, hanem kihajítja a kukába, és legközelebb nem a swapről, hanem az eredeti helyéről tölti vissza. Így spórol a swapen levő hellyel meg a swap írási területekkel is.
A diszk-memória összerendelés az majdnem ugyanaz, mint az fread(), de mmap()-nek hívják. Egyes helyeken az fread is lehet mmap.
-
doc
nagyúr
komolyan nem erzed, hogy milyen nevetseges vagy? osszefoglalom az altalad eddig elmondottakat:
"nem ertek az OOP-hoz, nem ismerem, de akkor is szar, semmi ujat nem hoz, tulbonyolit mindent, eroforrast pazarol, parasztvakitas az egesz, mondhattok barmit akkor is igy van es kesz"
az meg mar elhangzott, hogy a PLC nagyon mas vilag, mint a PC, nyilvan nem is "celpontja" az OOP -nak
irj programokat PC-re, mondjuk osszetettebbeket, ahol egyszerre sok dolgot kell csinalnod/kezelned. en is "sima" C-vel kezdtem, elveztem a strukturaltsagot/prodecuralitast a BASIC meg tarsai utan, de idovel nagyon nehez volt kezdben tartani egy-egy nagyobb kódot, mikor minden kis változáshoz egy rakás helyen kellett beletúrnom a kódba, aztán nyomozni hogy mi maradt ki, amitől még mindig nem jó...
az OOP nagyon kényelmes megoldást kínál ezekre a helyzetekre, remekül módosítható, átlátható, és ha valami kész van, akkor azt szépen elrakod, mint egy konzervdobozt, és nem kell beletúrni, csak elolvasni a dobozt, hogy hogyan kell használni és kész
elvileg persze ugyanezt meg lehet csinálni a hagyományos módszerekkel is, de az én tapasztalatom azt mutatja, hogy a sokkal nyögvenyelősebb.
aztán vannak olyan területek/nyelvek ahol az ember eleve nem tud mást csinálni, mint használni az OOP-t, pl. Java, ActionScript3, stb
megszokás után az ember soha nem szokik le róla
arról nem beszélve hogy milyen szép egy OO program. tudom, ez baromi szubjektív, de nekem akkor is sokkal jobban bejön egy Enemy.selfKill() mint egy Kill(Enemy)
vagy hogy hatmillió különféle objektumod mindegyikének mondhatod hogy "show" meg "hide" vagy "moveTo", nem kell külön függvényeket csinálni az összes típusra, mondjuk ShowBullet(), ShowShip(), ShowEnemy(), stb... persze itt is kihasználhatod hogy többféle típusú paraméterrel megírod ugyanazt a függvényt, de akkor is sokkal több meló, meg hogy elővegyük a vesszőparipádat: sokkal több felesleges erőforrás (ram, stb) elpazarlása -
#89
dabadab
titán
fordfairlane
#87
válasz
fordfairlane
#87
üzenetére
Ize, elsore volt visszateresi ertekuk is (ebbe lett volna), de aztan ugy dontottem, hogy jobb ugy, ha voidok (viszont a valtozot elfelejtettem kiszedni).
-
#88
fordfairlane
veterán
Kkocos
#83
fordfairlane
veterán
Gratula!
! Deh igenis jar, sokan hasznaljak, legtobszor ertelmetlenul. Ha meg feltetlenul peldat is akarsz szolj me' kuldom (csak azrt nem most mert meg meg kell hogy keresem oket)Ne haragudj, de ilyen megjegyzések után szerintem jobb lenne, ha pihentetnéd a dolgot. Ha ennyire nem vagy tisztában azzal, hogy mi az az objektum, és mire használják, akkor nincs értelme vitatkozni, mert igazából azt sem tudod, miről vitatkozol.
-
#95904256
törölt tag
Pl. Van x mennyiségű memória egy gépben ami futtat egy rakás kódot és adatot. Egyszer csak betelik a véges memória, de újabb kódot/adatot kell behozni a RAM-ba, ilyenkor mit csinál a "tisztességes" OS?
Szerintem illene a nem / legritkábban / legrégebben használt adatokat, programkódokat a merevlemezen lévő swap-ba tennie.
Vagy küldjön egy üzenetet hogy: "Out Of Memory" ?
-
Kkocos
tag
Erre vonatkozoan tudsz egy eljarast amihez 1 gepre 2 operacios rendszert (Windows+Linux) feltehetek. Az elsodleges a Windows legyen. Ezt a particiot szerentem a tarolasra is hasznalni! Soha se probaltam FAT, vagy NTFS en kivul ket kulombozo particiorol Bootolni (nah persze nem 1ccere)?
-
Kkocos
tag
Szivesen fogadok barmijen kritikat. Deh legalabb arrol szoljon amit mondtam! "Az automatizalasra meg alljon itt egy pelda:", nem ide ketem a peldat. Ez pelda arra hogy a c++, mit objektum orientalt nyelv, rovidebb, kevesebb hibat megengedo modon is kepes kezelni a kodot. Hat sajna ennek az elenkezojet en nem alitottam, ide vonatkozoan azt mondtam hogy nem erdekel, nem fogom bonyolitani az amugy sem egyszeru eletemet evvel, nem vonz, nem szeretnem hasznali, nem szeretek megkotve lenni.
"Pl. a kod ujrafelhasznalasa alatt a forraskodrol van szo: hogy ne kelljen ugyanazt a kodot tobbszor leirni, hanem eleg legyen egyszer belerakni a base classba (haho, memoriamegtakaritas!). Valamint olyat sem mondtam, hogy nem teszi atlathatobbat a kodot (mar hat azza teszi a ketszintu strukturalassal (osztaly/metodus)), csak nem ez a fo szerepe."
Basszus, hol hoz itt ujat az OOP?
"Ha egyszer csak jobbra meg balra akarod forgatni, akkor irjal olyan kodot, ami jobbra meg balra forgatja. Meg egyaltalan, mi koze az OOP-nek ahhoz, hogy egy adott eljarast milyen bonyolultan irsz meg?..."
Beszaras, mondtam ma', ugyanazt irjam le meg 1szer csak mert nem olvasod el figyelmesen? Nem kertelek hogy olvasd el, de ha ma' reagalsz valamire, tudd hogy mire is irsz!
"Az OOP-vel nem jar egyutt semmilyen vizualis maszlag, gyakorlatilag az osszes C++ kodot a ket dolgos kezemmel potyogtem a szovegszerkesztobe, sot, a legtobb programnak egyaltalan nem is volt GUI-ja."
Gratula!
! Deh igenis jar, sokan hasznaljak, legtobszor ertelmetlenul. Ha meg feltetlenul peldat is akarsz szolj me' kuldom (csak azrt nem most mert meg meg kell hogy keresem oket) -
bambano
titán
A linux bemappeli a diszkeken levő libeket, ami majdnem ugyanaz, mintha beolvasná. Viszont kitolni nem tolja ki, mert eredetileg is diszkről szedte be, minek tolná ki vissza a libet, ami nem módosuló kódszegmens?
A windowsról nyilvánvalóan levezethető következtetésemet most hagyjuk
-
Eleg nehez am ugy vitazni veled, hogy lathatoan nagyon nem vagy kepben a vita targyat illetoen.
Pl. a kod ujrafelhasznalasa alatt a forraskodrol van szo: hogy ne kelljen ugyanazt a kodot tobbszor leirni, hanem eleg legyen egyszer belerakni a base classba (haho, memoriamegtakaritas!). Valamint olyat sem mondtam, hogy nem teszi atlathatobbat a kodot (mar hat azza teszi a ketszintu strukturalassal (osztaly/metodus)), csak nem ez a fo szerepe.
Az olyan ex cathedra kijelentesekkel, hogy "Az adtok ma' reg gatyaba vannak razva, OOP-nak semmi koze sincs hozza!", meg nem nagyon tudok mit kezdeni, azonkivul, hogy szinten ex cathedra kijelentem, hogy "de nem"Az automatizalasra meg alljon itt egy pelda:
C++:
void A::B(int p)
{
X o;
o.f(p);
}ugyanez C-ben:
void B(int p)
{
Xp ptr;
int res;
X_init(ptr);
X_f(ptr,p);
X_del(ptr);
}Latod, hogy mar egy ilyen rovid kodnal is mennyi gepelest meg lehet takaritani? Es itt nem csak arrol van szo, hogy ne kopjon el az ember ujja, hanem arrol, hogy joval kevesebb lehetoseg van a hibazasra.
"Pelda: Van egy motorod, amit vezerelni akarsz egy convertizoron keresztul. Irsz ra egy altalnositott procedurat, ami megenged tobb fele vezerlest is. De most teszemazt csak jobra/balra akarod forgatni, semmi egyebb kulonos parametrizalas nem akar vegrehajtani. Nah most a fugvenyedhez rendelt adatbazis merete sokkal nagyobb, mert az nem csak egy egyszeru funkciohozz lett megirva"
???
Ha egyszer csak jobbra meg balra akarod forgatni, akkor irjal olyan kodot, ami jobbra meg balra forgatja. Meg egyaltalan, mi koze az OOP-nek ahhoz, hogy egy adott eljarast milyen bonyolultan irsz meg?..."nem fogott meg az OOP, es a vele jaro vizualis maszlag elonye"
???
Az OOP-vel nem jar egyutt semmilyen vizualis maszlag, gyakorlatilag az osszes C++ kodot a ket dolgos kezemmel potyogtem a szovegszerkesztobe, sot, a legtobb programnak egyaltalan nem is volt GUI-ja. -
Kkocos
tag
Windows nem ezt csinalja?? Nekem pedig ugy remlik hogy a RAM-ban varakokozo kodot eleg rendszeresen kuldi ki, pilanatnyilag nem hasznalt dll-t, stb. Aztan meg varhasz mig ujra betolti ha szukseg van megint ra! De ha' nem is foglalhat RAM-ot epp hasznalaton kivuli kod, legyen az akrami
-
Kkocos
tag
válasz
#95904256
#77
üzenetére
A 10 ev
melett elbujhatok, marmint 10 eve meg nem is halottam a Stepx-rol. A lenyegegben egyetertuk , es nem csak a levegobe beszeltem. Gyari rutinrol nem beszeltem, az 1 teljesem mas vitatema, bele se megyek, sot altalaban nem is vita.
Nah itt ragadnam meg a lehetoseget , ha esetleg [link] erre latsz megoldast
-
#95904256
törölt tag
Lassan 10 éve használom a Step7-et, illetve programozok PLC-ket. A PLC-s programokat nem venném egy kalap alá a PC-s programokkal. Merőben mások a feladatok és az eszközök, az egy dolog hogy mindegyiken fut egy program...
A PLC-ken nem is erőltetném az OOP-t, hacsak az adott objektumokat nem tudja az ember rendszeresen felhasználni. ( Pl. több tíz vagy száz hasonló vezérlést kellene elkészíteni ). De legtöbbször ezek olyan egyszerű ( pár soros ) dolgok hogy inkább a megfelelő helyen beírja az ember vagy komplett gyári objektumot használ.
Viszont a gyári objektumokat ( pl. soros kommunikáció, motorvezérlés, stb. ) sokkal egyszerűbb használni mint írni egy saját rutint, amihez elég alaposan meg kellene ismerni az aktuális hardvert is...
-
Kkocos
tag
Most peldakat soroltam fel eroltetve a proceduralis programozast az OOP karara. Persze lenyegeben egy nem altalanosan ismert nyelvrol beszeltem (Step7) es ami nem egy kozonseges CPU-n (PLC S7 2xx,3xx,4xx) fut. Ez igy nem korekt. Deh hozateszem en se itt kezdtem. Mint mindenki vegigjartam a programozas szamarletrajat (Pascal-> C-> C++-> Matlab-> Delphi-> CBuilder-> Step7). Es tapasztalat annyi hogy 1-2 helytol eltekintve nem fogott meg az OOP, es a vele jaro vizualis maszlag elonye.
U.I. Varom azt a tenylegesen minden indokot megdonto ervet konkret peldaval megerositve ami vegleg a vadaszmezokre kuldi a proceduralis eljarasokat -
Kkocos
tag
"Az OOP elsosorban nem a kod rendezeserol szol: azt mar elotte rendberaktak nagyjabol. Ennel sokkal fontosabb volt a kod altal hasznalt adatok gatyaba razasa, a kod ujrafelhasznalas tamogatasa valamint az, hogy minel tobb dolgot automatizaljanak."
Tehat:
1. Nem szol a kod rendezeserol, amit ma' egyszer rendberaktam, Ok.
2. A kod ujrafelhasznalhatosagarol : hogy 1 procedura ami a RAM van feltoltve nins feltetlenul duplikalva ha a proceduralis programozast is valasztottam (nem sorol fell miert).
3. Az adtok ma' reg gatyaba vannak razva, OOP-nak semmi koze sincs hozza!\
4. Marad esetleg a kod "felhasznalasanak" az automatizalasa? Hogy az objektumok interfeszein keresztul konyen ujra meg ujra meghivhassam az objektumot?"Ez nem igy mukodik: a kod mindenkeppen csak egyszer van a memoriaban, akarhany osztaly (es annak akarhany peldanya) is hasznalja, az egyes objektumok konkret memoriahasznalatat leginkabb az adat tagok merete hatarozza meg."
Nekem a kodnak a merete igenis lenyeges, mivel eleg korlatozott egy PLC memoriaja. Tehat ha objektum orientaltam kozeledek a problemahoz, es egy altalanositott kodot irok minden subrutinhoz, az maga utan vonja a felhasznalt adatbazis meretenek exponencialis novekedeset, minnel inkabb szettagolt a problema, mivel minnel tobb a felesleges reszlet a kodban, aminek ugyancsak van memoriaigenye.
Pelda: Van egy motorod, amit vezerelni akarsz egy convertizoron keresztul. Irsz ra egy altalnositott procedurat, ami megenged tobb fele vezerlest is. De most teszemazt csak jobra/balra akarod forgatni, semmi egyebb kulonos parametrizalas nem akar vegrehajtani. Nah most a fugvenyedhez rendelt adatbazis merete sokkal nagyobb, mert az nem csak egy egyszeru funkciohozz lett megirva. Akadhatt olyan helyzett is ahol tobb fazisban is, kulonfele bemeno parameterekben kell hogy a fugvenyt meghivjad. Itt jelentosen megno a memoriaigeny. Ha pedig az objektumod szuloosztaja less egy masik osztalynak a memoria igeny exponencialisan novekszik.
Tehat tobb munkafazisodhoz adva van bizonyos bemeno parameterkovetelmeny, ami lehetoleg minnek kevesebb heyet fogaljon el a !!!(szo szerint) draga memoriabol. Nah most ha egyszerutol a bonyolultig hozol letre objektumokat, minnel komplikaltabb az igeny annal inkabb epitve befele a megoldasokat, ugye? Nah itt jon az hogy minek baszakodjal az objektumokkal, proceduralis szinten is eleg egszeruen megoldhatod, semmi ujat nem ad neked az OPP, szerintem pontosabann tudod rendezni az adtabazist nelkule, vagy mit is akarsz mast? Sot a programok fojamatosan novekvo memoriaigenye is OPP hasznalatahoz (nem csak hozza) is viszavezetheto. Senki nem tori az agyat az alapokon, csak felhasznalja az altalanositott objektumokat, nem torodve a novekvo memoriaigenyevel, sot az altalanositasbol adodo futasi ido megnovekedesevel, koszonhetoen a folosleges dolgok kizarasbol adodo fojmatos elenorzesel.
U.I : Meg nem lattam 1 konkret peldat se hol jonn ki az OPP elonye!! -
#95904256
törölt tag
Tehat valami olyam megoldasra gondoltam hogy neh oroklodjenek folosleges procedurak, ezket en programozaskor ki-be tudjam kapcsolgatni, neh toltsek vele foloslegesen memoriat, elore latva azt hogy ezekre futaskor biztosan nem lesz szukseg!
Szerintem felesleges lenne ezzel töltened az időt. Az OS úgyis elvégzi helyetted ezt a feladatot. A nem futó programrészeket vagy be sem tölti vagy előbb-utóbb kipakolja a RAM-ból a merevlemezre ha kell a hely.
-
"nem hogy csak nem tetszik az OOP, deh nincs is benne komoly (!!!gyakorlatilag nincs benne) tapasztalatom"
Magyarul te is tudod, hogy fogalmad sincs, hogy mirol beszelsz.
Az OOP elsosorban nem a kod rendezeserol szol: azt mar elotte rendberaktak nagyjabol. Ennel sokkal fontosabb volt a kod altal hasznalt adatok gatyaba razasa, a kod ujrafelhasznalas tamogatasa valamint az, hogy minel tobb dolgot automatizaljanak.
"Tehat valami olyam megoldasra gondoltam hogy neh oroklodjenek folosleges procedurak, ezket en programozaskor ki-be tudjam kapcsolgatni, neh toltsek vele foloslegesen memoriat, elore latva azt hogy ezekre futaskor biztosan nem lesz szukseg!"
Ez nem igy mukodik: a kod mindenkeppen csak egyszer van a memoriaban, akarhany osztaly (es annak akarhany peldanya) is hasznalja, az egyes objektumok konkret memoriahasznalatat leginkabb az adat tagok merete hatarozza meg.
-
Kkocos
tag
Igen, biztosan, mint ma' mondtam nem hogy csak nem tetszik az OOP, deh nincs is benne komoly (!!!gyakorlatilag nincs benne) tapasztalatom .Tehat valami olyam megoldasra gondoltam hogy neh oroklodjenek folosleges procedurak, ezket en programozaskor ki-be tudjam kapcsolgatni, neh toltsek vele foloslegesen memoriat, elore latva azt hogy ezekre futaskor biztosan nem lesz szukseg!
Ha letezik hasonlo akko' meg lehet hogy radokumentalodok, lassam hasznalni tom e? -
Kkocos
tag
Arra hogy tobb proceurra/fugveny ugyanavval a nevel, deh mas pramameterekkel legyen meghivhato. Tehata a bejovo parameterektol fugoen mas-mas operaciot hajtson vegre es mas eredmenyet adjon vissza .Persze erre van egy megnevezes is, valmi over... , nem jutt eszembe
Vagyis ez nem egeszem modosithato oroklodes!!! Ugyanaz oroklodik! csak epp nem talatam a megfelelo megnevezest -
Kkocos
tag
Ez nem feltetlenul a problema szetdarabolasa, sot en ugy latom hogy semmi koze sincs az OOP vagy proceduralis nyelvek kozotti vitara! Szerintem meg mindennek meg van a helye, es az nem feltetlenul az, ahol ezt az objektum orientalt nyelv tamogatja.
Nah most ha egy adott problemara akarsz valaszt adni valameik nyelvben, a problema magjahoz altalban nem lelsz kesz objektumot (ritkan, es altalaban valanien operator intefeszhez!!). Nah most te valasztasz! Sajat objemtumrendszert csinalsz es obbjektum orientaltan oldod meg, lenyegeben csak azert hogy masnak is atlathatobb legyen, vagy pedig sajat proceduragyujtemenyel probalod megoldast adni .Nah ekkor ma' a kerdes redukalidik csak az atlathatobsagra. Most ki mondja azt hogy ez ma' kevesbe atlathato?!! Sot!! Meg inkabb az, me' valakinek nem kell eloszor megtanulni a komponenseid strukturajat ahoz hogy atlassa, kijavitsa amit csinaltal!!
Nah mond hol lehet konyebben megoldani ugyanazt obiektum orientaltan, mint anelkul? Lenyegeben az egesz ojektum orientaltsagnak csak a program strukturajaban van jelentosege, a fugvenyeid maradnak, csak egy korlatozott modon kell oket meghivnod. Ez az egesz hasonlitt ahoz hogy hogyan epitsunk tombhazakat. Lehet a pneles szart is valasztani, mindent ugyanugy, lenyegeben klonozva megcsinalni, keves a varialhatosag. Persze a paneles rendszert is lehet, habar csak korlatozottan, deh varialni. Deh minek, ha ugy irod meg hogy ki-be lehessen tulajdonsagokat, fugvenyeket kapcsolgatni, azt az idot amit nyersz esetlegesen az objektum orientalsagall itt ma' joesetben csak elveszted, ha nem bonyolitod meg tul is a temat avval hogy az egesz szart ugy kell hogy megtervezzed, hogy modosithatoo legyen az oroklodes. Ha meg nem akko cipelsz magad utan egy csomo folosleges szart, amire nincs, es altalaban nem is lessz szukseg.
Hazat is jol varialhatoban kismeretu teglakbol lehet jol epiteni. Az objektumoknak mint mondtam legfenneb az operator interfeszben van letjogosultsaga, azrt mert oda egy magas szinten standardizalt interfeszre van szugseg, eloszor is me' feltetelezzuk hogy nem magasan kepzett emberek fogjak kezelni, masodszor mert gyors donteseket el esetleg hozniuk, nincs ido kivesezni a problemat!
Lenyegeben ennyi! -
bambano
titán
Én elhiszem, hogy látványos, meg minden, azt meg láttam a saját szememmel, hogy mi minden van már pl. jávában nagyvállalati cuccokhoz. Ettől még az nekem bonyolult.
A kattidekattoda cuccokkal meg az a baj, hogy lehet kattni, de egyszer beleszaladsz valamibe, amit a vizuálisagymenés nem úgy csinál, ahogy hitted róla és akkor finító van.
-
Akkor szedjuk kette a dolgokat:
1. Az, hogy sok es bonyolult koddal kell egyuttmukodni, az nem az OOP resze. Futottam ossze ilyennel sima proceduralis nyelvnel is, volt, hogy egy fel ev(!) utan jutottam el oda, hogy kodot irjak (es akkor ez meg viszonylag jo eredmeny volt).
2. Az OOP nem a legkezenfekvobb modszer. Ugy jott ki, hogy nagyjabol olyan sorrendben talalkoztam nyelvekkel, ahogy a programozasi paradigmak is fejlodtek (BASIC, Assembly -> Pascal, C -> C++, Java), igy ertettem, hogy milyen problemakra adtak megoldast. Addig, amig valaki nem fut bele az adott paradigma korlataiba, addig a kovetkezo siman tulbonyolitasnak tunhet. Ezzel tulzottan sokat nem lehet kezdeni, ha csak a budira akarsz kimenni, akkor a Concorde felesleges bonyolitasnak tunik. -
S.P.Q.R.
csendes tag
Teljesen egyetértek veled, valóban fenn áll az a gond sajnos, hogy j2ee-s porgam megírása nem kispályás ügy, és sokezer oldalnyi kód és specifikáció no meg oktatási anyag kell hozzá és nem árt pár év gyakorlat sem. Több hónap alatt szokták a programozókat j2ee-re oktatni nagyobb cégek, és elötte pl a szakirányu végzettséget meg is követelik, netán 1-2 év gyakolatot is, pont a fent említett dolgok miatt. Ugyankkor látni kell azt is, hogy egy nagyobb j2ee-s program mennyire komplex, ugyanez értendő a .net keretrendszer kontra c#-ra is. Rengeteg dolog be van építve, sokminden plusszt tud a rendszer, szóval nem árt ezekkel tisztába lenni, de az eredméyn nagy és látványos tud ezáltal lenni. Valamit valamiért elven
Ettöl függetlenül én sem kedvelem a katt ide katt oda desinerrel tervezd gui-t féle megoldásokra, pl amiket az MS visual studio-ja és a segédprogramjai kínálnak...De valaki erre esküszik, mondván fene akar ezzel is törődni. Nos én azt mondom ki-ki a saját íze szerint, illetve amit megkövetelnek tőle a cégnél.
-
bambano
titán
tanulási görbe. Hogy pl. c-ben vagy pascalban az első program megírásához nem kell olyan sokat tanulni, ezzel szemben ahhoz, hogy az első tisztességes jsp vagy java vagy j2ee programodat megírd, több tízezer oldal specifikációt illene rendesen elolvasni. Ez utóbbi probléma már a c++-os komponens könyvtárak és a c# esetén is fennáll szerintem.
És hiába a mindenféle kattintós vizuálbaromság, akkor is sok-sok hónap kemény munka kell ahhoz, hogy az első komoly programod elkészüljön.
Elfogadom, ez így nem teljesen oop, hanem oop alapú programozás + oop eszközrendszerek, de ettől még ez a véleményem.
-
Kkocos
tag
Nem feltetlenul kell tobb ezer soros procedurakat hasznalod ahozz hogy ne hurcold magad utan az objektumokat, rendezheted az egeszet konyvtarakba. A fugvenyek strukturalt meghivasaval pedig atlathato lessz a kod. Ez meg nem feltetetlenul hozza maga utan az objektum orientaltsagot. Szerintem.
-
shev7
veterán
em a program bonyolultsaga a lenyeges, hanem a merete. Van egy szint ami felett megfelelo tervezes nelkul kezelhetetlenne valik a kod, akkor is ha alapvetoen rem egyszeru dolgokat csinal. Ezen segithet ha OOP-t hasznalsz. Persze ha rosszul hasznalod akkor termeszetesen teher.
Volt egy DB kerdes. Errol erdekes lenne beszelni, en peldaul annyira nem vagyok kibekulve a j2ee-s, hibernate-es megkozelitessel, amikor az adatbazistablak es az objektumok kozott 1-1 megfeleltetes van. jobb szeretem amikor az adatbazis fuggetlenebb a kodtol. De tudom ez is az adott szituaciotol fugg, van ahol celszeru ezt a megkozelitest hasznalni.
-
Kkocos
tag
Melesleg mea culpa. Elnezest minden programozotol aki oop-t hasznal (ide most azokat sorolom aki nem csak oszedobalja Delphi-ben (ersd mint magasabb programozasi nylev) egy progit, es egy ugyahoz megtervezett adatbazist koordinal vele) hanem aki sajat (esetleg sajat teem) altal kidolgozott objektumokat hasznal.
Deh azert!!! Ha objektumokat hasznalsz (ersd mint atlagos programozo), hogy mered le a sorok szamaban egy program bonyolultsagat. Feljebb latam par 1-2 ezer soros kodreszekrol irva mint bonyolult. Hat igy ma' nekem is van keszen nemegy "bonyolult" programom. Nem az szamit hany soros a program. 90 szazalekban meg az sem hogy mien gyorsan futt, ha csak az ido nem egy kritikus szempont. Neha meg a memoria igenye sem lenyeges. Szerintem egy programm akkor bonyolult hogyha egyszeruen (ersd atlathatoan, folosleges elenorzesek, iterblokkolok nelkul) old meg egy bonyolult temat. Csak ranezel es maris latod hogy mit is akar (persze csak ha te a problemat is erted, maskulomben hogy is alhatsz neki a karbantartasahoz???) -
#95904256
törölt tag
A FSTCW+FLDCW+FISTP+FLDCW helyett van gyorsabb TRUNC() megoldás is, most nem ugrik be a teljes kód, régen használtam már. De azért a következő pár sor alapján szerintem kikövetkeztethető a működése:
FIST D[esp]
FILD D[esp]
FCOMPP
FNSTSW AX
TEST AH,xx
Jcc READY
SUB D[esp],1
READY:Ez még mindig kétszer gyorsabb mint a CW regiszter módosításával működő TRUNC().
-
#95904256
törölt tag
Még ha legegyszerűbb módon is hajtod végre a ROUND()-ot, de függvénnyel, akkor is ott marad a szubrutin hívás költsége, és igazából egy ilyen egyszerű függvénynél ez zavar. Mint megmutattad a TRUNC()-ot a Delphi is kifejtette "in-line", de az egyszerűbb! ROUND()-ot nem.
szimpla CALL+RET páros átlagos órajeligénye kontra FLD+FISTP órajeligény
( a CPU általi utasításvégrehajtásba / ütemezésbe most nem bonyolódnék bele, aki ismeri az arhitektúrákat az úgyis tudja hogy mi merre mennyi )
Core2: 18.4 / 9.0
K10: 25.4 / 11.7
K8: 25.2 / 10.6Megjegyezném a példádban szereplő esetben a ROUND()-ot így helyettesíteném:
MOV EAX,ESI
CDQ -
Kkocos
tag
Azert nem aszontam meg mielott mindenki teljesen ramragasztana hogy az oop ez fassag, csak az eredeti problemara reagaltam, mikent hogy lehet csokenteni a tulparametrizalt programok parametereitt. Nah ezert huztam volna parhuzamot az POP(mint OOP) es secvencialis (es nem feltetlenul proceduralis) programok koze. Mind a 2 ugyanzat meg tudja csinalni!!
-
Kkocos
tag
#dabadab : 10x a kioktatast tanaur!
Azert mielott teljesen leirnal, nem elotte utananezek hogy mi a turot is akar csinalni az a lokott program. Fent csak azt mondtam hogy neha nem kell nekiugranni bizonyos procedurak legyartasat, eleg ha csak felmerem hogy lehet megcsinalni, es nem baszakodok vele, ha van fontosabb dogom is, vagy eleg csak az hogy epp most nincs kedvem hozza.
Nah most tapasztalat. Itt igaz csak most alok ra a STEP7 (STL,csak me' jobban szeretem).(+2 ev nem sokk deh ma' nem kontar) -
P.H.
senior tag
válasz
#95904256
#46
üzenetére
Round()-ot nem hoztam fel példának, mert az összes Opt. Manual-ban az hozzák fel érvként, hogy a kerekítés az alapértelmezett FPU konvertálás integer-be (a 'la C).
i:=16;
atemp:=round(i);Delphi:
mov eax,$00000010
mov [ebp-$08],esi
fild dword ptr [ebp-$08]
call @ROUND...
@ROUND:
sub esp,08h
fistp qword ptr [esp]
pop eax
pop edx
retFLD/FILD Q[ESP]: float -> integer lenne a mondandó, ez pedig nem az.
Lehet hogy a trunc() nem a legjobb példa, mert én SSE3-as FISTTP-et használok in-line, ellenben a szintén in-line ( és valóban nem funkcióhívás ) Delphi / C trunc() megoldással. Ennek ellenére a FISTTP kontra FSTCW+FLDCW+FISTP(+FLDCW) kombó sebességbeli különbsége elég látványos. Ezzel csak az a baj, hogy én nem sűrűn találkoztam SSE3-képes géppel a célközönségünkben. És holnap annak fogok nekiülni, hogy egy virtualizált, 32 vagy 64 MB memóriával ellátott Linux alatti Wine-s környezet normálisan futtassa a programomat.
Én »jelenleg« SSE2 felett nem szoktam programot írni nagyközönségnek, mert nincs arra képes hardware (csak itthon). -
S.P.Q.R.
csendes tag
Hi
Az OO programozás lényege szerintem is, hogy a kódod átlátható keretbe foglalja. Pl függvénykeet, változóidat stb... Én sem tartom csodaszernek, viszont manapság erősen előretört talán a c++ és a java elterjedésének köszönhetően. Viszont többféle megfogalmazás is létezik ez ügyben, hallottam már olyat is idézem: " a c++ nem oo mert lehet használni szabad függvénykeet nincs minden osztályokba kényszeritve, szóval nem kötelező nem úgy mint pl a c#-ban" vagy a javaban. Amúgy nem egészen szószerinti idézet de ezt egy BME-n dolgozó c#-os kollgea modnta, aki nem 1-2 ezer soros programokat irt és nem egyedül, nos én nem értettem egyett mindennel, amit mondott(nem feltétlenül a fenti idézetre gondolok), de kicsinek érzem magam ahhoz hogy vitába szálljak vele.Következő kérdés: A projektben melyik fázisban és mekkora hangsúllyal tervezitek a db-t?
Tudom sok modern programnál ez alapvető jelentőségű(tisztelet ami nem használja)...
Amúgy örülök hogy ilyen szépen beindult ez a fórum remélem jókat fogunk itt még dumálni
üdv: S.P.Q.R. -
#95904256
törölt tag
Hm... Lehet hogy a trunc() nem a legjobb példa, mert én SSE3-as FISTTP-et használok in-line, ellenben a szintén in-line ( és valóban nem funkcióhívás ) Delphi / C trunc() megoldással. Ennek ellenére a FISTTP kontra FSTCW+FLDCW+FISTP(+FLDCW) kombó sebességbeli különbsége elég látványos.
Jobb példa pl. egy 64 bites lebegőpontos szám kerekítése ( round() ).
Ezt most szedtem ki egy C kódból:
PUSH ECX
PUSH ECX
FSTP Q[ESP]
CALL RoundDouble
POP ECX
POP ECX
...
RoundDouble:
PUSH ECX
PUSH ECX
FLD Q[ESP+0Ch]
FRNDINT
FSTP Q[ESP]
FLD Q[ESP]
POP ECX
POP ECX
RETEzzel szemben az alábbi négysoros jóval gyorsabb:
SUB ESP,08h
FISTP Q[ESP]
FILD Q[ESP]
ADD ESP,08hszerk.: Természetesen ezt a négysorost lehet makróként is használni...
-
#95904256
törölt tag
Milyen hely az, ahol a technikusok belepiszkalhatnak a dolgokba?
Pedig sok helyen megcsinálják. Nem mindenütt képesek kivárni míg a gép gyári szervíze a helyszínre érkezik. Szélsőséges eset, de előfordult már olyan is hogy hajnalban riasztottak egy bizonyos német cég viszonylag új masinájához, ami felmondta a szolgálatot. Mert ha tovább ácsorog akkor másnap egy bizonyos japán autómárka futószalagjáról nem fognak legördülni az autók. Mint kiderült egy egyszerű felfutó él figyelést kihagyott az illetékes programozó a programból. Mondanom sem kell hogy a bizonyos német cégtől is 8-10 órán belül megérkezett egy tag aki konstatálta hogy minden rendben van...
Valamint megjegyzném hogy idehaza elég ritka hogy 8-10 órán belül a helyszínre ér külföldről egy szervizes. Sokszor napokat is kell várni, így nem csodálom hogy néha egy-két termelésvezető vagy hasonló beosztású mondmeg ráuszítja az embereit a feladatra. Az megint más kérdés hogy többször okoznak kárt mint hasznot...
szerk.: Ja igen. Szervizest említettem, nem technikust. A legtöbb helyen a technikusok félnek hozzányúlni a dolgokhoz ( helyesen teszik ), viszont a mérnök emberek annál vérmesebbek.
-
P.H.
senior tag
válasz
#95904256
#40
üzenetére
Csak egy egyszerű példa: egyszer nézz bele, hogy egy Delphi hogy oldja ezt (truncate float -> int; Delphiben trunc() )
fld dword ptr [value]
call @TRUNC
...@TRUNC:
sub esp,0Ch
fstcw word ptr [esp+00h]
fldcw word ptr [cwChop]
fistp word ptr [esp+04h]
fldcw word ptr [esp+00h]
pop ecx
pop eax
pop edx
retEz mindennapos. Egy 1000-es nagyságrendű, trunc() eljárást hívó ciklus vagy sima rutin esetén is ez van. Nem adna gyorsabb kódot ezt egy InitTrunc() (fstcw+fldcw) - 1000-es ciklus (fld - fistp) vagy rutin - EndTrunc() (fldcw) három makróval megoldani?
Tudom, van Set8087CW Delphi-ben. Vajon megváltozik ettől a trunc() működése?Persze itt nem erről beszélünk, ez az Opt. Manual-ok témája inkább.
-
válasz
#95904256
#33
üzenetére
Milyen hely az, ahol a technikusok belepiszkalhatnak a dolgokba? Azokban a beagyazott rendszereknel, amikkel kapcsolatba kerultem, a technikusoknak sem kepzettseguk, sem lehetoseguk, sem jogosultsaguk nem volt ehhez. Oke, mondjuk egy CNC gep programja eseteben ezt el tudom kepzelni, de barmi rendes programnal?...
-
Tulajdonkeppen milyen POP nyelvet hasznalsz?... Es hogy tervezed meg az adatstrukturakat, ha nem igazan erted, hogy mit kellene csinalni?...
Ill. szerintem bonuszkent, mielott vki nagyon elkezdene osztani az eszt, vmennyire elmondhatna, hogy mekkora/milyen tapasztalata van, mert egy kicsit ugy erzem, hogy inkabb elmeletben ismered a kerdest
-
"mi az amit OOP-val meg lehet csinálni, vagy jobban meg lehet csinálni, mint normál függvényhívásokkal ?"
Tipikus peldanak szoktak hozni a GUI-t. Az tenyleg pont olyan dolog, amin remekul fekszik az OOP-hez.
Persze, lehet irnit GUI-t sima proceduralis nyelvben is (meg a vegen a C++-bol is gepi kod lesz), de annak ugy is az a vege, hogy az ember OOP programot ir olyan nyelven, ami ezt nem tamogatja, igy a programozo kenytelen kezzel elvegezni egy csomo olyan dolgot, amit OOP kornyezetben a fordito megcsinalna helyette.Ezzel ket problema van: egyreszt a programozo ideje draga (es ezt tessek szo szerint venni) masreszt utalnak ilyen felesleges hulyesegekkel foglalkozni, harmadreszt meg ember, igy tevedhet (lsd mellekelt abra
).Viszont ez, mint az igazi tudas altalaban, csak masok elmondasabol nem elsajatithato, igazan akkor fogod megerteni, ha majd te is beleszaladsz azokba a problemakba, amikre megoldast nyujt az OOP.
-
#95904256
törölt tag
-
P.H.
senior tag
válasz
#95904256
#35
üzenetére
SZVSZ elbeszéltek kissé egymás mellett.
shev7 azt mondja, hogy egy kódot azért nem érdemes egynél több helyen felhasználni közvetlenül, mert »ha« a kód hibás (vagy később módosítani, fejleszteni kell), akkor egyszerűbb egy helyen azt megtenni. Te azt mondod, hogy ha az a (matematikailag ellenőrzött, letesztelt, esetleg valamire kihegyezett stb.) végleges kód, akkor lehet többször is alkalmazni (ez hatékonyabb is), mert ha mégsem az, akkor úgyis újra kell az egészet írni, esetleg tervezni is.
A témához - és amivé vált - hozzászólva: egy jól megírt (hatékony, jól karbantartható) kód eljárásalapú kód előbb-utóbb az OOP-szemlélettel hasonló tulajdonságokkal fog rendelkezni (pl. teljesen mindegy, hogy valamit object.procedure(...) vagy procedure(object,...) alakban írunk, ha a végeredmény ugyanaz lesz; az öröklődés még inkább ilyen, ez szinte megkerülhetetlen; nem véletlen lett kidolgozva az OOP elmélete). Ez csak azon múlik, kinek mi áll közelebb a gondolkodásához. Az első dolog mindenképp az kell, hogy legyen, hogy megértsük a lényegét, azt, hogy mire jó, és mit várunk el tőle. Enélkül üres szövegelés a pro és kontra érv-felsorolás mindkét (OOP és POP) oldalról.
Én pl. nem fognék neki még ma sem OOP-programnak, egyszerűen képtelen vagyok úgy tervezni valamit, hogy annak a központja a feldolgozandó adat struktúrája legyen, ehhez igazítva a kódot, inkább a kódhoz igazítom az adatszerkezetet (talán itt a legnagyobb különbség a kettő között; és az előbbit nem hiszem, hogy csoportos fejlesztésnél meg lehetne tenni komoly kompromisszumok nélkül). De szinte az összes végeredményem teljesíti az objektum-orientáltság követelményeit. És innen visszanézve őket nem mondhatom azt, hogy bonyolultabb lett volna alapból objektumokra alapozva tervezni.
Ez csak szemléletbeli különbség SZVSZ. Van, aki azonnal nekiugrik leprogramozni egy problémát, van, aki hosszú órákat/napokat tud ülni felette, végiggondolva a lehetséges következő elvárásokat, továbblépéseket, a kód jövőbeli életét.
-
#95904256
törölt tag
Na most, feltételezem hogy te sem eleve hibás kódot akarsz írni, így a több helyre való kibontás meg a hibás kód nem ugyan az a kategória.
Valamit félre értettél. Feltételezted hogy a programozó olyan szervizterminállal kínálja meg a szervizest hogy abból minden kiderül és a komolyabb gondok is elháríthatóak. A gyakorlatban ez ritka, mert nem fizetik meg, nincs rá idő. A komolyabb balhéknál a szervizes rászorul arra hogy programozó által kellőképpen nem kicsiszolt programot megigazítsa. Bár legtöbbször csak gányolásnak nevezném ezt a műveletet. ( Tisztelet a kivételnek, mert van ilyen is! )
-
shev7
veterán
válasz
#95904256
#33
üzenetére
namost a rekurzio kibontasa, meg egy esetlegesen hibas kod tobb helyre valo beszurasa az nem ugyan az a kategoria
az meg hogy milyen modszerrel fejlesztettek egy programot, es a szervizes a szervizterminalon mit lat szerintem nincs kapcsolat... vagy valamit felreertettem a mondandodban.
-
#95904256
törölt tag
Azzal nem értek egyet hogy nem érdemes bizonyos kódot duplikálva leírni. Jártam már úgy hogy egy önmagát rekurzívan hívó algoritmust kibontva és pár dolgot itt-ott összevonva több mint 50-szeres (nem 50%-os!) sebességnövekedést értem el.
Ipari vezérlőknél meg kifejezetten jól jön mikor az ember szervizesként rákapcsolódik egy masinára és nem ütközik egy "objektum"-ba, hanem on-line minden állapotot és kapcsolatot átlát. Ezzel gyakran pár perc alatt kiderül a hiba, szemben az elegánsabb módszer több órás műtéti idejével. Ez egy olyan masinánál amelynek a termelési értéke óránként akár több száz ezer forint, elég hasznos tud lenni.
szerk.: Ennek ellenére plusz egy pont az OOP-nak, mert elegáns és több agymunkát igényel.
-
-
Kkocos
tag
Megirom en,csak meg varok 5letekre, talan valaki jobb megoldast mond,es addig nem kell hogy torjem vele a fejem, talan nem is hasznalom
Esetleg tudsz jobb megoldast az alapproblemara (csak memoria frisitesul nem tok ilyan gyorsan analog jelet beolvasni mint ahogy az valtakozik) -
vakondka
őstag
Akkor mondjuk csinálok egy osztályt adatbázis kezelésre és beleteszem a hozzá tartozó függvényeket, egy másikat form kezelésre...stb...?
Nem is akarom, hogy valaki itt tanítson meg nekem egy egyetemi félévnyi tananyagot...
...de ha esetleg tudna valaki egy linket küldeni ahol jó szájbarágósan le vannak írva az alapok azt megköszönném (magyar vagy angol)ui: PHP-hoz kellene
-
Kkocos
tag
Tanultam en az OOP-t eleg rendesen, csak a gyakorlatban meg nem igazan hasznaltam. Talan ha majd mas programjat kell hogy javitgassam hasznos lessz ha obijektum orientaltan van megirva. Amedig csak en golgozom egy programom, vagy csak nagyok kis mertekben hasznalok masok altal gyartot programreszleteket addig nem is torom a fejem rajata. Amit en csinaltam azt meg eleg rendesen atlatom.
-
shev7
veterán
ha most ugysem akarsz vele foglalkozni, es nem akarod megirni, akkor ezeket a dolgokat miert akarod most kitalalni?
MOD: nem kell minden osztalynak szulo osztalyt adni (nyugodtan szaramzhat az altalanos os osztalybol, interfeszt meg foleg nem kell neki megadni, ha nincs ra szukseg)
-
Kkocos
tag
Meglehet hogy nekem az objektum orientalt programozasban vannak viszonylag nagy tapasztalatsagom, deh ennek az objektumnak mi lesz a szulo objektuma, sot az iterfesze.
Ha fugvenyt hasznalok, sejtem hogy a bejovo parameterem egy adatbazis cime lesz , a kimeno pedig par integer, talan rogton analog jel. No probleno. -
amargo
addikt
Nem csak nagyméretű kódok megoldására hasznos az OOP, egy kis péda.
Szerk:
shev7 Aki nincs tisztában az OO szemlélettel szerintem sem érdemes ezzel vacakolnia, mert nem fogja kihasználni, nem ismeri és csak időt veszít vele. Ha úgy érzi meg akarja tanulni, vagy elvárás lesz felé egy biztonságosabb kód, akkor jobban elmélyed. -
shev7
veterán
de nem ertelek tovabbra sem. Van egy olyan pont a programodban ahol majd valamikor meg fogsz hivni egy midi lejatszot. De most meg nem, mert most nincs olyanod. Nem midegy, hogy a fuggveny nincs kesz amit meg kell hivnod, vagy az objektumot nem keszited el aminek a fuggvenyet majd meghivod? mitol bonyolultabb az egyik eset a masiknal?
-
Kkocos
tag
Nah latodd itt ma' nekem is gondjaim vannak. Nem tom, vagyis nem tom hogy oldanam meg ezt OOP-vel, vagyis ha mejebben belegondolok van megoldas, objektumokat gyartani a lejatszohoz az alapoktol, deh minek.
Melesleg felreertesz nincs nekem bajom az OOP-vel , lehet olyan problema ahol ez (leggalbi szerintem) tulbonyolitja a dolgot, meg lehet oldani nelkule is, meg ha a problema eleg kiterjedt is, neadj isten egy teem dolgozik rajat. Ma' emlitettem a peldat
Az alaposztalyba' vagy az alaposztalybol derival osztalyba. Normalis hogy csak egyszer irod a kodot, deh azt akarhonan meghivhatod, ha ugy csinalod , nem kell ahoz OOP -
shev7
veterán
biztos igazad van, csak nem igazan ertem, hogy mirol beszelsz. Mi az akadalya annak, hogy oop-ben a pillanatnyilag irrelevans dolgokat kihagyva programozz...
#18: mi az, hogy eleg ososztalyba kell beszurni? ez alapveto barmilyen programozasi szemleletnel, hogy amennyire csak lehet keruljuk a kodduplikalast, nem szurjuk be ugyanazt a kodot tobb helyre.
-
#17
fordfairlane
veterán
vakondka
#10
fordfairlane
veterán
mi az amit OOP-val meg lehet csinálni, vagy jobban meg lehet csinálni, mint normál függvényhívásokkal ?
Mindent meg lehet csinálni globális függvényekkel és globális vagy lokális adatszerkezetekkel, az OOP sem csodaszer. Ami az OOP előnye, hogy keretbe foglalja az adatszerkezeteket, strukturálja, csoportosítja a függvényeket, összerendeli az egymáshoz tartozó funkciókat és adatokat. Másképp strukturál, mint a procedurális programozás, ami elsősorban a megvalósítandó funkciókra koncentrál, nem pedig ezek szisztematikus rendezésére. Ez a módszer összetettebb feladatok megoldásánál jó, mert egyszerűbb programnál fejben is el lehet végezni a programszerkezet felvázolását. Az OOP-t egy konkrét program kapcsán csak akkor lehet jól kihasználni, ha a nyelv OO elemeivel tisztában vagy és rutinosan tudod őket alkalmazni, enélkül inkább csak hátráltató.
-
Kkocos
tag
Szerintem viszont lehet 1-2 dolgott kesobre is hagyni, peldaul olyan problemak megoldasat amit ma' masok megtettek mas nyelvekben, es eleg biztos hogy a kivant nyelven te is megtudsz irni. Ha csak alapszinten utananeztem hogy lehetseges ez, eldonthetem hogy ez a dolog megcsinalhato, ezt elkonyvelem es kesobre halasztom a megcsinalasat.
Nah hogy neh csak a levegobe beszeljek itt van egy konkret pedla. Most dolgozom egy egy progin amit SIMATIC S7-3xx PLC-re irok, Itt van egy problemam. Zenere kelene motorokat vezereljek. A gondom az hogy tul gyors a frecvenciavaltas, es a PLC nem tud Ilyen gyorsan AD converziot csinalni. Azt talaltam ki hogy nem is kell neki, nem WAV vagy MP3zenere fogg menni, eleg neki a MIDI is ,igy ma csak egy MIDI lejatszot kell hogy csinaljak. Nah ez ma' letekiz, nem igenyel gyors es bonyolult szamitasokat, tehat megirhato S7-ben is, most ma' atugorhatom ezt a reszt, kesobre halasztva.
Nah ha en most peddig objektumokat kelenne hogy gyartsak az eleg sokk idot elvenne, igy meg ma' rogton lephetek tovabb, vagy mast is csinalhatok amedig meg alaposabann dokumentalodok.
Nincs IGAZAM????
Bocs a duplazaseert!!!! -
Kkocos
tag
Szerintem viszont lehet 1-2 dolgott kesobre is hagyni, peldaul olyan problemak megoldasat amit ma' masok megtettek mas nyelvekben, es eleg biztos hogy a kivant nyelven te is megtudsz irni. Ha csak alapszinten utananeztem hogy lehetseges ez, eldonthetem hogy ez a dolog megcsinalhato, ezt elkonyvelem es kesobre halasztom a megcsinalasat.
Nah hogy neh csak a levegobe beszeljek itt van egy konkret pedla. Most dolgozom egy egy progin amit SIMATIC S7-3xx PLC-re irok, Itt van egy problemam. Zenere kelene motorokat vezereljek. A gondom az hogy tul gyors a frecvenciavaltas, es a PLC nem tud Ilyen gyorsan AD converziot csinalni. Azt talaltam ki hogy nem is kell neki, nem WAV vagy MP3zenere fogg menni, eleg neki a MIDI is ,igy ma csak egy MIDI lejatszot kell hogy csinaljak. Nah ez ma' letekiz, nem igenyel gyors es bonyolult szamitasokat, tehat megirhato S7-ben is, most ma' atugorhatom ezt a reszt, kesobre halasztva.
Nah ha en most peddig objektumokat kelenne hogy gyartsak az eleg sokk idot elvenne, igy meg ma' rogton lephetek tovabb, vagy mast is csinalhatok amedig meg alaposabann dokumentalodok.
Nincs IGAZAM???? -
shev7
veterán
pedig a fo koncepcio elhangzott. Nagymeretu kod sokkal jobban kezelheto, ha a kod osszetartozo reszeit osztalyokba foglalod. Az osztalyok a kivulrol "lenyegtelen" funkciokat elrejtik. Alap szinten itt ki is merul a koncepcio. Ha ez megvan, akkor lehet olyan extra dolgokkal foglalkozni mint oroklodes, interfeszek stb. De ez tipikusan olyan dolog amit egy forumban nem lehet 3 mondatban osszefoglalni. Nem veletlenul tanitjak az elmeletet egy fel evig az egyetemen
-
vakondka
őstag
az egy dolog, hogy nem értek hozzá...de nem könyveltem el róla, hogy "fasság".
Épp ellenkezőleg. Látom nap mint nap, hogy a profi programozók ezt használják és szerettem volna megérteni a fő koncepciót...de úgy látom ez ebben a topicban nem jön össze...
...biztos az én hibám -
shev7
veterán
"mi az amit OOP-val meg lehet csinálni, vagy jobban meg lehet csinálni, mint normál függvényhívásokkal ?"
Ilyen nincs. Nem azert lett kitalava, mert jobban lehet vele megcsinalni, hanem azert mert mashogy. A fejlesztest szamomra kenyelmesebbe teszi peldaul azzal, hogy az objektumon kivul nem relevans dolgokat elrejti.
ha semmi nem egyertelmu, akkor nem az oop-vel van gond, hanem a tudasod keves. Mikor elkezdtem tanulni en is felesleges bonyolitasnak lattam. Kerdesedibol ugy tunik, hogy te elkonyvelted magadban, hogy ez fassag, felesleges vele foglalkozni. Viszont amig alap szinten sem erted a koncepciot, addig erdemben nem tudunk rola beszelgetni.
KKocos: nem bantasbol mondom, de a megfelelo tervezes kihagyasa, csak egy bizonyos meretig kontrollalhato. Utana mar visszanyal a fagyi.
-
Kkocos
tag
A problema eleg egyszeru . Meg a tervezesi fazisban eleg magas szinten meg kell erteni a problemat, mert ha nem akkor akadhat olyan problema is ahol a modositas meg tobb modositast igenyel .Ez megnyutja a tervezesi fazist . En jobb szeretek a melyebb reszekbe kesobb belemerulni, igy hamarabb nekiulhetek a dolog legyartasahoz. es nem vesztek el csomo idot a tanulmanyozassal, lehet hogy amig tanulmanyozok kesobb elfelejtem. Most lehet hogy en vagyok a turelmetlen, deh ez nekem eddig bejott. Itt az OOP rol beszeltem.
A szekvencialis programozasnal nincs ilyen gond , akarmikor ujabb secvenciat szurhatok be,es ha legalabb 2-3 secvenciankent ugrokk az elejen ,a kkor nincs semmi gond a kesobbi modositasal, persze erre csak a program jobb atkathatosaga miatt van szukseg -
vakondka
őstag
én "a tervezes soran jol elkulonitem az egyes funkciokat" és per pillanat tök jól megvagyok objektumok nélkül...
mi az amit OOP-val meg lehet csinálni, vagy jobban meg lehet csinálni, mint normál függvényhívásokkal ?
(egyébként nekem az nem egyértelmű, hogy honnan hogyan lehet elérni az objektum változóit...van egy pár verzió és számomra teljes a káosz, hogy miért van ez így megbonyolítva...meg hogy működik ez az extend dolog...meg szóval semmi sem egyértelmű...)
-
Kkocos
tag
Ujabb szavazat az OOP ellen. Ma' ha kozbeszolhatok szerintem POP (Process Oriented Programing), mar ha muszaj obiektumokat letrehozni. Amugy leteznek nyelvek amik nem is tamogatjak az OOP-t. Legjobb tudomasom szerint a Matlab sem (pedig eleg eros nyelv) . Meg a sekvencialis programozastol nem teritettek el.
-
vakondka
őstag
Lécci röviden írd le hogy mi a jó a OO programozásban ?
Miért jobb ez mint a sima function-ok meghívása ?Már ezeregy tutorialt olvastam ezzel kapcsolatban, de nem látom az előnyeit,
csak a hátrányát...gondolom azért mert nem értem a lényegét...Előre is köszi a felhomályosítást
-
S.P.Q.R.
csendes tag
Hi!
Egy már meglévő topikban merült fel a kérdés, hogy a fejlesztők esteleg beszámolhatnának tapasztalataikról mind pozitív mind negaív értelemben. Továbbá általános jótanácsokat adhatnának mindenkinek, aki erre kiváncsi. Ez a topic nincs nyelvhez kötve, általános programozási ötleteket, eljárásokat, szemléletet stb.. leirását várom mindazoktól, akiknek ezzel tapasztalatuk van. Osszuk meg egymással jó és rossz tapasztalatainkat egyaránt, mindenki közös épülésére, beszéljünk múltbéli hibáinkról és jövőbeli terveinkről is.
Várom a kommeneket
üdv: S.P.Q.R.
Nem csak feltétlen sql alapú adatbázisokról, de érdekel a véleményetek a kül OO-s megoldásokról, illetve a mai világban egyre elterjedtebb(amit amúgy én is hazsnálok ahol tudok) XML-s megoldásokról.
! Deh igenis jar, sokan hasznaljak, legtobszor ertelmetlenul. Ha meg feltetlenul peldat is akarsz szolj me' kuldom (csak azrt nem most mert meg meg kell hogy keresem oket)
).
Aktív témák
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Yettel topik
- Fotók, videók mobillal
- Nyíregyháza és környéke adok-veszek-beszélgetek
- Miskolc és környéke adok-veszek-beszélgetek
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Renault, Dacia topik
- Sega, Nintendo - retro konzolok
- Brogyi: CTEK akkumulátor töltő és másolatai
- További aktív témák...
- Készpénzes / Utalásos Számítógép felvásárlás! Személyesen vagy Postával!
- GYÖNYÖRŰ iPhone 14 Pro 128GB Space Black -1 ÉV GARANCIA - Kártyafüggetlen, MS4022
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X 16/32/64GB RAM RTX 5060 Ti 16GB GAMER termékbeszámítással
- Samsung Galaxy Watch 8 44mm GPS Wi.fi
- HIBÁTLAN iPhone 15 Plus 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS4504
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest