Swift



  • An sich eine nette Sprache, wirkt vom Syntax tatsächlich wie VB oder Rust. Apple hat innerhalb eines Jahres auch viele Updates gebracht. Obwohl Objective-C nicht sonderlich beliebt war, war es lange oben auf den Hitlisten der Programmiersprachen.
    Swift wird wohl mindestens diese Stellung einnehmen, aber weil es soeinen simplen Charm hat wohl nocht weiter nach Oben gehen.

    http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

    Ist auf jeden Fall lohnenswert sie zu erlernen, andere "hipppe" Sprachen wie D, Go, Clojure, Dart, Haskell, J#, OCaml, Rust, Smalltalk, Tcl,... bleiben oft schon 5 oder mehr Jahre im Rauschbereich. Sicher nicht verkehrt sie zu kennen, aber wenn ich mich entscheiden muss, dann investiere ich das wenige an Freizeit doch in eine Sprache mit der am Ende etwas anzufangen ist, das ist das gute an Swift.
    Obwohl ich das auch mal von C# dachte und Microsoft den support ziemlich reduziert hat (Kein Silverlight, kein XNA, nicht die einzige Sprache auf Windows Mobile,...)



  • Ich für meinen Teil bleibe bei Objective-C, da ändert sich die Syntax nicht alle paar Wochen.

    Marthog schrieb:

    So wird ein garbage collector (reference counting) verwendet

    Sorry, aber das ist Blödsinn, reference counting hat nichts mit einem Garbage Collector zu tun.

    Marthog schrieb:

    Ne ganz nette Sprache fuers schreiben von kleinen Apps, denn man kommt ohne viel Aufwand zum Ziel und das Produkt lauft immer noch recht schnell, aber das ist nichts fuer ein Grossprojekt mit >10 Jahren laufzeit.

    Warum? Wenn das Projekt unter OS X laufen soll, bleibt dir nur Objektive-C oder Swift. Zumindest wenn du die Funktionalität von Cocoa nutzen möchtest.



  • Matheo schrieb:

    andere "hipppe" Sprachen wie D, Go, Clojure, Dart, Haskell, J#, OCaml, Rust, Smalltalk, Tcl,... bleiben oft schon 5 oder mehr Jahre im Rauschbereich.

    Tcl und smalltalk sind wieder hip? Habe ich da was verpaßt?



  • ich denke er meint allgemein sprachen die als hip galten und sich manche die zeit nahmen diese zu erlernen und bis heute hat dieses wissen bzw. kennen keinen nutzen.



  • Die Sprachen leiden immer an der Praxistauglichkeit.
    Z.B. kann OCaml bis heute kein Unicode und kein Concurrency. Ehm, die haben schon mitbekommen das die Welt global ist und jeder Taschencomputer Multicore ist?

    Bei Smalltalk ging der Schuss schon zur Einführung nach hinten los: zu schwache Rechner. Aber heute wäre Smalltalk ideal. Weil CPU und RAM gefühlt ohne Ende vorhanden ist.
    Deshalb versuchen es die Leute von Pharo nochmal: http://pharo.org/
    Das hat Potenzial!



  • pierredrks schrieb:

    Marthog schrieb:

    So wird ein garbage collector (reference counting) verwendet

    Sorry, aber das ist Blödsinn, reference counting hat nichts mit einem Garbage Collector zu tun.

    Referenzzählung ist auch ein Garbage-Collection-Mechanismus. Allerdings ein relativ rückständiger wegen der erforderlichen Locks und der andauernden Gefahr von Referenzzyklen.

    Marthog schrieb:

    Wenn das Projekt unter OS X laufen soll, bleibt dir nur Objektive-C oder Swift. Zumindest wenn du die Funktionalität von Cocoa nutzen möchtest.

    Zum Glück stimmt das nicht. Xamarin/C# bietet auch vollen Zugang zu Cocoa, Delphi/C++Builder zumindest teilweise.



  • pierredrks schrieb:

    Wenn das Projekt unter OS X laufen soll, bleibt dir nur Objektive-C oder Swift. Zumindest wenn du die Funktionalität von Cocoa nutzen möchtest.

    Gerade deswegen ist Swift ja auch so beliebt. Es gibt nahezu keine Alternative, wenn man fuer iOS entwickeln will und da gibt es zur Zeit viel Geld zu holen.
    Haette man eine groessere Auswahl an einfach zu verwendenden Sprachen, wuerden die vielen Entwickler sich auf Python, C++, Go, Javascript, vielleicht auch Java, etc. aufteilen.

    Ich will jetzt wirklich keinen Streit ausloesen, aber ich werde das Gefuehl nicht los, das Apple bewusst eine neue Sprache entwickelt hat, um die Programme nicht portabel zu halten und dadurch die Leute an sich zu binden, insbesondere da Swift von den Sprachfeatures her anderen Sprachen so aehnlich ist, dass eine entsprechende go library wahrscheinlich fast genauso aussehen wuerde.



  • audacia schrieb:

    Referenzzählung ist auch ein Garbage-Collection-Mechanismus. Allerdings ein relativ rückständiger wegen der erforderlichen Locks und der andauernden Gefahr von Referenzzyklen.

    Es ist eine Art automatischer Speicherverwaltung aber wie gesagt keine Garbage Collection. Wenn man sich ein wenig Gedanken beim Programmieren macht, sind Referenzzyklen auch kein großes Problem aber klar die Gefahr besteht.

    Marthog schrieb:

    Wenn das Projekt unter OS X laufen soll, bleibt dir nur Objektive-C oder Swift. Zumindest wenn du die Funktionalität von Cocoa nutzen möchtest.

    Zum Glück stimmt das nicht. Xamarin/C# bietet auch vollen Zugang zu Cocoa, Delphi/C++Builder zumindest teilweise.[/quote]
    Xamarin bietet Cocoa Bindings?

    Marthog schrieb:

    Ich will jetzt wirklich keinen Streit ausloesen, aber ich werde das Gefuehl nicht los, das Apple bewusst eine neue Sprache entwickelt hat, um die Programme nicht portabel zu halten und dadurch die Leute an sich zu binden, insbesondere da Swift von den Sprachfeatures her anderen Sprachen so aehnlich ist, dass eine entsprechende go library wahrscheinlich fast genauso aussehen wuerde.

    Da würde ich dir Recht geben, warum sollte Apple auch Interesse daran haben, dass Swift Programme einfach auf anderen Plattformen laufen? Wobei hier die Sprache das kleinere Problem ist, ich könnte mir auch vorstellen, dass Apple den ganzen Swift Kram irgendwann Open Source macht, aber dann fehlt dir immer noch Cocoa um damit vernünftig zu arbeiten.



  • pierredrks schrieb:

    Xamarin bietet Cocoa Bindings?

    http://developer.xamarin.com/guides/mac/getting_started/hello,_mac/



  • pierredrks schrieb:

    audacia schrieb:

    Referenzzählung ist auch ein Garbage-Collection-Mechanismus. Allerdings ein relativ rückständiger wegen der erforderlichen Locks und der andauernden Gefahr von Referenzzyklen.

    Es ist eine Art automatischer Speicherverwaltung aber wie gesagt keine Garbage Collection.

    doch

    pierredrks schrieb:

    Da würde ich dir Recht geben, warum sollte Apple auch Interesse daran haben, dass Swift Programme einfach auf anderen Plattformen laufen? Wobei hier die Sprache das kleinere Problem ist, ich könnte mir auch vorstellen, dass Apple den ganzen Swift Kram irgendwann Open Source macht, aber dann fehlt dir immer noch Cocoa um damit vernünftig zu arbeiten.

    Nicht auf kompatibilitaet zu setzen ist ein riskantes Spiel. Mit Glueck kann es einem ein quasi-monopol geben, weil die software eben nicht portierbar ist. Mit Pech wird aber auch andere Software nicht auf die eigene Plattform portiert.
    Microsoft hat es aehnlich versucht. Active X ist tot und statt zu C# zu wechseln, sind viele Entwickler beim plattformunabhaengigen und bekannten Java geblieben.



  • Marthog schrieb:

    Nicht auf kompatibilitaet zu setzen ist ein riskantes Spiel. Mit Glueck kann es einem ein quasi-monopol geben, weil die software eben nicht portierbar ist. Mit Pech wird aber auch andere Software nicht auf die eigene Plattform portiert.
    Microsoft hat es aehnlich versucht. Active X ist tot und statt zu C# zu wechseln, sind viele Entwickler beim plattformunabhaengigen und bekannten Java geblieben.

    Du weißt schon dass es hier um Apple geht?



  • Marthog schrieb:

    pierredrks schrieb:

    audacia schrieb:

    Referenzzählung ist auch ein Garbage-Collection-Mechanismus. Allerdings ein relativ rückständiger wegen der erforderlichen Locks und der andauernden Gefahr von Referenzzyklen.

    Es ist eine Art automatischer Speicherverwaltung aber wie gesagt keine Garbage Collection.

    doch

    ARC != GC RC

    http://docs.elementscompiler.com/Concepts/ARCvsGC/



  • Marthog schrieb:

    Microsoft hat es aehnlich versucht. Active X ist tot und statt zu C# zu wechseln, sind viele Entwickler beim plattformunabhaengigen und bekannten Java geblieben.

    Du bist anscheinend mit der Windows NT Plattform nicht sehr vertraut? Sonst wüsstest du, das COM und ActiveX nicht tot sind! Es ist lediglich nicht mehr in IE erlaubt oder gern gesehen. Aber COM und ActiveX sind eine unerlässliche technische Eigenschaft des Windows NT Ökosystems! COM wurde sogar mit WinRT erweitert und ist weiter eine feste Grundlage.



  • Artchi schrieb:

    Marthog schrieb:

    Microsoft hat es aehnlich versucht. Active X ist tot und statt zu C# zu wechseln, sind viele Entwickler beim plattformunabhaengigen und bekannten Java geblieben.

    Du bist anscheinend mit der Windows NT Plattform nicht sehr vertraut? Sonst wüsstest du, das COM und ActiveX nicht tot sind! Es ist lediglich nicht mehr in IE erlaubt oder gern gesehen. Aber COM und ActiveX sind eine unerlässliche technische Eigenschaft des Windows NT Ökosystems! COM wurde sogar mit WinRT erweitert und ist weiter eine feste Grundlage.

    Silverlight und ANX sind tot. Ich frage mich eh wie das weitergeht, MS rudert zZ ziemlich richtung C++. Google mit Android Studio auch, weil sie lächerlicherweise wegen Java schlechte Karten vor Gericht haben.

    Ich muss immer lachend an https://xkcd.com/927/ denken wenn ich von einer neuen Sprache lese die alles besser macht. Das ist wie Software 2.0
    Bei Swift macht das noch ein wenig Sinn, da Apple als ziemlich einziger user von Objective-C langsam nach Swift migrieren kann.
    Aber ansonsten muss ich dem einen hier zustimmen der sagte, dass er keine Zeit hat jeder neuen Sprache nachzurennen. Ich hab VB gelernt, weil es viel besser als C ist auf Windows, Ich hab Pascal gelernt, weil der Syntax soviel besser ist als C und deswegen fehler wie if( foo=true ) garnicht passieren, ich hab Haskell gelernt weil Programmierer soviel Zeit mit Sourcecode-Schreiben verschwenden und ein Quicksort nur eine Zeile in Haskell ist....... ich programmiere immer noch C bzw C++.
    Swift werde ich im Urlaub ausprobieren. Geht das auch unter Linux oder Windows? Ich habe OSX seit Jahren nicht mehr gestartet.



  • Mondstaub schrieb:

    Ich muss immer lachend an https://xkcd.com/927/ denken wenn ich von einer neuen Sprache lese die alles besser macht. Das ist wie Software 2.0

    Schon, aber mal ohne Altlasten anzufangen ist auch ganz schön. Stell dir vor, wie viel angenehmer C++ sein könnte, hätte es nicht die Headerdateien, Makros, die Arraysemantik, das löchrige Typsystem mit all den impliziten Umwandlungen und die bescheuerte Syntax von C geerbt. Und ObjC soll ja noch schlimmer als C++ sein (combines the performance of Smalltalk with the beauty of C).

    Nur weil Microsoft seit einigen Jahren wieder Ressourcen in C++ steckt, heißt das außerdem nicht, daß C# deshalb zurückstehen müßte. Im Gegenteil , es passiert genug Neues auf der C#-Seite, wie dem aufmerksamen Zeitungsleser nicht entgeht.



  • Auf der WWDC wurde übrigens gerade angekündigt, dass Swift OpenSource geht und einen Compiler für Linux bekommt.



  • audacia schrieb:

    Stell dir vor, wie viel angenehmer C++ sein könnte, hätte es nicht die Headerdateien

    Ich finde das eigentlich eine sehr saubere Sache, da es Deklaration von Implementation trennt. Wenn ich mit Java arbeite ist es nervig im Source verstreute Funktionsdeklarationen zu suchen, ohne IDE ist das für mich nicht nutzbar.

    Makros

    Makros muss niemand nutzen, aber beim Portieren sind die manchmal unglaublich mächtig. Als ich einmal geholfen habe ein C# Projekt zu portieren, hat das "Refaktoring Tool" Code generierung gemacht, je nach Platform. Da fiel mir auf wie verkrampft manche um einen Preprocessor kommen wollen um dann doch dieselbe Arbeitsweise mit Umstäden zu verfolgen.

    die Arraysemantik,

    Kannst du ein Beispiel nennen was du meinst, bisher hab ich nichts schlechtes daran erkannt.

    das löchrige Typsystem mit all den impliziten Umwandlungen

    Eigentlich mag ich das, ich finde es z.B. in Java nervig immer nach boolean wandeln zu müssen. Wobei du eigentlich bei jedem Compiler die Warning Level so einstellen kannst, dass nicht implizit gecasted wird, was andere Sprachen nicht erlauben und wenn du Warning == Error einstellst, bist du auf der sicheren Seite.
    Ich hatte einmal an einem medizinischem Program gearbeitet, da wuerde vor jedem Code Submit noch PVS Studio als Validierung genutzt, was dort an Dingen aufkamen hab ich noch von keinem Compiler gesehen. Da es so sehr sensibel war was wir machten, durften wir auch nicht mit #pragma und desgleichen die Reports ausschalten, sondern mussten 100% validen Code schreiben.

    und die bescheuerte Syntax von C geerbt.

    Das klingt eher nach einem individuellem Problem. Es gibt auch Leute die Python oder Pascal bevorzugen und mir kommt deren Syntax bescheuert vor. Daran sollte eine Sprache ja nicht gemessen werden. Sprachen wie Java und C# sind extra an C/C++ angelehnt um Entwickler abzuwerben die die Syntax lieben.

    Zudem schreib ich hier eigentlich, weil ich im Heise newsticker sah dass Sift 2.0 raus ist und open source wird. Echt gute Entscheidung von Apple. Hat hier jemand schon mit Swift ein Projekt erfolgreich beendet und kann sagen wie es lief?



  • Eigentlich dachte ich, die genannten Schwächen seien hinlänglich bekannt und akzeptiert. Viele davon werden ja auch vom Standardisierungsprozeß angegangen (Makros sind verpönt, Module sollen Headerdateien ersetzen, std::array<,> die Arrays, für die kaputten Stellen der Syntax gibt es mittlerweile alternative Syntaxen etc.). Außerdem ist das hier ein Thread über Swift. Aber bitte...

    AuchMondMann schrieb:

    audacia schrieb:

    Stell dir vor, wie viel angenehmer C++ sein könnte, hätte es nicht die Headerdateien

    Ich finde das eigentlich eine sehr saubere Sache

    Eine Trennung von Deklaration und Definition kann man auch sehr schön ohne Headerdateien haben (siehe interface / implementation in Pascal). Headerdateien sind nicht deshalb Mist, weil man Deklaration und Definition trennen kann (aber nicht muß), sondern weil sie stupide Präprozessorexpansion sind => eskalierende Build-Zeiten, brüchige Modulkopplungen (manchmal geht was kaputt, wenn man #include -Statements umstellt), unoffensichtliche Abhängigkeiten (wenn du von einem Header abhängst, den du nicht einbindest, der aber von einem anderen Header referenziert wird). Das geht alles viel besser, wie man eigentlich an jeder anderen ernstzunehmenden Sprache sehen kann.

    AuchMondMann schrieb:

    Als ich einmal geholfen habe ein C# Projekt zu portieren, hat das "Refaktoring Tool" Code generierung gemacht, je nach Platform. Da fiel mir auf wie verkrampft manche um einen Preprocessor kommen wollen um dann doch dieselbe Arbeitsweise mit Umstäden zu verfolgen.

    Ich bin zuversichtlich, daß ein Präprozessor dieses Projekt auch nicht besser gemacht hätte.

    AuchMondMann schrieb:

    Makros muss niemand nutzen

    Aber sie sind da, also nutzen sie Leute wie du, anstatt einen Codegenerator zu schreiben, wenn sie einen brauchen, und ich muß dann die resultierenden Probleme bekämpfen.

    AuchMondMann schrieb:

    die Arraysemantik,

    Kannst du ein Beispiel nennen was du meinst, bisher hab ich nichts schlechtes daran erkannt.

    Du kannst einen Funktionsparameter deklarieren, der aussieht wie ein Array, aber fürs Typsystem ist es ein Zeiger; sogar dann, wenn du explizit die Arraygröße angibst. Arrays werden implizit in Zeiger umgewandelt (insbesondere multidimensionale Arrays werden implizit in einen Zeiger auf ein multidimensionales Array von einer Dimension weniger umgewandelt). Funktionen können keine Arrays zurückgeben, weil Arrayparameter wie in Fortran by reference sind (was an sich sinnvoll ist), aber das einzige brauchbare Speichermanagement, was die Sprache für solche Arrays zur Verfügung stellt (nämlich die Allokation auf dem Stack; es gibt zwar new , aber es ist unglaublich leicht, damit exceptionunsicheren Code zu schreiben oder delete und delete[] durcheinanderzubringen, was wiederum aufgrund der impliziten Umwandlung in einen Zeiger vom Typsystem nicht bemerkt wird), ist wiederum beschränkt auf sehr kleine Arrays (sonst Stackoverflow). Kurz, Arrays stiften i.d.R. mehr Verwirrung als Nutzen.

    AuchMondMann schrieb:

    das löchrige Typsystem mit all den impliziten Umwandlungen

    Eigentlich mag ich das, ich finde es z.B. in Java nervig immer nach boolean wandeln zu müssen.

    Ich habe es mir mittlerweile auch in C++ angewöhnt. Und ich hoffe, dein statisches Analysetool haut dir das um die Ohren.

    AuchMondMann schrieb:

    Wobei du eigentlich bei jedem Compiler die Warning Level so einstellen kannst, dass nicht implizit gecasted wird, was andere Sprachen nicht erlauben und wenn du Warning == Error einstellst, bist du auf der sicheren Seite.

    Klar, ein guter Compiler oder ein Werkzeug für statische Analyse kann vor vielen Problemen warnen, die in neueren Sprachen gleich by design vermieden wurden.

    AuchMondMann schrieb:

    und die bescheuerte Syntax von C geerbt.

    Das klingt eher nach einem individuellem Problem

    Ist es aber nicht. Die Syntaxprobleme von C++ sind objektiv nachweisbar. Beispiele:

    • der most vexing parse. Funktionsdeklarationen und Variablendeklarationen mit Konstruktoraufruf sind meist syntaktisch nicht unterscheidbar. Ich habe mich jahrelang geärgert, daß der C++Builder kein Parameter-Tooltip anzeigen konnte, wenn ich
    std::string foo(
    

    schrieb, sehr wohl aber, wenn ich nur

    std::string(
    

    schrieb. Kürzlich fiel mir auf, daß VC++ dasselbe Problem hat; sobald man aber einen Buchstaben nach der Klammer getippt hat, gibt es ein Tooltip, und da wurde mir auch klar, woran das liegt. Der Grund ist, daß der Compiler bei der Klammer noch nicht weiß, ob ich eine Funktion deklarieren will oder eine Variable; dafür muß er das Token danach auswerten und schauen, ob es sich um einen gültigen Typnamen handelt. Sowas weiß aber der Parser noch nicht; deshalb spekuliert der Compiler mal, daß es eine Funktionsdeklaration ist (was es im Zweifel auch bleibt, also z.B. wenn du std::string foo(); schreibst), und wenn er ein Token findet, was kein Typname ist, muß er den ganzen Vorgang zurückrollen und nochmal mit der Annahme anfangen, daß jetzt eine Variable kommt.
    (Diese Technik mit dem spekulativen Parsen gehört für Compiler u.a. wegen des most vexing parse zur Grundausrüstung, so daß sich furchtbare Hacks wie SFINAE bilden konnten und heute akzeptierte Patterns sind. Ein ähnlich furchtbarer Hack ist TMP, allerdings kann man das nicht zu den Altlasten zählen.)

    • Typaugmentationen wie * , & , [] beeinflussen den Typen, gehören aber verwirrenderweise syntaktisch zur Variable:
      `int* a, b; // WTF

    int c[];`

    • die Funktionszeigersyntax ist einfach kaputt. Was bitte ist das hier?
    int (*foo(float))(double(*)(char));
    
    • grundsätzlich sind alle Variablendeklarationen syntaktisch mehrdeutig, deshalb braucht man typename , damit der Compiler Template-Code parsen kann, obwohl er die Typen noch nicht kennt.

    Ich denke, man kann erkennen, daß das nichts mit Syntaxvorlieben zu tun hat. Wohlgemerkt treten diese Probleme in Sprachen wie Java und C#, die eine C-inspirierte Syntax verwenden, by design nicht auf. Und wie bereits erwähnt gibt es auch in modernem C++ Alternativen, die diese Probleme vermeiden (uniform initialization, aliases und alias templates, Smartpointer und std::array<,> ); aber allein dadurch gehen die Altlasten ja noch nicht weg.



  • audacia schrieb:

    sie stupide Präprozessorexpansion sind => eskalierende Build-Zeiten, brüchige Modulkopplungen (manchmal geht was kaputt, wenn man #include -Statements umstellt), unoffensichtliche Abhängigkeiten (wenn du von einem Header abhängst, den du nicht einbindest, der aber von einem anderen Header referenziert wird). Das geht alles viel besser, wie man eigentlich an jeder anderen ernstzunehmenden Sprache sehen kann.

    Du hast schlechte makefiles.

    [quote="audacia"]es gibt zwar new , aber es ist unglaublich leicht, damit exceptionunsicheren Code zu schreiben oder delete und delete[] durcheinanderzubringen,/quote]
    Kindergarten.

    audacia schrieb:

    Ich habe mich jahrelang geärgert, daß der C++Builder kein Parameter-Tooltip anzeigen konnte, wenn ich

    *lach*, Du hast jahrelang den C++Builder benutzt. Das allein reicht schon zu wissen.

    audacia schrieb:

    []Typaugmentationen wie * , & , [] beeinflussen den Typen, gehören aber verwirrenderweise syntaktisch zur Variable:
    `int
    a, b; // WTF

    int c[];`

    Schreib eine pro Zeile, sag ich seit 15 Jahren.

    audacia schrieb:

    [*]die Funktionszeigersyntax ist einfach kaputt. Was bitte ist das hier?

    int (*foo(float))(double(*)(char));
    

    Von innen nach außen und rechts vor links und alles kein Problem.

    foo ist (rechts abbiegen) eine Funktion, 
     die nimmt float (klammer zwingt nach links) 
     und gibt zurück zeiger auf (klammer fertig, weiter rechts) 
      funktion, die nimmt 
       zeiger auf funktion 
        die nimmt char 
        und gibt zurück double (links, weil rechts nix mehr ist)
       und gibt zurück int.
    

    Aber ein typedef täte gut.

    audacia schrieb:

    Ich denke, man kann erkennen, daß das nichts mit Syntaxvorlieben zu tun hat. Wohlgemerkt treten diese Probleme in Sprachen wie Java und C#, die eine C-inspirierte Syntax verwenden, by design nicht auf. Und wie bereits erwähnt gibt es auch in modernem C++ Alternativen, die diese Probleme vermeiden (uniform initialization, aliases und alias templates, Smartpointer und std::array<,> ); aber allein dadurch gehen die Altlasten ja noch nicht weg.

    Ja, wir werden alle sterben.
    Bin mir nicht so sicher, daß uniform initialization eine Hilfe ist.



  • audacia schrieb:

    AuchMondMann schrieb:

    Makros muss niemand nutzen

    Aber sie sind da, also nutzen sie Leute wie du, anstatt einen Codegenerator zu schreiben, wenn sie einen brauchen, und ich muß dann die resultierenden Probleme bekämpfen.

    einen Codegenerator schreiben, um ein einfaches build-abhängiges Debug-Makro per #ifdef DEBUG #define ... #endif zu vermeiden?? 😮

    audacia schrieb:

    Ich denke, man kann erkennen, daß das nichts mit Syntaxvorlieben zu tun hat. Wohlgemerkt treten diese Probleme in Sprachen wie Java und C#, die eine C-inspirierte Syntax verwenden, by design nicht auf.

    die sind aber nicht zero-overhead und nicht in dem Maß abwärtskompatibel zu C wie C++. Das sind aber wesentliche Features von C++.


Anmelden zum Antworten