Forum: Compiler & IDEs Pascal next Generation:-) PascalABC


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Max M. (max_mueller)


Lesenswert?

Kennt eigentlich jemand
https://pascalabc.net/en/samples

Offenbar gibt es neben dem Freepascal / Lazarus Projekt, doch immer 
wieder neue verbesserte Pascal Versionen
Vom ABC Pascal hatte ich aber tatsächlich noch gar nicht gehört.

: Bearbeitet durch User
von Max M. (max_mueller)


Lesenswert?

Was mir aber immer wieder auffällt, das in Russland Pascal offenbar 
aktiver genutzt wird als woanders.
Und auf bei diesem Projekt sind wieder Russen beteiligt

von Falk B. (falk)


Lesenswert?

Max M. schrieb:
> Was mir aber immer wieder auffällt, das in Russland Pascal offenbar
> aktiver genutzt wird als woanders.

Die fliegen auch noch mit Rakten aus den 1970er Jahren ins Weltall.
Das passt dazu! Echt russisch halt!  ;-)

von Joe (Firma: Wessibisser) (joe_l794)


Lesenswert?

Falk B. schrieb:
> Die fliegen auch noch mit Rakten aus den 1970er Jahren ins Weltall.
> Das passt dazu! Echt russisch halt!  ;-)

Haben die sich sicher bei Perry Hoden abgekuckt. Der war ja recht 
erfolgreich damit.

von Wastl (hartundweichware)


Lesenswert?

Max M. schrieb:
> Was mir aber immer wieder auffällt, das in Russland Pascal offenbar
> aktiver genutzt wird als woanders.

Was mir aber immer wieder auffällt ist dass ich Pascal absolut
nicht vermisse seitdem ich angefangen habe C zu programmieren.
Und das ist schon lang her.

von Ralph S. (jjflash)


Lesenswert?

Wastl schrieb:
> Was mir aber immer wieder auffällt ist dass ich Pascal absolut
> nicht vermisse seitdem ich angefangen habe C zu programmieren.

Hm, ich programmiere seit über 20 Jahren mit C/C++ und vermisse Pascal 
dennoch, was der Grund ist, dass ich manche Desktopprogramme (und ein 
ewig währendes Konsolenprojekt das seit über 10 Jahren immer weiter 
wächst) tatsächlich immer wieder mal mit Lazarus schreibe. Bei größeren 
Projekten passiert mir (leider) immer wieder einmal, dass ich Dinge 
erledigen will, die in C normal sind und in Pascal nicht funktionieren. 
Allerdings gilt das auch umgekehrt: Kehre ich von Pascal in ein C 
Projekt zurück, versuche ich bspw. immer wieder einmal etwas zu machen, 
was in Pascal geht und in C nicht.

Grundsätzlich fände ich schön, wenn es für C so etwas wie Lazarus in 
einer einzigen GUI Umgebung geben würde, das dann auch alle 
Abhängigkeiten mit in das ausführbare Binary statisch linkt (auch wenn 
so etwas bei manchen wohl verpönt ist). So muß ich den QT Creator und 
das Visual Studio verwenden.

Lazarus finde ich intuitiver, jedoch ist eine IDE kein Vor- oder 
Nachteil einer Sprache. Schade, dass es so etwas wie Lazarus für 
Pascal/Delphi nicht auch für C/C++ gibt.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Ralph S. schrieb:
> Grundsätzlich fände ich schön, wenn es für C so etwas wie Lazarus in
> einer einzigen GUI Umgebung geben würde, das dann auch alle
> Abhängigkeiten mit in das ausführbare Binary statisch linkt (auch wenn
> so etwas bei manchen wohl verpönt ist). So muß ich den QT Creator und
> das Visual Studio verwenden.

Verstehe ich nicht...

Warum willst du Qt&VS parallel verwenden?

Ich habe schon wirklich ewig kein Qt Programm mehr statisch gelingt, 
aber damals war da einfach nur "CONFIG += static" im Project file 
einzutragen.
Kann aber sein, dass du noch die statischen Libs nachinstallieren musst, 
damit das geht...

Gerade der Qt creator ist eine vollintegrierte ide, die im Grunde alle 
Features von qt kann (also GUI design, übersetungen, android, bare metal 
MCU, JavaScript, ...). Sogar mehrere Compiler werden unterstützt (GCC 
und llvm... Wobei letzterer mMn besser verständliche warnings und Errors 
ausgibt...).

73

von Andreas B. (bitverdreher)


Lesenswert?

Ralph S. schrieb:
> Lazarus finde ich intuitiver, jedoch ist eine IDE kein Vor- oder
> Nachteil einer Sprache. Schade, dass es so etwas wie Lazarus für
> Pascal/Delphi nicht auch für C/C++ gibt.

Ich bin auch kein Freund von Pascal, aber Lazarus ist einfach 
unschlagbar. Da nehme ich die suboptimale Sprache gerne in Kauf.

von Harald K. (kirnbichler)


Lesenswert?

Ralph S. schrieb:
> das dann auch alle
> Abhängigkeiten mit in das ausführbare Binary statisch linkt

Was ist daran besonders? Das kann der von MS als "Visual Studio" 
vertriebene Compiler schon seit Jahrzehnten.

von Ralph S. (jjflash)


Lesenswert?

Hans W. schrieb:
> Warum willst du Qt&VS parallel verwenden?

von mir schlecht kommuniziert: Qt verwende ich privat, dienstlich muss 
ich VS !

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Ralph S. schrieb:
> Hans W. schrieb:
>> Warum willst du Qt&VS parallel verwenden?
>
> von mir schlecht kommuniziert: Qt verwende ich privat, dienstlich muss
> ich VS !

Ahhh, ok.

von Thorsten M. (pappkamerad)


Lesenswert?

Falk B. schrieb:
> Die fliegen auch noch mit Rakten aus den 1970er Jahren ins Weltall.
> Das passt dazu! Echt russisch halt!  ;-)

Fun Fact:
Dem Falk aus der SBZ seine Lieblingssprache, c, ist - Trommelwirbel - 
aus den 70ern.
Und sprachlich FreePascal um Jahrzehnte hinterher.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Wastl schrieb:
> Was mir aber immer wieder auffällt ist dass ich Pascal absolut
> nicht vermisse seitdem ich angefangen habe C zu programmieren.
> Und das ist schon lang her.

Pascal nähert sich C bzw. C++ immer mehr an. Dieser Prozess hat vor 40
Jahren mit Turbo Pascal begonnen (Herrn Wirth dürften wohl die Haare zu
Berge gestanden haben) und wurde mit Delphi, Free Pascal, mikroPascal
und nun auch PascalABC fortgesetzt. PascalABC unterstützt nun bspw. auch
blocklokale Variablen und Lambda-Ausdrücke.

Vielleicht kommt irgendwann der Tag, an dem die schrecklichen BEGINs und
ENDs durch schneller zu tippende und weniger aufdringliche geschweifte
Klammern ersetzt werden ;-)

von Max M. (max_mueller)


Lesenswert?

Du kannst es ja dem Freepascal Projekt vorschlagen.
Viele solcher Änderungen sind in der IDE anwählbar, in welchem "Style" 
man schreiben möchte

von Yalu X. (yalu) (Moderator)


Lesenswert?

Max M. schrieb:
> Du kannst es ja dem Freepascal Projekt vorschlagen.
> Viele solcher Änderungen sind in der IDE anwählbar, in welchem "Style"
> man schreiben möchte

Das ist gar nicht nötig. Man kann den Angleichungsprozess von Pascal
nach C++ (und darüber hinaus) sogar dramatisch beschleunigen, ohne die
wertvolle Zeit der Free-Pascal-Entwickler zu beanspruchen. Hier sind die
erforderlichen Änderungen:
1
alias fpc=clang++

Aber auch die neu hinzugefügten C++-Sprachfeatures sind noch nicht das
Gelbe vom Ei und bedürfen deswegen noch einer kleinen Überarbeitung:
1
alias clang++=rustc

Schon besser. Wenn man aber schon am Optimieren der Sprache ist, kann
man es auch gleich richtig machen:
1
alias rustc="ghc -x hs"


Zur Demonstration ein kleines Programm für den offiziellen FPC, das
einfach den Datenstrom von stdin nach stdout kopiert:

in2out1.pas:
1
program CopyInputToOutput;
2
3
var
4
  c: char;
5
6
begin
7
  while not eof do
8
    begin
9
      read(c);
10
      write(c)
11
    end
12
end.

O je, so viel Code für so eine einfache Aufgabe. Zudem scheint er
zweimal zu beginnen und zweimal zu enden, was schon sehr komisch
aussieht.

Nun dasselbe Programm für den erweiterten FPC:

in2out2.pas:
1
main = interact id

Kompiliert wird wie gewohnt mit
1
fpc in2out2.pas

Wo sind die BEGINs und ENDs geblieben, wo die verschachtelte Struktur
des Originalcodes?

Genau dahin muss sich Pascal in Zukunft entwickeln. Der FPC kann das
dank der oben beschriebenen Änderungen schon heute ;-)

von Harald K. (kirnbichler)


Lesenswert?

Früher™ bestand der Sinn einer Programmiersprache nicht nur darin, 
lauffähige Programme damit schreiben zu können, sondern auch, daß andere 
den Quelltext lesen und verstehen können.

Mit der heutigen exponentiellen Proliferation von Programmiersprachen, 
Sprachversionen und Dialekten aber wird bald ein Zustand erreicht, in 
dem jeder Programmierer seine ihm eigene und für alle anderen 
weitestgehend unverständliche Programmiersprache einsetzt.

von Crazy H. (crazy_h)


Lesenswert?

Yalu X. schrieb:
> O je, so viel Code für so eine einfache Aufgabe. Zudem scheint er
> zweimal zu beginnen und zweimal zu enden, was schon sehr komisch
> aussieht.
Da gibts dann Pascalversionen, bei denen es nach den While kein Begin 
gibt und das am Ende EndWhile heißt und so kann man das schön lesen. 
Wenn man dann noch fleißig mit Einrücken arbeitet, kapiert man das auch 
nach Jahrzehten noch 😉

von Uwe S. (lzmr)


Lesenswert?

Harald K. schrieb:
> Mit der heutigen exponentiellen Proliferation von Programmiersprachen,
> Sprachversionen und Dialekten aber wird bald ein Zustand erreicht, in
> dem jeder Programmierer seine ihm eigene und für alle anderen
> weitestgehend unverständliche Programmiersprache einsetzt.

Damit nur der Programmierer sein Projekt versteht und damit immer wieder 
Geld verdienen kann, schon x-mal erlebt.

von Harald K. (kirnbichler)


Lesenswert?

Uwe S. schrieb:
> Damit nur der Programmierer sein Projekt versteht und damit immer wieder
> Geld verdienen kann, schon x-mal erlebt.

Früher™ haben Programmierer das mit normalen und allgemein verbreiteten 
Programmiersprachen hinbekommen, einfach durch die Qualität (oder 
"Qualität") ihres Codes.

Dann wurden Programmierrichtlinien für Codedokumentation, -Qualität etc. 
eingeführt.

Heute kann man durch geschickte Auswahl der Programmiersprache trotz 
Einhaltung sämtlicher Coderichtlinien genau das gleiche Ziel erreichen. 
Daß die Programmiersprache nur drei Programmierer nördlich des 
Mittelmeers und ein Einsiedler irgendwo in der Südsee verstehen, dafür 
kann der gewiefte Programmierer ja nun nichts, oder?

von Falk B. (falk)


Lesenswert?

Harald K. schrieb:
> dem jeder Programmierer seine ihm eigene und für alle anderen
> weitestgehend unverständliche Programmiersprache einsetzt.

Willkommen in Babylon!

von Patrick C. (pcrom)


Lesenswert?

Ich komme aus der zeit von PC-programmierung in DOS; Turbo Pascal 6.0 
[mit Turbo Vision]
Danach bin ich in embedded programmierung hinein gegangen (C).
Vor 10 Jahren ein bisschen angefangen mit C# fuer PC programmierung. Da 
faellte mir direct auf das die object-orientierte structur von C# mir 
sehr bekannt vorkam.

Die erklaerung : Anders Hejlsberg. Stand am basis von Turbo Pascal und 
C#.
https://de.wikipedia.org/wiki/Anders_Hejlsberg

Meiner meinung sind in C# viele erfahrungen von die Turbo Pascal zeit 
mitgenommen.

Patrick aus die Niederlande

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Harald K. schrieb:

> Früher™ bestand der Sinn einer Programmiersprache nicht nur darin,
> lauffähige Programme damit schreiben zu können, sondern auch, daß andere
> den Quelltext lesen und verstehen können.

Nö, spätestens mit der Erfindung von C (eigentlich schon bei dessen 
Vorgängern) wurde diese Idee aufgegeben.

Immerhin gibt es aber für C zumindest einen Art Standard, später sogar 
einen echten Standard. Problem ist nur: inzwischen ist das auch schon 
wieder wesentlich mehr als nur einer. Wenn die Sprache wirklich gut 
gewesen wäre, hätte es bei einem bleiben können.

War sie aber offensichtlich absolut nicht.

Nunja, Pascal hat es meines Wissens nach niemals zu einem offiziellen 
Standard gebracht. War allerdings dafür von vornherein auf bessere 
*Menschen*-Lesbarkeit ausgelegt und auch ihre Weiterentwicklungen 
blieben diesem Grundkonzept überwiegend treu. Erst in jüngster Zeit 
drehen die Programmiersprachen-Designer auch hier völlig frei. Womit wir 
wohl beim Thema dieses Threads wären...

Aber dieser Ausflug sei mir noch gegönnt: Die C-Weiterentwicklung C++ 
ist schon seit Jahrzehnten völlig in ähnlicher Weise völlig ausgetickt. 
Ich möchte angesichts der schieren Komplexität der Sprache behaupten, 
das es praktisch niemanden (also keinen Menschen) auf der ganzen Welt 
mehr gibt, der diese Sprache wirklich komplett beherrscht. Die was 
anderes behaupten, muß man einfach nur mal von der Möglichekeit 
abschneiden, jederzeit nachschauen zu können. Dann lernen auch die, dass 
diese Sprache unbrauchbar für Menschen ist.

von Ein T. (ein_typ)


Lesenswert?

Crazy H. schrieb:
> Yalu X. schrieb:
>> O je, so viel Code für so eine einfache Aufgabe. Zudem scheint er
>> zweimal zu beginnen und zweimal zu enden, was schon sehr komisch
>> aussieht.
> Da gibts dann Pascalversionen, bei denen es nach den While kein Begin
> gibt und das am Ende EndWhile heißt und so kann man das schön lesen.
> Wenn man dann noch fleißig mit Einrücken arbeitet, kapiert man das auch
> nach Jahrzehten noch 😉

Aber dann könnte man sich diesen ganzen End[...]-Krams doch gleich 
ersparen und nur mit Einrückungen arbeiten. :-)

von Bernd S. (bernds1)


Lesenswert?

Ein T. schrieb:
> Aber dann könnte man sich diesen ganzen End[...]-Krams doch gleich
> ersparen und nur mit Einrückungen arbeiten. :-)

Es gibt Sprachen, die haben deine Idee einfach aufgegriffen :-)

von Norbert (der_norbert)


Lesenswert?

Ein T. schrieb:
> Aber dann könnte man sich diesen ganzen End[...]-Krams doch gleich
> ersparen und nur mit Einrückungen arbeiten. :-)

Uuuhhh, ich sehe einen Sturm seltsamer Färbung aufziehen… ;-)

von Crazy H. (crazy_h)


Lesenswert?

Ein T. schrieb:
> Aber dann könnte man sich diesen ganzen End[...]-Krams doch gleich
> ersparen und nur mit Einrückungen arbeiten. :-)

War das nicht Python?

von Ein T. (ein_typ)


Lesenswert?

Bernd S. schrieb:
> Ein T. schrieb:
>> Aber dann könnte man sich diesen ganzen End[...]-Krams doch gleich
>> ersparen und nur mit Einrückungen arbeiten. :-)
>
> Es gibt Sprachen, die haben deine Idee einfach aufgegriffen :-)

Verdammt! Ich dachte schon, ich hätte auch mal eine revolutionäre Idee. 
:-)

von Ein T. (ein_typ)


Lesenswert?

Norbert schrieb:
> Ein T. schrieb:
>> Aber dann könnte man sich diesen ganzen End[...]-Krams doch gleich
>> ersparen und nur mit Einrückungen arbeiten. :-)
>
> Uuuhhh, ich sehe einen Sturm seltsamer Färbung aufziehen… ;-)

Nach eingehender, tiefschürfender und umfangreicher Recherche vermute 
ich: er schlängelt eher, dieser Sturm. :-)

von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

Ob S. schrieb:
> Nunja, Pascal hat es meines Wissens nach niemals zu einem offiziellen
> Standard gebracht.

Genaugenommen schon:
- Standard Pascal: ANSI/IEEE770X3.97-1993 oder ISO 7185:1990;
- Extended Pascal: ANSI/IEEE770X3.160-1989 oder ISO/IEC 10206:1991;
- https://de.wikipedia.org/wiki/Pascal_(Programmiersprache)#Standards
- https://www.cs.utexas.edu/users/novak/iso7185.pdf

Ob S. schrieb:
> War allerdings dafür von vornherein auf bessere *Menschen*-Lesbarkeit ausgelegt
Das kann man sich durchaus darüber streiten. Gerade durch seine extreme 
"Geschwätzigkeit" finde ich Pascal eher unübersichtlich. Ganz zu 
schweigen von den Wunden Fingern, von den endlos viele unnütz langen 
begin/end/then usw. die da getippt werden müssen. Z.B. das "verstecken" 
der Variablendeklarationen am Anfang und nicht dort wie sie hingehören, 
finde ich Pers. extrem nervig.

C/C++ mag da genau das Gegenteil davon sein und gelegentlich fast schon 
etwas zu "Kurzform". Aber mit etwas Disziplin beim Schreiben/Einrücken, 
finde ich, schneller und besser zu lesen als Pascal. Ist aber wohl alles 
eine Frage der täglichen Übung.
Gegen blödsinnige Variablen- und Funktionsnamen usw. sind jedenfalls 
beide nicht geschützt.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Ob S. schrieb:
> Immerhin gibt es aber für C zumindest einen Art Standard, später sogar
> einen echten Standard.

Die ISO/IEC 9899 gibt es seit nunmehr 33 Jahren.

> Problem ist nur: inzwischen ist das auch schon wieder wesentlich mehr
> als nur einer.

Nein, es gibt nur den einen. Dieser wird zwar alle paar Jahre mal
aktualisiert (wie praktisch jede Norm, nicht nur im Computerbereich),
mit jeder Neuauflage werden aber die vorangegangen ungültig.

Anders als bei Pascal, wo die Standardisierung (ISO 7184 und ISO 10206)
vonseiten der Compilerhersteller wenig Beachtung fand und schon bald
wieder aufgegeben wurde, halten sich die gängigen C- und C++-Compiler
recht gut an den Standard.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Irgend W. schrieb:
> Ob S. schrieb:
>> War allerdings dafür von vornherein auf bessere *Menschen*-Lesbarkeit ausgelegt
> Das kann man sich durchaus darüber streiten. Gerade durch seine extreme
> "Geschwätzigkeit" finde ich Pascal eher unübersichtlich.

Es ist eigentlich ganz einfach:

Wer eine Sprache gelernt hat¹ und sich damit beschäftigt, kann Programme
in dieser Sprache auch problemlos lesen. Wer die Sprache nicht gelernt
hat, kann beim Lesen von Code allenfalls erahnen, was dieser tut. Das
ist zwar besser als gar nichts, hat aber keinerlei praktischen Nutzen.

Ich persönlich kann zwar ein antikes Pascal-Programm aus Wirths Zeiten
problemlos lesen, weil ich das irgendwann mal gelernt habe. Bei einem
Programm in modernem Object-Pascal, das über Lehrbuchniveau hinausgeht,
habe ich aber keine Chance, weil ich mich nie intensiv damit beschäftigt
habe.

Umgekehrt ist es nicht verwunderlich, dass jemand, der immer nur in
Pascal programmiert hat, Schwierigkeiten beim Lesen von C- oder gar
C++-Code hat.

────────────
¹) Damit meine ich nicht das Anschauen eines 5-Minuten-Hipster-Videos
   zu dem Thema.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Yalu X. schrieb:

> Nein, es gibt nur den einen. Dieser wird zwar alle paar Jahre mal
> aktualisiert (wie praktisch jede Norm, nicht nur im Computerbereich),
> mit jeder Neuauflage werden aber die vorangegangen ungültig.

OK. Schöne Sache. Und wieso wird dann soviel Code "unbrauchbar", wenn 
man ihn mit einem neueren "Standard" übersetzt?

Das sagt doch eigentlich alles über die Sprache und deren Standards aus.

von Jens B. (dasjens)


Lesenswert?

Falk B. schrieb:
> Max M. schrieb:
>> Was mir aber immer wieder auffällt, das in Russland Pascal offenbar
>> aktiver genutzt wird als woanders.
>
> Die fliegen auch noch mit Rakten aus den 1970er Jahren ins Weltall.
> Das passt dazu! Echt russisch halt!  ;-)

Strukturierter Text bei der SPS Programmierung ist dann auch Russisch 
^^.
Das basiert auch auf Pascal.

Und btw. Die Amis haben bis vor paar Jahren (oder tun sie es immer 
noch?) Sowjetische Raketenantriebe gekauft.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Ob S. schrieb:
> Yalu X. schrieb:
>
>> Nein, es gibt nur den einen. Dieser wird zwar alle paar Jahre mal
>> aktualisiert (wie praktisch jede Norm, nicht nur im Computerbereich),
>> mit jeder Neuauflage werden aber die vorangegangen ungültig.
>
> OK. Schöne Sache. Und wieso wird dann soviel Code "unbrauchbar", wenn
> man ihn mit einem neueren "Standard" übersetzt?

Welchen Code meinst du konkret?

Wenn es Probleme bei der Portierung von alten auf neue Plattformen gibt,
liegt das i.Allg. nicht an der Sprache C/C++, sondern an irgendwelchen
verwendeten Bibliotheken oder Frameworks, die ebenfalls aktualisiert
wurden und die inkompatibel zu den alten Versionen sind, weil sie eben
nicht standardisiert wurden.

von Joe (Firma: Wessibisser) (joe_l794)


Lesenswert?

Yalu X. schrieb:
> in2out1.pas:program CopyInputToOutput;
> var
>   c: char;
> begin
>   while not eof do
>     begin
>       read(c);
>       write(c)
>     end
> end.
>
> O je, so viel Code für so eine einfache Aufgabe. Zudem scheint er
> zweimal zu beginnen und zweimal zu enden, was schon sehr komisch
> aussieht.
>
> Nun dasselbe Programm für den erweiterten FPC:
>
> in2out2.pas:main = interact id

Das obere Beispiel gibt immerhin einen Hinweis auf das was es tut und 
das auch fuer Laien. Die angeblich bessere untere Zeile ist zwar 
kuerzer, aber kryptisch.
Wartbarkeit, wenn Bedeutung vergessen, gleich Null. Ich sehe hier eher 
einen gewaltigen Rueckschritt. Das Zeug ist nicht lesbar.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Yalu X. schrieb:

> Welchen Code meinst du konkret?

Also das würde die Grenzen des Forums definitiv sprengen. Und ich bin 
absolut sicher: Du weißt das auch ganz genau.

> Wenn es Probleme bei der Portierung von alten auf neue Plattformen gibt,
> liegt das i.Allg. nicht an der Sprache C/C++, sondern an irgendwelchen
> verwendeten Bibliotheken oder Frameworks, die ebenfalls aktualisiert
> wurden und die inkompatibel zu den alten Versionen sind, weil sie eben
> nicht standardisiert wurden.

Es liegt daran, das dieser "includierte" Code genau das ursprüngliche 
Problem hat: War zur Zeit seiner Verfassung absolut standargerecht, ist 
es aber nach dem neueren Standard eben nicht mehr.

Nicht der Code ist das Problem, sondern die Änderung des Standards. Ist 
ja auch logisch: Wenn es Code gibt, der jemals nach irgendeinem Standard 
valid war, darf es keine Änderung des Standards geben, die ihn invalid 
macht. Wenn eine solche Änderung des Standards unumgänglich ist, um ein 
neues Feature umzusetzen, ist das nach den Gesetzen der Logik ein 
absolut eindeutiger Nachweis, dass die ursprüngliche Definition der 
Sprache unzureichend und die vorherigen Standards huppse waren.

So einfach ist das. Klar, dass du das nicht wahrhaben willst. Aber isso.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Joe schrieb:
> Das obere Beispiel gibt immerhin einen Hinweis auf das was es tut und
> das auch fuer Laien.

Dann lege den Code doch einmal jemandem vor, der noch nie etwas mit
Programmierung zu tun hatte. Der wird (ohne weitere Erläuterungen) bei
beiden Beispielen nur Bahnhof verstehen. Im Pascal-Code wird er trotz
seiner Englischkenntnisse spätestens beim "char" steckenbleiben, weil er
sich nicht sicher ist, ob damit die Holzkohle, die Putzfrau oder der
Saibling gemeint ist.

Ganz abgesehen davon wird Programmcode nicht für Laien geschrieben,
sondern für Kollegen, die der jeweiligen Sprache bereits mächtig sind.

> aber kryptisch.

Für dich kryptisch.

> nicht lesbar.

Für dich nicht lesbar.

Zeige einem Chinesen einen deutschen Text, dann wird er dich vielleicht
darauf hinweisen, dass das Ganze auf chinesisch nicht nur leichter
lesbar, sondern darüberhinaus auch noch deutlich kürzer ist. Das ist
alles eine Frage der Perspektive, s. auch hier:

Yalu X. schrieb:
> Es ist eigentlich ganz einfach:
> ...

von Yalu X. (yalu) (Moderator)


Lesenswert?

Ob S. schrieb:
> Yalu X. schrieb:
>
>> Welchen Code meinst du konkret?
>
> Also das würde die Grenzen des Forums definitiv sprengen.

Du sollst ja nicht den kompletten Quellcode posten. Ein Hinweis, woher
du diese Information hast, oder ein Link auf ein Open-Source-Projekt, wo
dies zu einem großen Problem wurde, würde schon genügen.

> Und ich bin absolut sicher: Du weißt das auch ganz genau.

Ehrlich gesagt nicht, sonst hätte ich nicht gefragt.

> Es liegt daran, das dieser "includierte" Code genau das ursprüngliche
> Problem hat: War zur Zeit seiner Verfassung absolut standargerecht, ist
> es aber nach dem neueren Standard eben nicht mehr.

Es gibt wohl kaum eine Programmiersprache, bei deren Standardisierung
mehr Wert auf Abwärtskompatibilität gelegt wird als bei C und C++.
Kompatibilitätsprobleme sind deswegen höchstens eine Randerscheinung und
erfahrungsgemäß auch meist sehr schnell behoben.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Yalu X. schrieb:

> Es gibt wohl kaum eine Programmiersprache, bei deren Standardisierung
> mehr Wert auf Abwärtskompatibilität gelegt wird als bei C und C++.

Kunststück: Es gibt ja kaum Programmiersprachen, bei denen man mit 
mehreren Standards zu kämpfen hat.

Im Übrigen ist die Bemühung um Abwärtskompatibilität sicher vorhanden 
und war sogar jeweils auch extrem wichtiges Design-Ziel, aber...

Hat nicht wirklich geklappt!

> Kompatibilitätsprobleme sind deswegen höchstens eine Randerscheinung und
> erfahrungsgemäß auch meist sehr schnell behoben.

Nur für die, die die Zeit haben, sich mit dem jeweils heissesten Schice 
der Sprache auseinander zu setzen. Und obendrein mit der Historie der 
Sprache, als die gerade der heisseste Schice war, jedenfalls für den 
Programmierer des unwilligen Quelltextes. Der ist sicher nicht Schuld, 
denn er konnte nicht in die Zukunft sehen.

Die Arschkarte haben die Leute gezogen, die den damaligen Code eben 
heute benutzen müssen. C bietet "Portabilität"... Da lach' ich drüber. C 
kann nicht mal Portabilität für den eigenen Code bieten.

Und noch viel ärger wird es, wenn man auch noch den Compiler wechseln 
muß. Auch die haben (und hatten) immer mal wieder doch leicht 
verschiedene Interpretationen des jeweils gültigen Standards. Das sorgt 
auch immer wieder mal für etwas Spaß...

von Harald K. (kirnbichler)


Lesenswert?

Irgendwie klingt das ein bisschen wie der Fanatismus von "moby".

Warum nur?

von Yalu X. (yalu) (Moderator)


Lesenswert?

Ob S. schrieb:
> Yalu X. schrieb:
>
>> Es gibt wohl kaum eine Programmiersprache, bei deren Standardisierung
>> mehr Wert auf Abwärtskompatibilität gelegt wird als bei C und C++.
>
> Kunststück: Es gibt ja kaum Programmiersprachen, bei denen man mit
> mehreren Standards zu kämpfen hat.

Wenn du mit "mehrere Standards" überarbeitete und erweiterte Versionen
ein und desselben Standards meinst: Solche Überarbeitungen gibt es für
praktisch jede aktiv genutzte Sprache. Sie stellen somit keine
C-spezifische Ausnahme, sondern die allgemeine Regel dar.

> Im Übrigen ist die Bemühung um Abwärtskompatibilität sicher vorhanden
> und war sogar jeweils auch extrem wichtiges Design-Ziel, aber...
>
> Hat nicht wirklich geklappt!

IMHO hat das sogar erstaunlich gut geklappt.

> Die Arschkarte haben die Leute gezogen, die den damaligen Code eben
> heute benutzen müssen.

Du sprichst in der dritten Person, d.h. du kennst die vermeintlichen
Probleme nur vom Hörensagen. Das erklärt natürlich auch, dass du keine
konkreten Beispiele nennen kannst, die deine Behauptungen untermauern
könnten.

: Bearbeitet durch Moderator
von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Yalu X. schrieb:

> Du sprichst in der dritten Person, d.h. du kennst die vermeintlichen
> Probleme nur vom Hörensagen.

Also das ist wohl unter "drastischer Fehlschluß" einzuordnen. Nein, klar 
bin ich auch perönlich von diesem Mist betroffen. War es in der 
Vergangenheit mehrfach und kämpfe gerade aktuell (mal wieder) mit so 
einem Problem.

> Das erklärt natürlich auch, dass du keine
> konkreten Beispiele nennen kannst, die deine Behauptungen untermauern
> könnten.

Nein. die Erklärung dafür ist viel einfacher: Das ist alles kein 
OpenSource. Und darf/soll es auch nicht werden.

Dies zu entscheiden obliegt nicht mir, sondern meinen Brötchengebern. So 
einfach ist das. Wenn du sowas nicht kapierst, bist du schlicht blöd. 
Sorry, aber ist so.

von Falk B. (falk)


Lesenswert?

Jens B. schrieb:
> Und btw. Die Amis haben bis vor paar Jahren (oder tun sie es immer
> noch?) Sowjetische Raketenantriebe gekauft.

Sicher nicht, denn die Sowjetunion gibt es seit über 30 Jahren nicht 
mehr. Wohl aber Russland. Ja, die Amis haben ne Menge russische 
Triebwerke gekuft, weil die sehr gut und scheinbar auch preiswert sind. 
Jetzt will man diese Geschäftsbeziehung eher lösen und nur noch Made in 
USA kaufen, vornehmlich bei SpaceX. Naja.

von Harald K. (kirnbichler)


Lesenswert?

Ob S. schrieb:
> War es in der
> Vergangenheit mehrfach und kämpfe gerade aktuell (mal wieder) mit so
> einem Problem.

Du behauptest also ernsthaft, daß ein aktueller C-Compiler keinen alten 
C-Code übersetzen kann?

von Gerhard O. (gerhard_)


Lesenswert?

Moin,

Ich habe einige ältere Arduino Projekte mit alten ASM Bibliotheken drin, 
die in neueren Versionen von GCC nicht mehr funktionieren. Die 
Originalprojekte bauten vollkommen Fehlerfrei unter V5.4.0. Bei den 
späteren Versionen gab es nur noch jede Menge Fehler durch die ASM Bib. 
Auch neuere, angepasste Versionen der ASM Bib. machten Schwierigkeiten 
oder liefen, obwohl kompilierbar, nicht mehr einwandfrei.

Es ist durchaus möglich, daß Experten, vielleicht besondere C.L. 
switches kennen, mit denen man die Probleme eliminieren könnte, aber da 
kenne ich mich einfach nicht genug aus um da selber folgerichtig auf den 
Grund der zahlreichen Probleme zu kommen. Und dafür wäre mir auch die 
Zeit zu schade. Es erschließt sich mir nicht unbedingt, warum der 
Compiler nicht selbständig Hinweise geben könnte, welche Einstellungen 
für Kompatibilität dann notwendig wären. Mir werden diese andauernde 
nicht-kompatiblen Versionen nach Versions-Update einfach zu lästig.

Meine Lösung für diese paar ältere Projekte war, einfach eine portable 
Version der IDE mit den korrekten Versionen anzufertigen, die nicht 
durch Updates modifiziert werden können, und alles ist gut.

Die für ein Projekt im IDE festgelegte Version wird übrigens durch die 
verwendete Bord Package maßgeblich festgelegt. Man muß im Quellcode 
einen Hinweis reinschreiben, daß das Projekt nur bis zu einer bestimmten 
Bordversion kompatibel ist. Wenn man sich dann in den IDE Ordnern 
umschaut, sieht man bei mir z.B. drei verschiedene eingebaute GCC 
Versionen. Aber das andauernde Umstellen ist nicht wirklich zweckmässig. 
Am besten ist es mit portablen IDE Versionen zu arbeiten. Dann bleibt 
alles beim Alten und lässt sich auch besser archivieren.

Ich versuche zwar, neue Projekte immer mit der aktuellen Version zu 
bauen, aber es ist bei alten Projekten zweckmässiger mit der 
ursprünglich benutzten IDE/GCC Konserve zu arbeiten.

Man sollte im Quell Informations Block immer alle Bau- und 
Versionshinweise reinschreiben, so daß man sich nötigenfalls alles von 
dort wieder so herrichten kann. Auch alle HW Besonderheiten sollten dort 
mit drinstehen. Ich halte es so, daß mir der Quellcode immer alle 
nötigen besonderen Informationen zum Bau der SW komplett enthält.

Ich hatte dasselbe Problem auch bei der PIC CCS Compiler Familie, daß 
alte Projekte ohne Anpassungen nicht mehr fehlerfrei erzeugbar waren. 
Auch da ist es am Besten, immer den ursprünglich benutzen Compiler bei 
Nacharbeiten zu wählen. Deshalb immer die frühen Compiler archivieren, 
wenn man Altes pflegen will.


Gerhard

von Yalu X. (yalu) (Moderator)


Lesenswert?

Ob S. schrieb:
> Yalu X. schrieb:
> ...
>> Das erklärt natürlich auch, dass du keine konkreten Beispiele nennen
>> kannst, die deine Behauptungen untermauern könnten.
>
> Nein. die Erklärung dafür ist viel einfacher: Das ist alles kein
> OpenSource. Und darf/soll es auch nicht werden.

Anstatt Quellcode zu posten, könntest du ja einfach ein paar von euch
häufig genutzte C-Features benennen, die nach ISO 9899:1990 noch
standardkonform waren, es heute (ISO 9899:2018) aber nicht mehr sind.

Ja, es gibt ein paar kleinere Inkompatibilitäten zwischen C90 und dem
aktuellen Standard. Es würde mich aber sehr wundern, wenn diese in eurem
realen Code tatsächlich auftreten und euch das Leben so schwer machen,
dass du die ganze Welt an eurem Problem teilhaben lassen musst.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Gerhard O. schrieb:
> Ich habe einige ältere Arduino Projekte mit alten ASM Bibliotheken drin,
> die in neueren Versionen von GCC nicht mehr funktionieren.

C++-Code mit Assemblermodulen sind eine andere Geschichte.

Von Zeit zu Zeit wird das ABI des C++-Compilers geändert. Dies führt
zwar selten zu Inkompatibilitäten, aber wenn doch, muss der komplette
C-Code eines Programms (einschließlich verwendeter Bibliotheken) neu
kompiliert sowie die Assemblermodule entsprechend angepasst und neu
assembliert werden.

Beim GCC sollte das seit 3.4.0 eigentlich nicht mehr erforderlich sein,
aber vielleicht enthalten die von dir verwendeten Assembler-Bibliotheken
Fehler, die erst im Zusammenhang mit neueren Compiler-Versionen in
Erscheinung treten.

Wie auch immer: Für Probleme mit Assemblermodulen kann nicht der
C-Standard verantwortlich gemacht werden.

von Gerhard O. (gerhard_)


Lesenswert?

Yalu X. schrieb:
> Gerhard O. schrieb:
>> Ich habe einige ältere Arduino Projekte mit alten ASM Bibliotheken drin,
>> die in neueren Versionen von GCC nicht mehr funktionieren.
>
> C++-Code mit Assemblermodulen sind eine andere Geschichte.
>
> Von Zeit zu Zeit wird das ABI des C++-Compilers geändert. Dies führt
> zwar selten zu Inkompatibilitäten, aber wenn doch, muss der komplette
> C-Code eines Programms (einschließlich verwendeter Bibliotheken) neu
> kompiliert sowie die Assemblermodule entsprechend angepasst und neu
> assembliert werden.
>
> Beim GCC sollte das seit 3.4.0 eigentlich nicht mehr erforderlich sein,
> aber vielleicht enthalten die von dir verwendeten Assembler-Bibliotheken
> Fehler, die erst im Zusammenhang mit neueren Compiler-Versionen in
> Erscheinung treten.
>
> Wie auch immer: Für Probleme mit Assemblermodulen kann nicht der
> C-Standard verantwortlich gemacht werden.

Ich kann mich momentan nicht erinnern, welche Art die Fehlermeldungen 
waren und von wem. Ich schaue mir das vielleicht wieder einmal an mit 
der aktuellen Version und berichte, wenn's interessiert. Die Bib ist 
übrigens die I2C-Master-SoftMaster oder so ähnlich.

...

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Yalu X. schrieb:
> Ja, es gibt ein paar kleinere Inkompatibilitäten zwischen C90 und dem
> aktuellen Standard. Es würde mich aber sehr wundern, wenn diese in eurem
> realen Code tatsächlich auftreten und euch das Leben so schwer machen,
> dass du die ganze Welt an eurem Problem teilhaben lassen musst.

Vor allem kann man ja sogar auf Dateiebene sagen welchen "Dialekt" der 
Compiler verstehen soll...wenn man will...und das build system das 
kann...

Der Compiler ist sicher nicht (extreme sonderfälle ausgenommen) das 
Problem. Alle mir bekannten können eigentlich alle gängigen 
"Entwicklungsstufen".

Aus halbwegs aktueller Erfahrung: c89 Code compiliert immer noch, wenn 
man im  makefile auch c89 angibt :)

Siehe auch hier: 
https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/C-Dialect-Options.html

73

von Ein T. (ein_typ)


Lesenswert?

Harald K. schrieb:
> Irgendwie klingt das ein bisschen wie der Fanatismus von "moby".
>
> Warum nur?

Natürlich aus Gründen. Aus Gründen, die so unfaßbar geheim sind, daß 
unser Held nicht einmal ein Minimum Working Example zur Erklärung seiner 
steilen Thesen daraus bauen kann. Er hat kein Argument, aber 
Recht!!eins1elfeins!!

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Was Kompatibilität betrifft, denke ich an meine Nischen-
Programmiersprache, die ich schon 30 Jahre lang nutze. Der
Hauptgrund war der, daß man alte Quelltexte, die im Forum
oder auch auf der eigenen Platte oder USB-Stick vorhanden
sind, ausführen konnte. Wenn man dann den Algo brauchen konnte,
konnte man ihn immer noch auf die neue Syntax umstricken. Somit
ersparte man sich unnötige Mühe, wenn es dann doch nicht das
richtige war.
Der Autor (Ein-Mann-Projekt) hatte immer sehr großen
Wert auf Abwärtskompatibiltät gelegt. Da gingen alte
Befehl/Funktionen immer noch einige Versionen weiterhin.
Der Parser des Interpreters/Runtimemodul erkannte die alte
Funktion/Befehl und hatte es erst in die neue Syntax umgewandelt,
die auch dann der neue Compiler verarbeiten konnte. Außerdem
stehen bei jedem Befehl/Funktion die Compilerversionen, also ab
wann der Befehl/Funktion verfügbar ist. Und wenn er es mit dem
Parser mal wirklich nicht auflösen konnte, stand das auch in der
Hilfe, daß z.b. dieser alte Befehl/Funktion nicht mehr geht.
Von Zeit zu Zeit gab er alte Versionen als Freeware frei und
damit verschwanden dann auch langsam die Uralt-Befehle/Funktionen,
die er dann rausnahm.

Ein sehr guter Einfall von ihm war damals das Thema Operatoren. In
den Anfangsjahren verstand die Sprache keine (+ - / *). Alles wurde
über Funktionen realiseiert (Add(N1, N2), Add$(S1, S2) SUB(N1,N2),
DIV(N1,N2), MUL(N1,N2)  ). Mit Einführung der normalen Operatoren
(+, -, /, *) hat er dann einen Interpreter/Compilerschalter $O+
eingebaut. Der Parser hatte dann in die neue Syntax übersetzt.
Auch eine Includedatei hatte er dafür vorbereitet.

so etwa :
Proc Add
Parameters n1%, n2%
Return n1% + n2%
EndProc

Wenn man da so eine Monsterzeile mit ADD() Sub() usw. und dann noch
mehrfach ineinander verschachtelt, umstricken wollte, kostete das schon
einige Mühe.

Schade eigentlich, daß er nun wegen Alters (70+) aufhört. Für kleine
Tools / Programme nutze ich es bis heute immer noch gerne. Halt gerade
deshalb, weil man damit flott etwas kleines gestrickt bekommt und kein
Monster anwerfen muß.

Was ich damit nur sagen wollte, ist, daß er hinsichtlich der 
Kompatibiltät
sehr vorbildlich war.

: Bearbeitet durch User
von Roland F. (rhf)


Angehängte Dateien:

Lesenswert?

Hallo,
Yalu X. schrieb:
> Ja, es gibt ein paar kleinere Inkompatibilitäten zwischen C90 und dem
> aktuellen Standard.

..die aber keine wirklichen Probleme darstellen, denn...

Hans W. schrieb:
> Vor allem kann man ja sogar auf Dateiebene sagen welchen "Dialekt" der
> Compiler verstehen soll...wenn man will...und das build system das
> kann...

...siehe Anhang, hier die Wahlmöglichkeiten (aus Code::Blocks) nach 
welchem Standard nun ein C- b.z.w C++-Quellcode übersetzt werden soll.

rhf

Beitrag #7528880 wurde von einem Moderator gelöscht.
Beitrag #7528883 wurde von einem Moderator gelöscht.
von Alexander S. (alesi)


Lesenswert?

Harald K. schrieb:
> wird bald ein Zustand erreicht, in
> dem jeder Programmierer seine ihm eigene und für alle anderen
> weitestgehend unverständliche Programmiersprache einsetzt.

Den Zustand bzw. die Möglichkeit dafür gibt es schon seit dem es Forth 
gibt :-)

von Harald K. (kirnbichler)


Lesenswert?

Nun, in Sachen "write-only-language" wird Forth vermutlich nur von 
Brainfuck getoppt.

von Christian M. (christian_m280)


Lesenswert?

Heinz B. schrieb:
> meine Nischen-
> Programmiersprache

(X)Profan? Habe ich auch jahrelang benutzt. Bin jetzt auf PureBasic 
umgestiegen.

Gruss Chregu

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Christian M. schrieb:
> (X)Profan? Habe ich auch jahrelang benutzt. Bin jetzt auf PureBasic
> umgestiegen.

Ja, genau. PureBasic hatte ich auch mal eine zeitlang benutzt.
Ist mir aber wegen den verschachtelten Eventabfragen für ein
Fenster zu fummelig. Auch die Debugausgaben, um kurz was auszugeben
sind nicht so meins. Für mein Kleinzeugs reicht mir deshalb auch 
XProfan.

von Falk B. (falk)


Lesenswert?

Harald K. schrieb:
> Nun, in Sachen "write-only-language" wird Forth vermutlich nur von
> Brainfuck getoppt.

Naja, avr gcc inline Assembler kommt da auch ganz gut ran ;-)

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Falk B. schrieb:
> Harald K. schrieb:
>> Nun, in Sachen "write-only-language" wird Forth vermutlich nur von
>> Brainfuck getoppt.
>
> Naja, avr gcc inline Assembler kommt da auch ganz gut ran ;-)

Nur dass es sich bei Inline Assembler nicht um eine Programmiersprache 
handelt, sondern nur um ein Interface um zwei verschiedene Sprachen 
miteinander zu verbinden.

von Vancouver (vancouver)


Lesenswert?

Wenn ich's mir so recht überlege, hat mich PASCAL doch recht lange 
begleitet: In den 80ern auf meinem Alphatronic-PC unter CP/M (nachdem 
mir Basic allmählich auf den S*** ging), später am Gymnasium im 
Informatikkurs auf Apple-IIe, und noch etwas später an der Uni bei den 
ersten Progammieraufgaben (wir konnten Pascal oder C verwenden), und 
irgendwann im ~3 Semester dann in Form der Totgeburt Oberon. In den 
späteren Semestern war dann PASCAL kein Thema mehr.

Im Rückblick muss ich sagen, eigentlich keine schlechte Sprache, wenn 
auch etwas geschwätzig. Aber angesichts von C++, Python und RUST sehe 
ich heute keinen Anlass mehr, mich mit PASCAL zu beschäftigen, nicht mal 
aus Sentimentalität.

von Oliver S. (oliverso)


Lesenswert?

Vancouver schrieb:
> Im Rückblick muss ich sagen, eigentlich keine schlechte Sprache, wenn
> auch etwas geschwätzig.

Und das auch nur, solange man damit akademische Probleme im Schule oder 
Studium lösen muß.

Vancouver schrieb:
> 3 Semester dann in Form der Totgeburt Oberon

Da war doch eigentlich das genauso tote Modula angesagt.

Oliver

von Vancouver (vancouver)


Lesenswert?

Oliver S. schrieb:
> Und das auch nur, solange man damit akademische Probleme im Schule oder
> Studium lösen muß.

Wenn man sich anschaut, was damals sonst so in Mode war, COBOL, FORTRAN, 
BASIC, dann war Pascal da schon Lichtjahre voraus. Aber die Dinosaurier 
waren damals noch lebendig, deswegen kam Pascal nicht so recht in die 
Puschen.

Modula wurde zumindest da und dort verwendet, meistens in akademischen 
Projekten. Oberon ist schon auf der Startrampe explodiert. Dummerweise 
habe ich daneben gestanden, einer meiner Profs war damals unendlich 
begeistert davon, hat aber später selbst zugegeben, dass das ein Irrtum 
war.

Das Einzige was mir an Oberon gut gefallen hat, war, dass es nur ein 
einziges Schleifenkonstrukt gab, nämlich loop/exit/end. Damit konnte man 
alle erdenklichen Schleifen bauen, und der Overhead gegenüber for, 
while, do usw. war minimal.

von Oliver S. (oliverso)


Lesenswert?

Vancouver schrieb:
> Das Einzige was mir an Oberon gut gefallen hat, war, dass es nur ein
> einziges Schleifenkonstrukt gab, nämlich loop/exit/end.

Das ist in C oder anderen Sprachen nicht anders, nur mit etwas mehr 
syntaktischem Zucker verschönert.

Oliver

von Andreas B. (bitverdreher)


Lesenswert?

Vancouver schrieb:
> Aber angesichts von C++, Python und RUST sehe
> ich heute keinen Anlass mehr, mich mit PASCAL zu beschäftigen, nicht mal
> aus Sentimentalität.

Das habe ich auch mal gedacht, bis ich auf Lazarus gestossen bin. ;-)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.