Hollosi Information eXchange /HIX/
HIX CODER 1843
Copyright (C) HIX
2003-06-12
Új cikk beküldése (a cikk tartalma az író felelőssége)
Megrendelés Lemondás
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

AGYKONTROLL ALLAT AUTO AZSIA BUDAPEST CODER DOSZ FELVIDEK FILM FILOZOFIA FORUM GURU HANG HIPHOP HIRDETES HIRMONDO HIXDVD HUDOM HUNGARY JATEK KEP KONYHA KONYV KORNYESZ KUKKER KULTURA LINUX MAGELLAN MAHAL MOBIL MOKA MOZAIK NARANCS NARANCS1 NY NYELV OTTHON OTTHONKA PARA RANDI REJTVENY SCM SPORT SZABAD SZALON TANC TIPP TUDOMANY UK UTAZAS UTLEVEL VITA WEBMESTER WINDOWS