Két tömb elemeit hogyan lehet egymáshoz adni?

Nem kötekedésből, de nem egyezik azzal az alapelvvel ami ez esetben a tomb3 kiíratása az a kiíratásával foglalkozzon előfeltételezés nélkül és független legyen attól hogy miből jött ki.

Amúgy a specifikáció szerint jól működik. Bár legalapabb szinten nem kell még ezt tudni.

Mondjuk, ha szigorúan veszem akkor nem is kell kiíratni sehogy, a feladat arról nem szól,de ettől én is eltekintettem.

"Bár legalapabb szinten nem kell még ezt tudni."

Mármint amit a kiíratásra mondtam.

"Nem mondhatnám, hogy értem az első mondatot"

Kihasználtad hogy tomb1 mérete az annyi mint tomb3 és tomb1-et vizsgálva megállapítottad for ciklussal hogy hány elemét írasd ki hogy kiírasd minden elemét. Ami valóban teljesen logikus és helyes eredményt ad itt, ezt nem vitatom. Viszont szoftver fejlesztés szempontjából ez nem preferált stratégia. Úgy szokták hogy van egy adatszerkezet melyhez definiáljuk hogy lehet bejárni azt, tudja az algoritmus ha a végére értünk csak magáról az adott adatszerkezetből. (Ugye nem csak tömb lehet egy adatszerkezet hanem lehet pl. hash tábla, láncolt lista, bináris fa, ezek keveréke.) Ha nem így tennék akkor nagyon megnehezítenénk a hibakeresést ezzel ha módosítunk rajta egy nagyobb forráskód halmazról van szó ami több forráskódfájlból is áll, ami nehezítés elkerülhető lett volna. Plusz ugye a kód újrafelhasználást is rontja. Ha ilyet már csinált az ember eleget, akkor már szúrja a szemét ha lát ilyet, legalábbis nekem. Nem is érzek rá kicsiben sem késztetést, hogy ne így alkossam meg még akkor se ha nincs semmi hátrány belőle.

"Apropó kiíratás. Mi van akkor, ha nem nem kiíratni akarom a tomb3-at, hanem visszatérési értéknek megadni? (return)"

Ugye meg kell oldanod, hogy tudd hol a vége, amit kifejtettem már. Viszont ezzel vigyázz! Ha a tomb3 az osszead függvényen belül van deklarálva akkor a return után a tömb megszűnik. Ugyanis a stack-en jön létre és tárolódik ideiglenesen. Maga az egész függvényhívás egy verem szerkezettel van megoldva. Az meg külön említésre méltó, hogyha nem tömb hanem int lenne, akkor az miért nem szűnne meg. Az is megszűnne, csak a másolat jön létre. Tömbök esetén meg nem magát a tömböt hanem memória címet ad át a függvény illetve kap meg, ha megadod argumentumba neki.

„Kihasználtad hogy tomb1 mérete az annyi mint tomb3”

Én semmi ilyesmit nem használtam ki, csak azt az együgyű tényt, hogy ugyanannyi értéket kell kiírni, mint amennyit beolvastál, tehát a kiírást is vezérelheti ugyanaz a végejel-vizsgálat, mint az eredmények eltárolását. A tömbök mérete ebből a szempontból közömbös, eltekintve attól, hogy az eredményeknek el kell férniük tomb3-ban. Ha ez teljesül, onnantól fogva már akármekkora lehet.

Mindez nem változtat azon, hogy a lényeget tekintve igazad van: Érdemes eleve szerkezetben gondolkodni. Erre éppen Kérdező szolgált ékes példával, akinek hirtelen eszébe jutott, hogy az alkalmilag a memóriába hányt adatsort inkább visszatérési értéknek használná. Innét már nyilvánvaló értelmetlenség volna elvárni a programtól, hogy továbbra is tomb1-et vizsgálgassa tomb3 helyett, amelyhez voltaképpen semmi köze, nem beszélve az ilyen globális megoldások egyéb kockázatairól. Vagyis a visszakapott tomb3 értelmezésének függetlennek kell lennie a másik tömbtől, és ehhez saját adatszerkezet szükségeltetik.

"Én semmi ilyesmit nem használtam ki"

Pont te ragaszkodtál ehhez korábbi hozzászólásodban, hogy minek akkora a tomb3 azért mondtam. Jó igazából 1-el kevesebb elemű a végjel hiánya miatt tomb3.

Az csak egyszerű takarékoskodás volt (épp úgy, mint a char tömbök használata int helyett), a program működéséhez nincs köze. A kelleténél eggyel rövidebb -- tehát a végejel elhelyezésére is alkalmatlan -- tomb3 használata már ezt a fukarkodást fordította groteszkbe, sajnálom, ha nem ment át az önirónia.

Közben megpróbálkoztam tomb3 visszaadott értékként való hasznosításával is, az így ütött ki:

[link]

Töltsd fel inkább valami normális oldalra, mert tegnap óta akárhányszor néztem nem működött!

[link]