Jup, und das verhindert auch sehr gut die angesprochenen Runtime-Fehler. Aber eigentlich ist es egal ob du die Typinformationen zur Laufzeit mitschleppst oder
zur Compilezeit schon aufloest. Wichtig ist halt nur das es diese Informationen braucht... und wie man damit umgeht. Nimm dagegen aber einfach mal den Ansatz
von Haskell und co. Dort kannst du wegen den ganzen Kategorie-gedoens auch "unendliche" Sachen machen die dir in C++ nach 2 Sekunden einen Stackoverflow verpassen

_________________
Meine Homepage

Ich glaube, hier verwechselst du was. Unendliche Datenstrukturen gehen in Haskell wegen Bedarfsauswertung (lazy evaluation). Mit anderen Worten, die Datenstruktur wird erst erzeugt, während sie ausgewertet wird (und auch nur so weit, wie sie ausgewertet wird).
Hat mit dem Typsystem aber nichts zu tun.

Also ich beschäftige mich mit c++ noch nicht lange, aber soweit ich weiß heißt auto, dass der nötige Speicher automatisch allokiert und freigegeben wird (und ist der default für lokale variablen), und hat nicht direkt was mit Typen zu tun (außer dass der Typ weiß, wie viel Speicher benötigt wird).

Stimmt soweit ich weiß für Haskell, aber Scala (auch eine funktionale Sprache), schleppt meines Wissens immer den Typen zur Laufzeit mit.

Das wurde mit C++11 geändert. OpenglerF meinte sowas:
variable bekommt so den Typ int, weil dies der Rückgabetyp von function() ist. Das ist ganz praktisch, wenn man mit langen Typnamen zu tun hat (wie z.B. std::chrono::high_resolution_clock::time_point).

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)

Ja, genau.
Im Prinzip braucht man so theoretisch fast keine Typen mehr angeben.
In C++14 kann man sogar den Rückgabetypen von definierten Funktionen "auto"matisch bestimmen lassen.

Nicht ganz, Lazy-Evaluation kannst du auch sehr leicht in anderen Sprachen bauen. Der wesentliche Unterschied ist aber das
eine einfache Liste (1,2,3,4) genau das gleiche ist wie eine Liste (1,2,..) naehmlich eine Liste. Richtig deutlich wird
das aber erst wenn du so etwas wie (xs n = n : xs (n +1)) hast und das immer noch im Prinzip das gleiche wie die Listen
ist. In C++ musst du fuer solche Konstrukte immer wieder komplizierte Wrapper-Klassen, hier Iterator, bauen und neue Objekte
bauen die deine bestehenden Objekte Wrappen.. Dazu kommen noch solche Internen Geschichten wie z.B. Thunks und co. (also das was
du ansprichst) die verhindern das alles explodiert. Alles in allen verhindert man so ca. 30000000 “new” pro Zeile



Ja, Erik Meijer (einer der Schoepfer von Haskell), hat es einmal auf den Punkt gebracht. In kurz:
Python, Scala und co. sind zwar nicht richtig, dafuer aber nicht so Realitaetsfremd wie Haskell



Ja da sind die C++ler ein wenig eigen. Die Missbrauchen sogar “static” als Abkkuerzung fuer “extern”

_________________
Meine Homepage

auto wurde hauptsächlich wegen der langen Namen bei Traits und Templates eingeführt.
Ich benutzte auto schon etwas länger und bind sehr glücklich damit.
auto hat auch nix mit dem Speichermanagment zu tun, sondern mit der Type Thematik.
Der Compiler muss bei auto den typ erkennen, der bei der Initialisierung der Variable zugewiesen wird und behält diesen bei.
Dabei werden literals und Funktionen/Methoden angeschaut und der Rückgabewert übernommen.

Es ist ganz schön hart sich hier rückwärts durch zu lesen ^^
Zum Thema Generics war ich verwirrt, weil Generics in C# die vereinfachte Variante von Templates sind aber ich glaube hier wird von Variants gesprochen, sonnst ergibt es einfach kein Sinn für mich.
C hat, wie gesagt eine schwache Typensicherheit und erlaubt das konvertieren von typen die nicht wirklich was gemein haben einfach zu, trotz verlust und Fehler.
C++ vor 11 war auch das gleiche aber mit 11 hat man da angefangen auch starke Typensicherheit zu ermöglichen.
Ein Beispiel ist enum class Variable:uint32{...};.
class sagt, dass Variable ein typ ist und nur die werte im Enum annehmen kann und ab dort kann man die Werte nicht mehr als Indices oder Zahlen als Werte verwenden, man muss nun alles per static_cast explizit machen. Das man nun auch die Größe mit :uint32 festlegen kann, ist ledeglich für die klarheit. Wie groß das enum abgespeichert wird. Default wird ein int verwendet, welches je nach Platform zwischen 8Bit und aufwärts sein darf, weil C es so definiert hat. Will ich aber für kompakte Strukturen ein uint8, dann prüft der Kompiler die Anzahl der Werte und ist es nicht abbildbar, dann wirft er ein Fehler.

Bei Klassen war es auch tricky, weil der Compiler über 1 indirekten Call arbeiten darf, wenn es möglich ist.
Der Copy-Constructor und Assign Operator sind dort richtig große Probleme gewesen aber nun darf man den delete modifier verwenden und kann somit dem Compiler sehr übersichtlich sogar 2-3 Pattern und klare verhaltensregeln bei bringen.


Es gibt auch bestimmt noch weiteren syntax sugar der mir gerade nicht einfällt und man sollte noch dran denken, dass zwar C/C++ nicht stark typensicher sind aber z.B. GCC und VC++ es trotzdem erlauben. Compiler Flags /WX /Wall okey muss nicht gerade Wall sein, bei VC++ gibt W1 schon nicht explizite typecasts als Fehler zurück und pedantic hilft bei gcc.
Das hat aber auch seine Nachteile, explizite casts sind sehr schreibaufwändig.


Bzgl der Operator Thematik hat sich mit C++11 und aufwärts auch was getan, User-Literals.
Man darf eigene Literal definieren und kann diese dann für z.B. Zeit, Lineare Algebra und ähnliches verwenden.
Vor einigen Monaten hab ich gelernt, dass man SIMD nicht sinnvoll in Klassen packen kann.
Viele haben bestimmt schon die eine oder andere Sache mit SIMD abgebildet aber das Problem ist, dass SIMD eine CPU extension ist und entsprechend Bytecode benötigt und viele dann die einzelnen Operationen wie Multiplikation, Division und so weiter per intrinsic's oder asm abbilden.
Das Problem ist, dass dies overhead produziert und SIMD wirklich effizient wird, wenn man große komplexe Funktionen darauf optimiert.
SIMD Klassen stehen diesen aber entgegen und der Performance gewinn ist maginal.
Sollte man z.B. eine Kamera Klasse auf SIMD implementieren ist es wesentlich effizienter.
Dies führt dazu, dass ich nicht mehr weiter Energie in meine SIMD Klassen stecke und eher auf Code generierung setzt.
Intel hat ein OpenSource Projekt, welcher C Code parsen kann und dann Code generiert, den man in sein C/C++ Projekt kompilieren und linken kann.
Der Sinn ist wie bei OpenCL die Routinen, die man optimieren will in eigenen Code Units zu schreiben und dann passenden OpCode zu generieren.
https://ispc.github.io/index.html
Um auf die Syntax Thematik zurück zu kommen, ich hab wie bei MS XNA beide Varianten implementiert.
Methoden ala Add, Mod ,... und Operatoren für die logischen ala +, - und so weiter.
Natürlich hab ich wesentlich mehr Methoden als Operatoren und von daher nutzte ich wie für C++ler üblich(so wenig wie möglich tippen) die Operatoren und weiche auf Methoden aus, wenn es dafür keine Operatoren gibt.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Die beiden Casts sehen für mich sehr überflüssig aus. Der reinterpret_cast ändert den Typ nicht und der const_cast müsste überflüssig sein, da man const hinzufügen darf, ohne dass es einen cast braucht (nur entfernen ist nicht erlaubt). Wenn ich mich jetzt nicht sehr irre.

viele Grüße,
Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

In beiden hast du recht, es sollte ein Beispiel sein und ich hab da ein typo.
Es ging nicht um die Korrektheit des Codes den ich mir ausgedacht hab sondern um zu zeigen, wo das Problem liegt aber offensichtlich war das wohl nicht so interessant.

Die erste Zeile wäre an sich schon falsch, weil L"asdf" const wchar[5] ist und nicht zu wchar* bla werden kann.
Zum 2. Problem

const_cast erlaubt in beide Richtungen zu casten aber ist nur notwendig, wenn man ein const weg bekommen will, weil das entfernen des schreibschutzes zu Problemen führen kann und man möchte, dass dies einem bewusst ist und explizit angefordert wird.
Allerdings sollte man aufpassen, denn man kann sich sehr schnell durch implizite casts alles kaputt machen.
Ich hab in meiner alten Firma schon einige Bugs auf dem Tisch gehabt, weil Klassen Operatoren überladen haben und somit Tür und Tor für implizite und ungewollte Casts aufgemacht haben.
So wurde aus einem bool ein integer und dinge namen ihren Lauf oder Container haben in ganz seltenden Konstellationen leaks produziert.
Ganz zu schweigen von den unsichtbaren Kosten, die durch das temporäre erzeugen von Objekten entstehen können.

Hier ein korrektes wild life Beispiel.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

So einfach ist das leider auch nicht. In C ist es tatsaechlich die Storageclass fuer "normale" lokale Variablen (ich denke daher kommt die Verwirrung). Und es kann auch durchaus
Sinn ergeben:



btw. das Beispiel mit den Strings ist mal wirklich "wild life"

_________________
Meine Homepage

Mhh, also das es in C ein auto gibt und es eine andere Funktionsweise hat wusste ich garnicht.
Bei C++ bin ich von aus gegangen, dass es mit C++11 rein kam aber es gab davor tatsächlich auch ein auto und das war das von C.
http://en.cppreference.com/w/cpp/keyword/auto
Also dein Beispiel würde in einem C++11 compiler einen syntax Fehler werfen, ziemlich grusselige Lösung.
Ich hätte lieber ein neues Keyword eingeführt.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

"auto" hat keiner für seinen ursprünglichen Zweck verwendet. Schließlich hat der Hinweis bei modernen Compilern keinen Effekt und "auto" konnte sowieso schon immer einfach weggelassen werden.

Ich finde sehr gut wenn man ganz langsam anfängt auch die antiken Altlasten wieder abzubauen. Ich wünschte, das würde viel stärker verfolgt.

jup, das kommt wohl noch aus der Zeit als die Compiler anders (bzw. garnicht?) mit den Stack gearbeitet haben. Es kam aber durchaus noch vor das Programmierer es verwendet
haben um, ich sags mal deutlich, Kommentare zu sparen. Von daher sollte man immer im Hinterkopf behalten das die Aenderung noch relativ neu ist und sich nicht ueber Fehler
wundern.

Ich denke aber man haette da durchaus etwas besseres finden koennen. Es gibt schliesslich auch Extensions die auto benutzen um zu sagen "Bleib im Scope". Da haette man doch
bestimmt so etwas wie den Vorschlag fuer GC oder bessere Tail Recursion ala OCaml mit abdecken koennen. Ausserdem finde ich es eine Frechheit zu behaupten man staerkt die
Kompatibilitaet zu C und macht dann gleichtzeitig so etwas, voellig egal wie man ueber auto denkt.

Mal was anderes:

ich arbeite gerade an einen kleinen Tool das C Code (nicht ganz) nimmt und durch einen beliebigen C-Compiler jagt. Soll letztenendes so etwas wie Pure-C werden. Schauts
euch mal dort zum Beispiel die Expressions an:

_________________
Meine Homepage

Wer behauptet denn, dass die Kompatiblität zu C gestärkt wurde? Das Ziel von C++11 war es die Sprache einfacher verwendbar zu machen.
Überhaupt: Wer noch Dinge wie "auto" verwendet, ist mit C++11 eh völlig falsch beraten weil der Code auch sonst inhaltlich höchstwahrscheinlich noch lang nicht bereit für C++11 ist.

Und Extensions können generell doch einfach die Sprache um ein neues Schlüsselwort erweitern. (Extension ≙ Erweiterung)

Ich benutze das neue auto keyword recht häufig, da ich bei Containern einfach zuviel tippen müsste und die Zeilen einfach zu lang werden, als das man sie noch lesen kann.
Sonnst nutz ich es eigentlich nicht, da ich lieber den Datentyp sehen möchte.

Wenn man sich allerdings lambda expressions anguckt, welche ziemlicher Syntax fuckup ist, dann bin ich recht froh mit auto als Wort. Vielleicht wären die sonnst dort auch auf lustige Sonderzeichen für modifier gekommen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

@OpenglerF
Man sollte nicht Unterschätzen wie sehr sich beide Sprachen da gegenseitig beeinflussen. Denk zum Beispiel einfach mal an solche trivialen Sachen wie den Header
einer Bibliothek. Du brauchst die selben Basis-Typen, den gleichen Praeprozessor (das beinhaltet bei C99 z.B. auch ehemalige Extensions wie func-Macro), die gleichen Deklarationen...

Und was der erst mal beim ganzen Low-Level Zeugs abgeht möchte ich gar nicht erst wissen. Da fliesst schon eine ganze Menge an Hirnschmalz mit rein, wenn man mal genau drüber nachdenkt.

Btw. ich hab da jetzt zum neuen Auto eine lustige Geschichte gelesen. Angeblich wurde das schon einmal in 80ern versucht. Da scheiterte es wohl am implicit int von C. Wir haben also tatsaechlich knapp 2 Jahrzehnte (C99) dafuer gebraucht um dieses eine Hindernis zu entfernen


Ich persoehnlich bin aber der Meinung man haette "auto" als Ersatz fuer "unique_ptr" verwenden sollen und zum Beispiel "var" fuer den Typenkram nehmen sollen. Ich hatte bei
meinen Objective-C Kram zum Beispiel das Problem das ich nicht "unique_ptr" benutzen konnte weil beim mingw dadurch der Klassen-Pointer um 4 Bytes verschoben war. Wobei
man da natuerlich wieder Argumentieren koennte das es am inkompatiblen Klassen/Struct-Layout liegt und das dann lieber fixxen sollte... Das ist aber nur meine Wunschliste

_________________
Meine Homepage