- Xiaomi 13 - felnőni nehéz
- Samsung Galaxy A52s 5G - jó S-tehetség
- Galaxy Z Fold6-hoz viszonyítva mutatják, mennyivel lesz vékonyabb a Z Fold7
- Fotók, videók mobillal
- Yettel topik
- Eltűnhet a Dinamikus Sziget
- Xiaomi 15 - kicsi telefon nagy energiával
- Samsung Galaxy S23 Ultra - non plus ultra
- Honor 400 Pro - gép a képben
- Samsung Galaxy Watch6 Classic - tekerd!
Aktív témák
-
Kkocos
tag
válasz
Jim Tonic
#186
üzenetére
A velemenyemet lenyegesen arnyaltabba teszi ez, ahol nem igazan lehet objektumokrol beszelni.Ha az objektumok tulajdonkeppen standardizalt kodok, akkor viszont, a legritkabb eseteket leszamitva, gyari funkciokon kivul nincsenek objektumok. Ha pedig, es a legtobb esetben igy van, par soros kodot akarsz beirni, nincs is szukseged standardizalni, a kulon blokokk hasznalatat nem indokolja semmi, sot csak belasitanak es meg atlathatatlanabba teszik a dolgot. Ez meg inkabb igy van ha tobben is belenyulnak a kodba.
Persze, a legtobb PC-s nyelvek mar nem tudnanak OOP nelkul meglenni, de kivetelek itt is vannak (Matlab), ahol sokkal jobban boldogulsz funkcio meghivasos modszerrel, mivel a tipuskonverziok nincsenek tamogatva, pointerek nem leteznek, stb.
Tehat ha a felhasznalt adat rendezeserol, felhasznalasanak modjarol van szo, ugyanugy el lehet boldogulni, OOPval mint nelkule. SQL-re csak alapszintem van szuksegem. Minden mukodik, csak a HM interfeszhez es a komunikaciohoz hasznalok objektumokat, de nem ezek a lenyeges, ha ugy tetszik "dolgozo" reszei a programnak, a tobbire csak a renszerbe agyazashoz van szukseg.
Elsore ennyi -
Lortech
addikt
válasz
norbiphu
#184
üzenetére
Szerintem azt válaszd, amihez jobban értesz, mert inkább az határozza meg majd az alkalmazásod teljesítményét, nem a két platform közötti teljesítménykülönbség. Egyébként alkalmazásoktól függően elég változó az egymáshoz viszonyított teljesítményük, de nagyjából egyforma teljesítmény érhető el velük. Ahol esetenként nagyobb különbség van, az a gyári osztályok megvalósításainak különbségében keresendő. (általában)
-
Minél nagyobb programot írsz, annál inkább előnyhöz jut az OOP. Egy osztályt annyiszor veszel elő, amennyiszer akarsz, és elég mindössze a nevét tudnod.
Kevés nyelv van manapság, ami nem támogat OOP-t. Kevesebb, mint a másik oldalon.
Ha a plattform-függetlenségről beszélünk, akkor meg ott a JAVA, amire a többi nyelv nem igazán képes.Kicsit régi dologra feleltem, de csak azért tettem, mert anno én is pont ilyen szemellenzős voltam. Pár soros programot ma sem raknék osztályokba, de már megváltozott a véleményem.
-
bdav
őstag
válasz
norbiphu
#184
üzenetére
úgy tudom .net gyorsabb valamivel
átlag weboldalhoz tökmindegy, elég gyors mindkettő, ha rendesen csinálod + értelmes gépet raksz alá.
Amúgy ha jól veszem ki a kommentedből, ennél az alkalmazásnál úgyis az adatbázis lesz a szűk keresztmetszet, az meg szintén nem annyira a keretrendszeren múlik. Mennyi lenne az a sok adat? -
norbiphu
őstag
nem találtam a kérdésemnek jobb helyet, remélem itt választ kapok rá.
tud valaki egy .net vs j2ee performancet mutatni valamerre? persze az is jó, ha véleményezitek a témát
. egy darabot találtam msdnan, azt nem tartottam túlzottam mérvadónak. olyan weboldalhoz kéne amin sok (nagyon sok) adatbázisban tárolt adat van (felhasználói profilok sok adattal, események, fórumok stb). 
előre is köszönöm
-
-
cucka
addikt
a php szkriptnyelv, ezért egyrészt butaság a c#-al hasonlítgatni, másrészt kifejezetten előny olyan esetekben, amikor valami egyszerűbb feladatot kell gyorsan megoldani - csakúgy, mint mondjuk a perl-nél.
vagy csak én vagyok annyira perverz, hogy az általános script feladatok jó részét php-ban írom meg? -
Vico87
tag
Egyébként én is legszívesebben C#-ban fejlesztek manapság. Nekem jobban tetszik a Javanál, a C++ pedig tök jó, csak lassabb benne fejleszteni (nagyokat tud nézni az ember egy-egy lefelejtett apróság által generált hibák miatt, amire egy felügyelt kódban nem kell figyelni).
Egyetértek azzal, hogy PHP-ben a típusbiztonság nem éppen megoldott dolog (kifejezetten nem tetszett, amikor először láttam PHP kódot, nekem valahogy reflex, hogy van típus, egyébként ezért is tartom a JavaScriptet undorítónak). -
bdav
őstag
válasz
Protezis
#177
üzenetére
firebug szvsz kevesebbet tud azért, bár tény hogy nem rossz, használom énis (breakpointban nem vagyok biztos, lehet bele rakni?). mondjuk ezt úgy mondom hogy igazán a VS2008 lehetőségeit ne ismerem a téren, és a bugot ise 100%-ig
C# vs. PHP: egyszerűen az előbbit jobb nyelvnek tartom. olyannyira hogy a most népszerű programozási nyelvek közül a legjobb (Javanal okosabb, C++-t meg akkor használok ha van rá valami jó okom, mert tény hogy többet kell szöszölni vele). Természetesen elismerem hogy a php-vel össze lehet hozni nagyon komoly oldalakat (és .net / java-val nagyon rosszakat), de akkor sem szeretem. pl. típusbiztonság nem nagyon van benne, debugolni nehéz, és ha nem használsz valami keretrendszert akkor nagyokat lehet gányolni vele.
A Microsoft megoldása elég letisztult ebből a szempontbólmvc meg nem technológia hanem design pattern vagy architektúrális pattern leginkább. Az meg az alkalmazás íróján múlik hogy mennyire követi
MS amúgy valami hasonlót már elég régóta támogat (Document - View, konkrétan MFC az nagyon ilyenre készült anno)Az én álláspontom az hogy alapvetően amit mostanában produkál a Microsoft az elég jó. A programozási eszközeik 2005-től kezdve mindenképp (akkor volt hasonlóan nagy launch, VS2005, .net2.0, sql 2005). az, hogy nem az ő ötletük az annyira nem zavar, mert nem mondthatom hogy 1az1ben nyúltak, hanem próbálták az "elődök" hibáit kiküszöbölni + ez bevett dolog ebben a szakmában (Sun is nyúlt ám rendesen a C#-ból az új Javakba). És végül hogy az előadásuk közben mit vakítanak, attól maga a cucc még nem biztos hogy rossz
-
Protezis
őstag
JS debug: firebug (bar ezt a reszet nem igazan hasznalom, nem tudom miota tudja)
"asp.net az a megjelenítésért felelős elsősorban, az alkalmazás vezérlését valami c# kód csinálja. ez önmagában nagyon nagy előny a php-hez képest." - ezt nem teljesen ertem. Mi az elonye a php-val szemben? Ha tobbgepes rendszert akarsz, akkor a php nyilvan nem jo megoldas, egyebkent mindegyiknek megvan a maga elonye es hatranya (egyebkent php-t is lehet parhuzamositani tobb gepen, nem is 1 megoldassal, igaz ami igaz, ezek nem beepitett featureok)
A php-val mindosszesen azert hozakodtam elo, mert abban van tapasztalatom orm-et es mvc-t illetoen (amik az MS-nel uj, illetve bevezetesre varo technologiak).De ahogy eszreveszem, egy allaspontot kepviselunk, csak mondhatni te szemet hunysz a dolgok felett, en meg az eloadas utan kicsit kikeltem magambol. De kezd eltunni a hab a szambol, es megfogadtam, hogy legkozelebb inkabb itthon maradok
-
bdav
őstag
válasz
Protezis
#175
üzenetére
ezen a hozzáálláson nem kell meglepődni, minden nagy cég olyan tálalásban adja elő a saját cuccait, mintha az lenne a világ 8. csodája. nem a marketing szöveget kell nézni, hanem a mögöttes tartalmat.
JS debug: én VisualStudio 2008 előtt nem láttam olyat ami hasonló szinten tud js-t debuggolni mint ez (breakpoint a js-be pl.)
asp.net az a megjelenítésért felelős elsősorban, az alkalmazás vezérlését valami c# kód csinálja. ez önmagában nagyon nagy előny a php-hez képest.
-
Protezis
őstag
"PHP azért messze nem egy kategória egy .nettel" - valoban nem, de ha az asp.net-et nezzuk (vagy akarmi is a pontos neve), akkor a ket dolog celja ugyanaz: webes kiszolgalas.
Mostmar vegleg felszivodott bennem az a gondolat, hogy az MS talalja ki az uj dolgokat, vagy akar csak reszben. Sajnos viszont sok ember azt gondolja, hogy wow, linq, mvc, js debug, ezaaaaz. Kozben meg ezeket masok mar reg hasznaljak. (emlitett olyat az eloado srac, hogy js-t eddig nem lehetett debugolni
)Ha ugy zajlott volna az eloadas, hogy ez es ez az orm, erre valo, az MS megvalositasat linq-nak nevezik, es igy mukodik..., egy szavam nem lenne. Nem ezeknek az eszkozoknek a letjogosultsagat, hasznossagat vitatom, hanem a koritest, amivel talaljak oket.
sghc_toma: koszonom!
-
sghc_toma
senior tag
válasz
Protezis
#172
üzenetére
egy mondatra reagálnék az írásból, erre:
Hogy az MS miert tartja komplexebbnek, bonyolultabbnak az opengl-t, mint a directx-et, arra nem jottem ra.a körítés miatt, gondolom.. legalábbis én amiatt tartom egyszerűbbnek a Direct3D-t.. pl. van kész vektor, kvaternió, textúra, vertex buffer, mesh, stb. osztály.. aztán az fx file-ok: szerintem sokkal egyszerűbb kezelni, mint az OpenGL vertex- és fragment shadereit.. úgy összességében kényelmesebb használni..
-
bdav
őstag
válasz
Protezis
#172
üzenetére
igazándiból a Microsoft elmúlt 2 évi fejlesztéseit nem igazán követtem, csak demo szinten láttam belőle dolgokat.
írásodhoz: PHP azért messze nem egy kategória egy .nettel
JavaScript debug az egy marha hasznos dolog + az is jo alapvetően hogy valami keretet tesznek az Ajax alá.
linq: orm az valóban nem egy új ötlet, és mondjuk a Hibernate - EJB3 Entity féle megoldás nekem jobban bejön. de valami ilyesminek a megvalósításával már adós volt a Microsoft egy ideje, pont amiatt hogy Java világ már tudja
-
Protezis
őstag
Ot eves egyetemi kepzest nem szabadna erre alapozni.
Mindenki: Miert jobb szalak helyett processzeket hasznalni? Ha a biztonsag a lenyeg, vagy akar tobb gep kozott akarjuk elosztani a feladatokat, akkor nyilvan processzeket kell inditani (mondjuk PVM), de ha egy felhasznaloi program idoigenyesebb reszet akarjuk parhuzamositani (1 gepen), akkor a szalazas elonyosebbnek tunik szamomra.
-
bdav
őstag
válasz
Protezis
#166
üzenetére
app szerver (akár .net akár java) párhuzamosítás nem arról szól hogy ilyen számítási műveletek kellenek. Ezek üzleti szoftverekhez készültek és pl. egy session beanból kifejezetten nem szabad szálat indítani. Itt ipikusan nem számolsz sokat. És amikor elmész programozó melóra, többségében ilyenek lesznek.
-
P.H.
senior tag
Protezis #163 és #166
A "túlmisztifikálás" kicsit erős volt, nem tagadom, de nem sokkal több az elméleti háttere, mint amit leírtam, az alkalmazása az adott szituációtól függ (és jó úton indultál el #166-ban: képzeld mondjuk ezt el egy 3x3 helyett 3000x3000-es mátrixra, egy vs. több szálon). Elméleti síkon (oktatásban) arra lehet elmenni nagyon messzire, hogy critical section-ök, összehangolás (amik közösadat-elérésnél mindig előjönnek, lásd adatbázisok), de tervezési fázisban ezek száraz tények, megvalósítási megközelítésben sem annyira fontos annyira ez, csak az OS-adta segítségek ismeretéig.
Egy példa:
A korábbiakban felmerült ebben a topikban a Dijkstra-algorimus. A legtöbb idő és energia azzal megy el, hogy megtaláld ezt és az ehhez kellő adatábrázolást, mint ideális megoldást az adott problémára. Magát az alapalgoritmust épeszű embernek nem jutna eszébe párhuzamosítani, mert többet veszt vele, mint nélküle. Viszont ha a - kapcsolatokra - alkalmazandó dinamizmus sokkal összetettebb és időigényesebb, mint amennyit a leírt alapadminisztráció megkövetel, akkor érdemes lehet elgondolkodni azon, hogy az épp feldolgozott ponthoz csatlakozó élek végleges súlyát ne párhuzamosan számoltassuk-e ki (a tárolás mellett többek között ezért fontos a listás gráfmegközelítésnél, hogy a lehetséges maximális kapcsolatszám egy ponthoz ismert-e).(Emlékszem persze - 0 amúgy
-, de nem akarok se szembemenni, se megerősíteni azt az oktatási nézőpontot, amiben én voltam: sok jót tudok mondani róla, de sok rosszat is; egyrészt a tanultak legalább 80%-át hasznosítottam azóta - mégha azt is gondoltam akkor, hogy erre nekem semmi szükségem nem lesz soha -, másrészt megtanított arra, hogy csak a specifikációknak higgyek, bármiről is legyen szó). Minden algoritmus megoldható egy szálon, maga a "programozás" talán arról szól, hogy a probléma és annak megoldása adott és kézzelfogható legyen. Hogy hogyan lehet »hatékonyabban«, az más megközelítés .dabadab #165 és #167:
Szál és process összehasonlítás SZVSZ nem ilyen egyszerű. Több szál azonos virtuális címtartományban fut egy process-en belül, ergo közös memóriájuk van, azonos adatterületen - főleg forrásadatoknál fontos ez - dolgozhatnak nagyjából kis ráfizetéssel (#166), de tényleg sok hibalehetőséggel (ezen a téren a CPU-gyártók is követettek el hibákak). A process-ek közti adatáramlás sokkal költségesebb, bonyolultabb (jellemzően file-alapú), viszont úgy látom, a világ mégis az előbbi felé halad (de leszögezem, a Linux lelki világát nem ismerem). Erről a Windows-os urban legend-ről még nem hallottam (de erről lehet szó itt is), de mégis arra haladnak a CPU-k, hogy azonos process-ben futó szálaknak minél kevesebb felesleges hátráltatást okozzanak task-váltáskor (gondolok itt AMD TLB-k esetén az Address Space Number-re, és Intel-nél a Hyperthreading-re és a speciálisan erre - nem csak alap több processor-ra - felkészített/optimalizált programokra is); pl. egyre fontosabb, hogy azonos process-hez tartozó szálak ne dobják ki a TLB-k és így az L1 cache-ek teljes tartalmát (amit tényleges process-váltásnál valóban meg kell tenni).
-
dabadab
titán
válasz
Protezis
#166
üzenetére
Ha hihetunk a varosi legendanak, akkor szalak egyedul azert vannak mindennapi hasznalatban, mert (es ez a resze tenyleg igy van) a Windows schedulere tul sokat pocsol(t) a processzek kozti kontextusvaltassal. Akar hogy is, mostanaban az a divatos elkepzeles, hogy a parhuzamositast szalakkal oldjak meg, nem processzekkel, ami joval tobb gond es hiba forrasa, mint amennyit egyszerusit a kommunikacion.
-
Protezis
őstag
"Meg mondjuk szerintem udvos lenne vegre leszokni a szalakrol es megint szep, tisztesseges processzeket hasznalni, tessek vegre rendes schedulert irni a Windowsba is" - ez erdekelne.
Egy processz ugye tobb szalbol allhat. Ezek a szalak - mivel egy processzen belul futnak - osztaznak az eroforrasokon, elerik ugyanazt a memoriateruletet. Mig processzek kozott nincs ez a szoros kapcsolat. Nem ertem, miert akarsz megszabadulni a szalaktol, amikor ha jol emlekszem a tanultakra, nem egy sulycsoportban vannak?!
Egyebkent meg most is indithatsz tobb processzt.Elobbiekhez: Parhuzamositasra pelda, ami ma jutott eszembe. Egyik jelenlegi kot.progomban matrixokat forgatok. Totalisan parhuzamosithato. Persze lehet, hogy semmi ertelme egy 3x3-as matrixnal inditani 9 szalat, de nem is ez a lenyeg, hanem az, hogy amikor megirtam a muveletet, eszembe nem jutott volna ez. Es ez a gond. Nem neveltek ra, hogy ha lehetoseg van ra, hasznaljam. Es ezt bizony nem parhuzamositja nekem automatikusan se a .NET Fw, se a Java VM.
-
dabadab
titán
"amúgy szvsz ma ha valaki programozónak megy, akkor meló közben 80% hogy nem fog saját maga párhuzamos szálat kezelni"
Nyilvan egy szal magamban nem vagyok tul reprezentativ pelda, de en eleg rendszeresen osszefutok azzal, hogy nekem kell tobb szalat programoznom. Igazabol debuggolni rossz nagyon, mert attol fuggoen, hogy az OS-nek epp' hogy sikerul idozitenie a szalakat, vagy elojon a hiba, v nem (vagy egy masik jon elo
).Meg mondjuk szerintem udvos lenne vegre leszokni a szalakrol es megint szep, tisztesseges processzeket hasznalni, tessek vegre rendes schedulert irni a Windowsba is
-
bdav
őstag
válasz
Protezis
#163
üzenetére
hát nekem nem volt párhuzamos programozásról kifejezetten tárgyam, de a problémakör elméleti síkon több helyen is előjött. sőt csináltam párhuzamosítást, java tárgy keretében, mert kellett
de az primitív volt.amúgy szvsz ma ha valaki programozónak megy, akkor meló közben 80% hogy nem fog saját maga párhuzamos szálat kezelni, mert elfedik előle a ma használt vállalati eszközök (ejb, .net ha úgy használod). ami felmerül az a "több-kliens ugyanazt az adatot bizgeti" probléma, amire szintén van aránylag jó megoldás (tranzakció), de itt azért néha gondolkozni kell hogy akkor most mivan.
-
Protezis
őstag
Miert tetted OFF-ba? Szerintem nagyon is ide tartozik.
Nem misztifikalom tul, legalabbis nem ez volt a celom. Amiket leirtal, azokrol mind tanultam mind elmeleti, mind gyakorlati sikon (Occam, Java). Ettol fuggetlenul peldaul volt olyan, hogy algoritmusok es adatszerkezetek tantargy kot.programjanal ki volt kotve, hogy nem lehet tobb szalat inditani
Es most tekintsunk el attol, hogy adott esetben celszeru lett volna, vagy sem.Raadasul ha visszaemlekszel (ha vissza kell, nekem nem, en meg egyetemista vagyok), akkor azokon a programozos orakon, ahol nem a parhuzamos programozas volt a kozeppontban, meg tudod mondani, hanyszor lattal/irtal tobbszalu programot? En igen: 0.
-
P.H.
senior tag
válasz
Protezis
#160
üzenetére
"Bar volt ilyen szakiranyos tantargyam, szerintem a jelentosegehez viszonyitva keveset foglalkoznak vele egyetemen."
A párhuzamosítást nem kell túlmisztifikálni, inkább csak megvalósítási, mint tervezési szemlélet, az algoritmus természetén múlik, hogy lehet-e egyáltalán, illetve ha lehet, hogyan lehet így megközelíteni.
Alapvetően két szemlélet lehetséges:
- a feladat több, egymástól független részfeladatra bontása: pl. ha egy kép átméretezése a feladat, akárhány részre (~szálra) bontva meg lehet tenni, a darabok függetlenek egymástól, lehetőség van közvetlen forrásmemóriából célmemóriába való feldolgozásra.
- több soros feldolgozási lépés van (kb. így működnek a médialejátszók), gyakorlatilag egy pipeline-on mennek keresztül az adatok: pl. adatkitömörítés->dekódolás->szín-hang konverzió->átméretezés. Egy-egy szálon egy-egy ilyen lépcsőfok fut, amelyek között ideiglenes bufferek (vagy ezek rendszere) tartják a kapcsolatot.
Lehet még beszélni a szinkronizációk elvéről, közös adatterületek elérési szabályairól, de sokkal több nincs benne.Amire nem lehet ráhúzni valamelyiket, azt nem lehet párhuzamosítani; és algoritmuselméleti szempontból az ilyen párhuzamosítás csak konstans lineáris gyorsulást hoz, tehát elméleti megközelítésben "meglehetősen unalmas" (soha nem okoz pl. NP->polinomiális vagy polinomiális->logaritmikus időigény-csökkenést), bár bír gyakorlati jelentőséggel (mivel irreális időigényű algoritmusokat úgysem programoznak le általánosan közzétéve).
-
doc
nagyúr
válasz
Protezis
#160
üzenetére
ez jo otlet, koszi!
igen, nalunk is csak egy felev parh.prog volt (valami pascalfc vagy hogy hivtak azt a nyelvet), ami epp' csak arra eleg, hogy az embernek nemi halvany fogalma legyen szemaforokrol, meg ugy altalaban a problemakrol amik elojohetnek, de tenyleges mt programozashoz keves volt
emlekszem, az elmeletre ugy kaptam meg a kettest hogy "na most az egyszer megadom", a gyakorlati vizsga meg ugy tetszett a tanarnak, hogy ott huldezett hogy hu de jo, jajj de jo, aztan mikor latta hogy milyen lett az elmelet, azt mondja: "nagy baj lenne ha csak harmast adnek?" mondom nekem nyóc, nem kell a kredit -
Protezis
őstag
"esetleg van még ötletetek, hogy milyen témákkal érdemes foglalkozni?" - huhh. Mindennel erdemes, de mivel nem adtal meg temakort, ezert modok olyat, ami sok helyen elojon: multithreading
Bar volt ilyen szakiranyos tantargyam, szerintem a jelentosegehez viszonyitva keveset foglalkoznak vele egyetemen.
-
doc
nagyúr
válasz
Protezis
#158
üzenetére
köszi mindkettőtöknek
a gond az, hogy nem írtam még olyan programot, ahol ez tényleg hasznos lett volna (vagy csak nem jöttem rá)
de majd befalom a könyvet, igyeXem megérteni, aztán a végén még Qrva okos leszek
esetleg van még ötletetek, hogy milyen témákkal érdemes foglalkozni? a Design Patterns is úgy jutott eszembe, hogy láttam pár álláshirdetésben, gondoltam csak megnézem már mi ez
tervezem még alaposan belemerülni a QT-be, idővel az OpenGL-be, de hirtelen nincs más ilyen jellegű ötletem -
Protezis
őstag
Akkor hasznos, ha garantalni akarod, hogy egy adott osztalybol csak 1 objektumod lehessen. Tipikusan adatbaziskapcsolodast megvalosito osztalyok eseten hasznalatos (meg persze rengeteg mas helyen). Olyan, mintha csinalnal egy globalis valtozot (egeszen pontosan egy globalis valtozohivatkozast, vagyis objektumhivatkozast... ehh), csak az nem tul szep megoldas. "Peldanyositaskor" pedig nem kell arra figyelned, hogy van -e mar olyan tipusu objektumod, vagy sem, a pattern elfedi eloled.
Az elozo OFF wolf7191 kolleganak ment
-
dabadab
titán
"(tudom mire val, de hogy miért jobb, mint simán használni egy class-t, az még nem esett le)"
A singleton azert jobb, mint a globalis valtozo (ill. objektum), mert egyreszt az inicializacio csak akkor fut le, amikor tenylegesen szukseg van ra, masreszt meg azert, mert nem globalis valtozo
-
doc
nagyúr
-
Protezis
őstag
Szia!
Singleton patternt rendszeresen hasznalok, egyszeru es nagyszeru
Ezen kivul hasznaltam factoryt, valamint elmeleti (ill tervezesi) sikon flyweight mintat. A tobbivel nem nagyon volt meg dolgom. Nagyjabol a felenel jarok az Erich Gamma fele konyvnek, es arra jottem ra, hogy eleg sokat kell hasznalni egy mintat, hogy igazan megertsd es a megfelelo helyen hasznalni is tudd. Az a legtobbszor nem megy, hogy adott problema eseten felcsapod a konyvet, es a tartalomjegyzeket vegigbogaraszva keresel egy szimpatikus mintat: 1 ora, mire felfogod, meg 1, mire nagyjabol megerted, miert is jo az, aztan meg 1, mire rajosz, hogy nem is az kell neked Es netan ezt akarod leprogramozni? Nezd meg a bongeszod cimsorat.
A forumban fent keress ra: ip, de tudod mit? Tessek! -
wolf7191
csendes tag
Sziasztok! Nem tudom mennyire vág a témába. De ti biztos többet tudtok erről mint én!
Nekem egy olyan problémám lenne, hogy regisztrálva vagyok az elitware.net oldalra, ahol sok jó dolgot lehet letölteni (film, zene, egyéb)
Általában minden több részeletben van rar formátumban. A bajom az, hogy egy részletet engedélyes letölteni, utána 90 perc szünetet kell tartani, mert többet nem engedélyez ingyen.
(http://rapidshare.com) Az IP cím alapján azonosítja, hogy töltöttél -e le már. nem tudom, hogy lehetne ezt kijátszani. Lehetséges ez valahogy -
Vico87
tag
válasz
S.P.Q.R.
#147
üzenetére
Hát ez tényleg attól függ, hogy mit programoz. Mert aki világ életében ügyviteli rendszerekkel foglalkozott, annak elég a négy alapművelet, aki viszont pl grafikával, annak óhatatlanul kell a gráfelmélet, lineáris algebra, geometria, stb...
Szerintem a középiskolás anyag a minimum, ami ajánlott programozáshoz, mert az már elég arra, hogy viszonylag sokféle problémát legalább alapszinten ismerjen az illető. -
S.P.Q.R.
csendes tag
Nah minekutána volt itt már szó algoritmusokról szerintem óhatatlanul felvetődik a kérdés, igazából egy programozónak mennyire kell jónak lennie matematikából?
Tudom ez kicsit tág kérdés szal inkább pontosítok, munkája során ki mennyire használja az analizist, esteleg a statisztikát valszámot, operációkutatást, halmazelméletet(ezt szerintem sokan) kriptográfiát, mátrixokat, mod 2-es algebrát stb...
Illetve ha te lennél XY egyetem rektora a mai informatikusoknak(főként a szoftverfejlesztőknek) melyik tárgyakat tartanád ezek közül a legfontosabbaknak?
üdv:
S.P.Q.R. -
S.P.Q.R.
csendes tag
Nem vitatozni akarok, én se használok főként mert ez egy elméleti modell amit algoritmusok vizsgálatához használnak fel(persze valóban épiteni lehet ilyen gépet). Használható továbbá annak bizonyitására, hogy léteznek algoritmikusan nem modellezhető problemek. Szal nem igaz az amit a 30-as évekig hittek: "midnen megoldható csak eleget kell rajta tökölni"
Én csak ebböl indultam ki, ennyi -
S.P.Q.R.
csendes tag
Ezzel vitatkoznék erősen. Vannak ugyanis algoritmikusan eldöntetlen/algoritmikusan nem modellezhető problémák.
Amelyekhez Nem tudsz olyan Turing gépet késziteni ami biztosan megáll!
És van ilyen
(Post probléma valamikor a 30-as években jöttek rá)
És vannak számitástechnikai szempontból kezelhetetlen algoritmusok is.
idézek:'A kezelhetetlen probléma definíciója
- Azok a problémák amelyek a futási idő
tekintetében a feladat méretének
exponenciális függvényével jellemezhetők,'
itten va hozzá egy jókis jegyzet, amiből a fenti idézet jött...
http://mokk.bme.hu/mediatervezo/targyak/programozas/media5_2.pdf
mindenkinek jó programozást meg fórumozást:
S.P. -
S.P.Q.R.
csendes tag
Bár kicsit brutálabb problémákat meg kell nézni hogy egyáltalán megoldható-e hatékonyan vagy létezik-e rá egyáltalán vmi. algoritmus.
Lásd Turing gépek,
http://www.kfki.hu/chemonet/TermVil/kulonsz/k002/algoritmus.html
Erröl jut eszembe P=NP?:S
már láttam anno a bme-n ilyen pólót is -
#141
Vico87
tag
kicsitomi88
#139
Vico87
tag
válasz
kicsitomi88
#139
üzenetére
Ha ez már egy "hogyan / hogyan ne programozzunk" topic, akkor leírom, hogy mindig érdemes algoritmuselméleti könyvben megnézni, ha valamire szükségünk van algoritmusra, ugyanis ha van benne, akkor nagy valószínűséggel jobb, mint amit mi találnánk ki, és még meg sem kell erõltetni magunkat (és így mindenki jobban jár).
Egy pár "híres" algoritmus:
gráfok : Dijkstra, Floyd, Bellman-Ford
rendezés : beszúrásos, összefésüléses, gyorsrendezés, kupac
keresés : lineáris, binárisEzekhez persze "járnak" adatszerkezetek is. És még egy tanács : ha algoritmusról van szó, akkor biztosan nem az elsõ gondolat a helyes
. -
#140
P.H.
senior tag
kicsitomi88
#139
P.H.
senior tag
válasz
kicsitomi88
#139
üzenetére
"Miert is erzem ugy, hogy ezt elobb tanulni(tanitani) kene mint csinalni(feladni otthonra)..."
Ez azért árulkodó: nehogy túlbonyolítsd! Ebbe a hibába sokan beleesnek. Csak azt oldd meg, ami a feladat.
Ha ez túlmutat azon, amit eddig tudsz/tudnod kellene, érdemes megkérdezni még egyszer, hogyan értették; lehet, hogy nem is az a feladat, amit gondolsz.Bár az olvasgatás nem árthat meg
-
#139
kicsitomi88
őstag
P.H.
#138
kicsitomi88
őstag
Nagyon köszönöm mindenkinek a valaszt, csak annyi gondom van, hogy az eletbe nem csinaltam meg hasonlot sem.
Tehat ha jol gondolom a feladatom az, hogy a szokott modon beolvasott adatokat egy elore kigondolt adatszerkezetbe helyezzem el amin vegrehajthato a dikjstra algoritmus. Miert is erzem ugy, hogy ezt elobb tanulni(tanitani) kene mint csinalni(feladni otthonra)...
Na jolvan, azt hiszem most egy kis olvasgatas jon a listas szerkezetrol.
-
#138
P.H.
senior tag
kicsitomi88
#134
P.H.
senior tag
válasz
kicsitomi88
#134
üzenetére
Szegedre jársz - ha nem tévedek -, gondolom, az Algoritmusok és adatszerkezetek tárgy ismerős (lesz, másodév). Oda az azonos című, részben helyi szerkesztésű könyv alapvető (nagy, fekete az a kiadása, ami nekem is megvan), abban nézz körül pl.
Ahogy írták is, a két alapvető gráftárolási megközelítés a mátrixos és a listás. Pár pro és kontra mindkettőre:
Mátrix-alapú:
- az adatszerkezet mérete exponenciális a pontok számával, mivel minden pont-pont kapcsolat helye - ha nem is lézetik ilyen - szerepel benne, ezért sűrű gráfok esetén érdemes alkalmazni
- Ha a kapcsolatoknak/éleknek több tulajdonsága is van (nem csak a hossza), akkor több, párhuzamos mátrix vagy nagyobb elemi mátrixelem-méret szükséges
- nagyon hatékony algoritmusok vannak a legrövidebb utak meghatározására (ebből érdemes kiindulni amúgy, az összes lehetséges még könnyű, a többi eléggé elbonyolítható), de nehéz dinamikussá tenni.Lista-alapú:
- nagyon hatékony adattárolási forma ritka mátrixokra: felsorolod a pontok mellé, hogy mely pontokkal állnak kapcsolatban
- viszont általános megoldásokban egyik kulcsjellemzője az egy ponthoz tartozó maximális (előre látott) lehetséges kapcsolatok száma, ennek változásával a hozzá tartozó algoritmusok is jelentősan változhatnak
- kézbentarthatóan (= lineárisan) skálázódik az erőforrásigénye (memória, file) a pontok számának növekedésével
- 'elég' hatékony algoritmusok vannak a legrövidebb utak meghatározására, de kis innovációval az eredetiekhez képest mindenképpen szükséges
- a tulajdonséggal rendelkező kapcsolatok adott szituációban való kiértékelése nagyon egyszerű, akár tiltással, akár helyzetenkénti eltérő súlyozással, stb.A buszjárat-feladat (a megállókkal) nagyon ritka gráfnak fogható fel, viszont rendelkezik jó pár további - dinamikus - kapcsolattulajdonsággal (várakozási idő, a célútvonal időintervalluma (reggel-délben-este), átszállás stb.), ezért - főleg nagyszámú pontnál - alkalmasabb a listás megközelítés, mint a mátrixos. Erre nagyon jó kiindulópont az előbbiekben linkelt Dijkstra-algoritmus.
-
#136
cucka
addikt
kicsitomi88
#134
cucka
addikt
válasz
kicsitomi88
#134
üzenetére
gráfot csúcsmátrixban vagy éllistával szokás tárolni, legrövidebb utak kereséséhez meg nézz utána a dijkstra algoritmusnak, amit célszerű az első reprezentációra megírni.
(csúcsmátrixnál a mátrix (x,y) pontjában az x-ből y-ba menő él hosszát tárolod el, éllistánál pedig minden csúcshoz tartozik egy lista, amelyben az adott csúcs szomszédai vannak.)elég rég tanultam ezeket, remélhetőleg jól emlékszem a terminológiára
-
#135
shev7
veterán
kicsitomi88
#134
shev7
veterán
válasz
kicsitomi88
#134
üzenetére
ha jol emlekszem ehhez az algoritmushoz egy egyszeru matrix a legcelszerubb, ami azt tarolja, hogy mennyi a tavolsag (a te esetedben ido a ket pont kozott) de igazad vna, egy csomo mindent figyelmen kivul hagytam... lehet, hogy felepited a grafot, de adott idopontban ott nem is jar busz... tovabb kell gondolni az algoritmust
-
#134
kicsitomi88
őstag
shev7
#133
kicsitomi88
őstag
Valszeg konnyu igen, viszont ezt igy eloszor csinalom.
Olyan adatszerkezetet irsz amiben konnyeden tudok tarolni grafokat, ilyen adatszerkezetrol leirast hol tudnek megnezni?
Valamint szamomra nem feltetlen kell legrovidebb ut, nekem csak egy ut kell
Ezt azert irom mert szamomra nem csak utat kell keresni, hanem megnezni, hogy az a bizonyos ut megfelel e egyeb kivanalmaknak(idopont stb), bar gondolom ezt az algon belul egy felteteles szerkezettel valo fuggo tetestol megoldom majd.Na szoval mi is az a grafos adatszerkezet?
-
#133
shev7
veterán
kicsitomi88
#132
shev7
veterán
válasz
kicsitomi88
#132
üzenetére
szerintem vegyel elo egy algoritmuselmelet konyvet
fogsz talalni olyan adatszerkezetet, amiben konnyen tarolhatsz grafokat, es amin gyorsan el tudod vegezni a legrövidebb ut kereseset. Azt a pseudo kodot akarmilyen kodda atirni nem nagy melo, gyorsabbat ugysem talalsz, es nem kell feltalalnod a spanyolviaszt Sot nem is kell algel konyv itt szepen le van irva a Dijkstra algoritmus.
-
#132
kicsitomi88
őstag
kicsitomi88
őstag
Sziasztok
Úgy volt, hogy az általam nyitott C programozas topikban teszem fel ezt az off kerdest, de valahogy itt kisse szakertobbnek lattam a tarsasagot akik nap mint nap itt voltak.
Nos van egy JAVA projektem egyetemen, nem nagy kunszt ahhoz kepest, hogy elso OO programkent irjuk, de egy resz megoldasaban nem vagyok biztos.
Van egy adatszerkezet melyben buszjaratok jellemzoit tarolom, ugy mint: jaratszam, elsojaratideje, utolsojaratideje, kovetesi ido, megallok es a hozza tartozo plusz percek indulastol szamitva hogy mikor er eppen oda.
Egy fajlbol szepen beolvastam a buszjaratok adatait, inputkent konzolrol fogadom a honnan hova mikor harmast, majd egy lehetseges utvonalat kell talalnom a honnan hova kozt idopontokkal, megallokkal es jaratszamokkal jelolve. A buszok korjaratok tehat visszafele is mennek, de ez mar nem is lenyeg.
Nos a kerdesem annyi lenne, hogy ennek a megvalositisara a visszalepeses kereses algoritmus jo otlet lenne-e? Vagy buveszkedjek magam ki egyet vagy teljesen rosszul gondolom?
A valaszt elore is koszonom ;)
-
doc
nagyúr
válasz
S.P.Q.R.
#130
üzenetére
a project fejlődése illetve "elkészülése" nem (csak) a PM-től függ
a mi játékunk is elkészült, igaz, szerintem még kellett volna bele egy-két apróság, de mindegy
viszont hiába készült el, és tette a dolgát remekül a zenész, a grafikusok, meg talán én is mint programozó, ha a játék kvázi eladhatatlan, mert nincs is piacra dobva. reklám kell, sok helyre bepróbálkozni, csinálni vele valamit. azzal hogy a vinyón üldögél, nehezen lesz bevétel...magába a fejlesztésbe szerintem ne szóljon bele nagyon egy PM, mondja el az elképzeléseit, sőt, a program/designtervet is csinálja meg, hogy tudjuk merre haladunk, figyelje azt hogy hogyan halad a project, hogy ne legyenek felesleges körök, pluszban elvégzett melók (nálunk sajna volt bőven), koordinálja a munkát, de ne ő mondja meg hogy hogyan írjam a kódot
-
S.P.Q.R.
csendes tag
Nah akkor megfordítom a kérdést(most figyeljetek
) Ha egy projekt manager nem a legalkalmasabb személy, akkor a projekt eleve veszve van?
A saját tapasztalatom az, hogy az egyik főnököm belenézett a kódba de az istennek sem akart kiszabadulni a visual basic-acces világból és csak abban volt hajlandó gondolkozni. De legalább(sajna) leült a kódhoz, bár php és java volt és mondott ezt-azt...A másik meg olyan volt, aki csak dirigált meg a szerződést lengette, hogy határidő meg stb...irreális dolgokat akart csináltatni, fontosabb volt számára a személyes ambíció stb, de nem pofázott bele mit hogyan valósítsunk meg...de a projekt mindkét esetben haladt, és nem tudom eldönteni, hogy melyik segített és melyik hátráltatott inkább...
A másik kérdés, ha nem feltétlen kell jó programozónak, és nem is feltétlen jó managernek vagy vezetőnek lennie a projekt managernek, akkor mi alapján lehet szerintetek eldönteni ki alkalmas rá és ki nem?
üdv:
S.P. -
doc
nagyúr
válasz
S.P.Q.R.
#127
üzenetére
nem kell hogy jó programozó legyen, elég ha van némi fogalma a dologról, arról hogy milyen megoldás mennyire reális/időigényes, inkább legyen jó "menedzser"
sajna a saját tapasztalatomból beszélek, egy ideje foglalkozom játékfejlesztéssel, és a tavaly áprilisban (!!) befejezett játékunk még mindig alig van kint a neten, a mostani meg már vagy egy hónapja nem haladt semmit, szóval katasztrófa...
pedig némi agilitással, meg "menedzserséggel" bőven meg lehetne ezeket a problémákat oldani, de a mi projectvezetőnk... -
shev7
veterán
válasz
S.P.Q.R.
#127
üzenetére
egyszer dolgoztam egy projecten, ahol szinte akadalymentesen mentek a dolgok. Szerintem a titka abban rejlett, hogy volt egy olyan kontakt szemely, aki a megrendelo kereseit ertelmesen le tudta forditani a programozoknak, minimalisra csokkentette a felreertesek lehetoseget, es rendelkezett akkora ralatassal a fejlesztoi oldalra, hogy a tul ertelmetlen kereseket mar elso korben elbuktatta. De emelett szukseg volt egy olyan project vezetore (nem neveznem managernek), aki tisztaban volt az egyes reszfeladatokkal, es a csapatban dolgozo emberek kepessegeivel.
-
S.P.Q.R.
csendes tag
Ki mit gondol, hogyan kell megközelíteniaz egység sugarú loosert...akarom mondani usert
Szal mi legyen az elsődleges szempont a user friendly felületen/arculaton. Ha a user olya tkér ami szakmailag nem indokolt, de pl ő a felhasználói képviselő, ti lebeszélnétek, vagy ráhagynátok ha ti lennétek ppéldául a projekt manager?
Következő kérdés, a projekt manager jó programozó legyen elsősorban hogy átlássa általánosságban(jó tudom ez így nem egészen lehet) a dolgot, vagy jó vezető ne adjisten jó menedzser? Vagy inkább ezek valamilyen arányú kombinációja?
Kinek mi erről a véleménye?
jó fórumozást:
S.P.stb.... -
S.P.Q.R.
csendes tag
Eléggé fel lesz paraméterezve, és úgy látom inkább hagyom a Visual studio-vs xml témát, ebböl is látszik hogy nem C#-ozom
Amúgy én a legutóbbi projektemben hosszú szövegek(nem olyan óriásikat azért;) változó fix), illetve cimkék tárolására használtam néha pedig sql scripteket tettem bele. A nagy adatoknak én is sql alapu db-t használtam, pl egy szótáron dolgoztam aminek a felületen megjelnő cimkéket xml-ből szedtem mig a szavakat és azok tulait MSSQL-ből.
Amúgy még mindig nem készültek el a SOAP-os kollegák, szal nem tudom beilleszteni, pedig már három órája várok rájuk -
Vico87
tag
válasz
S.P.Q.R.
#123
üzenetére
Ha adhatok egy tanácsot, akkor írd teljesen általánosra, a lényeg, hogy bármit képes legyen átküldeni és fogadni (nagyon széleskörûen paraméterezhetõ legyen), mert amikor legközelebb írsz SOAP-os cuccot, akkor jól jön. (Ha meg nem így csináltad, akkor nem lesz kedved egy nagyon hasonlót írni.)
@Lortech : én a lokalizáció kapcsán beszéltem XML-rõl (de újra elolvasva amit írtam tényleg nem egyértelmû, hogy arra gondoltam).
-
Lortech
addikt
válasz
S.P.Q.R.
#123
üzenetére
A gui leírásához (modell + viselkedés) nincs köze a visual studios xml-nek. Konkrétumot nem sokat írtatok, de ha nem ismerem a témát, úgy tűnt volna, hogy erre használatos (mint pl WPF + XAML-nél), közben meg nem. Erőforrások tárolására: lokalizáció, képek, szövegek, hangok stb. Akár egy konzolos alkalmazásnál is.
Én legutóbb az aláírásomból elérhető programhoz használtam xml-t, a prohardveres privát üzeneteket mentettem xml-be. Ilyen feladatokra pl. tökéletes és feleslegesnek tartottam egy mini adatbáziskezelőt hozzácsapni a programhoz.
Még objektumok sorosításához, webszolgáltatásokhoz használom remoting kapcsán a szakdogámban. -
S.P.Q.R.
csendes tag
Lehet almát körtével hasonlitunk, de mindkettő gömbölyű és finom, szal azért vannak hasonlóságok
A Visual studio Desiner kontra xml ezek szerint nagyjából jól sejtettem, bár most újdonságokat is megtudtam, és jó pap holtig tanulAmúgy mint irtam is, másféle dolgokra használom én is, de vannak határesetek amikor ez-is az is használható. Amúgy jó hogy a SOAP szóba jött most PHP5 alól épp SOAP-ozós progit fejelsztek ami majd valamilyen diagrammokhoz hiv meg függvényeket, vagy szolgáltat adatokat. Sajna kedves team-em késik ezzel szal határidő gondjaim lesznek, ha ők késnek én is kések
nah midnenkinek jó forumozás továbbra is:
S.P.Q.R. -
doc
nagyúr
nyilván teljesen másra való az XML és az SQL (pl.)
perpill. pl. egy flash menüt fejlesztek, ami 3D-s modelleket használ, ezek Collada objektumok (xml-ben tárolja a teljes modellt), a beállítások szintén xml-ben vannak, erre tökéletes, felesleges is lenne valami adatbázist mögé tenni (sőt, egy 3D objektumot elég érdekes lenne mondjuk SQL táblaként megoldani...)de mikor a php-val kezdtem foglalkozni, próbaképp csináltam egy több opció szerint kereshető/szűrhető listát a dvd-imről, ott nyilván sql-t használtam, eszembe sem jutott az XML
szóval almát körtével hasonlítunk, szerintem
-
Vico87
tag
válasz
S.P.Q.R.
#120
üzenetére
Bocsi, ha túl "magyarázó" voltam.
Én úgy tudom, hogy a Visual Studio (WinForms esetben, a WPF más tészta) designer módban rakja el XML-be, de amikor fordítod, és lesz belõle release, akkor egy dll-t csinál a különbözõ lokalizációkhoz. Ez azért van, mert az egyes lokalizációk esetében arra is kell gondolni, hogy egyes szövegeket hosszabban lehet leírni más nyelven, így pl a Button méretét is másra kell tervezni, de ha a Button nagyobb, akkor az vonzza magával, hogy mondjuk a ComboBox viszont kisebb, stb... ezért lesz belõle dll, mert kódot tartalmaz.
Egyébéknt az XML nagyon szép és jó, de egy méret után már nem emberi használatra való, hanem inkább kód kezelje. Mondjuk technológiailag lenyűgözõ, hogy mekkora szerep jutott az évek során az XML-nek (gondolok itt webszolgáltatásokra például, és annak vonzataira mint SOAP, WSDL, stb...).
-
S.P.Q.R.
csendes tag
Nah akkor válaszolok
Tökéletesen tisztában vagyok hogy más szintű és máshogy táolódnak az RDBMS rendszerekbe az adatok, mint a fastruktúrában tároló xpath-al könnyen kezelhető XML_ben.
Máshol és máshogyan alkalmazzák, hidd el én is irtam olyan progit eleget ami mindekettőből dolgozik, vagy épp XML-ből visz ád SQL alapú DB-be adatot, tehát ilyen konvertáló progi szerűt stb...
Csak azért írtam le így mindenféle kategorizálás nélkül egymás után őket, mert csak pl-nek hoztam fel őket beszédtémának. Szal hidd el tudatában vagyok miket írok
Amúgy azzal vitatkoznék kicsit, hogy másra alkalmasak,KIS méretű adathlamz esetén egy xml file xpath-al elég jól kezelhető, nagy méretben természetesen nem de igazából arra lennék kiváncsi, hogy ki hol és milyen mértékben használ pl XML-t bizonyos adatok tárolására. Pl tételezzük fel hogy van egy rendszer mondjuk egy portál/vagy éppen valami ablakos alkalmazás, ami többnyelvű kellen hogy legyen, ugye az kézenfekvő hogy a gombok menük szövege valahol tárolódik. Több féle megoldás is van ezekre. Például ha jól tudom,(ha nem mea culpa nem vagyok c# fejlesztő
) a visual studionak is van kül desiner felülete a GUi készítését elősegítendő. S ha jól tudom az ilyen jellegű adatokat XML-ben tárolja. Ez csak egy példa volt, az ilyen jellegű példák sokaságát várnám.
mindenkinek jó fórumozást:
S.P.Q.R. -
Vico87
tag
válasz
S.P.Q.R.
#115
üzenetére
Akkor én írok neked a DB-kről
.Szvsz másra alkalmasak az SQL és az XML alapon tárolt adatok. Az SQL esetén ugyebár van egy DBMS mögötte, amely igen sok verziót megért már (pl Oracle-nek 10, 11 még fejlesztés alatt, MSSQL 2008, ha jól tudom a 10-dik kiadás, pedig manapság jelenik vagy jelent meg) sok-sok funkcióval és optimalizálással. Mindez nincs XML esetén, hanem neked kell megírni a kezelést végzõ funkciókat (nyilván olyan API-k mint a Java vagy .net rengeteg objektumot a rendelkezésedre bocsát erre a célra).
Ezek a különbségek fõleg onnan erednek, hogy az SQL esetén relációs adatbázisból dolgozol (amely kezelésére vannak az elõbb említett DBMS-ek), míg XML esetén amolyan "adatkupac" jelleget ölt a dolog.
A relációs adatbázisok igen hatékonyak például üzleti adatok tárolására, amire az XML igencsak alkalmatlan. Ellenben egy fastruktúrát leírni egyszerűbb XML-ben. XML-ben nem lehet könnyen nagy mennyiségű adatot tárolni (itt igen sok adatra gondolok, de nem kell messzire menni, gondoljunk pl 10GB-nyi adatra, ami meg sem kottyan egy DBMS-nek, viszont ennyi adat kezelésére XML-alapú progit írni vérpisilõs mutatvány). Relációs adatbázisban minden mezõnek típusa van, míg XML-ben minden plain text, így kicsit könnyebb az adat ellenõrzése DBMS esetén (integritásellenõrzést alapszinten tud csak elvégezni, hiszen a DBMS "nem gondolkodik", de ez már sokkal több mint ami rendelkezésre áll XML-ben).
XML-ben van pl XSLT, amivel teljesen átírható az adat formátuma (nem a tartalom!), de ehhez hasonlót DBMS esetén sem nehéz megvalósítani.Mindezzel oda akartam kilyukadni, hogy más világ a kettõ. Nekem C#-ban volt szerencsém programot írni, ami egy MSSQL adatbázisból dolgozik, és azt kell mondanom, hogy kifejezetten tetszett a DataSet-es megközelítése az adatok leképezésének (lényegében minden táblához tartozik egy-egy osztály, amelyek egy "gyűjtõ" osztályban (class DataSet-bõl származó) vannak).
-
S.P.Q.R.
csendes tag
Nah úgy néz ki leült picit a téma javaslom kezdjük el az adatbázis alapú programokról szóló eszmefuttatást. A kérdéseket már feltettem feljebb..De megismételm.
-Ki mit gondol az SQL alapu db-kről?
-Mennyire kell elválasztani a kódot és a db-t egymástól? hallottam olyan véleméyneket, hogy lehetőleg legyenek függetlenek.
-Mit gondoltok kül OO-s db megoldásról pl olyamiről mint ami a Lotus alatt ketyeg?
-Újabb szabványok, pl XML(személyes kedvenc sokmindenre jó általános, jól kezelhető SGML származék) kezelésről, és adattárolásról kinek mi a véleméye?
-Ezeket ki milyen nyelven kezelné legszivesebben, személy szerint Java, PHP, C#-ban mind találtam rá nagyon jó kis megoldásokat
Nah lehet elmélekedni ezzel kapcsolatban
üdv: S.P.Q.R. -
doc
nagyúr
te beszélsz feltűnési viszketegségről meg "agyfosásról" ?
amúgy a felhozott példád remek, pontosan ez az a terület, ahol az OO sokkal kényelmesebben használható.
[i]
plus (a,b) : int;
a,b int;
plus:=a+b;plus (a,b) : real;
a,b : real
plus:=a+b;
[/i]itt most ugyanazt leírtad kétszer, azzal a különbséggel hogy az int-et kicserélted real-re... pont ezt (és még sok más "robotmunkát") segít elkerülni az OO szemlélet
pl. tegyük fel hogy az int és real nem alaptípusok, hanem annál bonyolultabb szerkezetek. ilyenkor ha szeretnél mondjuk még egy típust, nem kell szorgos hangya módjára copy-paste-elni, majd az int-eket más típusra cserélni, hanem egész egyszerűen származtatod az új, kibővített osztályt a régiből, és automatikusan jól működik minden. akkor kell a szóban forgó függvényt újra megírni, ha mást csinál, ha ugyanazt, akkor nem kell ötmilliószor lemásolni, erre való a virtuális metódus
egyébként már példát is hoztam a polimorfizmusra, tessék kicsit scrollozni, olyan sokat nem postoltam még ebbe a topicba...
-
Kkocos
tag
plus (a,b) : int;
a,b int;
plus:=a+b;plus (a,b) : real;
a,b : real
plus:=a+b;class complex
r,i: real;
end class;complex.plus (a,b: complex) : complex ;
begin
plus.r:=a.r+b.r;
plus.i:=a.i+b.i;
end;most ez nem polimorfizmus ha aszondom hogy c:=plus(a,b)\ c lehet barmi a fentiekbol?
Tul sokk az agy, a feltunosegi viszketegseg, senki se szol konkretumokrol, mindenki mindent tudd, csak epp maganak tartja, nem monda me' fel hogy beeg! Persze a kritikak omlenek, csak epp mire. Ha nem tetszik ne szolj hozza, ha hozaszolsz es epp kritikusan, ilenne megoldast is adni , igy csak agyfosasnak tunik
-
#110
Kkocos
tag
loszerafin
#107
Kkocos
tag
válasz
loszerafin
#107
üzenetére
Miert ne?
Ha aszondom hogy a plusz b
a lehet int,real,complex, mitomen
b csakugy
Ez polimorfizmus, nem?
Miert ne lehetne? -
dabadab
titán
[ Elkavartam valahova a sajtreszelot
]"Mit szolsz ehez
Tesszeb Button egy objektum
aszondom hogy :
new Button(x,y); \ahol x,y a pozicio. Mi a szentseget is csinaltam?????
Meghivtam az objektum construktorat. Nem? Vagyis?"Eloszor is azt, hogy soha nem keso megtanulni irni.
Masodszor meg azt, hogy a konstruktort hivtad meg, nem az objektumot. Objektumot nem lehet meghivni, csak az egyes metodusait (igen, a konstruktor az egy specialis metodus).
-
#107
loszerafin
senior tag
loszerafin
senior tag
Olvasgatom itt a flame-et az "OOP miért jó?" témáról. Lehet, hogy elsiklottam fölötte, de a lényeg talán nem világos:
Az OOP-t az "élet" kényszerítette ki. A sok befejezetlen, rossz IT project, a betartatlan határidők, túllépett keretek, a programozás minőségének ellenőrizhetetlensége. (stb)
A szakirodalom szerint főleg 5 dolog miatt kell OOP:
1 kód újrafelhasználhatóság
2 megbízhatóság
3 hajlékonyság
4 kiterjeszthetőség
5 karbantarthatóságSzerintem még van 1 fontos dolog: 6. kiforrott technológia segít OOP programokat írni.
Hogy éri el a célját az OOP programozó?
Kicsi, átlátható, tesztelhető apró darabokra vágja a problémát. A darabok egy kicsi részproblémát oldanak meg, da azt NAGYON JÓL. Gyorsan, hatékonyan, ellenőrzötten, tesztelten jól működik a kicsi program. A kicsi probléma jól körülhatárolt, világosan specifikált, a megoldása tömör, jól dokumentált, az API-k kiforrottak, könnyen kezelhetőek.Ezért ezek a kis részproblémákat megoldó programok könnyen felhasználhatók más programozók által, más projektben is, nem csak ott, ahol készültek.
A kis részproblémákat megoldó programokat összekapcsolják egymással, és így oldják meg az eredeti problémát. Az összekapcsolás kizárólag a dokumentált API-n keresztül történik, azaz NEM növelik a kis részek között a függést, a részek NEM látnak bele egymásba, nem módosítják egymást.
Tehát a részek belseje (a kódsorok) nyugodtan cserélhetők, feljleszthetők, javíthatók, ha az API nem változik, nem borul a teljes program.
Mivel a világban a problémák változnak, a programnak is változnia kell. Ehhez általában elég a kis részeket más sorrendben, más logikával "összeragasztani" -> gyorsan követhetik a programozók a világot.
A 6. pont is nagyon fontos:
OOP programnyelvekhez van pl. kód dokumentálás, UML, design patternek, unit tesztelés.
Ezek nélkül is lehet programozni, csak nem érdemes. Ha vmit megcsinálhatunk jól, akkor nem érdemes rosszul megcsinálni.Mit nem lehet struktuális programozással megvalósítani?
Hát pl. a polimorfizmust.
-
Kkocos
tag
???? "Felhozod a megdonthetetlennek hitt erveidet, de mivel nincs mogotte tudas, igy gyakorlatilag nincs ertelme annak amit mondasz..."?????
Furcsa
"Fogalmi zavarba kerultel... objektumot nem hivunk..."
Mit szolsz ehez
Tesszeb Button egy objektum
aszondom hogy :
new Button(x,y); \ahol x,y a pozicio. Mi a szentseget is csinaltam?????Meghivtam az objektum construktorat. Nem? Vagyis?
-
shev7
veterán
a helyzet az, hogy eddig senki sem mondta, hogy az OOP az isten minden mas szar, es mindehol az oopt kell hasznalni. Szemben veled aki lathatoan tudas nelkul mondasz velemenyt valami olyanrol amirol fogalmad sincs. Felhozod a megdonthetetlennek hitt erveidet, de mivel nincs mogotte tudas, igy gyakorlatilag nincs ertelme annak amit mondasz...
-
Kkocos
tag
Igen, lehet, koveted a secventialis elvet. Mint OOP, vannak objektumaid, deh az objektumok maguktol nem tudjak mien munkafazisban is vagy, ha csak nem bemenetkent megmondod nekik, es megfelo fazisban hajtjak vegyre a parancsokat, a tobbire meg "basznak" ra. Az uj amit ez hoz, hogy hiaba vannak meg a vegrehajtashoz az ossze kondicioja az objektumnak, nem dolgozza fel. en forditva gondolkodnek. csak akkor hivd meg az objektumot ha abba a fazisba kerultel. Nincs felesleges elenorzes
-
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
dabadab
titán
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
-
dabadab
titán
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.
-
dabadab
titán
"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.
-
dabadab
titán
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.
-
dabadab
titán
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?...
-
dabadab
titán
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
-
dabadab
titán
"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.
. egy darabot találtam msdnan, azt nem tartottam túlzottam mérvadónak. olyan weboldalhoz kéne amin sok (nagyon sok) adatbázisban tárolt adat van (felhasználói profilok sok adattal, események, fórumok stb). 
)
, azert irtam ide, hatha vlki a matlabban tud segiteni, francnak van kedve uj progit megtanulnia 
) Nemtom googlen azért csak akad hozzá anyag..
(Post probléma valamikor a 30-as években jöttek rá)
]
! 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
Hirdetés
- Új Apple iPhone 16 Pro 128GB, Kártyafüggetlen, 3 Év Garanciával
- Csere-Beszámítás! RTX Számítógép PC Játékra! R5 8400F / RTX 3070Ti / 32GB DDR5 / 1TB SSD
- BESZÁMÍTÁS! MSI B450M R5 5500 16GB DDR4 512GB SSD GTX 1080Ti 11GB Rampage SHIVA Chieftec 700W
- Bomba ár! HP ZBook 15 Studio G3 - Intel Xeon I 32GB I 512SSD I 15,6" FHD I Nvidia I Cam I W10 I Gar
- BESZÁMÍTÁS! CSAK KIPRÓBÁLT! ASUS ROG Ally X (2024) 1TB kézikonzol garanciával hibátlan működéssel
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest