Es gibt noch unzählige weitere IPC-Mechanismen, wie shared memory, unix domain sockets, FiFos, Pipes, uvm. wahlweise SysV oder POSIX.

Bislang beobachtete häufige Langzeitschäden sind m. W. n. nur chronische Erschöpfung, Gedächtnisprobleme und Unfruchtbarkeit auch bei leichen bzw. sogar symptomlosen Verläufen.

Achso, und massive Schädigungen an der Herzmuskulatur, Nieren, uvm. gibts auch noch.

Die beste Programmiersprache aus deiner Liste ist eindeutig HTML!

C++ ist übrigens keine Programmiersprache, sondern eine Auszeichnungssprache!

Sehr sehr heiß, oder sehr sehr kalt. So genau kann man das nicht sagen!

Je nach Ort kann das nahe dem absoluten Nullpunkt liegen, oder aber auch gerne mal mehrere Tausend bis mehrere Millionen Grad heißes Gas sein:

https://www.scinexx.de/news/kosmos/raetsel-der-fehlenden-materie-geloest/

Dass es überall nur sehr kalt ist, stimmt also nicht. Es gibt durchaus riesige Bereiche, die unfassbar heiß sind.

Ich habe ein dickes, fettes, sauteures und schweres Wörterbuch mit weit über 2000 Seiten, das so ziemlich alle japanischen Kanj enthält, die es gibt. Das sind deutlich mehr als 100000 Stück!

Kleine Wörterbücher, die nur die Joyokanji enthalten, bekommst du aber in jeder Fachbuchhandlung, oder eben bei Amazon.

Die neuesten HPV-Impfungen verhindern zu rund 90% eine Krebserkrankung.

Deine Freundin gehört dann wohl zu den unglücklchen 10%, bzw. wurde zu einer Zeit geimpft, als die Impfstoffe nur zu 70% schützten.

Verschwörungstheoretiker kann man nur mit Gerüchten aus Telegramgruppen überzeugen, die mindestens um fünf Ecken von anonymen Dritten stammen!

Vernünftig recherchierte Nachrichten oder gar wissenschaftliche Arbeiten international anerkannter Forscherteams können da leider nicht mithalten.

Naja, wir haben damals ziemlich genau ein Zehntel meines Monatslohns für eine sehr große 6-Zimmer Wohnung mit 180m² bezahlt.

Das Haus war alles andere als eine Bruchbude und zum Bahnhof waren es 3 Minuten Fußweg. Zum Konsum 30 Sekunden Fußweg. Zum Fleischer und Bäcker 2 Minuten. Lampenladen eine Minute.

Guck dir mal an, wieviel Prozent eines durchschnittlichen Gehaltes man heute für eine Riesenwohnung in Berlin in Spitzenlage bezahlt.

Außerdem gab es keinen Mangel an Kindergarten- und Krippenplätzen.

Obdachlose habe ich damals nie gesehen. In den 90ern wurde dort eine Suppenküche eröffnet, zu der immer so drei bis maximal sechs Leute kamen. Diese Suppenküche gibt es heute (2020) immer noch und die Schlange der Leute, die dort anstehen, ist mit Sicherheit weit über 150 Meter lang. (Noch vor Corona, ohne Social-Distancing!)

Es war natürlich vieles schlecht, vor allem die primitive Propaganda überall, aber eben auch nicht alles.

Flammenwerfer!

Mir gefallen die vielen Altbauten, die im Krieg nicht so stark zerstört wurden, wie in deutschen Städten.

Hab nur gute Erinnerungen an Paris bzw. ganz Frankreich.

Bezahle privat, dann bekommst du sehr schnell einen Termin.

Bei meiner Frau lief die Terminvergabe so ab, als ich dort angerufen habe:

• Ich: "Hallo, ich hätte gerne einen Termin für meine Frau.."
• Arzthelferin: "Oh, tut mir leid! Wir haben die nächsten drei Monate leider keine freien Termine mehr."
• Ich: "Wir zahlen privat."
• Arzthelferin: "Können Sie morgen früh um 10:00 Uhr hier sein?"

Seitdem bezahlen wir immer alles privat und nutzen die Krankenversicherung praktisch gar nicht mehr. Sind jedes mal im Schnitt 100€ bis 200€.

Total bescheuertes System! Leute, die sich das nicht leisten können, müssen warten, bis es zu spät ist.

Ruf einfach bei ein paar Hautärzten an, und sage direkt am Anfang, dass du als Privatpatient behandelt werden willst. Dann hast du spätestens Anfang nächster Woche deinen Termin.

Gute Besserung!

Typische Schulaufgabe. Sehr einfach. Sehe da keine Probleme.

Also die vorgegebene API ist unschön, weil man dabei zwangsläufig entweder auf globale Variablen angewiesen ist, oder bei jedem einzelnen Funktionsaufruf immer wieder neue Objekte erzeugen und oder zerstören muss.

Ich habe mich jetzt mal für einen globalen Zufallszahlengenerator und eine globale Ganzzahlverteilung entschieden:

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

#include <cstdlib> // size_t

using namespace ::std;

random_device generator {};
uniform_int_distribution<int> distribution { 1, 6 };

int wuerfel() {
    return distribution(generator);
}

void wuerfel(int & zahl) {
    zahl = distribution(generator);
}

int main (void) {
    for (size_t i { 1 }; i <= 9; ++i) {
        cout << "Runde #" << i << ": ";

        cout << wuerfel() << " und ";

        int zahl {};
        wuerfel(zahl);

        cout << zahl << endl;
    }
}

Die Ausgabe sieht ungefähr so aus:

Runde #1: 3 und 5
Runde #2: 4 und 4
Runde #3: 5 und 3
Runde #4: 2 und 4
Runde #5: 5 und 6
Runde #6: 1 und 1
Runde #7: 1 und 3
Runde #8: 4 und 6
Runde #9: 5 und 5

Bei dieser typischen Übungsaufgabe wirst du meistens auf Lösungen mit der ollen alten "rand()" Funktion aus C-Zeiten stoßen, aber da es hier um C++ geht, nutze ich natürlich auch die entsprechende Funktionalität aus dem <random> Header der Standardbibliothek.

Bei C++ gibt es eine ganze Reihe Pseudozufallszahlengeneratoren und einen echten Zufallszahlengenerator, der intern auf echten Hardwarezufall zugreift.

Naja, für Details guck dir die Dokumentation der Standardbibliothek an!

Und noch ein weiterer Tipp: Um besser oder gar wirklich gut werden zu können, löse so viele "Hausaufgaben" anderer Leute hier auf GF! Das ist eine prima Übung, vor allem für dich selbst!

Deshalb ist meine Antwort auch nicht ganz uneigennützig. :)

Trotzdem viel Spaß noch beim Lernen! :)

Anstatt "islower()" bzw. "isupper()", kannst du lieber "lower()" und "upper()" nutzen:

for pw in ('foo', 'BAR', 'bAz'):
    print(pw, end=': ')

    if pw != pw.lower() and pw != pw.upper():
        print('OK!')
    else:
        print('Aahhh!')

Die Ausgabe sieht dann so aus:

foo: Aahhh!!!
BAR: Aahhh!!!
bAz: OK!

Ich denke, das dürfte die kürzeste und eleganteste Lösung sein, ohne unnötige Schleifen.

Ich bin C++ler und TMP ist zufällig genau mein Fachgebiet.

Ich weiß aber, dass ich damit eine absolute Ausnahme darstelle.

Für die meisten - selbst sehr erfahrenen - Entwickler stellt die TMP eine Art unverständlilche schwarze Magie dar.

Das liegt aber m. M. n. nur daran, dass sich nie wirklich intensiv mit dem Thema befasst wurde.

Ich liebe C++ hauptsächlich wegen der TMP, die sonst (in dieser Form fast) keine andere Sprache bietet.

Das besondere an TMP ist, dass oft seeeehr viele Seiten Quelltext, auf eine einzige CPU-Instruktion eingedampft werden können, weil man dem Compiler viel viel viel genauer mitteeilen kann, was man beabsichtigt.

An Stellen, in denen sich im Kompilat viele hundert bis tausend Byte an Instruktionen wiederfinden, kann man diese Größe, und damit einhergehend natürlich die Performance, massiv verbessern.

Das Problem ist, dass TMP wirklich nix für Anfänger ist, und man richtig fit in C++ sein muss, um diese auf einem Level nutzen zu können, dass es wirklich Vorteile bietet.

Dem 08/15 C++ler würde ich deshalb von TMP abraten. Er wird seinen Code dadurch nur unübersichtlich und ineffizient machen, von aufgeblasenen Binaries mal abgesehen.

Hier ist ein etwas älterer C++ Code, der allerdings schon moderne Features nutzt, um die Eulersche Zahl zu berechnen:

anamespace {

template <
    typename T=double,
    long N_=::std::numeric_limits<T>::digits,
    long I_=0L
> [[nodiscard]] constexpr T e_() noexcept {
    static_assert(::std::is_floating_point<T>());
    static_assert(N_ > 0L);
    static_assert(I_ >= 0L);

    if constexpr (I_ < N_) {
        constexpr auto summand { static_cast<T>(3L + I_) };
        constexpr auto dividend { static_cast<T>(-1L - I_) };
        constexpr auto divisor { e_<T, N_, I_ + 1L>() };
    
        return summand + (dividend / divisor);
    } else {
        constexpr auto smallest { static_cast<T>(-0.0000015) };

        return smallest;
    }
}

} // anonymous

template <typename T=double>
constexpr T e { e_<T>() };

Das berechnet zur Kompilierzeit "e" mithilfe eines Algorithmus, der erst vor relativ kurzer Zeit entdeckt wurde, und sehr elegant ist.

Der Vorteil ggü. einem herkömmlichen "Casting" ist, dass versteckte Tippfehler nicht auftreten können, und bei einer möglichen zukünftigen Einführung von z. B. "long long double" oder "quad" der Code nicht angefasst werden muss, sondern einfach nur "e<long long double>" bzw. "e<quad>" sofort die Eulersche Zahl mit - für den gewählten Typen - perfekter Genauigkeit zur Verfügung steht.

Zudem wird unnötigerweise nichts berechnet werden, wenn kein "e" mit "double" Genauigkeit benötigt wird, und der Laufzeitoverhead ist gleich Null, da im Kompilat nur eine Konstante stehen wird.

Und zur Kritik aus der anderen Antwort bzgl. der Kompilierzeiten: Das ist doch gerade der Tradeoff! Es geht darum, zur Kompilierzeit so viel wie nur irgendmöglich zu erledigen, um dann zur Laufzeit Konstanten nutzen zu können.

Man bezahlt viel bessere Laufzeitperformance mit längeren Kompilierzeiten. Ist dies nicht gewünscht, gibt es Vorwärtsdeklarationen, Techniken wie Compilerfirewalls, Unity-Builds, und eine Million mehr Ansätze, die Kompilierzeit auf ein Bruchteil zu reduzieren.

Oder man verzichtet einfch auf TMP, wenn man der Meinung ist, dass Kompilierzeiten wichtiger sind, als Laufzeitoverhead.

Und "cool sein" ist in meinen Augen auch kein Grund, TMP zu nutzen.

TMP ist dann sinnvoll, wenn es sinnvoll ist. Punkt!

Wie gesagt, die meisten C++-Entwickler sind mit TMP überfordert und haben meistens noch nie wirklich eigenen Code damit entwickelt.

Allerdings ist nur mit TMP Code mögich, der auf andere Art und Weise nicht mögich wäre. Und nur mit TMP kann man Performance und Speichersparsamkeit erreichen, die ohne nicht ginge.

Allerdings muss man immer auch abwägen, ob es das Wert ist. Pauschal kann man also TMP nicht (!) empfehlen. Hängt jedes mal wieder vom aktuellen Einsatzzweck ab.

Noch ein kleiner Hinweis zum Schluss: In C++ haben Objekte abgeleiteter Klassen IMMER implizit einen versteckten Klassenzeiger, d. h. sie sind auf 64-Bit-Plattformen immer 8-Byte größer, als es auf den ersten Blick scheint.

Das wird dann zum Problem, wenn man massenhaft Fliegengewicht-Objekte erzeugen will, die nur ein oder zwei Byte groß sind.

Diese werden - wegen Aligning - dann nämlich auf 16 Byte "aufgeblasen". Dann liefert "sizeof(myObject)" plötzllich nicht mehr "1" sondern "16", was den nutzbaren RAM effektiv auf ein 16tel schrumpft.

Lange Rede kurzer Sinn: Mit TMP kann man Kompilierzeit-Klassen-Hierarchien realisieren, die voneinander erben, aber keinen Laufzeitoverhead mehr haben, sowohl im Bezug auf Speichernutzung, als auch auf die vergehende Zeit bei der Initilisierung in Konstruktoren.

Mit TMP kannst du JSON-Parser bauen ... die zur Kompilierzeit arbeiten und zur Laufzeit z. B. nur noch ein konstantes Ergeebnis ausgegeben werden muss.

TMP ist mit herkömmlicher Programmierung nicht vergleichbar! Herkömmliches C++ unterschiedet sich von C++ mit TMP ungefähr so stark, wie BASIC von Haskell.

Und ganz zum Schluss noch eine Feststellung meinerseits: 99,9% aller Kritiker der TMP, haben nie wirklich aktiv damit entwickelt und sich darauf eingelassen. Die mit Abstand meisten der Kritiker haben sogar nicht mal versstanden was TMP genaau bedeutet und können den Vorteil nicht erkennen, wenn ich sage: "Ich schreibe 3 Seiten Quelltext, der zu einer Hand voll Instruktionen vom Compiler eingedampft wird".

Die meisten denken, dass viel Quelltext auch viel Kompilat erzeugen muss, und wenn er das nicht tut, überflüssig ist. Was ein großes Missverständnis ist.

Naja, sorry für den Roman! Viel Spaß noch! :)

Naja, C hat zwar viel "Undefined Behaviour" und "Implemententation Dependend" Zeug, ist aber im Kern eine sehr schlanke Sprache, die man durchaus recht zeitnah lernen kann. Zum meistern der vielen Ausnahmen und Sonderfälle braucht man dann zwar auch als Fortgeschrittener eine Weile, aber alles in allem ist C an sich jetzt nicht soooo komplex.

C++ ist viiieeel umfangreicher, und zwar in jedem Aspekt. Von Syntax über die Standardbibliothek bis hin zu den vielen Paraadigmen. Um C++ wirklich gut auch als Fortgeschrittener oder gar Profi in anderen Sprachen beherrschen zu können, vergehen Jahre!

C# passt hier nicht ganz in deine Auflistung, da die Sprache sich schon seeehr von C und C++ unterscheidet. Selbst bei oberflächlicher Betrachtung ist nahezu jeder Aspekt dieser Sprache ziemlich anders, als bei C++ und auch C. Sie ist aber vermutlich auch - vor allem vergllichen mit C++ - sehr viel anfängerfreundlicher.

Allerdings sind in C und C++ Dinge möglich, von denen du bei C# nicht mal träumen kannst, und umgekehrt genauso.

Wenn du in C# eine Anwendung schreibst, die exzessiven Gebraucht vom Speichermanager macht, bzw. oft und viele Objekte erzeugt, dann kannst du die Performance nicht groß beeinflussen, wenn du schon alles am Entwurf bzw. Design ausgereizt hast.

Bei C++ (und auch bei C) kann man sich immer noch einen eigenen Speichermanager schreiben, was ich oft tue, und was die Performance gerne mal um den Faktor 20 auf einen Schlag steigert, ohne Änderungen an vorhandenem Projekten vornehmen zu müssen.

Das kommt zwar selten vor, aber wenn, dann bin ich froh, dass mir C++ die Möglichkeit bietet, einen eigenen Allokator zu nutzen, oder dass C mir erlaubt, [mc]alloc() und free() zu überladen.

Wenn man mit C# Desktopanwendungen schreibt, wird man da nur mit dem Kopf schütteln, aber wenn man z. B. Extensions für Blender schreibt, und das Rendering dauert dann nicht mehr eine ganze Stunde, sondern nur noch drei Minuten, dann lohnt sich das durchaus.

C# bietet hingegen eine viiiieeeel größere Standardbibliothek (bzw. gleich mehrere), die nahezu alles erschlagen, was man sich vorstellen kann.

Alle drei Sprachen - C, C++ und C# - sind auf unterschiedlichen Gebieten die mächtigsten.

Die Sprache, welche die Entwickler bzw. Anwender am meisten "beschützt" ist definitiv C#.

Die Sprache hingegen, die am meisten Freiheiten lässt, ist definitiv C++. :)

Ja, das schadet einem Akku definitiv.

Als Faustregel kannst du dir merken: Je schneller ein Akku geladen wird, desto stärker wird er belastet, was sich negativ auf die Lebensdauer auswirken wird.

Außerdem solltest du den Ladestand nicht unter 20% fallen lassen und nicht über 70% laden, um die Lebensdauer merklich zu verlängern.

Bernd heißt er. :)

Dadurch würde die Latenz enorm steigen und z. B. Videochats in Echtzeit unmöglich werden.

Einfach parenten!