Nem a C++ nyelv ellen irtam, amit irtam, s persze, hogy nincs nagyobb gond, ha tud ilyesmit az ember. Inkább ugy mondanám, hogy csaloka a fordito. Mindegy azt, hiszem most már tudom, hogy vigyázni kell és akik követték a témát talán jol is jött nekik.
Azért kiváncsi lennék hol vannak még ilyen rejtett csapdák.

A pointereknél, a tömb kezelésnél, a karakter típusnál, főleg, ha ékezeteset akarsz kezelni (1byte helyett 2byte-on van tárolva). Igazából mindenhol
Aztán lehet tovább menni, osztályok, különböző típus definíciók, függvények, amik automatikusan a megfelelő típust választják ki amikor meghívod, nem problémáznak, ha hiányzik egy paramétere, stb.

Nem a C specialitása. Más nyelveknél is figyelni kell a típusok közötti átalakításra, előjelekre stb. Pláne ahogy korábban valaki írta mikrovezérlő típusonként is másképp kezelik.

Itt csak az volt a gond, hogy egy egyszerü egyenletet másképp kezel, ha más sorrendben irod be a változokat. Ami matematikai nonszensz. ( ez olyan lenne, mintha 5x10 nem lenne egyenlö a 10x5-el). Erre valo utalást viszont eddig nem találtam.
Az természetesen rendben van, ha az ember rájön a turpisságra és ki is deriti mi a gond.
Nyilván, ha lépésenként kezeltem volna, akkor hamarabb kiderült volna a hiba, de ilyesmire sincs nagyon irott utalás. Elhiszem, minden nyelvben lehetnek ilyen gondok ( kivéve az ASM-t mert ott alapbol tudod mit rakhatsz be a változokba), de erre lehetne utalni vagy talán a fordito jelezhetne.
De azt hiszem, már teljesen kiveséztük a dolgot.

Nem a műveletek sorrendjéből adódott a probléma, hanem abból, hogy a részeredmény nagyobb volt mint amit a változó típus megengedett, így az túlcsordult... Ilyen a C!

Az világos, de ha leirsz egy képletet, akkor nem biztos, hogy arra gondolsz, hogy a fordito stb. nem tud vele mit kezdeni, söt ami rosszabb, rossz eredményt ad, és erre semmi sem hivja fel a figyelmed. (Holott az AVRchipben az adott esetben már tulfolyott valamelyik regiszter, azaz hiba belül megjelent. )
És végeredményben a sorrend változtatása segitett, ami szintén félrevezetö.

A fordító nem tudhatja, hogy mi lesz a szorzó érték tartománya... Ha mondjuk jelen esetben 0-7 akkor a program hibátlan, miért reklamálna?

Nem akarom én vesézni, csak segítségképpen magyarázatkot szerettem volna adni, mint most is.
A fordító nem tudhatja, hogy te mit szeretnél az adott változóval, pláne, mivel az változó, tehát ő nem tudhatja, hogy te akkora értéket is fogsz neki adni ami túlcsorduláshoz vezet. Programfutási időben meg már semmi köze hozzá. Hol is mutatná futási időben? Nyilván, ha PC-n vagy akkor kíírhatná, de amikor mikrovezérlőre írod, honnan tudja van-e kijelző csatlakoztatva, van-e rajta visszajelzéshez felület, stb. Mindig a programozónak kell ismernie a hardvert és a fejlesztői környezetet.

Azért nagyon kiváncsi lennék, hogy hány ember futott bele egy ilyen problémába, mert csak a szerencsén mulik milyen formában irod be ugyanazt az egyenletet/képletet.
S mint irtam nagyon is van az AVR-ben több jelzö is amelyik jelzi a belsö hibát, azaz ki is jelezhetné amikor leforditod, hogy az adott esetben baj van a koddal.
Szeretmén befejezni, mert ugy látszik nincs vége az eszmefuttatásoknak.

Ez a programozás alapjaihoz tartozik. Az elején meg kell tanulni, és onnantól oda kell figyelni. Ez is egy szakma, ahogy a feleségem szokta mondani.

Az a baj, hogy abból indulsz ki amit gondolsz, hogy hogyan kellene működnie. Ahelyett, hogy meghallgatnád amit többen is próbálnak elmondani neked. Segítséget kérsz, majd amikor korrekt, szakszerű választ kapsz, akkor látványosan ignorálod. Már az előző témánál is ezt tetted. Őszintén szólva én ott el is határoztam, hogy többet nem fogok segíteni. Nem bántásképpen írom, hanem azért, hogy ha nem változtatsz a hozzáállásodon, akkor ne csodálkozz, ha a többiek is így fognak esetleg dönteni.

Sziasztok! Arduino Leonardóval szeretnék ezen leírás alapján egy ATmega328-P PU-ra bootloadert felrakni, de ezt a hibaüzenetet kapom:
Az összekötések rendben vannak. A kvarc viszont 16MHz-en pár cm-ről CW-n meghallgatva nem ad jelet.
Mi lehet a megoldás?

Egyetértek. Megvan az oka, hogy miért működik így. Le van írva a dokumentációban, el kell olvasni.

Amíg mindig válaszolsz valamit, sosem lesz vége!
Gondolj bele, egy programozónak tudnia kell, hogyan vannak a számok tárolva, hogyan kell programozni. Én mondjuk pont ki akarom használni a túlcsordulást, ezt a "hibás" számolást, mert a feladat ezt adja, akkor miért kellene reklamálnia a fordítónak? Vagy amikor egymás mellett van & és &&, szólnia kellene? (az Atmel Studio szól egyébként ). Plusz a fordítónak fogalma sincs, hogy te az összeadással mit akarsz kezdeni. Ő összead akár két karaktert is, nem különösebben érdekli

Ráadásul változó van benne, aminek fordítási időben nincs értéke.
Futás közben meg szegény AVR honnan tudja, hogy neki most valami hibaüzenetet kellene küldenie. Na és ha kellene, hova is küldje? IIC, SPI, PIN-t állítson be, vagy füstjelet küldjön?
Mindegy, elég részletesen elmagyaráztuk. Részemről ennyi.

Onnan, hogy tulcsordul ez az.( van vagy 8 regiszter ilyesmire ). Na mindegy, azért érdekes lenne egy zsebszámologép, ha igy viselkedne egy primitiv egyenlet számolásánál...

Két 16 bites értéket összeszorzol. Mivel a szorzat nem fér el 16 biten ezért aztán túlcsordul. Azt nem mondod meg neki, hogy légyszi 32 bitesként szorozzad. Szerinted mégis mit is kellene csinálnia szerencsétlennek?

Ez nem egy zsebszámológép. Ha egyenletmegoldásra akarod használni, akkor neked kell gondoskodnod ezekről a dolgokról, mert te vagy a programozó.
A programozó pedig nem a felhasználója, hanem a tervezője és készítője valaminek. Ez fontos különbség.

Füstjelet küldjön!!! Aztán jöhet a páka!!!

A zsebszámológépben a programozó rendesen leprogramozta.

Amugy hibátlqn megoldás ez lett volna Y=(long)K * (long)2000 / X, de a sorrend megváltoztatása egyszerübb.

Úgy látszik csak egy nap késéssel olvasod el a válaszokat, mert tegnap ugyanezt írtam.

Nem csak egy napig itt okoskodás folyt, holott kétszer kértem, higy hagyják abba mert semmi értelme nincs. Rajtad kivül érdemben senki semmit nem mondott. Ennyi.
Befejeztem!

"Rajtad kivül érdemben senki semmit nem mondott." - a köszönöm jobban esik az embernek De semmi gond, megválogatom, kinek segítek.

ÜDV!

Én meg a mutatókkal bajlódok állandóan.
Egyszer már megcsináltam régebben, de azóta HHD hiba miatt elveszett és már nem emlékszem hogy volt. Van egy tömböm, és abba szeretnék változó vagy másik tömb adatait beilleszteni, úgy, hogy azt a beillesztett tömben is lássam futásidőben.
Tehát pl:

Addig megpróbálom összerakni, hátha sikerül magamtól is.
Valamint azt elfelejtettem, hogy ez esetleg oda-vissza működjön, tehát ha t1-et változtatom az t2-ben is látszódjon, de lehet, hogy erre nem lesz most szükségem, még nem tudom.

Odáig eljutottam, hogy tömbből tömbbe tudokmásolni mutatókkal és memcpy-val, de nem tudom, hogy az oda-vissza átjárhatóság megoldható-e valahogy.

Szia. Szerintem erre felesleg a memcpy. Pl.

Ez is megy, köszönöm, de gondoltam a memcpy gyorsabb. Én valami olyat szeretnék, (nem tudom megoldható-e), hogy fixen össze legyen kötve. Tehát ha megadtam neki, hogy t2 elemei t1-be hova illeszkedjenek, akkor ha bármikor módosítom a t2 elemeit, ne kellken újra bemásolini t1-be.

Értem, persze memcpy -vel is megoldható, de akkor nagyon vigyáznod kell nehogy tulhaladj a t1 változó memoria címén és felülírj más memória címeket mert akkor annak csúnya következményei lehetnek.
Pl.

Én az unio.n-ra gondolok hogy esetleg használható lenne valahogy. Bár az nem címezhető. (Az "unio.n"-ban a pont a motor miatt kellett, neked az nem kell )
De miért kell hogy oda-vissza menjen? Amikor írod, akkor tudod hogy írod nem? Egyszerűen íráskor beírod mindkét helyre és kész. Olvasni meg már azt olvasod amelyiket akarod.