Exakt 42%. Für alles! :)

Ein Hash ist ein Integer, der immer exakt dieselbe Größe von 4 Byte hat.

Nehmen wir mal an, es wäre kein "int", sondern ein "byte" und die einzig gültigen Hashwerte wären nicht -128 bis +127, sondern nur die Werte der Kleinbuchstaben 'a' bis 'z'.

Nehmen wir weiter an, der Algorithmus für Strings bestünde darin, einfach den ersten Buchstaben zu nehmen, sodass wir folgende Hashes für die entsprechenden Strings erhalten:

"Alpha" => 'a'
"alibaba" => 'a'
"" => 'a'
"Beta" => 'b'
"bierbauchartig" => 'b'
"Keksdose" => 'k'

Wie du siehst, ist es unmöglich aus den Hashwerten wieder die ursprünglichen Strings zu rekonstruieren, da derselbe Hashwert ohne weiteres für unendlich viele Strings stehen kann.

Und auch die Tatsache, dass Java-Hashes intern einen Integer mit 4 Byte einnehmen, ändert nichts daran, dass es pro Hash unendlich viele mögliche Strings und andere Objekte geben kann.

Das ist übrigens nicht nur bei Java so, sondern bei allen Hashalgorithmen, auch den kryptografisch sicheren. :)

Wenn du eine "deutsche" Programmiersprache suchst, ist C vielleicht etwas für dich:

#𝔦𝔫𝔠𝔩𝔲𝔡𝔢 <𝔰𝔱𝔡𝔦𝔬.𝔥>

𝔦𝔫𝔱 𝔪𝔞𝔦𝔫(𝔳𝔬𝔦𝔡) {
  𝔭𝔲𝔱𝔰("𝔖𝔢𝔯𝔳𝔲𝔰, 𝔚𝔢𝔩𝔱!");
}

Dazu müsstest du dir aber noch einen nicht-deutschen Präprozessor bauen, damit der obige Code kompiliert werden kann.

Also grundsätzlich kannst du ein Betriebssystem zu 100% selber schreiben, so wie es weltweit sicherlich schon zehntausende von Schülern, Studenten oder ausgebildeten Entwicklern gemacht haben.

Das ist dann aber nicht so etwas "wie Windows 10", sondern eher so eine Art Shell, Ein- und Ausgabemöglichkeiten, Dateisystem, Speichermanagement, usw. ... also ganz ganz rudimentär.

Es gibt auch Projekte, die viel weiter gehen, und wirklich schicke grafische Oberflächen mit Medienplayern, Webbrowsern, usw. entwickeln, aber die kannst du an einer Hand abzählen. Siehe dazu MenuetOS und dessen Forks Kolibri, usw.

Als ich früher mein OS zu Übungszwecken geschrieben habe, bin ich so vorgegangen:

• auf einem uralten Windows 98 habe ich mit dem Turbo-Assembler von Borland Binärblobs gebaut, die ich direkt auf die Sektoren einer Diskette geschrieben habe (aber bis die Minimalshell auf erste Eingaben gewartet hat, und erste Kommandos liefen, verging eine halbe Ewigkeit)
• nachdem Minimalshell, ein rudimentärer Editor, ein primitivst-Dateisystemchen und eine Hand voll Werkzeuge liefen, habe ich einen Assembler damit gebaut (ab diesem Zeitpunkt war ich unabhängig von anderen Betriebssysteme, also Windows in diesem Falle)
• Dann habe ich mir ein Forth-System (v. a. den Interpreter) mit dem Assembler gebaut. (einfach weil man so etwas für Forth in ein paar KB packen kann)
• Dank dieser "Hochsprache" konnte ich wesentlich schneller Programmieren und habe mir im nächsten Schritt einen C-Compiler gebaut, der allerdings einen abgespeckten Funktionsumfang hatte.
• Dann habe ich in einem Subset von C einen besseren C-Compiler geschrieben, der gefühlt 80% bis 90% des C89-Standards abdeckte, inklusive Standardbibliothek.
• Damit habe ich mir einige einfache Unix-Tools übersetzt und größtenteils zum Laufen gebracht.
• Dann habe ich mich damit auf das Betriebssystem zurück besonnen, und an der Hardware-Unterstützung, dem Dateisystem, der Shell, uvm. gearbeitet.
• Und dann hab ich die Lust verloren, bzw. mich einem anderen Projekt zugewandt :)

Alles in allem war das eine prima Übung um die Theorie von Tanenbaum und das Wissen aus dem Drachenbuch praktisch anzuwenden. Aber von einem "Windows 10" war ich damit noch seeeehr weit entfernt, und hätte mich vermutlich wie eine Amöbe einige zich male selber teilen müssen, um die benötigte Arbeitskraft zur Verfügung stellen zu können.

Fazit: Ein einfaches Betriebssystem, inkl. Bootstrapping von quasi Null, kann jeder. Ein "Betriebssystem" zu bauen, das diesen Namen auch verdient, ist eine Lebensaufgabe, für die ich mich aber - so wie die mit Abstand allermeisten - nicht erwärmen konnte.

Als Übung zum Lernen ganz nett, aber die Welt ist groß, und es gibt noch mehr! :)

Ich persönlich bevorzuge ebenfalls Tabs, aus dem von dir genannten Hauptgrund, dass man die Einrückung beliebig beeinflussen kann.

Und ich meine mit meiner Meinung "absolut" richtig zu liegen, da Tabs eine Art Semantik repräsentieren, und Leerzeichen eine Art Durchmischung von "Design und Content" darstellen.

Bei HTML achtet man auch strikt auf Semantik, und eine Vermischung vom Erscheinungsbild mit dem Inhalt gilt als schlechter Stil.

Grundsätzlich will man also Design vom Inhalt trennen, und das kann man bei Quelltext eben nur mit Tabs.

Übertragen auf HTML wären Tabs das <strong>-Tag, und Leerzeichen das alte <b>-Tag.

Und deshalb ist das Ganze meiner Meinung nach gar keine Glaubensfrage, sondern die Leerzeichennutzer liegen einfach falsch, auch wenn diese Ansicht etwas extrem wirken mag. :)

Fakt ist, dass ein Leerzeichennutzer einen Quelltext mit Tabs beliebig anpassen kann, ein Tabnutzer hingegen einen Quelltext mit Leerzeichen-Einrückungen nur mit speziellen Editoren.

Die eigenen Freiheiten hören also dort auf, wo die Freiheiten der anderen anfangen, und deshalb bin ich grundsätzlich ganz strikt gegen Leerzeichen. :)

PS: Deine Fragen hier sind überdurchschnittlich gut und stechen aus dem GF-Einerlei angenehm hervor. Allerdings neigen deine Fragen auch dazu, ein gewisses Trollpotential zu haben, und Meinungskriege zu verursachen. Das gefällt mir sehr! ;)

Chars kannst du - im Gegensatz zu Strings - einfach mit "==" und "!=" vergleichen:

if (str.charAt(x) != 'A') {
  System.out.println("Nicht A :)");
}

Ich bevorzuge C++, weil man damit generisch programmieren kann, diese Sprache die mächtigeren Sprachfeatures hat, und damit geschriebene Programme in allen Punkten weniger Overhead haben, vor allem im Bezug auf Laufzeitumgebung, Speicher, und CPU.

Aaaaaaaaber, Java nutze trotzdem oft und gerne, vor allem mit dem recht neuen JavaFX, dem älteren Swing und neuen schicken APIs, wie den Streams.

Alle Sprachen haben ihre Vor- und Nachteile, und es muss jeder für sich entscheiden, welche Punkte für ihn bzw. das aktuelle Projekt am wichtigsten sind.

Deshalb kann man sicherlich nicht pauschal sagen, Sprache A ist besser als Sprache B, aber in MEINEM Falle nutze ich mehr C++ als Java.

Das wird aber jeder anders sehen und wie sagt man so schön: Wenn du 10 Entwickler fragst, bekommst du 11 Meinungen zu hören. :)

HTML und CSS sind keine Programmiersprachen im eigentlichen Sinne, von einigen CSS-Hacks mal abgesehen.

Und was soll man zu JS sagen? Welche Meinung soll man dazu haben im Bezug auf was?

JavaScript hat interessante Konzepte, vor allem das Ducktyping, aber an einer mächtigen Standardbibliothek mangelt es leider.

Ansonsten hat JS mehr oder weniger gleich viele Inkonsistenzen und Knickeier wie andere Sprachen auch, was sich aufgrund des geringen Sprachumfangs aber noch gut überschauen lässt.

Performancetechnisch ist JS aber lange nicht so gut, wie oft behauptet wird, auch wenn die großen Interpreter bzw. JIT-Compiler gerade in den letzten 10 Jahren einen enormen Geschwindigkeitssprung nach Vorne gemacht haben.

Naja, aber ohne deine Frage genauer zu konkretisieren, weiß ich nicht, was man dazu noch sagen soll. :)

Da in den Tags "Programmieren" steht, geh ich mal davon aus, dass du Zugriff auf irgendeine unixoide Shell hast, in die du Folgendes eintippst:

seq -w 0 999999 >nums.txt

Als Ausgabe erhältst du eine Textdatei, welche hiermit anfängt ...

000000
000001
000002
000003
000004
000005
000006
000007
000008
000009

... und hiermit aufhört:

999990
999991
999992
999993
999994
999995
999996
999997
999998
999999

Aber natürlich geht das auch mit jeder anderen Skript- bzw. Programmiersprache, meist mit einer einzigen Zeile Code.

Naja, viel Spaß! :)

PS: Die resultierende Datei ist knapp 7MB groß. Bist du dir sicher, dass es sinnvoll ist, was du vor hast? ;)

Wenn du nur die ungeraden negativen Zahlen haben willst, dann starte bei -1 und zähle einfach in Zweier-Schritten runter:

int sumfoo(const int k) {
	int result = 0;

	for (int i = -1; i >= k; i -= 2) {
		result += i;
	}

	return result;
}

Das erschlägt dir auch die Behandlung des Sonderfalls bei " >= 0", weil dann immer automatisch "0" zurück gegeben wird. Falls du allerdings wirklich eine Fehlermeldung ausgeben willst, weißt du ja schon, wie man das macht.

Außerdem solltest du die Variablen Funktionslokal deklarieren, und auf Globals verzichten. :)

Denn als Programmierer weiß man, dass bei den Klammern nur eine Anweisung folgen kann. 

Das sagst du so leicht, aber dir ist sicher nicht klar, dass es in C und C++ gar kein "else if" gibt, sondern nur ein allein stehendes "if", bzw. "else". Die Verbindung "else if" kennt C und C++ gar nicht als Einheit!

Das sollte eigentlich auch jeder Programmierer dieser Sprachen wissen, aber den meisten ist das gar nicht klar.

Bei Python und vielen anderen Sprachen gibt es tatsächlich ein "elif", sodass man folgendes schreiben kann:

if x < 0:
  foo()
elif x > 0:
  bar()
else:
  qux()

Bei unixoiden Shells geht das auch:

if [ $x -lt 0 ]; then
  foo
elif [ $x -gt 0 ]; then
  bar
else
  qux
fi

In C/C++ übersetzt würdest du das so schreiben, was allerdings intern eine ganz andere Bedeutung hat:

if (x < 0) {
  foo();
} else if (x > 0) {
  bar();
} else {
  qux();
}

Das Problem ist, dass C/C++ kein "else if" kennt, und der Compiler in Wirklichkeit folgendes sieht, wenn man zusätzlich klammert:

if (x < 0) {
  foo();
} else {
  if (x > 0) {
    bar();
  } else {
    qux();
  }
}

Eben weil C/C++ nur ein "if" und ein "else" kennt, ist das "if" beim vermeindlichen "else if" die eine Anweisung, die ohne Klammern geschrieben wird, dafür aber oft selbst einen geklammerten Block enthält, der jedoch nicht zum "else" davor gehört.

Das mag jetzt für einen Anfänger unwichtig erscheinen, aber ermöglicht bei folgendem Problem die korrekte Antwort ... welcher Code ist richtig?

if constexpr (X < 0) {
  foo();
} else if (X > 0) {
  bar();
} else {
  baz();
}

if constexpr (X < 0) {
  foo();
} else if constexpr (X > 0) {
  bar();
} else {
  baz();
}

Richtig ist nur Lösung B, und A wird unter Umständen einen nicht zu vernachlässigenden Laufzeit-Overhead haben. Falls du nicht weißt, was constexpr-if macht, kannst du das erst mal noch ignorieren, aber merke dir einfach, dass die Tatsache, dass es sowohl in C, als auch C++, kein "else if" gibt, manchmal (wenn auch selten) enorm wichtig ist, und man das im Hinterkopf behalten sollte. :)

Klammern gilt allgemein als guter Stil, und das Weglassen von Klammern bei Bedingungen oder Schleifen gilt als potentielle Fehlerquelle. Außerdem werden die meisten Tools zur statischen Codeanalyse das Fehlen von Klammern ankreiden, wie gesagt, nicht ohne guten Grund.

Der Grund, warum in Büchern oft Klammern weggelassen werden, ist die Platzersparnis. Hier kannst du ja mal die Zeilen durchzählen:

while (foo()) {
  if (bar()) {
    qux();
  }
}

Ohne Klammern sähe das so aus:

while (foo())
  if (bar())
    qux();

Davon abgesehen, dass es auf mich persönlich unschön wirkt, spart man damit 40% an Zeilen ein, was sich bei einem Buch am Ende als bares Geld erweisen wird. Ich nehme an, dass ist der Grund, warum viele Bücher diesen Stil verwenden, auch wenn er mir hässlich erscheint. :)

Aus meiner Sicht ist es auch nicht sicherer die Klammern zu setzen [...] Wenn jemand den Code später überarbeitet und das nicht weiß, dann ist das nicht mein Problem.

Doch, es ist dein Problem, wenn dadurch der Workflow in deinem Programmierteam behindert wird. Auch wenn es jeder Programmierer weiß, so liest sich so ein Quelltext nun mal schlechter.

Und wenn du das nicht glaubst, dann liegt das an deiner fehlenden Erfahrung als Einsteiger. Schreib mal ruhig ein paar hundert Unit-Tests mit deinem Stil ohne Klammern, und ich garantiere dir, dass du SELBST aufgrund dessen Fehler machen wirst, die dir ohne Unit-Tests teilweise nie aufgefallen wären.

Merk dir einfach das, was seit Jahrzehnten guter Stil in der Industrie ist: Grundsätzlich klammern! Immer! Ohne Ausnahme!

Damit erschlägst du eine ganze Klasse von potentiellen Fehlerquellen! Glaub mir, ich spreche da aus Erfahrung! ;)

Jein, deine Messung ist falsch, aber im Grunde hast du ein bisschen Recht.

PHP kennt gar keine Arrays im herkömmlichen Sinne, sondern nur Container die zwar so heißen, intern aber ein Mix aus Deque, verketteten Listen, Bäumen bzw. Hashmaps sind.

Bei Java kommt dem - im Bezug auf dein Experiment - eine ArrayList am nächsten, und diese zu sortieren dauert tatsächlich etwas länger als bei PHP.

Da Java aber auch richtige Arrays kennt, würde man diese bei deinem Test bevorzugen, wobei Javacode dem sinngemäß identischen von PHP überlegen ist.

Ich habe gerade mal drei Benchmarks für Arme zusammen gefrickelt, und zwar in PHP ...

<?php

$arr = array();
for ($i = 0; $i < 100000000; ++$i) {
	$arr[] = rand();
}

$start = microtime(true);
asort($arr);
$end = microtime(true);

printf("%.5f secs\n", $end - $start);

... in Java mit echtem Array ...

import java.util.Arrays;
import java.util.Random;

class Main {

	public static void main(final String[] args) {
		final int size = 100000000;
		int[] arr = new int[size];

		Random prng = new Random();

		for (int i = 0; i < size; ++i) {
			arr[i] = prng.nextInt();
		}

		final long start = System.currentTimeMillis();
		Arrays.sort(arr);
		final long end = System.currentTimeMillis();

		System.out.printf("%.5f secs\n", (end - start) / 1000.0);
	}

}

... in Java mit ArrayList ...

import java.util.ArrayList;
import java.util.Collections;
import java.util.Random;

class Main {

	public static void main(final String[] args) {
		ArrayList<Integer> arr = new ArrayList<Integer>();

		Random prng = new Random();

		for (int i = 0; i < 100000000; ++i) {
			arr.add(prng.nextInt());
		}

		final long start = System.currentTimeMillis();
		Collections.sort(arr);
		final long end = System.currentTimeMillis();

		System.out.printf("%.5f secs\n", (end - start) / 1000.0);
	}

}

... und in C++ ...

#include <algorithm> // sort
#include <chrono> // high_resolution_clock
#include <iostream> // cout, endl
#include <vector> // vector
#include <random> // mt19937

#include <cstdlib> // size_t

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

	constexpr size_t size { 100'000'000 };
	vector<int> vec;
	vec.reserve(size);

	mt19937 gen;

	for (size_t i {}; i < size; ++i) {
		vec.push_back(gen());
	}

	const auto start = high_resolution_clock::now();
	sort(vec.begin(), vec.end());
	const auto end = high_resolution_clock::now();

	const duration<double> diff { end - start };
	cout.precision(5);
	cout << diff.count() << " secs" << endl;
}

Alle Programme erzeugen 100'000'000 Zufallsinteger, legen diese in einem Array bzw. einer Collection ab, und messen dann ausschließlich die Zeit, die beim Sortieren vergeht, und geben diese aus.

Die Ergebnisse sind wie folgt:

C++:             8.7132 secs
Java Array:     10.8170 secs
PHP:            36.0729 secs
Java ArrayList: 51.8430 secs

Daran erkennst du sehr schön, dass Java verdammt schnell sein kann, wenn man es richtig macht, und recht langsam ist, wenn man auf eine - in diesem Falle - ungeeignetere Datenstruktur setzt.

PHP ist im Schnitt immer noch ziemlich lahm und bietet ja auch keine echte Alternative an.

C++ ist - wie nicht anders zu erwarten war - am schnellsten.

Ich muss allerdings dazu sagen, dass ich unter echten Bedingungen so große Arrays parallelisiert sortieren würde, wobei Java und C++ dann nochmal sehr viel schneller sein dürften und abhängig von den verfügbaren CPU-Kernen evtl. sogar unter eine Sekunde kommen könnten.

Außerdem bieten Java und C++ hier noch sehr viele weitere Herangehensweisen um deine Aufgabe zu lösen, aber das würde jetzt den Rahmen sprengen.

Auch hier bietet PHP wieder keine Alternative und hat kein Optimierungspotential.

Fazit: Man kann getrost davon ausgehen, dass PHP solche großen Datenmengen unter realistischen Bedingungen am langsamsten sortieren wird. Einzig und Allein bei ArrayLists ist PHP etwas schneller, aber ein Java-Entwickler wird ArrayLists in diesem Falle wohl auch nicht einsetzen wollen.

Wenn er unbedingt ein Haustier haben will, sollte er sich einen Hamster kaufen. Aber ein Hamster wird ihm vermutlich nicht "männlich" genug sein. :)

Ansonsten würde ich ihm einen Deutschkurs an der VHS empfehlen, damit er die vier Fälle lernt, was in der Grundschule wohl an ihm vorbei gegangen ist. ;)

Mir ist absolut egal wer da kassiert.

Die Gründe hast du ja schon genannt.

Und als weiterer Punkt fällt mir noch ein, dass all die über Jahre erarbeiteten Erkenntnisse im Bezug auf UI-Gestaltung mit Elektron-Anwendungen über den Haufen geworfen werden, und jedes Programm völlig anders aussieht, sich anders bedienen lässt, andere Farben, Schriftarten und -größen nutzt.

Erst gestern wieder erlebt: Total aufgeblasene Software mit zich Megabyte und viel optischem Schnickschack, dafür aber alles andere als ergonomisch nutzbar. Die langsamen Animationen beim überblenden der einzelnen "Seiten" haben einfach nur genervt.

Ganz ehrlich, eine primitive Anwendung mit meinetwegen der ollen alten Win32-API belegt nur ein hundertstel so viel Plattenplatz, frisst nur ein Tausendstel so viel Speicher, reagiert quasi in Echtzeit, wirkt nicht wie ein Fremdkörper den anderen Fenstern gegenüber und ist schlicht und ergreifend einfach nur "benutzbar", im Gegensatz zu Electronmüll.

Electron ist einfach nur Bloatware, auf die Entwickler angewiesen sind, die nichts anderes gelernt haben. Alle anderen machen einen Bogen darum.

Der Pfuschlevel ist besonders unter Entwicklern, die auf Electron setzen, überdurchschnittlich hoch. Aber jede Generation hat ihre Hipster und da Flash ja jetzt tot ist, gibts eben Electron zum spielen. Igittipfui ... ><

Das, was jetzt kommt, wird dir ganz und gar nicht gefallen, ist aber leider die Wahrheit ...

Alle Anwendungen, die eigentlich Geld kosten, werden irgendwie gecrackt und weiter verkauft. Dem möchte ich vorbeugen.

Dem kannst du nicht vorbeugen.

Ist das überhaupt eine gute Lösung?

Nein. Ich betreibe privat und beruflich Reversing und übe oft mit irgendwelchen "Crackmes" aus dem Internet, und die von dir beschriebene Methode würde mich vermutlich nur etwas mehr als 30 Sekunden beschäftigen.

Das ist jetzt in keiner Weise übertrieben! Wenn dein Schutz nur aus dem besteht, was du da beschrieben hast, würde selbst ein mittelmäßiger Reverser keine 5 Minuten benötigen, um deine Software zu cracken. Wie gesagt, ich brauche für ähnliche Crackmes im Schnitt 30 bis 60 Sekunden.

Dir muss klar sein, dass dein Programm - obwohl es kompiliert ist - für jemanden mit Assembler-Kenntnissen und fortgeschrittenen Kenntnissen auf dem Gebiet, fast so flüssig lesbar ist, als hätte er deinen Quelltext vor der Nase. Vor allem Bedingungen (Vergleiche mit Sprüngen) zu verbiegen, ist trivial und ist überhaupt gar kein Schutz.

Wenn irgendwo in deinem Programm steht ...

if (false == validateLicenseKey(uid, key)) {
  closeApp();
}

doFancyStuff();

... dann ist es für jemanden wie mich ein Leichtes, diese Stelle innerhalb deiner Binary zu finden, und den Code so zu manipulieren, als hättest du in deinem Quelltext Folgendes zu stehen:

if (false) {
  closeApp();
}

doFancyStuff();

... oder so etwas hier:

goto cracked;
if (false == validateLicenseKey(uid, key)) {
  closeApp();
}

cracked:
doFancyStuff();

Oder, oder, oder, ... ich könnte deinen Code nach Belieben "vergurken". :)

Anhand deiner Frage erkenne ich, dass du dich noch nicht so intensiv mit dem Thema Kopier- bzw. Tamperschutz auseinander gesetzt hast, aber ich kann dir aus Erfahrung sagen, dass die gängigen Top 500 Techniken, die du bei Google finden wirst, zu 90% automatisiert von entsprechenden Disassemblern umgangen werden können, und an den verbleibenden 10% beißt sich niemand die Zähne aus, weil es eben sowieso alles ausgelutschte Kamellen sind.

Versteh mich nicht falsch, ich bin kein Cracker, aber ich analysiere beruflich Malware, und z. B. Trojaner sträuben sich mit Händen und Füßen dagegen, analysiert zu werden ... das hält mich allerdings nur selten länger als 5 Minuten auf.

Also merke dir bitte einfach, dass dein Kopierschutz in der jetzigen Form trivial selbst von Anfängern umgehbar ist. Investiere die Zeit dafür lieber in die Funktionalität deiner Software und beseitige z. B. bekannte Bugs. Da haben am Ende deine Nutzer wesentlich mehr von!

Außerdem bringen Kopierschutzmaßnahmen IMMER irgendwelche Nachteile mit sich, unter denen reguläre Nutzer leiden werden, und Leute die Cracks nutzen, bekommen davon gar nix mit.

Wenn z. B. dein Provider ein technisches Problem hat, und dein Server für kurze Zeit down ist, dann werden in dieser Zeit deine regulären Kunden keinen Zugriff auf die Software erhalten. Die Leute, die einen Crack nutzen, merken hingegen gar nix davon.

Lange Rede kurzer Sinn: Für Reverser / Hacker / Cracker (egal ob im positiven oder negativen Sinne) wird dein Kopierschutz alles andere als eine Herausforderung sein. So etwas knackt man mal eben schnell während die Frühstücksbrötchen im Ofen backen. Und es bietet praktisch nur Nachteile für deine regulären Nutzen.

Deshalb mein Tipp, den du vermutlich nicht hören willst: Lass den Kopierschutz komplett weg und fokussiere dich auf die Funktionalität deiner Software. Appelliere an die Vernunft deiner Nutzer und werbe damit, dass du bewusst keinen Kopierschutz einsetzt, um deinen regulären Nutzern lästige Bugs und Fehler zu ersparen.

Illegale Kopien wirst du nie verhindern können, aber du kannst mit Sympathie und Qualität den größten Teil deiner Nutzerschaft dazu bewegen, trotzdem eine Lizenz bei dir zu kaufen.

Nicht alle Leute sind Schmarotzer und ich habe schon immer gerne lieber etwas Geld für gute Software ausgegeben, als mir Cracks zu besorgen.

Viel Erfolg mit deiner Software! :)

PS: Und lass die Finger von fertigen Kopierschutzsystemen, die dir auf ihrer Website den ultimativen Schutz deiner Software versprechen. Die Dinger funktionieren NIE und es dauert nach dem Erscheinen einer neuen Version meist nur Stunden bis Tage, bis ein generischer "Patcher" oder "Keygen" für Software veröffentlich wird, die damit vermeintlich "geschützt" ist.

Trotzdem viel Glück mit deiner Software! ;)

::std::vector<::std::string> vec { "abc", "def" };

const char c { vec[1][2] }; // 'f'

Dir ist schon klar, dass die Begriffe "Lehrer" und "Lehrende" eine völlig unterschiedliche Bedeutung haben?

Im Deutschen gibt es so gut wie keine Wörter, die exakt die selbe Bedeutung haben und beliebig ausgetauscht werden können, ohne dass sich die Bedeutung ändert.

Gerade bei diesen Gender-Ersatz-Wörtern ist es faktisch IMMER so, dass eine Änderung der eigentlichen Aussage billigend in Kauf genommen wird. (Z. B. auch bei "Studenten" vs. "Studierende", was etwas völlig anderes ist.)

Man KANN "Lehrer" nicht beliebig durch "Lehrende" austauschen. Auch der Vorschlag aus der anderen Antwort mit "Lehrkräfte" bedeutet nicht unbedingt das selbe wie "Lehrer".

Merke: Man kann durchaus "Lehrer" sein, ohne eine "Lehrkraft" zu sein und dabei kein "Lehrender" zu sein. Genauso können "Lehrende" weder "Lehrer" noch "Lehrkraft" sein. Mach dir die Bedeutung dieser Wörter bitte mal klar!

Das ist realistisch betrachtet mit Python nicht möglich.

Du musst davon ausgehen, dass Nutzer dein VST-Plugin bei zwei Kanälen (also Stereo) und 192kHz nutzen.

Intern werden Audiodaten i. d. R. als Gleitpunktwerte behandelt, und wenn du für jeden Sampleframe mit nur 10 Operationen rechnest, wird es mit Python performancetechnisch sehr eng werden, gerade bei solchen Echtzeitanforderungen.

C++ ist hierbei über 100 mal schneller und kann dementsprechend mehr als 100 mal so viele Sampleframes pro Sekunde verarbeiten. (Hab das eben mal ausprobiert!)

Von daher: Mit Python zwar sicherlich irgendwie möglich, aber sollte man vermeiden, vor allem in solchen Bereichen, wo es auf präzises Timing ankommt.

Aus technischer Sicht könntest du ein VST in C++ schreiben, und einen Python-Interpreter einbinden, der dir ein Skripting erlaubt. Alles keine große Sache, aber der Nutzen ist eben wirklich fragwürdig.

Soweit ich weiß werden die meisten der brandneuen Spiele, vor Allem die, die aufwendige Grafiken beinhalten, ...

Ich gehe aufgrund dieses Halbsatzes in meinen folgenden Ausführungen mal davon aus, dass es dir hauptsächlich um grafiklastige AAA-Titel geht.

Kurze Antwort: Nein, das ist mit Java nicht möglich. Deshalb gibt es solche Java-Spiele auch nicht. Vom Spielprinzip her interessante Spiele wie Minecraft gehen natürlich, aber Minecraft sieht nicht ohne Grund wie Minecraft aus. :)

Lange Antwort: Java ist und bleibt merklich langsamer als C++, vor allem wenn es um ganze Programme, und nicht nur um kurze Demo-Algorithmen mit ein paar Zeilen geht.

Allein schon die Tatsache, dass Javacode in einer "gemanageten Umgebung" ausgeführt wird und auf einen GC (Garbage Collector) angewiesen ist, der dir zu nicht-vorhersebahren Zeiten in den Fluss deines Programms eingreifen wird, verhindert, dass ein Spiel flüssig und ohne merkliche Ruckler laufen wird.

Du kannst den GC zwar auf einen eigenen CPU-Kern auslagern, aber selbst dann muss er in Echtzeit (!) mit den anderen Threads / Prozessen kommunizieren, und so eine IPC (Interprozesskommunikation) frisst enorm viele Ressourcen.

Dazu zählt auch der erhöhte Speicherverbrauch. Im Schnitt verbrät der GC bei Java ca. anderthalb mal so viel Speicher für das aufzuräumende Objekt, als dieses in Wirklichkeit an Speicher belegt. Und "Speicher reservieren" ist so ziemlich die aufwändigste Operation, die intern in einem Programm ablaufen kann und gerne mal einige tausend CPU-Takte andauert.

Deshalb gibt es bei solchen Java-Programmen oft Peaks, bei denen sich CPU-Auslastung und Speicherverbrauch gegenseitig hochschaukeln, und SO ETWAS will man gerade bei Spielen überhaupt nicht haben.

Frag dich einfach mal selbst, warum es keinen einzigen Triple-A-Titel mit Java gibt. Die werden alle mit C++ oder evtl. noch mit C# geschrieben.

Wobei bei C# ein ähnliches Problem wie bei Java existiert. Wenn ein C#-Spiel aber gerade mal noch so flüssig auf einem High-End-PC läuft, dann kannst du im Umkehrschluss davon ausgehen, dass das selbe Spiel mit C++ nochmal deutlich flüssiger und mit wesentlich mehr Freiraum nach oben laufen würde.

Anders herum wird ein Spiel, welches schon mit C++ hart an der Grenze ist, mit C# - und erst Recht mit Java - schlicht und ergreifend unspielbar sein, es sei denn, du stehst auf Dia-Shows. :)

Java ist zwar eine wunderbare Sprache, aber - schon allein vom Konzept und Sprachdesign her - für Spiele leider völlig ungeeignet. Klar, du wirst so etwas wie Supermario darin bauen, und auch einfache 3D-Szenen erstellen können, aber mach dir nichts vor: Früher oder später MUSST du zu C++ wechseln, falls du grafisch aufwändige Spiele entwickeln willst. (Oder auch C#, allerdings mit Abstrichen!)

Wenn du jetzt, mit dem Hauptziel "Spieleprogrammierung" Java lernst, dann garantiere ich dir, dass du dir später selbst in den Hintern beißen wirst, wegen der verschwendeten Zeit.

Du kannst zwar irgendwelche Engines nehmen, und deren API-Aufrufe mit Java (oder sogar Python) zusammen kleben, aber du wirst damit immer auf relativ niedrigem Niveau rumfrickeln und Programmiertechnisch nie richtig "Erwachsen" werden.

Wenn man die Sinnhaftigkeit aber mal außer Acht lässt und sich rein auf die Realisierbarkeit fokussiert, wäre es dann möglich, Titel wie Black Ops 4 Oder Battlefield 5 von Grund auf und einzige in Java zu schreiben?

Nein, völlig unmöglich. An so etwas wird auch den nächsten zich Jahren kein Weg an C++ vorbei führen.

Wie gesagt, du kannst einfache Spiele mit Java schreiben, aber vergleiche mal die Demos der gängigen Java-3D-Engines mit den von dir genannten Titeln. Da liegen Welten dazwischen!

Wie sähe es mit CAD-Anwendungen aus? Könnte Software, die mit Blender oder Photoshop verglichen werden kann, in Sprachen wie Java geschrieben werden?

Wenn die Software am Ende auch angenehm benutzbar sein soll, dann nicht. Falls du als Anwender ewig lange Wartezeiten und extremen RAM-Verbrauch gewöhnt bist, dann ja, allerdings mit Ausnahme von Blender, wofür Java wieder einfach zu ungeeignet ist.

Könnte man solche Projekte auch ohne größere Performanceeinbußen realisieren?

Nein, wie oben beschrieben, wird der RAM-Verbrauch durch die Decke gehen, und die CPU dein Arbeitszimmer auch im Winter schön warm halten. :)

Kann man das noch einigermaßen in Kauf nehmen?

Nein, bei den von dir genannten "Softwaren" ist die Grenze zum Zumutbaren bei weitem überschritten. So etwas schreibt man einfach nicht mit Java.

Mir geht es bei der Frage im Grunde genommen darum, mich endlich zu entscheiden welche Programmiersprache ich lernen möchte. 

Im Idealfall beide, Java UND C++, denn nur so kannst du dir ein Bild machen. Außerdem steht in allen Java-Büchern und -Tutorials gleich in der Einleitung immer wie toll performant Java doch ist und dass alle anderen Behauptungen nicht wirklich zutreffend sind. Als reiner Java-Entwickler gewöhnt man sich dann tatsächlich daran, und empfindet Java-Programme oft nicht mehr als sooooo langsam, wie sie in Wirklichkeit sind.

Irgendwann wirst du dann tolle "Tricks" lernen, mit denen man die Geschwidigkeit erhöhen kann, evtl. Dinge wie "Excelsior Jet" nutzen, und dir ständig selber einreden, dass es ja "alles nicht so schlimm" und eigentlich immer noch "ganz gut" ist.

Am Ende sitzt du dann da mit einer fetten Laufzeitumgebung, verglichen mit C++-Programmen exorbitant hohem RAM-Verbrauch, schmutzigen Hacks um die Geschwndigkeitsprobleme doch noch irgendwie in den Griff zu bekommen und machst dir selbst vor, dass die tagelangen Suchen nach Workarounds bei Performance-Problemen die Symptome "ausreichend gelindert" (aber eben nicht "behoben") haben.

Relativ schnell wirst du dann nicht mehr weiter kommen, weil nach oben hin eben keine Luft mehr zum atmen ist, und deine Software bei 95% RAM-Verbrauch auf 100% CPU läuft. Und das ist dann der Moment, an dem du dir denken wirst: "Hätte ich bei der Spieleprogrammierung doch lieber gleich auf etwas Richtiges gesetzt". Und dann wirst du höchstwahrscheinlich aufgeben oder - auch wenn die Wahrscheinlichkeit dazu sehr gering ist - dich nochmal zusammen reißen, und C++ von Anfang an richtig lernen.

Wie gesagt, Java ist ne super Sprache und damit kann man verdammt viele Dinge tun. Aber Spiele, Photoshop, CAD, Blender, etc. gehören eindeutig nicht dazu. Und nur weil "es geht" und es den ein oder anderen Proof-of-Concept dazu gibt, heißt es noch lange nicht, dass es so ordentlich oder vernünftig ist.

Java hat VIEL mehr Overhead als C++, und zwar in einem Maße, dass sich nicht kleinreden lässt. Dummerweise kommt es aber genau DARAUF an, bei Spielen oder grafisch aufwändiger Software.

Fazit: Du willst ganz eindeutig C++ lernen und Java NICHT nutzen, für das, was du vor hast! ;)

Und lass dich nicht von Pseudo-Benchmarks beeindrucken, welche die tausendste Fibonacci-Folge in Java und in C++ vergleichen, wobei Java "fast so gut" wie C++ sein wird. Solche Tests sind völlig unrealistisch und verzerren die Realität. Am Ende wird Java - realistisch betrachtet bei "echten" Herausforderungen - immer um den Faktor 10 bis 100 langsamer sein als C++. Da beißt die Maus keinen Faden ab. :)

Oh, dein Fragetext war ja noch gar nicht zu Ende ... dann mal weiter im Text ...

Aus zeitlichen Gründen und auch deshalb, weil es mich hinsichtlich meines Berufes überhaupt nicht tangiert möchte ich mich auf eine einzige Sprache beschränken und das dafür richtig machen.

Dann verschwende deine Zeit nicht mit Java, und fang mit C++ an, auch wenn C++ verglichen mit Java für Einsteiger merklich "fordernder" sein wird, aber es lohnt sich.

Dabei wollte ich wenn möglich eine Sprach die Alles erlaubt. Da kam mir als erstes Java in den Sinn.

Genau genommen ist C++ die Sprache, die alles erlaubt. Die Einsatzbereiche für Java liegen sehr sehr weit darunter!

Da kam mir als erstes Java in den Sinn. Läuft überall, ist der Hit, wenn es um Android geht, ...

Rein theoretisch läuft Java überall, praktisch betrachtet kannst du die gut unterstützen Plattformen an einer einzigen Hand ablesen. Denn Java läuft nur dort, wo es auch ein JRE gibt, und das sind - anders als in der Theorie - nur sehr wenige Plattformen.

Von gescheiterten Experimenten wie "Java auf Mikrocontrollern" reden wir jetzt mal nicht, denn dort gilt das bekannte "Compile once, run anywhere" überhaupt nicht mehr, weil solche Plattformen einfach zu speziell sind.

Und da du gerade von Android redest ... Spiele-Engines werden für Android in C++ geschrieben, wenn sie grafisch aufwändiger sind, weil es mit Java einfach gar nicht möglich wäre. Diese C++-Teile werden dann kompiliert, und in relativ dünnschichtige Java-Wrapper eingebettet, sodass du dein Spiel am Smartphone nutzen kannst. Für eines der gefühlt vielen millionen Memory-Spiele oder einen Poker-Klon brauchst du natürlich keine C++ Engine auf deinem Android gerät, aber bei allem was darüber hinaus geht schon ... vorausgesetzt, dich kümmert die Akkulaufzeit der Geräte deiner Nutzer und deren Temperatur. (Also die Temperatur der Geräte, nicht der Nutzer!) :)

Ein Treiber in Java, wäre das überhaupt möglich?

Ohne da jetzt auf technische Details einzugehen: Realistisch betrachtet, Nein. :)

Hier haben Sprachen wie C++ tatsächlich die Nase vorne, aber auch da hat man, in den Bereichen wo Assembler eingesetzt wird, Grenzen.

In den 90ern habe ich meinen C++ Code noch hin und wieder mit Inline-Assembler "aufgehübscht", aber das ist heutzutage (fast) nicht mehr nötig.

Im Grund genommen ist das, wonach ich suche wahrscheinlich genau C++, ...

Das hast du richtig erkannt. In deinem Fall führt kein Weg an C++ vorbei.

... man kann sich ja, soweit ich weiß, auch selbst Laufzeitumgebungen basteln oder mit virtuellen Maschinen arbeiten, so dass der Großteil vom Code auch systemübergreifend funktioniert.

C++ Compiler gibt es für VIEL mehr Plattformen, als es JREs für Java gibt. Da mach dir um die Portabilität mal keine Gedanken.

Und das mit den "virtuellen Maschinen" hast du evtl. etwas falsch verstanden. Damit sind in erster Linie keine Dinge wie VMware oder VirtualBox gemeint, sondern ein Entwurfsmuster. Eine VM in C++ zu schreiben geht auf unter 100 Zeilen Code, vorausgesetzt es ist eine recht einfache.

Je nach Anforderung sind VMs in C++ höchst performant und werden gerade bei Spielen gern eingesetzt, um Dinge zu automatisieren, die in einer "geschlossenen Umgebung" lauffähig sein sollen.

Nebenbei bemerkt kannst du genauso gut in Java eine VM bauen, was ich auch schon oft getan habe. Wie gesagt, da ist nichts magisches dran. Es ist einfach nur eine Herangehensweise, ein Problem zu lösen. :)

Ich finde an C++ einfach nichts schlechtes. Allerdings hat mich schon der erste Blick in ein C++ Buch vollständig demotiviert.

Wenn du als Anfänger ein Fachbuch in der Mitte oder weiter hinten aufschlägst, wirst du grundsätzlich nichts verstehen, völlig unabhängig vom Thema (auch über die Programmierung hinaus).

Aber dafür sind Lehrbücher ja da: Dass sie dir Dinge von Anfang an, Schritt für Schritt, erklären.

Deshalb lass dich nicht von den hinteren Kapiteln schockieren, sondern fang beim Vorwort an, und arbeite dich dann Seite für Seite voran. Irgendwann bist du mit dem Buch durch, und wunderst dich, warum du vorher so große Angst davor hattest. :)

Es scheint mir so, als sei es um einiges schwieriger als Java, alleine schon was die Syntax angeht...

Die Syntax bei C++ bietet viel mehr Optimierungspotential als bei Java, und legt dir damit ein sehr mächtiges Werkzeug in die Hand.

Aber das tolle ist: Du musst dieses Werkzeug nicht nutzen, wenn es dich - zumindest am Anfang noch - überfordert.

Und was noch toller ist: Viele syntaktische Konstrukte sind einfacher und kürzer als bei Java! Allein die Mögilchkeit, Operatoren zu überladen, erlaubt dir, wesentlich lesbareren Code zu schreiben. :)

Außerdem ist weder Java, noch C++, für Anfänger entwickelt worden, sondern für Leute, die diese Sprachen größtenteils im Blut haben und damit gut umgehen können.

Und jemand der gut C++ kann, wird C++ Code auch lesen können. Genauso wie jemand, der gut Java kann, auch Java-Code lesen kann.

Du lernst die Sprachen ja nicht, um dein Leben lang Anfänger zu bleiben, sondern um damit "professionell arbeiten" zu können. Und so jemand hat auch keine Probleme mit der Syntax, auch wenn es für ihn als Anfänger früher mal alles furchtbar kompliziert erschien. :)

Lohnt es sich, wenn man sich den Weg zu aufwendigen Anwendungen offen halten möchte, C++ zu lernen, oder sind die Defizite von Java so gering, dass man es sich beim Lernen leichter machen sollte.

Für das, was du unter "aufwendigen Anwendungen" verstehst, hast du gar keine andere Wahl als C++, von daher stellt sich die Frage gar nicht.

Falls du wirklich versuchen solltest, so etwas mit Java zu realisieren, wirst du am Ende mit einer aufgeblasenen, von Abhängigkeiten strotzenden, langsamen, Speicher fressenden, im besten Falle "mittelmäßigen" Anwendung stehen.

Wenn du natürlich nur ein einfaches ERP-System mit Datenbankanbindung für ein mittelständisches Unternehmen bauen willst, kannste gerne Java nehmen. Dabei machen sich die Nachteile dieser Sprache / Laufzeitumgebung kaum bemerkbar, aber AAA-Titel? Das wird nix werden! ;)

... oder sind die Defizite von Java so gering, dass man es sich beim Lernen leichter machen sollte.

Wie gesagt, Java lernen lohnt sich in jedem Falle! Aber da du ja angibst wenig Zeit zu haben und nur eine Sprache wählen kannst, fällt Java leider weg, auch wenn es leichter als C++ sein wird, aber für dein Vorhaben eben alles andere als geeignet ist. :)

So, das war mein Roman zu dem Thema! ;)

Du musst jetzt selbst entscheiden, wofür du dich entscheidest.

Viel Spaß damit, was auch immer du tun wirst! ;)