boost? Nur ein STL wrapper? Wer hat es wann wo und warum entwickelt?



  • Wenn er kein kommerz will, soll er halt einfach die nicht kommerzielle Version der Qt nehmen. Wo ist da das Problem?



  • Weil er vielleicht auch kein GPL mag?



  • Dann soll er halt die Qt unter der QPL nehmen. Mein Gott, wenn er unbedingt seinen Code verfügbar machen will, soll er wenigstens dafür zahlen...



  • für socket braucht man eigentlich keinen wrapper. um die unterschiede unix/windoofs auszugleichen reichen ein paar wenige #ifdefs



  • net schrieb:

    für socket braucht man eigentlich keinen wrapper. um die unterschiede unix/windoofs auszugleichen reichen ein paar wenige #ifdefs

    Naja, socketprogrammierung unter Linux, damit kenn ihc mich aus.

    Aber ich habe nunmal kein plan von WinSock und will mich damit auch nicht beschäftigen *g*.

    Portabelität ist mir trotzdem noch wichtig.



  • net schrieb:

    für socket braucht man eigentlich keinen wrapper. um die unterschiede unix/windoofs auszugleichen reichen ein paar wenige #ifdefs

    erfordert mehr wissen und ist umständlicher.

    Und gerade wenn man schnelles Async I/O haben will, sind die Unterschiede schon ziemlich groß.



  • kingruedi schrieb:

    Und gerade wenn man schnelles Async I/O haben will, sind die Unterschiede schon ziemlich groß.

    wenn du damit diese WSAxxx-funktionen unter win meinst - dafür gibts (glaube ich) keinen ersatz unter unixen und deren clones...



  • WSAxxx? Keine Ahnung wie man Async unter Windows macht. Aber natürliche bietet Unix Async I/O. Aber auch effizientes I/O Multiplexing ist ja portabel kaum möglich.



  • kingruedi schrieb:

    Aber natürliche bietet Unix Async I/O

    meinst du jetzt nonblocking sockets, select, etc. oder was spezielles? falls ersteres: das geht auch unter win. m$ hat ja mehr oder weniger die berkeley sockets nachgebaut.



  • er meint die aio_ funktionen



  • net schrieb:

    kingruedi schrieb:

    Aber natürliche bietet Unix Async I/O

    meinst du jetzt nonblocking sockets, select, etc. oder was spezielles? falls ersteres: das geht auch unter win. m$ hat ja mehr oder weniger die berkeley sockets nachgebaut.

    select ist wie wir ja alle wissen eher ein krüppel-Funktion, die nicht gut skaliert. Daher bieten die Betriebssysteme unterschiedliche Ansätze Nonblocking oder Async I/O zu implementieren.

    Leider sind die sehr verschieden, unter FreeBSD (und OS X, glaube auch andere BSDs) ist es zB kqueue, unter Linux 2.4 ist es SIGIO, unter Linux 2.6 epoll etc. Wie es bei Windows heißt weiß ich nicht.


Anmelden zum Antworten