mikrocontroller.net

Forum: Compiler & IDEs Rust als Embedded-Programmiersprache


Autor: nga (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hallo zusammen,

hat jemand von euch schon einmal Erfahrung mit der Programmiersprache 
Rust im Embedded Umfeld (primär Cortex-M) gemacht? Gerade im Vergleich 
zu C oder C++ scheint es einige Vorteile zu geben.

Ich habe mir mit C und C++ schon öfters effizient in den Fuß geschossen, 
was gerade auf µCs oft nicht direkt auffällt, das es keinen SegFault wie 
auf dem PC gibt (Bitte keine Belehrungen dazu. Ich bin mir sicher, dass 
solche Dinge jedem schon einmal passiert sind... :-) ).

Rust vermeidet anscheinend ja effektiv Dangling Ponters und es gibt auch 
keine NULL-Pointer. Array-Bounds werden auch gecheckt. Das nimmt ja 
schon mal das meiste Gefahren-Potential.

Was ich mich noch frage: was passiert standardmäßig im Falle eines 
panic!()-Aufrufs?

Wie sieht es mit der Effizienz des erzeugtem Maschienencodes aus? Es 
wird ja LLVM benutzt, was ja schon einiges erwarten lässt (clang ist mWn 
auch ein LLVM-Frontend). Ich gehe stark davon aus, dass pure C/C++ eine 
kleinere Runtime hat (und damit erst einmal ein kleineres Binary), aber 
bei größeren Projekten sieht das evtl. anders aus (kann ich mangels 
einem solchen Projekt nicht testen).

Über Antworten freue ich mich.

Grüße,
nga

: Gesperrt durch Moderator
Autor: Kaj (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau mal hier:

Rust your ARM microcontroller!
http://blog.japaric.io/quickstart/

Vielleicht ist da ja was hilfreiches bei.

nga schrieb:
> Rust vermeidet anscheinend
Nicht nur anscheinend: es tut es. Der Preis dafuer ist halt eine 
laengere Compilierzeit. Man bekommt praktisch fuer alles einen Error, wo 
es in C/C++ noch nicht mal eine Warnung gibt bzw. nur, wenn man sie 
einschaltet.

Ausserdem muss man sich an ein paar Stellen eine neue Art der 
Programmierung angewoehnen, da man z.B. nicht mehrer Zeiger mit 
Schreibzugriff haben kann (ausser in unsafe {}), und das Borrowing 
erfordert auch ein umdenken.

Ich arbeite mich gerade selber in Rust ein, allerdings erstmal auf dem 
Desktop unter Linux. Ich will es dann aber auch auf ARM und AVR nutzen.

Autor: Achim S. (achs)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Kaj schrieb:
> wo es in C/C++ noch nicht mal eine Warnung gibt bzw. nur, wenn man sie
> einschaltet.

Ja, genau: für die allermeisten C-Probleme gibt es Warnungen, die man 
einschalten kann.... Und notfalls gibt es lint und Mists. Und Warnung 
als Error gibt's auch.

Beitrag #5513351 wurde von einem Moderator gelöscht.
Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Karl K. schrieb im Beitrag #5513351:

> Behalte Deinen C-Mist, hat keiner danach gefragt.

man man man, Turett-Syndrom, oder was? Hat er wohl nach gefragt:

wer schreibt:

> Gerade im Vergleich
> zu C oder C++ scheint es einige Vorteile zu geben.

fragt nach genau sowas.

Wobei, in so einem Fall C und C++ in einem Atemzug zu nennen, da ist 
schon klar, warum es beim programmieren zu Schüssen ins Bein kommt.

Und, mal ehrlich, wer wegen

> Array-Bounds werden auch gecheckt.

Meint eine neue Sprache lernen zu müssen ... Man könnte dann auch 
einfach (C++) gecheckte Zugriffe nehmen und fertig?

C und C++ hier in einem Atemzug zu nennen, klingt auch schon verdächtig. 
C++ und C haben eigentlich was Pointer angeht, nicht mehr viel 
gemeinsam. C++ mit Raw Pointern ist das selbe wie Rust mit Raw Pointern. 
Und null-Referenzen gibt es in C++ nicht.

Hat wirklich schonmal jemand mit -Wall und smart-Pointern Probleme mit 
dangling Pointers oder nullpointern gehabt? Das klingt für mich extrem 
exotisch.


Unabhängig davon macht Rust wirklich einen netten Eindruck und warum 
nicht, wenns Freude macht. Aber die vom TO vorgeschobenen C++ Probleme 
sind Quark.

vlg
 Timm

: Bearbeitet durch User
Autor: Karl K. (karl2go)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Timm R. schrieb:
> Meint eine neue Sprache lernen zu müssen ... Man könnte dann auch
> einfach (C++) gecheckte Zugriffe nehmen und fertig?

Es ist schon auffällig, dass hier im Forum in so ziemlich jedem Thread 
in dem eine andere Programmiersprache erwähnt wird die C-Freaks 
aufschlagen und erklären, wie toll ihr C ist und dass man das ja auch 
mit C könnte.

Ihr nervt!

Autor: Marian M. (mrhat2010)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Karl K. schrieb:
> Timm R. schrieb:
>> Meint eine neue Sprache lernen zu müssen ... Man könnte dann auch
>> einfach (C++) gecheckte Zugriffe nehmen und fertig?
>
> Es ist schon auffällig, dass hier im Forum in so ziemlich jedem Thread
> in dem eine andere Programmiersprache erwähnt wird die C-Freaks
> aufschlagen und erklären, wie toll ihr C ist und dass man das ja auch
> mit C könnte.
>
> Ihr nervt!

Timm sprach aber von C++ nicht von C

Autor: völlig egal (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Marian M. schrieb:
>> Es ist schon auffällig, dass hier im Forum in so ziemlich jedem Thread
>> in dem eine andere Programmiersprache erwähnt wird die C-Freaks
>> aufschlagen und erklären, wie toll ihr C ist und dass man das ja auch
>> mit C könnte.
>>
>> Ihr nervt!
>
> Timm sprach aber von C++ nicht von C

Nur mal so nebenbei als kleiner Seitenhieb: Egal ob er von C oder C++ 
sprach, war DAS nicht genau das, was einigen von euch immer so an Moby 
aufgestoßen ist, wenn er sein Assembler unerwartet in den Ring warf? Und 
warum stört euch der gleiche Vorgang plötzlich viel weniger oder gar 
nicht, wenn anstatt mit Assembler nun mit C oder C++ in eine 
Rust-Diskussion hineingegrätscht wird?

Kann es sein, dass hier gewisse verbreitete C, C++ Vorlieben zu einer 
deutlich höheren Toleranzschwelle gegenüber Störenfrieden führen?

Pharisäertum hier?

Autor: Marian M. (mrhat2010)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
völlig egal schrieb:
> Marian M. schrieb:
>>> Es ist schon auffällig, dass hier im Forum in so ziemlich jedem Thread
>>> in dem eine andere Programmiersprache erwähnt wird die C-Freaks
>>> aufschlagen und erklären, wie toll ihr C ist und dass man das ja auch
>>> mit C könnte.
>>>
>>> Ihr nervt!
>>
>> Timm sprach aber von C++ nicht von C
>
> Nur mal so nebenbei als kleiner Seitenhieb: Egal ob er von C oder C++
> sprach, war DAS nicht genau das, was einigen von euch immer so an Moby
> aufgestoßen ist, wenn er sein Assembler unerwartet in den Ring warf? Und
> warum stört euch der gleiche Vorgang plötzlich viel weniger oder gar
> nicht, wenn anstatt mit Assembler nun mit C oder C++ in eine
> Rust-Diskussion hineingegrätscht wird?
>
> Kann es sein, dass hier gewisse verbreitete C, C++ Vorlieben zu einer
> deutlich höheren Toleranzschwelle gegenüber Störenfrieden führen?
>
> Pharisäertum hier?

Ich verstehe worauf du hinaus willst, nur war es nicht meine Absicht C 
oder C++ besser als Rust darzustellen, ich hatte nur angemerkt, dass 
Timm von C++ und nicht von C gesprochen hat.

Persönlich empfinde ich es durchaus als Bereicherung eine weitere 
Sprache auf Controllern lauffähig zuhaben, nur sehe ich die 
Schwierigkeiten bei Rust darin wie bisheriger Code, welcher in C oder 
C++ geschrieben wurde, wiederverwendet werden kann. Bisher dachte ich, 
dass dazu dieser Teil des Projektes (zB eine Bibliothek) als unsafe 
eingebunden werden muss, was ja nicht der Weisheit letzter Schluss sein 
kann.

Sollte ich mich hier irren, könnten diejenigen bitte ein paar Beispiele 
verlinken, ich lerne durchaus gerne dazu ;)

Aber wenn man überlegt wie lange es gedauert hat bis sich C++ überhaupt 
in die Köpfe mancher embedded Entwickler eingeschlichen hatte, kann es 
gerade bei Rust noch Jahre dauern bis es zu einer nennenswerten 
Verbreitung kommt, aber eventuell gibt es ja dann doch ein paar 
Einflüsse die das beschleunigen könnten.

Autor: Rustecean (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Kaj schrieb:
> Schau mal hier:
>
> Rust your ARM microcontroller!
> http://blog.japaric.io/quickstart/
>
> Vielleicht ist da ja was hilfreiches bei.

Besser hier: https://rust-embedded.github.io/discovery/

Vom selben Autor, aber neuer, und damit auf dem aktuellen Stand... Xargo 
wird z. B. nicht mehr benötigt: 
https://users.rust-lang.org/t/cortex-m-library-dev...

Autor: Joe J. (j_955)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
[GELÖSCHT]

Will keinen Glaubenskrieg anzetteln.;-)

: Bearbeitet durch User
Autor: Ben W. (ben_w)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
hier ist noch ein kleiner fanboy von Rust im embedded Bereich :)
denke es hat sehr großes Potential.

Timm R. schrieb:
> Meint eine neue Sprache lernen zu müssen ... Man könnte dann auch
> einfach (C++) gecheckte Zugriffe nehmen und fertig?

korrigiere mich wenn ich falsch liege aber smartpointers etc. werden zur 
Laufzeit überprüft, während Rust versucht das ganze noch zur Compilezeit 
aufzulösen, was einen minimalistischeren Code ergeben sollte.

wenn man sich die Beispiele auf japarics blog anschaut, ist der 
generierte Assembler schon wirklich sehr effizient.

Klar kann ich sowas auch mit C und C++ erreichen aber mit wesentlich 
mehr Aufwand.
Für mich ist es eine einfache Kosten Nutzen Rechnung. Ich persönlich 
kann eher Rust lernen als C und/oder C++ so gut beherrschen um das 
gleiche zu erreichen.

Auf der embedded world 2018 habe ich den ersten Stand mit 
Dienstleistungen für Rust im embedded Bereich gesehen :)

für manche sachen wird wohl noch der nightly build vom Rust compiler 
benötigt,
mit dem Rust 2018 release (erwartet im Dezember) soll embedded targets 
out of the box unterstützt werden

nga schrieb:
> Was ich mich noch frage: was passiert standardmäßig im Falle eines
> panic!()-Aufrufs?
die cortex-rt crate kümmert sich darum. Default ist (glaube ich) es wird 
ein Fehler über semihosting oder SWO ausgegeben und anschließend eine 
endlosschleife betreten. Lässt sich aber auch umleiten auf z.B. einen 
UART oder so ...

Autor: Alexander B. (tecnologic) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ben W. schrieb:
> korrigiere mich wenn ich falsch liege aber smartpointers etc. werden zur
> Laufzeit überprüft, während Rust versucht das ganze noch zur Compilezeit
> aufzulösen, was einen minimalistischeren Code ergeben sollte.

Ich kann dich korrigieren :). C++ macht das bei std::array z.B. auch zur 
Compilezeit. Im Endeffekt wird auch in den aktuellen C++ Standards 
(11,14,17,21 ... ) viel auf solche Themen eingegangen. Der Punkt ist 
aber dass man sich es auch angewöhnen muss die STL in C++ Projekten zu 
nutzen und man sich sehr mit der Toolchain beschäftigen muss, weil es 
immer mal wieder Desktop Funktionalitäten gibt die man für embedded 
deaktivieren muss. (z.B. Exceptions, RTTI ...).

Daher kann ich es schon verstehen das einige hier den Weg über eine 
andere Sprache, die verspricht einem diese Fallstricke abzunehmen, gehen 
wollen.

Deshalb weiter so!

Ich wollte nur diese Diskussion "C++ kann das nicht aber Rust" 
entkräften. Das zeigt eigentlich schon was modernes C++ falsch macht. 
Die Leute wissen einfach nicht mehr was C++ alles kann und wie die 
Ganzen neuen Konstrukte funktionieren. Deshalb ist Rust vllt. wirklich 
die einfachere Alternative.

Gruß

Alex

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Lieber Karl,

Karl K. schrieb:

> Es ist schon auffällig, dass hier im Forum in so ziemlich jedem Thread
> in dem eine andere Programmiersprache erwähnt wird die C-Freaks
> aufschlagen und erklären, wie toll ihr C ist und dass man das ja auch
> mit C könnte.

Das Problem ist vielleicht auch, dass Du, weil du so genervt bist, 
einfach nicht liest? Der Ursprungs-Post ist – auch – ein C, C++ vs. Rust 
Post. Wenn der OP das nicht will, muss er einfach die Schlüsselwörter 
weglassen.

Zumal C++ vs. besonders "ansprechend" gestaltet ist, weil der OP 
nahelegt, dass er gar kein C++ kann, was das Ganze etwas grotesk macht.

Ich bin auch kein C Freak, noch nicht mal ein C++ Freak, du wirst auch 
von mir keinen einzigen Beitrag finden können, der die von Dir 
behaupteten Eigenschaften zeigt. Programmiersprachen sind Werkzeuge und 
keine Religionen.

Das C++ für embedded eine sehr heikle Sache sein kann, weil es schwierig 
ist, den Überblick zu behalten welche Features den Code blähen, ist 
bekannt und unbestritten.

Ich habe auch nicht das geringste gegen Rust einzuwenden, warum auch? 
Ich habe schonmal angefangen Rust zu lernen, zu der Zeit war aber noch 
nicht so viel los damit, ist aber auch schon was her.

Könnte sich denn vielleicht einer der Rust-kundigen und C++-kundigen 
erbarmen, mal ein minimales Beispiel mit c++ Pointer-Katastrophe zu 
zeigen und wie es in Rust besser läuft? Das wäre doch sicher für mehrere 
Rist-Unkundige interessant und erhellend? Mir fehlt da einfach die 
Vorstellungskraft.

vlg

Timm

: Bearbeitet durch User
Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Ben,

Ben W. schrieb:

> Timm R. schrieb:
>> Meint eine neue Sprache lernen zu müssen ... Man könnte dann auch
>> einfach (C++) gecheckte Zugriffe nehmen und fertig?
>
> korrigiere mich wenn ich falsch liege aber smartpointers etc. werden zur
> Laufzeit überprüft, während Rust versucht das ganze noch zur Compilezeit
> aufzulösen, was einen minimalistischeren Code ergeben sollte.

smart Pointer werden AFAIK gar nicht geprüft. Wenn ein smart Pointer 
null ist, gibts zur Laufzeit einen Knall. Sie verhindern nur böse Sachen 
wie:
    char* dp = NULL;
    {
        char c;
        dp = &c;
    }
    *dp = 42;

Was ja vermutlich so Szenarien sind, mit denen sich Anfänger in den Fuß 
schießen?

Bounds werden natürlich (ich weiße es nicht) in Rust genau so zur 
Laufzeit gecheckt, wie auch in C++. Das kann ja gar nicht anders gehen.

vlg
 Timm

: Bearbeitet durch User
Autor: Achim S. (achs)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Timm R. schrieb:
> Könnte sich denn vielleicht einer der Rust-kundigen und C++-kundigen
> erbarmen, mal ein minimales Beispiel mit c++ Pointer-Katastrophe zu
> zeigen und wie es in Rust besser läuft? Das wäre doch sicher für mehrere
> Rist-Unkundige interessant und erhellend?

Ja, das fände ich konstruktiv! Gerne auch in C. Und mit Angabe der 
Warnungen, die man dafür ausblenden muss oder nicht einschalten darf.

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für Rust benötigt man meines Wissens nach LLVM, die Auswahl an Backends 
ist dort aber noch überschaubar. Momentan setze ich (je nach 
Verfügbarkeit) auf GCC und SDCC, was wegen dem SDCC schon C++ 
ausschließt. Es gibt zwar genügend Anleitungen, um eigene Backends für 
LLVM zu schreiben, aber das ist ein Aufwand, den ich mir nicht antun 
möchte.

Autor: rostiger Nagel (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Also ich weiß nicht, geht das hier nicht 'schöner'?:
// Send a single character
    usart1.tdr.write(|w| w.tdr().bits(u16::from(b'X')));

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich habe mich bisher nur wenig mit Rust beschäftigt, halte es aber für
eine der interessantesten Programmiersprachen aus jüngerer Zeit.

Rust verfolgt ähnliche Ziele wie C++, nämlich relativ hohe Abstraktion
mit minimalem bis gar keinem Laufzeit-Overhead.

Mein Eindruck ist, dass alle wesentlichen Features von C++ in Rust
ebenso verfügbar sind oder aber durch mindestens gleichwertige andere
Features ersetzt wurden. Da diese Features bereits frühzeitig in das
Sprachkonzept eingeflossen sind und nicht, wie in C++, über viele Jahre
verteilt, ist Rust (zumindest derzeit noch) trotz seiner Mächtigkeit
eine recht schlanke Sprache ohne Kompatibilitätsaltlasten.

Wenn ich demnächst etwas mehr Zeit habe, werde ich versuchen, meine
Rust-Kenntnisse etwas zu vertiefen und in kleineren Hobbyprojekten
anstelle von C oder C++ zu nutzen.

Timm R. schrieb:
> Könnte sich denn vielleicht einer der Rust-kundigen und C++-kundigen
> erbarmen, mal ein minimales Beispiel mit c++ Pointer-Katastrophe zu
> zeigen und wie es in Rust besser läuft?

Hier ist ein kleines Beispiel von Steve Klabnik:

  https://github.com/steveklabnik/uniq_ptr_problem

Autor: mh (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ich habe keine Ahnung von rust und habe daher nichts zum eigentlich 
Thema zu sagen.

Aber zu diesem Link kann ich etwas sagen.
Yalu X. schrieb:
> Hier ist ein kleines Beispiel von Steve Klabnik:
>
>   https://github.com/steveklabnik/uniq_ptr_problem

Eine ganze Seite "Seite", die mit dem Ziel:
While it's true that C++'s smart pointers are a huge leap forward, they aren't actually safe in all cases. I always forget what the exact cases are, so I made this page to remind myself.
erstellt wurde, enhält genau ein Beispiel und dieses eine Beispiel ist 
trivial und sollte für jeden offensichtlich sein, der verstanden hat was 
ein unique_ptr und was move-Semantik ist.

Es ist kein Beispiel für Probleme mit smart-Pointern in c++, sondern 
eher für Probleme mit der move-Semantik. Probleme die rust anscheinend 
auch hat, wie man der gleichen Seite entnehmen kann. Ok bei rust gibt 
der Compiler eine Meldung aus, die man aber auch in c++ bekommt, wenn 
man clang-tidy benutzt.

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Yalu,

ja, ich denke, das Beispiel ist gültig. Danke!

Der Claim ist ja gerade, dass Rust sich wie ein erfahrener Ratgeber 
verhält und verhindert, dass man (aus versehen) blöde Dinge tut.

Die Move Semantik ist scheinbar so eindeutig, dass der Compiler diesen 
Fehler verhindern kann, das ist ein Beleg für den Claim.

Natürlich kommt das zu einem Preis, natürlich kann man sagen, dass das 
echt ein saublöder Fehler ist, den erfahrene Programmierer nie machen 
würden, aber darum geht es ja gerade. Unfälle passieren, weil man 
unachtsam blöde Dinge tut.

Vermutlich warnt der C++ Compiler nicht, weil std::move ja nicht move 
heißt, sondern nur move versuchen und was genau passiert, weiß man 
nicht. Bei einem anderen Typ könnte das Beispielprogramm problemlos 
laufen. Andererseits ist bei std::unique_ptr klar, dass das Programm 
fehlerhaft ist und er könnte sehr wohl warnen, wenn er wollte.

Wie auch immer: Wenn die Priorität auf dangling Pointer um jeden Preis 
vermeiden liegt, hat Rust hier einen Punkt gemacht.

Finde ich.

vlg

Timm

P.S. Ich glaube mich persönlich holt das Beispiel jetzt nicht so ab, 
denn es zeigt ja nichts unerwartetes oder spezielles, genau so wie in 
dem Beispiel soll es ja sein, trotzdem ist der Rest-flavour des Themas 
natürlich einsteigerfreundlicher, eindeutiger und sicherer.

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nga schrieb:
> Ich habe mir mit C und C++ schon öfters effizient in den Fuß geschossen,
> was gerade auf µCs oft nicht direkt auffällt, das es keinen SegFault wie
> auf dem PC gibt

Den gibt es schon, heißt nur HardFault und führt normalerweise zu einem 
Reset. Unterbindet man das (z.B. durch einen eigenen HardFault-Handler), 
dann unterscheidet er sich nicht besonders von seinem PC-Pendanten. 
Weglaufende Pointer fängt man damit relativ gut ein.

nga schrieb:
> Rust vermeidet anscheinend ja effektiv Dangling Ponters und es gibt auch
> keine NULL-Pointer. Array-Bounds werden auch gecheckt. Das nimmt ja
> schon mal das meiste Gefahren-Potential.

Die meisten Gefahren kann man auch in C++ relativ zuverlässig 
verhindern, wenn man ein Stück weit von C weggeht. Referenzen sind z.B. 
oft eine gute Alternative zu Pointern und niemals NULL. Mit range-based 
for-loops lässt sich gut über Container iterieren, ohne dabei 
Arraygrenzen zu überschreiten (reduziert für mich einiges an 
Gefahrenpotential).

Viele (aber nicht alle) Array-Bounds lassen sich auch zur Compilezeit 
prüfen, und wenn man die überschreitet, gibt es nette Warnungen. Das ist 
alles nicht mehr so schlimm wie vor einigen Jahren.

Ansonsten haben die meisten modernen Sprachen ähnliche Features, z.B. 
muss man in Kotlin alle Variablen, die NULL sein können, entsprechend 
annotieren und den NULL-Fall auch durchgängig abfangen.

nga schrieb:
> Wie sieht es mit der Effizienz des erzeugtem Maschienencodes aus? Es
> wird ja LLVM benutzt, was ja schon einiges erwarten lässt (clang ist mWn
> auch ein LLVM-Frontend).

Die LLVM-Backends für x86 und ARM sind relativ gut, davon abgesehen wird 
es eher dünn. Clang ist das C/C++-Frontend für LLVM, es gibt aber noch 
sehr viele andere - wie eben z.B. für Rust.

Kaj schrieb:
> Man bekommt praktisch fuer alles einen Error, wo es in C/C++ noch
> nicht mal eine Warnung gibt bzw. nur, wenn man sie einschaltet.

Wer C/C++ mit weniger als "-Wall" benutzt, hat sämtliche daraus 
resultierenden Fehler selbst zu verantworten. Es sei denn, man gehört 
auch sonst zu denjenigen, die sich überall die Ohren zuhalten, um ja 
nicht ihre Realität hinterfragen zu müssen. :-)

Kaj schrieb:
> Ich arbeite mich gerade selber in Rust ein, allerdings erstmal auf dem
> Desktop unter Linux. Ich will es dann aber auch auf ARM und AVR nutzen.

Für ARM ist das vermutlich kein Problem, aber auf dem AVR kannst du das 
Thema vergessen. Selbst, wenn du es einigermaßen zum Laufen bekommst, so 
ist der LLVM-Support dafür eher mäßig.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Es ist kein Beispiel für Probleme mit smart-Pointern in c++, sondern
> eher für Probleme mit der move-Semantik.

Es ist ein Beispiel dafür, dass nach einem Move das betreffende Objekt
fehlerhafterweise weiter benutzt wird.

Der Rust-Compiler erkennt diesen Fehler garantiert, ein C++-Compiler
nicht unbedingt.

> Ok bei rust gibt der Compiler eine Meldung aus, die man aber auch in
> c++ bekommt, wenn man clang-tidy benutzt.

Ist das bei clang-tidy wirklich garantiert, auch in verzwickteren
Fällen? Mit welchen Optionen muss ich clang-tidy aufrufen, damit in
folgendem Beispiel der Fehler erkannt wird:

#include <iostream>
#include <memory>

void sub(std::unique_ptr<int> *up) {
  auto stolen = std::move(*up);
}

int main () {
  std::unique_ptr<int> orig(new int(5));
  std::cout << *orig << '\n';
  sub(&orig);
  std::cout << *orig << '\n';
}

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Yalu,

guter Punkt!
Wobei ich da doch eine Referenz bevorzugt hätte, als die altmodische C 
Variante, aber das ändert natürlich rein garnichts.

vlg

Timm

: Bearbeitet durch User
Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Timm R. schrieb:
> Wobei ich da doch eine Referenz bevorzugt hätte, als die altmodische C
> Variante, aber das ändert natürlich rein garnichts.

Ich hatte ursprünglich eine Referenz verwendet, diese wurde aber von
clang-tidy angemeckert, weil ich mit -checks=* einfach mal blind alle
verfügbaren Prüfungen – und damit auch "google-runtime-references" –
aktiviert hatte:

  https://google.github.io/styleguide/cppguide.html#...

> Eine Nachfrage: Kann ich in Rust das Äquivalent zu std::move auf Objekte
> anwenden, die nicht bewegbar sind?

Wie gesagt, ich bin noch sehr grün in Sachen Rust, weswegen ich diese
Frage nicht beantworten kann. Ich habe sie möglicherweise aber auch gar
nicht verstanden, oder warum sollte ein nicht bewegbares Objekt gemovet
(also bwegt) werden können? Das wäre doch ein Widerspruch in sich?

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> mh schrieb:
>> Es ist kein Beispiel für Probleme mit smart-Pointern in c++, sondern
>> eher für Probleme mit der move-Semantik.

Die Seite selbst behauptet aber, dass es ein Beispiel ist für "c++ 
smart-Pointer sind unsicher".

Yalu X. schrieb:
> ...folgendem Beispiel...
Ein raw-Pointer auf einen unique_ptr ... zum Glück ist es nur ein 
Beispiel. Wer sowas macht hat keine Warnung vom Compiler verdient ;-) .

Yalu X. schrieb:
> Ist das bei clang-tidy wirklich garantiert, auch in verzwickteren
> Fällen?
Nein. Ist es in rust garantiert?
Wie würde die folgende Funktion (zum Glück auch nur ein Beispiel) in 
rust aussehen und was sagt der Compiler, wenn er f1 und f2 nicht zur 
Compilezeit kennt?
std::unique_ptr<int> func(bool f1, bool f2, std::unique_ptr<int> &up) {
  std::unique_ptr<int> tmp;
  if(f1) {
    tmp = std::move(up);
  } else {
    tmp = std::unique_ptr<int>(new int(6));
  }
  if(f2) {
    std::cout << *up << std::endl;
  }

  return tmp;
}
Verbietet er die Funtkion, gibt er eine Warnung aus (clang-tidy 
bugprone*) oder macht er etwas anderes?

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:

> Verbietet er die Funtkion, gibt er eine Warnung aus (clang-tidy
> bugprone*) oder macht er etwas anderes?

also ich habe keinen Schimmer von Rust, möchte aber gern eine Wette 
abgeben: Er verbietet es. Sonst würde imho das ganze Gezeter keinen Sinn 
ergeben.

Die Idee ist doch gerade, nur zuzulassen, was auch klappt, wenn der 
Entwickler nicht das falsche Gras geraucht hat. Dein Code kann aber in 
die Hose gehen. Also wette ich auf: Error.

Was ich dann auch nur folgerichtig und gut fände.

vlg
 Timm

: Bearbeitet durch User
Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kann hier jemand Rust? Könnte mir zufällig mal schnell jemand dies hier 
rosten? Die Definition von measure<> habe ich weggelassen, die wird man 
eh nicht 1:1 rosten können, ist aber auch egal. Ich würde gern mal damit 
in Tust experimentieren.

Ich würde es selbst versuchen, aber diese borrow mut Referenzen 
Geschichte, wäre nur trial & error.

vlg

 Timm
void mv2(std::vector<size_t>& a, std::vector<size_t>& b) {
    for(size_t i=0; i<100000; i++)
    {
        a = std::move(b);
        a[i]=42;
        b = std::move(a);
    }
}


int main(int argc, const char * argv[]) {
    std::vector<size_t> a{33, 100000};
    std::vector<size_t> b{34, 100000};
    auto timing = measure<std::chrono::microseconds>::execution(mv2, a, b);
    std::cout << b[100000-1] << " Zeit: " << timing << " µs" << std::endl;
    return 0;
}

: Bearbeitet durch User
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Yalu X. schrieb:
>> Ist das bei clang-tidy wirklich garantiert, auch in verzwickteren
>> Fällen?
> Nein. Ist es in rust garantiert?

Selbstverständlich. Es ist Teil der Sprachdefinition, ein Verstoß gegen 
die Ownership-Regeln könnte nicht kompiliert werden, es wäre ungültiger 
Code und der Compiler würde mit Fehler abbrechen.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> mh schrieb:
>> Yalu X. schrieb:
>>> Ist das bei clang-tidy wirklich garantiert, auch in verzwickteren
>>> Fällen?
>> Nein. Ist es in rust garantiert?
>
> Selbstverständlich. Es ist Teil der Sprachdefinition, ein Verstoß gegen
> die Ownership-Regeln könnte nicht kompiliert werden, es wäre ungültiger
> Code und der Compiler würde mit Fehler abbrechen.

In c++ gibt es nur im Fall f1=true f2=true ein Problem. Die drei anderen 
Fälle sind in Ordnung. Für rust ist das egal und es ist verboten?

Wo in der "Sprachdefinition" sind diese Ownership-Regeln definiert? Das 
was unter 
https://doc.rust-lang.org/stable/reference/memory-... steht 
ist nun wirklich nicht hilfreich.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
fn func(f1: bool, f2: bool, up: Box<i32>) -> Box<i32> {
    let mut tmp = Box::new(0);
    if f1 {
        tmp = up;
    }
    if f2 {
        println!("{}", up)
    }
    tmp
}

fn main() {
    let x = Box::new(42);
    func(true, true, x);
}
error[E0382]: use of moved value: `up`
 --> src/main.rs:7:24
  |
4 |         tmp = up;
  |               -- value moved here
...
7 |         println!("{}", up)
  |                        ^^ value used here after move
  |
  = note: move occurs because `up` has type `std::boxed::Box<i32>`, which does not implement the `Copy` trait

error: aborting due to previous error

For more information about this error, try `rustc --explain E0382`.
error: Could not compile `untitled2`.

To learn more, run the command again with --verbose.

Process finished with exit code 101

Autor: Kaj (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Wo in der "Sprachdefinition" sind diese Ownership-Regeln definiert?
Da:
https://doc.rust-lang.org/book/second-edition/ch04...
Ownership Rules

First, let’s take a look at the ownership rules. Keep these rules in mind
as we work through the examples that illustrate them:

    Each value in Rust has a variable that’s called its owner.
    There can only be one owner at a time.
    When the owner goes out of scope, the value will be dropped.


Autor: Kaj (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> aber auf dem AVR kannst du das Thema vergessen.
Warum? An dem Projekt wird aktiv gearbeitet: 
https://github.com/avr-rust/

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaj schrieb:
> mh schrieb:
>> Wo in der "Sprachdefinition" sind diese Ownership-Regeln definiert?
> Da:
> https://doc.rust-lang.org/book/second-edition/ch04...
Interessant, dass die Regeln nicht in der "The Rust Reference" stehen, 
sonder unter "Learning Rust".

Bernd K. schrieb:
> func(true, true, x);
Bei false false sagt er leider das gleiche.

Kaj schrieb:
> Ownership Rules
>
> First, let’s take a look at the ownership rules. Keep these rules in
> mind
> as we work through the examples that illustrate them:
>
>     Each value in Rust has a variable that’s called its owner.
>     There can only be one owner at a time.
>     When the owner goes out of scope, the value will be dropped.
Also für den false false Fall ist nach den Regeln alles in Ordnung.
Hat nen Owner.
Es gibt nur einen Owner.
Ist im Scope.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Also für den false false Fall ist nach den Regeln alles in Ordnung.
> Hat nen Owner.

Aber es könnte zur Laufzeit beide Fälle geben und deshalb ist der Code 
in dieser Form ungültig und kann nicht kompiliert werden.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> mh schrieb:
>> Also für den false false Fall ist nach den Regeln alles in Ordnung.
>> Hat nen Owner.
>
> Aber es könnte zur Laufzeit beide Fälle geben und deshalb ist der Code
> in dieser Form ungültig und kann nicht kompiliert werden.

Ok, es sollte also gehen, wenn man den Fall true true verhindert:
    if f2 & (f1 == false) {
        println!("{}", up)
    }
Leider immer noch die gleiche Meldung.

Autor: Jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Bernd K. schrieb:
>> mh schrieb:
>>> Also für den false false Fall ist nach den Regeln alles in Ordnung.
>>> Hat nen Owner.
>>
>> Aber es könnte zur Laufzeit beide Fälle geben und deshalb ist der Code
>> in dieser Form ungültig und kann nicht kompiliert werden.
>
> Ok, es sollte also gehen, wenn man den Fall true true verhindert:    if
> f2 & (f1 == false) {
>         println!("{}", up)
>     }
> Leider immer noch die gleiche Meldung.

Habe keine Ahnung von Rust, aber ich vermute es wird wie in anderen 
Sprachen auch behandelt: Wenn der Ausdruck nicht garantiert (unabhängig 
vom tatsächlichen Ausdruck!) während des Kompilierens ausgewertet werden 
kann, ist er so zu behandeln, als wäre das Ergebnis nur zur Laufzeit 
bekannt.
Das vereinfacht die Implementation und sorgt für konsistentes Verhalten.
Für mich ist das überhaupt nicht überraschend.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Leider immer noch die gleiche Meldung.

Man kann den Code auch so schreiben daß sich das Problem gar nicht erst 
stellt.
fn func(f1: bool, f2: bool, up: Box<i32>) -> Box<i32> {
    if f2 {
        println!("{}", up)
    }

    if f1 {
        up
    } else {
        Box::new(0)
    }
}

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Wo in der "Sprachdefinition" sind diese Ownership-Regeln definiert? Das
> was unter
> https://doc.rust-lang.org/stable/reference/memory-... steht
> ist nun wirklich nicht hilfreich.

Das Reference-Dokument ist leider noch sehr unvollständig, was den
Autoren aber bewusst ist:

For now, this reference is a best-effort document. We strive for
validity and completeness, but are not yet there. In the future, the
docs and lang teams will work together to figure out how best to do
this. Until then, this is a best-effort attempt. If you find something
wrong or missing, file an issue or send in a pull request.

Zudem scheint die Sprachdefinition in einigen Punkten ohnehin noch im
Fluss zu sein.

Was die Regeln zur Überprüfung des Verlusts der Ownership betrifft, ist
der Compiler eher pessimistisch. Selbst in diesem Fall

  let a = Box::new(123);
  if false {
    let b = a;
  }
  print!("{}\n", a);

meckert der Compiler, obwohl es offensichtlich ist, dass der if-Zweig
nie ausgeführt wird.

Bei der Prüfung wird also wohl davon ausgegangen, dass jede if/while-
Bedingung unabhängig von dem tatsächlichen Ausdruck und unabhängig von
allen anderen if/while-Bedingungen einen beliebigen Wahrheitswert
annehmen kann. Wenn es unter dieser Annahme einen Pfad gibt, der zum
Zugriff auf ein nicht geowntes Objekt führt, wird ein Fehler ausgegeben.

Diese Regel erscheint auf den ersten Blick unnötig pessimistisch. Wenn
aber etwas darüber nachdenkt, kann man die Entscheidung durchaus
verstehen:

- Der Compiler sollte eher zu pessimistisch als zu optimistisch sein, so
  dass auf keinen Fall eine Verletzung der Ownership akzeptiert wird.
  Denn das würde das ganze schöne Konzept über den Haufen schmeißen.

- Ein perfekter Algorithmus zum Aufspüren von Verletzungen in beliebig
  komplizierten Code existiert nicht, da dieses Problem ebenso wenig
  entscheidbar ist wie das Halteproblem. Das Regelwerk muss also zu
  einem gewissen Grad pessimistisch sein.

- Es stellt sich nun die Frage, ob man

  - ein nahezu optimales, dafür aber sehr komplexes, oder

  - ein weniger optimales, dafür aber einfaches Regelwerk bevorzugt.

  Die Rust-Entwickler haben sich offensichtlich für die zweite Option
  entschieden. Das ist IMHO auch gut so, denn die Koplexität des
  Regelwerks betrifft ja nicht nur die Compilerbauer, sondern jeden
  Rust-Programmierer.

Ich vermute, dass in realem Code die Fälle, wo der Compiler einen Fehler
meldet, obwohl bei genauerer Analyse keine Verletzung der Ownership
vorliegt, sehr selten sind. Sollte dieser Fall dennoch einmal auftreten,
kann das Problem sicher durch eine leichte Umstrukturierung des Codes
behoben werden, was den angenehmen Nebeneffekt hat, dass der Code etwas
entworren wird.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Ich habe mich bisher nur wenig mit Rust beschäftigt, halte es aber für
> eine der interessantesten Programmiersprachen aus jüngerer Zeit.

Ebenso. Es erscheinen regelmäßig neue Sprachen auf der Bildfläche die 
einen nicht wirklich vom Hocker reißen und keine wirklich neuen Konzepte 
einführen und verschwinden bald wieder in der Versenkung aber nur alle 
paar Schaltjahre taucht mal ein Stern am Programmiersprachenhimmel auf 
der sich wirklich von der Masse abhebt.

Und dann auch noch eine Sprache deren Kompilat ohne Runtime auskommt und 
damit in direkte Konkurrenz mit C(++) tritt und somit auch für kleinste 
µC interessant ist, solche Sprachen kann man fast an einer Hand 
abzählen.

Rust steht mittlerweile auch bei mir ganz oben auf meiner Liste der 
Sprachen in die ich gerne etwas tiefer einsteigen will.

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
>
> Und dann auch noch eine Sprache deren Kompilat ohne Runtime auskommt

Hallo,

sorry, kann mir jemand erklären, was das bedeutet? Heißt das, man kann 
Rust nicht dynamisch linken? Warum ist das gut?

Viele liebe Grüße
timm

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Timm R. schrieb:
> Bernd K. schrieb:
>>
>> Und dann auch noch eine Sprache deren Kompilat ohne Runtime auskommt
>
> Hallo,
>
> sorry, kann mir jemand erklären, was das bedeutet?

Bernd mein vermutlich so etwas wie bei Java oder C#, wo man ein
Riesenpaket an Bibliotheken und sonstigem Gedöns installieren muss,
bevor man die erste kleine Anwendung starten kann.

> Heißt das, man kann Rust nicht dynamisch linken?

Doch, das geht schon.

Auf Plattformen ohne Betriebssystem gibt es aber meist weder einen
dynamischen Linker noch ein Filesystem, vom dem die dynamischen
Bibliotheken geladen werden können. Da möchte man die komplette
Anwendung mit allem, was dazugehört, statisch in ein einziges Executable
linken.

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Timm R. schrieb:
>> Bernd K. schrieb:
>>>
>>> Und dann auch noch eine Sprache deren Kompilat ohne Runtime auskommt
>>
>> Hallo,
>>
>> sorry, kann mir jemand erklären, was das bedeutet?
>
> Bernd mein vermutlich so etwas wie bei Java oder C#, wo man ein
> Riesenpaket an Bibliotheken und sonstigem Gedöns installieren muss,
> bevor man die erste kleine Anwendung starten kann.

ach soo! Alles klar, danke. Ich dachte, das ginge gegen c/c++ und das 
ist ja wirklich mal eine Stelle, wo bei c/c++ alles proper ist.

vlg und danke
Timm

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Timm R. schrieb:
> Hallo,
>
> sorry, kann mir jemand erklären, was das bedeutet?

Nein, das bedeutet daß Rust (genau wie C oder C++ auch) sich gut für 
bare metal eignet, weil es zu nativem Code kompiliert der läuft ohne 
viel mehr als nur sich selbst zu benötigen, man kann große Teile der 
Standard Library welche dynamische Speicherallokation benutzen einfach 
weglassen und die Sprache mit dem was übrig bleibt immer noch benutzen 
(und die wichtigen Sprachfeatures immer noch funktionieren) und braucht 
dann nur noch die üblichen paar hundert Byte Startupcode (wie bei C++ 
auch) um den Prozessor zu initialisieren und den nackten kompilierten 
Rust-Code.

Runtime wäre sowas wie zum Beispiel ein immer zwingend vorhandener 
Garbage-Collector (das gibts nicht in Rust) oder gar eine riesige VM 
(wie in Java oder C#) die gleich mal mit vergleichsweise riesigem 
Overhead daherkommen selbst beim kleinsten Hello World.

Bei Rust kann man es so einrichten daß man genau wie bei C oder C++ 
wirklich nur noch die selbst geschriebenen Funktionen im Kompilat hat 
und sonst praktisch so gut wie nichts mehr (nicht mehr als man auch 
hätte wenn man es in C++ gemacht hätte) und die laufen so wie sie sind 
direkt auf dem blanken Silizium.

> Heißt das, man kann
> Rust nicht dynamisch linken? Warum ist das gut?

Das hat damit gar nichts zu tun.

Eher im Gegenteil ist es so daß man bei den oben genannten "gemanageten" 
Sprachen die innerhalb einer VM ablaufen arge Klimmzüge machen muß oder 
umständliche Wrapper braucht um sie in die eine oder andere Richtung mit 
C Kompilaten zu linken (falls überhaupt möglich).

Mit Rust kann man selbstverständlich Code erzeugen der sich mit C oder 
C++ problemlos und ganz direkt dynamisch oder statisch linken lässt. 
Darauf hat man absichtlich Wert gelegt.

Rust ist in dieser Hinsicht wie C, nur die eigentliche Sprache ist 
komplett anders und besser.

Autor: W.S. (Gast)
Datum:

Bewertung
-8 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Mit Rust kann man selbstverständlich Code erzeugen der sich mit C oder
> C++ problemlos...

.. zusammenlinken läßt. Naja, eben.

Rust ist ganz offensichtlich nur ein weiterer Vorbrenner für C. Sieht ja 
auch fast genauso aus, ist nur noch ein wenig unübersichtlicher.

W.S.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Genau, schließlich wissen wir ja alle dass die Optik bei einer 
Programmiersprache am Wichtigsten ist. Deswegen ist ja z.B. auch die 
Shakespeare Programming Language eine der Beliebtesten.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> weiterer Vorbrenner für C. Sieht ja
> auch fast genauso aus,

Nur daß es eigentlich komplett anders aussieht.

Und nein, es wird nicht in irgendeinem Zwischenschritt nach C 
kompiliert, C kommt überhaupt nicht vor, das verwechselst Du 
wahrscheinlich mit irgendeiner anderen Sprache. Der Compiler verwendet 
LLVM und spuckt direkt das native Binary aus.

Autor: Markus F. (mfro)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> Rust ist ganz offensichtlich nur ein weiterer Vorbrenner für C. Sieht ja
> auch fast genauso aus, ist nur noch ein wenig unübersichtlicher.

man merkt gleich, dass Du dich ganz genau informiert hast.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Markus F. schrieb:
> W.S. schrieb:
>> Rust ist ganz offensichtlich nur ein weiterer Vorbrenner für C. Sieht ja
>> auch fast genauso aus, ist nur noch ein wenig unübersichtlicher.
>
> man merkt gleich, dass Du dich ganz genau informiert hast.

Für W.S. ist alles C, was nicht Pascal ist ;-)

Versuchen wir aber trotzdem, die Diskussion auf das vom TE vorgegebene
Thema, nämlich Rust (im Vergleich zu C und C++) zu beschränken!

Autor: Yalu X. (yalu) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Timm R. schrieb:
> Könnte mir zufällig mal schnell jemand dies hier rosten?

Ich hab's mal versucht.

Allerdings habe ich das da nicht ganz verstanden:

    std::vector<size_t> a{33, 100000};
    std::vector<size_t> b{34, 100000};

Damit werden zwei Vektoren mit je zwei Elementen angelegt, was hier

    for(size_t i=0; i<100000; i++)
    {
        a = std::move(b);
        a[i]=42;
        b = std::move(a);
    }

unweigerlich zum Crash führt. Ich nehme an, es sollte

    std::vector<size_t> a(100000, 33);
    std::vector<size_t> b(100000, 34);

heißen (jeweils 100000 Elemente mit dem Wert 33 bzw. 34).

movetest1.rs wäre die 1:1-Umsetzung deines Codes. Das kompiliert aber
nicht, weil in mv2 versucht wird, die mittels Referenzen geborgten
Objekte zu moven. Das ist genauso, als würdest du dein Auto einem Freund
leihen und dieser es an einen Dritten verschenken oder es gleich auf den
Schrottplatz bringen :)

In C++ ist das zwar prinzipiell erlaubt, und sogar clang-tidy akzeptiert
das, trotzdem muss man beachten, dass nach dem Aufruf von mv2 der Vektor
a weggemovet worden ist und keine sinnvollen Daten mehr enthält.

Rust hat bzgl. geborgter Objekte (d.h. Referenzen auf Objekte) strengere
Regeln.

Alternativ zu Referenzen könnte man a und b per move an mv2 übergeben,
allerdings hat man dann hinterher keinen Zugriff mehr darauf, so dass
die Ausgabe des Elements von b angemeckert wird.

Man könnte a und b auch klonen, nur bekommt dann das Hauptprogramm die
in mv2 vorgenommenen Änderungen nicht mehr mit.

Wenn man die Argumentübergabe umgeht, indem man die Schleife ins
Hauptprogramm verlagert, gibt es keine Probleme. So habe ich es in
movetest2.rs schließlich gemacht.

movetest.cpp ist dein leicht modifizierter C++-Code. Damit bei der
Zeitmessung der Aufruf-Overhead von mv2 nicht mitgemessen wird, habe ich
sie in die Funktion mit hinein gepackt.

Die Compileraufrufe:
clang++ -Wall -std=c++17 -O3 -o movetestc movetest.cpp
g++     -Wall -std=c++17 -O3 -o movetestg movetest.cpp
rustc -C opt-level=3 movetest.rs

Die gemessenen Zeiten auf zwei Laptops mit unterschiedlichen CPUs:
        i7-4910MQ     i5-6267U
———————————————————————————————
Clang    512.8 ms     611.8 ms
GCC      513.2 ms     611.8 ms
Rust     526.4 ms     526.4 ms
———————————————————————————————

Noch ein Hinweis: Wenn du mit dem C++-Code herumspielst und feststellst,
dass der Clang-Code plötzlich um den Faktor 6 schneller als der GCC-Code
ist, liegt das daran, dass der Clang die Funktion mv2 inlinet und dabei
einen Großteils des Codes wegoptimiert. Mit __attribute__(noinline))
kann das ggf. vermieden werden.

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Yalu,

ja hatte das auf dem handy hingetippert. Wie blöd. War wohl dann 
schonmal eine kleine Werbung für Rust :-)

Vielen Dank! Sehr nett von dir!

Viele liebe Grüße
timm

Autor: Kaj (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hey Yalu,

du hast da einen kleinen Fehler in deinem Code.

In movetest1.rs hast du:
  for i in 0..N {
    *a = *b;
    b[i] = 42;  // !!!
    *b = *a;
  }

Und in movetest2.rs hast du aber:
  for i in 0..N {
    a = b;
    a[i] = 42;  // !!!
    b = a;
  }

Aendert man in movetest2.rs das a[i] zu b[i], dann compiliert es auch 
nicht mehr.
warning: value assigned to `a` is never read
 --> src/main.rs:6:11
  |
6 |   let mut a = vec![33usize; N];
  |           ^
  |
  = note: #[warn(unused_assignments)] on by default

error[E0382]: use of moved value: `b`
  --> src/main.rs:13:5
   |
12 |     a = b;
   |         - value moved here
13 |     b[i] = 42;
   |     ^ value used here after move
   |
   = note: move occurs because `b` has type `std::vec::Vec<usize>`, which does not implement the `Copy` trait

error: aborting due to previous error

For more information about this error, try `rustc --explain E0382`.
error: Could not compile `test_prog`.
Kurz: Egal wie du es machst, es geht nicht. :D

Yalu X. schrieb:
> Man könnte a und b auch klonen, nur bekommt dann das Hauptprogramm die
> in mv2 vorgenommenen Änderungen nicht mehr mit.
Da sich das Beispiel anscheinend nicht 1:1 in Rust umsetzen laesst, 
warum a und b nicht einfach als Tuple (oder sonstwas) zurueck geben?

Gruesse

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Yalu,

Yalu X. schrieb:
> Die gemessenen Zeiten auf zwei Laptops mit unterschiedlichen CPUs:
>         i7-4910MQ     i5-6267U
> ———————————————————————————————
> Clang    512.8 ms     611.8 ms
> GCC      513.2 ms     611.8 ms
> Rust     526.4 ms     526.4 ms
> ———————————————————————————————

hmhm, da stellt sich doch die Frage, warum das mit Clang und GCC auf 
meinem i7-6700K CPU @ 4.00GHz 10 ms langsamer ist, als auf Deinem 
i5-6267U. Das ist irgendwie ungerecht :-)

Danke, genau so, wie du es programmiert hast, war es gedacht.

1. Mein Fehler mit den {} ist ein Punkt für Rust
2. Habe ich die Timings zum Anlass genommen, die Behauptung des OP, 
Zugriffe seien Range-checked zu überprüfen: Das stimmt nicht, Zugriffe 
sind nicht range-checked.
3. Diese move-Sache interessiert mich. Hätte man nicht erwartet, dass 
Rust viel schneller ist? Ich dachte, ich hätte gelesen, dass Rust den 
Speicher als Block kopiert. C++ geht ja über alle Elemente und ruft den 
Move Konstruktor auf, was bei szie_t natürlich nichts bringt?

Mit String statt size_t ist dann bei mir der C++ move vermutlich im 
Vorteil.

Rust braucht 5.28s, Clang 1.62s

vlg

 Timm

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Timm R. schrieb:
> Hätte man nicht erwartet, dass
> Rust viel schneller ist? Ich dachte, ich hätte gelesen, dass Rust den
> Speicher als Block kopiert.

Rust muß doch beim Eigentümerwechsel zur Laufzeit gar nichts mehr 
machen. Das Objekt liegt irgendwo im Speicher und der Compiler hat schon 
zur Compilezeit sichergestellt daß die Eigentumsverhältnisse überall 
korrekt sind, es geht ja nur darum daß der Compiler keinen Code erzeugen 
kann bei dem ein Teil des Programms dem anderen unerwartet die Variablen 
unter den Füßen wegziehen kann. Sobald der Code so geschrieben ist daß 
das niemals geschehen kann muß beim eigentlchen move zur Laufzeit gar 
nichts mehr geschehen.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Timm R. schrieb:
> 1. Mein Fehler mit den {} ist ein Punkt für Rust

Wieso ist dein Fehler ein Punkt für rust?
In rust ist auch relevant was man genau schreibt:
let v = vec![10, 5];
let w = vec![10; 5];

Timm R. schrieb:
> 3. Diese move-Sache interessiert mich. Hätte man nicht erwartet, dass
> Rust viel schneller ist? Ich dachte, ich hätte gelesen, dass Rust den
> Speicher als Block kopiert. C++ geht ja über alle Elemente und ruft den
> Move Konstruktor auf, was bei szie_t natürlich nichts bringt?

In dem Beispiel wird ein std::vector gemoved. Es wird nicht jedes 
Element gemoved. Einen std::vector zu moven bedeutet 3 Pointer zu 
kopieren.

Autor: W.S. (Gast)
Datum:

Bewertung
-7 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Für W.S. ist alles C, was nicht Pascal ist ;-)

OK, ich revidiere das mal dahingehend, daß Rust sowohl wie C als auch 
wie Basic aussieht:
fn main() {
  let mut a = vec![33usize; N];
  let mut b = vec![34usize; N];
  let start = Instant::now(); 

Es fehlen bloß die Zeilennummern und 'dim'.
100 let a = 123
101 gosub 200

oder so ähnlich. Ist mir schon zu lange her.

Also was soll sowas bloß? Offenbar schmeißt Rust mit noch mehr 
Interpunktionszeichen um sich als C - und das will schon was heißen.

Aber mit dem Vorbrenner für C hatte ich schon Recht. Zitat: "On Windows, 
Rust additionally requires the C++ build tools for Visual Studio 2013 or 
later."

W.S.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
W.S. schrieb:
> OK, ich revidiere das mal dahingehend, daß Rust sowohl wie C als auch
> wie Basic aussieht:

Alter Schwede, was für ein saublödes Geschwätz. W.S. wie er leibt und 
lebt wieder mal. Echt original.

Autor: Yalu X. (yalu) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Kaj schrieb:
> du hast da einen kleinen Fehler in deinem Code.
>
> In movetest1.rs hast du:  for i in 0..N {
>     *a = *b;
>     b[i] = 42;  // !!!
>     *b = *a;
>   }

Du hast recht, da sollte
a[i] = 42;

stehen wie von Timm hier vorgegeben:

Timm R. schrieb:
> a[i]=42;

Die Fehlermeldungen bleiben aber die gleichen und beziehen sich auf das
*a = *b und *b = *a.

In movetest2.rs ist die entsprechende Zeile richtig.

Kaj schrieb:
> Yalu X. schrieb:
>> Man könnte a und b auch klonen, nur bekommt dann das Hauptprogramm die
>> in mv2 vorgenommenen Änderungen nicht mehr mit.
> Da sich das Beispiel anscheinend nicht 1:1 in Rust umsetzen laesst,
> warum a und b nicht einfach als Tuple (oder sonstwas) zurueck geben?

Stimmt. Es würde sogar reichen, b zurückzugeben, da a ja sowieso
zermovet ist (auch im Original-C++-Code von Timm) und auch gar nicht
mehr benötigt wird. Ich habe das mal in movetest3.rs so umgesetzt.

: Bearbeitet durch Moderator
Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd,

Bernd K. schrieb:
> Timm R. schrieb:
>> Hätte man nicht erwartet, dass
>> Rust viel schneller ist? Ich dachte, ich hätte gelesen, dass Rust den
>> Speicher als Block kopiert.
>
> Rust muß doch beim Eigentümerwechsel zur Laufzeit gar nichts mehr
> machen.

meine Worte, bzw.: um so erstaunlicher. 500-600 ms ist eine lange Zeit 
für "nichts" ... (Siehe Yalus Timings)

vlg

 Timm

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Timm R. schrieb:
> hmhm, da stellt sich doch die Frage, warum das mit Clang und GCC auf
> meinem i7-6700K CPU @ 4.00GHz 10 ms langsamer ist, als auf Deinem
> i5-6267U. Das ist irgendwie ungerecht :-)

Da sich die Prozessoren im Pipelining und in der Branch-Prediction stark
unterscheiden, kann es schon passieren, dass der eigentlich schnellere
Prozessor in bestimmten Fällen langsamer ist.

Als ich einmal mit einem Stückchen Code die Geschwindigkeit von C und
Haskell vergleichen wollte, stellte ich überrascht fest, dass der
Haskell-Code etwa 50% schneller war. Noch überraschter war, als ich den
vom C-Compiler generierten Assemblercode analysierte, der nach meinem
Dafürhalten nicht weiter optimierbar war, höchstens mit einem mir
unbekannten Programmiertrick. Also habe ich im vom Haskell-Compiler
generierten Assemblercode nach diesem Programmiertrick gesucht, musste
aber feststellen, dass dieser Code zwar nicht schlecht, aber dennoch
umständlicher war das der vom C-Compiler generierte. Ich vermute
deswegen, dass der Haskell-Code einfach besser mit dem Piplining des
Prozessors harmoniert hat. Auf einem anderen Prozessor war der C-Code
schneller.

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
mh schrieb:

> In dem Beispiel wird ein std::vector gemoved. Es wird nicht jedes
> Element gemoved. Einen std::vector zu moven bedeutet 3 Pointer zu
> kopieren.

und dafür braucht c++ 500 ms? Dann sollte man sich tatsächlich ernsthaft 
überlegen, die Sprache zu wechseln.

vlg
 Timm

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Rust muß doch beim Eigentümerwechsel zur Laufzeit gar nichts mehr
> machen.

Da bin ich mir nicht so sicher, bin aber noch nicht weit genug in die
Tiefen von Rust abgestiegen, um das sicher beurteilen zu können. Im
konkreten Beispiel hätte der Compiler das Kopieren vermutlich
wegoptimieren können, aber das geht nicht immer:

In folgendem Beispiel

  let a = ...;
  let b = ...;
  if ... {
    b = a;
  }
  machwasmit(b);

ist b beim Aufruf von machwasmit entweder das ursprüngliche b oder das
ursprüngliche a, jenachdem, ob die if-Bedingung falsch oder wahr ist.
Deswegen muss bei b = a mindestens eine Shallow-Copy gemacht werden.

Immerhin kann durch das Moven auf eine Deep-Copy verzichtet werden, und
durch die Prüfung der Ownership zur Compilezeit ist der Code auch ohne
Overhead durch Laufzeitprüfungen sicher.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Timm R. schrieb:
> meine Worte, bzw.: um so erstaunlicher. 500-600 ms ist eine lange Zeit
> für "nichts" ... (Siehe Yalus Timings)

Der "Eigentümer" muss immer noch gewechselt werden, was etwas mehr als 
"nichts" ist. Wenn a[i] (oder b[i])  einen Seiteneffekt hat, wie z.b. 
Rangecheck mit evtl. panic (k.a. was da genau im Hintergrund passiert), 
kann die Schleife auch nicht wirklich optimiert werden.

Timm R. schrieb:
> mh schrieb:
>
>> In dem Beispiel wird ein std::vector gemoved. Es wird nicht jedes
>> Element gemoved. Einen std::vector zu moven bedeutet 3 Pointer zu
>> kopieren.
>
> und dafür braucht c++ 500 ms?
Nein, die 800e6 Bytes wollen auch kopiert werden.

Timm R. schrieb:
> Dann sollte man sich tatsächlich ernsthaft
> überlegen, die Sprache zu wechseln.
Oder eine der Sprachen richtig lernen, damit du verstehst was alles im 
Hintergrund passiert?!

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> OK, ich revidiere das mal dahingehend, daß Rust sowohl wie C als auch
> wie Basic aussieht:fn main() {
>   let mut a = vec![33usize; N];
>   let mut b = vec![34usize; N];
>   let start = Instant::now();
>
> Es fehlen bloß die Zeilennummern und 'dim'.
> 100 let a = 123
> 101 gosub 200

Ja, dein scharfes Auge hat in beiden Beispielen das Schlüsselwort "let"
entdeckt. Herzlichen Glückwunsch dafür ;-)

Ist dir schon einmal in den Sinn gekommen, dass dieses "let" in Rust
eine gänzlich andere Bedeutung haben könnte als in Basic?

Beitrag #5516440 wurde von einem Moderator gelöscht.
Autor: Privatfrickler (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mir fehlt ein wenig die Einsicht was euer Code hier eigentlich soll???

Im Endeffekt lasst ihr 3 Pointer zwischen a und b immer sinnlos hin- und 
herpendeln (siehe Anhang!). Wenn der Compiler schlau genug wäre könnte 
er eigentlich über eine genauere "Laufzeit-Vorab-Analyse" nach ein paar 
Durchläufen erkennen, dass hier sinnlos im Kreis gepointert wird 
(Ringelrein mit Adressen) und den Code dazu anstatt Millionen mal 
schlicht zweimal ausführen a[] -> b[] -> a[] und gut ist.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Timm R. schrieb:
> meine Worte, bzw.: um so erstaunlicher. 500-600 ms ist eine lange Zeit
> für "nichts" ... (Siehe Yalus Timings)

Das sind 5-6 ns pro Schleifendurchlauf, d.h 2 Moves, 1 Zuweisung des
Array-Elements und Schleifenoverhead.

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:

>>> In dem Beispiel wird ein std::vector gemoved. Es wird nicht jedes
>>> Element gemoved. Einen std::vector zu moven bedeutet 3 Pointer zu
>>> kopieren.
>>
>> und dafür braucht c++ 500 ms?
> Nein, die 800e6 Bytes wollen auch kopiert werden.

Du wolltest also schreiben:

Einen std::vector zu moven bedeutet 3 Pointer und den gesamten 
Speicherbereich der Elemente zu kopieren?

Das ist aber nicht genau das selbe.

>Oder eine der Sprachen richtig lernen

Deutsch zum Beispiel?


vlg
 Timm

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Timm R. schrieb:
> Du wolltest also schreiben:
>
> Einen std::vector zu moven bedeutet 3 Pointer und den gesamten
> Speicherbereich der Elemente zu kopieren?
Nein!
//ein vector mit 1000 ints
std::vector<int> foo(1000);

//hier werden 3 Pointer kopiert
auto baa = std::move(foo);

// in dieser Schleife werden 6000 Pointer werden kopiert und 1000 ints werden geschrieben
for(int i=0; i<1000; ++i) {
  foo = std::move(baa); // 3 Pointer werden kopiert
  foo[i] = 42; // ein int wird in den Speicher geschrieben
  baa = std::move(foo); // 3 Pointer werden kopiert
}

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

diese move-Thema interessiert mich weiterhin.
Und danach, wie rüde und selbstsicher die Antworten formuliert sind zu 
gehen, bin ich wohl der Einzige, dem sich kein einheitliches Bild 
ergibt.

1. Warum genau ist die Move-Operation bei Rust so viel schneller, als 
bei clang c++?
2. Warum bricht die Performance so stark ein, wenn es sich nicht um 
einen vector von size_t sondern von string handelt?

std::string
clang: 1452 ms
rust: 5275 ms

size_t
clang: 831 ms
rust: 488 ms

rustc 1.28.0
LLVM version 9.1.0

Vielen Dank

 Timm

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Timm R. schrieb:
>> Du wolltest also schreiben:
>>
>> Einen std::vector zu moven bedeutet 3 Pointer und den gesamten
>> Speicherbereich der Elemente zu kopieren?
> Nein!

Ich bitte um Entschuldigung und danke für die Klarstellung. Da hatte ich 
wohl Tomaten auf den Ohren!

vlg

 Timm

Autor: Jürgen S. (starblue) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nga schrieb:
>
> Was ich mich noch frage: was passiert standardmäßig im Falle eines
> panic!()-Aufrufs?

Mikrokontroller programmiert man normalerweise ohne die 
Standardbibliothek,
die sonst das Panik-Handling macht (Direktive #[no_std]).
Darum muss es irgendwo einen Panik-Handler geben, für den Anfang reicht 
eine Endlosschleife:
use core::panic::PanicInfo;

#[panic_implementation]
fn panic(_info: &PanicInfo) -> ! {
    loop {}
}

Es gibt auch fertige Handler, die wohl per cortex-m-rt eingebunden 
werden sollen (panic-semihosting, panic-abort), hab ich aber noch nicht 
ausprobiert.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Timm R. schrieb:
> 1. Warum genau ist die Move-Operation bei Rust so viel schneller, als
> bei clang c++?
> 2. Warum bricht die Performance so stark ein, wenn es sich nicht um
> einen vector von size_t sondern von string handelt?
> std::string
> clang: 1452 ms
> rust: 5275 ms
> size_t
> clang: 831 ms
> rust: 488 ms
Was genau vergleichst du? Am besten du zeigst den Quelltext der beiden 
Programme mit denen du testest.

Autor: Alex G. (dragongamer)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Timm R. schrieb:
> Könnte sich denn vielleicht einer der Rust-kundigen und C++-kundigen
> erbarmen, mal ein minimales Beispiel mit c++ Pointer-Katastrophe zu
> zeigen und wie es in Rust besser läuft? Das wäre doch sicher für mehrere
> Rist-Unkundige interessant und erhellend? Mir fehlt da einfach die
> Vorstellungskraft.

Hmm, du hättest bei meinem Vortrag vor ein paar Wochen über Rust dabei 
sein sollen.
Dafür habe ich den Heartbleed Bug in C++ nachprogrammiert - und dann 
versucht ihn auch unter Rust zu programmieren (ohne Unsafe).
Letzteres war nicht möglich.
In der angehängten Datei sind zwei Versionen drin - eine die zur 
Compilezeit schon Error wirft und eine die die falsche 
Array-Längenangabe garnicht nutzen kann.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> Hmm, du hättest bei meinem Vortrag vor ein paar Wochen über Rust dabei
> sein sollen.
Wo hast du diesen Vortrag gehalten?

Alex G. schrieb:
> Dafür habe ich den Heartbleed Bug in C++ nachprogrammiert
Du hast den "Bug" in c programmiert und dann iostream benutzt, damit du 
es c++ nennen darfst. Für ein echtes c++ Beispiel hättest du zumindest 
std::string und/oder std::vector nutzen müssen. Der eigentliche Bug in 
deinem Programm ist übrigens ein memory leak.


Wo in deiner HeartbleedDemo.cpp ist eigentlich die
template <typename T>
void return(T)
deklariert/definiert? ;-)

Autor: Arc N. (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> mh schrieb:
>> Yalu X. schrieb:
>>> Ist das bei clang-tidy wirklich garantiert, auch in verzwickteren
>>> Fällen?
>> Nein. Ist es in rust garantiert?
>
> Selbstverständlich. Es ist Teil der Sprachdefinition, ein Verstoß gegen
> die Ownership-Regeln könnte nicht kompiliert werden, es wäre ungültiger
> Code und der Compiler würde mit Fehler abbrechen.

Selbst wenn es Teil der Sprachdefinition ist, ist das keine Garantie für 
irgendwas. Das gilt im übrigen auch für alle anderen Garantien die Rust 
geben will. Formale Beweise kommen so langsam, zumindest für eine gute 
Untermenge von Rust, 
https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf
Appendix und weiteres gibt's unter 
https://plv.mpi-sws.org/rustbelt/popl18/
Weniger formal erklärt inkl. der noch fehlenden Teile 
https://blog.acolyer.org/2018/01/18/rustbelt-secur...

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Alex G. schrieb:
>> Hmm, du hättest bei meinem Vortrag vor ein paar Wochen über Rust dabei
>> sein sollen.
> Wo hast du diesen Vortrag gehalten?
Hochschule Master in einem Kurs über "Secure Systems".
Haupthema war allerdings eher "Rust Belt"; ein mathematischer Ansatz der 
die Sicherheit von Rust's Standard library nachweist obwohl diese intern 
"unsafe" benutzt.

EDIT: Sehe grade, Arc. N hat genau darauf Bezug genommen!
Mag vielleicht noch nicht vollständig sein, aber ist noch immer 
erheblich mehr als was es für jede andere brauchbare Sprache gibt.

"Besseres" gibt es nur in Sprachen die umgekehrt entwickelt wurden: Erst 
sicheres mathematisches Konstrukt, dann darauf eine Art von Sprache.
Nur will man das Zeug als Programmierer der sein Geld durch einigermaßen 
effizientes Arbeiten verdienen muss, nicht mal mit der Kneifzange 
anfassen...

> Alex G. schrieb:
>> Dafür habe ich den Heartbleed Bug in C++ nachprogrammiert
> Du hast den "Bug" in c programmiert und dann iostream benutzt, damit du
> es c++ nennen darfst. Für ein echtes c++ Beispiel hättest du zumindest
> std::string und/oder std::vector nutzen müssen. Der eigentliche Bug in
> deinem Programm ist übrigens ein memory leak.
Der Heartbleed war doch im Grunde ein Memoryleak. Halt über die 
Systemgrenze hinweg.

Gut, das ist C. Sollte eben so leicht lesbar wie möglich sein. In dem 
Fall brauchte es auch eher keine Objektorientierung ;)

> Wo in deiner HeartbleedDemo.cpp ist eigentlich die
>
> template <typename T>
> void return(T)
> 
> deklariert/definiert? ;-)
Das verstehe ich jetzt aber nicht so ganz. Wofür wäre ein Template gut 
gewesen?

Achso, damit es mehr nach C++ klingt? :P

: Bearbeitet durch User
Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> Der Heartbleed war doch im Grunde ein Memoryleak. Halt über die
> Systemgrenze hinweg.
Nein! Bei Heartbleed kann man Speicher lesen, den man nicht lesen können 
sollte. Ein Programm hat ein memory leak, wenn es Speicher allokiert 
hat, auf den niemand mehr zugreifen kann. Und welche Systemgrenze meinst 
du?

Alex G. schrieb:
> Gut, das ist C. Sollte eben so leicht lesbar wie möglich sein.
Warum hast du es dann c++ genannt? Hättest du strings/vectoren genommen, 
könntest du testAliveA und testAliveB analog zu deinen rust Versionen 
schreiben und das es existiert nicht.

Alex G. schrieb:
> In dem Fall brauchte es auch eher keine Objektorientierung
Aber jemanden, der c++ als c mit Objekten sieht, hat die Sprache nicht 
verstanden. Bleibt die Frage: Warum vergleicht man c++ mit rust, wenn 
man kein c++ kann?

Alex G. schrieb:
> Das verstehe ich jetzt aber nicht so ganz. Wofür wäre ein Template gut
> gewesen?
>
> Achso, damit es mehr nach C++ klingt? :P
Nein, aber ich habe auch nicht erwartet, dass du die Frage verstehst.

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Echt jetzt, muss diese Überheblichkeit sein?
Bin Praktiker und kein Theoretiker den es interessiert die Sprache "zu 
verstehen". Dafür habe ich meine Bachelor Thesis mit Softwareprojekt in 
richtigem C++ geschrieben.

Autor: W.S. (Gast)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Alex G. schrieb:
> Echt jetzt, muss diese Überheblichkeit sein?

ist doch eigentlich nicht wichtig. Die Leute, die sich mit Rust befassen 
und es bewerben wollen, schaffen es ja nicht einmal, eine saubere 
Sprachdefinition hinzukriegen.
Siehe z.B. dort:
https://rust-lang-de.github.io/rustbook-de/

Da wird zuerst die Werbetrommel gerührt, was für hehre Ziele Rust denn 
so hat, Zitat: "Willkommen! Dieses Buch wird dir die Programmiersprache 
Rust beibringen. Rust ist eine Systemprogrammiersprache mit dem Fokus 
auf drei Ziele: Sicherheit, Geschwindigkeit und Nebenläufigkeit (Safety, 
Speed, Concurrency). Sie erreicht diese Ziele ohne Garbage Collector, 
was sie zu einer nützlichen Sprache für eine Reihe von Anwendungsfällen 
macht, in denen andere Sprachen nicht so gut sind..."

und dann kommt nicht das Allerwichtigste, nämlich eine Sprachdefinition 
(vorzugsweise Backus-Naur), sondern sowas: (wieder ein Zitat)

Erste Schritte - Richte deinen Computer ... ein.
Lerne Rust - Lerne Rust-Programmierung durch kleine Projekte.
Effektives Rust - Fortgeschrittene Konzepte, um ausgezeichneten 
Rust-Code zu schreiben.
Syntax und Semantik - Jedes Stück Rust auf kleine Stücke 
heruntergebrochen.
Nightly Rust - Cutting-edge features, die noch nicht im stabilen 
Compiler verfügbar sind.
Glossar - Erklärungen von Begriffen, die in diesem Buch verwendet 
werden.
Akademische Forschung - Literatur, die Rust beeinflusst hat.

Was soll das?
Das ist ja schlimmer als die Leute, die eurer Oma ne Wolldecke mit 
Magneten drin verhökern wollen.

Hier liegt ein Sprach-Gewurschtel vor und keine sauber konstruierte 
Programmiersprache. Die Fans fummeln an tausend kleinen Details herum, 
ohne daß es eine saubere logische Gesamtdefinition gäbe - und das macht 
eben keine gute Programmiersprache aus.

Und ihr wollt hier diskutieren, ob sich DAS als Programmiersprache für 
einen PIC32 oder einen Cortex eignet? Nur zu, wer es sich in den Kopf 
gesetzt hat, partout Rust für die Firmware seines BluePill-Brettl's oder 
seines AVR nehmen zu wollen, der muß es halt tun - wenngleich ich das 
Ganze für eine ausgemachte .. naja, sagen wir mal Theoretisiererei.. 
halte.

Ich bin mir sicher, daß in den nächten 10 Jahren weitere 30 derartige 
Sprachen der staunenden Fachwelt vorgestellt werden, die allesamt und 
jede für sich alles bisher Dagewesene in den Schatten stellt.

OK, um hier im Forum ein bissel zu diskutieren, mag Rust ja geeignet 
sein.

W.S.

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Glaube du zählst zu den wenigen Personen welche sich beim Befassen mit 
einer neuen Sprache, als erstes die Backus Naur Form sehen wollen...

Btw. hat es mich nur eine Google Query gekostet, zu finden was du 
scheinbar suchst: https://doc.rust-lang.org/grammar.html


Dass immer wieder revolutionäre Sprachen auftauchen die sich nie so 
richtig durchsetzen ist leider wahr. Damit hat auch Rust zu kämpfen, 
denn die Millionen C Entwickler kriegt man schlicht nicht umgeschult. 
Trotzdem ist die Sprache sehr förderungswert - zu unser aller 
Sicherheit!


Beliebt ist die Sprache jedenfalls. Schon seit drei Jahren an der 
Spitze: 
https://insights.stackoverflow.com/survey/2018/#mo...

: Bearbeitet durch User
Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Alex G. schrieb:
> Damit hat auch Rust zu kämpfen,
> denn die Millionen C Entwickler kriegt man schlicht nicht umgeschult.

Da kann man nur auf die Plancksche Lösung warten. Leider wachsen immer 
wieder welche nach...

Alex G. schrieb:
> Beliebt ist die Sprache jedenfalls. Schon seit drei Jahren an der
> Spitze:

Naja, Python steht da auch auf Platz drei, während Pascal nichtmal 
vorkommt. Beliebtheit ist offenbar kein Qualitätskriterium. ;-)

: Bearbeitet durch User
Autor: Alex G. (dragongamer)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Gute Nutzbarkeit ist natürlich ausschlaggebend und da ist Python kaum 
geschlagen.

Klar, in der Umfrage da werden alle Entwickler-Arten von Embedded bis AI 
zusammengenommen.

Wobei Rust eigentlich auch nicht unbedingt in erster Linie für Embedded 
ist. Die aktuellen Vorzeigeprojekte sind im Bereich Server und Desktop.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> Beliebt ist die Sprache jedenfalls.

Wobei man hinzufügen sollte, dass Rust keine nennenswerte Verbreitung 
hat (unter 4.2% in der gleichen Umfrage, d.h. taucht unter den Top 25 
nicht auf). Daraus lässt sich schließen, dass die hohe Beliebtheit von 
einer kleinen, sehr loyalen Anhängerschaft stammt.

Im Technologiegraph taucht Rust ebenfalls nicht auf, vermutlich wird 
Rust zu selten professionell eingesetzt. Schade eigentlich, denn dort 
hätte man die Anwendungsfälle sehen können.

Nachtrag: Delphi/Object Pascal taucht in der Liste der unbeliebtesten 
Sprachen auf Platz 12 auf, gleich neben C. C++ steht auf beiden Listen, 
polarisiert also offensichtlich sehr stark.

Überhaupt finde ich die Liste der beliebtesten Sprachen interessant.

: Bearbeitet durch User
Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Alex G. schrieb:
>> Beliebt ist die Sprache jedenfalls.
>
> Wobei man hinzufügen sollte, dass Rust keine nennenswerte Verbreitung
> hat (unter 4.2% in der gleichen Umfrage, d.h. taucht unter den Top 25
> nicht auf). Daraus lässt sich schließen, dass die hohe Beliebtheit von
> einer kleinen, sehr loyalen Anhängerschaft stammt.
Würde eher sagen die Beliebtheit stammt von Leuten die von der Sprache 
gehört haben und sie "interessant" finden, aber sie trotzdem nicht 
selber einsetzen (im Privaten hat man selten Projekte wo die Sprache 
Sinn macht und professionell ist sie leider eher rar wie du schon 
sagst).
Die Umfrage betrachtet nicht nur die tatsächlichen Nutzer der Sprache.

> Im Technologiegraph taucht Rust ebenfalls nicht auf, vermutlich wird
> Rust zu selten professionell eingesetzt. Schade eigentlich, denn dort
> hätte man die Anwendungsfälle sehen können.
Leider wahr.
Der englische Wiki Artikel nennt ein paar Programme bzw. Projekte welche 
die Sprache einsetzen. Zwei davon sind allerdings von Mozilla selbst.


> Überhaupt finde ich die Liste der beliebtesten Sprachen interessant.
Was haben eigentlich alle gegen Visual Basic? o.O

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> Die Umfrage betrachtet nicht nur die tatsächlichen Nutzer der Sprache.

Ich glaube, dass Rust hauptsächlich von Leuten angekreuzt wird, die es 
auch nutzen. Sonst hat ja niemand dazu einen Grund (bzw. wenn ich mich 
recht entsinne, stand das auch dabei). Und da es kaum professionelle 
Projekte in Rust gibt, sind das alles Hobbyisten - und die würden kein 
Rust verwenden, wenn sie es nicht toll fänden.

Alex G. schrieb:
>> Überhaupt finde ich die Liste der beliebtesten Sprachen interessant.
> Was haben eigentlich alle gegen Visual Basic? o.O

Naja, ich hab damit (und QBasic) angefangen, vor ziemlich vielen Jahren. 
Letztes Jahr habe ich aus nostalgischen Gründen (und weil ich bei meinen 
Eltern war) mal mein altes, dickes Fachbuch* rausgekramt und mich 
speziell in die Details reingelesen, die ich als Kind damals nicht 
verstanden habe.

*konkret "Visual Basic 6 Kompendium" von Peter Monadjemi

Nee, ich hab nicht das Gefühl bekommen, nochmal mit VB6 arbeiten zu 
wollen.

Autor: Kaj (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> Wobei Rust eigentlich auch nicht unbedingt in erster Linie für Embedded
> ist.
Das ist richtig, aber gerade da koennte Rust, m.M.n., punkten. Besonders 
da, wo hohe Anforderungen an Fehlerfreiheit gestellt werden. Da man 
viele Fehler in Rust, verglichen mit C und C++, gar nicht erst machen 
kann, beschraenken sich die Fehler fast ausschliesslich auf Logikfehler.

Alex G. schrieb:
> und professionell ist sie leider eher rar wie du schon sagst
Sehe ich nicht so. Siehe hier:
https://www.rust-lang.org/en-US/friends.html

Mit Cloudflare, Dropbox, Threema, Mozilla (die es ja entwickelt haben), 
Samsung, etc. sind schon ein paar grosse/bekannte Namen dabei, die Rust 
aktiv nutzen.

Und auch dieses 5 Seiten PDF, wie Rust bei einem Spielestudio seine 
Vorteile ausspielt, finde ich sehr interessant:

Rust Case Study:
Chucklefish Taps Rust to Bring Safe Concurrency to Video Games
https://www.rust-lang.org/pdfs/Rust-Chucklefish-Wh...

Es gibt praktisch kaum einen Grund, nicht auf Rust zu setzten (ausser im 
Embedded Bereich, wobei ARM schon recht gut unterstuetzt wird). Das 
Oekosystem ist sehr durchdacht, man muss keine Angst haben, dass man 
z.B. eine bestimmte Version eines Crates nicht mehr bekommt (ausser 
Github explodiert), man muss sich Abhaengigkeiten nicht von Hand 
zusammensuchen, etc.

Zum veroeffentlichen eines Crates braucht man zwar einen GitHub-Account, 
aber den Code selbst kann man Hosten wo man will.

Auch das Unittesting finde ich sehr gut, da man praktisch alle 
Funktionen testen kann, was in C++ mit privaten Methoden schon schwer 
wird. Auch das Benchmarking finde ich klasse, wobei das, je nach 
Funktion, etwas tricky werden kann.

Insgesamt wirkt die Sprache und das gesamte Oekosystem sehr durchdacht. 
Ob die eigentliche Toolchain wirklich durchdacht ist, darueber koennte 
man bestimmt streiten. Gerade fuer den Embedded Bereich wuerde ich es 
schoener finden, wenn aus Rust nur Zwischencode erzeugt wird, den man 
dann an einen beliebigen Compiler z.B. an den AVR-GCC verfuettert. So 
schlage ich mich immernoch damit herum, avr-rust zu bauen, was praktisch 
immer an LLVM scheitert...

Aber gut, es ist wie es ist, und abgesehen von Embedded, bin ich mit 
Rust sehr zufrieden.

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaj schrieb:
> .... Gerade fuer den Embedded Bereich wuerde ich es
> schoener finden, wenn aus Rust nur Zwischencode erzeugt wird, den man
> dann an einen beliebigen Compiler z.B. an den AVR-GCC verfuettert. So
> schlage ich mich immernoch damit herum, avr-rust zu bauen, was praktisch
> immer an LLVM scheitert...

Es gibt ein C-Backend für LLVM, das genau für den Usecase gedacht ist.

rust -(rustc)-> C -(GCC)-> AVR8

Sicher nicht ideal, aber besser als nichts.

Autor: Privatfrickler (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
S. R. schrieb:
> Naja, ich hab damit (und QBasic) angefangen, vor ziemlich vielen Jahren.
> Letztes Jahr habe ich aus nostalgischen Gründen (und weil ich bei meinen
> Eltern war) mal mein altes, dickes Fachbuch* rausgekramt und mich
> speziell in die Details reingelesen, die ich als Kind damals nicht
> verstanden habe.

Dann sei froh, dass du damals nicht an Rust geraten bist. Denn mit so 
einer Einführung hier

https://rust-lang-de.github.io/rustbook-de/

Erst hüh

"Es ist ebenfalls beachtenswert, dass hier keine Typangaben notwendig 
waren: Obwohl Rust statisch typisiert ist, mussten wir den Typ nicht 
ausdrücklich angeben. Rust hat type inference [engl.: Typinferenz, 
Typableitung], um die Stärke statischer Typen und der Ausführlichkeit 
des Angebens von Typen auszubalancieren."

dann hott

"Anders als bei let, musst du die Typen von Funktionsargumenten angeben. 
Das hier funktioniert nicht:

# #![allow(unused_variables)]
#fn main() {
fn print_sum(x, y) {
    println!("sum is: {}", x + y);
}
"
Aha! Manchmal ist es eine Stärke von Rust KEINE Typangaben machen zu 
müssen und manchmal ist eine Stärke von Rust DOCH Typangaben machen zu 
müssen oder wie?

Der Autor bekennt und lobt in der "Wir" Form:

"Das ist eine bewusste Designentscheidung. Obwohl das Herleiten der 
Typen eines kompletten Programmes möglich ist, wie zum Beispiel in 
Sprachen wie Haskell, wird dennoch häufig dazu geraten die Typen 
ausdrücklich zu dokumentieren. Wir stimmen zu, dass ausdrückliche 
Typvermerke in Funktionssignaturen und Typherleitung innerhalb von 
Funktionskörpern wundervoller Mittelweg ist."

Dann solche Schwurbelsätze wie

"Referenzen interagieren mit dem ownership-System durch das ‚Ausleihen‘ 
(borrowing) dessen, worauf sie zeigen. Der Unterschied ist, dass sie 
nicht den zugrunde liegenden Speicher freigibt, wenn die Referenz den 
Scope verlässt. Falls sie das täte, dann würden wir zweimal freigeben, 
was schlecht wäre."

Der Abschnitt beginnt mit

"Referenzen interagieren mit dem ownership-System .."

Klingt für mich ähnlich wie

Der Programmierer interagiert mit seinem Quellcode
oder
Der Programmierer interagiert mit seinem Algorithmus so lange, bis der 
Mist endlich fehlerfrei läuft.

Dann heißt es
"push ist eine Methode auf Vektoren, die ein weiteres Element an das 
Ende des Vektors anhängt."

Mit Vektor soll hier das Stückchen String "Hallo Welt" gemeint sein. Aus

"let mut x = vec!["Hallo", "Welt"];"

Und was versteht der Autor unter einer Referenz y wenn er schreibt

"let y = &x[0];"

y sei nun das erste Element des Vektors x ?

doch nicht etwa

Erstes Element vec(x) = 'H'  ???

Warum wird eine schnöde Zeichenkette hier in Schwurbelpädagogik 
umschrieben, die nichts weiter als eine Ansammlung von Einzelelementen 
vom Typ Char ist, so aufgeplustert, als etwas völlig Artfremdes 
dargestellt, was es in anderen Sprachen doch schon seit umme gibt?

Dazu heißt es

"Wir haben eine weitere Variablenbindung y hinzugefügt. In diesem Fall 
ist y eine ‚Referenz‘ auf das erste Element des Vektors. Rusts 
Referenzen sind ähnlich wie Zeiger in anderen Sprachen, aber mit 
zusätzlichen Überprüfungen zur Kompilierzeit. Referenzen interagieren 
mit dem ownership-System durch das ‚Ausleihen‘ (borrowing) dessen, 
worauf sie zeigen."

Und? Hab ich jetzt mit

"let z = &x[1];"

mir hemmungslos das ZWEITE Element des Vektors x ausgeborgt?

Frau Gilzer, ich hätte gerne ein 'a'. Was muss ich da wohl tun?

Ach das ist einfach Herr Kandidat. Sie müssen lediglich per borrow sich 
eine Referenz von ihrem mutable-baren Vektor x ausleihen und dann einer 
neuen Variablen, z.B. z zuweisen, aber ohne mutable. Welches Element 
hättens denn gerne? Ach Frau Gilzer, geben Sie mir mal ein 'o'. Dann 
lieber Kandidat, wäre das so zu schreiben

"let z = &x[4];"

Nun haben Sie ein 'o' geborgt von ihrem Vektor x.

Aber lieber Kandidat, passen Sie auf, dass ihr x dabei nicht gerade den 
Scope verlässt. Sonst borgen Sie von etwas was ihnen gar nicht mehr 
gehört! Aber keine Sorge, da schreitet der Kompiler schon ein 
(hoffentlich). Bei uns fangen Sie sich jedenfalls keine Nebenläufigkeit 
ein. Das haben wir alles im Griff. Frau Gilzer, was ist denn eine 
Nebenläufigkeit? Ach Herr Kandidat, wenn ich ihnen das jetzt alles 
erklären müsste ...

Hauptsache Sie haben keinem hängenden Zeiger! Ich bitte Sie, Frau 
Gilzer! Bei mir hängt gar nix! Darauf können Sie sich verlassen.

Frau Gilzer: Und da wäre ja auch noch die iterator Invalidation. DIE ist 
erst speziell ...

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Privatfrickler schrieb:
> Dann sei froh, dass du damals nicht an Rust geraten bist.

Das wäre mir damals auch egal gewesen.
Verstanden hätte ich es sowieso nicht.

Ich hatte die "Visual Basic 6 Einsteiger Edition" und ein Buch von "DATA 
BECKER". Absolute Qualitätslektüre, ich weiß, aber für einen 
14-Jährigen, der sich da ganz allein ohne Hilfe durchboxen muss (bzw. 
will), sind solch bebilderte Anleitungen verdammt nützlich.

Habe ich damit "programmieren" gelernt? Sicherlich nicht.
Aber aus der Zeit stammt ein kleines Programm, was bei meinem Vater noch 
immer täglich im Einsatz ist. Und darauf bin ich ein kleines bisschen 
stolz. ;-)

Autor: Privatfrickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Privatfrickler schrieb:
>> Dann sei froh, dass du damals nicht an Rust geraten bist.
>
> Das wäre mir damals auch egal gewesen.
> Verstanden hätte ich es sowieso nicht.

Das meinte ich damit.

Da war PASCAL doch geradezu eine Wohltat gegen.

> Ich hatte die "Visual Basic 6 Einsteiger Edition" und ein Buch von "DATA
> BECKER". Absolute Qualitätslektüre,

Du wirst es nicht glauben, ich habe noch PC intern 4 - 
Systemprogrammierung. Ein fast 1400 Seiten Wälzer mit CD mit zig 
Assembler, C und PASCAL Listings. Kein schlechtes Buch!

> ich weiß, aber für einen
> 14-Jährigen, der sich da ganz allein ohne Hilfe durchboxen muss (bzw.
> will), sind solch bebilderte Anleitungen verdammt nützlich.
>
> Habe ich damit "programmieren" gelernt? Sicherlich nicht.
> Aber aus der Zeit stammt ein kleines Programm, was bei meinem Vater noch
> immer täglich im Einsatz ist. Und darauf bin ich ein kleines bisschen
> stolz. ;-)

Mit GFA BASIC auf dem AMIGA hab ich damals viele kleinere Progrämmchen 
geschafft. GFA BASIC fand ich damals schon sehr angenehm. Ich meine aus 
der Erinnerung, es ließ sich sogar kompilieren und lief dann flott.

Autor: Privatfrickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PC intern 4 - Systemprogrammierung war ein DATA Becker Buch vom Autor 
Michael Tischer Erstauflage 1994.

Autor: Privatfrickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Ich hatte die "Visual Basic 6 Einsteiger Edition" und ein Buch von "DATA
> BECKER". Absolute Qualitätslektüre, ich weiß, aber für einen
> 14-Jährigen, der sich da ganz allein ohne Hilfe durchboxen muss (bzw.
> will), sind solch bebilderte Anleitungen verdammt nützlich.
>
> Habe ich damit "programmieren" gelernt? Sicherlich nicht.

Gerade nochmal recherchiert. Data Becker musste 2014 dicht machen.

https://www.heise.de/newsticker/meldung/Data-Becke...

Hier Jürgen Kuri dazu
https://plus.google.com/+J%C3%BCrgenKuri/posts/BCszMPpX9RS

Autor: W.S. (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Alex G. schrieb:
> Glaube du zählst zu den wenigen Personen welche sich beim Befassen mit
> einer neuen Sprache, als erstes die Backus Naur Form sehen wollen...
>
> Btw. hat es mich nur eine Google Query gekostet, zu finden was du
> scheinbar suchst

Du hast den Sinn nicht erfasst.

Wenn ich unbedingt wollte, könnte ich mich selber auf die Suche machen, 
aber hier geht es nicht darum, was ich will, sondern darum, was die 
Rust-Leute ihren eventuellen Interessenten anbieten, also wie sich Rust 
dem Publikum präsentiert.

Da wäre eine straffe Definition der Sprache - eben per BNF - an 
allererster Stelle extrem hilfreich, um eine neue Sprache sachgerecht 
einzuführen und sie auf saubere Logik (oder eben deren Fehlen) 
abzuklopfen.

Was man dort jedoch sieht, ist Gelaber und Geschwurbel. Die PR-Leute von 
Rust schaffen es nicht, dem Leser einen sachlichen Überblick zu geben 
(weil sie den wohl selber nicht haben) und stochern stattdessen in 
Details herum.

Nochmal: die Sprache per BNF darzustellen ist ein Prüfstein für die 
Sprache selbst. Dort kommt es nämlich ganz schnell heraus, wenn es an 
innerer Logik fehlt und stattdessen mit Sonderfällen und "hier ist das 
eben so" gearbeitet wird.

W.S.

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Denke schon die Tatsache dass es Rust Belt gibt zeigt dass es nicht 
grade schlecht um die Logik steht.
Und nochmal, für diese Sache interessieren sich theoretische 
Informatiker, aber kaum Programmierer und letztere sind es die Rust 
braucht und anlocken muss um erfolgreich zu sein!

Btw. wenn ich auf Java.com gehe finde ich sowas dazu auch nicht.
Was ist die Referenzseite zu C oder C++ wo die Theorie angeblich an 
erster Stelle steht?

: Bearbeitet durch User
Beitrag #5517631 wurde von einem Moderator gelöscht.
Autor: Alex G. (dragongamer)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nichteinmal die Logik Sprache schlechthin, Matlab stellt die Grammatik 
in ihrer Doku an erster Stelle!
https://de.mathworks.com/help/matlab/

: Wiederhergestellt durch Moderator
Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:
> Ich hatte die "Visual Basic 6 Einsteiger Edition" und ein Buch von "DATA
> BECKER".

Siehste, andere hatten nur "Programmieren mit dem Mikrocomputer KC85" 
oder so. Das war aber nur ein dünnes Heftchen. Aber es kam ganz viel 
GOTO darin vor. ;-)

Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
W.S. schrieb:
> Da wäre eine straffe Definition der Sprache - eben per BNF - an
> allererster Stelle extrem hilfreich

Bei allem Geschwurbel, was Du hier abgibst, aber: Das fehlt mir bisher 
auch, um mal einen Überblick über die Sprache zu bekommen.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Siehste, andere hatten nur "Programmieren mit dem Mikrocomputer KC85"
> oder so.

Och, auf dem hab ich auch ein bisschen BASIC gemacht.
Hauptsächlich aber DIGGER gespielt. :-)

Das war aber alles lange nach der Wende, die Bücher existieren schon 
lange nicht mehr und die KCs sind mit dem Tod der Station Junger 
Techniker alle entsorgt worden. Leider, ich hätte gerne einen davon 
gehabt.

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> W.S. schrieb:
>> Da wäre eine straffe Definition der Sprache - eben per BNF - an
>> allererster Stelle extrem hilfreich
>
> Bei allem Geschwurbel, was Du hier abgibst, aber: Das fehlt mir bisher
> auch, um mal einen Überblick über die Sprache zu bekommen.

Ehrlich gesagt halte ich es persönlich anhand meiner Erfahrungen aus dem 
Grundstudium, für nahezu unmöglich daraus einnechtes Gefühl dafür zu 
bekommen wie man mit der Sprache tatsächlich programmiert und ist es 
nicht das was zählt?

Es gab eine Reihe von Versuchen hochsichere Sprachen mathematisch zu 
bauen. Die sahen in solchen normierten Formen auch sehr schön aus. Den 
Bekanntheitsgrad von Rust konnte davon aber nichts erlangen weil sie 
einfach nicht wirklich praxistauglich sind.

Wie auch immer - enthält dieser Link nicht die Information die du 
brauchst?
https://doc.rust-lang.org/grammar.html

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Alex G. schrieb:
> Btw. wenn ich auf Java.com gehe finde ich sowas dazu auch nicht.
> Was ist die Referenzseite zu C oder C++ wo die Theorie angeblich an
> erster Stelle steht?

Du missverstehst da etwas absichtlich.

Erstens sind C, C++ und Java etablierte Sprachen, die müssen sich mit 
anderen Sprachen nicht mehr messen lassen. Deren Vor- und Nachteile sind 
bekannt.

Zweitens sind all diese Sprachen in einer Zeit entstanden, als eine 
vollständige, lückenlose Definition nicht notwendig war. Daraus folgen 
ziemlich hässliche Altlasten und komplexe formale Definitionen.

Neue Sprachen müssen mehr Anforderungen erfüllen als alte Sprachen, denn 
die Welt hat sich geändert. Sonderlocken im Parser drehen zu müssen ist 
nicht mehr akzeptabel, eine klare BNF macht das deutlich. 
Nebenläufigkeit und Speichermodelle sind ordentlich und klar in einer 
Weise zu definieren, die effiziente Implementationen ermöglicht. 
Undefiniertes Verhalten ist inakzeptabel.

Wenn man das hinkriegt, dann kann man seine Nische gründlich besetzen. 
Kotlin hat das für Android bereits getan. Rust nicht.

Btw: https://kotlinlang.org/docs/reference/grammar.html

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nagut, wenn du meinst dass die potentielle Nutzerschaft wirklich darauf 
achtet bzw. sich das durchlesen würde...

EDIT: Willst du mich verarschen oder so?
Dein Kotlin hat "grammar" exakt genau so wenig an erster Stelle der Doku 
wie Rust!

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> EDIT: Willst du mich verarschen oder so?

Nein, ich habe zum Vergleich auf die BNF von Kotlin verlinkt. Da sind 
keine FIXMEs und längliche Erläuterungen drin.

Wenn du aber so angepisst reagierst, naja... schlaf dich erstmal aus.

: Bearbeitet durch User
Autor: Privatfrickler (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Ich pick mir mal noch einen Absatz aus dem rustbook heraus.

https://rust-lang-de.github.io/rustbook-de/Variabl...

"Fast jedes nicht-triviale Rust-Programm verwendet Variablenbindungen. 
Sie sehen so aus:

fn main() {
    let x = 5;
}

fn main() { in jedes Beispiel zu schreiben ist ein wenig mühsam, also 
werden wir es in Zukunft weglassen. Falls du diese Beispiele 
ausprobierst, stelle sicher, dass du deinen Code in einer main() Methode 
schreibst (und nicht wie wir weglässt). Ansonsten bekommst du einen 
Fehler.

In vielen Sprachen wird das eine Variable genannt, aber Rusts 
Variablenbindungen haben ein paar Tricks im Ärmel. Zum Beispiel ist die 
linke Seite der let Anweisung ein ‘Muster’ und nicht einfach nur ein 
Variablenname. Das bedeutet, dass wir solche Sachen tun können:

# #![allow(unused_variables)]
#fn main() {
let (x, y) = (1, 2);
"

Was um alles in der Welt denkt sich dieser Schreiberling hier bei seinen 
Ausführungen?

Anstatt mal den Begriff "Variablenbindung" vor dessen Verwendung zu 
definieren, haut er mir gleich mal ein Beispiel um die Ohren, nämlich 
dieses hier

fn main() {
    let x = 5;
}

und geht anschließend überhaupt nicht mehr darauf ein. Statt dessen 
macht er einen auf "ich bin ein fauler Schreiber" und lässt gleich mal 
ein wichtiges Bestandteil zum NEULERNEN einer Programmiersprache weg. In 
C wäre das dann in etwa so:

Hier mal ein C-Programm für euch

printf("Hallo Welt")

Das Unwichtige mit dem main() und so hab ich mal weggelassen, weil ich 
(euer Tutor) bin ja schreibfaul (hihihi). Wenn ihr (Dooflinge) also mein 
Programm compilieren wollt, vergesst doch bitte nicht alles 
hinzuzufügen, was es bei einem ORDENTLICHEN C-Programm eben so braucht.

Da fällt mir wirklich die Hutkrempe herunter.

Dann der Halbsatz

"In vielen Sprachen wird das eine Variable genannt, ..."

" ... aber Rusts Variablenbindungen haben ein paar Tricks im Ärmel."

Was ist denn das für ein Schwafler, der so schreibt? Klingt als Leser 
wie "Hey! Hier is uns're supergoile Proggersprache mit den affengeilen 
Tricks im Ärmel"

Dann dieses tendenziöse "ich kann's euch nich erklären, darum bringe ich 
lieber ein Beispiel".

Da isses wieder:

"Zum Beispiel ist die linke Seite der let Anweisung ein ‘Muster’ und 
nicht einfach nur ein Variablenname. Das bedeutet, dass wir solche 
Sachen tun können:"

Jetzt müsste man ihn gleich löchern und fragen, erklären Sie doch mal 
genau, was ein Muster ist.

"Das bedeutet, dass wir solche Sachen tun können:"

Das bedeutet, DU lieber Schreiberling kannst NICHT erklären! DAS 
bedeutet das!

Das jenes hier

let x = 5;

so gar nicht ausschaut wie das Geklammerte hier (eben wegen dieser 
Klammern)

let (x, y) = (1, 2);

lässt er natürlich unter den Tisch fallen. Weil er das erste Beispiel 
unter den Tisch fallen lies und nix dazu erklärte. Vielleicht gab es 
auch gar nix dazu zu erklären, weil es einfach eine Variablendeklaration 
ist und sonst gar nix. Aber nein, er schrieb ja

"In vielen Sprachen wird das eine Variable genannt, "

legt den Schluss nahe, bei Rust ist das eben NICHT so oder vielleicht 
doch und der Autor weiß es einfach selber nicht so genau.

---

Und so gehen diese Erklärungen, d.h. dieses Geschwurbel weiter und 
weiter. Ich komm da keine paar Zeilen weit, ohne dass mir der 
Widerspruch in den Fingern juckt.

Vielleicht liegt es auch an diesem elendigen auf DU-und-DU gemache 
ICH-KENN-DICH-PERSÖNLICH Schreibstil, der immer öfter um sich greift, 
siehe

"Wenn du die zwei geschweiften Klammern ({}, manche nennen sie 
Schnurrbärte..) in deinem auszugebenden String einfügst, "

Sorry, aber ich möchte als Leser NICHT so angesprochen werden! Das stört 
mich auch oftmals an diesen YouTube-Vorträgen, in denen Studies gerne 
auf Kumpel machen, um mir was zu vermitteln. Gute Vorträge werden so 
nicht gesprochen. Dieser ASTA-Speech nervt mich total ab. Ich bekomme 
Wutstarre.

Korrekt heißt das so

Ein auszugebender String wird in geschweifte Klammern gesetzt.
Rust interpretiert die Klammern als Anweisung, an dieser Stelle einen 
Wert einzufügen.

Nix "wenn DU die" ... und "Schnurrbärte"

Dödel!

Beitrag #5517735 wurde von einem Moderator gelöscht.
Beitrag #5517752 wurde von einem Moderator gelöscht.
Autor: Yalu X. (yalu) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Alex G. schrieb:
> Karl K. schrieb:
>> W.S. schrieb:
>>> Da wäre eine straffe Definition der Sprache - eben per BNF - an
>>> allererster Stelle extrem hilfreich
>>
>> Bei allem Geschwurbel, was Du hier abgibst, aber: Das fehlt mir bisher
>> auch, um mal einen Überblick über die Sprache zu bekommen.
>
> Ehrlich gesagt halte ich es persönlich anhand meiner Erfahrungen aus dem
> Grundstudium, für nahezu unmöglich daraus einnechtes Gefühl dafür zu
> bekommen wie man mit der Sprache tatsächlich programmiert und ist es
> nicht das was zählt?

Mir geht es bzgl. der BNF ähnlich wie Alex:

Um mir einen ersten Eindruck über die Syntax einer Sprache zu
verschaffen, möchte ich ein paar aussagekräftige Codebeispiele und keine
formale Syntaxbeschreibung per BNF. Diese steht in Lehrbüchern – wenn
überhaupt vorhanden – üblicherweise ganz am Ende. Ich habe diese noch
nie komplett durchgelesen, sondern nutze sie allenfalls dann, wenn ich
eine konkrete Frage zu irgend einem syntaktischen Detail habe.

Um einen ersten Eindruck über die Semantik der Sprache zu bekommen,
möchte ich eine kurze Erläuterung der wichtigsten Eigenschaften in Prosa
und keine Semantikbeschreibung mittels abstrakter mathematischer
Modelle. Eine solche Beschreibung gibt es sowieso nur für die wenigsten
Programmiersprachen.

S. R. schrieb:
> Nein, ich habe zum Vergleich auf die BNF von Kotlin verlinkt. Da sind
> keine FIXMEs und längliche Erläuterungen drin.

Im Anhang findest du entsprechendes für Rust, ebenfalls ohne FIXMEs und
längliche Erläuterungen.

Beitrag #5517760 wurde von einem Moderator gelöscht.
Beitrag #5517761 wurde von einem Moderator gelöscht.
Beitrag #5517762 wurde von einem Moderator gelöscht.
Beitrag #5517763 wurde von einem Moderator gelöscht.
Beitrag #5517764 wurde von einem Moderator gelöscht.
Beitrag #5517765 wurde von einem Moderator gelöscht.
Beitrag #5517766 wurde von einem Moderator gelöscht.
Beitrag #5517767 wurde von einem Moderator gelöscht.
Beitrag #5517768 wurde von einem Moderator gelöscht.
Beitrag #5517771 wurde von einem Moderator gelöscht.
Beitrag #5517772 wurde von einem Moderator gelöscht.
Beitrag #5517773 wurde von einem Moderator gelöscht.
Beitrag #5517774 wurde von einem Moderator gelöscht.
Beitrag #5517778 wurde von einem Moderator gelöscht.
Beitrag #5517780 wurde von einem Moderator gelöscht.
Beitrag #5517782 wurde von einem Moderator gelöscht.
Beitrag #5517784 wurde von einem Moderator gelöscht.
Beitrag #5517785 wurde von einem Moderator gelöscht.
Beitrag #5517786 wurde von einem Moderator gelöscht.
Beitrag #5517787 wurde von einem Moderator gelöscht.
Beitrag #5517788 wurde von einem Moderator gelöscht.
Beitrag #5517789 wurde von einem Moderator gelöscht.
Beitrag #5517792 wurde von einem Moderator gelöscht.
Beitrag #5517794 wurde von einem Moderator gelöscht.
Beitrag #5517795 wurde von einem Moderator gelöscht.
Beitrag #5517799 wurde von einem Moderator gelöscht.
Beitrag #5517801 wurde von einem Moderator gelöscht.
Beitrag #5517804 wurde von einem Moderator gelöscht.
Beitrag #5517805 wurde von einem Moderator gelöscht.
Beitrag #5517806 wurde von einem Moderator gelöscht.
Beitrag #5517807 wurde von einem Moderator gelöscht.
Beitrag #5517808 wurde von einem Moderator gelöscht.
Beitrag #5517809 wurde von einem Moderator gelöscht.
Beitrag #5517810 wurde von einem Moderator gelöscht.
Beitrag #5517811 wurde von einem Moderator gelöscht.
Beitrag #5517813 wurde von einem Moderator gelöscht.
Beitrag #5517814 wurde von einem Moderator gelöscht.
Beitrag #5517815 wurde von einem Moderator gelöscht.
Beitrag #5517816 wurde von einem Moderator gelöscht.
Beitrag #5517817 wurde von einem Moderator gelöscht.
Beitrag #5517819 wurde von einem Moderator gelöscht.
Beitrag #5517820 wurde von einem Moderator gelöscht.
Beitrag #5517821 wurde von einem Moderator gelöscht.
Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@privatfrickler:

Die deutsche Übersetzung des Rust-Handbuchs ist uralt. Nimm besser
dieses hier

  https://doc.rust-lang.org/book/2018-edition/

oder – falls dir das ebenfalls nicht zusagt – such dir eins von hier
aus, das besser deinem Geschmack entspricht:

  https://hackr.io/tutorials/learn-rust

Beitrag #5517823 wurde von einem Moderator gelöscht.
Beitrag #5517824 wurde von einem Moderator gelöscht.
Beitrag #5517825 wurde von einem Moderator gelöscht.
Beitrag #5517826 wurde von einem Moderator gelöscht.
Beitrag #5517827 wurde von einem Moderator gelöscht.
Beitrag #5517828 wurde von einem Moderator gelöscht.
Beitrag #5517829 wurde von einem Moderator gelöscht.
Beitrag #5517830 wurde von einem Moderator gelöscht.
Beitrag #5517831 wurde von einem Moderator gelöscht.
Beitrag #5517832 wurde von einem Moderator gelöscht.
Beitrag #5517833 wurde von einem Moderator gelöscht.
Beitrag #5517834 wurde von einem Moderator gelöscht.
Beitrag #5517836 wurde von einem Moderator gelöscht.
Beitrag #5517837 wurde von einem Moderator gelöscht.
Beitrag #5517838 wurde von einem Moderator gelöscht.
Beitrag #5517839 wurde von einem Moderator gelöscht.
Beitrag #5517840 wurde von einem Moderator gelöscht.
Beitrag #5517842 wurde von einem Moderator gelöscht.
Beitrag #5517843 wurde von einem Moderator gelöscht.
Beitrag #5517844 wurde von einem Moderator gelöscht.
Beitrag #5517845 wurde von einem Moderator gelöscht.
Beitrag #5517847 wurde von einem Moderator gelöscht.
Beitrag #5517848 wurde von einem Moderator gelöscht.
Beitrag #5517850 wurde von einem Moderator gelöscht.
Beitrag #5517851 wurde von einem Moderator gelöscht.
Beitrag #5517852 wurde von einem Moderator gelöscht.
Beitrag #5517853 wurde von einem Moderator gelöscht.
Beitrag #5517855 wurde von einem Moderator gelöscht.
Beitrag #5517857 wurde von einem Moderator gelöscht.
Beitrag #5517858 wurde von einem Moderator gelöscht.
Beitrag #5517859 wurde von einem Moderator gelöscht.
Beitrag #5517860 wurde von einem Moderator gelöscht.
Beitrag #5517862 wurde von einem Moderator gelöscht.
Beitrag #5517863 wurde von einem Moderator gelöscht.
Beitrag #5517864 wurde von einem Moderator gelöscht.
Beitrag #5517865 wurde von einem Moderator gelöscht.
Beitrag #5517867 wurde von einem Moderator gelöscht.
Beitrag #5517868 wurde von einem Moderator gelöscht.
Beitrag #5517869 wurde von einem Moderator gelöscht.
Beitrag #5517870 wurde von einem Moderator gelöscht.
Beitrag #5517871 wurde von einem Moderator gelöscht.
Beitrag #5517872 wurde von einem Moderator gelöscht.
Beitrag #5517873 wurde von einem Moderator gelöscht.
Beitrag #5517874 wurde von einem Moderator gelöscht.
Beitrag #5517875 wurde von einem Moderator gelöscht.
Beitrag #5517876 wurde von einem Moderator gelöscht.
Beitrag #5517877 wurde von einem Moderator gelöscht.
Beitrag #5517878 wurde von einem Moderator gelöscht.
Beitrag #5517880 wurde von einem Moderator gelöscht.
Autor: Privatfrickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> @privatfrickler:
>
> Die deutsche Übersetzung des Rust-Handbuchs ist uralt. Nimm besser
> dieses hier
>
>   https://doc.rust-lang.org/book/2018-edition/
>
> oder – falls dir das ebenfalls nicht zusagt – such dir eins von hier
> aus, das besser deinem Geschmack entspricht:
>
>   https://hackr.io/tutorials/learn-rust

@Yalu

Danke für deinen Hinweis. Werde mir das mit etwas Abstand nochmals 
genauer betrachten. Ich bin gar nicht so extrem pingelig wie es 
vielleicht den Anschein weckt. Ich merke halt sehr schnell ob ein Text 
mich motiviert oder aber wie bei dem Geschwafel in mir das völlige 
Gegenteil bewirkt.

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Privatfrickler schrieb:

> "let y = &x[0];"
>
> y sei nun das erste Element des Vektors x ?

ja, aber viel weitreichender, als man sich so denkt? Denn, wenn ich das 
richtig sehe, kann man jetzt in x[0] nicht mehr schreiben?

vlg
 Timm

Autor: Kaj (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Timm R. schrieb:
> ja, aber viel weitreichender, als man sich so denkt? Denn, wenn ich das
> richtig sehe, kann man jetzt in x[0] nicht mehr schreiben?
Es geht sogar noch weiter: Du kannst in keins der Elemente von x 
schreiben.
fn main() {
    let mut x = vec!["Hallo", "Welt"];
    let y = &x[0];

    x[0] = "Hello";
    x[1] = "World";

    println!("{:?}", x);
}
error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:5
  |
3 |     let y = &x[0];
  |              - immutable borrow occurs here
4 | 
5 |     x[0] = "Hello";
  |     ^ mutable borrow occurs here
...
9 | }
  | - immutable borrow ends here

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:6:5
  |
3 |     let y = &x[0];
  |              - immutable borrow occurs here
...
6 |     x[1] = "World";
  |     ^ mutable borrow occurs here
...
9 | }
  | - immutable borrow ends here

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0502`.

Was du aber machen kannst: Mittels shadowing ein neues x anlegen.
fn main() {
    let mut x = vec!["Hallo", "Welt"];
    let y = &x[0];

    let mut x = vec!["Hello", x[1]];

    println!("{:?}", x);
}

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm,

gut, in C++ kann man einen std::vector gar nicht mit einem structured 
binding verarzten, in sofern ...

Aber andererseits? Wegen einem Binding gleich das ganze Objekt 
blockieren?

Ich glaube, das gefällt mir nicht.

vlg

 Timm

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo Alex,

Alex G. schrieb:
> Timm R. schrieb:
>> Könnte sich denn vielleicht einer der Rust-kundigen und C++-kundigen
>> erbarmen, mal ein minimales Beispiel mit c++ Pointer-Katastrophe zu
>> zeigen und wie es in Rust besser läuft? Das wäre doch sicher für mehrere
>> Rist-Unkundige interessant und erhellend? Mir fehlt da einfach die
>> Vorstellungskraft.
>
> Hmm, du hättest bei meinem Vortrag vor ein paar Wochen über Rust dabei
> sein sollen.
> Dafür habe ich den Heartbleed Bug in C++ nachprogrammiert - und dann
> versucht ihn auch unter Rust zu programmieren (ohne Unsafe).

also, erstmal danke für das instruktive Programm. Ja, das ist ein 
Beispiel für einen echten Sicherheitsgewinn. Ich möchte aber doch 
anmerken, m.h. tat das ja schon, wenn auch etwas stoffelig, dass das 
kein C++ ist.

Vielmehr wird ziemlich klar, dass auch in diesem Fall richtiges C++ das 
Problem schon gelöst hätte.

Yalus  Beispiel ist zwar valide. Aber auch da bin ich unschlüssig, ob 
den Tausch Brauchbarkeit der Features gegen eine bedingt relevante 
Sicherheit profitabel finde.

vlg

 Timm

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rust ist ganz klar einschränkend - bietet aber wiederum Strukturen um 
solche Einschränkungen ganz kontrolliert wieder aufzuheben.
Z.B. die CELL Datenstruktur.

Auch wenn ich hiermit meinen Realnamen preisgebe - hier habe ich einen 
Blogeintrag über Rust und RustBelt geschrieben: 
https://blog.mi.hdm-stuttgart.de/index.php/2018/07...
Das enthält auch eine zusammenhängende Ausführung des Grundgedanken 
dieser Sprache mit Beispielen,

Beitrag #5518962 wurde von einem Moderator gelöscht.
Beitrag #5518963 wurde von einem Moderator gelöscht.
Beitrag #5518964 wurde von einem Moderator gelöscht.
Beitrag #5518966 wurde von einem Moderator gelöscht.
Autor: Kaj (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Timm R. schrieb:
> Wegen einem Binding gleich das ganze Objekt
> blockieren?
>
> Ich glaube, das gefällt mir nicht.
Es ist ja nicht (vollstaendig) blockiert. Lesen kannst du noch ohne 
Probleme.
fn main() {
    let mut x = vec!["Hallo", "Welt"];
    let y = &x[0];

    println!("x: `{:?}`", x);
    println!("y: `{:?}`", y);
}
x: `["Hallo", "Welt"]`
y: `"Hallo"`

Ja, das Ownershipkonzept erfordert etwas umdenken, verglichen mit C und 
C++. Aber das Umdenken zahlt sich aus.

Beitrag #5518969 wurde von einem Moderator gelöscht.
Beitrag #5518970 wurde von einem Moderator gelöscht.
Beitrag #5518971 wurde von einem Moderator gelöscht.
Beitrag #5518973 wurde von einem Moderator gelöscht.
Beitrag #5518974 wurde von einem Moderator gelöscht.
Beitrag #5518975 wurde von einem Moderator gelöscht.
Beitrag #5518979 wurde von einem Moderator gelöscht.
Beitrag #5518980 wurde von einem Moderator gelöscht.
Beitrag #5518982 wurde von einem Moderator gelöscht.
Beitrag #5518988 wurde von einem Moderator gelöscht.
Beitrag #5518991 wurde von einem Moderator gelöscht.
Beitrag #5518994 wurde von einem Moderator gelöscht.
Beitrag #5518995 wurde von einem Moderator gelöscht.
Beitrag #5518996 wurde von einem Moderator gelöscht.
Beitrag #5518997 wurde von einem Moderator gelöscht.
Beitrag #5518998 wurde von einem Moderator gelöscht.
Beitrag #5518999 wurde von einem Moderator gelöscht.
Beitrag #5519000 wurde von einem Moderator gelöscht.
Beitrag #5519001 wurde von einem Moderator gelöscht.
Beitrag #5519003 wurde von einem Moderator gelöscht.
Beitrag #5519004 wurde von einem Moderator gelöscht.
Beitrag #5519005 wurde von einem Moderator gelöscht.
Beitrag #5519006 wurde von einem Moderator gelöscht.
Beitrag #5519007 wurde von einem Moderator gelöscht.
Beitrag #5519008 wurde von einem Moderator gelöscht.
Beitrag #5519009 wurde von einem Moderator gelöscht.
Beitrag #5519010 wurde von einem Moderator gelöscht.
Beitrag #5519011 wurde von einem Moderator gelöscht.
Beitrag #5519013 wurde von einem Moderator gelöscht.
Beitrag #5519014 wurde von einem Moderator gelöscht.
Beitrag #5519015 wurde von einem Moderator gelöscht.
Beitrag #5519016 wurde von einem Moderator gelöscht.
Beitrag #5519017 wurde von einem Moderator gelöscht.
Beitrag #5519018 wurde von einem Moderator gelöscht.
Beitrag #5519019 wurde von einem Moderator gelöscht.
Beitrag #5519020 wurde von einem Moderator gelöscht.
Beitrag #5519021 wurde von einem Moderator gelöscht.
Beitrag #5519022 wurde von einem Moderator gelöscht.
Beitrag #5519024 wurde von einem Moderator gelöscht.
Beitrag #5519026 wurde von einem Moderator gelöscht.
Beitrag #5519027 wurde von einem Moderator gelöscht.
Beitrag #5519029 wurde von einem Moderator gelöscht.
Beitrag #5519030 wurde von einem Moderator gelöscht.
Beitrag #5519031 wurde von einem Moderator gelöscht.
Beitrag #5519032 wurde von einem Moderator gelöscht.
Beitrag #5519033 wurde von einem Moderator gelöscht.
Beitrag #5519034 wurde von einem Moderator gelöscht.
Beitrag #5519035 wurde von einem Moderator gelöscht.
Beitrag #5519037 wurde von einem Moderator gelöscht.
Beitrag #5519039 wurde von einem Moderator gelöscht.
Beitrag #5519040 wurde von einem Moderator gelöscht.
Beitrag #5519041 wurde von einem Moderator gelöscht.
Beitrag #5519042 wurde von einem Moderator gelöscht.
Beitrag #5519046 wurde von einem Moderator gelöscht.
Beitrag #5519047 wurde von einem Moderator gelöscht.
Beitrag #5519048 wurde von einem Moderator gelöscht.
Beitrag #5519050 wurde von einem Moderator gelöscht.
Beitrag #5519051 wurde von einem Moderator gelöscht.
Beitrag #5519053 wurde von einem Moderator gelöscht.
Beitrag #5519054 wurde von einem Moderator gelöscht.
Beitrag #5519057 wurde von einem Moderator gelöscht.
Beitrag #5519059 wurde von einem Moderator gelöscht.
Beitrag #5519060 wurde von einem Moderator gelöscht.
Beitrag #5519061 wurde von einem Moderator gelöscht.
Beitrag #5519063 wurde von einem Moderator gelöscht.
Beitrag #5519065 wurde von einem Moderator gelöscht.
Beitrag #5519067 wurde von einem Moderator gelöscht.
Beitrag #5519069 wurde von einem Moderator gelöscht.
Beitrag #5519072 wurde von einem Moderator gelöscht.
Beitrag #5519073 wurde von einem Moderator gelöscht.
Beitrag #5519074 wurde von einem Moderator gelöscht.
Beitrag #5519075 wurde von einem Moderator gelöscht.
Beitrag #5519079 wurde von einem Moderator gelöscht.
Beitrag #5519080 wurde von einem Moderator gelöscht.
Beitrag #5519082 wurde von einem Moderator gelöscht.
Beitrag #5519083 wurde von einem Moderator gelöscht.
Beitrag #5519085 wurde von einem Moderator gelöscht.
Beitrag #5519086 wurde von einem Moderator gelöscht.
Beitrag #5519136 wurde von einem Moderator gelöscht.
Beitrag #5519137 wurde von einem Moderator gelöscht.
Beitrag #5519138 wurde von einem Moderator gelöscht.
Beitrag #5519139 wurde von einem Moderator gelöscht.
Beitrag #5519140 wurde von einem Moderator gelöscht.
Beitrag #5519142 wurde von einem Moderator gelöscht.
Beitrag #5519143 wurde von einem Moderator gelöscht.
Beitrag #5519144 wurde von einem Moderator gelöscht.
Beitrag #5519145 wurde von einem Moderator gelöscht.
Beitrag #5519146 wurde von einem Moderator gelöscht.
Beitrag #5519147 wurde von einem Moderator gelöscht.
Beitrag #5519148 wurde von einem Moderator gelöscht.
Beitrag #5519149 wurde von einem Moderator gelöscht.
Beitrag #5519150 wurde von einem Moderator gelöscht.
Beitrag #5519151 wurde von einem Moderator gelöscht.
Beitrag #5519152 wurde von einem Moderator gelöscht.
Beitrag #5519153 wurde von einem Moderator gelöscht.
Beitrag #5519155 wurde von einem Moderator gelöscht.
Beitrag #5519156 wurde von einem Moderator gelöscht.
Beitrag #5519157 wurde von einem Moderator gelöscht.
Beitrag #5519158 wurde von einem Moderator gelöscht.
Beitrag #5519159 wurde von einem Moderator gelöscht.
Beitrag #5519164 wurde von einem Moderator gelöscht.
Beitrag #5519165 wurde von einem Moderator gelöscht.
Beitrag #5519167 wurde von einem Moderator gelöscht.
Beitrag #5519168 wurde von einem Moderator gelöscht.
Beitrag #5519169 wurde von einem Moderator gelöscht.
Beitrag #5519170 wurde von einem Moderator gelöscht.
Beitrag #5519171 wurde von einem Moderator gelöscht.
Beitrag #5519172 wurde von einem Moderator gelöscht.
Beitrag #5519173 wurde von einem Moderator gelöscht.
Beitrag #5519174 wurde von einem Moderator gelöscht.
Beitrag #5519176 wurde von einem Moderator gelöscht.
Beitrag #5519177 wurde von einem Moderator gelöscht.
Beitrag #5519178 wurde von einem Moderator gelöscht.
Beitrag #5519179 wurde von einem Moderator gelöscht.
Beitrag #5519180 wurde von einem Moderator gelöscht.
Beitrag #5519181 wurde von einem Moderator gelöscht.
Beitrag #5519182 wurde von einem Moderator gelöscht.
Beitrag #5519184 wurde von einem Moderator gelöscht.
Beitrag #5519185 wurde von einem Moderator gelöscht.
Beitrag #5519186 wurde von einem Moderator gelöscht.
Beitrag #5519187 wurde von einem Moderator gelöscht.
Beitrag #5519189 wurde von einem Moderator gelöscht.
Beitrag #5519194 wurde von einem Moderator gelöscht.
Beitrag #5519203 wurde von einem Moderator gelöscht.
Beitrag #5519204 wurde von einem Moderator gelöscht.
Beitrag #5519205 wurde von einem Moderator gelöscht.
Beitrag #5519206 wurde von einem Moderator gelöscht.
Beitrag #5519207 wurde von einem Moderator gelöscht.
Beitrag #5519208 wurde von einem Moderator gelöscht.
Beitrag #5519209 wurde von einem Moderator gelöscht.
Beitrag #5519210 wurde von einem Moderator gelöscht.
Beitrag #5519211 wurde von einem Moderator gelöscht.
Beitrag #5519223 wurde von einem Moderator gelöscht.
Beitrag #5519224 wurde von einem Moderator gelöscht.
Beitrag #5519225 wurde von einem Moderator gelöscht.
Beitrag #5519226 wurde von einem Moderator gelöscht.
Beitrag #5519227 wurde von einem Moderator gelöscht.
Beitrag #5519231 wurde von einem Moderator gelöscht.
Beitrag #5519232 wurde von einem Moderator gelöscht.
Beitrag #5519233 wurde von einem Moderator gelöscht.
Beitrag #5519234 wurde von einem Moderator gelöscht.
Beitrag #5519235 wurde von einem Moderator gelöscht.
Beitrag #5519236 wurde von einem Moderator gelöscht.
Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Kaj schrieb:
> Timm R. schrieb:
>> Wegen einem Binding gleich das ganze Objekt
>> blockieren?
>>
>> Ich glaube, das gefällt mir nicht.
> Es ist ja nicht (vollstaendig) blockiert. Lesen kannst du noch ohne
> Probleme.
Als weiterfuehrung zu meiner vorherigen Antwort:

Timm R. schrieb:
> gut, in C++ kann man einen std::vector gar nicht mit einem structured
> binding verarzten, in sofern ...
>
> Aber andererseits? Wegen einem Binding gleich das ganze Objekt
> blockieren?
>
> Ich glaube, das gefällt mir nicht.
Spiel einfach mal ein bisschen mit Rust. Theoretisch kannst du Rust 
'einfach' als C/C++ mit invertierten Regeln betrachten (grob gesagt).

==================================================

Beispiel 1, C/C++:
void foo(void)
{
    //...
}
Diese Funktion ist praktisch fuer jede andere Uebersetzungseinheit 
sichtbar, da sie nicht static ist (ja, es muss noch die .h-Datei 
eingebunden werden, ich weiss).

Beispiel 1, Rust:
fn foo() {
    //...
}
Diese Funktion ist nur innerhalb der Datei in der sie steht, sichtbar, 
da sie nicht explizit sichtbar gemacht wurde. Soll sie auch in anderen 
Uebersetzungseinheit sichtbar sein, dann muss das so aussehen:
pub fn foo() {
    //...
}

C und C++: Sichtbarkeit muss explizit eingeschraenkt werden.
Rust: Sichtbarkeit muss explizit ausgeweitet werden.

==================================================

Beispiel 2, C/C++:
int main(void)
{
    int a = 0;
    // ...
    return 0;
}
Die Variable a kann beschrieben werden, da sie nicht const ist.

Beispiel 2, Rust:
fn main()
{
    let a: i32 = 0;
    // ...
    return 0;
}
Die Variable a ist read-only (aber nicht const(!)), da sie nicht mut 
ist. Das heisst: man kann a mittels shadowing ueberdecken. Das geht bei 
einer Konstanten nicht.
fn main() {
    const A:i32 = 42;
    let A: i32 = 43;
}

error[E0005]: refutable pattern in local binding: `_` not covered
 --> src/main.rs:3:9
  |
3 |     let A: i32 = 43;
  |         ^ interpreted as a constant pattern, not new variable
fn main() {
    const A:i32 = 42;
    let mut A: i32 = 44;
}

error[E0530]: let bindings cannot shadow constants
 --> src/main.rs:3:13
  |
2 |     const A:i32 = 42;
  |     ----------------- a constant `A` is defined here
3 |     let mut A: i32 = 44;
  |             ^ cannot be named the same as a constant

C und C++: Schreibrechte muessen explizit entzogen werden.
Rust: Schreibrechte muessen explizit erteilt werden.

==================================================

Und so zieht es sich immer weiter. Wenn du es eben so betrachtest, dass 
Rust "nur ein invertiertes C/C++" ist, dann duerfte es dir leichter 
fallen die Sprache zu verstehen. So geht es zumindestens mir. Und genau 
durch diese 'Invertierung' erreicht Rust schon eine hoehere Sicherheit.

Gruesse

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl,

ja das ist soweit sehr interessant und hilfreich. Auch die Logik 
verstehe ich: der unaufmerksame Tipper tippt per default maximale 
Sicherheit.

Das gefällt mir auch sehr gut.

Borrowing als Alternative zu RAII erscheint mir allerdings wie die 
Therapie von Kopfschmerz durch Dekaputation. Da bin ich mir nicht 
sicher, ob das rockt.

Was ja sehr heiß sein soll ist die concurrency bei Rust. Vielleicht 
hilft da das Borrowing auch?

In c++ ist das Thema ja jetzt mit C++17 und später überhaupt erst auf 
dem Tapet.

Viele liebe Grüße

timm

Autor: TriHexagon (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Timm R. schrieb:
> Was ja sehr heiß sein soll ist die concurrency bei Rust. Vielleicht
> hilft da das Borrowing auch?

Ja, das Ownership-System wurde eben wegen den Gefahren von nebenläufigen 
Code entworfen. In Rust ist es ebenso, dass ein Objekt entweder 
immutable ist, dann können mehrere darauf zugreifen, oder es ist mutable 
aber nur der Besitzer hat Schreibzugriff. Das Ownership-System 
garantiert das und deshalb können auch keine Raceconditions in Plain 
Rust auftreten. Natürlich lässt sich das mithilfe von unsafe umgehen, 
damit man trotzdem Semaphore und Co. in Rust umsetzen kann.

Durch das Ownership-System hat Rust definitiv ein nützliches 
Alleinstellungsmerkmal.

Beitrag #5519813 wurde von einem Moderator gelöscht.
Beitrag #5519814 wurde von einem Moderator gelöscht.
Beitrag #5519815 wurde von einem Moderator gelöscht.
Beitrag #5519817 wurde von einem Moderator gelöscht.
Beitrag #5519821 wurde von einem Moderator gelöscht.
Beitrag #5519823 wurde von einem Moderator gelöscht.
Beitrag #5519824 wurde von einem Moderator gelöscht.
Beitrag #5519870 wurde von einem Moderator gelöscht.
Beitrag #5519877 wurde von einem Moderator gelöscht.
Beitrag #5519894 wurde von einem Moderator gelöscht.
Beitrag #5519897 wurde von einem Moderator gelöscht.
Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Timm R. schrieb:
> Was ja sehr heiß sein soll ist die concurrency bei Rust. Vielleicht
> hilft da das Borrowing auch?
Lies einfach mal hier:

Fearless Concurrency
https://doc.rust-lang.org/book/second-edition/ch16...

Using Threads to Run Code Simultaneously
https://doc.rust-lang.org/book/second-edition/ch16...

Using Message Passing to Transfer Data Between Threads
https://doc.rust-lang.org/book/second-edition/ch16...

Channels and Ownership Transference
https://doc.rust-lang.org/book/second-edition/ch16...
The ownership rules play a vital role in message sending because they
help you write safe, concurrent code. Preventing errors in concurrent
programming is the advantage of thinking about ownership throughout
your Rust programs.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaj G. schrieb:
> Using Message Passing to Transfer Data Between Threads

Das ist übrigens ganz generell ein Entwurfsmuster das es auch in andern 
Sprachen sehr entspannt und angstfrei macht mit vielen Threads zu 
arbeiten ohne in die Bredouille zu kommen. Alles was man braucht ist 
eine threadsichere Queue.

: Bearbeitet durch User
Beitrag #5520001 wurde von einem Moderator gelöscht.
Beitrag #5520005 wurde von einem Moderator gelöscht.
Beitrag #5520006 wurde von einem Moderator gelöscht.
Beitrag #5520008 wurde von einem Moderator gelöscht.
Autor: W.S. (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
RalfW schrieb im Beitrag #5520008:
> Warum tut man sich das freiwillig an?

Einmal hätte doch gereicht.

Also, WARUM ?

Es ist vielen C-Programmierern seit geraumer Zeit klar, daß die Sprache 
C für die heutigen Bedürfnisse nicht mehr wirklich ausreicht und daß sie 
nicht mehr renovierungsfähig ist. Sie ist dafür bereits seit langem zu 
verkalkt.

Deshalb sinnieren viele C-Programmierer seit ebenso geraumer Zeit über 
neue Sprachentwürfe nach, mit denen sie all die uralten Geburtsfehler 
von C endlich hinter sich lassen können.

Dummerweise haben eben gerade die Programmierer, denen eine Nachfolge 
für C durchaus am Herzen liegt, "ihr" C so tief verinnerlicht, daß sie 
unfreiwillig bei jedem neuen Versuch einer neuen Programmiersprache 
sofort wieder in ihre eingefahrenen Denk-Gleise zurückfallen.

Deswegen kommt bei jeder neu erfundenen Programmiersprache im Grunde 
wieder nur C heraus, bloß hie und da mit irgendwelchen zusätzlichen 
Kringeln versehen, die die praktische Anwendung regelmäßig verhindern.

Kurzum, die Leute kommen einfach nicht aus ihrem Tunnelblick heraus, 
egal wie sie es anstellen.

Das ist das Tragische daran.

W.S.

: Wiederhergestellt durch Moderator
Autor: Alex G. (dragongamer)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
@W.S.
Du willst aber damit hoffentlich nicht ausdrücken dass das auch für Rust 
gelten würde, oder?

Autor: TriHexagon (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
W.S. schrieb:
> Deswegen kommt bei jeder neu erfundenen Programmiersprache im Grunde
> wieder nur C heraus, bloß hie und da mit irgendwelchen zusätzlichen
> Kringeln versehen, die die praktische Anwendung regelmäßig verhindern.

Mein Gott, wie kann man nur so wenig Ahnung haben und trotzdem so 
penetrant sein. Aber mach nur, mach dich weiter lächerlich, das steht 
dir so gut. ;)

Zu glauben Rust wäre wie C, weil es syntaktische Ähnlichkeiten hat, 
großartig. Das in etwa das Niveau von Moby...

Autor: Karl K. (karl2go)
Datum:

Bewertung
-7 lesenswert
nicht lesenswert
Alex G. schrieb:
> Du willst aber damit hoffentlich nicht ausdrücken dass das auch für Rust
> gelten würde, oder?

Doch, leider. Ist mir auch so ziemlich als erstes aufgefallen:

Diese unsäglichen geschweiften Klammern zum Einfassen einer Funktion 
oder Anweisung. Gleichzeitig benutzen sie es noch als Platzhalter.

Das C-typische = für Zuweisungen, == für Vergleiche. Ahhh. Nach zig 
Jahren if x = y sollte man es doch mal verstanden haben, dass das 
Bullshit ist.

Vielleicht könnte Rust das bessere C sein, aber es ist halt doch zuviel 
C.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Karl K. schrieb:
> Diese unsäglichen geschweiften Klammern zum Einfassen einer Funktion
> oder Anweisung. Gleichzeitig benutzen sie es noch als Platzhalter.

Siehe hier:

TriHexagon schrieb:
> Zu glauben Rust wäre wie C, weil es syntaktische Ähnlichkeiten hat,
> großartig. Das in etwa das Niveau von Moby...

Karl K. schrieb:
> Das C-typische = für Zuweisungen, == für Vergleiche. Ahhh. Nach zig
> Jahren if x = y sollte man es doch mal verstanden haben, dass das
> Bullshit ist.

Da ist in Python oder Haskell auch so. Ist deswegen Python==Haskell==C?

Nein. Und auch Rust ist – bis auf diese beiden minimalen syntaktischen
Ähnlichenkeiten – völlig verschieden von C.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Nach zig
> Jahren if x = y sollte man es doch mal verstanden haben

Was faselst Du? Hast Du auch mal ausprobiert was Du da frech gelogen 
unterstellst oder schwallst Du einfach nur so aus Langeweile dumm daher 
damit irgendwas gesagt ist, ganz egal was?

Autor: brackets (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Karl K. schrieb:
> Alex G. schrieb:
>> Du willst aber damit hoffentlich nicht ausdrücken dass das auch für Rust
>> gelten würde, oder?
>
> Doch, leider. Ist mir auch so ziemlich als erstes aufgefallen:
>
> Diese unsäglichen geschweiften Klammern zum Einfassen einer Funktion
> oder Anweisung. Gleichzeitig benutzen sie es noch als Platzhalter.
>
> Das C-typische = für Zuweisungen, == für Vergleiche. Ahhh. Nach zig
> Jahren if x = y sollte man es doch mal verstanden haben, dass das
> Bullshit ist.
>
> Vielleicht könnte Rust das bessere C sein, aber es ist halt doch zuviel
> C.

Bei der Zuweisung gebe ich dir recht, da wäre ein := besser. Aber immer 
noch besser als = == === in JavaScript ;-)
Die {} finde ich zum Einfassen von Blöcken nach wie vor besser leserlich 
als das unsägliche Einrücken in Python. Einmal die Quelle mit den 
falschen Einstellungen im Editor geladen und schon verhagelt es einem 
die Funktion des Programms. Da ist mir eine Sprache mit geschweiften 
Klammern lieber. Der Compiler weiß dann auch was zu tun ist, wenn 
irgendwelche Whitespaces durch andere ersetzt/optimiert wurden.
Auf Rust bin ich erst durch diesen Thread aufmerksam geworden und habe 
mich am Wochenende genauer damit beschäftigt. Bis jetzt finde ich die 
Sprache sehr interessant. Ich programmiere seit über 20 Jahren im 
embedded Bereich in C (nicht nur Projekte bei welchen zwei LEDs blinken 
;-)) und sehne mich nach einer Sprache, welche ähnlich für die 
Systemprogrammierung geeignet ist, mich vor Memory-Leaks, übergelaufenen 
Arrays etc. bewahrt, nativ und nicht in einer VM ausgeführt wird und 
keinen riesigen Overhead besitzt (z.B. Garbage Collector, fettes 
Exception-Handling ... hat hier schon jemand C++ unter den Rock geschaut 
... brrrr). Rust hat mich positiv überrascht, sogar Inline-Assembler ist 
möglich.

Gruß
{}

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> die die praktische Anwendung regelmäßig verhindern.
Dann zeig doch bitte die "Kringel" die die Anwendung von Rust 
verhindern.

W.S. schrieb:
> Kurzum, die Leute kommen einfach nicht aus ihrem Tunnelblick heraus,
> egal wie sie es anstellen.
Sagt ja der richtige...

Karl K. schrieb:
> Vielleicht könnte Rust das bessere C sein, aber es ist halt doch zuviel
> C.
Doof nur das Rust nicht viel mit C gemein hat, ausser etwas Syntax.

Karl K. schrieb:
> Das C-typische = für Zuweisungen, == für Vergleiche. Ahhh. Nach zig
> Jahren if x = y sollte man es doch mal verstanden haben, dass das
> Bullshit ist.
Auch du hast dich null mit Rust beschaeftigt.

1. Das was du da schreibst compiliert in Rust gar nicht.
fn main() {
    let mut x = 5;
    let mut y = 7;

    if x = y {
        // ...
    }
}

error[E0308]: mismatched types
 --> src/main.rs:5:8
  |
5 |     if x = y {
  |        ^^^^^
  |        |
  |        expected bool, found ()
  |        help: try comparing for equality: `x == y`
  |
  = note: expected type `bool`
             found type `()`

Wer glaubt, dass nur an den Typen von x und y liegt:
fn main() {
    let x = true;
    let y = false;

    if x = y {
        // ...
    }
}

error[E0308]: mismatched types
 --> src/main.rs:5:8
  |
5 |     if x = y {
  |        ^^^^^
  |        |
  |        expected bool, found ()
  |        help: try comparing for equality: `x == y`
  |
  = note: expected type `bool`
             found type `()`

Eine Zuweisung liefert keinen bool.

2. In Rust muessen alle Ausdruecke bei einem if ein bool liefern, und 
nicht etwas, das wie ein bool interpretiert werden koennte.
Was in C/C++ geht
if (x) {

}
compiliert in Rust ebefalls nicht
fn main() {
    let x = 5;

    if x {
        // ...
    }
}

error[E0308]: mismatched types
 --> src/main.rs:5:8
  |
5 |     if x {
  |        ^ expected bool, found integral variable
  |
  = note: expected type `bool`
             found type `{integer}`

Auch sowas geht nicht:
fn main() {
    let x = 5;

    if x & 5 {
        // ...
    }
}

error[E0308]: mismatched types
 --> src/main.rs:4:8
  |
4 |     if x & 5 {
  |        ^^^^^ expected bool, found integral variable
  |
  = note: expected type `bool`
             found type `{integer}`

Es compiliert erst, wenn ein bool rauskommt:
fn main() {
    let x = 5;

    if x & 5 == 5 {
        // ...
    }
}

Wenn man keine Ahnung hat...

Autor: TriHexagon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Diese unsäglichen geschweiften Klammern zum Einfassen einer Funktion
> oder Anweisung. Gleichzeitig benutzen sie es noch als Platzhalter.

Wo ist denn das Problem? Weil man statt geschweiften Klammern alles mit 
begin und end zu bombt? Ohne Syntax-Highlighting ist die Lesbarkeit mit 
begin/end allerdings schlecht. Passiert wenn man den Code mit cat oder 
diff ausgibt.

Karl K. schrieb:
> Das C-typische = für Zuweisungen, == für Vergleiche. Ahhh. Nach zig
> Jahren if x = y sollte man es doch mal verstanden haben, dass das
> Bullshit ist.

Ist kein Bullshit, weil man damit elegant gleichzeitig Zuweisen und 
Vergleichen kann. Gerade in Schleifenköpfe ist das praktisch.

Karl K. schrieb:
> Vielleicht könnte Rust das bessere C sein, aber es ist halt doch zuviel
> C.

Das ist reine Geschmacksache. Ich bevorzuge den Stil von C, aber 
deswegen Kotze ich mich bei VHDL doch nicht aus... . Daran bemisst sich 
ganz sicher nicht die Qualität von Rust, auch wenn es sich ein paar 
Ewiggestrigene wünschen, die immer noch um Pascal trauern.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
brackets schrieb:
> Aber immer
> noch besser als = == === in JavaScript ;-)
Das gibt es auch in PHP ;)

Autor: TriHexagon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TriHexagon schrieb:
> Karl K. schrieb:
>> Das C-typische = für Zuweisungen, == für Vergleiche. Ahhh. Nach zig
>> Jahren if x = y sollte man es doch mal verstanden haben, dass das
>> Bullshit ist.
>
> Ist kein Bullshit, weil man damit elegant gleichzeitig Zuweisen und
> Vergleichen kann. Gerade in Schleifenköpfe ist das praktisch.

Und das ist in Rust nicht einmal möglich, wie Kaj G. schon zeigte.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
x = y = z;

hätte auch keinen Sinn, selbst wenn es gehen würde wenn man bedenkt was 
der = Operator macht, je nachdem ob z copy ist oder nicht. Deshalb 
braucht keiner sowas wie das was da oben steht und käme auch nie auf die 
Idee sowas zu schreiben oder haben zu wollen.

Deshalb evaluiert eine Zuweisung immer zu (). Und () ist nicht bool.

Also hat Rust auch dieses Problem elegant über die Bande gespielt allein 
mit dem Typsystem nachhaltig aus der Welt geschafft ohne irgendwelche 
altgewohnte Syntax ändern zu müssen.

Autor: Karl K. (karl2go)
Datum:

Bewertung
-8 lesenswert
nicht lesenswert
Ja ok, ich sehe schon, Rust hat hier genauso arschlöchrige Fanboys wie 
C. Damit ist die Diskussion hinfällig.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
brackets schrieb:
> Die {} finde ich zum Einfassen von Blöcken nach wie vor besser leserlich
> als das unsägliche Einrücken in Python.

Wer sagt denn das es das Einrücken sein muß. Es gibt auch andere 
Möglichkeiten Blöcke zusammenzufassen bzw. zu kennzeichnen.
Es soll ja Programmiersprachen geben die den Anfang und das Ende eines 
Blockes im Klartext hinschreiben. Das empfinde ich als sehr angenehm, 
weil gut lesbar ist. Wenn dann noch dazu sinnvoll eingerückt wird ist es 
eigentlich optimal lesbar.
Ich kann auch mit der geschweiften Klammer leben - ist allemal besser 
als das Einrückungsprinzip in Python. Einen Vorteil hat allerdings das 
Pythonverfahren: Es zwingt zu einem sauberen Aufschreiben des 
Quelltextes.

Autor: Rustbratwurst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum zum Geier muss ich bei Rust immer an diesen komischen 
Kremelflieger denken? Bin ich etwa anders als andere?

Autor: Zeno (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
TriHexagon schrieb:
> weil man damit elegant gleichzeitig Zuweisen und
> Vergleichen kann. Gerade in Schleifenköpfe ist das praktisch.

Das ist eine ganz böse Falle, weil das auch mal richtig nach hinten los 
gehen kann.
Im Übrigen ist dieses Verhalten nicht vom verwendeten 
Zuweisungs-/Vergleichsoperator abhängig. Das könnte man mit jeder 
beliebigen Zuweisungs-/Vergleichsoperatorkombination realisieren, weil 
das letztendlich vom Compiler abhängt. Es hat aber schon gute Gründe, 
das es Compiler gibt die so etwas nicht zu lassen. Zuweisen ist halt 
etwas anderes als Vergleichen.

Autor: TriHexagon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Ja ok, ich sehe schon, Rust hat hier genauso arschlöchrige Fanboys wie
> C. Damit ist die Diskussion hinfällig.

Sich zuerst überheblich an solchen Kleinigkeiten aufhängen, dann sich 
eine blutige Nasse holen und gleich beleidigt abhauen. So ist recht.

Aber gut, eigentlich sollte es darum gar nicht gehen. Ich habe vor einem 
Jahr einen einfachen Assembler in Rust geschrieben. Und muss sagen, dass 
mir Rust sehr gut gefällt. Natürlich muss man sich ein bisschen mehr 
Gedanken durch das Ownership-System machen, man wird aber belohnt. Ich 
hatte allerdings noch nicht die Möglichkeit ein komplexeres Programm zu 
schreiben mit vielen Datenstrukturen. Da wäre interessant wie gut das 
geht.

Auch gefällt mir die Fehlerbehandlung in Rust durch nullable-Types mit 
Verzicht auf Exceptions. Durchs Patternmatching lässt sich das auch 
relativ elegant behandeln. Überhaupt sind diese mächtigen Enums wirklich 
genial.

Wollte mir in nächster Zeit mal mit Rust auf einem ARM Cortex 
beschäftigen, da sehe ich wirklich Potential.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was hier im Forum ja auch ganz gerne an C/C++ bemaengelt wird: die 
Endlosschleife.
In C/C++:
while (1) {

}

for (;;) {

}
Da wird ja auch gerne gemotzt, dass man das doch besser mit goto (oder 
sonst wie) machen sollte, weil alles andere ja eine zweckentfremdung der 
Schleife waere...

Auch das macht Rust ganz einfach:
loop {

}

Rust hat dazu auch noch Schleifen-Lables:
https://doc.rust-lang.org/rust-by-example/flow_con...
#![allow(unreachable_code)]

fn main() {
    'outer: loop {
        println!("Entered the outer loop");

        'inner: loop {
            println!("Entered the inner loop");

            // This would break only the inner loop
            //break;

            // This breaks the outer loop
            break 'outer;
        }

        println!("This point will never be reached");
    }

    println!("Exited the outer loop");
}
Wie goto, nur deutlich weniger fehleranfaellig.

Was ich ebefalls schoen finde:
fn main() {
    let cond = true;

    let x = if cond {
        5
    } else {
        6
    };
}
In C/C++ muss man dazu x erstmal anlege und laesst es uninitialisiert 
oder belegt es erstmal mit einen dummy Wert, der dann wieder 
ueberschrieben werden muss.


Auf uninitialisierte Variablen kann in Rust nicht lesend zugegriffen 
werden:
fn main() {
    let x: i32;
    let y = x;
}

error[E0381]: use of possibly uninitialized variable: `x`
 --> src/main.rs:4:9
  |
4 |     let y = x;
  |         ^ use of possibly uninitialized `x`
Boom: Wieder ein typisches Problem von C und C++ einfach so aus dem Weg 
geraeumt.


Wer hier immernoch die Meinung vertritt, das Rust wie C ist, der moege 
doch bitte die Klappe halten. Ihr muesst es nicht nutzen, aber lasst uns 
doch unseren Spass an dieser Sprache. Nicht jeder moechte stehen 
bleiben, und Sprachen mit Konzepten (bzw. eher ohne Konzepten) von vor 
ueber 20 Jahren nutzen.

Rust unterstuetzt den Entwickler besser als die meisten anderen Sprachen 
(besonders besser als C und C++), um fehlerfreien/fehlerarmen Code zu 
schreiben. Und der Entwickler muss sich weniger Gedanken um Dinge wie 
undefined behavior machen, und kann sich mehr auf die eigentliche 
Aufgabe konzentrieren, ohne dabei auf die Performance von C/C++ 
verzichten zu muessen.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
TriHexagon schrieb:
> Ich
> hatte allerdings noch nicht die Möglichkeit ein komplexeres Programm zu
> schreiben mit vielen Datenstrukturen. Da wäre interessant wie gut das
> geht.
Wenn du ein grosses Projekt suchst, das in Rust geschrieben wird:
Sequoia-PGP
https://sequoia-pgp.org/

Autor: TriHexagon (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Zeno schrieb:
> TriHexagon schrieb:
>> weil man damit elegant gleichzeitig Zuweisen und
>> Vergleichen kann. Gerade in Schleifenköpfe ist das praktisch.
>
> Das ist eine ganz böse Falle, weil das auch mal richtig nach hinten los
> gehen kann.
> Im Übrigen ist dieses Verhalten nicht vom verwendeten
> Zuweisungs-/Vergleichsoperator abhängig. Das könnte man mit jeder
> beliebigen Zuweisungs-/Vergleichsoperatorkombination realisieren, weil
> das letztendlich vom Compiler abhängt. Es hat aber schon gute Gründe,
> das es Compiler gibt die so etwas nicht zu lassen. Zuweisen ist halt
> etwas anderes als Vergleichen.

Da hast du recht und ich kann total verstehen, dass man das verbieten 
sollte. Aber die damalige Designentscheidung ist allerdings zumindest 
nachvollziehbar und kein "Bullshit", auch wenns zu einem weiteren 
Fallstrick führt.

Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Karl K. schrieb:
> Ja ok, ich sehe schon, Rust hat hier genauso arschlöchrige
> Fanboys wie C. Damit ist die Diskussion hinfällig.

Welche Sprache wäre denn deiner Meinung nach ein würdiger Nachfolger von 
C? Jetzt sag aber bitte nicht C++ oder Assembler.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Apropos Enums:

Option und Result, wer fühlt sich bei diesen beiden Enums nicht sofort 
an Haskell's Maybe und Either Monaden erinnert?

Auch das Auspacken in einem Pattern-Matching Konstrukt funktioniert 
genauso, ein Datentyp der mehrere "Formen" mit komplett 
unterschiedlichen Strukturen und Inhalten annehmen kann [wie ein union 
aber doch wieder irgendwie ganz anders, mächtiger und sicherer], zum 
Beispiel der Typ std::net::IpAddr ist ein Enum das entweder V4 oder V6 
sein kann und je nachdem komplett unterschiedliche Datenfelder hat, 
jedoch ist es vollkommen unmöglich Code zu schreiben der versehentlich 
auf die jeweils falschen Felder zugreift wenn man gerade ein Exemplar 
der einen oder der anderen Sorte vorliegen hat. Mit der selben Kraft des 
Enums kann man versehentliche Nullpointer-Dereferenzierung unmöglich 
machen.

Ich glaube die Enums wurden in diesem Thread noch nicht ausreichend 
gewürdigt, ich finde dieses Konzept mindestens genauso genial wie das 
Ownership-System (wenngleich es auch schon etwas älter ist und in 
anderen Sprachen ebenfalls vorkommt), allein die Enums und das 
Pattern-Matching machen die Sprache schon extrem mächtig und nützlich.

Irgendjemand hat auch mal Rust als Einstiegsdroge für Haskell 
bezeichnet, ich weiß zu wenig über Haskell um das kommentieren zu können 
aber mein Bauch sagt mir daß da zumindest teilweise was dran sein 
könnte.

: Bearbeitet durch User
Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bernd,

schenk uns doch bitte mal ein MWE dazu, das wäre interessant(er).

vlg
 Timm

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Timm R. schrieb:
> schenk uns doch bitte mal ein MWE dazu, das wäre interessant(er).

Was ist ein "MWE"?

: Bearbeitet durch User
Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Welche Sprache wäre denn deiner Meinung nach ein würdiger Nachfolger von
> C? Jetzt sag aber bitte nicht C++ oder Assembler.

Wer sagt, dass c einen Nachfolger hat oder braucht? Und wenn es einen 
braucht, was spricht gegen c++?

Kaj G. schrieb:
> Wie goto, nur deutlich weniger fehleranfaellig.
Warum ist es weniger fehleranfällig? Wenn man goto nur in dieser 
Situation einsetzt, ist es das gleiche (das label steht an einer anderen 
Stelle).

Kaj G. schrieb:
> Was ich ebefalls schoen finde:fn main() {
     let cond = true;
 
     let x = if cond {
         5
     } else {
         6
     };
 }
> In C/C++ muss man dazu x erstmal anlege und laesst es uninitialisiert
> oder belegt es erstmal mit einen dummy Wert, der dann wieder
> ueberschrieben werden muss.
Ja, in einigen Fällen kann man so ohne uninitialisierte Variable 
auskommen, wo man sie in c++ nicht vermeiden kann. In den meisten Fällen 
kann man uninitialisierte Variablen aber leicht umgehen. Für dein 
Beispiel sieht das dann so aus:
auto x = 6;
if(cond) {
  x = 5;
}
Der Compiler erzeugt vermutlich identischen Code. Bei komplizierternen 
Fällen sollte man sich fragen, warum es so kompliziert ist und es 
vereinfachen.

Dein Beispiel ist meiner Meinung nach ziemlich schlecht lesbar. Eine 
Variablen wird über 5 Zeilen initialisiert. Ich muss 5 Zeilen lesen bis 
ich weiß, welchen Wert und Typ x hat. If als Ausdruck mit Wert, macht 
die Definition der Sprache vllt. einfacher und eleganter, aber für mich 
nicht leichter lesbar. Genauso unübersichtlich sind Funktionen mit 
Rückgabewert aber ohne return.

Kaj G. schrieb:
> Boom: Wieder ein typisches Problem von C und C++ einfach so aus dem Weg
> geraeumt.
Ich kann mich nicht daran erinnern, dass das für mich in c oder c++ im 
letzten Jahrzehnt ein Problem gewesen ist. Nachdem ich den Fehler ein 
paar mal gemacht habe, habe ich mir ganz schnell angewöhnt Variablen zu 
initialisieren und Klassen so du designen, dass sie nur initialisiert 
existieren können. Davon abgesehen warnt mich mein Compiler vor 
uninitialiserten Variablen (bzw die ide während ich tippe).
Kaj G. schrieb:
> use of possibly uninitialized `x`
Vor allem dieses "possibly" stört mich. Ich habe häufiger Variablen, bei 
denen der Compiler nicht wissen kann, ob sie initialisiert sind oder 
nicht. Und nein, es ist kein Sicherheitsrisiko, wenn man es sorgfältig 
macht.

Autor: S. R. (svenska)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
mh schrieb:
> Wer sagt, dass c einen Nachfolger hat oder braucht?
> Und wenn es einen braucht, was spricht gegen c++?

Vorweg: Ich programmiere gerne in C. Gleichzeitig sehe ich aber auch 
ein, dass C nicht der Weisheit letzter Schluss ist, aus wohlbekannten 
und bereits bekannten Gründen.

Meiner Meinung nach leider C++ an der gleichen Überkomplexität wie Perl: 
Es gibt zuviele Wege, ein Problem zu lösen. Das führt dazu, dass jeder 
sein persönliches Subset der Sprache benutzt, mit dem er Probleme gut 
lösen kann, aber am Ende beherrscht niemand die Sprache so gut, um die 
Lösungen anderer zuverlässig zu lesen (sprich: zu debuggen).

Und innerhalb dieser Diskussion hier habe ich nicht so richtig das 
Gefühl, dass Rust da wesentlich besser ist. Ich kann mich täuschen, habe 
aber gerade wenig Lust, mich in eine neue Sprache einzuarbeiten (im 
Augenblick arbeite ich ständig mit C++, Java, Kotlin, VHDL und hab den 
Kopf voll).

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Timm R. schrieb:
>> schenk uns doch bitte mal ein MWE dazu, das wäre interessant(er).
>
> Was ist ein "MWE"?

Hey Bernd,

sorry! Minimal Working Example

vlg
 Timm

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Option und Result, wer fühlt sich bei diesen beiden Enums nicht sofort
> an Haskell

https://doc.rust-lang.org/book/second-edition/ch06...
Enums are a feature in many languages, but their capabilities differ
in each language. Rust’s enums are most similar to algebraic data types
in functional languages, such as F#, OCaml, and Haskell.

Was ein valides struct ist, ist auch ein valides enum:
https://doc.rust-lang.org/rust-by-example/custom_t...
The enum keyword allows the creation of a type which may be one of a
few different variants. Any variant which is valid as a struct is also
valid as an enum.

mh schrieb:
> Warum ist es weniger fehleranfällig?
Weil du nicht irgendwo in der Funktion hinspringen kannst, sondern nur 
aus der Schleife raus. Nicht mehr und nicht weniger. Grosser Unterschied 
zu goto.

mh schrieb:
> Dein Beispiel ist meiner Meinung nach ziemlich schlecht lesbar. Eine
> Variablen wird über 5 Zeilen initialisiert.
Musst du ja nicht so machen. Kannst du ja genauso machen wie in C/C++:
fn main() {
    let cond = true;
    let mut x: i32 = 6;

    if cond {
        x = 5;
    }
}

Es gibt jetzt nur einen eklatanten unterschied:
In meinem Beispiel
let x = if cond {
    5
} else {
    6
};
ist x danach read-only, aber nicht const, d.h. x koennte per shadowing 
ueberdeckt werden, wenn man es braucht.

fn main() {
    let cond = true;
    let x = if cond {
        5
    } else {
        6
    };

    x = 7;
}

error[E0384]: cannot assign twice to immutable variable `x`
 --> src/main.rs:9:5
  |
3 |     let x = if cond {
  |         - first assignment to `x`
...
9 |     x = 7;
  |     ^^^^^ cannot assign twice to immutable variable
Soweit ich das sehe, ist sowas in C/C++ nicht moeglich.


mh schrieb:
> Ich kann mich nicht daran erinnern, dass das für mich in c oder c++ im
> letzten Jahrzehnt ein Problem gewesen ist.
Nur weil es fuer dich kein Problem ist, heisst das nicht, dass es kein 
generelles Problem ist. Schau nur mal wie viele Bugs es wegen nicht 
initialisierten Variablen (UB) gibt.

Bei meinem alten Arbeitgeber haben wir mal genau so einen Bug gesucht, 
der nur aufgefallen ist, weil unsere Software auf FreeBSD und auf 
Windows laufen musste. Auf BSD kein Problem, unter Windows hat sich das 
Programm aber anders verhalten. Was war das Problem?
bool flag;

// jede menge code

if (flag) {

} else {

}
Ist halt doof, wenn die Variable auf dem einen System Wert x und auf dem 
anderen Wert y hat.

Wenn es fuer dich kein Problem ist, ist ja gut, UB ist trotzdem mit 
einer der am verbreitesten Fehlerursachen in C/C++. Nullpointer, 
User-After-Free, etc. Alles UB.

mh schrieb:
> Und nein, es ist kein Sicherheitsrisiko, wenn man es sorgfältig
> macht.
Du sagst es ja selbst: Man muss extra aufpassen, weil genau sowas UB 
ist. Und gerade UB ist eben etwas, auf das ich in Rust nicht achten 
muss, und ich mir auch keinen Kopf darum machen will.

Kannst ja mal hier schauen, was so alles UB ist. Und dann sag mal, ob du 
das alles wusstest, und wenn nicht, ob du deine Programme jetzt danach 
durchsuchst und das behebst. ;)
Keine Angst, sind nur 203 Aufgelistet.
https://wiki.sei.cmu.edu/confluence/display/c/CC.+...

Und dazu kommt dann auch noch unspecified behavior. Auch das sind 'nur' 
58.
https://wiki.sei.cmu.edu/confluence/display/c/DD.+...

Sind also gut 260 Fallstricke, die du immer im Kopf haben musst. Und das 
nur fuer C.
Man brauch ja nur mal hier im Forum suchen, wie es immer und immer 
wieder zu der Frage nach union kommt. Das endet nahezu immer darin, das 
man dem TO erklaeren muss, dass das was er da macht UB ist, und er es 
einfach ignoriert, weil es ja beim ihm funktioniert. 'Works for me!'
Kann also gar nicht falsch sein.

Sorry, aber damit gewinnt C und auch C++ keinen Blumentopf mehr.

Autor: Carl D. (jcw2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
mh schrieb:
> Kaj G. schrieb:
.
>> Was ich ebefalls schoen finde:fn main() {
>
>      let cond = true;
> 
>      let x = if cond {
>          5
>      } else {
>          6
>      };
>  }
> 
>> In C/C++ muss man dazu x erstmal anlege und laesst es uninitialisiert
>> oder belegt es erstmal mit einen dummy Wert, der dann wieder
>> ueberschrieben werden muss.
.
> Ja, in einigen Fällen kann man so ohne uninitialisierte Variable
> auskommen, wo man sie in c++ nicht vermeiden kann. In den meisten Fällen
> kann man uninitialisierte Variablen aber leicht umgehen. Für dein
> Beispiel sieht das dann so aus:
>
> auto x = 6;
> if(cond) {
>   x = 5;
> }
> 
> Der Compiler erzeugt vermutlich identischen Code. Bei komplizierternen
> Fällen sollte man sich fragen, warum es so kompliziert ist und es
> vereinfachen.

Oder vielleicht schlicht die 1:1 Variante
auto x = (cond) ? 5 : 6;

Autor: mh (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Kaj G. schrieb:
> Soweit ich das sehe, ist sowas in C/C++ nicht moeglich.
Wenn man es unbedingt braucht:
auto const x = cond ? 5 : 6;

Kaj G. schrieb:
> Du sagst es ja selbst: Man muss extra aufpassen, weil genau sowas UB
> ist. Und gerade UB ist eben etwas, auf das ich in Rust nicht achten
> muss, und ich mir auch keinen Kopf darum machen will.
Das bringt mir wenig, wenn ich statt dessen andauernd den Compiler 
"umgehen" muss, um meine Probleme zu Lösen (siehe: use of possibly 
uninitialized `x`).

Kaj G. schrieb:
> bool flag;
>
> // jede menge code
>
> if (flag) {
>
> } else {
>
> }
Bei rust nen Error bei c++ ne Warnung.


Kaj G. schrieb:
> Wenn es fuer dich kein Problem ist, ist ja gut, UB ist trotzdem mit
> einer der am verbreitesten Fehlerursachen in C/C++. Nullpointer,
> User-After-Free, etc. Alles UB.
Nullpointer und Use-After-Free sind keine wirklichen Probleme in c++, da 
man keine Raw-Pointer verwendet.

Kaj G. schrieb:
> Kannst ja mal hier schauen, was so alles UB ist.Und dann sag mal, ob du
> das alles wusstest, und wenn nicht, ob du deine Programme jetzt danach
> durchsuchst und das behebst.
Ich kenne nicht alle Fälle von UB, aber alle die relevant sind. Hast du 
die Liste gelesen?
A nonempty source file does not end in a new-line character which is not immediately preceded by a backslash character or ends in a partial preprocessing token or comment (5.1.1.2).
Sehr relevant... Wenn ich mich nicht irre hat gcc früher trotzdem 
gewarnt.
A program in a hosted environment does not define a function named main using one of the specified forms (5.1.2.2.1).
Kennt jemand einen Linker, der nicht meckert, wenn er kein main findet?
A reserved keyword token is used in translation phase 7 or 8 for some purpose other than as a keyword (6.4.1).
Muss ich davor Angst haben?

Kaj G. schrieb:
> Sorry, aber damit gewinnt C und auch C++ keinen Blumentopf mehr.
Wo findet man nochmal den vollständigen rust-Standard, in dem es kein 
Undefined Behaviour gibt? Die Antwort auf 
https://www.rust-lang.org/en-US/documentation.html:
> While Rust does not have a specification, the reference tries to describe
> its working in detail. It tends to be out of date.

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:

Hallo,

> Kaj G. schrieb:
>> Wenn es fuer dich kein Problem ist, ist ja gut, UB ist trotzdem mit
>> einer der am verbreitesten Fehlerursachen in C/C++. Nullpointer,
>> User-After-Free, etc. Alles UB.
> Nullpointer und Use-After-Free sind keine wirklichen Probleme in c++, da
> man keine Raw-Pointer verwendet.

bzw, wenn man sie verwendet, dann sind das Fälle, wo auch in Rust 
"unsafe" stehen würde. Und eine Heap-Allokation die sich heimlich 
verabschiedet kann der Rust "unsafe" genau so wenig vorhersehen, wie ein 
C++ Compiler. Kein Unterschied.

Wobei man eben schon zugeben muss, dass sowas wie der C-Code oben aus 
dem Heartbleed Beispiel in Rust eben nicht so einfach einzuschmuggeln 
ist.



> Kaj G. schrieb:
>> Kannst ja mal hier schauen, was so alles UB ist.Und dann sag mal, ob du
>> das alles wusstest,

na, das ist doch mal etwas schräg? Ich kenne auch nicht alle Fraun, mit 
denen ich nicht verheiratet bin. Wozu denn auch? Du musst ein gutes 
Gebiet defined behavior kennen und das UB, dass dir auf die Füße fallen 
könnte, wenn du im Halbschlaf rumtipperst.

Kaj, du hast ja scheinbar einen riesen Fundus UB ausgegraben, dann nenn 
doch bitte mal ein einziges UB, das einen C++ Dilettanten wie mich 
überrascht, gern auch als Quizzfrage. Ich war noch nie von UB 
überrascht, sondern höchstens mal, dass etwas nicht UB ist, aber das ist 
ja nicht gefährlich.

vlg
 Timm

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

nicht 100% ernst gemeint:

Vielleicht beginnt ja dann in Zukunft jeder noob sein Rust Programm mit
unsafe {

so wie in c++ das
using namespace std;

:-))

vlg
 Timm

Autor: Achim S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaj G. schrieb:
> bool flag;
>
> // jede menge code
>
> if (flag) {
>
> } else {

Da schlägt doch der Compiler Alarm, oder zumindest Lint. Ja, man kann in 
C so programmieren, dass solch Warnungen untergehen ...

Autor: Privatfrickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaj G. schrieb:
> Bei meinem alten Arbeitgeber haben wir mal genau so einen Bug gesucht,
> der nur aufgefallen ist, weil unsere Software auf FreeBSD und auf
> Windows laufen musste. Auf BSD kein Problem, unter Windows hat sich das
> Programm aber anders verhalten. Was war das Problem?bool flag;
>
> // jede menge code
>
> if (flag) {
>
> } else {
>
> }

Selbst in Pelles C bekomme ich da bei un-initialisiertem Gebrauch von 
flag eine Warning geworfen!

C99 mit
<stdbool.h>
eingebunden
Building main.obj.
C:\Users\..\Documents\Pelles C Projects\bool01\main.c(22): warning #2229: Local 'flag' is potentially used without being initialized.
Done.

Beitrag #5520584 wurde von einem Moderator gelöscht.
Beitrag #5520585 wurde von einem Moderator gelöscht.
Beitrag #5520586 wurde von einem Moderator gelöscht.
Beitrag #5520587 wurde von einem Moderator gelöscht.
Beitrag #5520600 wurde von einem Moderator gelöscht.
Beitrag #5520601 wurde von einem Moderator gelöscht.
Beitrag #5520602 wurde von einem Moderator gelöscht.
Beitrag #5520603 wurde von einem Moderator gelöscht.
Beitrag #5520604 wurde von einem Moderator gelöscht.
Beitrag #5520605 wurde von einem Moderator gelöscht.
Beitrag #5520606 wurde von einem Moderator gelöscht.
Beitrag #5520607 wurde von einem Moderator gelöscht.
Beitrag #5520608 wurde von einem Moderator gelöscht.
Beitrag #5520609 wurde von einem Moderator gelöscht.
Beitrag #5520610 wurde von einem Moderator gelöscht.
Beitrag #5520612 wurde von einem Moderator gelöscht.
Beitrag #5520613 wurde von einem Moderator gelöscht.
Beitrag #5520614 wurde von einem Moderator gelöscht.
Beitrag #5520615 wurde von einem Moderator gelöscht.
Beitrag #5520617 wurde von einem Moderator gelöscht.
Beitrag #5520619 wurde von einem Moderator gelöscht.
Beitrag #5520620 wurde von einem Moderator gelöscht.
Beitrag #5520621 wurde von einem Moderator gelöscht.
Beitrag #5522113 wurde von einem Moderator gelöscht.
Beitrag #5522114 wurde von einem Moderator gelöscht.
Beitrag #5522143 wurde von einem Moderator gelöscht.
Beitrag #5522144 wurde von einem Moderator gelöscht.
Beitrag #5522145 wurde von einem Moderator gelöscht.
Beitrag #5522146 wurde von einem Moderator gelöscht.
Autor: Operator S. (smkr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kaj G.
Man kann sich die Beispiele auch so zurechtrücken, dass seine Ansichten 
am besten da stehen. So gerne ich Rust auch mag, so sind nicht all seine 
Eigenschaften ein Alleinstellungsmerkmal der Sprache.

Hier sagst du
Kaj G. schrieb:
> C und C++: Sichtbarkeit muss explizit eingeschraenkt werden.
> Rust: Sichtbarkeit muss explizit ausgeweitet werden.

merkst aber sogar selbst an, dass die Funktion über das Headerfile 
öffentlich gemacht werden muss. Noch expliziter gehts ja kaum.
Ausserdem sind in C++ Methoden in einer Klasse default private. 
Umgekehrt sind sie in einem struct default public.

Kaj G. schrieb:
> Auf uninitialisierte Variablen kann in Rust nicht lesend zugegriffen
> werden:
C++ initialisiert diese einem sogar, wenn man es nicht selber 
hinschreiben will.


Kaj G. schrieb:
> Was ich ebefalls schoen finde:fn main() {
>     let cond = true;
>
>     let x = if cond {
>         5
>     } else {
>         6
>     };
> }
> In C/C++ muss man dazu x erstmal anlege und laesst es uninitialisiert
> oder belegt es erstmal mit einen dummy Wert, der dann wieder
> ueberschrieben werden muss.
Die Behauptungen zu C++ stimmen schlichtweg nicht, was aber weiter oben 
schon erläutert wurde.

Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab über Rust bisher leider nur gelesen und es selbst nie angewandt, 
aber was mir persönlich sehr abgehn würde und wofür es glaub ich bisher 
kein Äquivalent in C++ gibt ist:
- constexpr
- variadic arguments
- function overloading

Kann jemand dazu was sagen?
Grad constexpr wäre für eine embedded Sprache, in der es imho übermäßig 
viele compile-time Checks geben kann und sollte sehr wichtig.

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Vincent,

magst duu deinen Post noch mal lesen? Irgendwas stimmt da nicht.

Viele liebe Grüße
timm

: Bearbeitet durch User
Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Err... zu meinte ich natürlich, Äquivalent zu C++, nicht in.

Autor: Der wo ich bin (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ich hab mal eine grundsätzliche Frage an die Community hier, welche ich 
mir jedesmal stelle, wenn Threads dieser Art (C vs. C++, C vs. Rust, C 
vs. Ada) aufploppen.

Wer würde folgenden Aussagen zustimmen?

Ich bevorzuge C gegenüber C++/Rust/Ada weil:

- diese Sprachen es zu leicht machen sich in eine Ecke zu designen.
- für ein Byte der Typ uint8_t genügt, es braucht keinen n-dimensionalen 
Bojackel-Schniepel aus den tiefen des Weltalls.
- ich keine Lust habe mich in die Abstraktionsuntiefen anderer zu 
begeben, wenn das Problem eigentlich einfacher zu lösen ist.

Ich persönlich habe mit Rust experimentiert, und wäre glücklich gewesen 
wenn es ein C mit borrow checker geworden wäre. Der Rest führt meiner 
Erfahrung nach, früher oder später, zu einer over engineering Kultur 
(wie bei allen Sprachen mit "mächtigem Typsystem"). Irgendwann kommt der 
Punkt an dem man sich zur akademisch niedrigsten Lebensform 
zurückentwickelt, dem Taxonomen 
(https://de.wikipedia.org/wiki/Taxonomie).

Aber wahrscheinlich abstrahiere ich nur gerne in die andere Richtung 
(uint8_t vs. Bojackel-Schniepel, denn hey, im Grunde sind alles nur 
Zahlen ;-) ).

P.S.:
Hat jemand Erfahrung mit https://ziglang.org?

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Der wo ich bin schrieb:
> für ein Byte der Typ uint8_t genügt, es braucht keinen n-dimensionalen
> Bojackel-Schniepel aus den tiefen des Weltalls.

Der Typ für einen "n-dimensionale Bojackel-Schniepel aus den tiefen des 
Weltalls als Ersatz für uint8_t" heißt in Rust ganz einfach u8.

Darüber hinaus sind Deine Aussagen über die negativen Eigenschaften von 
Rust etwas schwammig und nicht ganz nachvollziehbar. Insbesondere weil 
Du sagst der Borrow-Checker bereitet Dir erstaunlicherweise keine 
Probleme, das ist aber so ziemlich der komplizierteste Teil, alles 
andere ist genau wie C mit ein paar zusätzlichen Schmankerln (Enums, 
Pattern-Matching, etc.) und einer angenehmeren Syntax als C(++).

: Bearbeitet durch User
Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der wo ich bin schrieb:
> Ich hab mal eine grundsätzliche Frage an die Community hier, welche ich
> mir jedesmal stelle, wenn Threads dieser Art (C vs. C++, C vs. Rust, C
> vs. Ada) aufploppen.
>
> Wer würde folgenden Aussagen zustimmen?
>
> Ich bevorzuge C gegenüber C++/Rust/Ada weil:
>
> - diese Sprachen es zu leicht machen sich in eine Ecke zu designen.
> - für ein Byte der Typ uint8_t genügt, es braucht keinen n-dimensionalen
> Bojackel-Schniepel aus den tiefen des Weltalls.
> - ich keine Lust habe mich in die Abstraktionsuntiefen anderer zu
> begeben, wenn das Problem eigentlich einfacher zu lösen ist.
Bei Entwicklern die nur ein paar tausendzeilige Programme schreiben 
wirst du ganz sicher Gleichgesinnte finden (Ausnahmen bestätigen die 
Regel).
Das setzt allerdings vorraus dass du eben Probleme hast die sich so 
einfach umsetzen lassen und vorallem vom Menschen (und einem späteren 
Leser des Codes) erfasst werden können. Schließlich ist das der 
Hauptgrundgrund für Abstraktion.

Wobei mein Argument hier wenig mit C vs Rust zutun hat, sondern mehr C 
vs Objektorientierung.
Dass es irgendwann ein "Rust++" mit vollwertiger Objektorientierung 
geben könnte sind Moment nur Gerüchte und Wünsche.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> Bei Entwicklern die nur ein paar tausendzeilige Programme schreiben
> wirst du ganz sicher Gleichgesinnte finden (Ausnahmen bestätigen die
> Regel).

Ein mächtiges Typsystem verleitet zu Missbrauch.

Wenn jede einzelne Information zu einem eigenen Datentyp gemacht wird, 
und durch die Abstraktionshierarchien hindurch ständig Datentypen 
ineinander konvertiert werden müssen (weil sie abstrakt definiert 
wurden, statt zueinander kompatibel), dann ist das jeglicher Form von 
Wartung abträglich. Und wenn man dann durch sechs, sieben 
Abstraktionsstufen hindurchgelaufen ist und eine Trivialität findet, 
dann fühlt man sich schon ein bisschen verarscht.

Komplexität taucht immer irgendwo auf, aber mir ist Komplexität in der 
Programmlogik (die man verfolgen kann) lieber, als Komplexität in der 
Abstraktionierung (eben weil man die nicht verfolgen kann - der Code ist 
über viele Dateien verstreut).

Aber das ist definitiv kein Fehler von Rust.

Autor: Der wo ich bin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der borrow checker ist in der tat kein Problem. Das Problem ist das man 
(wie auch bei C++ und Ada) zum Taxonomen wird, wobei scheinbar immer 
versucht wird möglichst fein granulierte Designs und Typen zu 
implementieren. Nach Möglichkeit nah an der Realität, wobei ich mich da 
dann frage wo die Abstraktion sein soll. Ist dann eher eine 
Nachempfindung.

Mein Beispiel oben (uint8_t) z.B. wurde von Bernd K. falsch verstanden. 
Als ob ich nicht wüsste das es u8 gibt. Im Rust Forum hatte ich die 
Frage genau so auch gestellt (über die offizielle Webseite zu erreichen, 
Stichwort thinking in types). Antwort war "geht auch, aber idiomatisch 
müsstest du..."

Aber ich sehe wir haben einfach zu verschiedene Denkweisen.

P.S.:
Tausendzeilig? Die meisten Kernel und (bedeutenden) libs sind größer 
denke ich.

P.P.S.:
Ich schreibe nie mehr was per Telefon!

Autor: Der wo ich bin (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
An Alex G.:

Anstatt durch die Blume zu implizieren ich sei kein Profi, hätte keine 
Ahnung oder bin einfach zu dumm, google mal "Rust severely disappoints 
me" von Eric Raymond. Am besten auch googeln wer das ist.

Und kuck dir mal die Sprache Zig an und warum sie ins Leben gerufen 
wurde.
Zitat:
"Small, simple language. Focus on debugging your application rather than 
debugging your knowledge of your programming language."

Wahrscheinlich alle zu dumm, oder?

ein Zitat von L. Toralds, welches ich auf den Punkt gebracht finde:

"inefficient abstracted programming models where two years down the road
   you notice that some abstraction wasn't very efficient, but now all
   your code depends on all the nice object models around it, and you
   cannot fix it without rewriting your app."

Autor: Achim S. (achs)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Der wo ich bin schrieb:
> Mein Beispiel oben (uint8_t)

Da ins gleiche Horn die 40 Jahre alte Weisheit: die von Mathematikern 
erfunden Zahlen sind kompakt und wunderschön. Sie sollten nicht von 
Ingenieuren zugemüllt werden.

Es ging darum, ob den Zahlen Einheiten zugeordnet sein sollten.  Nein! 
Auch wenn dann der Compiler  da ein paar Fallstricke erkennen kann ... 
Eine Zahl ist eine Zahl, wenn ich sie z.b. im Menü eingebe oder mit 
min/max teste...

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> Der wo ich bin schrieb:
>> Mein Beispiel oben (uint8_t)
>
> Da ins gleiche Horn die 40 Jahre alte Weisheit: die von Mathematikern
> erfunden Zahlen sind kompakt und wunderschön. Sie sollten nicht von
> Ingenieuren zugemüllt werden.
>
> Es ging darum, ob den Zahlen Einheiten zugeordnet sein sollten.  Nein!
> Auch wenn dann der Compiler  da ein paar Fallstricke erkennen kann ...
> Eine Zahl ist eine Zahl, wenn ich sie z.b. im Menü eingebe oder mit
> min/max teste...

kannst Du noch ein wenig ausführen, worum es hier geht? Geht es noch um 
Rust, oder was ist das Thema?

Klingt eher nach c/Assembler vs. die Moderne?

vlg
 Timm

: Bearbeitet durch User
Autor: Privatfrickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der wo ich bin schrieb:
> google mal "Rust severely disappoints
> me" von Eric Raymond. Am besten auch googeln wer das ist.
>
> Und kuck dir mal die Sprache Zig an und warum sie ins Leben gerufen
> wurde.
> Zitat:
> "Small, simple language. Focus on debugging your application rather than
> debugging your knowledge of your programming language."

Also ist Zig das neue Rust?

https://ziglang.org/
const builtin = @import("builtin");
const std = @import("std");
const io = std.io;
const fmt = std.fmt;
const os = std.os;

pub fn main() !void {
    var stdout_file = try io.getStdOut();
    var stdout_file_stream = io.FileOutStream.init(&stdout_file);
    const stdout = &stdout_file_stream.stream;

    try stdout.print("Welcome to the Guess Number Game in Zig.\n");

    var seed_bytes: [@sizeOf(u64)]u8 = undefined;
    os.getRandomBytes(seed_bytes[0..]) catch |err| {
        std.debug.warn("unable to seed random number generator: {}", err);
        return err;
    };
    const seed = std.mem.readInt(seed_bytes, u64, builtin.Endian.Big);
    var prng = std.rand.DefaultPrng.init(seed);

    const answer = prng.random.range(u8, 0, 100) + 1;

    while (true) {
        try stdout.print("\nGuess a number between 1 and 100: ");
        var line_buf: [20]u8 = undefined;

        const line_len = io.readLine(line_buf[0..]) catch |err| switch (err) {
            error.InputTooLong => {
                try stdout.print("Input too long.\n");
                continue;
            },
            error.EndOfFile, error.StdInUnavailable => return err,
        };

        const guess = fmt.parseUnsigned(u8, line_buf[0..line_len], 10) catch {
            try stdout.print("Invalid number.\n");
            continue;
        };
        if (guess > answer) {
            try stdout.print("Guess lower.\n");
        } else if (guess < answer) {
            try stdout.print("Guess higher.\n");
        } else {
            try stdout.print("You win!\n");
            return;
        }
    }
}

Autor: Jan W. R. (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Der wo ich bin schrieb:

>> "Rust severely disappoints me" von Eric Raymond. Am besten auch googeln wer das 
ist.

https://de.wikipedia.org/wiki/Eric_S._Raymond

„…Er bekennt sich zu den Idealen des Libertarismus und ist starker 
Verfechter des Rechts auf Waffenbesitz“
Verfechter des Rechts auf Waffenbesitz leben meiner Meinung nach in 
Irrtum. Ein Grund für mich sich mit Ihm nicht zu beschäftigen, um 
solchen Leuten kein Zuspruch und Anerkennung zu geben


>>"Small, simple language. Focus on debugging your application rather than
>> debugging your knowledge of your programming language."

Ist eine Coole Aussage, leider sehr Pauschal könnte auch auf der 
folgenden Internetseite stehen :
http://www.toodarkpark.org/computers/humor/shoot-s...

Dort sind Witze zu finden wie z.B.  :
>>C++ ◦You accidentally create a dozen instances of yourself and shoot them all in 
the foot. Providing emergency medical assistance is impossible since you can't 
tell which are bitwise copies and which are just pointing at others and saying, 
>>"That's me, over there."

Zitat:
>>"inefficient abstracted programming models where two years down the road
>>   you notice that some abstraction wasn't very efficient, but now all
>>   your code depends on all the nice object models around it, and you
>>   cannot fix it without rewriting your app."

Ist auch eine pauschale Aussage, Populismus.

Ein Amerikanischer Senator leugnete den Klimawandel und warf einen 
Schneeball auf den Boden unter dem Stichwort, „Ist doch kalt draußen“
Es war eine coole Aktion, leide Falsch die Aussage. Jeder von uns weis 
das wir den Klimawandel und Erderwärmung haben.
Mit diesem banalen Beispiel wollte ich sagen das solche Zitate keine 
Argumente sind.


Der Profi selbst weiß wie viel Abstraktion und wie viel Typisierung  wo 
und wie eingesetzt wird.

Gruss,
Jan

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr schön gesagt.

Das klingt wohl jetzt auch pauschal aber denke auch der Entwickler muss 
eben einschätzen ob das Risiko nach einem Jahr fest zu stellen dass man 
falsch abstrahiert hat, grösser ist, als das Risiko nach eine Jahr nicht 
mehr in seinem eigenen Code durch zu blicken weil man grade nicht 
abstrahiert hat.


Am Ende wird man wohl nie alle glücklich machen können mit einer Sprache 
denn grade bei der Frage wie restriktiv die Sprache sein soll, scheiden 
sich die Geister.

Autor: W.S. (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Der wo ich bin schrieb:
> Ich hab mal eine grundsätzliche Frage...
> ...
> Ich bevorzuge C ...

Nö. präziser: GENERAL-NÖ.
Ich bevorzuge C überhaupt nicht, sondern benutze es nur notgedrungen und 
nur dort, wo es keine besseren Alternativen gibt.
Und all diese Pippifax-C-Ersatz-Sprachen sind durchweg eben keine 
Alternativen, geschweige denn bessere Alternativen.

Die Gründe für all dieses Sich-Winden in neuerfundenen Sprachen habe ich 
ja schon viel weiter oben dargelegt: Die Spracherfinder stecken mental 
viel zu tief in der C-Furche und kommen dort zeitlebens nie wieder 
heraus.

Genau DAS ist die Tragik bei all den fruchtlosen Bemühungen.

Wenn man mal bedenkt, wieviel Entwicklungsaufwand vergeigt wird in dem 
Bemühen, eine Art neues C mit allen bisherigen Gewohnheiten aber 
zugleich ohne all die bisherigen Geburtsfehler und Fallstricke und 
natürlich ohne das Aufgeben von bisheriger Syntax, dann wird unsereiner 
melancholisch.

Viel Lärm um nichts, wasch mich ohne mich naßzumachen, nur einmal um 
sich selbst gedreht ohne ein neues (oder wenigstens besseres) Ufer 
erreicht zu haben.

W.S.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Viel Lärm um nichts, wasch mich ohne mich naßzumachen, nur einmal um
> sich selbst gedreht ohne ein neues (oder wenigstens besseres) Ufer
> erreicht zu haben.

Was schlägst Du also vor? Du scheinst eine Vision zu haben, wie sieht 
sie konkret aus Deine radikale Abkehr von allem dagewesenen die alles 
endlich wirklich besser macht?

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> Da ins gleiche Horn die 40 Jahre alte Weisheit: die von Mathematikern
> erfunden Zahlen sind kompakt und wunderschön. Sie sollten nicht von
> Ingenieuren zugemüllt werden.

Leider hast Du da eine Kleinigkeit übersehen: Der Zahlenraum in dem 
Mathematiker arbeiten können ist unbegrenzt und unendlich. Der eines 
Computers nicht.

Ergo muss man sich bei der Programmierung auf sinnvolle Einheiten und 
mitunter auch Einheitenvorsätze festlegen, um den vorhandenen Zahlenraum 
sinnvoll nutzen zu können.

Autor: Timm R. (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also dieser sehr bekannte Benchmark für Rust

https://benchmarksgame-team.pages.debian.net/bench...

mogelt, finde ich, ein bisschen. Das Rust Programm benutzt die externe 
Bibliothek Rayon für parallele Verarbeitung. Rayon gehört nicht zum 
Sprachumfang. Dann müsste ein C/C++ Programm auch externe 
Hilfsbibliotheken benutzen dürfen.

vlg

 Timm

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Timm R. schrieb:
> Hallo,
>
> also dieser sehr bekannte Benchmark für Rust
>
> https://benchmarksgame-team.pages.debian.net/bench...
Wieso bekannt? Und wieso Benchmark? Es nennt sich selbst benchmarkgame.


Timm R. schrieb:
> mogelt, finde ich, ein bisschen. Das Rust Programm benutzt die externe
> Bibliothek Rayon für parallele Verarbeitung. Rayon gehört nicht zum
> Sprachumfang. Dann müsste ein C/C++ Programm auch externe
> Hilfsbibliotheken benutzen dürfen.
>
> vlg
>
>  Timm
Es wird noch mehr "gemogelt". Beim rust-Program auf Platz 1 steht als 
Author unter anderem "Rust Project Developers". Wo ist das Beispiel mit 
den Authoren "g++ Developers" oder "clang++ Developers"?

Wenn dann in den c++ Beispielen sowas wie:
template< class type >
struct vector2 : public std::vector<type> {
   type &last() { return this->operator[]( std::vector<type>::size() -1 ); }
};
oder
struct Chunker {
protected:
   static volatile int printQueue;
};
vorkommt, muss man sich schon fragen, was da überhaupt vergleichbar sein 
soll.

Autor: Privatfrickler (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
W.S. schrieb:
> Ich bevorzuge C überhaupt nicht, sondern benutze es nur notgedrungen und
> nur dort, wo es keine besseren Alternativen gibt.
> Und all diese Pippifax-C-Ersatz-Sprachen sind durchweg eben keine
> Alternativen, geschweige denn bessere Alternativen.
>
> Die Gründe für all dieses Sich-Winden in neuerfundenen Sprachen habe ich
> ja schon viel weiter oben dargelegt: Die Spracherfinder stecken mental
> viel zu tief in der C-Furche und kommen dort zeitlebens nie wieder
> heraus.
>
> W.S.

Was würdest DU als Alternative vorschlagen?

Autor: mh (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
mh schrieb:
> Es wird noch mehr "gemogelt".

Ich muss mich korrigieren. Es wird gemogelt! Die Regeln schreiben das 
zeilenweise Einlesen von stdin vor, wobei die Zeilen max. 60 Zeichen 
lang sind. Das rust-Programm liest deutlich größere Blöcke.

Autor: W.S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Was schlägst Du also vor? Du scheinst eine Vision zu haben, wie sieht
> sie konkret aus Deine radikale Abkehr von allem dagewesenen die alles
> endlich wirklich besser macht?

Hä?
Du tust ja grad so, als ob ICH sowas wie Rust und Konsorten verzapft 
hätte. Nein, hab ich nicht. Ich habe mich durchaus nicht von allem 
Dagewesenen abgekehrt - insbesondere ICH NICHT.

Aber anstatt sich immer neue Sprachen auszudenken, die aussehen und 
funktionieren wie ein verwurschteltes C, hätte ich den Neusprachlern 
eher angeraten, ihren Elan darauf zu verwenden, ihre Herkunfts-Sprache 
zu renovieren, und das gründlich.
Also:
- Headerdateien abschaffen und stattdessen ein echtes Modulsystem auf 
Compilerebene einführen, wo sauber geregelt ist, welche Entitäten des 
Moduls von außen sichtbar und zugänglich sein dürfen und welche nicht.
- verläßliche Datentypen auf Compilerebene einführen. Datentypen haben 
gefälligst problemorientiert zu sein und nicht hardwareorientiert. 
Letzteres hinzukriegen, ist Aufgabe des Compilers und nicht der Sprache.
- boolean einführen
- Strings einführen. Also sowas, wo man ohne Abzählen bis null die Länge 
kennt und die man addieren kann, ohne dabei die berüchtigten 
Pufferüberläufe zu riskieren.
- char von allen Integertypen trennen
- keinerlei Defaults zulassen
- keinerlei Wert von Anweisungen zulassen
- die Deklaration von Konstanten, Typen und Variablen radikal umstellen.
  Bei Variablen
 attribut attribut.. name;
 attribut attribut.. name[indexbereich];
auf
 name : typbezeichnung;
wobei die Typbezeichnung ZUVOR dem Compiler bekannt sein muß.
- die Deklarationen sauber von Anweisungen und Funktionen trennen.
- einen sauberen Zuweisungsoperator einführen, um die Verwendung des "=" 
zum Zuweisen abzuschaffen. Das Gleichheitszeichen ist nämlich ein 
mathematisches Zeichen, das man verdammt noch mal nicht mißbrauchen 
sollte. Ein Ähnliches gilt für den Asterisk (das Sternchen) und das Et 
(Kaufmannsund, "&"), was man vom At ("@") unterscheiden sollte. 
Heutzutage ist das At den Leuten ohnehin weitaus geläufiger als das Et 
und das Sternchen für die bisherigen Pointeroperationen.
- Gleichheit für alle Pointeroperationen einführen. Dabei fliegen 
Sternchen und Et raus, ebenso "->", und das Ganze wird mit dem Punkt für 
Members ersetzt.
- Einführen von Variablenreferenzen anstelle von Pointern als Argumente 
zwecks besserer Kontrolle durch den Compiler.

So, reicht das für den Anfang? Bin mal gespannt, ob jetzt ein Gekreisch 
hier einsetzt.

Man muß ja nicht alles auf einmal einführen, damit das Gezeter der ewig 
Gestrigen sich auf einen größeren Zeitraum verteilt.

W.S.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> Aber anstatt sich immer neue Sprachen auszudenken, die aussehen und
> funktionieren wie ein verwurschteltes C, hätte ich den Neusprachlern
> eher angeraten, ihren Elan darauf zu verwenden, ihre Herkunfts-Sprache
> zu renovieren, und das gründlich.
> Also:

Ok, also schaun wir mal Punkt für Punkt:

> - Headerdateien abschaffen und stattdessen ein echtes Modulsystem auf
> Compilerebene einführen, wo sauber geregelt ist, welche Entitäten des
> Moduls von außen sichtbar und zugänglich sein dürfen und welche nicht.

check

> - verläßliche Datentypen auf Compilerebene einführen. Datentypen haben
> gefälligst problemorientiert zu sein und nicht hardwareorientiert.

check

> Letzteres hinzukriegen, ist Aufgabe des Compilers und nicht der Sprache.

? Ein Typsystem mit solchen Garantien muß immer Teil der 
Sprachdefinition sein

> - boolean einführen

check

> - Strings einführen. Also sowas, wo man ohne Abzählen bis null die Länge
> kennt und die man addieren kann, ohne dabei die berüchtigten
> Pufferüberläufe zu riskieren.

check

> - char von allen Integertypen trennen

check

> - keinerlei Defaults zulassen

?

> - keinerlei Wert von Anweisungen zulassen

check

> - die Deklaration von Konstanten, Typen und Variablen radikal umstellen.
>   Bei Variablen
>  attribut attribut.. name;
>  attribut attribut.. name[indexbereich];
> auf
>  name : typbezeichnung;
> wobei die Typbezeichnung ZUVOR dem Compiler bekannt sein muß.

check

> - die Deklarationen sauber von Anweisungen und Funktionen trennen.

? Die Syntax ist klar, es ist deutlich ersichtlich was eine 
Variablenddeklaration ist und was nicht, es gibt sogar ein eigenes 
Keyword dafür "let", ist das getrennt genug?
also check (für meine Ansprüche zumindest)

> - einen sauberen Zuweisungsoperator einführen, um die Verwendung des "="
> zum Zuweisen abzuschaffen. Das Gleichheitszeichen ist nämlich ein
> mathematisches Zeichen, das man verdammt noch mal nicht mißbrauchen
> sollte. Ein Ähnliches gilt für den Asterisk (das Sternchen) und das Et
> (Kaufmannsund, "&"), was man vom At ("@") unterscheiden sollte.
> Heutzutage ist das At den Leuten ohnehin weitaus geläufiger als das Et
> und das Sternchen für die bisherigen Pointeroperationen.

Reine Kosmetik. Ob er = oder := oder <- oder sonstwie geschrieben wird 
ist schnurz. Rust hat einen "sauberen" Zuweisungsoperator, der ganze 
andere Kram mit & vs @ ist auch reine Kosmetik, Pascal hätte auch mit & 
statt @ funktioniert und keiner hätte sich daran gestört. Der einzige 
valide Kritikpunkt wäre daß man argumentieren könnte daß das Sternchen 
zum Dereferenzieren auf der falschen Seite steht (ist mir auch sofort 
ins Auge gestochen, bei Pascal zum Beispiel steht das Dach auf der 
richtigen Seite) aber selbst das ist nur minimale Kosmetik die hinter 
weit wichtigerem zurücktritt.

also check

> - Gleichheit für alle Pointeroperationen einführen. Dabei fliegen
> Sternchen und Et raus, ebenso "->", und das Ganze wird mit dem Punkt für
> Members ersetzt.

? Die Sprache soll verständlich sein, also sollte man schon sehen was 
man schreibt, denselben Operator für völlig unterschiedliche 
Operationen?
Unfug

Und übrigens das -> hat in Rust überhaupt nichts mit Pointeroperationen 
zu tun, ich weiß nicht warum Du das jetzt anführst, das -> symbolisiert 
den Abbildungspfeil wie man ihn aus der Mathematik kennt bei der 
Deklaration einer Funktion, es zeigt auf den Zieltyp der Abbildung, zum 
Beispiel so:

fn foo(x: i32) -> i32

> - Einführen von Variablenreferenzen anstelle von Pointern als Argumente
> zwecks besserer Kontrolle durch den Compiler.

Check


Also was war nochmal Deine Kritik an Rust? Als Pascal-Liebhaber müßtest 
Du es eigentlich lieben, endlich ein "Pascal" ohne Boilerplate, dann 
sogar noch mit Typinferenz und die Kompilezeit-Typsicherheit gleich 
nochmal ins übernächste Level katapultiert! Was will man mehr?

: Bearbeitet durch User
Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Da musste ich schon ein wenig grinsen :)

Erst schreibt W.S.:

W.S. schrieb:
> Rust ist ganz offensichtlich nur ein weiterer Vorbrenner für C. Sieht ja
> auch fast genauso aus, ist nur noch ein wenig unübersichtlicher.

Auf die Nachfrage hin, wie denn seine Vision aussehe, schreibt er:

W.S. schrieb:
> Aber anstatt sich immer neue Sprachen auszudenken, die aussehen und
> funktionieren wie ein verwurschteltes C, hätte ich den Neusprachlern
> eher angeraten, ihren Elan darauf zu verwenden, ihre Herkunfts-Sprache
> zu renovieren, und das gründlich.
> Also:
> ...

Da, wo die ... stehen, beschreibt er Features, die zu 95% von Rust
umgesetzt wurden und die Bernd netterweise Stück für Stück aufgedröselt
hat:

Bernd K. schrieb:
> check
> check
> check
> ...

@W.S:

Bist du sicher, dass deine Vision der optimalen Programmierpsrache ein
Vorbrenner für C ist, der fast genauso aussieht und nur ein wenig
unübersichtlicher ist? ;-) SCNR

Wobei man sagen muss, dass die meisten der von dir aufgeführten
Forderungen von fast jeder neueren Programmiersprache erfüllt werden.
Das, was die Sprachen wirklich voneinander unterscheidet, beschränkt
sich nicht auf solche Oberflächlichkeiten.

: Bearbeitet durch Moderator
Autor: Privatfrickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Reine Kosmetik. Ob er = oder := oder <- oder sonstwie geschrieben wird
> ist schnurz.

Gerade die "Kosmetik" zwingt aber leidlich zum permanenten Umdenken und 
schafft somit unnötig zusätzliche Komplexität. Wenn fünf 
Programmiersprachen fünf verschiedene Symbole für Zuweisungen verwenden, 
dann hast du fünf-fachen Aufwand diese zu unterscheiden. Und es bleibt 
ja nicht bei diesem einen Umstand. Für den Vergleich gibt es dann 
vielleicht wieder fünf verschiedene Symbole. Für einen Zeiger nochmals 
fünf weitere Unterschiedlichkeiten. Vor lauter Symboljongliererei 
verbraucht man dann mehr Hirnschmalz das noch auseinanderzuhalten als 
sich dem eigentlichen Sinn der Programmiererei zuzuwenden.

Autor: Privatfrickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder nehmt mal die ausufernde
const 

Verwendung aus dem Beispielcode von ziglang aus meinem Post weiter oben.

Warum muss eine sich verändernde Zeilenlänge unbedingt ein const davor 
tragen? Das erscheint doch irgendwie widersinnig!
const line_len = io.readLine(line_buf[0..]) catch |err| switch (err) 

Mit Intuition kommt man jedenfalls nicht darauf.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Privatfrickler schrieb:
> Warum muss eine sich verändernde Zeilenlänge unbedingt ein const davor
> tragen? Das erscheint doch irgendwie widersinnig!
> const line_len = io.readLine(line_buf[0..]) catch |err| switch (err)

Wo ändert sich line_len? Ich sehe da nur lesende Zugriffe.

Privatfrickler schrieb:
> Oder nehmt mal die ausuferndeA
>
> const
>
> Verwendung

Deswegen sind in Rust alle Variablen defaultmäßig const, so dass dort
nichts ausufert. Nur dijenigen Variablen, die überschrieben werden
sollen, werden speziell deklariert, nämlich mit "mut".

Autor: Privatfrickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Wo ändert sich line_len? Ich sehe da nur lesende Zugriffe.

Also ich sehe zumindest keine Zeichenkette die Konstant bleibt, sonst 
gäbe es ja kein
try stdout.print("Input too long.\n");

Aber vielleicht habe da auch einfach eine andere Sichtweise als du?

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Privatfrickler schrieb:
> Gerade die "Kosmetik" zwingt aber leidlich zum permanenten Umdenken und
> schafft somit unnötig zusätzliche Komplexität. Wenn fünf
> Programmiersprachen fünf verschiedene Symbole für Zuweisungen verwenden,

Die überwiegende Mehrheit inclusive der Zielgruppe C(++)-Umsteiger 
verwendet ja schon das simple = für die Zuweisung, also hat Rust die 
richtige Wahl getroffen. Ein := hätt ich aber genauso akzeptiert, ich 
mach noch viel Pascal nebenher, Probleme mit dem Umdenken kann ich nicht 
feststellen. Ab und zu vielleicht mal ein Vertipper wenn man zehnmal am 
Tag hin- und herwechselt aber der Compiler meckert sofort, keine große 
Sache.

Ich find das überhaupt nicht dramatisch.

Bei vielen (allen) Sachen muß man "umdenken", nicht nur bei der Syntax, 
wenn man die Sprache wechselt, mir rutscht auch zweimal die Woche ein ; 
am Zeilenende in Python raus und sofort klopft mir der Linter auf die 
Finger, ich empfinde das aber nicht als Erschwernis, mit der Zeit 
beherrscht man das im Schlaf und kann in 2 Sekunden fast vollständig 
umswitchen ohne nachzudenken.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Privatfrickler schrieb:
> Yalu X. schrieb:
>> Wo ändert sich line_len? Ich sehe da nur lesende Zugriffe.
>
> Also ich sehe zumindest keine Zeichenkette die Konstant bleibt, sonst
> gäbe es ja kein
> try stdout.print("Input too long.\n");
>
> Aber vielleicht habe da auch einfach eine andere Sichtweise als du?

Const bedeutet in diesem Zusammenhang, dass die Variable, nachdem sie
einmal initialisiert, d.h. an einen Wert gebunden worden ist, während
ihrer gesamten Lebensdauer diesen Wert beibehält. Das bedeutet nicht
unbedingt, dass der Wert schon zur Compilezeit feststeht.

Auch die Zeichenkettenvariable line_buf könnte als const deklariert
werden, wenn es eine Möglichkeit gäbe, sie direkt bei ihrer Deklaration
zu initialisieren, etwa mit

   const line_buf: [20]u8 = io.readLine();

Da die Funktion io.readLine() die gelesene Zeichenkette aber nicht als
Funktionswert, sondern in einem variablen Funktionsargument zurückgibt,
gibt es diese Möglichkeit nicht. Deswegen wird line_buf zunächst mit
"undefined" initialisiert und danach durch io.readLine() überschrieben.

In Rust ist die "Constness" ebenso definiert, nur dass man dort das
Schlüsselwort "const" nicht explizit hinschreibt.

: Bearbeitet durch Moderator
Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Privatfrickler schrieb:
> Gerade die "Kosmetik" zwingt aber leidlich zum permanenten Umdenken und
> schafft somit unnötig zusätzliche Komplexität. Wenn fünf
> Programmiersprachen fünf verschiedene Symbole für Zuweisungen verwenden,
> dann hast du fünf-fachen Aufwand diese zu unterscheiden.

Ja aber wenn es eine Sprache so richtig verkackt hat wie C mit = und ==, 
dann muss man diesen Fehler wirklich nicht ständig wieder machen (JS, 
Python, Rust...).

Das hat schon was von Einsteins Satz über die Definition von Wahnsinn.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Const bedeutet in diesem Zusammenhang, dass die Variable, nachdem sie
> einmal initialisiert, d.h. an einen Wert gebunden worden ist, während
> ihrer gesamten Lebensdauer diesen Wert beibehält. Das bedeutet nicht
> unbedingt, dass der Wert schon zur Compilezeit feststeht.

Das ist ne ziemlich ungewöhnliche Definition einer Konstanten, finde 
ich. So wie: Wir wissen zwar noch nicht, wie groß Pi diesmal sein wird, 
aber wenn wir erstmal nen Wert haben lassen wir ihn so.

Gerade für Embedded finde ich das verwirrend, werden Konstanten dort 
doch oft direkt in den Code eingebaut (ldi, cpi, subi), was ja irgendwie 
schwer geht wenn sie noch nicht feststehen.

Also muss der Compiler wieder unterscheiden zwischen "echten" Konstanten 
und - naja, nennen wir sie Variablen.

Autor: Privatfrickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Deswegen wird line_buf zunächst mit
> "undefined" initialisiert und danach durch io.readLine() überschrieben.

Dagegen habe ich ja auch überhaupt nichts einzuwenden. Man möchte einen 
Zeichenpuffer bereitstellen, dessen Größe man zunächst nicht angeben 
möchte (wobei das ja an sich schon irrig ist, denn dann müsste man ja 
MÖGLICHERWEISE AUCH von ausgehen, dass der Zeichenpuffer beispielsweise 
auch unsinnig groß (1 TB) werden könnte, aber wer will das schon?). Also 
bekommt er ein "undefined" aufgepappt und geht damit in die while(true) 
Endlosschleife. Nun kommt der Lesevorgang (io.readline). Der wird doch 
immer wieder ausgeführt, solange der catch nix schlimmes signalisiert. 
Also wird der Zeilenpuffer auch immer wieder mit anderen Wertlängen 
beschrieben. Was ist daran nun Konstant?

Mich stört einfach der Begriff const hier. Wenn es nur darum geht, 
auszuschließen, dass sonstwie (an anderer Codestelle) auf den Puffer 
zugegriffen wird, wäre doch so was wie ein blocked viel angebrachter.

anstatt
const line_len = io.readLine(line_buf[0..]) catch |err| switch (err)
müsste es beispielsweise heißen
blocked line_len = io.readLine(line_buf[0..]) catch |err| switch (err)

const. wäre dann nur noch für wirklich konstante Längen verwendbar

Wie auch immer. Sowas nervt mich eben, hält einfach von anderem ab und 
stielt unnütz meine Zeit.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl K. schrieb:
> Ja aber wenn es eine Sprache so richtig verkackt hat wie C mit = und ==,
> dann muss man diesen Fehler wirklich nicht ständig wieder machen (JS,
> Python, Rust...).

Das Problem bei C ist ja nicht, dass die Operatoren = und == heißen,
sondern dass eine Zuweisung (bspw. a=13) ein Ausdruck mit einem
Ergebniswert (im Beispiel: 13) ist, der als Bedingung in einem if- oder
while- oder for-Konstrukt verwendet werden kann, bspw. in if(a=13) ...,
was oft nicht beabsichtigt ist.

In Python führt if a=13: ... zu einem Syntaxfehler. Aber auch die
C-Compiler sind mittlerweile so weit, dass sie bei if(a=13) ..., obwohl
syntaktisch korrekt, wenigstens eine Warnung auisgeben.

Karl K. schrieb:
> Yalu X. schrieb:
>> Const bedeutet in diesem Zusammenhang, dass die Variable, nachdem sie
>> einmal initialisiert, d.h. an einen Wert gebunden worden ist, während
>> ihrer gesamten Lebensdauer diesen Wert beibehält. Das bedeutet nicht
>> unbedingt, dass der Wert schon zur Compilezeit feststeht.
>
> Das ist ne ziemlich ungewöhnliche Definition einer Konstanten, finde
> ich. So wie: Wir wissen zwar noch nicht, wie groß Pi diesmal sein wird,
> aber wenn wir erstmal nen Wert haben lassen wir ihn so.

Im englischen Sprachgebrauch unterscheidet man zwischen

  compile-time constant

und

  immutable

In C++ werden dafür die beiden Schlüsselwörter "constexpr" und "const"
verwendet, um diesen Unterschied deutlich zu machen.

In der Mathematik wäre eine Konstante wie π oder e compile-time constant
und eine gewöhnliche Variable immutable. Mutable Variablen gibt es in
der mathematischen Formelsprache nicht, da es dort auch keine
Zuweisungen gibt.

: Bearbeitet durch Moderator
Autor: Privatfrickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Mutable Variablen gibt es in
> der mathematischen Formelsprache nicht, da es dort auch keine
> Zuweisungen gibt.

Was genau meinst du denn jetzt mit "mathematischer Formelsprache"?

y = 1 Konstant
y = x für x e R nicht mehr allzu Konstant oder?

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Privatfrickler schrieb:
> Nun kommt der Lesevorgang (io.readline). Der wird doch
> immer wieder ausgeführt, solange der catch nix schlimmes signalisiert.
> Also wird der Zeilenpuffer auch immer wieder mit anderen Wertlängen
> beschrieben. Was ist daran nun Konstant?

Der Zeilenpuffer kann ja aus dem o.g. Grund sowieso nicht als const
deklariert werden. Aber nehmen wir wieder line_len als Beispiel:

Diese (immutable) Variable ist innerhalb der While-Rumpfs deklariert.
Ihre Lebensdauer erstreckt sich damit von der Zeile, in der sie
deklariert wird bis zum Ende des While-Rumpfs, also bis zur schließenden
geschweiften Klammer in der zweitletzten Codezeile.

Mit jedem Schleifendurchlauf wird die Variable (zumindest formal) neu
geschaffen und am Ende dieses Schleifendurchlaufs wieder zerstört.
Dazwischen wird die Variable kein einziges Mal überschrieben.

> Mich stört einfach der Begriff const hier. Wenn es nur darum geht,
> auszuschließen, dass sonstwie (an anderer Codestelle) auf den Puffer
> zugegriffen wird, wäre doch so was wie ein blocked viel angebrachter.

Ich gebe dir recht, dass das Schlüsselwort "const" etwas unglücklich
gewählt ist. Aber auch der Begriff "blocked" würde mich in diesem
Zusammenhang stören. Mit "blocked" verbinde ich etwas Laufendes, was
plötzlich angehalten wird. Vielleicht können wir uns ja auf "immutable"
als besten Kompromiss einigen.

Oder man geht der Diskussion ganz aus dem Weg, indem man wie in Rust
solche const/immutable Variablen gar nicht explizit als solche
deklariert :)

: Bearbeitet durch Moderator
Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Privatfrickler schrieb:
> Yalu X. schrieb:
>> Mutable Variablen gibt es in
>> der mathematischen Formelsprache nicht, da es dort auch keine
>> Zuweisungen gibt.
>
> Was genau meinst du denn jetzt mit "mathematischer Formelsprache"?
>
> y = 1 Konstant
> y = x für x e R nicht mehr allzu Konstant oder?

Richtig, deswegen heißt man y ja auch eine Variable und keine Konstante.
y ist aber auch nicht so variabel wie eine mutable Variable in einer
Programmiersprache. In C kann man schreiben:

  y = 3;
  y = y + 1;

wodurch y am Ende den Wert 4 hat.

In der Mathematik wäre die zweite Zeile entweder eine nicht lösbare
Gleichung oder eine wenig sinnhafte rekursive Definition für y.

Als rekursive Definition wird die zweite Zeile übrigens auch in
Funktionalsprachen (die stark von der mathematischen Schreib- und
Denkweise inspiriert sind) interpretiert. Auch dort ergibt sie praktisch
keinen Sinn.

Der Ausdruck x ∈ ℝ bedeutet in der Mathematik nicht, dass x alle paar
Sekunden einen neuen Wert annimmt. Er bedeutet vielmehr, dass x einen
beliebigen Wert annehmen darf, der aber im nachfolgenden Text (wenn
bspw. irgendwelche Sätze aufgestellt werden, in denen y vorkommt) fest
bleibt.

Autor: Privatfrickler (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Der Zeilenpuffer kann ja aus dem o.g. Grund sowieso nicht als const
> deklariert werden.

Es ging ja auch nicht um den Inhalt des Zeilenpuffers

also ob da "abcde" oder "12345" drin steht, sondern um die Länge also
"abc" (3 Zeichen + Zeilenende) oder "dieKatzeLiegtImSchnee" (21 Zeichen 
+ Zeilenende)

> Aber nehmen wir wieder line_len als Beispiel:
> Diese (immutable) Variable ist innerhalb der While-Rumpfs deklariert.

Richtig.

> Ihre Lebensdauer erstreckt sich damit von der Zeile, in der sie
> deklariert wird bis zum Ende des While-Rumpfs, also bis zur schließenden
> geschweiften Klammer in der zweitletzten Codezeile.

Korrekt.

> Mit jedem Schleifendurchlauf wird die Variable (zumindest formal) neu
> geschaffen und am Ende dieses Schleifendurc