4. VC++ 7.0/NET

VC++ 7.0/NET

  • ?

    @thomas80d
    Hä ?
    i =3; ist in dem Fall (nach dem Standard) illegal weils ein undefiniertes Symbol ist. In VC++ 6.0 funktionierte es aber eben weil die Variable nicht auf den Sichtbarkeitsbereich des Schleifenrumpfes begrenzt war. (Was in meinem Fall oben zu einem semantischen Fehler führt: Zweimalige Deklaration von i !)

    Also was ist nun das Problem in der neuen Version ?

    EDIT:
    @Scania V8
    Danke, der Link war hilfreich.

    [ Dieser Beitrag wurde am 28.05.2002 um 21:38 Uhr von Space^qx editiert. ]

    0
  • T

    Ja, aber in VC++ 7.0 geht das eben immer noch. Es müsste doch einen Error geben. Nachdem am Ende der Destruktor von i aufgerufen wurde, kann man immer noch drauf zugreifen.

    0
  • ?

    Ja, der Sichtbarkeitsbereich ist im VC5 und VC6 falsch implementiert - und auch im VC7. Und wird es auch im VC8, VC9 und VC## sein - stellt Euch vor, die wuerden das aendern. Man koennte keinen alten Quellcode mehr uebersetzen.

    Das ist der Fluch der boesen Tat - einmal vom Standard weg, immer vom Standard weg.

    Wer einen Standard C++ Quelltext uebersetzen muss, der auf den richtigen Sichtbarkeitsbereich aufsetzt, kann dies ja relativ leicht mit einem #define gem. MSDN loesen.

    0
  • O

    Original erstellt von Marc++us@aussenteam:
    Ja, der Sichtbarkeitsbereich ist im VC5 und VC6 falsch implementiert - und auch im VC7. Und wird es auch im VC8, VC9 und VC## sein - stellt Euch vor, die wuerden das aendern. Man koennte keinen alten Quellcode mehr uebersetzen.

    *lol* Danke für die kleine Aufheiterung, einach herrlich.
    Mit gcc wär das nicht passiert.

    O'Dog

    0
  • L

    [ Dieser Beitrag wurde am 30.05.2002 um 09:07 Uhr von Lacos editiert. ]

    0
  • H

    Setzt mal in die erste Zeile eurer Programme ein

    #define for if(false); else for

    Dan ist alles wie im Standard defniert.

    0
  • ?

    Hmpf, gestern hat mir jemand ein MS Statement zu export zitiert: "Die Benutzer wollen keine unnötigen Features die sie sowieso nicht benutzen..."
    Deshalb wird es weder jetzt noch in Zukunft export geben.

    Weiss ja nicht wie ihr das seht aber dieses Schlüsselwort fehlt mir ständig. Implementation und Schnittstelle auf Dateiebene zu trennen trägt doch einiges an Übersichtlichkeit bei.
    Und cpp zu inkludieren oder explizite Templateinstanzierungen sind einfach keine Lösung 😞

    0
  • D

    Hmpf, gestern hat mir jemand ein MS Statement zu export zitiert: "Die Benutzer wollen keine unnötigen Features die sie sowieso nicht benutzen..."

    Unsere MS-Freunde machen ihre Umfragen wahrscheinlich in Grönland ..

    0
  • S

    Finde ich auch eine etwas gewagte Aussage von Microsoft...wollen wahrscheinlich das man vor lauter Frust zu c# wechselt.

    Ich persönlich würde gerne mehr Templates erstellen, aber immer alles in den Header zu packen finde ich fast schon obszön...

    MfG SideWinder

    0
  • T

    Original erstellt von SideWinder:
    **...wollen wahrscheinlich das man vor lauter Frust zu c# wechselt.
    **

    Das bringt dann auch nix, da es ja in C# noch nicht mal templates gibt.

    0
  • D

    Dafür aber immerhin den universellen Typ 'object'.

    0
  • H

    ja, aber object hat meiner meinung nach nur nachteile. Ein Template wird vom Compiler geprüft, object kann erst zur Laufzit entscheiden, ob alles korekt ist.

    Warum nennt sich C# eigentlich C# und nicht Java#, das wäre passender, da es kaum dinge aus C++, aber wfast alles aus Java übernommen hat.

    0
  • D

    Warum nennt sich C# eigentlich C# und nicht Java#, das wäre passender[..]

    Ich glaube das kommt aus Gründen des Marketings nicht so gut rüber 😉

    0
  • S

    Ausserdem soll dann mal noch J# kommen.

    0
Anmelden zum Antworten