[elektro] Fw: C18 előfordító

elight elight at gmail.hu
Wed Jun 17 12:37:39 CEST 2015


Soha nem használok put();  gert();  függvényt.
Ja meg printf() et sem... Ezek régi beidegződések.. :-)
Igaz multiplatform , meg win sem készül semmi...

Üdv István
2015-06-17 12:33 keltezéssel, hg12345 írta:
> Azért van ennek az ellenkezője is. hogyan oldod meg a put és get fügvények megfelelő ki és bemeneti perifériákhoz csatolását.azért ilyenkor némileg át kell írni ez a két függvényt...
> "Balla zoltán" <sdrlab at yandex.ru> írta:
>> Feladó: "Kiss Gabor" <kissg at ssg.ki.iif.hu>
>>> Na tegyük fel, hogy minden úgy van, ahogy szeretnéd!
>>> A _fordító_ észreveszi, hogy egy "gyári" függvénynek csupa konstans
>>> (pontosabban fordításkor ismert értékű) argumentuma van,
>>> ezért _forditási_ időben meghívja azt, és az eredményt teszi a
>>> függvényhívás helyére.
>>>
>>> Ezt szeretnéd, ugye?
>>>
>>> Na akkor nézzük mi történik ebben az esetben!
>>>
>>> char *a, *b;
>>> int len;
>>>
>>> a=malloc(16);
>>> b=malloc(16);
>>> strcpy(a, "kutya");
>>> strcpy(b, "cica");
>>> printf("%s nem %s\n", a, b);
>>>
>> Nem ismerem a malloc függvény realizálását belülről, de nyilván memóriát
>> foglalni csak futásidőben értelmezett.
>> Ezért _sem_ kellene beletúrkálni a gyári függvényekbe, mert akkor a fordító
>> kapából tudja, mi az ami kiszámolható, mert értelmezhető rá a számolási
>> művelet, és mi az ami _csak_ futáskor...
>> Értem én, hogy a C lehetőséget ad a berhelésre, és ettől kezdve nincsenek
>> dedikált függvények. Az egész felvetésemnek az az alapja, hogy _nem_ nyúlunk
>> a gyári függvényekhez, mert minek ??!! Hisz enélkül is tökéletesen és gond
>> nélkül megoldható minden, akkor minek ?! Ha pedig mégis hozzányúlunk, mert
>> mi olyan profik vagyunk, akkor meg garantálnunk kell az eredetivel vali
>> visszafelé kompatibilitást. De ez már a saját felelősségünk. A fordító ekkor
>> még mindig korrektül járhat el, hisz tudja mely függvényeket számolhatja
>> előre ki, melyeket nem.
>>
>> Zoli
>>
>> -----------------------------------------
>>           elektro[-flame|-etc]
> -----------------------------------------
>            elektro[-flame|-etc]



More information about the Elektro mailing list