Schnelles C++
-
Citizen42 schrieb:
Ich meine, C++11 ist der aktuelle Standard und der nächste steht schon vor der Tür..
Ich finde das toll, dass das so an alle vorbeigeht: C++14 ist schon seit 4 Monaten draußen!
-
Ups echt? Ich dachte irgend ein Draft wäre fertig und muss noch durchgewunken werden.
-
Jup, echt: http://en.wikipedia.org/wiki/C%2B%2B14
-
Jut, dann ab heute -std=c++14 denn das ist ja dann das neue Standard-C++. Sind ja zum Glück nicht so viele Änderungen wie bei C++11.
-
Nathan schrieb:
Jup, echt: http://en.wikipedia.org/wiki/C%2B%2B14
Ich denke der isocpp-Artikel passt hier besser.
Sind ja zum Glück nicht so viele Änderungen wie bei C++11.
Zum Glück?
-
Glück für das wenige Dazulernen von 11 auf 14. Die Änderungen vom alten 98 zu 11 waren ja wohl doch schon viel, aber auch gut, so wie ich das gelesen habe. Ich kenne ja C++98 gar nicht.
Nun haben wir bald 2015 und dann zwei Jahre Zeit bist es wieder was Neues gibt. Bis auf Mircosoft sind ja wohl auch die Features immer recht schnell in den Compilern verfügbar.
-
volkard schrieb:
Speicher sparen, den kein anderer braucht, ist blöd. Embedded system nehme ich an und singlethreaded. Dann kannste die Garantie einfach benutzen und weiterreichen. Das Wachsen des Speichers, was ich auf PCs bevorzugen würde, könnte dümmstenfalls doppelt so viel Speicher fressen wie das feste Vorallokieren.
Naja, ich hab mir schon was dabei überlegt.
Der Programmierer soll zum Beispiel bestimmen können, ob die Funktion jetzt einen Speicher, den er angegeben hat, verwenden soll - in einer Streamer-Struktur, die ich ursprünglich mal für einen IRC-Bot geschrieben habe, aber die hat sich als so vielseitig herausgestellt, dass ich die für das Verzeichnisse-durchlaufen einfach "missbraucht" habe - oder ob die Funktion sich darum kümmert. Der Vorteil ist: die Funktion reserviert den Speicher neu, behält aber originale Daten bei und schaut nur zu, dass am Ende die Daten der rekursiven Funktion geschrieben werden. Der Speicher wird dann nicht freigegeben, weil darum sich der Programmierer kümmern soll, und kann den erweiterten Speicher dann auch für andere Sachen nutzen.
Und wenn er keinen Bock hat, sich um die Speicherverwaltung zu kümmern, gibt er beim Initialcall einfach 0 an, und die Routine kümmert sich selbst darum. Dann gibt die aber den Speicher am Ende wieder frei - der Programmierer wollte ja nicht.Es ist erstaunlich, wie oft man einfach nur einen großen Speicherbereich braucht, und ein bisschen Intelligenz innerhalb seiner Routinen, um sich einen Haufen
malloc/realloc/free-Calls zu spraren. Den gleichen Speicherbereich, den du zum Buffern einer HTTP-Antwort verwendest, kannst du später dazu verwenden, zu ge-entzippen. Und dann später, um wieder in einem Verzeichnis suchen zu lassen und eine Anfrage zu generieren. Wenn man dann noch ein paar PP-Makros definiert, die quasi die Schnittstelle dafür bieten, muss du nur nur 5 weitere Zeilen in deine Funktion unterbringen, und kannst den Durchsatz um einiges erhöhen (waren damals von 50.xxx Cycles auf 10.xxx Cycles runter). Einen HTTP-Parser habe ich so (und ein paar zusätzlichen Tricks) auch von 60.xxx Cycles auf <2.000 Cycles bekommen.
-
Hört sich alles nicht praxisrelevant an. Ein HTTP Parser wird im HTTP Server nicht das Bottleneck sein. Schön, wenn es dir Spass macht, sowas zu optimieren, aber wirklich bringen tut es wohl nichts und führt sehr wahrscheinlich einfach nur zu schlechter wartbarem Code.
-
Ich dachte immer ein Client parst HTML und weniger der Server, der soll doch nur nach Anfrage abliefern, oder nicht? Es sein denn, es sind Serverseitige-Script-Sprachen mit im Spiel, die werden ja vom Server abgearbeitet.
-
Naja, und den ganzen STL Datenstrukturen kann man einen Allokator mitgeben. Ob der jede Speicheranforderung mit einem new Speicher holt oder am Anfang einfach mal 100GB allokiert und diese dann schrittweise rausgibt bleibt dem Entwickler überlassen...
-
Citizen42 schrieb:
Ich dachte immer ein Client parst HTML und weniger der Server
Die Rede war ja auch von HTTP, nicht HTML.
-
*kopfklatsch Sorry, mein Fehler.
-
Arcoth schrieb:
Nathan schrieb:
Jup, echt: http://en.wikipedia.org/wiki/C%2B%2B14
Ich denke der isocpp-Artikel passt hier besser.
Der listet aber nicht so schön alle Änderungen auf.
