u++ adatfeldolgozás txt

 ( emberk | 2008. április 29., kedd - 11:12 )

Sziasztok!

(Kezdő guiirós kérdés)
eddig ansi-c kódokat írtam, de most u++-ban kell kódolnom (ami tetszik cask kicsit új még) abban az egyszerű dologban kérném a segítségeteket, hogy egy text filben lévő 2 oszlapban lévő számsort szeretnék beolvastatni egy memóriatömbbe. Ezt hogyan kell megtenni?
ilyen egy számsortöredék.
0,386490725 14,3
0,403089987 13,8
0,436010796 13,3
0,403089987 13,4
0,436010796 13,7
0,419601024 14,4
0,370403905 13,6
0,403089987 14,1
0,403089987 14,4
0,436010796 14,3
0,436010796 14,8
A memóriafoglalás az ok, az megvan, (ansi szabány megy), de most egy betöltés gombon kleresztül kell berántanom az adatokat.

Előre is köszi, és bocsi a láma kérdésért, de valahol el kell kezdeni.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

up.

Pontosan mi a kérdés? hogy hogyan parszolod az adatokat a text fájlból vagy hogy hogyan kell eseménykezelőt írni a gombhoz vagy mi?

Mi az az u++?

Pontosítsd, hogy mi a kérdés. Ha pontosan fel tudod tenni a kérdést akkor meg fogod kapni a választ is.

u++ = ultimate++, és tuladonképpen egyedül a file megnyitásával van bajom. A gombhoz át tudom adni a vezérlést(THISBACK) képet adatfeldolgozásra meg tudok nyitni, de egy txt-tileből a számokat kellene beolvasni egy adattömbe, ahoz nem találtam tutorialt, azért nem tudom hogy kel mert ennek e nyelvnek nem találtam tutorialját ehez a témához (lehet van), sőt kirattatni is tudom a tartalmat. (puts(LoadFile(GetDataFile(~fs))); csak nem tudok hozzá adatfeldolgozást produkálni, mert nem tudom hogy hivatkozok a filen belül, mire hivatkozzon az előbbi hívás (LoadFile(GetDataFile(~fs)) hogy tudjak a fáljból adatot kivenni. Az tiszta sor hogy ha beolvasok egy sort akkor hogy dolgozom fel sscanf pl, de nem tudom a sorokat kiszedni.

Az ultimate++ csak egy könyvtár c++-hoz, nem? Tehát akármilyen c++-os megoldással megoldhatod a problémát. Vagy akár "sima" C-ben is. Vagy ez valami gigantikus tévedés a részemről?

Ezt eddig nem is tudtam. (Újfiú vagyok gui téren), tehát akkor sima C++-os megoldás az mehet? csak mert marhára nem úgy nézett ki eddig egy tutorial sem.

Valójában gőzöm nincs. De próbáld ki, abból nem lehet baj

jól van épp azt teszem.

Az az igazság, hogy a u++ -nak meg vannak a saját osztályai az i/o -hoz.
Nem az std::iostream-et használja.
Az upp++ STL megfelelője az NTL. Ez jobban illeszkedik az u++ osztály-rendszeréhez.
Pár hasznos link, hátha:
Egy ilyen NTL-es vektorban tárolhatnád a számokat: http://www.ultimatepp.org/srcdoc$Core$Tutorial$en-us.html

String és Value osztályok:
http://www.ultimatepp.org/srcdoc$Core$CoreTutorial$en-us.html

Szövegformázás:
http://www.ultimatepp.org/src$Core$Format$en-us.html

String és StringBuffer műveletek:
http://www.ultimatepp.org/src$Core$String$en-us.html

Stream-ek, köztük a FileStream és a FileIn stream:
http://www.ultimatepp.org/src$Core$Stream$en-us.html

Stream segédletek (köztük stdin olvasása):
http://www.ultimatepp.org/src$Core$StreamFn$en-us.html

Így elsőre szerintem ezekre lesz szükséged.
Személyes véleményem azomban az, hogy az upp helyett keress valami mást.
Minden szép és jó, de figyelembe kell venni, hogy:
- az osztályokat a stacken hozod létre (ezrt nem szükséges delete -t használni upp-s programokban, és ezt a módszert hívják az upp-s arcok "garbage collectornak"....)
- pár (4-5) ember fejleszti - mi van, ha gondolnak egyet, és holnap abbahagyják az egészet? Akkor a programod karbantartása mellett fejleszheted magad az upp keretrendszert is.
- Néhány lap dolog hiányzik, ami csak később derül ki. Én pl. kb 2 éve próbálkoztam vele utoljára, s ott adtam fel, hogy egyszerűen nem volt egy inputline -nak keypreview v. hasonló tulajdonsága, és így nem tudtam azt megcsinálni, hogyha enter -t nyomnak, akkor végrehajtódjon valami. Úgy vettem észre, hogy (akkor legalábbis, nem tudom, ma hol áll) ez általános az egész rendszerben, minden osztály csak az eseményvezérlő callback-okon keresztük vezérelhető. Ez a keypreview hiánya szvsz nagy baj, kényelmetlen lesz a végtermék használata a felhasználónak. Ezen kívül volt még egy-két apróság, de azokra nem emlékszem.
- adatbázis-kezelésben egy nagy nulla (volt legalábbis 2 éve).

Sajnos Linux platformra még mindig ez a legkénylemesebb RAD eszköz, ráadásul ingyenes is.
Ha netán win.-re fejlesztesz, javaslom a .NET kipróbálását, egy Express Visual Cˇvagy C++ RAD-dal.
Sajnos azt kell,. hogy mondjam, ezek a mostani Visual Studiok messze fényévekre vernek minden más fejlesztőeszközt (beleértve az xcode -ot is OSX-en).
Kár, hogy a .NET3.0 nem multiplatform... :(
http://www.ultimatepp.org/src$Core$Stream$en-us.html

- az osztályokat a stacken hozod létre (ezrt nem szükséges delete -t használni upp-s programokban, és ezt a módszert hívják az upp-s arcok "garbage collectornak"....)

Szerintem valamit igencsak félreérthettél...

ott adtam fel, hogy egyszerűen nem volt egy inputline -nak keypreview v. hasonló tulajdonsága, és így nem tudtam azt megcsinálni, hogyha enter -t nyomnak, akkor végrehajtódjon valami.

Érdekes, én meg pont amiatt szeretem, hogy ilyesmiket pár sor megcsinálni.

- adatbázis-kezelésben egy nagy nulla (volt legalábbis 2 éve).

Nagyon fura ízlésed lehet, de nekem nagyon bejön, hogy C++-ban deklarálom az adatbázist és automatikusan tartja karban az adatbázis-szerkezetet fejlesztés közben. Soha nem kell "create table"/"alter table" sql-eket írkálni.

Nagyon király az is, hogy C++-ban írhatom a query-ket, tehát a változtatott adatbázison már fordításkor kiderül, hogy pl. olyan mezőt akartam valahol lekérdezni, ami nincs az adatbázisban.

Az sem rossz, hogy az adatbázis-rekordoknak megfelelő osztályok maguktól deklarálódnak és nagyon egyszerű őket az adatbázisból betölteni és oda visszaírni.

Nem tudok más olyan eszközről jelenleg, ami ilyen szintű adatbázis-támogatást adna. Delphi-vel dolgoztam régen pár évet, de az megrekedt egy elég kezdetleges szinten.

.NET-be tettek most valami hasonlót LINQ néven, de az is elég bénára sikerült szerintem, főleg a fordított szintaxis gáz, amúgy meg agyon van bonyolítva.

És FILE*, vagy int fájlleírót se tudsz kicsikarni?
Vagy legalább fájl nevet.
Én se értek az u++ könyvtárhoz.
Mi az, hogy bajod van a fájlmegnyitással?
Megnyomsz a gui-n egy gombot és az mit csinál?

Tipp:
A puts argumentuma char* string, ha az megvan akkor azt "kézzel" parse-olod.

Sajnos puts épp az stdout-ra ír ki, úgyhogy azt vehéz lenne parse-olni...

őőő, félreértehető voltam
ha a puts-hez megvan a string
akkor azt már nem csak kiíratni lehet

Töltsd be az egész file-t egy tömbbe és variálj vele ott:
String LoadFile(const char *filename)

Pl:

String s = LoadFile("valamiFilenev");

Split meg jó arra, hogy a file-t első lépésben sorokra, aztán meg cellákra bontsd.

Vector<String> Split(const char *s, int chr, bool ignoreempty)

Ok köszi ez a kettő elvileg elég is. Ezt már így érem.

Ha már egyszer U++-ozik az ember, szerintem jobb, ha elkerüli az ilyen régimódi stl-es kódokat ;)

Nekem meg a fájlok egészben memóriába való berántásától lesz libabőrös a hátam. :)

Nekem is a "klasszikus verzió" tetszik jobban. Na meg ilyet már csináltam. De egyébként lehet gofy gyorsabb, mert ma már nem a memória igazából a szűkkersztmetszet. Megírom így iy úgy is amelyik gyorsabb.

Közben írták fent az u++-oss megfelelőit a filestream-eknek. Ha nem akarsz nagyon rendszeridegen lenni :), akkor azoknak a képességeit próbáldd ki először.

Aha nézegetem, de kezd nem tetszeni. Az alap C jobban tetszett (többet lehet buherálni, itt még a memóriakezelés is managgelt, én meg mindíg ilyen hardverközelí dolgokat szerettem csinálni). Olyan "túl autómata" akar lenni. Lehet inkább C++,qt vagy C,gtk lesz előbb utóbb belőle.

a memóriakezelés is managgelt

Ez hülyeség, de áruld már el hol olvastál ilyet?

Ha ennyire nem értesz a C++-hoz, inkább gtk-t javaslom.
Cserébe a forrásaid legalább 10-szer akkorák lesznek, mintha Ultimate++-szal írtad volna őket.

Szerintem addig ne állj neki U++-szal fejleszteni, míg nem olvastad Stroustrup könyvét a C++-ról, mert csak magadat fogod szívatni.

Igen ezt benéztem. Valóban nem az. Aról olvastam hogy valami garbera corrector (vagy mi már nem emlékszem rá) na az használható vele, vagy tervezik. Egyébként nekem ez az U++ olyan kényszermegoldás, mert én a C-t részesítettem előnyben, de az nem fekszik az itteni munkához. Soha nem is szerettem ezt az objektumorientált vacakolást. Ahogy nézem, a GUI-íráson kívül halál semmi értelme (bár igen kicsi fiú vagyok még ebben a támában ez ikább első benyomás), matematikai pogramok írására, annyi az eredmény hogy sokal lassabb és dagadtabb lesz a program, na nem is objektumorientáltra írtam. Ja a linuxos ide-hozzá meg egy rakat bughalmaz (pl nem találja a saját libjeit, ami kicsit erős hiba szerintem, hába állítom be a fordítási beállításokban, azon felül csak debug módban fordít nekem, bármely más mód esén elhasal error11 vagy valami hasonló sokat mondó hibával).

Jaj, ez a garbera corrector nagyon megmosolyogtató, garbage collector-nak hívják amire gondolsz:)

Gerbera collector ;)

mégjobb:)

"Build Methods"-ban "Release mode"-nál is "Shared libs"-re kell állítani a kapcsolót.

"Soha nem is szerettem ezt az objektumorientált vacakolást"

:) tizenvalahány éve még én sem értettem mi szükség rá, viszont nagyobb project-eket (több 100 ezer sor) lehetetlen normális idő alatt és jó minőségben elkészíteni, ha nem objektum-orientáltan csinálod.

Ha C nyelven dolgozol és karbantartható kódot szeretnél írni, akkor is célszerű objektum-orientáltan szervezni a munkát (lásd: Apache, Gtk+, Squid, stb.).
A gond csak az, hogy a C nem OO nyelv, ezért rengeteg plusz melót jelent az OO elvek követése.

Ezt kipróbálom. Mármint a shared lib-re kapcsolást. Egyébként kezdem belátni, hogy ez az oo-ellenszenv kezdeti lázadás, mert annyira más mint az alap C, meg kell még értenem igazán.

objektumorientált vacakolás ... matematikai pogramok ... sokal lassabb

Ez teljesen tévhit, ld. http://www.oonumerics.org/blitz/

+1

Ahogy elnézem, az u++ "garbage collector"-a lénygében kimerül abban, hogy a stacken hozod létre az objektumokat...
Ha igazi garbage collector, meg managelt kód kell, akkor inkább Java, de még inkébb C# (csak ez !win -en problémás, sajnos).
(Igen, olvastam, hogy neked inkább vi + gcc kell, én is szeretem, de GUI programot eléggé macerás írni benne, míg egy RAD eszközzel pár perc alatt összedobsz egy-egy dialógust/ablakot.)

Egyébként az U++ filozófiájának a lényege, hogy normális kódszervezés esetén az ember egyetlen explicit allokációt (new, malloc) sem ír a kódba, így nincs lehetőség leak-elő programok írására.

Ergo, a garbage collector teljesen felesleges és nem is lesz soha U++-ban.

Természetesen a környezet mindent megad ahhoz, hogy ez megvalósítható legyen és tényleg működik.
Persze egy ilyen program lényegesen gyorsabb, mintha GC-s lenne, ráadásul egy GC-ssel szemben kiszámítható (determinisztikus) a működése.

A probléma az, hogy az új Java/C# programozó nemzedék már csak olyan programozási mintákban képes gondolkodni, amihez GC elengedhetetlen.

"A probléma az, hogy az új Java/C# programozó nemzedék már csak olyan programozási mintákban képes gondolkodni, amihez GC elengedhetetlen."

Valójában ez a probléma. Ugyanis a C++ minden lehetőséget megad rá, hogy még new használatával is felesleges legyen a GC, és ez mindössze egy kis odafigyelést/tervezést igényel.

A gond az, hogy sokan C++-ban Java/C# szemlélettel próbálnak programozni. Ez legalább akkora hiba mint C szemlélettel.
Egyszerűen ezek különböző nyelvek, és különböző gondolkodásmódot igényelnek, még akkor is, ha elsőre hasonlóak.

(A következő C++ szabvány lehetőséget ad GC használatára, de hála istennek ez kikapcsolható lesz (ha lesz)...)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Most hogy kezdem megismerni ezt az u++ ot úgy kicsit komolyabban, kezdem kifejezetten nem rossz nyelvnek tartani. Használhatóak benne a c++-os memóraikezelések (én pointerekkel szeretek tömböt összerakni ez van. Fapdos módszert, de ezt ismerem ezt szeretem, és ha még jóval gyorsabb is akkor....). Ezen felül egy rakat kényelmi funkciót (is) tartalmaz. Kár hgy nem népszerűbb linuxos körökben, de annyira kevesen fejlesztenek benne, hogy kénytelen leszek én is áttérni a qt&c++-ra, vagy gtk&C-re, nekem ez utóbbi talán jobb de majd kipróbálom mind kettőt.

"én pointerekkel szeretek tömböt összerakni ez van. Fapdos módszert, de ezt ismerem ezt szeretem, és ha még jóval gyorsabb is akkor...."

Nem pontosan tudom, mire is gondolsz (több ötletem is van), de az biztos, hogy nem "jóval gyorsabb" mint a vector és a hasonlók...

Másrészről Knut szerint a túl korai optimalizáció minden baj forrása.
Tehát érdemesebb magasabb szinten dolgozni, mert egyszerűbb, kifejezőbb, biztonságosabb, és csak akkor alacsony szinten mókolni, ha az valóban szükséges.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o