- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
Hirdetés
-
Megjelenési dátumot kapott a Star Wars: Hunters
gp A tervek szerint június elején végre befut a teljes kiadás mobilokra/tabletekre és Nintendo Switch-re.
-
Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
ph A cég megoldása centralizált vezérelhetőséggel, masszív radiátorral és robusztus ventilátorokkal igyekszik vásárlásra csábítani.
-
Új Beats fej- és fülhallgatók jelentek meg
ma Frissítette a Solo termékcsaládot az Apple házi audiomárkája.
Új hozzászólás Aktív témák
-
Gregorius
őstag
Nehéz kérdés, lévén sohasem foglalkoztam néhány óránál tovább PC-nél kisebb platformok programozásával, de amit te keresel, az a .NET Compact Framework. Ennek dedikált magyar nyelvű könyvről nem nagyon tudok, legfeljebb tanfolyamokat lehet találni, de azok többnyire fizetősek.
A funkciógombokat hogyan tudod használni? -
Gregorius
őstag
Esetleg így:
this.cbbStatusz.SelectedIndex =
this.cbbStatusz.FindStringExact(''HIANYOS'');Az egy dolog, hogy kiválasztod az 1. indexet, de ott tényleg a ''HIANYOS'' van? A ComboBox lehet rendezett is.
Az Items.AddRange-nél meg szerintem nem kell az utolsó vessző.
[Szerkesztve] -
Gregorius
őstag
Defaultban nem fognak futni. Átlag júzer átlag programja úgy kerül lefordításra, hogy azt a framework-öt használja, amelyikkel fordítva lett (vagyis VS2002->FW1.0, VS2003->FW1.1, VS2005->FW2.0). Ha van ilyen a rendszeren, akkor ezzel fog futni a program. Továbbá meg lehet jelölni AssemblyInfo-ban, hogy melyik FW-vel kompatibilis a progi, tehát egy jól összeszerelt (és esetleg CLS-compliant) programra rá bírod írni, hogy fut az 1.0-val, és az 1.1-gyel is. (asszem a 2.0 eltérő assembly szerkezetet használ, ezért az csak felülről kompatibilis, a 2.0-s progikat az 1.1 nem tudja futtatni, de fordítva igen)
-
Gregorius
őstag
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] -
Gregorius
őstag
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
[Szerkesztve] -
Gregorius
őstag
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!
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 .
[Szerkesztve] -
Gregorius
őstag
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. Á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
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) -
Gregorius
őstag
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] -
Gregorius
őstag
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
[Szerkesztve] -
Gregorius
őstag
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] -
Gregorius
őstag
Amint hazaértem, elolvasom, csak RDP-n keresztül kicsit komplikált
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
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) -
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. -
Gregorius
őstag
Az ultimate mitírki
class _
{
enum ___{_,___,_____,_______,________,______,____,__}
static ___ __(___ _,___ __)
{
return (___)(_|___.___|__);
}
static void Main()
{
___ _ = _.__(___._____|__(___.___,___._____),___._____);
Console.WriteLine(_);
}
}
Teljesen legális C# kód, ki lehet próbálni. Épp a nyelv specifikációját böngésztem, úgy tűnik, a srácok úgy gondolták, hogy jó ha ilyet is lehet csinálni
[Szerkesztve] -
Gregorius
őstag
válasz paramparya #156 üzenetére
Mármint midi port, vagy zenélni akarsz?
Előbbi esetben max interop jöhet szóba a win32 API-val, utóbbi esetben Managed DirectX, azon belül DirectMusic alapos tanulmányozása. (egyébként meg egyáltalán nem értek hozzá ) -
Gregorius
őstag
Ha írtál már valaha önerőből on-demand lexikai- és szintaxiselemzőt, ez sajna nem a tíz soros ''Hello World'' kategória (ráadásul atomra ki van optimalizálva), és őszintén szólva kétlem, hogy bárki bármilyen tapasztalattal képes lenne két napnál hamarabb megoldani (még ha tökéletes a dokumentáció, akkor sem), kivéve ha az illető az azon a kódrészen dolgozó csapatban van.
Ez idáig rendben van, csak azt nem értem, hogy melyik balf*** tolta hónapokkal egy stabil változat előtt piacra a VS-t?!
a bugfixeket service-packokba gyujtse azonnali relase helyett. van ennek valami oka is a tradicion kivul?
Kevesebb verzióval kell foglalkozni, ha összeakad valamivel az egyik javítás.
nem nagyon latom, hogy akarmelyik kereskedelmi IDE hasonlo utemben tudna bugfixeket kozzetenni, mint egy opensource project.
Ezt majd akkor fogadom el érvnek, ha mondjuk a NetBeans vagy az Eclipse sebességben és memória-hatékonyságban utoléri a Visual Studio-t. Akár a 2005-öst, pedig az nagyságrenddel lassabb, mint a 2003 (szintén ''bug''). -
Gregorius
őstag
Szerintem jobban jársz, ha globálisan csinálod meg, nem egyenként minden control-ra.
Ehhez először el kell kapni a billentyűleütéseket a Form-on:
this.KeyPreview=true;
Aztán lereagálni a KeyDown/KeyPress események valamelyikét. A KeyDown finomabban hangolható: az alábbi működik Enter-re, de pl. Shift-Enter-re már nem reagál.
private void Form1_KeyDown( object sender, KeyEventArgs e )
{
if( e.KeyData == Keys.Enter )
{
e.SuppressKeyPress = true;
this.SelectNextControl(this.ActiveControl, true, true, true, true); //A SendKeys-t nem szeressük
}
}
Egy apró pici részletet még nem szabad elfelejteni: ha a Form-on van AcceptButton (Form.AcceptButton=...), akkor az mindenképpen ellopja az Enter-t bármelyik Control-ról, akármit is csinálsz. -
Gregorius
őstag
-
Gregorius
őstag
static int steps = 20;
static Thread[] workers = new Thread[10];
static void Main( string[] args )
{
for( int i = 0; i < workers.Length; i++ )
{
workers = new Thread(new ParameterizedThreadStart(Worker));
workers.Start(i);
}
for( int i = 0; i < workers.Length; i++ )
{
workers.Join();
}
Console.WriteLine(''--Készen van--'');
}
static void Worker( object arg )
{
int id = (int)arg;
for( int i = 0; i < steps; i++ )
{
Console.WriteLine(''Dógozom #{0}: {1}'', id, i);
}
}
Ha arra az egymásbaágyazott for ciklusos megoldásra gondolsz, ami különböző lépésközzel végigmegy az egész tömbön egymás után, akkor sajna az a tényállás: az egyszálú esetben jobban optimalizálható az előző pass-ok eredményeinek felhasználásával.
[Szerkesztve] -
Gregorius
őstag
Egyszerű láncolt listát akarsz csinálni?
Arra már van kész komponens: LinkedList<T>. Mondjuk ez duplán láncolt, és pár tíz bájttal nagyobb az állapota, mint szükséges volna.
Esetleg jó lehet a List<T> is, ezzel csak az a baj, hogy ha a közepére/ből szúrsz be/veszel ki egy-egy elemet, akkor az egész listát lemásolja (a berakott/kivett elemmel/nélkül), és ez kellemesen lassú tud lenni.
Feladattól függően esetleg a Queue<T> és a Stack<T> is hasznos lehet.
Amúgy meg nem kell hozzá unsafe, mert referenciákkal is ugyanolyan láncolt listát lehet csinálni, mint C-ben.
class LáncoltLista<T>
{
public LáncElem<T> Első = null;
public void Eléfűz(T érték)
{
LáncElem<T> le = new LáncElem<T>(érték);
le.Következő = this.Első;
this.Első = le;
}
}
class LáncElem<T>
{
public T Érték;
public LáncElem<T> Következő;
public LáncElem(T érték)
{
this.Érték = Érték;
this.Következő = null;
}
}
A T helyére meg olyan típust írsz, amilyen tetszik. Például
LáncoltLista<Point> pontLista = new LáncoltLista<Point>();
pontLista.Eléfűz(new Point(12,25));
... -
Gregorius
őstag
Ha jól érzékelem, azt akarnád csinálni, hogy egy WebService összerak neked egy DataSet-et és azt akarod egy oldalon többrendbelileg megmutatni. Nekem nagyon úgy tűnik, hogy az ObjectDataSource nem támogatja. Helyette ezt lehet írni a Page_Load-ba:
TesztDS ds = new WebService().GetMyData();
this.GridView1.DataSource = ds;
this.GridView1.DataMember = ''TesztTable1'';
this.GridView1.DataBind();
this.GridView2.DataSource = ds;
this.GridView2.DataMember = ''TesztTable2'';
this.GridView2.DataBind(); -
Gregorius
őstag
Háát, azt esetleg meg lehet játszani, hogy a webservice-edben perzisztens gyűjteményt használsz (értsd: nem kéred le az egész dataset-et újra minden hívásra), és az egyes method-ok külön táblákat adnak vissza ebből, akkor több objectdatasource-ból összeszedheted az adatokat. Persze hogy ez így működik-e... Igazság szerint nem nagyon foglalkoztam még bővebben asp.net-tel.
-
Gregorius
őstag
válasz paramparya #216 üzenetére
Ha mindig ugyanaz kell, akkor a TabIndex-eket úgy kell beállítani, a legelső index lesz az aktív majd növekvő sorrendben lépked végig. Ha változtatni akarsz, akkor pedig TextBox.Focus()
-
Gregorius
őstag
válasz andriscs #220 üzenetére
GUI-nak nem szokás külön szálat indítani, GUI szálat Sleep-pel várakoztatni meg végképp nem. Én a helyedben inkább azt csinálnám, hogy a spash screen-re felraknék egy 2000ms-re állított timer-t, majd amikor az lejár, akkor bezárnám a splash-t. Első körben. Ha közben még dolgoztatni akarod a rendszert, akkor még lehet kicsit bonyolítani, de alapnak ez így jó.
splash.ShowDialog();
Application.Run(new MainForm());
//...
splash_Load(...)
{
this.timer1.Start();
}
timer1_Timer(...)
{
this.timer1.Stop();
this.Close();
} -
Gregorius
őstag
válasz Vilmoskorte #223 üzenetére
A Debugger Users csoporthoz add hozzá magad.
Amúgy meg várjuk már az SP1-et (Q3 2006), mint a messiást. Nekem ma egy órán belül kétszeri ''Visual Basic Compiler has encountered an error...'' után úgy borult meg az egész, hogy minden szép és jó, amíg egy DataAdaptert meg nem kísérelek konfigurálni, amit egyszerűen megtagad a Studio mondván a projekt nem létezik, és utána arra hivatkozik, hogy a referencia (System, System.Windows.Forms, stb...) által mutatott fájlt nem találja. Úgyhogy most szépen lefekszem, holnap reggel meg előveszem a telepítőcédét.
[Szerkesztve] -
Gregorius
őstag
válasz Vilmoskorte #225 üzenetére
Ha nem hozta, akkor marad az admin. Ez van. Nem hiszem, hogy éveket szeretnél azzal tölteni, hogy egy rakás COM objektum meg registry bejegyzés jogosultságait állítgatod.
A full image-es telepítő amúgy asszem nem nyaggat, hogy regisztráld. -
Gregorius
őstag
Ha minden igaz, leválasztották magukról a devenv fejlesztő üzletágukat. Hogy ténylegesen el is adták, vagy csak átcsoportosítás volt, az jó kérdés.
Mindenesetre az biztos, hogy a Borland a fejlesztőeszközeivel minimum egy éves lemaradásban van, az pedig ezen a téren nagyon nagy idő. -
Gregorius
őstag
A DataSet/DataTable az egy struktúrált adathalmaz. Hogy ezt adatbázisból töltöd fel vagy szövegfájlból vagy kézzel, az már rajtad múlik.
Ha nincs szükséged a DataTable szolgáltatásaira (rendezés, keresés, indexelés, változáskezelés), akkor kicsit több munkával de lényegesen gyorsabb és kevesebb memóriát zabáló megoldást kapsz, ha egy saját class-t implementálsz, azt pakolod bele egy BindingList<T>-be, és ezt adod meg DataSource-nak, igaz ez sokkal kevesebbet tud. A DGTextBoxColumn, stb... ugyanúgy működik. -
Gregorius
őstag
válasz Terminus_ #276 üzenetére
Két hét alatt? Az húzós lesz, és ezt nyugodtan megmondhatod a főnökségnek is. Ennyi idő még az osztálykönyvtárak minimális ismeretéhez is igencsak kevés, úgyhogy inkább azt tudom mondani, hogy a .NET belső lelki világával, a CLR-rel (assembly, JIT, GC), meg az alapvető nyelvi elemekkel (property, event, delegate) foglalkozz, mert azt kizárt, hogy a helpből könnyedén meg lehetne tanulni. Amit viszont az osztálykönyvtárból mindenképpen alapos áttanulmányozni az a System.Collections, mert ez gyakorlatilag minden programban előfordul, ami a Hello World!-nél hosszabb.
Amúgy milyen feladatkörben kellene használni? Mert akkor esetleg afelé lehet orientálódni a tanulásban is. -
Gregorius
őstag
válasz Terminus_ #278 üzenetére
Hát szerintem az ECMA az, amihez utoljára nyúlj. Egyrészt az csak a nyelv specifikációja, másrészt konkrét példákból hamarabb meg lehet tanulni a szintaxist.
A könyvben sajna nem tudok segíteni, a 2.0-hoz készült irodalmat nem ismerem, az 1.1 óta pedig pont az ASP.NET-ben történt a legtöbb változás. -
Gregorius
őstag
Naszóval.
Errõl én nem tudtam
Úgy értettem, hogy ahol maradéktalanul tudsz .NET-es programot futtatni, ott MSSQL-t is fel tudsz tenni.
Ja és ugye nem biztos, hogy azt is meg akarja venni...
Az MSSQLEx Ingyen van.
ahol fut a .net 2.0, ott azt valaki direktbe felrakta, mert kellett neki vagy
a visual studio 2005-tel együtt került fel, ahol a telepítő automatikusan rakta fel.
Vagy ingyen és bérmentve letöltötte MS-től ([link]) és úgy rakta fel.
Mellesleg az MSSQL2005 felrakja magával a .NET 2.0-t is.
mert egyébként én sem vagyok hülye és nem szivatnám magam egy alig támogatott adatbáziskezelővel.
Van egy sajnálatos hírem: ahol a .NET a trendi, ott a MySQL az alig támogatott, ahol meg az utóbbi a bevált, ott meg szarnak a .NET-re.
igenis ki lehet rakni, sőt ki is van rakva a mysql a netre, ajánlom a figyelmedbe:
Értelmes szolgáltatóval nem nagyon találkozni, amelyik a localhost kivételével más gépről is közvetlenül elérhetővé tette volna a MySQL-jét (ez biztonsági okokból van így). Márpedig ha csak a localhost-ról éred el, akkor ugyanitt kellene futnia az adatlekérő kódnak is, amiből el akarod érni az adatbázist, vagyis jobb esetben windows-on kell hogy hosztoljanak hozzá, amire az ember általában igen csúnyán néz (főleg ha nem dedikált szerverek vannak, kicsit körülményes a rendes izolációt megcsinálni a különböző tárhelyek között, nem is sokan vállalják el).
Szóval vagy átvered a kedves üzemeltetőn, hogy márpedig neked külsö kapcsolat kell a MySQL-hez (hozzáteszem szerény véleményem szerint nincs olyan agyatlan barom a világon aki közvetlenül kirak egy adatbázisszervert az internetre a legkisebb rosszérzés nélkül), vagy elfelejtheted a .NET Connectort és írhatsz helyette egy kellemesen csúnya adatelérő wrappert, amivel ugyanúgy biztonsági problémák vannak. Az meg egy vizsgáztató rendszernél nem jó dolog, hogy a furfangos tanuló betör a rendszerbe és átírkálja a saját eredményeit.
[Szerkesztve] -
Gregorius
őstag
A jelenlegi infrastruktúrába csinálhatsz egy webservice szerű dolgot php-ben, de akkor pont a VS-t küszöbölöd ki a rendszerből, merthogy ilyenkor a feladat zömét a php végzi el.
A legegyszerűbb VS-es megoldás az volna, ha egy saját masinát beállítasz a datacenter-be, ami majd asp.net oldalt fog kiszolgálni (vagy keresel egy másik szolgáltatót pl. [link]), persze ekkor a WinForms-t dobtad, de legalább nem kell telepíteni a kliensszoftvert.
Ha mindenképpen WinForms, akkor a szerverre lehet webservice-t írni, ami gyakorlatilag csak annyiban különbözik az asp.net-es megoldástól, hogy nem ember által oldasható html oldalt, hanem gépi feldolgozáshoz strukturált adatokat ad ki magából, de az alkalmazáslogika 90%-a még mindig ebben van. -
Gregorius
őstag
válasz whitewolf5 #294 üzenetére
Amikor a webszerveren futtatod, akkor nem ugyanazokkal a jogosultságokkal fut az oldal, mint amikor VS-ben. Utóbbi esetben azzal a júzer account-tal fut, amivel bejelentkeztél (az esetek zömében rendszergazdaként ), az IIS viszont az IWAM_<gépedneve> júzer nevében futtatja az oldalt, szóval ezt a júzert a megfelelő jogokkal hozzá kell adni az SQL-t elérni jogosultak köréhez, és az adott adatbázison felvenni a db_datareader illetve a megfelelő role-ba.
-
Gregorius
őstag
válasz whitewolf5 #297 üzenetére
Az adatbázisfájlokat ott kell hagyni, ahová az mssql megcsinálta.
Az IIS-en nem kell beállítani különösebben semmit, legfeljebb annyit, hogy adott application pool-hoz hozzárendelni, de ha már csatlakozni akar az mssql-hez, akkor jól van beállítva.
A hibaüzenetből ítélve pedig rossz a connection string a web.config-ban, nem találja a megadott mssql szervert. Vagyis (egyelőre még) nem a loginnel van baj.
[Szerkesztve]
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!