Damit hast du schon mal eine gute Wahl getroffen.Krishty hat geschrieben:ich bin etwa bei dem Punkt, wo der Compiler global Symbole zusammensuchen kann
Ich habe lange versucht, eine einheitliche Deklarationssyntax sowohl für Daten als auch für Funktionen hinzukriegen, aber bisher mit wenig Erfolg.BeRsErKeR hat geschrieben:Verblüffenderweise sieht deine Syntax für Funktionen fast exakt wie mein Entwurf aus.
Meinst du mit von Haus aus müssen pur sein oder sind pur so lange nicht anders angegeben? Keine Ahnung, ob Erstes so eine gute Idee ist – für eine Skriptsprache mit Sicherheit; für eine vollwertige Programmiersprache wäre es mir schon wieder zu utopisch. Pascal hat eine Unterscheidung zwischen Funktionen (Parameter zu Rückgabewert; letzterer muss vom Aufrufer behandelt werden) und Prozeduren (Wirkung; Rückgabewert optional); das wäre für mich ein brauchbarer Kompromiss.BeRsErKeR hat geschrieben:Was mir auch wichtig ist, ist Nebenwirkungen so gut es geht zu minimieren. Bei mir sollen alle Funktionen von Haus aus "pur" sein, man kann also weder I/O durchführen, noch globale Variablen ändern.
Array-Syntax ist ein interessantes Thema … ich hasse C(++)-Arrays. Im Augenblick löse ich in meinen C++-Projekten alles über range-Strukturen, die auf Anfang und Ende von Feldern zeigen, und das fließt wie Butter – abgesehen von dem winzigen Detail, dass der Compiler es nicht ausreichend optimiert, weil es keine Wurzel in der Sprache selber hat; und dass mir bei String-Literalen immer die automatisch angehängte Null zum Verhängnis wird (for teh luv of gawd, WHY!). Ich muss mir auch unbedingt nochmal Gos Slices ansehen, falls ich irgendwann mal Zeit habe. Und dann wären da noch Strings, die ja auch ein Thema für sich sind (Rein in die Sprache oder nicht? Nur Literale? Nullterminiert oder nicht? …).BeRsErKeR hat geschrieben:hab mich da teilweise an D orientiert, genau wie bei der Syntax von Arrays
Gegen globale Variablen spricht für mich nur der eine Grund, dass sie nicht mit dem Konzept von Threads und Fibers vereinbar sind. Ich würde definitiv statische (vorberechnete) globale Variablen für sowas wie Nachschlagtabellen erlauben; wohl auch einige bei Programmstart initialisierte Instanzen (mit automatisch korrekter Initialisierungsreihenfolge, da ich die Abhängigkeiten sowieso zur Typauflösen ausklamüsern muss), weil man sich ohne einfach zu weit von der Praxis entfernen würde. (Beispiel Spiele-Sandbox: Wo nähmst du freien Speicher manueller Lebenszeit her, falls du weder I/O aufrufen, noch einen globalen Zeiger anlegen könntest? Du müsstest alles auf esoterische, wahrscheinlich halb rekursive Gebilde umschrauben … das würde es für den Compiler-Entwickler vereinfachen, aber sicher nicht für den Programmierer.) Aber bei mit dem Prozess initialisierten Variablen würden dann wieder Leute alles aushebeln, indem sie ihr ganzes Programm in einen K’tor packen (MFC).BeRsErKeR hat geschrieben:globale Variablen / statische Member soll es höchstwahrscheinlich gar nicht erst geben (allerdings globale Funktionen und eventuell statische Methoden, wobei mit global dann modul-lokal bzw. namespace-lokal gemeint ist).
Nein; das benötige ich für Template-Metaprogrammierung. Genau genommen benötigt C++ es (in Form von typename vor den Namen abhängiger Typen in Templates), um beim Parsen zwischen den FällenBeRsErKeR hat geschrieben:Bei deinem Beispiel fällt mir das Schlüsselwort instance auf. Ich vermute du unterscheidest dadurch zwischen Stack und Heap?
Ja ich bin auch noch am Frickeln.Krishty hat geschrieben:Ich habe lange versucht, eine einheitliche Deklarationssyntax sowohl für Daten als auch für Funktionen hinzukriegen, aber bisher mit wenig Erfolg.BeRsErKeR hat geschrieben:Verblüffenderweise sieht deine Syntax für Funktionen fast exakt wie mein Entwurf aus.
Zur Zeit unterscheide ich zwischen Funktion und Prozedur. Da Prozeduren ohne Nebenwirkungen sinnfrei sind, müssen diese eigentlich nicht weiter mit Schlüsselwörtern beschmückt werden. Ich nutze aber zusätzlich noch ein Schlüsselwort um Funktionen als non-pure bzw. in dem konkreten Fall als Funktionen, die I/O durchführen zu kennzeichnen. Problematisch ist halt, wie du sagst, dass man dann eigentlich nicht wirklich I/O nutzen kann, weil pure Funktionen keine I/O-Funktionen aufrufen können. Und das ganze ab der main-Funktion trennen ist wohl auch nicht sehr sinnvoll oder in jedem Fall machbar. Und prinzipiell benötigt man auch nicht-pure Funktionen, falls man z.B. was aus ner Datei lesen will. Naja mit dem Thema werde ich mich noch beschäftigen.Krishty hat geschrieben:Meinst du mit von Haus aus müssen pur sein oder sind pur so lange nicht anders angegeben? Keine Ahnung, ob Erstes so eine gute Idee ist – für eine Skriptsprache mit Sicherheit; für eine vollwertige Programmiersprache wäre es mir schon wieder zu utopisch. Pascal hat eine Unterscheidung zwischen Funktionen (Parameter zu Rückgabewert; letzterer muss vom Aufrufer behandelt werden) und Prozeduren (Wirkung; Rückgabewert optional); das wäre für mich ein brauchbarer Kompromiss.BeRsErKeR hat geschrieben:Was mir auch wichtig ist, ist Nebenwirkungen so gut es geht zu minimieren. Bei mir sollen alle Funktionen von Haus aus "pur" sein, man kann also weder I/O durchführen, noch globale Variablen ändern.
Klingt interessant. Kannst du mir da mal ein Beispiel zeigen? Zwecks range-Strukturen.Krishty hat geschrieben:Array-Syntax ist ein interessantes Thema … ich hasse C(++)-Arrays. Im Augenblick löse ich in meinen C++-Projekten alles über range-Strukturen, die auf Anfang und Ende von Feldern zeigen, und das fließt wie Butter – abgesehen von dem winzigen Detail, dass der Compiler es nicht ausreichend optimiert, weil es keine Wurzel in der Sprache selber hat; und dass mir bei String-Literalen immer die automatisch angehängte Null zum Verhängnis wird (for teh luv of gawd, WHY!). Ich muss mir auch unbedingt nochmal Gos Slices ansehen, falls ich irgendwann mal Zeit habe. Und dann wären da noch Strings, die ja auch ein Thema für sich sind (Rein in die Sprache oder nicht? Nur Literale? Nullterminiert oder nicht? …).BeRsErKeR hat geschrieben:hab mich da teilweise an D orientiert, genau wie bei der Syntax von Arrays
Ich möchte es bei mir recht strikt und eindeutig halten. Ich überlege z.B. die Ausdrücke für Typen und Variablen soweit einzuschränken, dass sie in jedem Fall unterscheidbar sind und auch die Syntax für Pointer wird eher in Richtung von pointer<a> i; gehen, als a * i; - halt um solche Sachen zu vermeiden. Aber auch da muss ich mir noch was Anständiges überlegen.Krishty hat geschrieben:Nein; das benötige ich für Template-Metaprogrammierung. Genau genommen benötigt C++ es (in Form von typename vor den Namen abhängiger Typen in Templates), um beim Parsen zwischen den FällenBeRsErKeR hat geschrieben:Bei deinem Beispiel fällt mir das Schlüsselwort instance auf. Ich vermute du unterscheidest dadurch zwischen Stack und Heap?
a * i; // Multiplikation; a: int; i: int
a * i; // Zeigerdeklaration; a: typedef für int; i: Name des Zeigers
unterscheiden zu können. Ich brauche es immer, weil ich ja keine Deklarationen habe und der Compiler sonst beim Parsen dieser Stelle nicht wissen könnte, um welchen der Fälle es sich handelt. Mit einer ausreichend klaren Deklarationssyntax wäre das am Ende sicher obsolet; aber um es mir selber zu vereinfachen, habe ich es erstmal dringelassen. Was die Unterscheidung zwischen Stack / Heap angeht (sehr unglückliche Begriffe; nennen wir sie automatische und manuelle Speicherverwaltung), würde ich nur eine Placement-Syntax bauen (d.h., Byte-Array aus beliebiger Quelle zu Objekt initialisieren) und die vor ein paar Tagen erwähnte Array-Initialisierung irgendwie reinboxen.
Code: Alles auswählen
struct Bounds { float3 Min, Max; };
RWStructuredBuffer<Bounds> BoundsUAV;
struct BoundsConstantLayout
{
float4 MinM;
float2 ax;
};
cbuffer BoundsConstants
{
BoundsConstantLayout BoundsConstants;
}
// ...
float3 min = BoundsConstants.MinM.xyz;
float3 max = float3(BoundsConstants.MinM.w, BoundsConstants.ax);Code: Alles auswählen
struct Bounds { float3 Min; float _1; float3 Max; float _2; };
RWStructuredBuffer<Bounds> BoundsUAV;
cbuffer BoundsConstants
{
Bounds BoundsConstants;
}
// ...
float3 min = BoundsConstants.Min;
float3 max = BoundsConstants.Max;Das kann ich nur bestätigen :lol:TDK hat geschrieben:Was zum Jammern ist:
Wenn ich mir hier die Postings im Thema durchlese, frage ich mich mittlerweile, ob ich hier in einem Programmiersprachen-Guru-Forum gelandet bin, oder in einem Forum für Spieleprogrammierer :|
Du meinst hier Umstellung von Member-Methode auf freie Funktion? Ist das schneller oder geht das "nur" auf die Diskussion von neulich zurück, die Vorteile von freien Funktionen aufzeigte?CodingCat hat geschrieben:Nein nein, das hat schon seine Richtigkeit, dank Java sind wir hier leider im Laufe des letzten Jahres kollektiv verblödet. (Ich habe gerade mehrere 100 Zeilen fremden Mathecode von abstrusem x.Cross(y) auf cross(x, y) gebracht, auch deshalb ist ADL ein Segen; hat aber nichts mit der Uni zu tun ...).
Das ist mal sowas von gar nichts im Vergleich zu dem hier (ein paar Mal aktualisieren).Jonathan hat geschrieben:Gut, die erste konnte ich noch googeln, aber für die zweite muss man irgendwie schon ne Menge vorwissen haben, oder es wird kniffelig.
Nein, die optimale Auflösung.eXile hat geschrieben:Außerdem willst du die Rotation des Bildes via Fouriertransformation berechnen? Das glaube ich nicht; eher Kantenerkennung, dann Hough-Transformation, und dann einen RANSAC-Algorithmus. :)
Macht nichts. Habe eh nur noch eine halbe Stunde bevor ich den Rest auf unbestimmte Zeit verschieben muss.eXile hat geschrieben:Ich hatte vor knapp einen Monat mal schnell eine obskure russische Scan-Software ausprobiert, die ziemlich gut automatisiert hat. Hätte ich deinen Post damals antizipiert, würde ich jetzt nicht seit einer halben Stunde danach suchen; ich melde mich wieder, wenn ich sie wiedergefunden habe.
