[elektro] (C) programozási kérdés

[hg12345]

Köszi a segitséget.

Az ASM szeretném kihagyni a következő termékekből. Marad a C :-).

A HEAP-t eddig kihagytam a lehetőségek közül. De nagyon tényleg mindnt kereszthivásokkal kezelek.
Ezeket a kereszthivásokat egy közös belépési pont elfedi, de pont ezekkel van problémám.
Az összes kereszthivatkozó függvény pont a "hiba megelözést" végzi, és a visszatérő érték több mint hiba/jó.


A header kezelés is hasonló az általad írthoz.



Info <info at kiralyelektronika.hu> írta:
>> egy kérdésem lenne nagyobb program írókhoz.>
Hát sajna 5-10e sornál meg szoktam állni, ez a kicsik közé tartozik.>
>
> ASM-ben is írtam nagy programokat, de az alkalmazás miatt nem>
> volt a technika kérdés egybe kellett includolni.>
Háát, azért lehet ott modulokat létrehozni, van extern, export>
kulcsszó, sőt C-be is lehet importálni, a linkernek mindegy mit>
eszik...>
>
Ha nagy asm-es vagy (mondjuk én is azt preferálom :) szóval próbáld>
úgy elképzelni illetve meg is csinálni, mintha modulokat használnál.>
Kitalálsz valami hívási konvenciót, mittomén a hívó fél kezeli a>
paramétervermet a hívott meg csak a változóit (heap) foglalja és így>
felépíteni a programodat. Minél kevesebb keresztbehívással (sajna az>
optimalizálás kárára) és annál több hibaellenőrzéssel.>
Magasabb szinteken előszeretettel módi, hogy ha nem tudunk valamilyen>
paramétert akkor 0-val hívjuk a függvényt.>
Pl. egy bool ReadReplyFromBuf(ptr pDestBuf, pdword pBufSize) függvényt>
lehet így is használni:>
  if(ReadReplyFromBuf(0, &requestedSize) &&>
     (requestedSize < cMainBufSize)) {>
         ReadReplyFromBuf(&MainBuf[0], &requestedSize);>
         ...>
  }>
ugye itt NIL a mutató, és egyből hibára szaladnál ha nem ellenőriznéd,>
viszont kíválóan használható így arra, hogy lekérdezd van-e elég adat,>
érdemes-e foglalkozni vele, stb.>
 Szóval ki kell használni a nyelv lehetőségeit, hogy van egy>
függvényed és azt több dologra használni még akkor is ha többször>
hívod és többet ellenőrzöl, heapot kezelsz, stb. Ezek járulékos>
dolgok, de minél feljebb lépsz ez csak fokozódik. C++-ban pl. már ha>
betöltessz egy objektumot az inicializálja a belső változóit, esetleg>
kapcsolódik, megkeresi a "helyét" ezközöket, stb., szal ott már a>
forráskód még olvashatóbb de asm-nézetben sokkal kuszább és sok>
felesleges dolog történik. Bele kell törődni, és megpróbálni segíteni>
a futásban más módon. Pl., dword-alignmentet megengedni, ez is sok>
fölösleges lukat eredményez, lehetőleg a sokat használt flageket nem>
bitstruktúrában elérni mert minden hozzáféréskor tologatni fogja.>
Szóval a pár kByte/IT rutin + 5-10kByte math könyvtár sajna vele jár.>
>
> Itt a C-ben a programrészek szétszedve külön forditási>
> egységben, de az includok lassan minden fordítási egységben>
> megjelennek. A program eléggé összetett. Lassan minden include>
> mindenütt szerepel.>
> Ez em tetszik!>
>
Nem is jó az.>
>
> Van erre valami értelmes szabály ami ezt kikerüli?>
>
Hierarchia, és rejtés.>
>
"hwinit.h":>
#ifndef INIT_H>
#define INIT_H>
 void InitGPIO(void);>
 extern dword LED_PIN;>
#endif>
>
"serial.h":>
#ifndef SERIAL_H>
#define SERIAL_H>
#include "hwinit.h">
 void InitCOMport(void);>
#endif>
>
"main.h":>
#ifndef MAIN_H>
#define MAIN_H>
#include "serial.h">
 void Main(void);>
#endif>
>
Így minden include egyszer fut le egy .c-ből hívva, nem lesznek>
felüldefiniálások. A változók foglalása sem a headerekben hanem a>
.c-ben van, a .h-ban csak jelzed, mint extern cucc, valahol majd lesz.>
>
Pl. egy szimpla kommunikációt szétbonthatsz:>
- hw kapcsolat, ellenőrzés, időzítés, eseménykezelés (hwio.c)>
- bufferkezelés                                      (mem.c)>
- megnyitás, lezárás, akitív/foglalt lekérdezés      (com.c)>
- kódolás/dekódolás                                  (crypt.c)>
- eseménykezelés                                     (driver.c)>
- önálló feladatok                                   (modbus.c)>
>
Szóval nem egyszerű, qrvasok kód, define, konstansok, kommentek, de>
végül nagyon meg fog tetszeni, mert átlátható, egyszerűen olvasható>
mintha könyv lenne. Az tuti, hogy mivel elsődlegesen az olvashatóság a>
szerepe a magasabb szintű nyelveknek érdemes nem lehagyni az>
5-10-soros kommenteket a függvények előtt, részletezve mit csinál, mi>
lehet a hibája, futási feltétele, stb. Hálás dolog ha vissza kell>
nézni :)>
>
> Vagy eleve másképp kell programozni? Érdemes minden különálló>
> programnak UI felületet gyártani, egy belési ponttal és funkció>
> felsorolással? (Mondjuk ez egy kicsit lassítaná a programot, de>
> lassan olyan korszakban élünk, hogy ez szinte észrevehetetlen.)>
> Persze ez is problémás mert a funkciók nem azonos adatokat />
> strukturákat kérnek!>
>
Igen!>
Lehetőleg önnállóan működjön, minél jobban közelítsd meg a következő>
C++ szintet, azaz ha mondjuk includolsz akkor állítsa be a>
perifériákat magától akár ifdeffel, építs valami vázat az időkritikus>
események kezelésére, főleg a szemaforos threadra gondolok ami nemrég>
volt téma, közös adatstruktúrák létrehozása mondjuk a types.h-ban, így>
ha meghívod egyből tudni fogja minden rész mi az a t_AkarmiStruct...>
>
----------------------------------------->
          elektro[-flame|-etc]>