- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Milyen videókártyát?
- Milyen egeret válasszak?
- Melyik tápegységet vegyem?
- Léghűtés topik
- Milyen notebookot vegyek?
- IGP nélküli processzorokkal készül az Intel és az AMD
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Hogy is néznek ki a gépeink?
- Autóhifi
Új hozzászólás Aktív témák
-
mitore
csendes tag
-
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(); -
mitore
csendes tag
válasz
Gregorius
#192
üzenetére
Nos, tehát van akkor egy ASP oldalam, amin van egy GridView, és egy ObjectDataSource, ennek be van állítva a webszolgáltatásom forrásként, és hogy SelectMetodként a megadott függvényemet használja. A GridView-nak pedig, hogy melyik DataTable a DataSource, és hogy mi a DataMember-ja. Ekkor ha ki akaro próbálni, akkor azt írja ki:
''The data source 'ObjectDataSource1' only supports a single view named 'DefaultView'. You may also leave the view name (also called a data member) empty for the default view to be chosen.
Parameter name: viewName'' -
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));
... -
tomazin
veterán
Sziasztok!
Tudom,h lami kérdés,de nekem ez az unsafe téma...
Egy pointerekkel készített láncot szeretnék csinálni.Úgy hogy minden eleme struktúra tipusú legyen.Meg lehet ezt itt csinálni,és ha igen akkor hogyan?
Mivel egy gráfbejárást kellene csinálnom,amihez kell 3vector,de szeretném,h egybe legyen..előre is köci
-
mitore
csendes tag
Sziasztok!
Lenne egy nagyon fontos kérdésem, amire addig még sehol nem kaptam választ, hétha Ti tudtok Nekem segíteni.
C#-ban fejlesztek, már 2 éve, és most a VS2005-el beleütköztem egy olyan problémába amit nem tudok megoldani.
Ez a következő:
Van egy webszolgáltatásom, ami adatbázist használ. Típusos DataSet-ben tárolja az adatokat, több táblát is és TableAdapter-t is. A webmetódusok ilyen típusos DataSet-et adnak vissza. Nos ez eddig szépen működik is, mert WinForms alól megy rendesen a függvényhívás, meg minden. De ha ASP oldalon GridView-ban szeretném megjeleníteni, és webreferenciaként átadom neki a webszolgáltatást, akkor az ObjectDataSource csak a legelső úgynevezett DefaultView, azaz a legalső tblát jeleníti meg. Ha viszont manuálisan adom meg neki, hogy melyik DataMember-t, és a DataSource-t, akkor meg kiakad az egész.
Tud valaki valami jó megoldást erre?
[Szerkesztve]
[Szerkesztve] -
Shape
aktív tag
válasz
Gregorius
#186
üzenetére
tyü ha, ez egy kicsit kemény volt igy nekem
nagyábol értem hogy mit csinál ez a progi de nem teljesen.
emailodra el küldhetem neked azt a progit, ami azt csinálja ami a feladat csak szálak nélkül??
és akkor nem kell itt magyaráznom (ami nem is megy nagyon jol nekem
) hogy mit akarok csinálni.
amugy lényegében az hogy lépésközökkel kell menni egy tömbön, csak nem azonos lépésközökkel hanem, mindig más lépésközzel.
ha tudnál emailban segiteni akkor azt nagyon megköszönném.
üdv Shape -
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] -
Shape
aktív tag
válasz
Gregorius
#183
üzenetére
végre egy szaki
egy tömböt machinál az összes szál, és elég konzolosan
a program lényege amugy az hogy 1-1000 ig megkeresi a prim számokat egy algoritmussal. és az algoritmust én egvalósitottam egy tömbel ill. több for ciklussal. szerintem ezeket a for cikluskat kell külön külön szálakba rakni
reméelem tudsz segiteni, mert a vizuális programozás gyakjegyem mulik rajta -
Gregorius
őstag
-
Shape
aktív tag
üdv minden c# fejlesztönek
én csak most kezdtem el tanulni a nyelevet, és reménykedek hogy tudtok segiteni
az lenne a problémám hogy eegy viszonylag egyszerü programot (söt nagyon egyszerü, nem viszonylag) kellene párhuzamos szálak segitségével megvalósitanom.
ha valakinekk van példa progija akkor nagyon megköszönném, mert nem nagyon találok semmit se
a szálaknak egy tömbön kellene müveletet végrehajtaniuk
kösz -
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. -
tildy
nagyúr
És ha a következő elem nem egy textbox, hanem valami más, ami indexelve van (tabbal jól is lehet benne lépkedni...)
Nem értem, erre miért nem reagál jól.
private void textBox1_KeyPress(object sender, KeyPressEventArgs e)
{
if (e.KeyChar == 13)
SendKeys.Send(''{Tab}'');
}
Microsoft visual c# express 2005-t használok, de mitn modntam, még csak msot tanulgatoma dolgokat, és rögtön egy ilyennél elakadtam
pff, na msot meg jó. Én voltam hülye
[Szerkesztve] -
tildy
nagyúr
Kezdő vagyok még c#-ban, és olyan gondom lenne, hogy azt szeretném megvalósítani, hogy egy textboxban az enter leütése után ugorjon át a következő elemre (úgy , mintha tabot nyomtam volna). Emlékeim szerintdelphiben és egyéb hasonló progikban ezt az onenter methódussal elhetett megtenni, de itt nem sikerül
Hogy kell? Üdv: Tildy -
ar
tag
Sziasztok!
Azt szeretnem megtudni, hogy szerintetek meg lehet e oldani a kovetkezot: Adott egy futo .Net (csharp-ban irt) alkalmazas. Ennek a futo alkalmazasnak kellene az egyik osztaly instance-enek (tehat a mar letrejott futo instance-rol van szo) egy metodusat egy masik programbol (ugyanazon a gepen) meghivni. A program obfuscatorral kezelve. A szukseges class nem Remoteable.
A valaszokat, elmeleti fejtegeteseket elore is koszonom!
-
Miracle
senior tag
válasz
Gregorius
#171
üzenetére
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
irtam is, es ismerek mukodo valtozatokat is, es tudom, h nem 10 sor, de az ilyen elemzok algoritmusai jol ismertek, ha nehany nap alatt nem lehet egy ilyen hibat normalisan kijavitani akkor alapjaiban van elcseszve (ez, azaz hogy szar a kod egyebkent fel sem merul bennem, mint valos lehetoseg)
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?!
most erre mit mondjak? cebiten az avalonos microsoftos ember sajnalkozott, hogy a visual studio es a standard XAML design tool (aminek nem jut eszembe a neve) kulonbozo, egymassal nem kompatibilis XAML verziot hasznal a publikus >>BETA<< valtozatban. tehat ami UIt legeneralsz azzal kitorolheted a s****d, hab a tortan, hogy a 3Ds designer(szinten nem jut eszembe a neve) egy 3. verziot hasznal. tehat a kiadott 3 SW (VS2K5, 2d, 3d design tool) 2 teljesen hasznalhatatlan, es igy lett belole beta verzio. ez mar a nocomment kategoria nalam, annak ellenere, hogy az avalon (khm.. wpf vagy valami ilyesmi a relase nev) nagyon utos cucc.
Kevesebb verzióval kell foglalkozni, ha összeakad valamivel az egyik javítás.
ezt el tudnam fogadni, ha nem lenne egy halom visual studioval osszemerheto osszetettsegu opensource project, amelyek kifogastalanul buildelhetok current CVS snapshotbol, de mivel van, es nem hiszem hogy a CVS vagy a clearcase ilyen brutalis feature-folenyben lenne a ms verziokezelo rendszerevel (amit egyebkent nem ismerek) ezt az ervet nem tudom elfogadni, marad a hagyomany.
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'').
igazabol nem kell engem gyozkodni a kereskedelmi IDEk elonyeirol
a netbeans egyebkent azert lassu, mert a java swing az 1.5osig nagyjabol pure java, raadasul messze osszetettebb mint a win.forms, de ha igazak a pletykak az 1.6os nativ implementaciot kap windows, es X11 feluletre is.
Eclipse-el meg nem ertem mi a problema, nalam az remek gyors.
Es a kerdesem nem az volt, hogy miben jobb a VS mint az opensource IDEek, hanem az, hogy ha mar fizetek erte akkor miert nem kapok olyan szolgaltatasokat, amelyek ha nem is feltetlenul elozik meg, de legalabb nem maradnak el ilyen messze az opensource megoldasoktol. -
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''). -
Miracle
senior tag
válasz
Gregorius
#169
üzenetére
lattunk mar BUGot, van ilyen
es igazan nem akarom itt az opensource flamet kelteni, de ilyenkor egy nyilt szoftverben orak kerdese egy workaround, es napok kerdese egy rendes bugfix. igazan elvarnek valami hasonlot egy kereskedelmi szoftvertol is, azaz nem nagyon latom, hogy akarmelyik kereskedelmi IDE hasonlo utemben tudna bugfixeket kozzetenni, mint egy opensource project. vajon miert nem? de most komolyan mondom, nem ertem mi keszteti a microsoftot arra h a bugfixeket service-packokba gyujtse azonnali relase helyett. van ennek valami oka is a tradicion kivul? -
-
-
andriscs
aktív tag
Hi!
A problémám a következő: WinForms-ot hazsnálok, és az egyik form alsó részére raktam egy toolstripStatus cuccost. Erre raktam StatusLabel-eket. A gondom az, hogy ezeket nem lehet áthelyezni, hanem csak egymás mellett vannak, és a felirattól függően méreteződnek át. Hogyan lehet azt megoldani, hogy pl az egyik a bal oldalon legyen, a másik a jobb oldalon? -
#158
paramparya
őstag
Gregorius
#157
-
#157
Gregorius
őstag
paramparya
#156
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á
) -
#156
paramparya
őstag
paramparya
őstag
Ért valamelyikőtök a midi programozáshoz c#-ban?
Az is elég lenne, ha tudnátok valami angol v. magyar nyelvű leírást/segítséget hozzá...
Thx. -
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] -
andriscs
aktív tag
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? -
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
-
andriscs
aktív tag
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] -
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. -
Jester01
veterán
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. -
andriscs
aktív tag
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]](http://javalang.uw.hu/print.jpg "[kép]")
[Szerkesztve] -
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)...
Másik kérdésem: openGL-t be lehet valahogy üzemelni C# alatt? -
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? -
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.
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? -
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!?'' -
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 ;) -
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
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. -
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 :> -
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![;]](//cdn.rios.hu/dl/s/v1.gif)
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? -
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] -
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 -
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] -
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 -
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] -
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] -
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) -
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? -
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] -
-
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.
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.
[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 -
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] -
zoty314
aktív tag
-
Miracle
senior tag
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. -
Miracle
senior tag
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 -
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 -
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] -
-
Diskcopy
tag
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.
) hogy mit akarok csinálni.
:
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)
Új hozzászólás Aktív témák
Hirdetés
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Xbox Series X|S
- Egyre csak fejlődik az AI, emberek tízezreit rúgja majd ki a BT
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Milyen videókártyát?
- Nintendo Switch 2
- BestBuy topik
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- Xbox Classic / Xbox 360
- ASZTALI GÉP / ALKATRÉSZ beárazás
- Elektromos autók - motorok
- További aktív témák...
- BESZÁMÍTÁS! Gigabyte B550M R7 5700X 32GB DDR4 512GB SSD RX 7700 XT 12GB DeepCool CC560 Seasonic 650W
- AKCIÓ! Apple MacBook Pro 16 M4 Pro - M4 Pro 24GB 512GB SSD garanciával hibátlan működéssel
- Samsung Galaxy A5 32GB Kártyafüggetlen 1Év Garanciával
- Csere-Beszámítás! Olcsó Számítógép PC Akár játékra! Intel X5650 / GTX 1650 / 24GB / 240SSD+ 500HDD
- Telefon felváráslás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest