u++ adatfeldolgozás txt

C/C++

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.

  • 1771 megtekintés

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 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.

( zsolt | 2008. 04. 29., k – 14:53 )

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");

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).

"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.

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