VC++ 7.0/NET

Da es hier ja auch um .NET allgemein und was damit zusammenhängt geht:
Hat schon jemand VC++ 7/.NET ?

Wie ist der Compiler ?
Hat sich die IDE weiterentwickelt...sinnvolle Neuerungen ?
Kann man damit Code für das .NET Framework aber auch nativen Code erstellen ?
Wie sieht es mit dem Standard aus ? Ist das Schlüsselwort export endlich implementiert, kommt er mit partieller Templatespezialisierung zurecht ?
Ist der Linker (bzw. der Objektcode) kompatibel zu dem von VC++ 6.0 ? Also kann ich weiterhin meine Import Libs verwenden oder muss ich die aus den DLLs neu extrahieren (Wenn ein entsprechendes Tool dabei ist) ?

Bitte berichtet mal bevor ich mir das Teil bestelle

space

[ Dieser Beitrag wurde am 27.05.2002 um 17:51 Uhr von Space^qx editiert. ]

Szcypior

Hallo,

Kann man damit Code für das .NET Framework aber auch nativen Code erstellen ?

Ja kann man!

Die anderen Fragen kann ich leider net beantworten. Weil ich das noch nicht ausprobiert habe.
Es ist auch eine neue MFC Version mit dabei.

cu

thomas80d

Original erstellt von Space^qx:
Ist das Schlüsselwort export endlich implementiert editiert. ][/QB]

Leider nein. Dafür haben sie jetzt for( int i;...) total versaut.

Szcypior

Wieso, was haben die denn mit der for-Schleife gemacht???

cu

Das ist ja wohl ein Witz.
Soll man vielleicht bis VC 11.0 warten bis export mal vorhanden ist ?
Der 'neue' Intel Compiler kennt das Keyword auch nicht.

Dafür haben sie jetzt for( int i;...) total versaut.

Wie meinst du das ?
Wenn
for(int i=0; i<2; i++);
for(int i=0; i<2; i++);
jetzt funktioniert haben sie aber nix versaut sondern nur einen Bug behoben

Scania V8

Dies ist alles neu:

Allgemein: msdn.microsoft.com/library/default.asp?url=/library/en-us/vcedit/html/vcrefwhatsnewcompilerandcplulangvisualc70.asp

.NET: msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmex/html/vclrfMXKeywords.asp

Delirium

Der 'neue' Intel Compiler kennt das Keyword auch nicht.

Ich war mir bis jetzt eigentlich ziemlich sicher, dass der Intel Compiler 'export' unterstützt ... wenn dieser Compiler nicht, wer dann? Gibts überhaupt irgendeinen der es unterstützt (g++ ?)?

@Delirium
Ich habe mir vorgestern die 30 Tage Testversion des Intel Compilers für Windows runtergeladen.
Viel konnte ich nocht nicht testen, aber 'export' ist ihm ein Fremdwort. Part. Templatespezialisierung beherrscht er aber.

Also ich hab mich nicht ausgiebig damit beschäftigt. Vielleicht muss für export eine spezielle Compileroption gesetzt werden ? Halte ich aber für seeehr unwahrscheinlich.

Btw. g++ auch nicht. Genauso wenig wie Borlands BCC32 5.0.x.
Mir ist keine Compiler bekannt der export kennt.

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

Scania V8

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q243451

im Mai überarbeitet!

thomas80d

Original erstellt von Space^qx:
**
for(int i=0; i<2; i++);
for(int i=0; i<2; i++);
jetzt funktioniert haben sie aber nix versaut sondern nur einen Bug behoben :)**

Und was ist damit?

for(int i=0; i<2; i++);
i = 3;
for(int i=0; i<2; i++);

Wieso darf ich das i benutzen?
Und aufgepasst, nimm mal anstatt int ne eigene Klasse und definier mal explizit C-tor und D-tor. Und schau dann mal, wo was aufgerufen wird.

@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. ]

thomas80d

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.

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.

O'Dog

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

Lacos

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

Helium

Setzt mal in die erste Zeile eurer Programme ein

#define for if(false); else for

Dan ist alles wie im Standard defniert.

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

Delirium

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

SideWinder

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

thomas80d

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.