suche gute Socket Library
-
client manager schrieb:
Wo sind RawSockets?
*lol*
Naja gut, so weit runter muss man dann auch nicht gehen können, wenns ja vor allem darum geht dem User das zu verschleiern. Aber ich stehe halt persönlich auf Libraries bei denen man zwar mit drei Methodenaufrufen alles am Laufen hat aber im Notfall nahezu alles durch eigene Module austauschen kann um an die untersten Regionen auch zu kommen
MfG SideWinder
-
man kann ja erstmal nen guten wrapper bauen und darum baut man dann im zweiten schritt das high-level zeug
-
kingruedi schrieb:
Stabile und funktionierende Libraries gibt es ja zu hauf. Siehe ACE oder Netxx. !flame!Und die sind immer noch besser als der J*v*/*N*T Müll
!flame!Genau, und weil es für C++ so viele tolle Libs gibt, ist es auch immer meine erste Wahl für die Anwendungsprogrammierung.
ACE ist kostenpflichtig, oder? boost ist seit ungefähr 2-3 Jahren alpha und damit IMHO tot.
-
communityprojekt schrieb:
man kann ja erstmal nen guten wrapper bauen und darum baut man dann im zweiten schritt das high-level zeug
Ja, das ist die richtige Vorgehensweise. Siehe dazu auch (wenn es euch nicht zu sehr kränkt) das Design in der .Net Klassenbibliothek. Es gibt einen Raw-Socket-Wrapper, den man benutzen kann, wenn man auf Schmerzen steht. Dann gibt es einen TcpClient/TcpListener, der dieses Ding wrappt und Stream I/O bereitstellt. Außerdem sind hier noch ein paar Sachen wie Protokoll-Auswahl vorweg genommen (es gibt auch entsprechend nen UdpClient). Und natürlich ist hier ne Unterscheidung zwischen Server-/Client Sockets, die bei Raw Sockets bekanntlich nicht so gegeben ist.
Wiederum darauf aufbauend findet man dann Dinge wie Remoting.
Der einzige echte Designfehler ist, dass man jeweils an die eingekapselten Objekte ran kommt. Man kann von nen Remoting-Sink den TcpClient getten und von den den Raw-Socket-Wrapper. Dies hätte ich nicht zugelassen.
-
ACE ist glaubt ich nicht kostenpflichtig, aber es gibt keine kostenlose Dokumentation. Die Doku muß man sich in Form eines Buches kaufen. Das Geld wird also mit dem Buch gemacht und man kann die ACE-Entwickler als Berater einkaufen. Insofern wird ACE auch nicht einfacher benutzbar gemacht werden.
Die CommonC++ Lib von GNU hat doch so viele Socketklassen. Ich bin leider keiner der Sockets benötigt und hab es entsprechend noch nicht getestet. Der Nachteil an CommonC++ ist die GPL Lizenz.
-
Der Nachteil an CommonC++ ist die GPL Lizenz.
Der zweite Nachteil ist der, das es von Noobs programmiert worden ist.
-
Irgendwie schon nen Armutszeugnis für C++. Wenn ich mir da die .NET Socket Lib ansehe
-
wxWidgets
-
Entwickler78 schrieb:
Irgendwie schon nen Armutszeugnis für C++. Wenn ich mir da die .NET Socket Lib ansehe
Willst du es nicht verstehen ? C++ ist eine standartisierte Sprache. .Net ist M$-Scheisse. Eine Standartisierte C++ Socket lib müsste auf ALLEN Plattformen gleich funktionieren. Versuche einmal etwas zu standartisieren das auch auf Windows funktioniert. Bei der nächsten Win-Version beginnst du wieder von vorne. Da liegt das Problem.
Kurt
-
Bei der nächsten Win-Version beginnst du wieder von vorne.
??
-
Zuk! Ich glaub du verstehst nicht.
.NET ist sehr wohl standardisiert bei der ECMA und somit keine M$-Sch***. Ich weiß jetzt nicht ob die .NET-Sockets in der ECMA drin sind, aber bevor man über MS herzieht, nur weil es MS ist, sollte man sich über .NET informieren.Außerdem ist .NET hier nicht das Thema.
-
C++ ist eine standartisierte Sprache. .Net ist M$-Scheisse.
Beides ist standardisiert, wo genau ist da jetzt dann der Unterschied?
Versuche einmal etwas zu standartisieren
Mit 'd'...
das auch auf Windows funktioniert
??
Da liegt das Problem.
Ganz bestimmt
MfG SideWinder
-
Entwickler78 schrieb:
Irgendwie schon nen Armutszeugnis für C++. Wenn ich mir da die .NET Socket Lib ansehe
C++ kann dafür nichts. Es gibt schliesslich Socketlibs in Qt, wxWidgets, MFC, ACE, CommonC++ usw. Also sogar mehr als es für .NET und Java gibt. Das spricht eher für die Verbreitung von C++. Nur halt keine Lib die ich mir mal so ebend einzeln als eigenes Modul ziehen kann oder die in der Std-Lib dabei ist.
-
ZuK schrieb:
Willst du es nicht verstehen ? C++ ist eine standartisierte Sprache.
Genau, mit standardisierter Bibliothek. Hier könnte man ansetzen. Die Bibliothek ist aber darauf ausgelegt, auch auf einem Toaster zu laufen. Du kannst aber leider nicht ohne weiteres für alle Toaster einen einheitlichen Zugriff auf das Dateisystem oder auf ein Netzwerk bereitstellen. Deshalb gibt's selbst elementare Dinge nicht. Je mehr theoretisch plattformunabhängiger C++ ist, desto weniger plattformunabhängig ist es in der Praxis. Denn in der Theorie sage ich "ich bau keine Sockets ein, dann ist es unabhängiger". In der Praxis brauche ich aber Sockets.
C++ ist eine standartisierte Sprache. .Net ist M$-Scheisse.
Danke, dass du mich erleuchtet hast. Jetzt ist mir der Unterschied klar.
-
ACE ist kostenlos und es gibt auch kostenlose Dokumentationen.
Ansonsten gibt es eine Menge Socket Libraries, google einfach mal nach socket++. Der Punkt bei C++-Socket-Libraries ist einfach nur die Eleganz und nicht die Existenz.
Boost ist alpha? Ne, du meinst Boost-Socket :p Aber einige Software nutzt das ja bereits im normalen Betrieb. Siehe zB. monotone
-
SideWinder schrieb:
Beides ist standardisiert, wo genau ist da jetzt dann der Unterschied?
Ist es das ? Gebe zu hätte mich informieren sollen.
Versuche einmal etwas zu standartisieren das auch auf Windows funktioniert
Meine Windows Programme funktionieren regelmässig nicht mehr wenn ich auf eine neue Windows-Version umsteige. Ich habe einfach keine Lust mehr jedes mal von vorne zu beginnen.
Artchi schrieb:
Außerdem ist .NET hier nicht das Thema.
Hatte mich auf Entwickler78's Aussage bezogen
K
-
Meine Windows Programme funktionieren regelmässig nicht mehr wenn ich auf eine neue Windows-Version umsteige. Ich habe einfach keine Lust mehr jedes mal von vorne zu beginnen.
kann der fehler auch bei dir liegen?
-
Wieso wurde mein Posting gelöscht? Hier wird wohl übelst zensiert.
-
Natürlich.
Kurt
Edit: Diese Antwort bezog sich natürlich auf die Frage ob der Fehler auch an mir liegen könnte.
-
wenn schon eine library, dann würde ich eine nehmen, die die socket-funktionalität erweitert, z.b. ein 'connect' bei dem man den timeout selber bestimmen kann u.ä. dinge die sonst nur mit tricks möglich sind.