Forum: PC-Programmierung Rust - ist das hier um zu bleiben?

Du hast die Frage nicht beantwortet.

Aber willst du offenbar nicht. Da empfiehlt man nun schon mal, dass die 
Leute stattdessen doch lieber gleich was anderes machen sollten, isses 
dir auch nicht recht.

MaWin schrieb:
> Gucke doch das Video.

Die 1,5 h Zeit würde ich, wenn schon, lieber in Rust investieren.

Aber solange du einfach nur bei persönlichen Beschimpfungen bleiben 
willst, was soll's?

cppbert schrieb:
> wenn es um C++2 geht - dann geht es eher darum das der Wechsel zwischen
> C++ und C++2 so absolut leicht und einfach sein soll wie möglich d.h. am
> besten 100% kompatibel

Das ist mir durchaus beim Ansehen des Videos (und der ja teils 
euphorischen Kommentare) klar geworden. Ich fürchte trotzdem, dass das 
nicht viel bringt, und dass es sinnvoller ist, es so wie Firefox zu 
machen und stückweise Subsysteme neu zu implementieren.

Dass das nicht von heute auf morgen gemacht ist, sieht man natürlich 
auch an Fifrefox.

cppbert schrieb:
> ja das Herb Sutter Beispiel ist ja nur ein Aufrüttler - was wäre wenn
> C++ sowas wie die Rust Editions hätte - was wäre möglich - Herb muss ja
> immer der am-weitesten-über-den-Tellerrand-schauer sein

Das wurde als 'Epochs' bereits von Vittorio Romero vorgeschlagen und 
soweit ich mich erinnern kann mit großer Mehrheit vom Komitee abgelehnt.

MaWin schrieb:
> Eines der größten Probleme mit C++ ist, dass es nicht mit Altlasten
> aufräumen kann.

Eben deshalb halte ich das für keine sonderlich zielführende Idee, da 
noch weiter dran herum zu ändern. C++ hat sowieso schon eine Unmenge an 
Veränderungen in den letzten Jahrzehnten erfahren, dass da kaum einer 
noch durchblickt.

Ich sehe einfach nicht, dass das die Welt retten würde.

MaWin schrieb:
> Aber würde es sie verschlechtern?

Ist halt die Frage: wenn du Leuten noch weniger Anreiz gibst, 
stattdessen andere Sprachen in Erwägung zu ziehen, ist das dann schon 
eine Verschlechterung?

MaWin schrieb:
> die niemand auf eine inkompatible Sprache umziehen wird

Es geht ja nicht um "umziehen" (vor allem nicht sofort), ich hatte 
Firefox als Beispiel genannt.

MaWin schrieb:
> Ganz ähnlich, wie man das bei der Migration von C zu C++ tun kann. (Wie
> z.B. gcc es getan haben). Der Erste Schritt ist: Keine Codeänderung. Nur
> neuer Compiler.

C ist kein Subset von C++. C++ Leuten, die versuchen C zu schreiben, und 
die Sprache nicht kennen, mag es vielleicht so vor kommen. Aber echte C 
Programmierer kennen die Sprache und nutzen ihr Potential voll aus. 
Einfach einen C++ Compiler nehmen geht da erfahrungsgemäss nur selten. 
Zumindest bei meinem Code geht das eigentlich nie. Da habe ich sowohl 
Sachen, die in C++ gar nicht kompilieren würden, als auch solche, die in 
C wohldefiniert, und in C++ ub sind.

Daniel A. schrieb:
> C ist kein Subset von C++

Dann lass mal hören welche Teile von C nicht in C++ enthalten sind.

Cyblord -. schrieb:
> Daniel A. schrieb:
>> C ist kein Subset von C++
>
> Dann lass mal hören welche Teile von C nicht in C++ enthalten sind.

https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B

Cyblord -. schrieb:
> Daniel A. schrieb:
>> C ist kein Subset von C++
>
> Dann lass mal hören welche Teile von C nicht in C++ enthalten sind.

Da gibt es ganz elementare Sachen.

z.B., wenn ich in C "struct bla" schreibe, dann ist nur "struct bla" 
definiert, aber bla nicht. Ich könnte dann sogar zeugs machen, wie 
"typedef int bla;", oder eine variable bla oder Funktion bla nennen, 
usw.

Ein anderes Beispiel sind compound literale. Und bevor du jetzt sagst, 
"C++ hat die jetzt auch", die haben dort zusätzliche Einschränkungen. In 
C spielt es keine rolle, in welcher Reihenfolge ich die Dinger 
initialisiere. In C++ schon.

Ein Klassiger sind auch die Cast regeln. "dingsbums* x = 
(dingsbums*)malloc(sizeof(*x));" ist in C ein absolutes noob no-go. Den 
cast lässt man gefälligst weg.

Ein Beispiel für etwas, das nicht nur anders funktioniert, sondern es 
nur in C gibt: _Generic.

Dann noch ein Beispiel, das in C gut funktioniert, aber in C++ ub ist:

1

#include <stdio.h>

2

#include <string.h>

3

static inline char* hello(char bla[13]){

4

  strcpy(bla, "Hello World!");

5

  return bla;

6

}

7

int main(){

8

  const char* msg = hello((char[16]){0});

9

  puts(msg); // In C ok, da das compound literal im block scope ist. In C++ ub, weil die Lifetime nach dem Funktionsaufruf zuende ist.

10

}

Ich hätte noch mehr Beispiele, aber das dürfte fürs erste mal reichen.

MaWin schrieb:
> Es geht darum bestehenden C++-Code mit Cpp2 zu übersetzen und Schritt
> für Schritt zu verbessern, bis man den Cpp2-only-Schalter umlegen kann.

Ich habe nur meine Zweifel, dass just diese Organisationen mit riesigen 
C++-Codebasen die nötigen Ressourcen dafür aufzuwenden bereit sind. Denn 
es kostet Ressourcen, das alles durchzugehen. Das sehen wir doch schon 
an so einfachen Beispielen wie Compilerwarnungen über Mischen von signed 
und unsigned. Welches größere Projekt macht sich nachträglich die Mühe 
(die ja insbesondere auch irgendeine Finanzierung benötigt), sowas zu 
reparieren?

Daniel A. schrieb:
> Ich hätte noch mehr Beispiele, aber das dürfte fürs erste mal reichen.

Das ist denk ich der Punkt: Es ist nicht das eine große Feature, das in 
C++ fehlt, sondern viele Feinheiten, die es inkompatibel machen. Man 
muss auch bedenken, dass C++ ursprünglich mal C89 als Basis hatte. 
Inzwischen hat sich auch C weiterentwickelt. Vieles davon wurde in C++ 
auch nachgezogen, aber nicht alles, und auch nicht alles exakt gleich.

MaWin schrieb:
> Rolf M. schrieb:
>> Das ist denk ich der Punkt
>
> Nein. Der Punkt war, dass das nur ein Beispiel war. Ein Vergleich.
> Große Projekte haben diese Migration geschafft.

Natürlich ist die Migration machbar. Alleine schon die Wortwahl 
"Migration geschafft" zeigt aber doch, dass es doch etwas mehr ist als 
das Ersetzen von "gcc" durch "g++" im Makefile. Je nach Projekt kann der 
Aufwand zwischen relativ gering und sehr hoch variieren. Gemacht habe 
ich das auch schon, und dabei habe ich eben gemerkt, dass da der Teufel 
oft im Detail steckt.

> Auch wenn die µC.net-Experten dies aufgrund der großen Unterschiede als
> praktisch unmöglich ansehen.

Das habe ich hier nirgends gelesen.

Nano schrieb:
> Die Frage ist,

… was willst du damit?

Fragt doch auch keiner nach einem C++-Compiler für CP/M. (Selbst 
C-Compiler für CP/M waren eher der Graus.)

Nicht einmal GCC läuft auf diesem ollen Krempel. DJ-GCC lief nur im 
32-Bit-Modus eines 80386.

cppbert schrieb:
> aber selbst C hat im Vergleich zu damaligen Assemblern schon viel mehr
> Resourcen gebraucht

Üblich war eine Diskette mit den Tools, eine zweite mit den Dateien 
(Quellcode, Zwischendateien). Dauerte natürlich in der Tat ewig.

Turbo-Pascal wurde seinem Namen dagegen gerecht, im Vergleich zu allen 
anderen Compilern der Zeit war es rasend schnell und brachte noch dazu 
die wohl erste IDE mit, die es gab. Im Vergleich zu heute dürfte die 
Optimierung nicht sonderlich großartig gewesen sein, aber für viele 
Fälle reichte es. Ich habe einen kompletten EPROMMer damit recht 
komfortabel bedient, nur die innere Schleife wurde dann durch 
handoptimierten Inline-Assembler ersetzt.

MaWin schrieb:
> Ziemlich sicher nicht.
> Heutige Sprachen sind überhaupt nur möglich, weil genug Rechenleistung
> und Speicher für die Compiler zur Verfügung stehen.
>
> Auch modernes C kann man mit einem modernen optimierenden Compiler nicht
> auf einer 8086 mit 640k RAM compilieren.

Forth (2012) könnte vielleicht auf 8086 mit 640k RAM  gehen. Auf die 
Schnelle habe ich dazu aber keine Infos gefunden, nur das gforth auf 386 
läuft. https://gforth.org/  Supported systems i386 und Gforth 
EC(embedded) auch auf 8086.

P.S. Das ist zwar off-topic. Aber das waren einige andere Beiträge 
vorher auch. :-)

Frühe Compiler bestanden aus mehreren Einzelprogrammen, von denen jedes 
einen Teilschritt des Compiliervorgangs durchführte, weil man alles 
zusammen nicht gleichzeitig in den Speicher bekam. Das hat's natürlich 
auch nicht gerade schnell gemacht, weil die Zwischenergebnisse natürlich 
immer erst abgespeichert und dann wieder geladen werden mussten. So sind 
moderne Compiler aber nicht mehr aufgebaut, daher funktionieren die auf 
Systemen mit so begrenzten Ressourcen nicht.

🐧 DPA 🐧 schrieb:
> Der GCC kann übrigens auch noch pipes zwischen Compiler und Linker
> verwenden.

Linker nicht, aber zwischen Compiler und Assembler.
Präprozessor früher noch, aber das ist kein separater Prozess mehr.

🐧 DPA 🐧 schrieb:
> So könnte man also theoretisch kompilieren und linken, ohne
> alles ins Dateisystem zu legen, und ohne alles auf einmal im RAM zu
> haben.

Das ist beim gcc normal, siehe -save-temps Option.

Wilhelm M. schrieb:
> Das ist beim gcc normal, siehe -save-temps Option.

-save-temps behält sie nur bei, erzeugt werden sie auch sonst.

Aber das dürfte bei heutigen Betriebssystemen und Speichergrößen oft 
keine Rolle mehr spielen, weil die Zwischendateien im Cache bleiben. 
Windows ist allerdings mit vielen Dateioperationen spürbar langsam, und 
wenn man dann noch einen Virenchecker hat, der sich auch noch alle 
Zwischendateien ansehen möchte, dann hat man die Po-Karte gezogen.

Moin,

Jörg W. schrieb:
> dann hat man die Po-Karte gezogen.

Wenn du ein Po-Kartenspiel hast, und du ziehst eine Karte...Was 
erwartest du dann? ;-)

scnr,
WK

Jörg W. schrieb:
> Aber das dürfte bei heutigen Betriebssystemen und Speichergrößen oft
> keine Rolle mehr spielen, weil die Zwischendateien im Cache bleiben.

Bei *nix werden temporäre Dateien unter /tmp erzeugt, was typischerweise 
ein tmpfs o.ä. ist, für das keine Persistenz verlangt wird.

Wilhelm M. schrieb:
> Bei *nix werden temporäre Dateien unter /tmp erzeugt, was typischerweise
> ein tmpfs o.ä. ist

So typisch ist das nicht. Auf den Systemen, wo ich arbeite, ist es ein 
ganz normales Dateisystem (bzw. Bestandteil von /). Trotzdem geht es 
schnell, weil der Krempel noch komplett im RAM verfügbar ist, wenn die 
nächste Phase ihn wieder lesen will. Daher bringt -pipe nicht mehr so 
viel, wie das noch vor 20 Jahren der Fall war.

Jörg W. schrieb:
> So typisch ist das nicht.

Dann sind Deine Systeme atypisch oder antiquarisch oder beides ;-)

Du meinst, zur Frage, ob der Rust-Compiler auch temp files anlegt und ob 
man schneller wird, wenn man sie durch eine Pipe ersetzt? ;-)

Gibt's eigentlich Geschwindigkeitsvergleiche zwischen *nix und Windows 
für den Rust-Compiler?

cppbert schrieb:
> zurück zum Thema, Burschen!

Ok, zweiter Versuch:
Was kann Rust besser als Forth? https://gforth.org/
:-)

Nano schrieb:
> Präprozessor
> Compiler
> Assembler
> Linker
> und gegebenenfalls noch
> EXE2BIN (war Bestandteil von MS-DOS, wurde manchem MS Compiler aber auch
> mitgeliefert)

Ich beziehe mich nur auf den Teil "Compiler". Dieser wurde in mehrere 
als getrennte Programme ausgeführte Einzelschritte zerlegt, wie z.B. 
lexikalische Analyse, Syntaxanalyse, Codegenerierung.

MaWin schrieb:
> Bei Rust gibt es nicht nur einen solchen Zwischenschritt (IR), sondern
> mehrere:

Wobei das jetzt eher ein Implementierungsdetail denn ein Sprachfeature 
sein dürfte, oder? Trifft man außerdem auch bei anderen Sprachen an. 
Lass mal den GCC mit -fdump-rtl-all laufen und erfreu dich dann an 
mehreren Dutzend Dateien, die die einzelnen Zwischenstufen 
repräsentieren. ;-)

MaWin schrieb:
> Bitte einfach einmal den verlinkten Artikel lesen.

Ändert nichts dran, dass da Implementierungsdetails beschrieben werden.

Nachdenklicher schrieb:
> Das Executable hat knapp 4 Megabyte.

Schau dir die Ausgabe von "size <filename>" an, nicht die Größe im 
Dateisystem.

1

$ cat helloworld.rs 

2

fn main() {

3

    // Statements here are executed when the compiled binary is called

4

5

    // Print text to the console

6

    println!("Hello World!");

7

}

8

$ rustc -O helloworld.rs

9

$ ./helloworld

10

Hello World!

11

$ size helloworld

12

    text    data   bss      dec       hex   filename

13

  307914   12864   273   321051   0x4e61b   helloworld

OK, Gegentest:

1

$ cat helloworld.c

2

#include <stdio.h>

3

4

int main(void) {

5

   printf("Hello, world!\n");

6

   return 0;

7

}

8

$ cc -O -o helloworld helloworld.c

9

$ ./helloworld 

10

Hello, world!

11

$ size helloworld

12

  text   data   bss    dec     hex   filename

13

  1839    409     8   2256   0x8d0   helloworld

Gut, etwas kleiner. :-)

1

$ cat helloworld.cc

2

#include <iostream>

3

4

int main(void) {

5

  std::cout << "Hello, world" << std::endl;

6

  return 0;

7

}

8

$ c++ -O -o helloworld helloworld.cc

9

$ ./helloworld 

10

Hello, world

11

$ size helloworld

12

  text   data   bss    dec      hex   filename

13

  4997    649   192   5838   0x16ce   helloworld

Aber so ist das mit Trivialbeispielen, sie sind völlig unrepräsentativ 
für die reale Welt.

307914 vs 1839.

Damit hat sich die Frage nach Rust für Embedded sowieso bereits 
erledigt. Wie schon vermutet, alles ein Phänomen im PC Bereich. Wo bei 
Speicher und Co. alles egal ist.
Wie soll man mit so einem Footprint C für den Microcontrollerbereich mit 
wenigen MB oder gar kB Flash ablösen? Utopie trifft Wahnvorstellung.

MaWin schrieb:
> Nö. Das ist ein reines PC-"Problem".

Ach so. Gibts denn so ein Beispiel dann auch mal für zwei lauffähige 
Binaries für sagen wie mal nen STM32F103?

> Da kann Rust nun beim besten Willen nichts für und kann da auch nichts
> dran ändern.

Wenn man nicht schwimmen kann, ist meistens nicht die Badehose schuld.

Nachdenklicher schrieb:
> Woran liegt das dann, frage ich mich?

An allen möglichen weiteren sections im ELF-File, also Symboltabellen 
und Debug-Infos.

Aber das ist doch für die praktische Anwendung komplett irrelevant: 
geladen wird das, was "size" dir anzeigt. Alles andere braucht Platz auf 
der Festplatte, mehr nicht.

Cyblord -. schrieb:
> 307914 vs 1839.

Lässt allerdings komplett außer acht, dass das natürlich hier alles 
dynamisch gelinkte Binaries sind, d.h. ein nicht zu vernachlässigender 
Anteil an Code liegt in den shared libs. Jedoch sind diese natürlich, so 
der Name, eben "shared", d.h. alle Anwendungen nutzen das gemeinsam. 
(Das wäre bei "deeply embedded", also MCUs, anders.)

Jörg W. schrieb:
> Lässt allerdings komplett außer acht, dass das natürlich hier alles
> dynamisch gelinkte Binaries sind, d.h. ein nicht zu vernachlässigender
> Anteil an Code liegt in den shared libs. Jedoch sind diese natürlich, so
> der Name, eben "shared", d.h. alle Anwendungen nutzen das gemeinsam.
> (Das wäre bei "deeply embedded", also MCUs, anders.)

Und was macht das C Programm hier anders als Rust? Und warum? Das muss 
ja auch auf dem bösen Windows laufen.

Oliver R. schrieb:
> Der Hauptgrund für die Binary-Größe auf Desktop-System ist die
> dazugelinkte Standard-Library.

Also ist die Standard Library für Rust nur bloat im Gegensatz zu der von 
C? Nochmal die Frage an dich: Warum hat ein C Programm unter Windows 
nicht die gleichen Probleme?

Oliver R. schrieb:
> Der Hauptgrund für die Binary-Größe auf Desktop-System ist die
> dazugelinkte Standard-Library.

Leuchtet allerdings dahingehend nicht ein, dass aus einer Library nur 
die Dinge gelinkt werden sollten, die auch tatsächlich benötigt werden.

Es werden wohl eher Dinge wie ein Laufzeitsystem sein, die das 
aufblähen. Da ist dann die Frage, wieviel dieses Overheads eher statisch 
sind (also auch bei großen Programmen annähernd gleich groß bleiben), 
oder ob da was "mitwächst".

Dass ein Helloworld kein sinnvoller Benchmark für die Größe eines 
erzeugten Binaries ist, sollte jedem klar sein.

Jörg W. schrieb:
> Dass ein Helloworld kein sinnvoller Benchmark für die Größe eines
> erzeugten Binaries ist, sollte jedem klar sein.

Warum das? Es gibt immerhin mal eine untere Grenze für die Binary Größe 
an.

MaWin schrieb:
> Weil es völlig egal ist, ob das 1 kB, 10 kB oder ein paar 100 kB sind,

Genau DAS ist eben die fatale Einstellung der Rusties.

Ich denke Rust hat fertig. Rust kann gehen.

Cyblord -. schrieb:
>> Dass ein Helloworld kein sinnvoller Benchmark für die Größe eines
>> erzeugten Binaries ist, sollte jedem klar sein.
>
> Warum das?

Weil es nichts sinnvolles macht.

> Es gibt immerhin mal eine untere Grenze für die Binary Größe an.

Nein, falls da wirklich printf drin ist (meist wird es der Compiler 
rauskicken), dann bläht das auch schon auf. Die untere Grenze wäre

1

int main(void) {

2

  return 0;

3

}

MaWin schrieb:
> Aber sie ist per default statisch gelinkt.

Siehe oben, das allein erklärt das nicht. Auch bei statischem Linken 
wird aus einer Bibliothek nur rausgezogen, was benötigt wird.

Es erscheint mir auch nach all den Beschreibungen über die Features von 
Rust völlig logisch, dass da etwas mehr an Laufzeitsystem dahinter 
steckt. Alle diese Überprüfungen, die nicht schon der Compiler machen 
kann, müssen ja schließlich irgendwo stecken. Das ist bei FORTRAN oder 
Pascal nicht anders.

Komplett statisches Linken von Rust-Binaries scheint aber schon einiges 
an Aufwand zu sein, sonst hätte ich den Vergleich mal probiert. (Das 
zuweilen dokumentierte -C target-feature=+crt-static generiert trotzdem 
noch ein dynamisch gelinktes Binary, weil die Systembibliotheken 
dynamisch bleiben.)

Jörg W. schrieb:
> Leuchtet allerdings dahingehend nicht ein, dass aus einer Library nur
> die Dinge gelinkt werden sollten, die auch tatsächlich benötigt werden.

Kannst gerne dran arbeiten, wenn es dich so stört.
Die Arbeit wird gerne angenommen.

Tipp: Auf Embedded-Rust ist das natürlich auch genau so, weil dort die 
stdlib im (LTO-)Build direkt mitgebaut wird statt dazugelinkt wird.
Das ist dann tatsächlich noch optimaler, als der C-Ansatz mit 
Link-Elision auf Funktionsbasis.

> Es werden wohl eher Dinge wie ein Laufzeitsystem sein, die das
> aufblähen.

Jörg wieder einmal wild am spekulieren.
Was soll das denn für ein Laufzeitsystem sein?

Oliver R. schrieb:
> Cyblord -. schrieb:
>> Warum hat ein C Programm unter Windows
>> nicht die gleichen Probleme?
>
> Z.B. weil Rust einen Panic-Handler verwendet, während ein C Programm
> sich im Fall eines Absturzes einfach nur beendet.

Ja und? Will ich jetzt aber nicht haben. Muss ich aber drin haben? 
Super.

Ich stelle mir das schon vor:
"Also Chef, wir brauchen den größeren und teureren Controller, weil Rust 
hat den Panic Handler immer mit drin. Was der bringt? Bei uns gar 
nichts. Ja ist halt trotzdem drin. Ok machen wir das Produkt teuer. Die 
Kunden haben ja auch was davon. Was genau? Äh Ich muss weg."

MaWin O. schrieb:
> Jörg W. schrieb:
>> Leuchtet allerdings dahingehend nicht ein, dass aus einer Library nur
>> die Dinge gelinkt werden sollten, die auch tatsächlich benötigt werden.
>
> Kannst gerne dran arbeiten, wenn es dich so stört.

Das Verhalten, aus einer Library nur das rauszuziehen, was benötigt 
wird, hat nichts mit der Sprache zu tun, sondern ist eine Eigenschaft 
des Linkers.

> Was soll das denn für ein Laufzeitsystem sein?

Ich dachte, dass du mir das erklären kannst.

Oliver R. hat ja zumindest einen Punkt gebracht, der in diese Richtung 
passt.

Cyblord -. schrieb:
> Ja und? Will ich jetzt aber nicht haben. Muss ich aber drin haben?

Nein.
Du kannst es soweit reduzieren, dass es nur ein abort()-Aufruf ist.
Deine Entscheidung.

Jörg W. schrieb:
> Ich dachte, dass du mir das erklären kannst.

Naja, du spekulierst hier wild herum über etwas, das es so nicht gibt.

MaWin O. schrieb:
> Nein.
> Du kannst es soweit reduzieren, dass es nur ein abort()-Aufruf ist.
> Deine Entscheidung.

Ah wieder mal was per default drin was kacke ist. I see.

Cyblord -. schrieb:
> Ah wieder mal was per default drin was kacke ist. I see.

Es ist kacke ein Programm bei einem fatalen Problem vernünftig zu 
beenden und eine vernünftige Fehlermeldung auszugeben?
Verstehe.

MaWin O. schrieb:
> Cyblord -. schrieb:
>> Ja und? Will ich jetzt aber nicht haben. Muss ich aber drin haben?
>
> Nein.
> Du kannst es soweit reduzieren, dass es nur ein abort()-Aufruf ist.
> Deine Entscheidung.

Dann zeig doch bitte mal, wie diese "deine Entscheidung" praktisch 
aussieht.

Das (primitive) Codebeispiel ist oben. copy&paste einfach mal die 
nötigen Compileroptionen und das Ergebnis (wieder als Ausgabe von 
"size"). Das überzeugt deutlich mehr als eine wortreiche Erklärung "kann 
man doch alles abschalten". Bitte schalte es mal ab.

MaWin O. schrieb:

> Es ist kacke ein Programm bei einem fatalen Problem vernünftig zu
> beenden und eine vernünftige Fehlermeldung auszugeben?
> Verstehe.

In den meisten Fällen bringt dir das gar nichts. Das Gerät geht halt 
nicht mehr. Egal welche Handler da angesprungen oder nicht angesprungen 
werden.

Jörg W. schrieb:
> Dann zeig doch bitte mal, wie diese "deine Entscheidung" praktisch
> aussieht.

Ach komm. Ist Google tatsächlich kaputt?
Das ist doch lächerlich.

Ich suche es jetzt garantiert nicht extra für dich raus, aber man muss 
ins Cargo.toml sowas wie panic=abort schreiben. Genauer habe ich es 
jetzt nicht im Kopf.

Cyblord -. schrieb:
> In den meisten Fällen bringt dir das gar nichts. Das Gerät geht halt
> nicht mehr. Egal welche Handler da angesprungen oder nicht angesprungen
> werden.

Genau deshalb schaltet man diesen Handler auf Embedded ja auch ab.
Wo ist eigentlich dein Problem?

Gibt es bei Rust für Embedded-Architekturen nicht irgendsowas wie 
-ffreestanding? Oder irgendwas um Teile der Laufzeitumgebung nicht 
mitzulinken?

Auf dem PC sind 3Mb Laufzeitgedöns vernachlässigbar (gesetzt dem Fall 
dass es nicht mitwächst und ein 100Mb-Exectuable auch nur 3Mb Bloat drin 
hat).
Embedded sind diese 3Mb natürlich ein NoGo.

Le X. schrieb:
> Gibt es bei Rust für Embedded-Architekturen nicht irgendsowas wie
> -ffreestanding? Oder irgendwas um Teile der Laufzeitumgebung nicht
> mitzulinken?

Selbstverständlich. Nennt sich

#![no_std]

Wurde natürlich auch schon gesagt.

Le X. schrieb:
> Embedded sind diese 3Mb natürlich ein NoGo.

Gegebene Antworten hier nicht so lesen ist für mich ein NoGo.
Ich wiederhole das jetzt nicht.

MaWin O. schrieb:

> Ach komm. Ist Google tatsächlich kaputt?
> Das ist doch lächerlich.

Ja, warum muss man ständig deine kruden Behauptungen selber googlen? 
Belege sie selbst oder nehme sie zurück.

> Ich suche es jetzt garantiert nicht extra für dich raus, aber man muss
> ins Cargo.toml sowas wie panic=abort schreiben. Genauer habe ich es
> jetzt nicht im Kopf.

Ja klar. Ist sicher echt trivial.

> Genau deshalb schaltet man diesen Handler auf Embedded ja auch ab.
> Wo ist eigentlich dein Problem?

Dass die Beispiele ständig zeigen dass es nicht brauchbar ist und du 
ständig behauptest man könne das alles auch anders haben, aber den 
Beweis schuldig bleibst und auf google verweist.
Argumentativ noch nackiger kann man sich ja nicht mehr machen als du 
hier gerade.

Cyblord -. schrieb:
> Belege sie selbst oder nehme sie zurück.

Ich werde weder das eine, noch das andere tun.
Stirb doch einfach dumm, Cyblord. Wie wäre das?

MaWin O. schrieb:
> Stirb doch einfach dumm, Cyblord. Wie wäre das?

Solange ich ohne Rust sterben darf ist alles ok.

MaWin O. schrieb:
> Jörg W. schrieb:
>> Dann zeig doch bitte mal, wie diese "deine Entscheidung" praktisch
>> aussieht.
>
> Ach komm. Ist Google tatsächlich kaputt?

Ich habe auch nicht auf Google verwiesen, sondern Beispiele gezeigt, die 
man per copy&paste nachvollziehen kann.

Aber lass man, helfen oder gar jemanden überzeugen willst du offenbar 
nicht.

Jörg W. schrieb:
> jemanden überzeugen willst du offenbar nicht.

Ganz gut erkannt.
Wenn du es nicht nutzen willst - und das willst du ganz offensichtlich 
nicht - dann lasse es halt.
Kein Problem.

MaWin O. schrieb:
> Ganz gut erkannt.
> Wenn du es nicht nutzen willst - und das willst du ganz offensichtlich
> nicht - dann lasse es halt.

Ich will es derzeit nicht nutzen (weil ich aktuell schlicht keine 
Anwendung für sowas habe). Ich mache aktuell auch bspw. kein C++.

Deshalb stecke ich jetzt auch keinen Aufwand da rein, aber es täte mich 
interessieren, und wenn ich das mal irgendwo gesehen habe, speichere ich 
mir solche Tricks gedanklich ab. Deshalb wäre ich daran interessiert, 
von jemandem, der damit täglich umgeht (und daher schneller ist als 
ich), sowas zu erfahren.

Von dir also offenbar nicht, dann lass es. Ich werde wohl lieber zu 
gegebener Zeit meinen Sohn danach fragen, das dürfte ergiebiger sein als 
so einen Sturkopf wie dich.

Sorry, musste mal raus.

Jörg W. schrieb:
> Deshalb stecke ich jetzt auch keinen Aufwand da rein

Ja, das merke ich.
Das ist natürlich sehr klug mir den Aufwand aufzubürden und mich die 
Dokumentation durchsuchen zu lassen.
Nur tue ich das nicht.

> Deshalb wäre ich daran interessiert,
> von jemandem, der damit täglich umgeht (und daher schneller ist als
> ich), sowas zu erfahren.

Ich habe dir alle Stichworte geliefert, mit denen du es findest.
Der Rest liegt an dir.

> das dürfte ergiebiger sein als so einen Sturkopf wie dich.

Du bist ein ziemlich unverschämter Mensch, der direkt bockig wird, wenn 
andere Leute nicht nach deiner Pfeife tanzen.

Damit musst du leider leben.

MaWin O. schrieb:
> Das ist natürlich sehr klug mir den Aufwand aufzubürden und mich die
> Dokumentation durchsuchen zu lassen.

Nun, du hast behauptet, dass du das schon gemacht hast, insofern nahm 
ich an, dass du nicht erst Google bemühen musst. Da lag ich wohl falsch.

Wenn ich ansonsten genauso "bockig" wäre, wie du das behauptest, glaubst 
du, ich würde hier alle nasenlang Leuten bei den Problemen helfen, bei 
denen ich mich gut auskenne?

Bei mir ergibt das Rust HelloWorld Beispiel:

1

$ size hello

2

text    data     bss     dec     hex filename

3

1780     616       8    2404     964 hello

Das C++ Beispiel ist unwesentlich kleiner:

1

$ size hellocc

2

text    data     bss     dec     hex filename

3

1046     608       8    1662     67e hellocc

Beides dynamisch gelinkt.

Wilhelm M. schrieb:
> Bei mir ergibt das Rust HelloWorld Beispiel:

Das sieht doch gut aus.

Kannst du jetzt noch die Build-Optionen dafür posten?

Jörg W. schrieb:
> Nun, du hast behauptet, dass du das schon gemacht hast, insofern nahm
> ich an, dass du nicht erst Google bemühen musst.

Richtig. Und ich habe ganz genau beschrieben, was ich gemacht habe und 
was ich noch im Kopf wusste.
Wo ist eigentlich dein Problem?
Statt hier mit mir zu diskutieren, hättest du schon lange "panic=abort" 
in Google eingeben können.
Das wäre vermutlich zu einfach gewesen.

Jörg W. schrieb:
> Wilhelm M. schrieb:
>> Bei mir ergibt das Rust HelloWorld Beispiel:
>
> Das sieht doch gut aus.
>
> Kannst du jetzt noch die Build-Optionen dafür posten?

1

rustc -C opt-level=z -C strip=symbols -C prefer-dynamic=yes hello.rs

Aber das haben die Rust-Experten hier ja sicher alles gewusst ;-)

Und statisch ist Rust und C++ auch wieder vergleichbar.

Moin,

OK, damit kommt dann bei mir, wenn man sich das executable mittels ldd 
anguckt, noch eine weitere shared-lib dazu, die dann halt den Krempel, 
der vorher das binary so aufgeblasen hat, beinhalten wird. Bei so einem 
genialen Namen wie dann hier dafuer verwendet wird, freu' ich mich schon 
arg auf interoperabilitaet.
Achja: Neben den ganzen lustigen, aber scheint's wohl etwas 
platzfressenden Gimmicks von rust wird natuerlich in allen Faellen 
immernoch zusaetzlich die libc gebraucht...

1

ldd hello

2

  linux-vdso.so.1 (0x00007ffe60353000)

3

  libstd-b5176101f2c4a3c2.so => /opt/rustc/lib/libstd-b5176101f2c4a3c2.so (0x00007f9a9bbac000)

4

  libc.so.6 => /usr/lib/libc.so.6 (0x00007f9a9b9aa000)

5

  libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f9a9b990000)

6

  /lib64/ld-linux-x86-64.so.2 (0x00007f9a9bd6a000)

Gruss
WK

Wilhelm M. schrieb:
> Und statisch ist Rust und C++ auch wieder vergleichbar.

Hast du denn Rust statisch bekommen? Ich nicht, libc war trotzdem noch 
dynamisch, und das Netz verweist auf MUSL (oder so ähnlich).

Dergute W. schrieb:
> Bei so einem
> genialen Namen wie dann hier dafuer verwendet wird, freu' ich mich schon
> arg auf interoperabilitaet.

Und deine konkrete Kritik ist jetzt was?

> von rust wird natuerlich in allen Faellen
> immernoch zusaetzlich die libc gebraucht...

Selbstverständlich nicht.
Aber das wurde hier mehrfach erklärt. Auch heute noch einmal. Deshalb 
wiederhole ich das jetzt nicht noch einmal.

Auf einem PC ist die libc halt de-facto die Schnittstelle zum 
Betriebsystem. Auf Windows ganz offiziell und auf Linux praktisch auch. 
Direkte Syscalls macht niemand.
Wenn man kein OS hat, dann braucht man die libc selbstverständlich 
nicht.
(Auf AVR braucht man sie derzeit nur, weil sie noch niemand rausgeworfen 
hat und die paar benötigten Features in Rust neuimplementiert hat.).

Dergute W. schrieb:
> OK, damit kommt dann bei mir, wenn man sich das executable mittels ldd
> anguckt, noch eine weitere shared-lib dazu, die dann halt den Krempel,
> der vorher das binary so aufgeblasen hat, beinhalten wird.

Das ist bei C++ auch so (und auch bei anderen Sprachen außer C). Nur C 
kommt (fast) nur mit der C-Lib aus.

Alles andere braucht auch die C-Lib, weil das auf den meisten Systemen 
das POSIX-API realisiert. Daher auch bei einem Rust executable.

Jörg W. schrieb:
> Wilhelm M. schrieb:
>> Und statisch ist Rust und C++ auch wieder vergleichbar.
>
> Hast du denn Rust statisch bekommen? Ich nicht, libc war trotzdem noch
> dynamisch, und das Netz verweist auf MUSL (oder so ähnlich).

Nicht vollständig wie bei C / C++ / ....
Das bezieht sich bei Rust nur auf die Bib von Rust selbst. Aber ich bin 
kein Rust Experte ...

Wenn ich mir ein

1

nm hello

ansehe, dann weiß ich auch, warm das dann so groß ist ;-)

Moin,

MaWin O. schrieb:
> Dergute W. schrieb:
>> Bei so einem
>> genialen Namen wie dann hier dafuer verwendet wird, freu' ich mich schon
>> arg auf interoperabilitaet.
>
> Und deine konkrete Kritik ist jetzt was?
Keine Kritik - ich schrieb doch: ich freue mich... :-)

> Aber das wurde hier mehrfach erklärt. Auch heute noch einmal. Deshalb
> wiederhole ich das jetzt nicht noch einmal.
Tschuldigung, ich bin da halt etwas begriffstutzig.

> Auf einem PC ist die libc halt de-facto die Schnittstelle zum
> Betriebsystem. Auf Windows ganz offiziell und auf Linux praktisch auch.
> Direkte Syscalls macht niemand.
> Wenn man kein OS hat, dann braucht man die libc selbstverständlich
> nicht.
> (Auf AVR braucht man sie derzeit nur, weil sie noch niemand rausgeworfen
> hat und die paar benötigten Features in Rust neuimplementiert hat.).
Axo. Selbstverstaendlich.
Wie kam ich nur auf das schmale Brett, das bei dem sicheren Rust 
vielleicht auch der ganze "unsichere, in boesem C geschriebene" Unterbau 
durch was eigenes, viel geileres, sichereres ersetzt worden haette sein 
koennen. Von der Groesse der "Rust-Laufzeitumgebung" vielleicht? 
Neeeein, ist sicher nur, weil ich halt so'n bissl langsamer im Denken 
bin.

Gruss
WK

Dergute W. schrieb:
> Neeeein, ist sicher nur, weil ich halt so'n bissl langsamer im Denken
> bin.

Gut erkannt.

cppbert schrieb:
> du wolltest noch erklären warum das Iterator-Konzept ein No-go für
> embedded ist

:-))

cppbert schrieb:
> das liegt primär daran das Rust die Standardlib statisch linked - auf
> embedded sieht das ganz ganz anders aus

Naja: dort wird alles statisch gelinkt (zumindest auf MCUs - auf MPUs 
läuft ja eher ein reguläres OS).

Jörg W. schrieb:
> Naja: dort wird alles statisch gelinkt

Es ist trotzdem ein Unterschied, weil bei Rust Embedded (beim normalen 
Arbeiten mit Cargo) die stdlib nicht vorkompiliert ist. Sie nimmt Teil 
an dem einen Gesamtbuild mit dem einen LTO.

Geht natürlich auch anders, wenn man will, aber sinnvoll ist es allemal 
das Gesamtkonstrukt zu optimieren und dann nichts mehr hinzu zu linken.

cppbert schrieb:
> Niemand hat gesagt das Rust und die komplette Tool-Chain 100% ausgereift
> ist

Das genügt den µC.net-Ansprüchen aber nicht.
Es muss alles perfekt sein. Erst dann kann die bekanntlich perfekte 
Sprache C abgelöst werden.
Da werden keinerlei Kompromisse eingegangen. :)

Außer bei den eigenen Kenntnissen. Da werden Kompromisse eingegangen bis 
hin zur völligen Abwesenheit.

> es geht hier (nach meiner Meinung) primär um die Sprache selbst

Ich finde es schon wichtig auch zu zeigen, dass zum Beispiel das 
Standard-Buildsystem Cargo praktisch allen anderen Buildsystemen 
haushoch überlegen ist.

Es funktioniert einfach sehr gut.
Selbstverständlich liegt das auch daran, dass es perfekt auf Rust und 
seinen Compiler zugeschnitten ist. Das ist klar.

cppbert schrieb:
> und wenn die GCC Leute ihr eigenes Frontend bauen sieht es da auch ganz
> anders aus

Ich denke nicht, dass es ganz anders aussieht.
Aber sicher wird man Aspekte der Sprache finden, über die sich bisher 
formell noch niemand Gedanken gemacht hat und die einfach so sind, weil 
rustc sie so implementiert. Das ist ja bereits so passiert und wird auch 
noch ein paar mal passieren.
Das führt aber dazu, dass die Sprache als Ganzes noch besser wird. 
Deshalb sind sowohl gccrs als auch codegen-gcc ganz wichtige Projekte.
Die Geschichte hat uns gelehrt, dass erst LLVM/clang wieder Leben in die 
damals völlig festgerostete gcc-Entwicklung gebracht hat.

> Announcing Rust 1.66.0

https://blog.rust-lang.org/2022/12/15/Rust-1.66.0.html

> Explicit discriminants on enums with fields

Ist manchmal ganz nützlich z.B. in Parsern oder Protokollinterpretern.
Jetzt auch mit komplexen enums.

> core::hint::black_box

Könnte nützlich sein für Embedded-Entwicklung.
Da ist tatsächlich oft das "Problem", dass es einem den Code komplett 
wegoptimiert, wenn man ihn nirgendwo verwendet. z.B. wenn man nur mal 
kurz schauen will, zu welchem Assembly ein Stück Code generiert war es 
oft notwendig die Ein- und Ausgaben zu diesem Code irgendwie über 
volatile-Zugriffe zu machen.
Das hier vereinfacht das sicher enorm.

> checked signed+unsigned operations

Das ist tatsächlich sehr nützlich und wird einige Programmteile deutlich 
verkürzen.
Rust verbietet normalerweise Operationen zwischen verschiedenen Typen. 
Deshalb muss man Typen konvertieren und dann natürlich Überlaufprüfungen 
usw. machen. Es gibt aber einige Funktionen, die einige dieser gängigen 
Operationen erleichtern und gleichzeitig safe halten.

> You can now use ..=X ranges in patterns.

Jo das ist gut. Weiß gar nicht, warum das so lange nicht stabil war :)

cppbert schrieb:
> ich meinte beim Bezug zum GCC auch nur das dort das Linken usw.
> default-Verhalten nicht unbedingt so sein muss wie beim Referenz-System
> rustc usw.

Achso. Ja.
Das Linken hat natürlich gar nichts mit rustc zu tun. Auch heute nicht. 
Das ist wie Cargo die Toolchain bedient. Deshalb denke ich aber schon, 
dass sich das nicht grundsätzlich unterscheiden wird. Jedenfalls nicht 
mehr, als es sich bei gcc vs clang unterscheidet.

Nano schrieb:
> Wenn das komplette Programm in den L1 Cache der CPU passt, macht das
> schon etwas aus, wenn es performancekritisch ist.

Wer kennt sie nicht, die performancekritischen Hello-World-Programme.

Außerdem: Lies mal nach, was Dateigröße, Sectiongröße und RAM-Belegung 
unterscheidet.
Es ist nicht mehr DOS.

Du fragst: Wo soll ich das lesen? Wo soll ich mich weiterbilden?
Die Antwort wird dich total überraschen: Hier im Thread! Heute!

Nano schrieb:
> Nö, das weiß ich. Wenn du das binary strippst, dann unterscheidet sich
> die ls Ausgabe nicht mehr groß von size.

Besser doch noch einmal hier nachlesen und sich weiterbilden.

Nano schrieb:
> Wie ich bereits sagte, muss ich das nicht, da ich das schon weiß.

Anscheinend ja nicht.

> Dein Problem ist, dass du Fakten nicht als gegeben hinnehmen willst.
> Wenn jemand Fakten liefert, dann greifst du die Person persönlich an.

Bitte einmal ein vollständiges Zitat liefern, wo ich das getan habe. Und 
zwar nicht als Reaktion auf einen vorhergehenden persönlichen Angriff 
(wie heute von unserem Herrn Moderator).
Danke.

Nano schrieb:
>> Anscheinend ja nicht.
> Du unterstellst mir Dinge

Du solltest einmal nachschlagen, was das Wort "anscheinend" bedeutet.

> Dich stört der Fakt, dass Assemblerprogramme kleiner sind als C oder
> Rust Programme.

Völliger Unsinn.

> Das könnte man jetzt als so gegeben hinnehmen und fertig.

Und warum tust du das dann nicht?

> Aber du kochst rot vor Wut

Ach? Habe ich gar nicht gemerkt.

> das einfach mal
> wertfrei und objektiv an das schwarze Brett zu hängen

Und für meine Antwort auf deinen Beitrag gelten diese Grundsätze nicht?

> Sprich, du hast Komplexe und noch ganz andere Probleme, komm
> mal klar.

Hm ja. Danke, Herr Psychologe, der auch sagt:

Nano schrieb:
> dann greifst du die Person persönlich an.

Aber du scheinst mich ja ziemlich gut zu kennen, denn

> Und jetzt nörgelst du daran herum, weil du streiten willst.

Du scheinst ein sehr angenehmer Zeitgenosse zu sein.

Nano schrieb:
>> Bla bla bla

Ganz schön wertfrei und objektiv, deine Antwort.
Danke dafür.