Hypercell ein ] Hypercell aus ] Zeige Navigation ] Verstecke Navigation ]
c++.net  
   

Die mobilen Seiten von c++.net:
https://m.c-plusplus.net

  
C++ Forum :: Linux/Unix ::  non-blocking sockets - HTTP - Client-Seitig  
Gehen Sie zu Seite 1, 2, 3, 4, 5  Weiter
  Zeige alle Beiträge auf einer Seite
Thema geschlossen
Autor Nachricht
Blockade
Unregistrierter




Beitrag Blockade Unregistrierter 21:55:12 15.05.2017   Titel:   non-blocking sockets - HTTP - Client-Seitig            Zitieren

Hallo,

man braucht non-blocking Sockets als Klient für eine HTTP-Antwort, weil man sich nicht auf die Content-Length basieren soll.

Also wenn ich das richtig verstanden habe, muss man sich bei non-blocking Sockets auf Timeouts basieren, stimmt das? Für non-blocking Sockets benutzt man doch idR select(), man kann aber auch recv() benutzen.

Bei recv() bedeutet eine Rückgabe von EAGAIN oder EWOULDBLOCK, dass die Funktion blockieren würde. Ergo entweder man empfängt zu früh und man bekommt EAGAIN, oder man hat tatsächlich alles empfangen und man bekommt EAGAIN. Einen Unterschied zwischen den beiden kann man nicht machen. Und genau das ist mein Problem.

Ich kann mich gerade nicht damit abfinden, dass ich mit Timeouts arbeiten soll, weil das doch erheblich die Performance (so um gefühlt 0,5 - 1 Sekunde) beeinträchtigt.

Bevor ich das ganze Zeug also mit Timeouts implementiere, wollte ich hier mal nachfragen, nur um auf Nummer sicher zu gehen.

Ich dachte eigentlich ständig man kann sehr wohl definieren wann das Lesen bei non-blocking Sockets endet, man kann sich jedoch nicht auf EAGAIN verlassen, weil wie bereits gesagt, empfängt man zu früh bekommt man auch EAGAIN.

Ergo man kann bei non-blocking Sockets nicht definieren wann Anfang und Ende ist, sondern man muss warten. Und wenn man nach dem Warten nichts bekommen hat, so "vermutet" man einfach, dass alles angekommen ist, was dann auch wohl zu 99% immer der Fall sein wird.

Nun angenommen ich schreibe ein Programm, das eine HTTP-Antwort (eine einzige) empfängt, die Daten bearbeitet und das Resultat ausspucht - Programm Ende. Wenn ich das sauber mit Nonblocks machen will, dann habe ich einige Bruchteile einer Sekunde verpatzt, nur weil ich warten musste, bis das Timeout endet.

Soll das so wirklich richtig sein...?
dachschaden
Mitglied

Benutzerprofil
Anmeldungsdatum: 06.12.2014
Beiträge: 1267
Beitrag dachschaden Mitglied 22:35:08 15.05.2017   Titel:   Re: non-blocking sockets - HTTP - Client-Seitig            Zitieren

Blockade schrieb:
man braucht non-blocking Sockets als Klient für eine HTTP-Antwort, weil man sich nicht auf die Content-Length basieren soll.


Ist deine Muttersprache deutsch?

Blockade schrieb:
Also wenn ich das richtig verstanden habe, muss man sich bei non-blocking Sockets auf Timeouts basieren, stimmt das? Für non-blocking Sockets benutzt man doch idR select(), man kann aber auch recv() benutzen.


Ich verdoppel' meine Frage. Hast du dir die Doku zu Sockets durchgelesen? Wenn ja: was genau hast du nicht verstanden?

Wenn du nicht auf den TCP-Timeout warten willst, weil der vom OS vorgeben wird und standardmäßig echt groß ist, dann musst du deinen eigenen Timeout definieren. Welches ENAPI (Event Notification API) du da jetzt verwendest, ist relativ egal, zumindest wenn du nicht ein völlig kaputtes (wie kqueue oder so) verwendest. 'nen Timeout kannst du sowohl bei select wie auch epoll_wait angeben. Das ist aber komplett unabhängig davon, ob dein Socket jetzt blockiert oder nicht!

Warum? Was macht ein blocking Socket bei einem read/recv? Er wartet, bis Daten ankommen. Notfalls bis zum erwähnten TCP-Timeout, bei dem der Leseversuch dann abgebrochen wird. Aber ansonsten hängt er dann da. Und macht nichts.

Was macht ein non-blocking Socket bei einem read/recv? Er wartet nicht. Er kehrt direkt zurück, wenn es keine Daten gibt.

Das erste Szenario ohne ENAPI sorgt dafür, dass du bei Timeouts nix machen kannst. Das zweite Szenario ohne ENAPI sorgt dafür, dass deine CPU-Last hochgeht. Beides ist scheiße. Für beides nimmst du ein ENAPI. Problem gelößt. Da braucht es keine Sonderfälle für das Lesen vom Socket.

Blockade schrieb:
Einen Unterschied zwischen den beiden kann man nicht machen. Und genau das ist mein Problem.


Doch, kannst du. Du redest ja hier von HTTP-Kommunikation. Also machst du bei jedem erfolgreichen Read von Socket eine Syntaxprüfung der Daten. Über ein State-Objekt kannst du bestimmte Daten cachen, die musst du dann nicht wieder und wieder und wieder einlesen, verifizieren usw. Sobald du genug Daten hast, signalisiert du das der Schleife, die die Daten von dem Socket ließt, damit sie aufhört.

An der Syntaxprüfung kommst du nicht vorbei. An der Syntaxprüfung kommst du nicht vorbei! Musst du machen. Also zuerst ENAPI, damit du bei zu langen Durststrecken abbrechen kannst, und dann Syntaxprüfung, damit du weißt, wann die andere Seite tatsächlich nix mehr zu sagen hat. Dann sind auch die "Performancebeeinträchtigungen" weg.

_________________
"'Das habe ich getan' sagt mein Gedächtnis. Das kann ich nicht getan haben - sagt mein Stolz und bleibt unerbittlich. Endlich - gibt das Gedächtnis nach." - Friedrich Nietzsche
The only valid measurement of code quality: WTFs/minute
tntnet
Mitglied

Benutzerprofil
Anmeldungsdatum: 12.06.2005
Beiträge: 1775
Beitrag tntnet Mitglied 19:07:59 18.05.2017   Titel:              Zitieren

Man braucht erst mal keine non blocking Sockets für eine HTTP-Antwort. Es gibt 3 Möglichkeiten, wie das Ende der HTTP-Antwort aussehen kann. Allerdings hängt das weitestgehend vom Server ab, welche er verwendet.

Möglichkeit 1: HTTP/1.0: Im Http-Header steht die Version 1.0. Dann ist die Antwort abgeschlossen, sobald der Server die Verbindung schließt.

Möglichkeit 2: HTTP/1.1 mit Content-Size: Da steht tatsächlich die Anzahl der Bytes vom Body im Header. Dann kannst Du Dich darauf verlassen.

Möglichkeit 3: Chunked-Encoding: Der Server schickt so Blöcke mit einem Längenheader. Ein Block mit der Länge 0 schließt den Body ab.

In keinem Fall brauchst Du not blocking Sockets. Außer Dein Client will auf Timeouts reagieren, also für den Fall vorbereitet sein, dass der Server aus irgendeinen Grund nicht antwortet.

Details über HTTP kannst Du im RFC 2616 nachlesen.

Was willst Du erreichen? Brauchst Du einen Client für ein Projekt oder willst Du nur Netzwerkkommunikation üben? Im ersten Fall solltest Du eine fertige Library nehmen, da ein robuster HTTP-Client alles andere als trivial ist.

Ich empfehle natürlich meine cxxtools. Kannst aber auch libcurl oder Poco oder was auch immer nehmen.

_________________
Webprogrammierung mit C++: http://www.tntnet.org/
dachschaden
Mitglied

Benutzerprofil
Anmeldungsdatum: 06.12.2014
Beiträge: 1267
Beitrag dachschaden Mitglied 20:07:21 18.05.2017   Titel:              Zitieren

tntnet schrieb:
Möglichkeit 2: HTTP/1.1 mit Content-Size: Da steht tatsächlich die Anzahl der Bytes vom Body im Header. Dann kannst Du Dich darauf verlassen.


Nein, kannst du nicht. Sende ich zu wenig Bytes, blockiere ich damit zumindest den Socket Thread. Sende ich zu viele Bytes, kann ich bei mangelhafter Programmierung (die ich durch deine Aussage bereits in meinem Kopf inspiriert sehe) einen Overflow erzeugen.

Unabhängig davon kann es sein, dass du zu wenig Daten bekommst, weil gerade die Verbindung mies ist oder so. Oder der Server unterstützt Pipelining und sendet mehrere Antworten in einem Batch. Deswegen: NICHT verlassen. Nimm die Content-Length (nicht Content-Size!) als Hinweis darauf, wie viele Bytes da ankommen müssen, aber verlasse ich nicht darauf, exakt diese Menge zu bekommen. Sonst kommst du schneller in Teufels Küche, als uns allen lieb ist.

tntnet schrieb:
In keinem Fall brauchst Du not blocking Sockets.


Stimmt so auch nicht ganz. Gerade das select bei Linux ist radioaktive Ebola-Beulenpest in Tüten - da können fehlerhafte OOB-Daten ("Rauschen") die Funktion zurückkehren lassen, aber ein späterer read blockiert dann wieder. Wird so auch von den Kernel-Leuten verteidigt, der Geschwindigkeit wegen. Fix: mach doch einfach deinen Socket non-blocking!

Kommt halt darauf an, wie sehr du um eine kaputte Funktion rumarbeiten willst.

tntnet schrieb:
Außer Dein Client will auf Timeouts reagieren, also für den Fall vorbereitet sein, dass der Server aus irgendeinen Grund nicht antwortet.


Passiert auch so selten, wa?

tntnet schrieb:
Ich empfehle natürlich meine cxxtools. Kannst aber auch libcurl oder Poco oder was auch immer nehmen.


Habe mir mal den Code kurz angeschaut. Verwendet Streams zum Buffern, und die sind natürlich auch privat. Man kann also nicht eigenen Speicher angeben, der nach Möglichkeit noch erweitert werden kann. Relokation ist daher sehr wahrscheinlich auch mit einer Kopie verbunden.

deflate/gzip-Dekodierung wird nicht unterstützt? Denn de-chunken ohne weitere Kopie?

Also so ganz überzeugt bin ich ja nicht ...

_________________
"'Das habe ich getan' sagt mein Gedächtnis. Das kann ich nicht getan haben - sagt mein Stolz und bleibt unerbittlich. Endlich - gibt das Gedächtnis nach." - Friedrich Nietzsche
The only valid measurement of code quality: WTFs/minute


Zuletzt bearbeitet von dachschaden am 21:45:49 18.05.2017, insgesamt 2-mal bearbeitet
tntnet
Mitglied

Benutzerprofil
Anmeldungsdatum: 12.06.2005
Beiträge: 1775
Beitrag tntnet Mitglied 21:10:44 18.05.2017   Titel:              Zitieren

dachschaden schrieb:
deflate/gzip-Dekodierung wird nicht unterstützt? Denn de-chunken ohne weitere Kopie?

Also so ganz überzeugt bin ich ja nicht ...
Ist deine Muttersprache deutsch? :p

Na Dich muss ich ja nicht überzeugen ;) Ich kann damit leben, dass Du mein Code nicht gut findest.

_________________
Webprogrammierung mit C++: http://www.tntnet.org/
dachschaden
Mitglied

Benutzerprofil
Anmeldungsdatum: 06.12.2014
Beiträge: 1267
Beitrag dachschaden Mitglied 21:27:02 18.05.2017   Titel:              Zitieren

tntnet schrieb:
Ist deine Muttersprache deutsch? :p


In der Tat. Die Datenpakete bei "Transfer-Encoding: chunked" werden nun mal "Chunks" genannt, das Entfernen der Chunk-Header ist daher das "de-chunken".

Dass man sich auf irgendwelchen Werten nicht "basieren" sollte, habe ich allerdings noch nie gehört. Der korrekte Ausdruck wäre hier "festlegen" oder "vertrauen".

Und das "denn" leitet eine zweite Frage ein, wenn man die erste Frage negativ beantwortet erwartet.

tntnet schrieb:
Na Dich muss ich ja nicht überzeugen ;) Ich kann damit leben, dass Du mein Code nicht gut findest.


Ja, ein Glück, dass das Runterschrauben der eigenen Ansprüche so leicht geht. Nicht auszudenken, wenn da ordentliche Arbeit hinterstehen würde.

_________________
"'Das habe ich getan' sagt mein Gedächtnis. Das kann ich nicht getan haben - sagt mein Stolz und bleibt unerbittlich. Endlich - gibt das Gedächtnis nach." - Friedrich Nietzsche
The only valid measurement of code quality: WTFs/minute
tntnet
Mitglied

Benutzerprofil
Anmeldungsdatum: 12.06.2005
Beiträge: 1775
Beitrag tntnet Mitglied 17:22:53 19.05.2017   Titel:              Zitieren

tntnet schrieb:
dachschaden schrieb:
deflate/gzip-Dekodierung wird nicht unterstützt? Denn de-chunken ohne weitere Kopie?

Also so ganz überzeugt bin ich ja nicht ...
Ist deine Muttersprache deutsch? :p
Wie wäre es, wenn Du ganze und möglicherweise sogar verständliche Sätze schreiben würdest? "Denn de-chunken ohne weitere Kopie?" verstehe ich als Satz schon gar nicht. Ich weiß echt nicht, was Du damit meinst.

Und wenn "Anspruch runter schrauben" bedeutet, dass ich ausgerechnet Dich nicht überzeugen muss, dann sei es so.

_________________
Webprogrammierung mit C++: http://www.tntnet.org/
dachschaden
Mitglied

Benutzerprofil
Anmeldungsdatum: 06.12.2014
Beiträge: 1267
Beitrag dachschaden Mitglied 20:51:22 19.05.2017   Titel:              Zitieren

tntnet schrieb:
Wie wäre es, wenn Du ganze und möglicherweise sogar verständliche Sätze schreiben würdest?


Du bist der erste, der sich darüber beschwert hat. Ich gehe daher davon aus, dass es deine Deutschkenntnisse sind, die hier mangelhaft sind.

tntnet schrieb:
"Denn de-chunken ohne weitere Kopie?" verstehe ich als Satz schon gar nicht. Ich weiß echt nicht, was Du damit meinst.


Für den Fall, dass es am Deutsch hapert: siehe oben.

Für den Fall, dass dir der Umstand nur nicht bewusst ist: damit meine ich, ob dein Code es schafft, die Chunk-Header zu entfernen, ohne dass du dafür ein neues Feld alloziieren musst?

tntnet schrieb:
Und wenn "Anspruch runter schrauben" bedeutet, dass ich ausgerechnet Dich nicht überzeugen muss, dann sei es so.


Also, was denn jetzt? Wenn man eine eigene Library schreibt, die man dann noch anderen empfiehlt, dann muss diese mehrere objektive Voraussetzungen erfüllen:

1. Die Interfaces müssen offensichtlich sein.
2. Es muss einfacher sein, die APIs richtig zu benutzen, als sie falsch zu benutzen.
3. Die Implementation darf keine Zweifel lassen, dass "ich mach das mal schnell von Hand" keine Vorteile und nur Nachteile hat.
4. Insbesondere muss die Performance besser sein, als man das mal eben selber hingekriegt hätte.

Nummer 1 sehe ich hier nicht gegeben - was alleine der Konstruktor verbricht, habe ich bereits geschrieben.
2 - habe ich nicht geprüft, lasse ich also offen.
3 - auch hier wieder deine Konstruktoren. Wo ich sogar vor zwei Posts geschrieben habe, was man besser hätte machen können.
4 - und auch hier wieder, deine Konstruktoren. Was meinst du, warum ich die als Beispiel genommen habe?

Es gibt nur einen Grund, warum man deinen Code verwenden sollte, und der ist, dein Ego zu befriedigen. Und genau darum geht es hier - dein Ego, welches sich einredet, dass deine Library gut genug ist. Weil du auf halben Weg gesagt hast, dass es schon gut genug sein wird. Warum sonst lässt du diese Eiterbeulen da drin und empfiehlst sie dennoch?

Ich brauche deinen Code nicht. Dein Code ist mir komplett egal. Ich habe meinen eigenen, den ich aber nicht Leuten empfehle. Aber wenn du anfängst, anderen deinen Code zu empfehlen, und dann sind dieses Eiterbeulen da drin, dann hörst du den Donner von mir. Vor allem dann, wenn meine Kritik mit "es muss dir aber nicht reichen!1!!" beantwortet wird.

"Streamobjekte reiche ich derzeit nicht durch, könnte ich beizeiten mal einfügen" - bamm, bin ich schachmatt.
"Speicherallokationen in C++ sind scheiße, wenn man was ordentliches haben will, ist das halbes C und man wird dafür ausgebuht. Deswegen geht Relokation nur mit Kopie" - kann ich verstehen. Sogar gut. Hätte ich auch keine Munition gegen.
"Ich könnte den Speicher, in dem der Content drin ist, behalten und Chunk-Header einfach mit memmove überschreiben" - genau das mache ich auch. Keine weitere Kopie. Kann wahrscheinlich direkt im CPU-Cache gemacht werden und sollte rasendschnell gehen.

Stattdessen bekomme ich die Antwort, dass du dir "ist schon gut genug" herbeihalluzinierst. Aber dann anderen es empfehlen. Warum ich darauf so rumreite? Weil Anfänger keinen Plan davon haben, wie gut Code ist. Passiv anbieten - kann man machen. Aktiv empfehlen - nur dann, wenn die obigen Kriterien erfüllt sind.

Niemand geht los, um langsame Software zu schreiben. Aber auf dem Weg brechen viele Leute ab, weil ihnen gesagt wird, die Dinge seien "schnell genug". Oder weil sie es sich selbst sagen.

_________________
"'Das habe ich getan' sagt mein Gedächtnis. Das kann ich nicht getan haben - sagt mein Stolz und bleibt unerbittlich. Endlich - gibt das Gedächtnis nach." - Friedrich Nietzsche
The only valid measurement of code quality: WTFs/minute
tntnet
Mitglied

Benutzerprofil
Anmeldungsdatum: 12.06.2005
Beiträge: 1775
Beitrag tntnet Mitglied 00:17:54 20.05.2017   Titel:              Zitieren

dachschaden schrieb:

tntnet schrieb:
"Denn de-chunken ohne weitere Kopie?" verstehe ich als Satz schon gar nicht. Ich weiß echt nicht, was Du damit meinst.


Für den Fall, dass es am Deutsch hapert: siehe oben.

Für den Fall, dass dir der Umstand nur nicht bewusst ist: damit meine ich, ob dein Code es schafft, die Chunk-Header zu entfernen, ohne dass du dafür ein neues Feld alloziieren musst?
Also gut. Ein deutscher Satz besteht in der Regel aus einem Subjekt, Prädikat und Objekt.

"Denn de-chunken ohne weitere Kopie?"

Also "de-chunken" ist ein Verb. Das ist wohl das Prädikat. "ohne weitere Kopie" sieht aus, wie ein Objekt. Ach ich verstehe diesen Satz einfach nicht. Der ist mir wohl zu schwer. Na dann entschuldige ich mich für meine mangelnden Deutschkenntnisse. Und dafür, dass ich meine Library empfohlen habe.

C++:
   cxxtools::http::Client client("www.tntnet.org", 80);
   std::string indexPage = client.get("/");
Ich habe mir Mühe gegeben, das Interface so einfach wie möglich zu gestalten. Ich weiß nicht, wie ich das vereinfachen könnte. Da fehlen mir wohl die Deutschkenntnisse.

Ich danke für Deine ausführliche Kritik an meinem Code. Ich werde es in meinen zukünftigen Projekten beachten. Insbesondere werde ich zukünftig nicht mehr einfach so unbedacht de-chunken.

_________________
Webprogrammierung mit C++: http://www.tntnet.org/
dachschaden
Mitglied

Benutzerprofil
Anmeldungsdatum: 06.12.2014
Beiträge: 1267
Beitrag dachschaden Mitglied 01:11:50 20.05.2017   Titel:              Zitieren

tntnet schrieb:
Also gut. Ein deutscher Satz besteht in der Regel aus einem Subjekt, Prädikat und Objekt.


Ja, genau. Jetzt misch noch Haupt- und Nebensätze in einen Pott. Ist ja nicht so, dass sie einem im Deutschunterricht jede Woche eintrichtern, dass Nebensätze ohne auf sie referenzierende Hauptsätze nicht alleinstehen können. Dass du dies nicht weißt, ist ja nicht mal mit Abendschuldeutsch zu erklären; das muss komplette Arbeitsverweigerung gewesen sein.

Also, jetzt mal Deutsch für Hauptschüler: Der Hauptsatz ist hier:

"deflate/gzip-Dekodierung wird nicht unterstützt?"

, welcher außerdem eine Frage ist. Präsenz Passiv, "unterstützen" ist das Verb hier.

Der Nebensatz ist:

"Denn de-chunken ohne weitere Kopie?"

Würde man ihn in seinen eigenen Hauptsatz umwandeln, wäre dieser:

"Wird denn de-chunken ohne weitere Kopie unterstützt?"

Wenn man kein Sprachgefühl besitzt, dann stört es einen natürlich nicht, dass das gleiche Verb in zwei aufeinanderfolgenden Sätzen verwendet wird, ohne dass hierbei eine rhetorische Wirkung beabsichtigt ist:

"deflate/gzip-Dekodierung wird nicht unterstützt? Wird denn de-chunken ohne weitere Kopie unterstützt?"

Und ich verstehe auch, dass es eine Doktorarbeit in fortgeschrittener Germanistik benötigt, um zu begreifen, dass man Konjugationen im Deutschen weglassen kann, solange die Relation von Haupt- und Nebensatz deutlich ist. Mit einer Konjugation wäre diese:

"deflate/gzip-Dekodierung wird nicht unterstützt, genauso wie de-chunken ohne weitere Kopie?"

Aber anscheinend kann bei dir der Fokus des Hauptsatzes nicht erhalten werden, wenn es einen Punkt zwischen beiden Sätzen gibt. Aber selbst Abendschulverweigerer sollten erkennen, dass Haupt- und Nebensätze getrennt sein können, solange nur der Nebensatz auf den Hauptsatz referenziert:

"deflate/gzip-Dekodierung wird nicht unterstützt? Genauso wie de-chunken ohne weitere Kopie?"

Die besondere Ironie ist, dass ich des öfteren Rechtsschreibfehler tippe. Auf diesen hättest du, zwar ein wenig kleinlich, aber wenigstens berechtigt rumreiten können. Aber wer nie ein ordentliches Sprachgefühl entwickelt hat, der würde diese wahrscheinlich auch gar nicht erkennen.

tntnet schrieb:

C++:
   cxxtools::http::Client client("www.tntnet.org", 80);
   std::string indexPage = client.get("/");



Wo gebe ich den Buffer für das HTTP-Header-Array? Werden die Header vordefiniert? Kann ich zwei Arrays angeben, einmal mit den Namen, dann mit den Werten, die beim HTTP-Request gesendet werden sollen? Habe ich präzise Kontrolle darüber, in welcher Reihenfolge welche Header in den Socket geschrieben werden (wichtig für Fingerprints von Browsern)?

Was ist, wenn ich mich mit einem Host verbinden will, der mehrere virtuelle Hosts beherbergt? Wo ist das obligatorische Statusobjekt, in dem die Daten des Sockets reingeschrieben werden? Kann ich eine maximale Responsegröße anlegen? Warum muss ich Domain und Port beim Konstruktor angeben? Was, wenn das Objekt nicht angelegt werden konnte, weil z.B. gerade keine Verbindung besteht? Exceptions? Ernsthaft? Also Objekt auf dem Heap erstellen, Stack rewinden, Objekt auflösen?

Was ist mit mehreren Namenstabellen? Wenn ich jetzt zum Beispiel will, dass mehrere Clients sich die gleichen Auflösungen teilen? Wenn das OS intelligent ist, wird gecacht, aber getaddrinfo ist sehr kaputt (benötigt freeaddrinfo ... ernsthaft jetzt?).

Wie steht es mit deinem de-gzipper aus? Werden Daten größer als 4 GiB unterstützt?

Was ist mit dynamischen HTTP-Header-Daten? Sagen wir mal, wenn du Content-Disposition[c] baust. Oder [c]Content-Length. Heap, wahrscheinlich, oder? Ohne Möglichkeit, meinen eigenen Buffer zwischenzuklemmen?

Was, wenn ich über einen transparenten Proxy reingehen will/muss? Kann ich ein Protokoll angeben, über das versucht wird, mit dem Proxy zu reden? Kann ich auch meinen eigenen Socket verwenden lassen? Wie steht's mit Pipelining? Wie oft verwendest du komplett unnötig new und delete?

Was ist, wenn du Daten (Plural von Datum) schreiben musst? strftime oder eine Funktion, die sie abkapselt?

tntnet schrieb:
Ich habe mir Mühe gegeben, das Interface so einfach wie möglich zu gestalten.


Du hast die Funktionalität stark eingeschränkt, um das Interface einfach halten zu können, ohne viel Arbeit reinzustecken. Wenn du auch nur bei 50% meiner Fragen sagen kannst, dass das von dir exportierte Interface diese Sachen einfach und intuitiv erlaubt, dann fresse ich einen Besen.

tntnet schrieb:
Ich weiß nicht, wie ich das vereinfachen könnte. Da fehlen mir wohl die Deutschkenntnisse.


Nee, die fehlen dir noch dazu.

_________________
"'Das habe ich getan' sagt mein Gedächtnis. Das kann ich nicht getan haben - sagt mein Stolz und bleibt unerbittlich. Endlich - gibt das Gedächtnis nach." - Friedrich Nietzsche
The only valid measurement of code quality: WTFs/minute
C++ Forum :: Linux/Unix ::  non-blocking sockets - HTTP - Client-Seitig  
Gehen Sie zu Seite 1, 2, 3, 4, 5  Weiter
Thema geschlossen

Zeige alle Beiträge auf einer Seite




Nächstes Thema anzeigen
Vorheriges Thema anzeigen
Sie können Beiträge in dieses Forum schreiben.
Sie können auf Beiträge in diesem Forum antworten.
Sie können Ihre Beiträge in diesem Forum nicht bearbeiten.
Sie können Ihre Beiträge in diesem Forum nicht löschen.
Sie können an Umfragen in diesem Forum nicht mitmachen.

Powered by phpBB © 2001, 2002 phpBB Group :: FI Theme

c++.net ist Teilnehmer des Partnerprogramms von Amazon Europe S.à.r.l. und Partner des Werbeprogramms, das zur Bereitstellung eines Mediums für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu amazon.de Werbekostenerstattung verdient werden kann.

Die Vervielfältigung der auf den Seiten www.c-plusplus.de, www.c-plusplus.info und www.c-plusplus.net enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt (vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden. Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.