Das meinte ich übrigens (@Spiele Programmierer) mit dem gelöschten Einwand "dann wäre es ein Heap". Aber ich war dann selbst verunsichert ob das jemals passieren kann.Krishty hat geschrieben:@antisteo: Ja; klar. Spätestens, wenn die Scopes unterschiedlich große Brocken allokieren und dazwischen andere Variablen sitzen, beginnen einfache Algorithmen zu fragmentieren.
Weird.Nein. Visual C++ erlaubt’s trotzdem und tut weitestgehend, was du erwarten würdest.
Unter der Haube ist das eh kein richtiger Stack, denn der Compiler vergrößert den Stapel nur einmal beim Betreten der Funktion (und nicht jedes Mal, wenn eine Variable angelegt wird). Die Variablen werden auch gern mal umsortiert usw. Es sieht nur nach außen aus wie ein Stapel, weil sich das Frontend an die Lebenszeiten aus dem Quelltext hält.Alexander Kornrumpf hat geschrieben:Das meinte ich übrigens (@Spiele Programmierer) mit dem gelöschten Einwand "dann wäre es ein Heap". Aber ich war dann selbst verunsichert ob das jemals passieren kann.
Naja; nützlich (für Fehlerverarbeitung à la goto fail.) So lange da kein Konstruktor oder Destruktor läuft, sondern nur native Datentypen angelegt werden (die eh uninitialisiert sind, so lange man's nicht explizit hinschreibt), sehe ich auch nicht ein, dass das verboten sein sollte.Weird.Nein. Visual C++ erlaubt’s trotzdem und tut weitestgehend, was du erwarten würdest.
Code: Alles auswählen
{
int foo = 0;
goto bar;
int baz =0; //wird wahrscheinlich wegoptimiert
bar:
++foo; //foo muss hier noch allokiert sein. foobar darf es nach deiner Logik nicht sein.
}
{
int foobar = 0;
//mach irgendwas damit foobar nicht wegoptimiert wird
goto bar;
//mach irgendwas damit nicht offensichtlich ist, dass der scope hier endet, z. B.
foobaz:
int baz =0;
//mach was mit baz. Es könnte einen Sprung an foobaz geben. Ist foobar allokiert oder nicht?
}
Das ist genau das was Krishty nicht will?! Hab ich was total falsch verstanden?Spiele Programmierer hat geschrieben:Der Speicherplatz für lokale Variablen wird für gewöhnlich am Anfang der Funktion allokiert und nicht auf Blocklevel.
Ja. Um meine ursprüngliche Vermutung, dass das Problem äquivalent zu Allokation und Deallokation im Freispeicher (vulgo: Heap) ist, zu prüfen, versuche ich jetzt herauszufinden wieviel man mit goto kaputt machen kann.Spiele Programmierer hat geschrieben: Wenn zwei lokale Variablen nicht gleichzeitig auftreten, können sie sich sie einen Bereich teilen.
Deckt sich mit meiner Einschätzung.Spiele Programmierer hat geschrieben:Ja mit "goto" kann man das teilweise untergraben.
Ohne "goto" bzw. andere teilweise problematische Konstrukte sollte es aber funktionieren. ;-)
Ich habe goto noch nie verwendet und weiß nicht wie es sich verhält. Deswegen frage ich ja.Krishty hat geschrieben:goto bedeutet nicht, dass der Compiler da direkt einen Sprungbefehl einbaut. Er *muss* sogar die alten Variablen zerstören, um das Programm funktionsfähig zu halten. Darum sehe ich nicht, was da untergraben werden sollte.
Code: Alles auswählen
//pre-scope
{
//in-scope
}
//post-scope
Trade-off in der Entwicklungszeit? Es gab ja letztens diesen tollen Artikel eines Entwicklers, dass Visual C++ darauf ausgelegt war, in 128 KiB RAM zu laufen, und deshalb möglichst wenig Zustand mitschleppt (u.a. Code erzeugt, bevor die Funktion zu ende geparst ist). Vielleicht deshalb bloß ein int mit „bisher benötigte Stack-Größe“ und jede Variable addiert einfach auf. Was anderes kann ich mir nicht vorstellen.Alexander Kornrumpf hat geschrieben:Erschwerend kommt hinzu, dass selbst wenn es konzeptionell so funktionieren würde, wie Wirth es sich vorstellt, ist es, wie ihr beide angemerkt habt, tatsächlich nicht so _implementiert_. Ist es also vielleicht ein anderweitig nützliches Detail der Implementierung, was die o. g. Invarianz zerstört? Sprich: ein Trade-Off?
Was war nochmal der Grund für den For-Scope Bug in Visual C++ 6? War das die Geschichte?Krishty hat geschrieben:Trade-off in der Entwicklungszeit? Es gab ja letztens diesen tollen Artikel eines Entwicklers, dass Visual C++ darauf ausgelegt war, in 128 KiB RAM zu laufen, und deshalb möglichst wenig Zustand mitschleppt (u.a. Code erzeugt, bevor die Funktion zu ende geparst ist). Vielleicht deshalb bloß ein int mit „bisher benötigte Stack-Größe“ und jede Variable addiert einfach auf. Was anderes kann ich mir nicht vorstellen.Alexander Kornrumpf hat geschrieben:Erschwerend kommt hinzu, dass selbst wenn es konzeptionell so funktionieren würde, wie Wirth es sich vorstellt, ist es, wie ihr beide angemerkt habt, tatsächlich nicht so _implementiert_. Ist es also vielleicht ein anderweitig nützliches Detail der Implementierung, was die o. g. Invarianz zerstört? Sprich: ein Trade-Off?
Vielleicht war das mit dem for auch ein „Feature“ um Quelltext möglichst unportierbar zu anderen Compilern zu machen (mit Internet Explorers HTML haben sie es ja zu ähnlicher Zeit auch so gemacht). Falls du Quellen mit Erklärungen findest, poste sie bitte; mich interessiert sowas sehr :)Alexander Kornrumpf hat geschrieben:Was war nochmal der Grund für den For-Scope Bug in Visual C++ 6? War das die Geschichte?
Du hast recht. Woran ich dachte, geht nicht.Darum sehe ich nicht, was da untergraben werden sollte.
Code: Alles auswählen
if(CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT APPLE)Code: Alles auswählen
else (WIN32)
if ( USING_GNU_C AND NOT APPLE)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -DM_PI=3.14159265358979323846" )
Code: Alles auswählen
# This enforces a particular version of CMake that we require to process the script files
# properly.
cmake_minimum_required(VERSION 2.8.8 FATAL_ERROR)
# As of CMake 2.6 policies were introduced in order to provide a mechanism for
# adding backwards compatibility one feature at a time. We will just specify
# that all policies will use version 2.6 symantics.
cmake_policy(VERSION 2.6)Du musst bedenken: Die verwenden schon CMake, damit isses eigentlich eh schon egal... :PJonathan hat geschrieben:Egal was für einen obskuren Grund es dafür auch geben mag, sollte man doch trotzdem irgendwie einsehen, dass das keine Gute Lösung sein kann...
Vielleicht haben sie das so gemacht weil ihnen sonst einfach zu viel Code kaputtgeht. Hier ist Quelltext aus dem Microsoft-Beispiel, wie man einen Shell Handler für Thumbnail-Erzeugung registriert:Alexander Kornrumpf hat geschrieben:Ist es also vielleicht ein anderweitig nützliches Detail der Implementierung, was die o. g. Invarianz zerstört? Sprich: ein Trade-Off?
Code: Alles auswählen
if (*pszFileType == L'.')
{
wchar_t szDefaultVal[260];
hr = GetHKCRRegistryKeyAndValue(pszFileType, NULL, szDefaultVal,
sizeof(szDefaultVal));
// If the key exists and its default value is not empty, use the
// ProgID as the file type.
if (SUCCEEDED(hr) && szDefaultVal[0] != L'\0')
{
pszFileType = szDefaultVal;
}
}
// Create the registry key
// HKCR\<File Type>\shellex\{e357fccd-a995-4576-b01f-234630154e96}
hr = StringCchPrintf(keyPath, ARRAYSIZE(keyPath),
L"%s\\shellex\\{e357fccd-a995-4576-b01f-234630154e96}", pszFileType);