ZFX + Developia

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.

Nein. Visual C++ erlaubt’s trotzdem und tut weitestgehend, was du erwarten würdest.

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.

Nein. Visual C++ erlaubt’s trotzdem und tut weitestgehend, was du erwarten würdest.

Weird.

Spiele Programmierer hat geschrieben:Der Speicherplatz für lokale Variablen wird für gewöhnlich am Anfang der Funktion allokiert und nicht auf Blocklevel.

Spiele Programmierer hat geschrieben: Wenn zwei lokale Variablen nicht gleichzeitig auftreten, können sie sich sie einen Bereich teilen.

Spiele Programmierer hat geschrieben:Ja mit "goto" kann man das teilweise untergraben.
Ohne "goto" bzw. andere teilweise problematische Konstrukte sollte es aber funktionieren. ;-)

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.

//pre-scope
{
    //in-scope
}
//post-scope

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?

Krishty hat geschrieben:

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?

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:Was war nochmal der Grund für den For-Scope Bug in Visual C++ 6? War das die Geschichte?

Darum sehe ich nicht, was da untergraben werden sollte.

Jonathan 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...

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?

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);

• log10() (fast 2 KiB)
• parse_command_line(), expand_argument_wildcards(), common_expand_argv_wildcards(), usw – obwohl ich eine DLL kompiliere(!)
• memcpy – ich sehe ein, dass man das manchmal zur Initialisierung braucht; aber nicht, dass es mit 1 KiB größer ist als viele meiner Image Loader
• _raise_exc_ex(), _seh_filter_exe() und weitere Ausnahmebehandlungsroutinen – obwohl Exceptions in den Projekteinstellungen abgeschaltet sind und ich kein SEH nutze
• setmbcp_internal(), write_text_utf8_nolock(), und weiterer Locale-Dreck – obwohl ich keine stdio oder C++-I/O nutze
• __report_gsfailure() – obwohl Security Checks deaktiviert und Security Cookies durch Compiler-Switch ausgeknipst sind
• Rund fünfzig Funktionen betreffend Locks und Mutexe – obwohl ich nichts in Richtung Multithreading verwende außer _InterlockedIncrement() & Co.
• Etliche KiB unkenntlichen Mülls aus einer gewissen winapi_thunks.obj

1. Visual C++ baut für alle globalen Variablen Initializer.
2. Diese Initializer werden bei Programmstart durch die CRT aufgerufen.
3. Die CRT wird nur gelinkt, nicht reinkompiliert. Die reingelinkte CRT hatte wahrscheinlich Exceptions eingeschaltet und nutzt irgendwo was mit Locales (Fehlermeldungen?).
4. Visual C++ hievt den Scheiß also auch bei mir rein
5. Sicher liegen die main() für DLL und EXE in der selben CPP, also werden beide gelinkt, also rutscht das Kommandozeilenzeug mit rein.