4. OOC mit Macros, Events, Listen und Exceptions

OOC mit Macros, Events, Listen und Exceptions

  • ?

    fricky schrieb:

    wer dogmen anbringt, kriegt auch gleich 'ne exception vorgesetzt.

    Hehe. Ich will versuchen, das Dogma zu retten:
    Satz: Zu jedem malloc() muss ein free(), ausser die Welt geht gerade unter.

    Antoras schrieb:

    Konstuktoren sind dagegen so einfach zu realisieren, dass auf diese mit Sicherheit nicht nur in OO-Sprachen gesetzt werden sollte.

    Ich hab's mir nocheinmal angesehen:

    GLDisplay *display = newGLDisplay("TestProject");
    TestRenderer *renderer = newTestRenderer();
    InputHandler *handler = newInputHandler(renderer, display);

    So ganz hat man damit noch keine Konstruktoren wie in Java, weil die dort etwas erzeugen, was von selbst wieder verschwindet. Wenn aber zB newGLDisplay() Aufrufe von malloc() enthält, solltest du dich, wie das Dogma befiehlt, auf free() einstellen.

    Wie du dafür sorgst, dass free() aufgerufen wird, ist aber völlig dir überlassen. Du könntest zB eine Liste mit Zeigern auf alle allozierten Blöcke unterhalten, um am Ende den Speicher automatisch freigeben zu können. Da würde es dann reichen, am Ende von main zu sagen: free_all(liste) .

    0
  • S

    µngbd schrieb:

    Hehe. Ich will versuchen, das Dogma zu retten:
    Satz: Zu jedem malloc() muss ein free(), ausser die Welt geht gerade unter.

    Wenn wir schon dabei sind, dann
    Satz: Zu jeden malloc() muss ein free() , sonst geht die Welt unter. 😉

    µngbd schrieb:

    Antoras schrieb:

    Konstuktoren sind dagegen so einfach zu realisieren, dass auf diese mit Sicherheit nicht nur in OO-Sprachen gesetzt werden sollte.

    Ich hab's mir nocheinmal angesehen:

    GLDisplay *display = newGLDisplay("TestProject");
    TestRenderer *renderer = newTestRenderer();
    InputHandler *handler = newInputHandler(renderer, display);

    So ganz hat man damit noch keine Konstruktoren wie in Java, weil die dort etwas erzeugen, was von selbst wieder verschwindet. Wenn aber zB newGLDisplay() Aufrufe von malloc() enthält, solltest du dich, wie das Dogma befiehlt, auf free() einstellen.

    Wie du dafür sorgst, dass free() aufgerufen wird, ist aber völlig dir überlassen. Du könntest zB eine Liste mit Zeigern auf alle allozierten Blöcke unterhalten, um am Ende den Speicher automatisch freigeben zu können. Da würde es dann reichen, am Ende von main zu sagen: free_all(liste) .

    Nur weil es "automatisch" (wie in Java/C++) nicht geht, heißt es nicht, dass sie nicht Konstruktoren sind. Sie reservieren Speicher, initialisieren das Objekt, sprich sie erledigen die Arbeit eines Konstruktors, somit sind sie auch Konstruktoren. Ein beliebter Fehler bei OO ist es zu glauben, dass bei OO alles "automatisch" gehen muss.

    Und was das free angeht, so kannst du den Code auch weiter vervollständigen:

    GLDisplay *display = newGLDisplay("TestProject");
TestRenderer *renderer = newTestRenderer();
InputHandler *handler = newInputHandler(renderer, display);

...

free_InputHeandler(handler);
free_TestRenderer(renderer);
free_GLDisplay(display);

    wo ist dann das Problem? Und wenn du dir das sparen willst, dann kannst du dir einen mini-garbage collector für deine Objekte mit man: atexit(3) basteln.

    0
  • ?

    supertux schrieb:

    µngbd schrieb:

    Satz: Zu jedem malloc() muss ein free(), ausser die Welt geht gerade unter.

    Satz: Zu jeden malloc() muss ein free() , sonst geht die Welt unter. 😉

    es gibt mindestens eine welt, in der zu jedem malloc() ein free gehört().
    🙂

    0
  • ?

    supertux schrieb:

    Wenn wir schon dabei sind, dann
    Satz: Zu jeden malloc() muss ein free() , sonst geht die Welt unter. 😉

    Satz: Zu jedem free() gehört ein malloc() , sonst geht die Welt wirklich unter.

    0
  • P

    +gjm+ schrieb:

    supertux schrieb:

    Wenn wir schon dabei sind, dann
    Satz: Zu jeden malloc() muss ein free() , sonst geht die Welt unter. 😉

    Satz: Zu jedem free() gehört ein malloc() , sonst geht die Welt wirklich unter.

    Ihr seid sicher, daß die Welt malloc() und free() braucht, um nicht unterzugehen? Wenns nicht mehr braucht ... Cool! 🕶

    atexit kannte ich übrigens noch nicht ... man lernt nie aus ... 😉

    0
  • ?

    +gjm+ schrieb:

    Satz: Zu jedem free() gehört ein malloc() , sonst geht die Welt wirklich unter.

    also stimmt es doch, was ich immer gegelaubt habe, dass unsere welt erst seit wenigen sekunden existiert.
    🙂

    0
  • ?

    also stimmt es doch, was ich immer gegelaubt habe, dass unsere welt erst seit wenigen sekunden existiert.

    Witzig, das hab ich auch schon öfter gedacht. Aber irgendwie müßig, darüber nachzudenken.
    🙂

    atexit kannte ich übrigens noch nicht ... man lernt nie aus ...

    Ich hatte das für eine POSIX-Sache gehalten, aber atexit(3) sagt, daß es schon in C89 vorhanden war. Hätte ich schon öfter verwenden sollen... 🙄

    0
  • P

    µngbd schrieb:

    Ich hatte das für eine POSIX-Sache gehalten, aber atexit(3) sagt, daß es schon in C89 vorhanden war. Hätte ich schon öfter verwenden sollen... 🙄

    Jaa, ich hab auch gestaunt, aber ein paar meiner embedded- compiler kennen das nicht, da wird's das wiederentdeckte goto tun müssen ...
    🙄

    0
  • ?

    pointercrash() schrieb:

    µngbd schrieb:

    Ich hatte das für eine POSIX-Sache gehalten, aber atexit(3) sagt, daß es schon in C89 vorhanden war. Hätte ich schon öfter verwenden sollen...

    Jaa, ich hab auch gestaunt, aber ein paar meiner embedded- compiler kennen das nicht...

    du kannst es leicht selbst einbauen, einfach ein kleines array von function pointern machen, dann den startup/exit-code so manipulieren, dass er, nachdem 'main' verlassen wurde, die liste durchgeht und alle funktionen darin aufruft.
    ach ja: wenn die main verlassen wird, geht die welt unter.
    🙂

    0
  • P

    ;fricky schrieb:

    wenn die main verlassen wird, geht die welt unter.
    🙂

    Achsoo, und ich dachte, wenn die welt verlassen wird, gibt's keine main() mehr.
    Bin eh grad am Abwägen, ob goto praktischer ist oder das Selbstschreiben eines C- Compilers und hab' dabei festgestellt, daß wir alle nur ein FIG- Port und somit völlig verdreht sind ... 😃
    Uiui, DAS war OT 🙄

    0
  • A

    Ich implementiere zu jedem Konstruktor auch immer einen Dekonstruktor. Ich hab diese bisher nur immer während des Programmablaufs aufgerufen, nie bei Prozessende. Wenn ihr der Meinung seid, dass das aber sinnvoll wäre, dann mache ich das ab jetzt in Zukunft immer.

    supertux schrieb:

    wo ist dann das Problem? Und wenn du dir das sparen willst, dann kannst du dir einen mini-garbage collector für deine Objekte mit man: atexit(3) basteln.

    Hey, die atexit-Funktion ist genial. Danke für den Tipp. 🙂

    ;fricky schrieb:

    du kannst es leicht selbst einbauen, einfach ein kleines array von function pointern machen, dann den startup/exit-code so manipulieren, dass er, nachdem 'main' verlassen wurde, die liste durchgeht und alle funktionen darin aufruft.

    Noch en besserer Tipp. Warum ne Lib benutzen wenn man es auch selber machen kann?

    Exceptions lass ich jetzt wahrscheinlich doch komplett wegfallen. Konsolenausgaben reichen für meine Programme bisher vollkommen aus.

    ;fricky schrieb:

    wie jetzt? einen webserver willste nicht in C aber in asm machen? das halte ich für keine gute idee. ok, wenn du spass daran hast, dann mach es, aber C finde ich gerade für sowas wie (embedded) webserver ideal. auch kannste C-code leichter auf andere targets portieren, was mit ASM nur geht, wenn der andere controller auf derselben CPU-familie basiert.

    Das liegt daran, dass das dar Mini-Webserver nicht besonders leistungsfähig ist - da halte ich selbst C für overpowered...
    Aber mal gucken wie groß der Aufwand im Endeffekt ist, vllt. lohnt sich es ja doch noch auf C umzusteigen.

    ;fricky schrieb:

    ach ja: wenn die main verlassen wird, geht die welt unter.

    Also, ich finde die Welt geht erst unter wenn die Lebensquelle(Stecker) nicht mehr ist...

    0
  • S

    Antoras schrieb:

    Noch en besserer Tipp. Warum ne Lib benutzen wenn man es auch selber machen kann?

    super, erfinde doch das Rad noch einmal, am besten lässt du dich das Rad 2.0 patentieren. 😕

    Viele Bibliotheken sind länger getestet und somit stabiler, was ein großer Vorteil bedeutet, vor allem, wenn man produktiv arbeitet. Außerdem haben viele auch Portierungen für andere Plattformen und wenn du ein Produkt für mehrere Plattformen haben willst, dann ist es blöd, alles selber machen zu müssen.

    Also, ich weiß nicht, ob du uns auf den Arm nehmen willst, oder echt ernst meinst, einen Webserver in ASM schreiben zu wollen, aber C als overpoweder zu halten 😕

    0
  • A

    supertux schrieb:

    super, erfinde doch das Rad noch einmal, am besten lässt du dich das Rad 2.0 patentieren. 😕

    Viele Bibliotheken sind länger getestet und somit stabiler, was ein großer Vorteil bedeutet, vor allem, wenn man produktiv arbeitet. Außerdem haben viele auch Portierungen für andere Plattformen und wenn du ein Produkt für mehrere Plattformen haben willst, dann ist es blöd, alles selber machen zu müssen.

    Ich hab halt einen Splean und möchte alles selber machen. Dass das aber nicht so ohne weiteres möglich und auch sinnvoll ist weiß ich aber auch. 😉

    supertux schrieb:

    Also, ich weiß nicht, ob du uns auf den Arm nehmen willst, oder echt ernst meinst, einen Webserver in ASM schreiben zu wollen, aber C als overpoweder zu halten 😕

    Ich glaub ich hab mich falsch ausgedrückt. Das wird ein Webserver für einen Mikrocontroller und nicht für einen PC. Hier steht das Programmieren der Hardwarefunktionen im Vordergrund. Deshalb meine Äußerung C sei hier overpowered. Zumindest eignet es sich imho nicht so gut zu lernen wie die Hardware arbeitet.

    0
  • ?

    supertux schrieb:

    super, erfinde doch das Rad noch einmal

    Du hast natürlich recht. Aber ich kann die Freude gut nachvollziehen, daß man mit C auf einmal "on the bare metal" ist:

    Antoras schrieb:

    Noch en besserer Tipp. Warum ne Lib benutzen wenn man es auch selber machen kann?

    Letztlich sicher eine Design-Frage: willst du unabhängig sein: dann bau es selbst. Willst du auf der Arbeit anderer aufbauen: das hat viele Vorteile.

    pointercrash() hat ja darauf hingewiesen, daß es kleine Systeme gibt, die nicht den ganzen Standard umsetzen. Sich nur nichts einreden lassen: es ist dein Programm, und du bestimmst die Ziel-Platformen.

    Antoras schrieb:

    Das liegt daran, dass das dar Mini-Webserver nicht besonders leistungsfähig ist - da halte ich selbst C für overpowered...
    Aber mal gucken wie groß der Aufwand im Endeffekt ist, vllt. lohnt sich es ja doch noch auf C umzusteigen.

    Gute Gelegenheit, zu erforschen, wie gut die beiden zusammenspielen können. Ist ja auch bei Betriebssytemen üblich, so früh als möglich C zu verwenden. Da kann man sicher was lernen.

    0
  • ?

    Antoras schrieb:

    Exceptions lass ich jetzt wahrscheinlich doch komplett wegfallen. Konsolenausgaben reichen für meine Programme bisher vollkommen aus.

    Meinst du zum Debuggen?

    0
  • ?

    Antoras schrieb:

    Ich hab halt einen Spleen und möchte alles selber machen. Dass das aber nicht so ohne weiteres möglich und auch sinnvoll ist weiß ich aber auch. 🙂

    Zunächst einmal hängt alles nur davon ab, was du dir alles zutraust zu programmieren. 🙂

    Später hängt alles davon ab wie schnell du dabei bist. 😞

    Der Satz: mit dem Rad erfinden und so ist auch nur ein Dogma.

    0
  • ?

    Antoras schrieb:

    Ich glaub ich hab mich falsch ausgedrückt. Das wird ein Webserver für einen Mikrocontroller und nicht für einen PC. Hier steht das Programmieren der Hardwarefunktionen im Vordergrund. Deshalb meine Äußerung C sei hier overpowered.

    ein webserver hat ja mit der hardware direkt nix am hut, der muss HTTP-anfragen beantworten und daten versenden. dazwischen hängt noch ein TCP-stack, der auch nicht direkt die hardware ansprechen muss. erst dann kommt ein treiber für's netzwerkinterface, der zwar mit der hardware redet, aber selbst solche treibersachen sind meistens zu 99% in C implementiert.

    auf welchem controller soll dein webserver denn laufen?
    vielleicht wird dich das interessieren: http://www.iosoft.co.uk/tcplean.php
    🙂

    0
  • P

    ;fricky schrieb:

    ... dazwischen hängt noch ein TCP-stack, der auch nicht direkt die hardware ansprechen muss. erst dann kommt ein treiber für's netzwerkinterface, der zwar mit der hardware redet, aber selbst solche treibersachen sind meistens zu 99% in C implementiert.

    auf welchem controller soll dein webserver denn laufen?
    vielleicht wird dich das interessieren: http://www.iosoft.co.uk/tcplean.php
    🙂

    Des kostet ja Geld und nicht mal so wenig 😮 Der uIP von Dunkels soll für die ganz kleinen Kisten recht gut sein, den OpenTCP hab ich nur mal ins Projekt klinken müssen - läuft. Bei Dunkels ist der Webserver auch mit bei.
    Da seh' ich übrigens gar keinen Sinn, auch nur irgendwas in ASM zu machen. Erst wenn es an der Performance hapert, mal die Hardwarezugriffe unter die Lupe nehmen, ob man da was per ASM handoptimieren kann.

    0
  • ?

    pointercrash() schrieb:

    Des kostet ja Geld und nicht mal so wenig

    du kannste es auch umsonst haben (ich darf aber nicht verraten wo, sonst gibts mecker vom mod). ach ja, openTCP hat viele bugs, funktioniert aber erstmal. bei uIP geht der DHCP-client nicht und der ganze code schwer zu portieren. naja, mittlerweile kann man auch kommerzielle tcp-stacks, als source-code, von den herstellern kostenlos downloaden (micrium und so), die darfste nur nicht in eigenen produkten einsetzen, also nur ausprobieren.
    🙂

    0
  • A

    ;fricky schrieb:

    du kannste es auch umsonst haben

    Ich habs schon 😃

    ;fricky schrieb:

    auf welchem controller soll dein webserver denn laufen?

    Auf einem MSC1210.

    µngbd schrieb:

    Meinst du zum Debuggen?

    Ja. Für den Anwender bringen die Konsolenausgaben natürlich nichts. Aber für so en Zeugs wie ein Segmentation Fault benutz ich sowieso gleich den Debugger.

    0
Anmelden zum Antworten