Nein, es funktioniert nicht genauso!

float ist ein Datentyp der seine Werte nur "ungefähr" darstellen kann, d. h. es gibt immer irgendwelche Ungenauigkeiten.

int hingegen ist exakt.

Beispiel:

float f = 0.1 + 0.1 + 0.1;
int i = 1 + 1 + 1;

Der Integer ist exakt 3, der Float-Wert hingegen ist NICHT exakt 0.3.

Je mehr, länger und öfter Gleitpunktwerte verrechnet werden, desto stärker akkumulieren sich diese Fehler, und gerade wenn du große mit kleinen Werten verrechnest, wird es sehr oft passieren, dass dein float-Wert um einige zichtausend neben dem korrekten Ergebnis liegt.

Merke dir: floats sind nur Annäherungen an korrekte Werte, werden diese aber so gut wie nie exakt darstellen können.

Wenn du dir sicher sein willst, rechne so lange wie möglich mit ints und arbeite erst ganz zum Schluss mit floats.

Aus dem selben Grunde werden Geldbeträge bei Banken auch nicht als float behandelt, sondern es wird ausschließlich mit ints gerechnet.

Das hängt sehr vom Umfang ab.

Einen Forth-Parser bekommst du in 3 Zeilen C-Code hin, einen Parser für C++20 hingegen sicherlich nur mit vielen zichtausend Zeilen C-Code.

Und in was soll kompiliert werden? Im einfachsten Falle in eine weitere Sprache, oder für eine eigene virtuelle Maschine, oder für eine real existierende CPU mit entsprechendem Executable-Format?

Und soll das Ganze standalone laufen, oder planst du auf fertige Bibliotheken zurück zu greifen, allen voran die Standard-C-Bibliothek?

Alles in allem kommen da mehrere Themen zusammen.

Ich habe bislang folgende "eigene Programmiersprachen" geschrieben:

• eine Art Hochsprachenassembler für eigene Stack- und Registermaschinen
• Metacompiler um C mit Features von Python anzureichern.
• Erweiterung von Sprachfeatures mithilfe der Metaprogrammierung in C++ und Python
• Ganz viel dreckige Makromagie mit dem C-Präprozessor, um C mit Exceptionhandling auszustatten, ohne auf C++ angewiesen zu sein, uvm.
• in verschiedenen Skriptsprachen recht schwachbrüstige Interpreter für andere Skriptsprachen geschrieben
• ein Clang-Backend für eine eigene virtuelle Maschine

Das meiste davon nur als DSL für Spezialanwendungen.

Eine "richtige" Programmiersprache from Scratch zu schreiben, hatte ich bislang nicht nötig. Wäre mir auch zu umfangreich und ich sehe darin keinen nutzen.

Aber so etwas wie Qt (mit dem Signal- und Slotsystem) als Compilerzwischenschicht musste ich schon oft basteln.

Unterschätze den Aufwand für eine richtige eigene Programmiersprache nicht! Der dürfte enorm sein. Zumal der Nutzen fraglich ist.

Das geht sehr einfach so:

num = 147

locals().update((chr(ord('a') + i), int(c)) for i, c in enumerate(str(num)))

print(a) # 1
print(b) # 4
print(c) # 7

Aber das ist mit Sicherheit nicht das, was du wirklich willst!

Befasse dich am besten damit, wie die Containertypen funktionieren, vor allem Listen. Dann wird sehr vieles sehr viel einfacher werden! ;)

Aktuelle KIs sind Fachidioten.

Aber GPT-3 dürfte momentan die fortgeschrittendste KI sein, neben Roderic.

Häh? Wovon redest du bitte?

Keine Zeit hat es zu einer anderen Zeit gegeben.

Jeder (beliebig lang wählbare) Zeitabschnitt ist verglichen mit anderen anders.

Wird doch genutzt, wenn sinnvoll!

Ist eben meistens nicht nötig, also verzichtet man drauf. Kommt aber in der Praxis tatsächlich hin und wieder vor!

Nicht lösbar, sofern jede Linie exakt einmal überfahren werden muss, da 6x rot und 8x blau, wobei mit rot begonnen werden muss.

Fazit: Es gibt keine Lösung! Außer man lässt Linien aus!

Zu umständlich und stört den Lesefluss massiv.

Bin blind, und sowohl mit Braille, als auch Screenreader, macht Gendern absolut keinen Spaß.

Du kannst "static" nutzen, was aber anders funktioniert, als du vielleicht von anderen Sprachen her erwartest. (Es verhindert u. a. das öffentliche Exporieren von Symbolen.)

Keine Ahnung, was du vor hast, aber Präfixe bei Bezeichnern und viel Disziplin helfen Pseudo-Namensräume aufzubauen.

Oooooder du nutzt einen C++-Compiler und nutzt lediglich "namespace" und "using" zusätzlich zu deinem herkömmlichen C-Code.

Davon abgesehen, dass dieser Schufa-Score mehr oder weniger Kaffeesatzleserei ist: 90% ist aber schon ziemlich schlecht.

Ich kenne jemanden, mit mehreren Krediten, Konten bei vier verschiedenen Banken, und der hat einen Score von weit über 99%.

Aber wie gesagt: Kaffeesatzleserei.

Und schnell wird der sich auch nicht ändern, da das, was du heute kündigst, glaube ich noch ein weiteres Jahr lang bei der Schufa gespeichert werden wird.

Nichts. Es wäre zu klein und zu leicht für ein schwarzes Loch. Es würde vermutlich sofort zerstrahlen und wäre dann weg. In der näheren Umgebung wären sicherlich alle Lebewesen sofort tot, aber sooo groß wäre dieser gefährliche Radius auch nicht.

Der Sprung von PHP 5.x auf 7.x war schon ein merkbarer Performancesprung, und ich denke, ähnlich wird es jetzt beim Wechsel hin zu PHP 8.x sein.

Aaaaaber PHP-Code ist oft nicht wirklich von hoher Qualität, und mit diversen Caching-Techniken kann man unvergleichbar mehr an Performance heraus holen.

Ein riesen Problem, welches ich bei PHP 8.x sehe, ist der extreme Enbruch im Punkto Sicherheit.

PHP 8.x ist jetzt dort angekommen, wo früher Flash und Javaapplets aufgehört haben.

Der Hauptgrund, der 99% aller Sicherheitslücken bei JavaScript im Browser, Java in der VM oder eben früher Flash in der Sandbox, erst möglich macht, ist der JIT-Compiler.

PHP führt jetzt ebenfalls einen JIT-Compiler ein, was zwangsweise zur Folge hat, dass Speicherseiten nicht mehr W^X markiert sein können.

Bislang war genau DAS der Grund, für nahezu alle Sicherheitslücken in ALLEN mir bekannten Projekten mit JIT-Compilern.

Anzunehmen, PHP wäre das erste Projekt, welches dieses seit Jahrzehnten bestehende Problem in den Griff bekommt, ist natürlich völlig illusorisch. (Vor allem beim "ersten Versuch" gleich nach Release bei Version 8.0.x ... wers glaubt!)

Fazit: Die Performance wird merklich steigen, vor allem wenn man vernünftigen Code schreibt, und vermeindlich unnötige Features wie Typehinting nutzt, aaaaaber der JIT-Compiler hat eine ganze Reihe an neuen Angriffsvektoren aufgemacht, von denen wir sehr zeitnah noch sehr viel hören werden.

So eine Art vier dimensionale komplexe Zahl. Braucht man häufig um zum Beispiel Rotationen im dreidimensionalen Raum effizient berechnen zu können.

Du bist nicht skeptisch, sondern ungebildet. Aber das trifft auf fast alle zu, die sich selber als "skeptisch" bezeichnen.

Ja. In meinem Falle: Aufstieg bis ca. zur Hälfte, dann Übernachtung in einer Hütte, am Morgen während der Dunkelheit Aufstieg, sodass man den Sonnenaufgang vom Gipfel aus beobachten kann, und danach Abstieg bis zum Fuße.

Zum Thema Sportlichkeit: Wichtiger ist, ob du an große Höhen gewöhnt bist. Ansonsten bekommst du mordsmäßige Kopfschmerzen und musst pausenlos an einer Sauerstoffflasche schnüffeln ... die man unterwegs in der Hütte auch kaufen kann.

Aber der Aufstieg an sich ist recht komfortabel, wenn man halbwegs trainiert ist, und nicht gerade die schwerste Route wählt. :)

Du solltest nicht die alten C-Funktionen srand() und rand() nutzen, sondern die Möglichkeiten, die dir modernes C++ bietet.

Im <random> Header gibt es ein Interface zum echten Hardwarezufallszahlengenerator deines Computers, was meistens entweder die CPU oder ein TPM-Chip sein wird.

In modernem C++17 sieht das dann so aus:

#include <iostream> // cout, endl
#include <random> // random_device, uniform_int_distribution

#include <cstdlib> // size_t

int main (void) {
    using namespace ::std;

    random_device gen {};
    uniform_int_distribution<int> dist { 1, 100 };

    const auto num { dist(gen) };
    cout << "Number: " << num << endl;

    size_t i { 1UL };
    while (num != dist(gen)) {
        ++i;
    }

    cout << "Tries: " << i << endl;
}

Wie gesagt, dein Compiler muss dafür C++17 unterstützen können, allerdings eigentlich nur für die Initialisierung mit "auto", die ich verwende. Alles andere funktioniert auch ab C++11.

Ich hoffe, ich habe deine Frage richtig verstanden. Das obige Programm "rät" eine Zufallszahl im geschlossenen Intervall von 1 bis 100, und zählt danach einfach, wie oft es weiter raten muss, um die zuerst geratene Zahl nochmals zu erraten.

Naja, viel Spaß! :)

Eindeutig ja. PHP ist nur fürs Web geeignet.

Man kann damit zwar auch Skripte bauen, die in der Konsole laufen, aber andere Sprachen sind dafür bei weitem besser geeignet.

Allein schon die Tatsache dass in PHP kein Shebang möglich ist, macht die Sache etwas unhandlich.

Und solche Dinge wie Pipes aus herkömmlichen Shellskripten oder List-Comprehensions von Python, Ruby oder Perl kennt PHP auch nicht, was zur Folge hat, dass man unvergleichbar mehr Tipparbeit hat, als würde man gleich auf eine geeignetere Sprache setzen.

Dann gibt es noch eine ganze Reihe semi-unterstütze Projekte, mit denem man GUI-Anwendungen oder Smartphone-Apps mithilfe von PHP bauen können soll, aber da stößt man binnen Stunden an Grenzen. Mehr als Proof-of-Concept ist das alles nicht.

Hinzu kommt, dass PHP nicht wirklich schön mit Binärdaten umgehen kann, und man alles irgendwie als String behandeln muss.

Das gleiche gilt für Unicodeunterstützung, für die es gleich eine ganze Reihe an Workarounds und ebenso vielen Fehlerquellen gibt.

Und obwohl PHP als Serversprache entwickelt wurde, fehlen Synchronisierungsmöglichen, die eine Parallelisierung unmöglich machen. Man ist Quasi auf die vom Server bereitgestellten Threads angewiesen, kann aber ohne Drittmodule keine eigene Parallelisierung mit Prozessen oder Threads implementieren ... und selbst mit POSIX-, SysV- usw. Drittmodulen geht es auch nur sehr unschön, weil es alles nur halbgar implementiert ist.

Das ist überhaupt ein riesen Problem von PHP, das ich von keiner anderen Sprache kenne: Die Pflege der Drittmodule wird extrem schleifen gelassen! Das OpenSSL-Modul enthält zu großen Teilen leere Funktionsrümpfe, Konstanten sind einfach nicht definiert, obwohl in der Dokumentation vorhanden, uvm.

Apropos Dokumentation: Keine andere Sprache hat eine so dermaßen fehlerträchtige und unfertige Dokumentation wie PHP. Nicht ohne Grund gibt es am Ende jeder Seite unzählbar viele Kommentare, die auf Inkonsistenzen, Unzulänglichkeiten, fehlende Informationen oder schlicht Fehler hindeuten.

Darüber hinaus ist die Dokumentation an vielen Stellen total veraltet. Es ist z. B. oft die Rede davon, wie man mithilfe des UA-Strings den Internet Explorer erkennen kann, oder Flashcontent erstellt. Aber auch an anderen Stellen merkt man deutlich, dass die Dokumentation nicht auf dem aktuellen Stand ist.

Uuuuuuuund zu guterletzt die vielen Inkonsistenzen im Sprachdesign und v. a. den Bezeichnern. Ein ähnliches Wirrwarr gibt es bei keiner anderen Sprache, und ich hoffe, dass diese Zöpfe mit PHP 8 endlich abgeschnitten werden.

Lange Rede kurzer Sinn: Auch wenn es mehr theoretisch als praktisch die Möglichkeit gibt, auch mit PHP das ein oder andere Shellskript, eine GUI-Anwendung oder eine Smartphone-App zu entwickeln, so ist das alles doch sehr praxisfern.

Anstatt zu versuchen, so etwas unter Krämpfen mit PHP tot zu schlagen, lieber von Anfang an auf ein passendes Werkzeug setzen.

Man muss sich nicht quälen, nur weil irgendeine Frickellösung existiert, die vorgibt, das zu können.

Also PHP am besten nur fürs Web nutzen. Für alles andere gibts Besseres! :)

Da stecken Mietzekatzen dahinter! Die tun immer so niedlich, aber in Wirklichkeit wollen sie uns mit Corona, 5G und Katzenklos unterjochen.

Dummerweise erkennt das außer mir niemand!

Das ist total normal!

Konnte ich mir früher auch nicht vorstellen, aber komischerweise stecken ich und meine Frau uns auch fast nie gegenseitig an.

Wir trinken aus dn selben Gefäßen, schlafen im selben Bett, arbeiten im selben Büro, und tun andere ehepaartypische Dinge.

Trotzdem infizieren wir uns eigentlich nie gegenseitig mit Schnupfen, Erkältung und sogar Grippe.

Woran das liegt, weiß ich nicht, aber dass es bei Corona nicht anders sein wird, ist zumindest annehmbar.

Trotzdem wäre ich vorsichtig, da ich keine Lust auf Covid hätte.

Alle aktuellen AMD-CPUs haben AVX-512 schon lange dabei.