Hirdetés

Új hozzászólás Aktív témák

  • Miracle

    senior tag

    válasz Gregorius #100 üzenetére

    :R vagy 1 eve CIL assemblyket irtam(assemblerrel ofkoz) es eskuszom nekem required remlett de hat van ilyen :)

    értelmező késziszótár :: rekurzió --> lásd : rekurzió

  • zoty314

    aktív tag

    Egy gyors kérdés. Melyik osztály melyik függvényével tudom megoldani, hogy egy fájlból szavanként (szóköztől szóközig) olvassak be?

  • Diskcopy

    tag

    válasz zoty314 #102 üzenetére

    Hello! Miért nem olvasol be egy teljes sort aztán darabolod?


    string Olvasott = ''String Manipulation'';
    string [] Split = Olvasott.Split(new Char [] {' '});
    //Eredmény kiírása
    MessageBox.Show(Convert.ToString(Split[0]));
    MessageBox.Show(Convert.ToString(Split[1]));


    Szavanként nem tudom, hogy tudnád olvasni.. Max úgy, hogy karakterenként olvasod, és ha Spacehez érsz, akkor egy új szó jön.

  • zoty314

    aktív tag

    válasz Diskcopy #103 üzenetére

    Mert feltételeztem, hogy ha egy C++ képes erre, akkor a C# is tudja csuklóból.

    De kösz ezt a megoldást is. :)

  • Miracle

    senior tag

    válasz zoty314 #104 üzenetére

    valojaban a c++ joval osszetettebb nyelv, mint a c#, tehat inkabb a c++ tud mindent, amit a c# is tud, nem forditva. nem mellesleg a kerdes amit feltettel nyelvfuggetlen :)
    es en is csak a stringdarabolos megoldas ismerem.

    értelmező késziszótár :: rekurzió --> lásd : rekurzió

  • zoty314

    aktív tag

    válasz Miracle #105 üzenetére

    Ok, akkor elnézést a hülye kérdésért. :) Kösz a választ.

  • Gregorius

    őstag

    válasz Miracle #105 üzenetére

    valojaban a c++ joval osszetettebb nyelv, mint a c#, tehat inkabb a c++ tud mindent, amit a c# is tud, nem forditva
    Például?


    zoty314:

    while( vanmégstring )
    {
    string[] tokens = olvasott.Split(new char[]{' '}, 2);
    string nextToken = tokens[0];
    olvasott = tokens[1]; //ez a maradek
    }

    Vagy ha whitespace mentén (space, újsor, tab, stb...) akarod szétszedni a string-et, akkor a fenti sor kicserélendő erre:

    string[] tokens = olvasott.Split(null, 2);



    [Szerkesztve]

  • Miracle

    senior tag

    válasz Gregorius #107 üzenetére

    Például?
    tobbszoros oroklodes, operator overloading, elegans referenciakezeles, hatekonysagi okokbol opcionalis GC (tobbfele implementacio), templatek, lehetoseg a nyelvi helyett az op.rendszer biztositotta mem.kezeles hasznalatara, parameteratadasnal kovariancia, member-poionterek, aut.tipuskonverzio
    hirtelen tobb nem jut eszembe ;]

    értelmező késziszótár :: rekurzió --> lásd : rekurzió

  • Miracle

    senior tag

    válasz zoty314 #110 üzenetére

    igen.
    persze ettol nem lesz a c++ jobb nyelv, csak nem a do-what-i-mean filozofia menten fejlesztettek, mint a javat meg a c#ot, a cel az volt, a programozonak minden lehetoseget megadni, hogy a leheto legtomorebben es hatekonyabban, legkifejezobben ki tudja magat fejezni. es persze joval tobb hibat is tudjon ejteni, es JOVAL JOVAL nehezebb legyen megtanulni olyan szinten, hogy ne on es kozveszelyes programokat irjon a kedves fejleszto :)

    értelmező késziszótár :: rekurzió --> lásd : rekurzió

  • zoty314

    aktív tag

    válasz Miracle #111 üzenetére

    Azért szerintem a C#-os műveletek túlterhelésének nézz utána, mert lehet. A többihez még nem tudok hozzászólni, de pl. a többszörös öröklődés tényleg nem került bele a nyelvbe a sok hibalehetőség és fejfájás miatt.

  • Miracle

    senior tag

    válasz zoty314 #112 üzenetére

    most eppen c#ban fejlesztek, tudom, hogy van method overloading, en operator overloadingrol beszeltem, pl. sajat osztalyokra ertelmezheted az + operatort (operator+).
    ez nincs c#ban.
    es ha valamit nagyon gyorsra is kene csinalni akkor sincs lehetoseged kezedbe venni a memoriakezelest, engem ez zavar neha :) de a c# is igen remek nyelv, mindossze annyi, hogy nem tudja teljesen kivaltani a c++t, de hat nem is erre keszult.

    értelmező késziszótár :: rekurzió --> lásd : rekurzió

  • Miracle

    senior tag

    válasz zoty314 #114 üzenetére

    uhuh oke :R
    akkor vajon miert nem lattam meg sosem ilyet eles kodban?! eheh
    na mind1 nemtervezem hasznalni ezutansem, de meg komolyan nem talalkoztam vele :)
    mondjuk c#al nemreg foglalkozok :B

    értelmező késziszótár :: rekurzió --> lásd : rekurzió

  • zoty314

    aktív tag

    válasz Miracle #115 üzenetére

    A többire csak azért nem tudok még mit mondani, mert még egy progit sem írtam benne, na jó, komolyabb progit nem.

  • Gregorius

    őstag

    válasz Miracle #109 üzenetére

    Nah akkor rögtön:
    operator overloading
    templatek
    aut.tipuskonverzio
    És ezeket miért is nem tudja a C#?

    lehetoseg a nyelvi helyett az op.rendszer biztositotta mem.kezeles hasznalatara
    Nem tudom, a C mióta csinál memóriakezelést.

    hatekonysagi okokbol opcionalis GC (tobbfele implementacio)
    Ezt miért tartod szükségesnek?

    elegans referenciakezeles
    Nem tudom, mi nem elég elegáns rajta.

    parameteratadasnal kovariancia
    Ez valóban jól jött volna néhány esetben. Majd megcsinálják a 3.0-ban. Szerencse, hogy template-ekkel megoldható.

    a programozonak minden lehetoseget megadni, hogy a leheto legtomorebben es hatekonyabban...
    ...tudja elcseszni a programot :D

    [Szerkesztve]

  • Miracle

    senior tag

    válasz Gregorius #117 üzenetére

    templatek
    igen, a 2.0ban mar vannak, de nem olyan osszetettek, mint a c++ban levok.

    Nem tudom, a C mióta csinál memóriakezelést.
    a malloc/free es a new/delete tekintheto nyelvi eszkoznek a memoria kezelesere, de akar windowson akar linuxon problemas veluk 1 GBytenal nagyobb mennyisegu memoriat kezelni, es lassuak is.

    hatekonysagi okokbol opcionalis GC (tobbfele implementacio)
    Ezt miért tartod szükségesnek?

    azert, mert a GC sajnos esetenkent nem elhanyagolhato ovreheadet jelent, es nem-szintetikus-tesztek eseten (amikor csinalunk ugyan abbol 50000 peldanyt mondjuk) lassabb lesz, raadasul ugy a .NET mint a java GCa elegge alkalmatlanna teszi a nyelvet realtime mukodesre, mert nincs definialva, hogy mikor collectel. presze, ki lehet kenyszeriteni, es ha te akarod ugy intezni, hogy a kritikus idopontokban NE kezdjen el gyujtogetni akkor joval bonyolultabb kodot is kaphatsz. persze ez az kis teljesitmenytoblet az esetek nagy tobbsegeben valoban kicsi, es megeri GCt hasznalni, de igy, hogy kotelezo lett, a juzer elesik a placement-new hasznalatatol, ami eleg komoly fegyverteny tud lenni bizonyos esetekben. persze sima, semmilyen kulonleges igenyt nem tamaszto feladathoz nyilvan tokeletes megoldas barmilyen GC, mert az esetek nagy tobbsegeben inkabb mem.leakeket szuntet meg, mintsem problemat okozzon.

    elegans referenciakezeles
    Nem tudom, mi nem elég elegáns rajta.

    hat ha visszanezunk a programozasi nyelvek tortenetere, akkor eloszor jott a valtozofoglalas, ami nev, es memoria. aztan jott a memoria, amihez nem tartozik nev. aztan jottek ilyen olyan probalkozasok (pl. smalltalk) amibe nem mennek bele, de lenyeg az, hogy a c++ nyelvben lehetett eloszor ertelmesen uj nevet bevezetni hozza tartozo memoriaterulet foglalasa nelkul. es ezt 1 darab operatorral oldottak meg, ami minden esetben elegseges volt az egyertelmu kifejezeshez. c#ban eltunt ez a szep, egyseges, elegans megoldas.

    a programozonak minden lehetoseget megadni, hogy a leheto legtomorebben es hatekonyabban...
    ...tudja elcseszni a programot

    igen, en is odairtam, hogy az esetek nagy tobbsegeben a c++ bovebb feature-listajat a programozok gyakran inkabb bugtenyesztesre hasznaltak, mint elegans kod keszitesere, megegyszer mondom, en a nyelv osszetettsegerol, es nem az eletkepessegerol/hasznalhatosagarol beszeltem :DDD

    értelmező késziszótár :: rekurzió --> lásd : rekurzió

  • zoty314

    aktív tag

    Hát, srácok, most viccen kívül, örülök, hogy így vitatkoztok ezen. Legalább megtudok 1-2 dolgot én is. Érdekel és többet ér mint egy egyetemi előadás. :D Csak így tovább, hajrá. Azért a végén egyezzetek meg az egyes pontokban, meg figyelmesen olvassátok el egymás szövegét, mert néha picit egymás mellett elbeszéltek. :D

    [Szerkesztve]

  • Miracle

    senior tag

    válasz zoty314 #119 üzenetére

    ennek orulok, de azert illik mindent kello szkepticizmussal kezelni, es/vagy utanaolvasni annak ami itt elhangzik :)
    es felterjesztem megegyezesre, hogy altalanos celu alkalmazasfejlesztesre a c# bizony alkalmasabb nyelv ;)

    értelmező késziszótár :: rekurzió --> lásd : rekurzió

  • zoty314

    aktív tag

    válasz Miracle #120 üzenetére

    Természetesen nem hiszek el mindent, amit mondanak vagy leírnak, szóval ezeket sem teljesen. :D

  • Gregorius

    őstag

    válasz Miracle #118 üzenetére

    a malloc/free es a new/delete tekintheto nyelvi eszkoznek a memoria kezelesere
    A malloc/free nem tekinthető, az runtime library. A new/delete inkább, de azok is a malloc/free-re vannak visszavezetve, szóval csak ún. szintaktikus édesítőszerek. Ráadásul nem is kifejezetten a te programod, hanem az oprendszer része a kérdéses RT, úgyhogy effektíve akkor cseréli ki alattad a microsoft, amikor neki tetszik. (Volt már ebből problémám, hogy a letöltött program csak nem akart futni, aztán kiderült, hogy egy régebbi RT-vel linkelték, úgyhogy újra kellett fordítanom, hogy rendesen együttműködjön a többi komponenssel)

    azert, mert a GC sajnos esetenkent nem elhanyagolhato ovreheadet jelent, es nem-szintetikus-tesztek eseten (amikor csinalunk ugyan abbol 50000 peldanyt mondjuk) lassabb lesz
    Meg kell tanulni hatékonyan GC alá programot írni. Gondolom az ember a hagyományos programját sem tűzdeli tele folyamatos objektumallokációkkal.
    Ráadásul a GC a programtól függetlenül cserélhető, ezért mire kitaláltál egy jobb GC algoritmust vagy netán megoldottad manuális memóriakezeléssel, addigra kapsz egy jobban optimalizált GC-t, amely ráadásul az összes programhoz használható.
    Egyébként ha összevissza allokálsz mindent, azt a heap sem tolerálja valami jól.

    a .NET mint a java GCa elegge alkalmatlanna teszi a nyelvet realtime mukodesre, mert nincs definialva, hogy mikor collectel.
    A windows önmagában alkalmatlan hard real time működésre GC-vel, vagy anélkül. Viszont soft real time működés nyugodtan megvalósítható a GC jelentette bizonytalanság mellett, az átlagos idők ugyanúgy mérhetőek, mint bármelyik másik alkalmazás esetén. Ha meg a rendszer elkezd vergődni, akkor tényleg végképp mindegy, hogy GC vagy nem GC.
    Persze kétségtelen, hogy a .NET teljesítményben egyelőre elmarad a natív C-től (és megsúgom, előzetes mérések szerint a .NET 2.0 Math könyvtára gyengébb lesz, mint az 1.1-é). De egyrészt aki powah rutinokat akar írogatni, az kódolja le az érzékeny részeket ASM-ben, másrészt ez nem szorosan a nyelv függvénye, hanem a JIT-é és a framework-é.

    es ha te akarod ugy intezni, hogy a kritikus idopontokban NE kezdjen el gyujtogetni
    Akkor szépen meghívod előre a GC-t, hogy na akkor gyűjtsön most, megvárod amíg begyűjt (WaitForPendingFinalizers), aztán végrehajtod a kritikus részt. Közben persze C-ben sem nagyon tudsz objektumokat allokálgatni, mert a heap sem a kiszámíthatóságáról híres, már ami az allokációt érinti. Egy esetben lehet értelme a dolognak, ha az ember C++-ban mindent a stack-re allokál, de akkor inkább maradjon a sima C-nél. (Találkoztam már olyan emberrel, aki tervezési elvi alapon teljesen hanyagolta a heap-et a kiszámíthatatlansága miatt)
    A GC az alapból alacsony prioritáson fut, úgyhogy a CPU-intenzív working thread-eket nem nagyon zavarja, viszont ha vészesen fogy a fizikai memória, akkor realtime prioritással pillanatokon belül ledarálja az összes szemetet.
    Egyébként döbbenetes, hogy a GC algoritmusokat milyen durván optimalizálják. Pl. ha jól tudom, a .net-es adaptálódik a processzor cache méretéhez, úgyhogy a 0. generációban felszabadított objektumok többsége lényegében sosem kerül ki az L2 cache-ből, így kegyetlen gyors tud lenni.

    a c++ nyelvben lehetett eloszor ertelmesen uj nevet bevezetni hozza tartozo memoriaterulet foglalasa nelkul. es ezt 1 darab operatorral oldottak meg, ami minden esetben elegseges volt az egyertelmu kifejezeshez. c#ban eltunt ez a szep, egyseges, elegans megoldas.
    Még mindig nem értem. Írsz egy C++ példát, hogy mi annyira jó miben?

    többszálú öröklődés...
    en a nyelv osszetettsegerol, es nem az eletkepessegerol/hasznalhatosagarol beszeltem
    Én ezt inkább összefércelésnek hívom, mint összetettségnek, de ízlés kérdése. Az ilyen programozói agyelszállások inkább az interoperabilitás illetve a kódújrafelhasználás szempontjából fontosak.

    szkepticizmussal kezelni, es/vagy utanaolvasni
    És megcáfolni, ha nincs igazunk! :D

    es felterjesztem megegyezesre, hogy altalanos celu alkalmazasfejlesztesre a c# bizony alkalmasabb nyelv
    Ebben egyetértünk. Bár ez akár a 6-os vagy régebbi Visual Basic-re is mondható (inkább mint platformra a mindenféle designerjével), az pedig egy bűn rossz nyelv, mégis egy-két évvel ezelőtt többen használták, mint a C-t :Y.

    [Szerkesztve]

  • Miracle

    senior tag

    válasz Gregorius #122 üzenetére

    A malloc/free nem tekinthető, az runtime library.
    resze a standard libnek, legalabb annyira a nyelv resze, mint a System.GC vagy mindketto, vagy egyik sem ;] persze lattam mar olyan C forditot, ami nem tamogatta, de az a szoftver, amit azzal forditottak vonatvezerlo volt, ott pedig 0 bizonytalansagnak van helye :)

    Meg kell tanulni hatékonyan GC alá programot írni. Gondolom az ember a hagyományos programját sem tűzdeli tele folyamatos objektumallokációkkal.
    hat... NAGYON nagy projektek eseten eleg komoly aldozatokat kell meghozni az erthetoseg, es a csapatmunka oltara, es tobb, kisebb funkcionalitast megvalosito osztaly, amiket esetleg gyakrabban kell cserelni/letrehozni osszessegeben megiscsak megterulhet. szoval a hatekonysag neha utolso szempont, hogy 1000 ember is tudjon egyutt dolgozni, es ekkor igen hasznos technikak allnak a c++ programozok rendelkezesere, hogy a kodot a rendszer megvaltoztatasa nelkul tegyek hatekonyabba (PIMPL, palement/new stb... ilyenekbol tenyleg sok van).

    igen, GC programtol fuggetlenul cserelheto... ja varj... c++ ala ismerek vagy 6 GCt, es mar 4et hsznaltam... mennyit is ismerek c# ala? egyet? van egyaltalan masik? lehet NEKEM is cserelnem? (rotor, mono nemjatszik :) )

    De egyrészt aki powah rutinokat akar írogatni, az kódolja le az érzékeny részeket ASM-ben, másrészt ez nem szorosan a nyelv függvénye, hanem a JIT-é és a framework-é.
    hat CIL ASMel nem megyunk sokra, masfele ASMet meg nem illik :)
    a JITek meg igen komoly fejlodesen mentek mar keresztul, de naiv gondolat azt hinni, hogy egy rendes fordito optimalizacios kepessegeit valaha is elerheti. esetleg megkozelitheti :)

    Akkor szépen meghívod előre a GC-t, hogy na akkor gyűjtsön most, megvárod amíg begyűjt (WaitForPendingFinalizers)
    ez lesz csak a szep meg a hatekony kod :) az a baj, hogy a durvan optimalizalt GC mem.kezeleset elegge hasravagja az ilyen.

    Egyébként döbbenetes, hogy a GC algoritmusokat milyen durván optimalizálják. Pl. ha jól tudom, a .net-es adaptálódik a processzor cache méretéhez, úgyhogy a 0. generációban felszabadított objektumok többsége lényegében sosem kerül ki az L2 cache-ből, így kegyetlen gyors tud lenni.
    a m$nal volt kis vita, hogy a rotorba beletegyek-e a rendes .NET runtime GCat, es ha jol tudom vegulis az dontotte el a kerdest, hogy valami eszmeletlenul bonyolult, es feltek, a budos eletben senki nem ertene meg a mukodeset, es az egesz rotornak nem ez a celja :)

    Még mindig nem értem. Írsz egy C++ példát, hogy mi annyira jó miben?
    nem, nem irok peldat, ez puszta elegancia kerdese, a c++ egy igen igenyes megoldast adott a problemara, a c# meg visszalepett egyet, es nem olyan igenyes megoldast adott. persze ez hasznalhatosag szempontjabol nem sokat jelent, a koder altalaban el tudja donteni, hogy parametert vesz at, vagy csak ugy referenciat keszit, ez pusztan szepseg kerdese :)

    többszálú öröklődés...
    hat igen... egy szoval nem mondtam, hogy a tobbszalu oroklodes jo dolog, ez is csak 1 tipikus pelda a ket nyelv kozotti tervezesi filozofia kulnbsegere:
    a: minden lehetoseget megadni a programozonak, hogy azt csinaljon amit tud
    b: olyan lehetosegeket adni a programozonak, ami az esetek 98%ban elegendo, igy konnyen tanulhato, egyszerubb, es hetkoznapi hasznalatra alkalmasabb nyelv jon letre.

    Bár ez akár a 6-os vagy régebbi Visual Basic-re is mondható (inkább mint platformra a mindenféle designerjével), az pedig egy bűn rossz nyelv, mégis egy-két évvel ezelőtt többen használták, mint a C-t .
    amikor azt mondod hogy C akkor c++ra is gondolsz ?!?!?! ez halal komoly?! a windows programozas rejtelmeibe az egeszen kozeli multig nem nagyon volt betekintesem, ha valami nagyon kellett, akkor is QT+mingw vagy java ment, a nativ windows programozas kimaradt az eletembol... ez azert eleg durva :)

    de ha mar itt vagyunk van valami otleted, hogyan kellene 1 c# programbol figyelni arra, ha az user egy filet (amit mondjuk masodpercenkent fel kell dolgozni, de nem tarthatom lefoglalva, mert akkor nem kerul bele amit fel kell dolgozni) masik konyvtarba mozgat? FileSystemWatcher-el odaig jutottam, h atnevezest (konyvtaron beluli mozgatast) mar elkapom, de amint kilep a konyvtarbol buktam a filet, hacsak nincs watcher allitva a celkonyvtarra is, de ez nem megoldhato... szoval otlet?

    értelmező késziszótár :: rekurzió --> lásd : rekurzió

  • Gregorius

    őstag

    válasz Miracle #123 üzenetére

    resze a standard libnek, legalabb annyira a nyelv resze, mint a System.GC
    A GC sem a nyelv része, hanem a platformé.

    naiv gondolat azt hinni, hogy egy rendes fordito optimalizacios kepessegeit valaha is elerheti
    Épp ellenkezőleg. A JIT-nek van lehetősége a futtató processzor architekturális sajátosságait, spéci utasításkészleteit kihasználni. A ''rendes'' C-fordítóknak pedig az összes megcélzott architekturával kompatibilis kódot kell generálniuk.

    az a baj, hogy a durvan optimalizalt GC mem.kezeleset elegge hasravagja az ilyen.
    Nah, csak a statisztikáit. :D Általában nincs is rá szükség, de ha tudod, hogy utána egy igen sok memóriát igénylő folyamat következik, akkor célszerű előre takarítani.

    nem, nem irok peldat, ez puszta elegancia kerdese, a c++ egy igen igenyes megoldast adott a problemara
    Most már sosem tudom meg, mi ez a fantomelegancia, amiről beszélsz :O :D

    amikor azt mondod hogy C akkor c++ra is gondolsz ?!?!?! ez halal komoly?!
    Igen. Sajna az. Nem tudom, pontosan mi volt az előd, de a VB előtt sem a C/C++ volt a top. Sok az amatőr programozó a világban...

    c++ ala ismerek vagy 6 GCt, es mar 4et hsznaltam... mennyit is ismerek c# ala?
    Jogos. Sőt, C++-ban írhatsz akár saját mem.mgr-t is. Viszont az velük a probléma, hogy amint két program interfészel egymással rögtön ott a kérdés, hogy mi van, hogy ha különböző memóriamanagert használnak?

    FileSystemWatcher-el odaig jutottam, h atnevezest (konyvtaron beluli mozgatast) mar elkapom, de amint kilep a konyvtarbol buktam a filet, hacsak nincs watcher allitva a celkonyvtarra is, de ez nem megoldhato... szoval otlet?
    Lehet próbálkozni azzal, hogy arra állítod a FSW-t, hogy subdireket is monitorozzon, de ha nem tudod, hogy a fájl potenciálisan hova fog kerülni, akkor csak úgy kaphatnád el, ha monitoroznád az egész partíciót, de iszonyatosan nagy overhead kiválogatni, hogy téged melyik fájl érdekel. A másik megoldás a kernel hook, de az meg nagyon ronda.
    Egyébként a fájlt nyitva tarthatod shared write módban is (FileShare.ReadWrite). Ilyenkor más is tud bele írni, csak törölni nem lehet. (áthelyezni lehet, hogy igen, nem tudom, de ettől nem válik invaliddá a file handle)

  • Miracle

    senior tag

    válasz Gregorius #124 üzenetére

    A GC sem a nyelv része, hanem a platformé.
    a malloc is a platform resze :) szoval ha a GC MINIMALIS kiszamithatosagat/vezerelhetoseget is tekintetbe vesszuk, akkor a malloc is jar, mint ,,alap'' szolgaltatas. de felreteve az elvi vitat, eleg ertelmetlen a nyelvrol platform nelkul beszelni :)


    Épp ellenkezőleg. A JIT-nek van lehetősége a futtató processzor architekturális sajátosságait, spéci utasításkészleteit kihasználni. A ''rendes'' C-fordítóknak pedig az összes megcélzott architekturával kompatibilis kódot kell generálniuk.
    hat... igazabol a kodok teljesitmeny-kritikus reszet, normalis programozo sok sok architekturara leforditja :) szoval ez nem igazi elony, szerintem sokkal nagyobb fegyverteny az, hogy a kod joval nagyobb egeszet atlatja a fordito, es az optimalizacio elvegzesere is tobb ideje van.

    Most már sosem tudom meg, mi ez a fantomelegancia, amiről beszélsz
    na akkor volt eloszor az automatikus valtozo: egyszerre foglalsz memoriateruletet, es valtozonevet
    aztan lehett foglalni kulon memoriateruletet.
    aztan a c++ oldotta meg eloszor, hogy NEVET lehessen foglalni, tarterulet nelkul.
    c#ban is van lehetoseg azonos fonkcionalitas megvalositasara, de nem ilyen szep, elegans, programozaselmeleti szempontbol is szep megoldas.

    Viszont az velük a probléma, hogy amint két program interfészel egymással rögtön ott a kérdés, hogy mi van, hogy ha különböző memóriamanagert használnak?
    hat igen, ezzel elegge meg lehet szopni :) persze amikor egy modult tobb projektben torteni felhasznalasra terveznek akkor erre figyelni kell.

    [Filekovetes]
    hat igen, ez lehet az en hulyesegem, de nem szeretek csak azert nyitva tartani fileokat, hogy ne veszitsem el oket ha elmozhatjak. szoval lehet hogy osszetakolt az az egesz unix vilag, de hogy mit meg nem adnek most egy rohadt i-node szamert .NET alatt... :))

    [Szerkesztve]

    értelmező késziszótár :: rekurzió --> lásd : rekurzió

  • Gregorius

    őstag

    válasz Miracle #125 üzenetére

    igazabol a kodok teljesitmeny-kritikus reszet, normalis programozo sok sok architekturara leforditja
    A különbség a kettő között az, hogy a programozó arra fordítja le, amit ő támogat, aztán kiadja a programot. A .NET esetében meg először kiadják a programot, aztán lehet, hogy két év múlva előkerül egy überfrankó architektura, amire aztán a .NET tud fordítani, és egyből fut a felturbózott program.
    A programozónak viszont elő kell vennie a régi programját. Plusz neki kell arról is kell gondoskodnia, hogy a megfelelő rendszerképességeket felismerje és az annak megfelelő modult töltse be.

    a kod joval nagyobb egeszet atlatja a fordito, es az optimalizacio elvegzesere is tobb ideje van
    Miért látná át nagyobb egészét? A C fordító a legáltalánosabb dolgokon kívül semmit nem tud a célplatform hardver- és szoftverkörnyezetéről. Optimalizálni valóban több ideje van (és ezt az időt ki is használja alaposan, amilyen lassúak a C fordítók...), azonban a JIT-nek több információ áll rendelkezésére ugyanezen feladatok elvégzéséhez. És akár még teljesítményinfókat is gyűjthet (hasonlóan a processzorok elágazásbecsléséhez P1 óta)

    na akkor volt eloszor az automatikus valtozo: egyszerre foglalsz memoriateruletet, es valtozonevet
    aztan lehett foglalni kulon memoriateruletet
    aztan a c++ oldotta meg eloszor, hogy NEVET lehessen foglalni, tarterulet nelkul
    1: int i;
    2: void *p = malloc(...);
    3: int& i;
    Jól gondolom, hogy ezekről beszélsz?

    persze amikor egy modult tobb projektben torteni felhasznalasra terveznek akkor erre figyelni kell
    Ezt mondd azoknak, akik public domain-be rakják a kreálmányaikat. ;)

    mit meg nem adnek most egy rohadt i-node szamert .NET alatt...
    Akkor nem lesz fájlrendszer-független a programod.
    Ha muszáj, esetleg érdemes a Distributed Link Tracking Client szolgáltatásba beleásódni, az csinál olyasmi követést NTFS rendszeren, amit szeretnél, de ez természetesen FAT/FAT32-n nem működik, szóval nem jó erre alapozni.
    Bővebben: link
    A Platform SDK-ba kell beleásódni.

    [Szerkesztve]

  • Miracle

    senior tag

    válasz Gregorius #126 üzenetére

    A programozónak viszont elő kell vennie a régi programját. Plusz neki kell arról is kell gondoskodnia, hogy a megfelelő rendszerképességeket felismerje és az annak megfelelő modult töltse be.
    ezzel az a baj, hogy a: ezt mar gyakran nem is kell a programozonak megcsinalnia, mert a fordito elhelyez bizonyos kodreszletekbol tobb fele optimalizalt valtozatot a forditasi direktivak alapjan. masfelol ha megnezed, egy rendes fordito mennyit kepesz szarakodni egy nem is olyan nagy kodon, ennyi ideje egy JITnek nem lesz... szoval igen, elmeletben tobb infoja van, gyakorlatilag nem vagyok meggyozve, hogy a JIT algoritmusokat valaha is tudjak odaig finomitani, hogy versenykepes sebesseget nyujtanak. persze ez is egy olyan dolog, hogy time will tell :)
    amugy meg valaki aki powerappot fejleszt szepen forditsa csak ujra idonkent es disztributolja a binarisokat, ez nem pelda nelkuli dolog.

    Miért látná át nagyobb egészét?
    ugye nem gondoltad, hogy komolyan teljesitmenyigenyes szoftvereket a hagyomanyos object-modellel forditanak? ;)

    (hasonlóan a processzorok elágazásbecsléséhez P1 óta)
    hat ez most lehet hogy nagy belekotes lesz, de mar a P1 elott is volt ilyen, igaz nem x86on.

    Jól gondolom, hogy ezekről beszélsz?
    igen, a c#ban uj nyelvi elemet vezettek be a referencia szerinti parameteratadashoz.

    Ezt mondd azoknak, akik public domain-be rakják a kreálmányaikat.
    kellene valami ECPSEL (Europen Computer Programming and Software Engineering License) szoval tenyleg eleg gaz arcok vannak, errol oldalakat lehetne irni, gondolom mindankinek megvannak a maga tortenetei :)
    (amugy websphere erre is ad megoldast ;] )

    Akkor nem lesz fájlrendszer-független a programod.
    nemerdekel, csak windows NT alapu szervereken fog futni, az NTFS levaltasa meg nincs tervbeveve a pico & puha cegnel.
    a shared megnyitvatartassal meg az a haz, hogy a cegnel mar mukodik egy meglehetosen stabil, es nagyon nagy rendszer, es az en kicsi programomnak e melle kellene befekudni, ugy, hogy ne nagyon zavarja a masik, tenyleg nagy programot... eredetileg annak a moduljakent akarta a ceg megiratni ezt a kiegeszitest, csak mondtuk hogy az nem volna okos gondolat.
    amugy egy sokkal elegansabb megoldast talaltam a problemara: kiegeszitettem a specifikaciot, hogy csak az adott directoryn belul mozgathato a file ;];];]

    értelmező késziszótár :: rekurzió --> lásd : rekurzió

  • Gregorius

    őstag

    válasz Miracle #127 üzenetére

    a fordito elhelyez bizonyos kodreszletekbol tobb fele optimalizalt valtozatot a forditasi direktivak alapjan
    És ennek eredményeként ugyanaz a kód hatszor lesz benne a programban. Vagy ha az #if-#endif-es direktívákra gondoltál, akkor annak a különböző ágaiban is meg kell írnia valakinek a megfelelő optimalizált programot.

    ugye nem gondoltad, hogy komolyan teljesitmenyigenyes szoftvereket a hagyomanyos object-modellel forditanak? ;)
    De azokat nem is multiplatformos környezetbe szánják.

    ha megnezed, egy rendes fordito mennyit kepesz szarakodni egy nem is olyan nagy kodon
    Ennek inkább az eléggé elavult C fordítási modell az oka, de mégha ezt figyelmen kívül hagyjuk, akkor is erősen nyelvfüggő, hogy egy fordító milyen tempóban dolgozik. Pl. a VB.NET-es fordító érezhetően lassabb a C#-énál, pedig még emberi ésszel is simán lehet sorról sorra konvertálni a két nyelv között, és a célplatform is megegyezik.

    gyakorlatilag nem vagyok meggyozve, hogy a JIT algoritmusokat valaha is tudjak odaig finomitani, hogy versenykepes sebesseget nyujtanak
    Tényleg nehéz hosszútávon megjósolni, hogy mi lesz belőle, de ahogy egyre gyorsul a vas, egyre inkább előtérbe kerülni látszik a GC meg a JIT. Már 94-ben is igen komoly algoritmusok léteztek pl. GC ügyben, de akkor még olyan overhead-et jelentett a processzoroknak, hogy gyakorlatban nem nagyon volt értelme használni. Hol volt akkor még a Java? Sehol. Azóta bőven megduplázódott a JRE által fordított programok teljesítménye is. (Azért nem a .NET-et hozom fel példának, mert amögött még nincs elég nagy történelem).
    Most meg már van izom vas, sőt jönnek a dual-core procik, ami már kimondottan előnyös a GC-nek is. Aztán szépen lassan eljutunk odáig, hogy 1-2% a különbség.
    Persze azt sem szabad elfelejteni, hogy a JIT az nem a text forráskódon dolgozik, úgyhogy legalább egy igen költséges parszolást megtakarít.

    Jól gondolom, hogy ezekről beszélsz?
    igen

    Akkor pár korrekció.
    Az 1. eset tökazonos C-ben és C#-ban
    A 2. eset megoldható az IntPtr-rel és a Marshal class-szal, nagyjából ugyanakkora méretű kódban, csak az átlag programozót rendszerint seggbe rúgják érte. Ha stílusosan akar az ember ''típustalan'' bulk memory-t foglalni, akkor ott a MemoryStream. Igény szerint előre rögzíthető, hogy mekkora terület legyen.
    A 3. eset is foglal memóriát, nem csak nevet, merthogy a referencia csak egy szintaktikai elem, pointerre alakítja át a fordító (x86-32-n 4byte), szóval ez a háttérben gyak. ugyanaz, mint a 2.
    C#-ban a value type-ok (struct) nem tudják ezt egyedül szépen (típusosan) megcsinálni, csak boxinggal, minden más (class) referenciaként van átadogatva mindenhol. Vagy ki lehet explicit írni a hívásban, hogy ref. Szerintem ez nem baj, legalább a hívásnál is látszik, hogy a kérdéses függvény babrálni fogja az értéket, hülyebiztos a megoldás. (megmondom őszintén, én még sohasem használtam C#-ban a ref kulcsszót, pedig már programozok egy ideje)

    eredetileg annak a moduljakent akarta a ceg megiratni ezt a kiegeszitest, csak mondtuk hogy az nem volna okos gondolat.
    Háát, hozzáhegeszteni egy meglévő rendszerhez általában bonyolultabb, mint bővíteni. Úgy legalább lehet, hogy nem kellett volna konkurálni a fájlért.

    kiegeszitettem a specifikaciot, hogy csak az adott directoryn belul mozgathato a file
    :D:D:D

    [Szerkesztve]

  • Miracle

    senior tag

    válasz Gregorius #128 üzenetére

    És ennek eredményeként ugyanaz a kód hatszor lesz benne a programban. Vagy ha az #if-#endif-es direktívákra gondoltál, akkor annak a különböző ágaiban is meg kell írnia valakinek a megfelelő optimalizált programot.
    nem a preprocesszorra gondoltam, hanem jelezni a forditonak, hogy ezen a kodreszleten elmelkedjen kicsit tobbet, legyen belole egyszalu, tobbszalo, SSEs, SSE2es, stbstb...

    De azokat nem is multiplatformos környezetbe szánják.
    jo, hat akkor most eljutottunk oda, hogy akkor csak nem lesz a c# sosem olyan gyors, a c++ meg olyan rugalmas, de ezt nagyjabol az elejen is tudtuk :)

    Ennek inkább az eléggé elavult C fordítási modell az oka
    igaz, a Ct is, de foleg a c++t NAGYON nehez parsolni, az igazi implementacio LL{infinity} volna, habar ettol el szoktak tekinteni a forditofejlesztok :)

    Tényleg nehéz hosszútávon megjósolni, hogy mi lesz belőle, de ahogy egyre gyorsul a vas, egyre inkább előtérbe kerülni látszik a GC meg a JIT.
    a GCokkal tokeletesen egyetertek, a JITek meg meg elegge el vannak jelen pillanatban maradva, hogy ez a kerdes ne doljon el iden :)
    csak tudod leggujabb intel fordito szekvencialis kodbol csinal tobbszalu kodot, HThez, es valodi tobbutas rendszerhez is kulon, mindemellett alapbol fordit minden kodot SSEre es FPUra (mar ahol ennek van ertelme ugye) es mindkettot bedrotozza az ojjekt fileba, majd futas idoben dont processzor alapjan h melyik a jo valtozat. arrol meg nem is beszelve, hogy ha nem fortrant hasznalunk akkor kb. az intel az egyetlen x86 fordito, ahol assembly betetek nelkul ertelmes SIMD kod szuletik. raadasul az intel fordito teljesitmenyben meglehetosen a konkurencia elott jar (most talan van valami AMDs fordito is, amit fuggetlen ceg fejleszt, es asszongyak h suti cucc lett, meg nem neztem meg) de ettol egy lepcsovel lejjebb van a gcc es MS forditok, es meg ezeknel is joval lassabb a JIT. szoval ha hirtelen leallnanak a hagyomanyos forditok fejlesztesevel, meg akkor is hosszu hosszu evekbe telne mire a JITek versenykepesse valnanak a gccvel, ill. mS forditokkal, es az elvonaltol meg akkor is messze lesznek.

    Akkor pár korrekció. [referenciakrol]
    nem ideztem be mindent, de eppen errol beszeltem, hogy ming c++ alatt erre egy nyelvi elem van, es gyakorlatilag ugyan az a szemantika mukodik parameteratadasnal, mint sima referencia letrehozasakor, mig c# alatt nem. (value type vs osztalyok a heapen)
    amugy utalom a boxing kifejezest, mi a francert nem lehet wrappernek mondani, mint ahogy mar 20 eve mindenki mondja a hasonlo szerepu osztalyokat...

    Háát, hozzáhegeszteni egy meglévő rendszerhez általában bonyolultabb, mint bővíteni. Úgy legalább lehet, hogy nem kellett volna konkurálni a fájlért.
    eppen ez az, hogy a kiegeszitesnek csak olvasnia kell a textfilet, es az alapjan dolgozni, a nagy rendszertol fuggetlenul. a nagy rendszernek meg kb. a rendszertervet ertettem volna meg annyi ido alatt, mint ahogy elkeszitettem ezt a programot es ha modulban gondolkozok akkor figyelnem kell egy par dologra, amiket igy megusztam, az user eddig nem pampogott, es sztem nem is fog, mert jol mukodik amit kapott :)

    értelmező késziszótár :: rekurzió --> lásd : rekurzió

  • Gregorius

    őstag

    válasz Miracle #129 üzenetére

    amugy utalom a boxing kifejezest, mi a francert nem lehet wrappernek mondani
    Mert a wrapper a becsomagoló objektum neve, a boxing meg a műveleté. ;) Meg ha már mindenáron meg akarjuk különböztetni, akkor még ilyen lényegtelen különbségek vannak a wrappelés és a boxing között, hogy az előbbi rendszerint explicit módon történik, az utóbbit implicit elintézi a fordító, ahol lehet.
    Nem utolsó sorban, a wrapper class valamilyen durvább különbséget hidal át két komponens között (pl. managed-unmanaged), a boxing meg nem.

    [Szerkesztve]

  • Miracle

    senior tag

    válasz Gregorius #130 üzenetére

    boxing vs wrapper class
    igaz, a wrapping eleg szokatlanul hangzik, de a java scennek megfelelt par evig :)
    amugy az erveleseddel az a baj, hogy valoban ket kulonbozo dologrol van szo, de nem okozhat felreertes, mert a szovegkornyezetbol egyertelmuen kiderul, hogy melyik jelentesre vagyunk kivancsiak. szoval ez kicsit ilyen risc-vs-cisc vita szeru dolog, hogy majdnem ugyanarra kell-e meg egy szo ;] es ugye tudjuk, hogy a m$ milyen processzorokon tud piaci eredmenyeket felmutatni ;];];]
    najo ez szar vicc volt, lenyeg az, hogy a ket jelentes keverese a wrapper szo hasznalataval sem okozott ertelmezesi problemat az elmult ~10 evben, ez megint csak egy affele m$os ki-ha-en-nem hozzallas eredmenye, ami engem bosszantani szokott.
    az is nagyon felbosszantott, amikor olvastam a c# ref.manual bevezetojet... szoval az elso 3 oldal arrol szol, hogy igazabol a c#ot valojaban sok sok programnyelvbol kopiztak ossze, es hogy szerintuk ezzel nincs semmi baj. (szerintem sem, ez az elso nyelveket leszamitva sosem igy tortent) es fel is soroltak a szoveg kozben ilyen olyan nyelveket, amiktol atvettek dolgokat.
    kitalalod, melyik az az EGYETLEN nyelv, ami hianyzott a szovegbol, mint nagy elod?

    értelmező késziszótár :: rekurzió --> lásd : rekurzió

  • Miracle

    senior tag

    GC vs malloc : Bővebben: link
    erdemes elolvasni, summa summarum nagyon vegyes es sokretu tesztek utan arra jutottak, hogy generacio GC rendszerek 5* akkora memoriaval tudnak olyan sebesseget elerni, mint manualis mem.kezelessel, ha nem all ennyi memoria rendelkezesre akkor az eredmeny romlik eleg meredeken. persze a fejlesztes idejerol es a mem.leakekrol nem szol az iromany, ez pusztan sebessegteszt, nem kell masra kovetkeztetni belole, csak a .NET meg a Java jovojere a powerappok teruleten :>

    értelmező késziszótár :: rekurzió --> lásd : rekurzió

  • Gregorius

    őstag

    válasz Miracle #132 üzenetére

    Amint hazaértem, elolvasom, csak RDP-n keresztül kicsit komplikált :D

    Addig egy kérdés: csinálok egy setup&deployment projektet (jelenleg a VS2005RC1-ben, mert úgy tűnik, a 2003-asom megadta magát és nincs kéznél az install CD, de látszólag ugyanaz). Hogyan tudok olyat csinálni, hogy telepítés után minden egyes júzer bejelentkezésekor elinduljon egy konfigurációs lépés? Arra volna szükség, hogy ha a júzer a telepítés óta először jelentkezik be, akkor az Application Data mappájába bekerüljön néhány fájl. Ezt meg tudja oldani a VS-féle setup projekt, megoldható-e custom step-pel, vagy nézzek valami komolyabb megoldás után?
    Egy meglévő programot wrappelek msi-be, hogy lehessen távtelepíteni, úgyhogy magát a programot nem tudom módosítani.

  • Gregorius

    őstag

    válasz Miracle #132 üzenetére

    Nah beleolvastam.
    Aszongya a 7. pontban
    this paper examines only stop-the-world, non-incremental,
    non-concurrent garbage collectors.

    Kár, hogy a .NET GC és az újabb Java cuccok nem ilyenek.

    If their applications will be deployed on
    systems with at least three times as much RAM as needed

    Megmondom őszintén, olyan rendszert még nem nagyon láttam (az otthoni játékpc-ket kivéve), ahol átlagosan a RAM több, mint 50%-a ki lett volna használva. Ökölszabályként is ezt használják rendszerméretezéskor.
    De ha már mégis fogytán a RAM, nem csoda, hogy a garbage collection szarul teljesít, lévén egy csomó szemét kikerül a pagefile-ba ahelyett, hogy a rendszer engedné előtte a GC-nek begyűjteni. (A bookmarking collector-juk, ami figyelembe veszi ezt a paging-et, állításuk szerint alig veszít a teljesítményéből nagy memóriaterhelés esetén)

  • Miracle

    senior tag

    válasz Gregorius #134 üzenetére

    oki oki nem arrol volt szo, hogy nemkellGC mert szar, hanem arrol, hogy nekialltak es eleg komolyan megkutattak mennyivel lassabb, nyilvan meg lehet magyarazni, ami senkit nem erdekel es nem is szamit, inkabb csak tudni kell hogy a gepbe kell memoria mint allat mert az olcsobb mint amig a programozo kezzel kezel memoriat es ezzel szamolni kell :)
    es a problemadhoz amit elozo hozzaszolasban mondtal otletem sincs, en nem csinalok installert ;)

    értelmező késziszótár :: rekurzió --> lásd : rekurzió

  • zoty314

    aktív tag

    Egy ismerősömnek lenne egy gondja. Remélem tudtok segíteni, elég sürgős lenne. Előre is köszi.

    ''Néhány éve elkészítettünk a média üzletágra egy olyan szoftvert amelynek főoldalán fotók találhatók egymás alatt, és mellettük a jellemző adatok szerepelnek táblázatban. A fotók száma nem ismert, tehát görgethető volt az oldal függőleges irányban a képek, és vízszintes irányban a megjelenítendő adatok miatt. Borland Builder fejlesztői környezetet választva az F1Book jelentette az adatok megjelenítésére a megoldást, így képenként egy F1Book-ot használtunk. A kép és a mellette lévő F1Book egy panelen helyezkedett el, ami egy komponensként volt kódolva, tehát ilyen komponensek listáját láthatta a felhasználó, és görgethette azt. Ezt a szoftvert a rengeteg felmerült új igény kapcsán szeretnénk újraírni, és a kérdésem az lenne, hogy Microsoft Visual Studio 2005-öt választva milyen egzakt megoldással lehetne felváltani, kiváltani a fent leírtakat, tehát ahogy a szoftver jelenleg működik. Létezik-e adatok megjelenítésére alkalmas komponens ha a megjelenítés nem adatbázisból történik? Lehet-e és hogyan pl. egyetlen excel sheetet beágyazni, vagy ez rossz irány!?''

  • Jester01

    veterán

    Nem tudtok olyan .net memory profilert ami futó service processhez tud attacholni és megmutatja heapet? Már a hajam tépem. Ha profilerrel indítom akkor olyan lassú, hogy egy nap alatt sem eszi meg a memóriát. :O
    Vagy esetleg egy linket, hogy milyen apival lehet heap dumpot csinálni? Miért fájt volna m$nek a GC osztályba ilyen metódusokat rakni?

    Jester

  • andriscs

    aktív tag

    Hi!

    Éppen a nyomtatást próbálom leprogramozniC# alatt, és kisebb gondom akadt. Miután beolvastam egy szöveget egy richtextbox-ba, és kirakom a nyomtatási képet, akkor a drawString metódus érdekesen viselkedik. Ha hagyom, hogy soronként írja ki a kinyert szöveget, akkor nincs gond, csakhogy a sorok elég hosszúak, tehát túllógnak a margón. Ezért próbáltam használni a négyzetes beleírást, hogy hátha belefitteli a szöveget. De nem.
    Itt a kód:

    RectangleF rec=new Rectangle(e.MarginBounds.Left,e.MarginBounds.Top,e.MarginBounds.Width,e.MarginBounds.Height);
    e.Graphics.DrawString(str, printFont, myBrush, rec, new StrinfFormat(StringFormatFlags.FitBlackBox));


    A baj ezzel annyi, hogy nincs benne sorlépés, vagyis csak asszem 1 pixelnyi. Tehát 200 oldal kb. 4 sornyi.
    Hogy vegyem rá, hogy rendesen rakja ki?

    Andris - http://andriscs.blogspot.com

  • orbano

    félisten

    válasz andriscs #138 üzenetére

    ha ezt nem tördeli be neked rendesen az oldalra, akkor a MarginBounds lehet rosszul megadva, próbáld meg e.PageBounds-dzal.

    Amúgy üdv mindenkinek! KB. fél éve foglalkozom C#-pal, ügyviteli programokat írogatok VS.NET-tel. Szvsz baromira kiforratlan az egész :) De kényelmes benne dolgozni, szóval...

    Valaki csinált már közületek többszálas progit? Elvileg jól beírtam a tutorialos példát, de mégsem képes a formban létrehozott szál meghívni a formban megadott eseménykezelőket (gyakorlatilag nincs kommunikáció a gyermek- és a szülő szá között)... :F

    Másik kérdésem: openGL-t be lehet valahogy üzemelni C# alatt?

    A vér nem válik VAZZE!™

  • Jester01

    veterán

    válasz orbano #139 üzenetére

    Valaki csinált már közületek többszálas progit?

    Igen.

    Jester

  • andriscs

    aktív tag

    válasz orbano #139 üzenetére

    Hi!

    Nem segített sajnos az sem, csak annyi, hogy a sorok szélesebbek, de még mindig egymásra csúsznak. Mellékelek egy screenshot-ot, hátha jobban érthető úgy( ez itt kb 400 sor lenne). De csak azokkal a file-okkal csinálja, amelysiket más alkalmazással hoztam létre. Lehet valahogy ''kötelezni'' a richTextbox-ot, hogy vegye fel a formázást?
    [kép]



    [Szerkesztve]

    Andris - http://andriscs.blogspot.com

  • orbano

    félisten

    válasz andriscs #141 üzenetére

    milyen sortörés-karakterek vannak abban a fileban? ahogy elnézem (bár lehet tévedek), a kódolással is el van valami állítva. próbáltad betölteni a szöveget valami szövegmegjelenítős controlba?

    A vér nem válik VAZZE!™

  • orbano

    félisten

    válasz andriscs #141 üzenetére

    javaslom a filebeolvasónál nézd át, hogy milyen Locale információ alapján állítja be a kódlapot, illetve a kódolást, amivel beolvasod a szövegfilet... kezdek egyre jobban erre gyanakodni :F

    A vér nem válik VAZZE!™

  • Jester01

    veterán

    válasz orbano #143 üzenetére

    Hát azt nem lehet ;)
    Inkább te mutasd meg mi nem mûködik neked :)


    private Thread mThread;
    ...
    mThread = new Thread(new ThreadStart(ThreadProc));
    mThread.Priority = ThreadPriority.Lowest;
    mThread.Start();
    ...
    private void ThreadProc()
    {
    ...
    }


    Másik szálon lévõ control metódusait Invoke használatával kell hívni.

    Jester

  • Gregorius

    őstag

    válasz andriscs #138 üzenetére

    Éppen a nyomtatást próbálom leprogramozniC# alatt, és kisebb gondom akadt. Miután beolvastam egy szöveget egy richtextbox-ba, és kirakom a nyomtatási képet, akkor a drawString metódus
    Hadd mutassalak be a ReportViewer-nek: [link] [link]
    A GDI-s DrawString-es megoldást pedig nyugodtan el szabad felejteni. Jah, a DrawString nem fog neked formázott szöveget rajzolni.

    Valaki csinált már közületek többszálas progit?
    Ja. Nem volt egy leányálom.

    Elvileg jól beírtam a tutorialos példát, de mégsem képes a formban létrehozott szál meghívni a formban megadott eseménykezelőket (gyakorlatilag nincs kommunikáció a gyermek- és a szülő szá között)...
    Kód?

    Másik kérdésem: openGL-t be lehet valahogy üzemelni C# alatt?
    Utoljára ezt használtam: [link] Balra a menüben a BaseCode alatt lehet válogatni.

  • andriscs

    aktív tag

    válasz orbano #144 üzenetére

    Hi!

    Elvileg plain text amit beolvasok a richTextbox-ba:
    LoadFile(fileName, RichTextBoxStreamType.PlainText);
    Nem tudom, hogy mire gondolsz a Locale beállítássl, ahogy néztem a property-ket, a textbox-nál nincs ilyen. Max a Form-nak van, de az meg default-ra van állítva.

    Ok, megnézem a ReportViewer-t.

    [Szerkesztve]

    Andris - http://andriscs.blogspot.com

  • orbano

    félisten

    válasz andriscs #147 üzenetére

    a file handlernél kell beállítani amikor létrehozod (reader, vagy mi a tököm, 1x csináltam csak, nekem csak az ékezeteket nem szerette). a konstruktor paraméterei között vannak kódolási- és kódlap beállítások. ezeket érdemes jól beállítani, valszeg főképp a kódlapot, a kódolást feltehetőleg megfelelően értelmezi a bom alapján :B

    A vér nem válik VAZZE!™

  • orbano

    félisten

    válasz Jester01 #145 üzenetére

    okéj, összeszedem a gondolataim és megmutatom...

    A vér nem válik VAZZE!™

  • andriscs

    aktív tag

    válasz orbano #148 üzenetére

    Hi!

    Nem igazán vágom, hogy mire gondolsz. Semmi stream nincs a progiban, a richTextBox beépített LoadFile metódusával közvetlen filenév alapján olvassa be PlainText formátumban. El tudnád részletesen mondani a dolgot?
    Amúgy újabb kérdésem van: richTextBox-on be lehet állítani contextMenustrip-et?

    Andris - http://andriscs.blogspot.com

Új hozzászólás Aktív témák