Ha tényleg az optimalizáció vágta ki, akkor a fordítónak kutya kötelessége minél gyorsabb és rövidebb kód gyártása (ha úgy állítottad be) - a nem kívánt kódrészeket meg ugye a fordító nyugodtan "kioptimalizálhatja" a kódból...
Próbáld meg úgy fordítani, hogy a kódban kezdesz is valamit a tömbök adataival...

AE

Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]

De akkor miért nullázza ki az egyiket és miért nem a másikat? Főleg, hogy ha a két változódeklarálást felcserélem akkor pont a másikat nem nullázza ki, azaz mindig a második tömb az inicializálatlan.

(Megjegyzem a MinGW ritkán fent nálam, most is csak azért mert beadandót kell készíteni, szóval nem ismerem ezt a fordítót)

Egyébként ott a pont

Csak, azt nem értem, hogy használom, mert ha debugoltok, akkor az u3-as tömbbel dolgozik a program. Szóval 0-val kellene dolgoznia.

Mondjuk azért mert egyiket sem nullázza ki, csak a memória egy része véletlen pont nulla. Attól függően melyik tömb kerül oda, lesz nulla vagy nem.

hruodnand: ami kódot mutattál az csak írja a tömböt. Tehát mindegy mi a kezdőértéke. A debuggolásról meg a fordító előre nem tud.

[ Szerkesztve ]

Jester

Pontosabban a rendes fejlesztő-környezetek a debug-módba való fordításnál nem szokták szokták engedélyezni az (ilyen szintű) optimalizációt...

AE

Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]

Igen, de nekünk vizsgán debuggolással kell igazolni, hogy működik a program rendesen. Na most, ha nem ad nekem kezdőértéket, amit ugye beállítok, akkor onnantól kezdve karó! Szóval nincs benne printf, meg ilyenek. Csak debuggolás. Windows alatt ugye nem ad értéket, gondolom az előbb említett fordítóbeli különbségek miatt, de Linux alatt meg ad.

Gondolom, "az csak írja a tömböt" alatt, azt értetted, hogy nem fogok kiíratni az értékét

[ Szerkesztve ]

Igen, lehet hogy az egész arról szól, hogy a kolléga elfelejtette kikapcsolni az optimalizációt.

hruodnand: úgy értettem, hogy ha a program működése szempontjából lényegtelen a kezdőérték, akkor a fordítónak nem muszáj nulláznia.

Mellesleg aggresszívabb optimalizáció mellett (linuxon!) az egész ciklus eltűnik a fenébe tömböstül mindenestül - mivel nincs használva. Ellenőrizd az optimalizációs beállításokat.

[ Szerkesztve ]

Jester

Értem, köszönöm. Akkor ennek jobban utána járok!

Nem, csak az egyiket nullázza ki.

Úgy, hogy nincs optimalizáció

Az tény, hogy nekem sincs semmilyen optimalizáció bekapcsolva ezeken a füleken.

Érdekes (bár továbbra sem hiba). A codeblocks alatt is gcc van, ugye? Milyen verzió?

Jester

4.4-es van Ubuntu és Windows alatt is.

Konkrétan MinGW van alatta. A verziója
mingw32-gcc.exe (TDM-2 mingw32) 4.4.1

Viszont nem optimalizációs hiba, mert ha adunk neki egy -O vagy egy -Os -et akkor az egész kódot "eltünteti". Legalábbis debugger alatt semmilyen változó nem látszik, és a debugnál ha a next line-ra kattintok, akkor a program végéhez ugrik.

Nekem 4.2.1 van, az látszólag nem csinálja ezt.

MOD: felraktam 4.4.4-et az se. Igaz mind a kettő cross-compiler, de mingw.

[ Szerkesztve ]

Jester

Helló,

próbálj meg eléjük rakni volatile kulcsszót. ha fv-en belül nem engedi, akkor globális namespace-ben deklaráld. illetve az u1 és u3-as tömböt írasd ki a program futása végén, hogy használva legyen. Szerintem így már nem fogja kioptimalizálni.

volatile -al már jó! Köszönöm.

Eddig is "jó" volt, még mindig nem láttam olyan kódot ami rosszul működött volna.

Mostantól viszont minden egyes írás/olvasás a memóriába megy, akár optimalizálsz akár nem (megkötötted a fordító kezét). Ez jelen helyzetben gondolom nem probléma, de azért ezt ne tanuld meg. Azt viszont tanuld meg, mit csinál a volatile, hátha megkérdezik miért tetted oda

Jester

Köszönöm! Pont most van a laborom és sikerült egy 5-öst szerezni.

Bitoperátoros, tömbös, ciklusos (elől-hátul tesztelős) vegyes felvágott program volt, sok kritériummal.
Sikerült.

Én sem voltam tisztában a volatile kulcsszó hatásáról belső működésben, csak azzal, hogy mire használják.

Szóval igen, ebben az esetben debuggolásnál hasznodra válik majd, de ne szokd meg a használatát. Lehet, hogy jobb, ha valamilyen formában kiírod az outputra a tömböket. akkor nyilván békén hagyja a tömböket, mert tudni fogja, hogy szükség van rájuk.

Szeretnék c-t tanulni kicsit komolyabban mit ajánlanátok iskolán kívül? Most az iskolába C-t tanulok de hát semmit se tudok max ilyen tömb feltöltés stb az alapismereteim nagyon rosszak és az egyik tanárom se tanít a leg fényesebben így önerőből szeretnék fejlődni ha lehet mert így eléggé le vagyok maradva jópár oszt társammal együtt (2 csoport van az egyik semmit nem tud programozni a másik meg egész jó én a rosszabba vagyok)

én azt ajánlom, hogy gyakorolj

itt rengeteg forrást találsz, sok gyakorlati példát.
http://infoc.eet.bme.hu/

[ Szerkesztve ]

C - Mi történik ha egy tömbre mutató pointner értékét eggyel növelem, majd kiíratom?
Mi történik ha egy tömbre mutató pointner értékét eggyel növelem,majd kiíratom .Ezután egy új értéket adok a tömbnek.

Szerintem:
Ha eggyel növelem a mutatót eggyel tovább ugrik a memóriában ahol el van mentve a pointner.

Ha új értéket adok utána - nos nem tudom ,uj értéket adtam a pointernek,de nem változott meg az értéke teljesen - maradt a régi értékéből és az újból is ? de viszont a memoria cime nem változott a pointernak

#include <stdio.h>
#include <conio.h>

int main()

{

char str1[ ] = "abc";
char *p;
p = str1;
printf("1. ertek{pointnera}: %p\n",p);
printf("1. ertek{pointnera}: %s\n\n",p);
p++;
printf("2. ertek{pointnera}: %p\n\n",p);

*p='df';
printf("uj erteke : %s\n",p);
printf("uj erteke: %p\n\n",p);

return 0;
}

Szerintem:
Ha eggyel növelem a mutatót eggyel tovább ugrik a memóriában ahol el van mentve a pointner.

Nem egyel tovább ugrik a memóriában, ahol el van mentve a pointer, hanem:
A pointer értéke (egy memória cím, egy szám) nő annyival, ahány byte-os az adatstruktúra, amire a pointert deklaráltad.

Ha új értéket adok utána - nos nem tudom ,uj értéket adtam a pointernek,de nem változott meg az értéke teljesen - maradt a régi értékéből és az újból is ? de viszont a memoria cime nem változott a pointernak

Nem a pointernek adtál új értéket, hanem annak a memóriának, amire mutat a pointered.

A programod elvileg azt csinlája, hogy 'b'-t kicseréli 'd'-re (gondolom az f az csak elírás, mert aposztrófok közé csak karaktert lehet írni)

Ne stringgel teszteld, vagy ha azzal, akkor karakterként irasd ki, illetve írd a végére a string lezáró \0 karaktert is. Egy int tömbbel sokkal látványosabb a dolog.
Az elmélethez: azt is érdemes megmondani, hogy mi történik, ha egy n elemű tömb n+1-edik elemére hivatkozol/írod.

Nem vagyok nagy C-s, de valszeg a beolvasás lenyeli a sorvégét, azt most nem tudnám megmondani ezzel mit kell művelni.
A torlés viszont azért nem megy szerintem, mert az if-esle nek lefelejtetted az else ágát és a sort mindenképpen kiírod az átmeneti fájlba.

if(tmp2 == &celpont1 || tmp2 == &celpont2 || tmp2 == &celpont3 || tmp2 == &celpont4)
{
fprintf(tmp, " ");
}
else
{
putc(tmp2[TMP], tmp);
}

Szóval ezt így kéne.

[ Szerkesztve ]

Továbbá stringeket nem a címükkel hasonlítunk össze, hanem mondjuk strcpy-vel.

Jester

Thx, valóban De az strcpy az a másolás, összehasonlítás az strcmp.

Huppsz, valóban

Jester

A celpont illetve tmp2 változóid mind csak 1 karakterek, azokba nem nagyon tudsz fgets-sel hosszabb szövegeket beolvasni.

Jester

Sziasztok!
Egy egyszerű kis programocskát írok, és lenne egy olyan problémám, hogy van két tömbböm, össze akarom hasonlítani őket, egy ciklusban. Az egyes elemeket. Na, szóval 6 elemű a tömb, de csak 5 elemet akar nekem vizsgálni. A tömbbök jól vannak feltöltve, és már ötletem elfogyott, valaki segítsen mán ki
#include <stdio.h>
#include <stdlib.h>

int main()
{
int tomb_user[5]; //tomb_user tippje tömbbe alakítva
int tipp=0; //tomb_user tippje
int i=0; // tömb indexek
int j=0;
srand(time(NULL)); //random számhoz kell
int tomb[5]; //random számokat ide töltöti

while(i<6) //feltöltöm a tömbböt
{
tomb[i]=rand()%9; //%9 az a limit
i++;
}

for(i=0;i<6;i++) printf("%d ", tomb[i]);

//adatok bekérése
printf("Kerek egy tippet, hat darab szamot: ");
scanf("%d", &tipp);
if(tipp>999999){
printf("Hat szamjegyet adjon meg!\n");
printf("Kerek egy tippet, hat darab szamot: ");
scanf("%d", &tipp);
}

//user tipp tombbe alakítása
tomb_user[0]=tipp/100000;
tomb_user[1]=tipp%100000/10000;
tomb_user[2]=tipp%100000%10000/1000;
tomb_user[3]=tipp%100000%10000%1000/100;
tomb_user[4]=tipp%100000%10000%1000%100/10;
tomb_user[5]=tipp%100000%10000%1000%100%10;

//===megvizsgálom az egyes elemeket
printf("\nTalálat: ");
i=j=0;
for(i=0;i<6;i++)
{
if(tomb[i]==tomb_user[j]) {printf("H " );}
j++;

}

return 0;
}

[ Szerkesztve ]

Nem tudom feltűnt-e, de 5 elemű tömböket hozol létre, és mindenhol 6 elemet akarsz belőle használni - mondjuk azt nem értem, hogy miért nem dob erre semmilyen warningot.

[ Szerkesztve ]

0-5 az hat elem, nem?

int tomb_user[5];
int tomb[5];

Az meg öt.

Kifejtenéd mire gondolsz? 0 1 2 3 4 5 az hat elemű tömb, de lehet rosszul tudom

Rég C-ztem már, de úgy rémlik, hogy amikor létrehozod a tömböt, akkor a zárójelbe a méretét írod, tehát int tomb[5] egy 5 elemű int tömb lesz. A sorszámozás persze 0-tól indul. Így for-ban 0-tól <méret-ig lehet számolni, ami pont jó, mert szép, megjegyezhető, és mindent elárul - pl azt is, hogy 6 eleműnek akartad definiálni.

[ Szerkesztve ]

hmm, btw kipróbáltam 5 helyett hattal, így már lehet jó is lesz.
Köszönöm!

mondjuk azt nem értem, hogy miért nem dob erre semmilyen warningot

A túlindexelést semmilyen fordító nem ellenőrzi, csak futásidő alatt derül ki, vagy exception/segfault, rosszabb esetben csak a furcsa viselkedés miatt.

Sziasztok,

Lehet nem ez a legmegfelelőbb topik, de gondban vagyok egy algoritmussal kapcsolatban. Van ez a spreadsort nevű hibrid rendezési algoritmus http://en.wikipedia.org/wiki/Spreadsort itt található a leírása. Na most a baj az, hogy a rövid kis leírásból nem lehet rájönni, hogy pontosan, hogy is rendezi ez a sorozatot. Alatta van egy gyönyörű C/C++-ban írt kód, ami elvileg a rendezés algoritmusa, de abból meg nem sokan értek, mivel java, C#-on nevelkedtem és itt jobbra balra bitshiftelnek ha jól látom. Az a baj, hogy nekem be kéne mutatnom, hogy hogy működik ez a rendezés, de nem értem egészen pontosan. Légyszi valaki aki jó C-ben vagy algoritmusokban vessen rá egy pillantást és magyarázza el nekem hogy működik ez az algoritmus.

Köszönöm előre is.

mivel java, C#-on nevelkedtem és itt jobbra balra bitshiftelnek ha jól látom

Ez aztán a jó kifogás
Mintha azokban a nyelvekben nem lenne bit shift.

A rövid kis leírás pont elmeséli hogyan működik. Veszi a tömböt, megkeresi a legkisebb és legnagyobb elemeket. Az így megkapott intervallumot elosztja egyenlő részekre majd ezeket a részeket rekurzívan rendezi. A rekurzió során bizonyos elemszám alatt már másfajta rendezést használ.

Jester

Igen, eddig én is eljutottam, abból ha az intervallumokat rendezed, nem lesz rendezett listád. Akkor sem ha a végén n elemszámú listában n darab intervallumod lesz. Max akkor lenne a végén rendezett ha még a rendezett intervallumokat összefésülnénk, ami igen hatékony de egy TimSort nevű rendezés sokkal jobban csinálja, szóval itt nem ez a lényeg. A lényeg ott lenne, hogy a min és max elemek közé úgy pakoljuk be az elemeket, hogy valamilyen csoportosításba kerüljenek mint a BucketSortnál pl 10-20, 20-30, 40-50- ig stb. Ezután az intervallumok rendezésével akár rekurzivan egy rendezett sorozatot kapnánk a végén. De mivel a leirásban az is szerepel hogy egyenlő elem számú intervallumokra osztja, tényleg nem értem hogy csinálja, hogy a végén rendezve is legyen az egész lista, ne csak az intervallumok.

A leírás elég egyértelmű. Gyakorlatilag egy quicksort, csak nem egy hanem több pivotot használ -> 2 helyett több partíciót csinál az elemekből aztán rekurzívan azokat is rendezi, és így tovább. Ha nem ismered a quicksortot akkor először azt nézd meg, és utána érteni fogod.

Aműgy ebbe a topicba szerintem jobban illene a téma: http://itcafe.hu/tema/programozas_forum/hsz_1-50.html

[ Szerkesztve ]

A lényeg ott lenne, hogy a min és max elemek közé úgy pakoljuk be az elemeket, hogy valamilyen csoportosításba kerüljenek mint a BucketSortnál pl 10-20, 20-30, 40-50- ig stb.

Igen, ez így történik. Mivel az értéktartományt osztja szét részekre és az elemeket szétdobálja. Utána pedig az egyes részeket is berendezi. A két rendezésből az egész rendezve lesz. Az intervallumok viszont nem lesznek egyenlő számosságúak.

Jester

"Mivel az értéktartományt osztja szét részekre és az elemeket szétdobálja. Utána pedig az egyes részeket is berendezi. A két rendezésből az egész rendezve lesz. "

Ehhez annyit még hozzátennék, hogy nem két rendezésről hanem n darab rekurzióról beszélünk. A részekre ugzanez a rendezés lesz ráeresztve, majd azoknak a részeire is egészen addig amíg egy-egy részben nem 0-1 elem marad ami már rendezett, és akkor elkezdenek visszatérni.

Ohh.. my bad De ebben a hszben rosszul nézett ki

Ismerem az összes rendezést köztük a quicksortot is mert ezelőtt, már 4 másik hibrid rendezést megvalósítottam amiben benne volt a quicksort is egyikben.

DE!

A leírás azt írja equal-sized bins! Az equal sized az azonos méretű. ha választok véletlenszerűen pivot elemeket és szétdobálom közöttük, baromira nem biztos hogy equal sized -ok lesznek, és akkor minek kerestem meg a min és max elemet. Itt olyan intervallumokra kell osztani amiben egyenlő számú elemek vannak, ez nem egy quicksort több pivottal, mert akkor azt írná.

Equal-sized az értékkészletben. Nem azonos elem számosságú. Legalábbis a mellékelt kód szerint. Pl itt látszik:
// Calculating the size of each bin; this takes roughly 10% of runtime

Végigmegy az elemeken és megnézi melyik bin-be kerülnek, aztán a bin-ek kezdőpozíciót a számosságok alapján számolja ki.

Jester