[Programmiererstammtisch] "Zum ächzenden Compiler"

[Ramkhamhaeng]

Man kann es nicht direkt ablesen und damit ist es für euch genauso schwer wie für mich (ohne Debugger. Ihr kennt das... man denkt man spart sich die Zeit zum Aufbau eines Setups in dem man einen interaktiven Debugger verwenden kann. Klappt nie ).

Lösung

Achtung Spoiler:

path und tmp_path verwiesen auf das gleiche Objekt. Damit steht es direkt vor einem: path.clear().

Hintergrund: Die Kollision entstand beim Löschen einer lokalen Variable gleichen Names...
Mit der lokalen Variable tmp_path galt noch path != tmp_path. Die lokale Variable habe ich dann entfernt weil ich dachte es reicht auch eine temporäre Variable für Zwischenresultate. (Ja, eine weitere unkluge Entscheidung )

Sich an keine Namenskonvention (z.B. Großbuchstaben in statischer Variable), zu halten war hier also auch unklug.
Visual Studio hatte vorher aber auch keine Warnung ausgespuckt die auf die Kollision hinwies

[Flunky]

€: F5... Tj, call by reference ist halt fehleranfällig.

[Mr. X]

Achtung Spoiler:

path und tmp_path verwiesen auf das gleiche Objekt. Damit steht es direkt vor einem: path.clear().

.

(Das ist aus deinem Code-Ausschnitt nicht zu erkennen )

[Zulan]

€: F5... Tj, call by reference ist halt fehleranfällig.

mit const std::string& waer das nicht passiert ...

[Peregrin_Tooc]

OK, das passiert in meiner Welt nicht

[Ramkhamhaeng]

mit const std::string& waer das nicht passiert ...

Ich will die Struktur des Codes nicht verteidigen, aber das Funktions-Argument solle als Ausgabeparameter genutzt werden und war daher eine Referenz.
Aber hatte auch sein gutes. Sind mir mal wieder viele typische Fehler aufgefallen, die mir beim Programmieren unterlaufen…

[Tiramisu]

Ich will in Sql einen String in einen table eintragen, der sich aus einem String und einer ganzen Zahl zusammensetzt. || kann man ja nicht so einfach verwenden, um String und Integer zu einem einzigen String zusammenzusetzen, also habe ich bisher folgendes probiert:

DECLARE @cnt INT = 1;
DECLARE @cnt_total INT = 20;

WHILE @cnt < cnt_total
BEGIN
    INSERT INTO RequirementSets (RequirementSetId, RequirementSetType) VALUE
    (CONCAT ( 'RESEARCH_NERF_REQUIRES_ATLEAST_', @cnt, '_CITIES_REQUIREMENTS' ), 'REQUIREMENTSET_TEST_ALL');   
    SET @cnt = @cnt + 1;
END;

Weiß jemand, wo der Fehler ist?

[Shakka]

In der Zeile mit WHILE sollte ein @ ans cnt_total dran

[Tiramisu]

Ja, da hast du auf jeden Fall recht.
Allerdings habe ich festgestellt, dass mein Code schon daran scheitert, dass ich überhaupt Variablen deklariert habe. Ich habe gerade gesehen, dass Civ6 SQLite verwendet, weswegen diese Art von Deklaration nicht unterstützt wird.

[Shakka]

Dann mach den While-Kram doch im Programm, nicht in sql.

[Tiramisu]

Was meinst du mit "im Programm"? In Lua kann ich das nicht umsetzen, was ich programmieren will.

[Shakka]

Du hast ein Programm in Lua.
An irgend einer Stelle sorgt Lua dafür, dass im SQL das da oben ausgeführt wird.

Also vereinfachst Du das da oben auf ein einzlenes Insert und packst in Lua eine For-Schleife drum.

[Tiramisu]

Ich verstehe nicht ganz. Diese SQL-Tabellen sind doch nur read-only. Wenn ich die in Lua versuche zu ändern, gibt es eine Fehlermeldung. Denn zuerst werden die SQL-Daten und erst danach die Lua-Skripte geladen, wenn ich mich nicht irre.

[Snup]

Hat hier zufällig jemand ein bisschen tiefergehend Ahnung von WPF, um mir zu erklären, warum sich XAML-Code mit verschachtelten ListViews nicht so verhält, wie ich mir das vorstelle?

[Tiramisu]

Gibt es in der Informatik ein Fachgebiet, das sich damit beschäftigt, welche Strukturen man zur Datenspeicherung nutzen sollte?
Ich habe festgestellt, dass das bei komplizierteren Sachen gar nicht mal so trivial ist. Denn wenn ich meine Daten einfach nur in simplen Listen speichere, kostet es manchmal ziemlich viel Performance, wenn mein Programm aufwendige loops nutzen muss, um wieder auf diese Daten zurückzugreifen.