1. |
Re: C++ (mind) |
98 sor |
(cikkei) |
2. |
Re: Moderatorok es a lista (mind) |
20 sor |
(cikkei) |
3. |
Re: Moderatorok es a lista (mind) |
12 sor |
(cikkei) |
4. |
Re: C++ (mind) |
33 sor |
(cikkei) |
5. |
Re: C++ (mind) |
44 sor |
(cikkei) |
6. |
Re: C++ folytatas (mind) |
18 sor |
(cikkei) |
7. |
mozgokep, mit tud a profi technika? (mind) |
77 sor |
(cikkei) |
8. |
Re: C (mind) |
31 sor |
(cikkei) |
9. |
sqlplus /nologon (mind) |
12 sor |
(cikkei) |
10. |
RE: C++ (mind) |
23 sor |
(cikkei) |
11. |
Re: C (mind) |
44 sor |
(cikkei) |
12. |
Re: Re: mozgokep (mind) |
41 sor |
(cikkei) |
13. |
Re: C++ (mind) |
15 sor |
(cikkei) |
14. |
Re: c++ (mind) |
190 sor |
(cikkei) |
|
+ - | Re: C++ (mind) |
VÁLASZ |
Feladó: (cikkei)
|
> Sziasztok!
Szia
> Az elmeleti kerdes a virtualis/statikus tagfuggvenyekre vonatkozik:
> Korabban javaban lattam hogy minden tagfuggveny virtualis kiveve
> amit a static kukcsszoval statikussa nem nyilvanitunk pl.: a main-t,
> es ez igy jo. Most c++ban azt latom hogy minden tagfuggveny statikus
> kiveve ha kulon a virtual kulcsszoval virtualissa nem nyilvanitjuk,
> es itt meg igy jo. Elmagyarazna valaki hogy, mi a jo nekem, ha minnel
> tobb fuggvenyem statikus, vagy ha minnel tobb virtualis?
Hat azt a reszt most inkabb kihagyom, hogy mi a velemenyem a java-rol.
A problema itt eloszor is az, hogy nem 2 fajta, 3 fajta tagfugvenyeid vannak:
1) statikus
Ezt ugy szoktak magyarazni, hogy az osztalyod fuggvenye es nem az objektume.
Vagyis az osztalyodhoz kapcsolodik elmeletileg, de nem kotott egy objektumhoz
sem. Ezert nincs is szuksege objektumra. (ezert tudod igy [is] meghivni:
osztaly::metodus()). A java-ban azert kell a main az legyen, mert kezdetben
egy objektumod sincs, majd a main kell letrehozza oket.
2) normal
Ez egy objektumhoz kotott fuggveny. Csak objektumon keresztul erheted el:
Osztaly * o = new Osztaly();
...
o->metodus();
3) virtualis
alap allapotban ugyanaz mint az elobbi. A kulombseg (ami viszont nagyon
fontos) ott van, hogy hogyan fiselkedik felulirt metodusok eseten.
Pelda:
class A
{
public:
void hello(){ printf("Hello World!\n"); }
};
class B: public A
{
public:
void hello(){ printf("Gooood morning vietnam!\n"); }
};
A *valami = new B();
valami->hello();
A kerdes, hogy mit fog kiirni.
Ebben az allapotban (a metodus normal) azt irja ki, hogy "Hello World", mert
hiaba B-nek hoztuk letre, a fordito A-nak ismeri, azert az A::hello-t fogja
meghivni.
Ha viszont az A-ban a metodust virtualnak definialjuk, akkor a B::hello-t
fogja meghivni, mert az objektumot B-nek hozta letre. Ez egyszeruen ugy
mukodik, hogy a normal eljarasokat direkt hivja meg, mig a virtualisakat egy
pointeren keresztul. Ha A-nak van letrehozva, akkor pointer az A::hello-ra
mutat, ha B-nek, akkor a B::hello-ra. (Ezek a pointerek vanna a virtual
method table-ben - VMT, ami az objektumod legelejen foglal kb 4 bytot...
persze csak abban az esetben ha van virtualis metodusod. Probald ki: irasd ki
sizeof(A)-t mindket esetben)
Szoval a java es a c++ kozti kulombseg es hasonlosag:
Mindkettoben a statikus metodusokat expliciute meg kell adni.
Javaban alapertelmezett a virtualis, mig c++-ben a normal (A C++ inkabb
sebessegre megy, a virtualis eljarasok egy kicsit lasabbak, es meg szukseg
van a a VMT-re is)
C++-ban virtualis metodust ugy definialod, hogy ele irod a 'virtual'
kulcsszot.
Java-ban meg asszem a 'final'-t kell eleirni, hogy ne legyen virtualis, de
ebben nem vagyok biztos.
> Csakhogy ez a megoldas szvsz semmivel sem biztonsagosabb mintha
> public-ra deklaraltam volna az x-et hisz azt adok meg a setX
> parameterenek
hehehe .... ezert nekem is megvolt a velemenyem a tanaromrol, mikor ezt
mondta, de sajnos azota belattam, hogy igaza van.
A biztonsagot felejtsd el, mert nem tul sokat javit rajta (esetleg annyit,
hogy tudsz csinalni csak olvashato mezoket : csak a getX metodust irod meg)
Amiben nagyobb haszna van, az az, hogy konyebb boviteni a programot.
Mikor mar kb 10.000 sornal jarsz, rajoszz, hogy mikor egy mezot
megvaltoztatsz, nem artana ujraszamolni egy masikat...
Ha a mezo-det egy fuiggveny valtoztatja meg, akkor eleg a fuggvenybe megirni a
modositast.
> amit csak akarok. Ha az eredeti logikat kovetem, akkor a setX eleve
> nem lehet void visszateresu hisz vizsgalni kellene a meghivas helyen
> hogy sikeres volt-e az ertekadas. Tehat szerintem helyesen igy nezne
> ki:
Az objektum orientalt elkepzeles szerint ilyenkor kivetelekkel ping-pong-ozol
:-)
> Mert lehet hogy egy profinak ez trivialis, de egy kezdonek nem az.
Szerintem egy kezdonek ez hulyesegnek tunik, a profik viszont mar beletorodtek
a szukseges rosszba :-))
Sok sikert
Pali
|
+ - | Re: Moderatorok es a lista (mind) |
VÁLASZ |
Feladó: (cikkei)
|
> elnezestkeresek is terhelik a listat, fel is teszem: Hova lettek a
> moderatorok? Jonnek a mellement off-topic levelek (itt nyilvan nem a
Mielott lugot iszol: Igyal inkabb tejet, azzal is a magyar tejipart
tamogatod, amennyiben nem szupermarketben veszed.
A moderatorok a HIX-rol felszivodtak, mert maga a HIX rendszer ingyenes, es
ki az aki vatikani valutaval tudja etetni csaladjat.
A problemat en mar felvetettem a "webmesteren", az ekezettelenites ugyen.
Ha el akarod olvasni, ajanlom a http://www.google.com csoportok kereseset,
utt amiota NewsGroupon is megjelenik arhivalasra kerulnek a levelek. Keres
ra a magyar csoportoknal a "kpd"-re, asszem talalkozni fogsz eezzel a
temaval, amelyet mar mindenki oromere lezartam.
Tehat nincs moderator, nincs ekezet, mert nincs penz sem.
Megegyszer mindenkitol elnezest kerek a korabbi felrement levelert!
Nem gondolom, hogy barkiben is felmerult a szandekossag.
kpd
|
+ - | Re: Moderatorok es a lista (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Udv!
Ez a lista mar kb nagyonsok ideje
__nem moderalt__ .
Amugy engem nem erdekel hogy a kualalumpuri
kiralyfi mennyit ajanl fel ha tisztara mosom
a penzet, nem ezzel van baj, hanem tenyleg
azzal, hogy egyre kevesebb a tartalom a listan.
--
Hofferek Attila
<hofi at WiZARD dot DunaNet dot hu>
|
+ - | Re: C++ (mind) |
VÁLASZ |
Feladó: (cikkei)
|
>A tankonyveim szertint az adattagokat private-ra kell deklarani hogy
>a nagyobb biztonsag erdekeben csak a tagfuggvenyek ferjenek hozza. pl.:
Olyan peldat szoktak gyakran felhozni, miszerint egy objektumban egy vektort
tarolsz.
private double x, y;
Hogy ne kelljen minden alkalommal kiszamolni ujra a vektor hosszat,
van egy
private double length;
valtozod is.
Ehhez metodusok: void setX(double x), setY, double getX(), getY(), double
getLength()
Itt jon a szerepe annak, hogy mindegyik private,
es hogy csak metodusokkal tudsz hozzaferni.
Ha szabadon allithatnad az x-et es y-t, minden valtoztatas utan
ujra ki kellene szamolnod a length erteket is.
Ha esetleg elfelejted, rossz adatot fog tarolni az objektum.
Ezert a setX - setY metodus igy nez ki:
void setX( double x){
this.x = x;
length = gyok( negyzet(x) + negyzet(y));
}
A length-et persze csak lekerdezni lehet, hisz miert allitanad at?
Mindig a jo adat van az objektumban.
Ezutan mar egyszeruen elkeszithetsz egy skalarszorzo metodust:
void skalarszoros(double skalar){
setX( skalar * getX());
setY( skalar * getY());
}
Es igy nem kell ujbol leirni, hogy szamolja ki a vektor hosszanak uj
erteket.
Udv,
Tibor
|
+ - | Re: C++ (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Szevasztok, Szevasz Andras!
> Felado : [Hungary]
> A tankonyveim szertint az adattagokat private-ra kell deklarani hogy a
nagyobb biztonsag erdekeben csak a tagfuggvenyek ferjenek hozza. >
Lehet annak a valtozonak ertelmezesi tartomanya, abrazolasi modja, lehet,
hogy ertekenek megvaltozasarol ertesiteni kell egy masik fuggvenyt stb. Ha
kozvetlenul allitod az erteket, akkor az elozoek vizsgalata illetve
vegrehajtasara nincs modod.
1. Pl.: volt egy belso adatbazisom, ahol elore lathatoan eleg volt a 16
bites szamabrazolas. Az ertekado fuggveny parameteret viszont a biztonsag
kedveert 32 bites tipusra valasztottam. Milyen jol jott ez a megoldas
kesobb, amikor megsem volt eleg a 16 bites abrazolas! Nem kellett mindenhol
tipust valtoztatnom, ahol az illeto valtozo elofordult, csak az ertekado
fuggvenyben. (Ennel azert bonyolultabb volt az eredeti feladat, de itt
nyilvanvaloan egyszerusiteni kell.)
2. Pl.: a szukseg ugy hozta, hogy egy bitmezoben meg kellett valtoztatni a
bitek kiosztasat. Az ertekado fuggvenyben (es a kiolvaso fuggvenyben) kelett
csak valtoztatni, sehol mashol.
3. Pl.: kirajzolsz valamilyen szamitott erteksort. Eleg ujrarajzolni akkor,
ha valamelyik valtozojanak megvaltozott az erteke. Erre is jo az ertekado
fuggveny.
4. Pl.: ha a valtozo nem veheti fel az osszes lehetseges erteket, amit a
tipussal abrazolni tud, akkor ezt figyelheted, hibajelzest kuldhetsz, stb.
> Ha az eredeti logikat kovetem, akkor a setX eleve nem lehet void
visszateresu hisz vizsgalni kellene a meghivas helyen hogy sikeres volt-e az
ertekadas. >
Bizony igazad van, de a legegyszerubb esetben valoban mindig true erteket
adna vissza.
> Harom tankonyvet neztem att, de mindegyik csak a fentire hasonlo,
szerintem hibas peldakat hoz fel. >
Nem hibasak, csak nem a valosagbol kiragadott peldak, hanem illusztraciok.
>Andras
(Ment listara es maganba.)
Cap
http://web.axelero.hu/torszoft/ (Szovegesinformacio-kezeles)
|
+ - | Re: C++ folytatas (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Szevasztok, Szevasz Andras!
Eszembe jutott meg egy szempont: ha tagfuggvenyen keresztul adsz erteket egy
valtozonak (es olvasod ki), akkor peldaul teljesen rugalmasan oldhatod meg,
hogy hol es hogyan tarolod a valtozod tartalmat. Lehet statikusan,
dinamikusan, file-ban, vagy akar halozaton, netan az interneten (:-). Es
mindezeket ugy tudod a kesobbiekben is valtoztatni, hogy a valtozot hasznalo
fuggvenyek errol tudomast sem szereznek.
Pl.: van egy dinamikusan valtozo meretu tombod, ahol elofordulhat kis
elemszam es nagyon nagy elemszam is. Amig a tomb kicsi, tarolhatod egy
statikusan lefoglat tombben, majd egy dinammikusan lefoglalt tombben, majd
ha azt is kinotted, akkor egy file-ban.
Osszefoglalva: a tagfuggvenyen keresztuli valtozo ertekadas es kiolvasas
kontrollalhatova teszi e muveleteket, valamint rugalmassa a kesobbi
programbeli valtoztatasokkal szemben.
Cap
|
+ - | mozgokep, mit tud a profi technika? (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Koszonom szepen a valasz leveleket.
>van rá orvosság: profi digitális eszközök.
>Pl. Canon XL1-S digitális kamera,
> "Frame movie mode", ez másodpercenként
>hót ziher hogy 25 teljes képet csinál, mint a mozi.
Ennel a kep elso es utolso sorai ugyanazt az idopillanatot
abrazoljak? Avagy itt is van 40 ms eltérés?
Azert kerdem, mert ha van, akkor az a baj,
ha meg mondjuk nincs, es valoban allo pillanatkepeket keszit,
akkor azt teven vagy CRT monitoron nem is lehet jol megnezni.
Telhetetlen vagyok, mi? :-))
Csak olyanon nezheto, ami egyszerre frissiti minden sorat, nem?
A TFT monitorok hogy allnak a frissitessel?
Soronkent, ahogy kapjak az infot,
vagy egy pillanatban valt az egesz kep?
Es az LCD-s projektorok?
>Az eltéro képfrissítési frekvencia okozza a gondot.
:-) Igen, rajottem.
>> a kamera egy utcat pasztaz, es a 24...25 fps lathatoan nem eleg.
>Sajnos, gyakran van ilyen,
>...
>Mindenesetre a 25 fps jól ki van találva, elég az.
Most akkor melyik? :-))
Kepernyo meretnel eleg a 25 fps, de mozivasznon mar nem mindig.
Ami azert furcsa, mert elobb volt mozi, mint kepernyo...
>> Avagy keptartalomfuggo fps.
>A 35 mm-s mozifilmen már így se nagyon férnek el, nem várhatjuk
>el a mozigépészektol az állandó sebességállítgatást is.
Ezt nem mondod komolyan !!!?!?
Nem a huszadik szazadban elunk! :-)) Videotechnika!!!
Csak azokat a 8x8 pixeles kocekakat gondoltam gyakrabban
(aka'r 100fps) frissiteni, es csak akkor,
ahol es amikor gyorsan valtozik a keptartalom.
> mert dupla felbontas korantsem ad dupla adatmennyiseget.
>...négyszeres lesz,
Persze, csak siettem, elirtam
-------------
>>100Hz-es teven probalom visszajatszani,
>>A kep ugral, ami leginkabb akkor eszreveheto,
>>amikor fuggeleges e'lek (oszlopok) mozognak vizszintesen.
>Hat ez erdekes effekt, de szerintem inkabb vizszintes elek mozognak
>(vagy nem u gyanarrol beszelunk, de ez elegge valoszinutlen,
>mert ez egy kozismert problema ).
En hatarozottan fuggoleges e'lekrol, oszlopokrol beszelek,
azok ugralnak amikor pasztazom az utcat.
Pedig nem pasztazok tul gyorsan. (max 2 sec/90fok).
Mint regen a ZX Spectrumon, amikor a betuk karakterenkent
ugraltak, nem pixelenkent masztak (hacsak nem irtuk ra vmit
gepikodban). (TravelWith rulez!!!)
Fuggolegesen me'g nem is probaltam pasztazni semmit,
lehet, hogy akkor tovabbi ujabb jelensegeket kapok? :-) Jaj!
>virtualdubot, abban van kapasbol deinterlace filter.
Az hogyan mukodik?
2 db egymast koveto felkockabol hogyan keszit
1 db nem fele felbontasu, de nem is fe'su"s kockat?
Bizony 20ms alatt sokminden megvaltozik a keptartalomban!
Legyenek a felkepek .... A1, B1, A2, B2, A3 ....
Az A2 hianyzo sorait a B1 es B2 intepolalasaval nyeri?
Mas nemigen tudok elkepzelni. Ha nem, hat hogyan?
BM
|
+ - | Re: C (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Virtualis/statikus tema: a statikus (static) fuggveny kicsit mast jelent, mint
amit irtal (osztalyszintu deklaracio), de ertem azt is, amit kerdezni akartal:
a virtualis fuggvenyhez VMT (virtualis metodus tabla) kell, az meg plusz memori
a, es persze plusz teljesitmeny (eggyel tobb indirekcio). A C++ alapvetoen telj
esitmenyorientalt, a Java alapvetoen a biztonsagra es a kenyelemre torekszik. T
ehat ez az oka: a hozzaallas.
Private/public pelda: ezt hivjak encapsulationnak, vagyis kivulrol az osztaly (
objektum) egy zart dolog, senkinek semmi koze ahhoz, hogy belul hogy intezi a d
olgait. Az objektummal uzenetek segitsegevel kommunikalunk, ilyen uzenet az, ho
gy setX(). Hogy erre az objektum mit lep, az teljesen az o dolga. Lehet, hogy a
lapvetoen az ertekadason kivul semmi mas nem tortenik, de lehet, hogy ket het m
ulva megvaltozik az implementacio, vagy egyszeruen beleteszel olyasfajta hibake
zelest, amit irtal -> ebben az esetben _csak egy helyen_ kell modositanod a pro
gramodat, ha uzenetekre reagalsz (ott, ahol az uzenetet feldolgozod), mig ellen
kezo esetben az _osszes_ olyan helyen, ahol kivulrol beleturkalnal az objectbe
at kellene irnod a kodot. 100 soros program eseten ez meg nem tunik olyan vesze
snek, de a tanitasi orakon kivul viszonylag keves 100 soros programmal talalkoz
ik az ember.
Tehat osszefoglalva: egyreszt igazad van, nem jo a pelda abbol a szempontbol, h
ogy nem vilagit ra a dolog ertelmere, masreszt viszont a tankonyvirot is megert
em, bar konkretan abban a fejezetben, ahol az egysegbezarasrol esik szo, igazan
irhatna bovebb kodot is. A lenyeg, hogy jo volt a peldad, csak igy tovabb! ;-]
Ha tudsz angolul, es egy igazan jo C++ konyvet szeretnel olvasni, ajanlom a Thi
nking in C++ cimut, netrol ingyen es bermentve letoltheto:
http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html
medve
(webes bekuldes, a bekuldo gepe: proxy.graphisoft.hu)
|
+ - | sqlplus /nologon (mind) |
VÁLASZ |
Feladó: (cikkei)
|
ORACLE 8i.ben szeretnek kesziteni egy sqlplus scriptet, mely
a kovetkezoket tudja:
Bekerek egy jelszot,
majd megprobalok becsatlakozni.
Ha a csatlakozas sikeres akkor lefuttatok egy masik scriptet, ellenkezo
esetben ujra kerem a jelszot. (max. haromszor).
Valamilyen otletet szeretnek ezzel kapcsolatban begyujteni, mert
nekem sehogy sem akar osszejonni.
Elore is koszonom!
Patalenszki Zoltan
|
+ - | RE: C++ (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hali,
jogos, igazad van abban a tekintetben (most a gyakorlati kerdesrol
beszelek), hogy a Set() fuggvények feladata tulmutat azon, hogy a
parameterkent kapott ertekkel egyenlove tegyek a nekik megfelelo
tagfuggvenyt. Leginkabb olyasmire szolgal ekkor a tagfuggveny, hogy az
adattagtol fuggo egyeb adattagokat is megvaltoztassa, most nagyhirtelen csak
egy tankonyvi pelda jut eszembe, van mondjuk egy Vector osztályod, ahol
eltarolod a hosszt is mint adattagot, hogy ne kelljen mindig kiszamolni.
Ekkor a koordinatak allitasaval egyutt nyilvan meg kell valtoztatni a hossz
adattagot is. Tehat a cel a konzisztencia megtartasa, amit el lehet erni ugy
is, hogy az ember public adattagokat hasznal, utana "odafigyel" :), csak
jobb, ha erre van nyelvi eszkoz.
Az elmeleti kerdesre annyit tudnek mondani, hogy Te dontod el, mit
minositesz virtualisnak, mit nem, ezt az osztalydiagram felepitesenel kell
eldonteni. Nem biztos, hogy jo az, hogy van egy olyan ososztaly, amibol
mindenki szarmazik, es tele van tisztan virtualis tagfuggvenyekkel, mert az
ember feje nem kaptalan :). Erre tudtommal nincsen "okolszabaly", a hasznalt
tervmintatol fugg, hogy mi sul ki belole.
Udv,
Tamas
|
+ - | Re: C (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hali!
>es itt meg igy jo. Elmagyarazna valaki hogy, mi a jo nekem, ha minnel
>tobb fuggvenyem statikus, vagy ha minnel tobb virtualis?
Eloszoris nem statikusak alapban.
Statikus: Osztalyon belul ha egy fuggveny statikus, az azt jelenti,
hogy vonatkoznak ra a lathatosagi szabalyok, de egyebkent egy szimpla fuggven
y.
Tehat pl. hivhato anelkul, hogy peldanyositanad az osztalyt (ez gyakorlatilag
azt jelenti, hogy nem megy at neki rejtve a this).
Virtualis: ezen fuggvenyeket ha feluldefinalod szarmaztatas soran, akkor biztos
itja
a fordito, hogyha van egy peldanyod a szarmaztatott osztalybol, s egy arra mu
tato
pointered, ami a bazis osztaly tipusu, s felhivod a fuggvanyt, akkor a szarma
ztatott
osztaly guffvenye hivodik fel. (igy muksz a polimorfizmus).
Egyeb fuggvenyek: Ezek siman hivodnak. Nincs polimorfizmus, igy ha az os pointe
ren keresztul
hivsz egy fuggvenyt, s az nem volt virtualis, akkor az os fuggvenye hivodik f
el
(mig virtualis eseten a konkret peldany donti el, hogy mi kerul felhivasra)
>Harom tankonyvet neztem att, de mindegyik csak a fentire hasonlo,
>szerintem hibas peldakat hoz fel. Most en bonyolitom feleslegesen
>tul a dolgot, vagy tenyleg ennyire, hulyeseget irnak a konyvek?
>Mert lehet hogy egy profinak ez trivialis, de egy kezdonek nem az.
Az elv helyes. Ha public-ra deklaralsz egy valtozot, akkor azt barki barmikor,
barhonnan modosithatja. Ha irsz hozza egy fuggvenyt, s azon keresztul erik el,
akkor elso lepeskent minden valtoztatas kozpontositva lesz. S hogy ez miert jo
?
Egy szimpla valtozonal nem latni a hatast, de ha annak a valtozonak az erteketo
l
fugg valami, akkor mar evidens, hogy miert van a dolog.
Egy ilyen fuggoseg a fejlesztes soran barmikor elokerulhet, s egyszerubb egy
fuggvenyt modositani, mint megkeresni az osszes ertekadast.
tejfel
ui: ajanlott olvasmany: Bjarne Stroustrup: A C++ Programozási nyelv Kiskapu Kft
. 2001
Magyarul nem tudok mas ertelmes C++-os konyvrol.
(webes bekuldes, a bekuldo gepe: adsl66.226.axelero.hu)
|
+ - | Re: Re: mozgokep (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Hali!
>kézikamerázásra. És ez is miniDV. Csak sajnos 1,3 millió ft.
DV-bol is van tobbfele. A miniDV, ami a kis kamerakban is
van, az 25MB/s, s letezi DVPro talan, az 50MB/s.
> Az analog tevevel valo tokeletes egyuttmokodesbol arra
> kovetkeztetek, hogy a miniDV kamera is ugy kesziti a kepet,
Az en sony kameram is tud progressive-et. Ha szamitogepre keszul
a dolgo mindenkeppen ajanlott a hasznalata (ha tv-re, akkor
nagyon nemajanlott, hisz nem eri meg lemondani az interlace
altal kinalt elonyokrol)
>> monitoron vagy akar 100Hz-es teven probalom visszajatszani,
>> akkor bizony latni, hogy nem az igazi, valahogy nem stimmel.
>Az eltérõ képfrissítési frekvencia okozza a gondot.
Ez azert is erdekes, mert a 100Hz-es tv igazan sokmindent nem csinal
tudtommal, csak duplan villant.
>Mindenesetre a 25 fps jól ki van találva, elég az.
>Az emberi szemnek is van egy adott tehetetlensége, hiába látnál
>te az utcáról egy másodperc alatt 200 képet, a szemed nem tudná
>mindet feldolgozni. Jól ki van ez találva.
Ezzel nem ertek egyet. 25 fps mar nagyon nem eleg, de draga.
(+5 fps mar +20% anyag es utomunka koltseg)
>> Az elozo cikkemben emlitett, va'gyott, esetleges uj szabvany
>> akar 50...100fps-es is lehetne, mert a redundanciat kivonva
>Digitális filmeknél semmi akadálya, úgy kódolod ahogy akarod.
>50-60 fps fölött azért már végképp helypocsékolás lenne a dolog.
Jaja, sztem is a digitalis mozira fog varni a dolog. (mondjuk ami
a MOM parkban van digitalis mozi vimmel, az nagyon tavol all meg
minosegben a szimpla mozitol, igy nem is latom ertelmet)
A tobbi emlitett temaban is. Jelenleg a filmeket 2048*1556-os
felbontasban dolgozzak fel. Idovel atternek majd a dupla ekkora
felbontasra, ahogy megy lefele a feldolgozas koltsege.
tejfel
(webes bekuldes, a bekuldo gepe: adsl66.226.axelero.hu)
|
+ - | Re: C++ (mind) |
VÁLASZ |
Feladó: (cikkei)
|
Sziasztok!
Olyan elkepeszto mennyisegu valaszt kaptam, hogy nem tudok
mindre maganban reagalni, igy ezuton szeretnem megkoszonni
mindenkinek.
Koszonom!
Andras
_______________________________________________________________________
Ha van kedved a kalandhoz, szerelemhez, izgalomhoz, regisztráld
magad adatbázisunkba!
http://szerelem.mailbox.hu
|
+ - | Re: c++ (mind) |
VÁLASZ |
Feladó: (cikkei)
|
, 2003.06.11.
>Korabban javaban lattam hogy minden tagfuggveny virtualis kiveve
>amit a static kukcsszoval statikussa nem nyilvanitunk pl.: a main-t,
>es ez igy jo. Most c++ban azt latom hogy minden tagfuggveny statikus
>kiveve ha kulon a virtual kulcsszoval virtualissa nem nyilvanitjuk,
>es itt meg igy jo. Elmagyarazna valaki hogy, mi a jo nekem, ha minnel
>tobb fuggvenyem statikus, vagy ha minnel tobb virtualis?
szerintem itt keverednek a dolgok.
A C-ben nem letezik olyan hogy "virtualis" fuggveny. A fuggvenyek
globalisan elerhetoek minden modulbol (a rendszered minden *.c fajljabol),
hacsak nem rejted el a tobbi modul elol a static kulcsszoval, amikor csak a
definiciojat tartalmazo modulbol erheto el.
A C++ osztalyokban a tagfuggvenyek lehetnek
1. "kozonsegesek". Gyakori. Semmi tarolasi osztaly nincs megadva, ekkor
szamodra rejtetten megkapjak az osztaly this mutatojat. PL
class Tester {
public:
int Value;
void ShowValue();
Tester(){Value=100;}
Tester(const Tester &t2){*this=t2;}
~Tester(){}
};
A cpp fajlban pedig:
void Tester::ShowValue() //itt utazik egy rejtett this ptr is!!!
{
cout << Value; //ez valojaban cout << this->Value;
}
tehat a kozonseges tagfuggvenyek a this mutato reven hasznalni tudjak az
osztaly egy adott peldanyat amit pl a kovetkezo koddal hasznalhasz ki:
int main()
{
Tester T;
T.ShowValue(); //utazik a &T is !
}
2. statikusak. Ritka mint a szurke hollo. Ilyenkor a fuggveny meghivasahoz
nincs szukseg az adott class egy peldanyara, es nem utazik a this ptr. Ezt
altalaban akkor hasznaljak, ha pl a fuggveny mukodesehez nincs szukseg this
ptr-re (optimalizacio), vagy a terv olyan hogy objektum nelkul kell
mukodnie. Pl:
class Tester {
private:
static int CallCount;
public:
int Value;
void ShowValue();
static int GetCallCount() {return CallCount;}
static const char* GetType() {return "Simple tester";}
static Tester* GetNew () {return new Tester();} //"class factory"
static Destroy(Tester*Obj) {delete Obj;}
};
A cpp fajlban pedig:
int Tester::CallCount=0;
hivasnal akar:
{
Tester* Tp = Tester::GetNew();
Tp->ShowValue();
Tester::Destroy(Tp);
}
3. virtualisak. Gyakori. Teljesitmeny es elvi okokbol csak akkor hasznalunk
ilyet, ha az osztaly egy bazisosztaly lesz orokleshez, es az interfesz
fuggvenynel megvan az eselye hogy azt az orokles soran atdefinialjak. A
hivas ekkor egy fuggveny pointer tablan keresztul zajlik, az oroklodesi
lancban barki kenye-kedve szerint a cserelheti le az interfesz fuggveny
mogott allo kodot. Pl ha Tester-ben
virtual void ShowValue(); -t irunk
class NetworkedTester : public Tester {
public:
int DestAddress;
void ShowValue(); //masik ShowValue megvalositas
NetworkedTester() : Tester() {}
NetworkedTester(const NetworkedTester &t2) : Tester(t2) {*this=t2;}
~NetworkedTester() {}
};
es a cpp fajlban:
void NetworkedTester::ShowValue()
{
ShowNetMsg(DestAddress,Value);
}
akkor Tester objektumokra a korabban mutatott, NetworkedTester objektumokra
ez a fuggveny hivodik meg a pointer tabla alapjan.
1 _oriasi_ hianyossag meg van a fenti peldaban: BAZISOSZTALY DESTRUKTORA
MINDIG VIRTUALIS KELL HOGY LEGYEN. kulonben igen csunya hibak lepnek fel.
tehat Tester javitando:
virtual ~Tester() {}
==========
Tehat c++ ban nem "statikus"-ak a tagfuggvenyek, csak ha static-ot adsz
nekik, ezt azonban tudni kell hogy pontosan mit is jelent.
"mi a jo nekem, ha minnel tobb fuggvenyem statikus, vagy ha minnel tobb
virtualis?"
en nem tudom neked mi a jo, masik programozonak az a jo, ha a problemahoz
igazodva csinalod meg az interfeszt. virtual csak ha orokleshez szanod,
static csak specko esetben.
>A gyakorlati kerdesem is tagfuggvenyre vonatkozik:
>
>A tankonyveim szertint az adattagokat private-ra kell deklarani hogy
>a nagyobb biztonsag erdekeben csak a tagfuggvenyek ferjenek hozza. pl.:
>
>class CProba
>{
> private:
> int x;
> public:
> CProba();
> ~CProba();
> void setX(int x1);
>};
>
>void CProba::setX(int x1)
>{
> x = x1;
>}
>
>Csakhogy ez a megoldas szvsz semmivel sem biztonsagosabb mintha
>public-ra deklaraltam volna az x-et hisz azt adok meg a setX
>parameterenek amit csak akarok.
miert hasznalunk private-ot?
azert mert igy elrejtjuk az implementacio reszleteit (az int X-et), es csak
egy jol kezben tarthato, nem valtozo feluletet adunk annak bizergalasara.
Idaig altalanos a kerdes.
>Ha az eredeti logikat kovetem, akkor a setX eleve
>nem lehet void visszateresu hisz vizsgalni kellene a meghivas helyen
>hogy sikeres volt-e az ertekadas.
ez mar feladat-specifikus problema (kell-e vizsgalat vagy sem, es mit
csinaljunk ha illegalis az ertek). Gyakorlatban az esetek 99%-ban nem kell
vizsgalni, hogy mi az ertek. A fennmarado 1%-ra viszont a c++ elegansabb
modszert kinal a hibakezelesre: a kivetelkezelest.
*.hpp:
#define CPROBA_ERR_ILLEGALX_IN_SETX -100
*.cpp
void CProba::SetX(int NewX)
{
if( NewX >= 100 )
throw new MyException(CPROBA_ERR_ILLEGALX_IN_SETX,"Illegal NewX
(CProba::SetX)");
X = NewX;
}
Elotte celszeru definialni egy MyException osztalyt az egesz projektnek,
valahogy igy:
#define MYEXCEPTION_MAX_MSG_LEN 200
class MyException {
public:
int ErrCode;
char ErrMsg[MYEXCEPTION_MAX_MSG_LEN+1];
MyException() {ErrCode=0;ErrMsg[0]='\0';}
MyException(int NewErCode, const char* NewErrMsg=0);
~MyException() {}
};
es cpp:
MyException::MyException(int NewErCode, const char* NewErrMsg)
{
ErrCode = NewErrCode;
if( NewErrMsg ) {
strncpy(ErrMsg, NewErrMsg, MYEXCEPTION_MAX_MSG_LEN);
NewErrMsg[MYEXCEPTION_MAX_MSG_LEN] = '\0';
}
}
tovabbi lehetosegek: a csunya define-ok eltuntetese namespace-ek es const
int-ek segitsegevel, stb, stb
Jozsi
|
|