Die Sortierung von Dictionaries ist nicht definiert.
Falls es auf eine Sortierung der Schlüssel ankommt, nimm lieber das hier:
https://docs.python.org/3/library/collections.html#collections.OrderedDict
Politiker, die sich gegenseitig aufm Klo verprügeln:
https://www.welt.de/politik/deutschland/article182740182/Sachsen-Anhalt-AfD-Abgeordneter-soll-Parteifreund-auf-Toilette-verpruegelt-haben.html
Mit einem Regenbogenarmband bringe ich viel mehr ein Regenbogenarmband in Verbindung, als an irgendwelche sexuellen Präferenzen zu denken.
Mir persönlich würde das vermutlich überhaupt nicht auffallen. :)
Ist doch aber auch egal, was andere denken, oder? Trag einfach das, was du willst!
Ein Mix aus Bloatware, Vendo-Lock-In und geschicktem Marketing. :)
Etwas unkonventionell, aber wenn deine Werte aus einer vertrauenswürdigen Quelle stammen, dann vielleicht so:
l = ["a = 4.12" , "b = 13.2" , "c = 4.25"]
exec(';'.join(l))
print(a) # 4.12
print(b) # 13.2
print(c) # 4.25
Der Vorteil ist, dass damit automatisch Variablen "erzeugt" werden, welche die passenden Werte haben und dass die Lösung nur eine viertel Zeile lang ist.
Der Nachteil sind sicherheitstechnische Bedenken, falls deine Werte live irgendwo aus dem Internet von einer nicht-vertrauenswürdigen Quelle geladen werden.
Ansonsten haben dir die anderen ja schon recht schlanke funktionale Lösungen gezeigt, also such dir eine aus. ;)
Mehrere gaaaanz kurze Anmerkungen, nach Wichtigkeit sortiert:
So, ich denke, das wars erst mal. :)
Ähm, ja! ^^
"Den" DLL-Injection Code, von dem dein Snippet stammt, kenne ich zwar nicht persönlich, aber auf den ersten Blick kann ich sagen, dass man das auch so machen kann, wenn man denn lustig ist.
(Da fehlt aber noch der größte Teil der Implementierung! Du hast nur den Teil aus der Header-Datei gepostet!)
Außerdem würde ich die Prototypen nicht hinter einem using verstecken, sondern lieber mit Funktionszeigern bzw. -referenzen arbeiten, oder vorzugsweise sogar mit opaquen Templates, aber das bleibt letztendlich dir überlassen.
Wenn dir klar ist, wie DLL-Injection funktioniert, warum fragst du denn dann hier, und saugst dir nicht irgendeine beliebige Implementierung aus den Fingern? Das sind doch nur ein paar Zeilen Code!
Das Ganze klingt, als würdest du nach dem "Code" fragen, mit dem man die ersten Primzahlen bis 1000 finden kann ... das wäre auch a) ein sehr simples Problem, und b) gibt es dafür mehr oder weniger gut geeignete Ansätze.
Wenn du weißt, was DLL-Injection ist, und wie sie funktioniert, warum musst du dann hier nachfragen? Ich verstehe jetzt dein Problem nicht so richtig. :)
Schmeiß den Code komplett weg, so wie er ist, und überlege dir ganz langsam und Schritt für Schritt einen neuen. Im Moment enthält der Code so unendlich viele Fehler, dass du damit kein zufriedenstellendes Ergebnis erzielen wirst.
Allein schon die Bedingung ...
str[i] != ' ' || str[i] != '\0'
... ist IMMER wahr und <stdio.h> kommt von C, die du in C++ üblicherweise mit <cstdio> einbindest.
Aber egal ... lerne lieber erst mal ordentlich die Grundlagen von C++, bevor du dich so weit an eigene Experimente wagst! :)
Alle Sprachen, die eine Form von JIT-Compiler nutzen, sind zwangsweise "unsicher" in dem Sinne, dass bestimmte Speicherseiten nicht nur gelesen und geschrieben werden können, wie z. B. bei einem C++ Programm, sondern auch als ausführbar markiert sind.
Das hat zur Folge, dass eine Lücke, die ein Schreiben des Speichers erlaubt, unter Java VIEL gefährlicher ist, als bei einem normalen Programm.
Allerdings muss man fairerweise sagen, dass Java sich große Mühe dabei gibt, Anwendungen nicht wild im Speicher rum schreiben zu lassen. Es lässt sich zwar nicht wirklich verhindern, und ist - wenn man weiß wie es geht - auch weiterhin machbar, aber zusätzlich benötigt man immer noch eine weitere Sicherheitslücke, um die mit Shellcode beschriebenen Speicherbereiche auch auszuführen.
Bei C++ liegen die Probleme an anderer Stelle: Trotz moderner Techniken wie Smartpointern ist es für mäßig fähige Entwickler vermutlich einfacher, unbeabsichtigt Speicherlecks und dergleichen in Programme einzubauen. Da hier allerdings i. d. R. Speicherseiten für Daten von Speicherseiten für Code getrennt sind, und es normalerweise überhaupt nicht vorgesehen ist, irgendwelche Instruktionen dynamisch anzupassen, stellen Lücken in diesem Bereich bei JIT-kompilierten Sprachen, eine wesentlich größere Gefahr dar.
Und das ist der Hauptgrund, warum Java-Lücken oft so gravierend ausfallen! Aber pauschal Java als "unsicher" zu bezeichnen, geht m. M. n. etwas zu weit ... soooo schlimm ist die Situation jetzt auch wieder nicht. Vor allem, seitdem es keine / kaum noch Applets gibt. :)
Alles was du zum Thema "DoS" in Kombination mit "cmd.exe" liest, ist Schwachsinn und stammt aus der Feder von Kindern, für Kinder.
Das hat früher mal funktioniert, aber zu dieser Zeit warst du vermutlich noch nicht mal geboren.
DoS oder auch DDoS sind sowieso Dinge, die ausschließlich von sehr "schlichten Geistern" eingesetzt werden, die einfach nichts können und nicht wissen, wie man es richtig macht. Das ist die primitivste und plumpeste Methode, Server in die Knie zu zwingen. Wer etwas auf sich hält wird so etwas nicht einsetzen, bzw. auch nicht Dritten gegenüber erwähnen.
Wer wirklich gut ist, kann sich selbst ein Skript / einen Shellcode / ein Wasauchimmer bauen, und dann mit einem einzigen Request einen Server abschießen, wird das aber NICHT tun, sondern den Seitenbetreiber freundlich darauf hinweisen.
Nur dumme Kinder greifen Webseiten an. Und die Dümmsten unter den dummen Kindern nutzen eine Art von DoS. Jemand der hingegen ethisch nicht komplett abgeglitten ist, wird sich solche peinlichen Aktionen verkneifen.
Aber um deine Frage zu beantworten: Eine "herkömmliche" PHP-Installation kannst du - je nach Caching und Optimierungen - mit 100 bis 10000 parallelen Requests "abschießen", sofern es sich um einen einzigen Server handelt. Da allerdings viele Provider wissen, wie man Loadbalancer einsetzt und auch schon mal was von DoS gehört haben, kannst du bei vielen damit gar nichts erreichen.
Dann müsste man wieder auf selbst gefundene Lücken und selbst gebaute Exploits zurück greifen, aber das ist - wie gesagt - nichts für kleine Kinder.
Fazit: Vergiss es! ;)
Die Antworten zum Compiler und Interpreter von den anderen sind ziemlich gut, aber ich möchte nochmal auf einen Pseudo-Vorteil bzw. gravierenden Nachteil von Assembler hinweisen:
Auf aktuellen Desktop Systemen (x86, x64 und teilweise auch ARM) sollte rein theoretisch ein Stück Code, geschrieben in Assembler, am schnellsten laufen, aaaaber moderne CPUs sind ultra-komplexe Dinger, es gibt unzählige (Hardware- und / oder Microcode-) Bugs, man muss hunderte (!) Seiten von Errata lesen und ständig das Pipelining im Hinterkopf behalten, um WIRKLICH effizienten Code schreiben zu können.
Keine Frage, das ist möglich, aber der Aufwand übersteigt fast immer bei weitem den Nutzen, im Sinne von Entwicklungszeit.
Früher in den 90ern war allen Entwicklern bekannt, dass "inc ax" langsamer ist als "add ax, 1", und deshalb wurde die zweite Methode eingesetzt, auch wenn das den Code etwas mehr aufbläht.
Heutzutage gibt es ähnliche Dinge zu beachten, nur hundert mal komplexer und auch quantitativ (fast) unüberschaubar.
Deshalb eignet sich Assembler heutzutage meistens nur noch dazu, fertigen Code zu analysieren / reversen, in einer kompilierten Sprache Inline-Assembler mit nur einer Hand voll spezieller Instruktionen zu nutzen, oder auf einem Mikrocontroller zu entwickeln, wo die Zahl der möglichen Instruktionen und die Gesamtkomplexität noch recht einfach überschaubar ist.
Nichtsdestortrotz macht Assembler großen Spaß und man kann damit wirklich überdurchschnittlich kleine und flinke Programme schreiben, aaaaber das frisst wie gesagt a) verdammt viel Zeit und b) muss man sich da gerade bei modernen CPUs wirklich richtig gut auskennen, um eine Konkurrenz zu akutellen Compilern sein zu können.
Du warst angeblich mal in der "Hackerszene" aktiv, und musst jetzt hier auf GF fragen, wo die sich heutzutage rumtreiben?!?! Soll das ein Witz sein?
Das klingt eher nach einem Skriptkiddie, welches nie so richtig gut war, irgendwann das Interesse verloren hat, und jetzt doch noch mal ran will.
Aber ich will mal nicht so sein ...
QOKgOtbd6njqEQDkT5QkYY+vMvu3wKVr15J7... wenn du wirklich jemals über Skriptkiddie-Niveau hinaus gekommen sein solltest, dann wirst du damit ans Ziel finden. (Protipp: Nein, das ist natürlich nicht nur Base64. Von einem richtigen Hacker darf man wohl etwas mehr erwarten, oder?)
Falls du damit nicht klar kommst: Skript-Kiddie! ;)