Würde mich freuen, wenn ihr mir dazu antworten könntet...
Gruß
E-the-Real

1. Ist dieses Visual C++ .Net kompatibel zum alten Sprachstandard, d.h. kann ich wie gewohnt C++-Programme mit dem neuen Teil schreiben, oder muß ich von nun an Managed C++ bzw. .NET-Klassensyntax lernen?

Du kannst natürlich auch C++-Programme damit schreiben.

ethereal schrieb:

2. Ich hatte vor, mir die Professional-Edition zu besorgen(die gibt es ja für Schüle/Stud. etc günstiger). Reicht die aus, oder braucht man unbedingt die Features der Enterprise-Versionen???

Kommt drauf an was du machen willst. Mir persönlich reicht Professional. Auf der Arbeit benutze ich die Enterprise Architect-Version. Allerdings habe ich noch nie ein Feature benutzt das ich nicht auch zu Hause habe.

2. Woher sollen wir wissen, ob dir die Prof-Version reicht oder du die Enterprise benötigst? Mir z.B. reicht die Standard-Version voll aus. Schau doch einfach auf der MS-Website nach, da gibt es einen Vergleich der Versionen:
http://msdn.microsoft.com/visualc/howtobuy/choosing.aspx

Aber der Unterschied Standard <=> Professional ist gigantisch, vor allem weil die Professional-Variante einen stark optimierenden Compiler hat (Optimierungen auch spezifizierbar, etc.).

MfG SideWinder

P.S.:

Und selbst dann kann man genialerweise sogar unmanaged mit managed Code mischen, in dem man im Sourcecode Markierungen anhand von Makros setzt. Einfach genial, wie ich finde!

hmmm....das hört sich stilistisch so nach Spaghetti-Mixcode an, wenn man hier ein bissl .NET-Class schreibt, dann kommt etwas unmanaged C++, vielleicht noch ein bischen C, um "hardwarenah" zu bleiben und für die Hardcore-Routinen Assembler auch mit drin... OK, ein bischen überzeichnet, aber besteht da nicht prinzipiell eine Gefahr, dass der Code dann eben doch nicht mehr einheitlich ist?

Und ANSI-C wird imho soweit unterstüzt wie es mit C++ Gemeinsamkeiten hat. Ein paar Dinge aus dem C99-Standard werden also eventuell unter den Tisch gekehrt da es in erster Linie immer noch ein C++-Compiler ist.

MfG SideWinder

using System::String;
S"Ein System::String";   // ich weiss net...

new __gc System::Object;   //  ;(

Und da das Übersetzungsmodell von C++ sowieso saugt und man die Vorteile von C++ aber nicht mehr richtig nutzen kann (const geht nicht), finde ich C# für sowas besser.

Ich z.B. finde es praktisch, das ich die GUI mit WindowsForms erstellen kann, wofür ja ManagedC++ nötig ist. Aber ich kann meine BusinessLogic im UnmanagedC++ schreiben und somit wäre sogar dieser teil noch portabel, das StandardC++.

Spagetti-Code ist es meiner Meinung nach nicht. Ein Bsp. aus der MSDN:

// pragma_directives_managed_unmanaged.cpp
// compile with: /clr
#using   <mscorlib.dll>
#include <stdio.h>

// func1 is managed
void func1(void)
{
   System::Console::WriteLine("In managed function.\n");
}

#pragma unmanaged

// func2 is unmanaged
void func2(void)
{
   printf("In unmanaged function.\n");
}

#pragma managed

// main is managed
int main()
{
   func1();
   func2();
}

Ausgabe:

In managed function.

In unmanaged function.

Wie man sieht, programmiert man gaaaanz normal wie immer, nur das man die #pragma-Makros einsetzen kann um zu switchen. Klar, wer sagt, ich brauch kein ManagedC++, verzichtet drauf. Wer aber mal auf das .NET-Framework (was nunmal mächtig ist und mächtiger wird!) zugreifen will, muß dafür auch nicht komplett auf eine andere Sprache umsteigen. Er baut ebend mal ein #pragma ein und ruft was im .NET auf und macht danach unmanaged weiter.

Und nicht jeder will oder muß portabel programmieren. Ich gehöre zu der Gattung, die gerne .NET-Features nutzen will, ohne auf C++ zu verzichten.

Aber es gibt nunmal .Net-Klassen, die einem ganz einfach das Windows-Coding einfacher machen können. Beispiel: WindowsForms. Oder meinetwegen anderen Nettigkeiten. Soll heißen, bevor man sich einen Ast abbricht, weil es das in der Standard-Lib nicht gibt oder die MFC einen stinkt, greift man auf .NET-Klassen zu.

Als C++-Programmierer sehe ich das .NET-Framework nicht als Ersatz (wie in deinem Beispiel) sondern als Ergenzung!

Ah, du hast in der Zwischenzeit wieder gepostet. Naja passt immer noch einigermaßen.

Mal schaun, für VS 2005 wollen sie da einiges nachbessern.

Eine neue Compilerversion? Aktuell ist doch imho 7.1,oder? Meint ihr, es lohnt sich, auf VS 05 zu warten?

Nochmal etwas zu dem switchen: Ich könnte mit vorstellen, dass dieses ewige "pragma-setzen" auch leicht zu weiteren Fehlerquellen führt, insgesamt also bei einer Mixtur die Fehleranfälligkeit größer wird. War es nicht ein Ziel MS', den Code rustikaler gegenüber eventuellen Fehlern zu machen? (Daher z.B. der implizite GarbageCollector, das Class-Framework etc...). Mir persönlich widerstrebt es momentan, da zu mixen (OK, ich muß zugeben, ich habe noch nicht viel mit .NET/C# gemacht, aber mal so rein vom Verständnis). Ebenso habe ich momentan auch nicht die Lust/Zeit/Notwendigkeit, auf C#/mC++ umzusteigen, ich will eigentlich nur einen neuen, besseren Compiler (momentan habe ich 6.0! ), und da ich mich bis jetzt halt an die MS-VisualIDE gewöhnt habe, wollte ich da auch bleiben...
Gruß
E-the-Real

Optimizer schrieb:

Mal schaun, für VS 2005 wollen sie da einiges nachbessern.

Eine neue Compilerversion? Aktuell ist doch imho 7.1,oder?

Jupp, z.B. mit 64-Bit-Unterstützung. Die IDE sieht auch stylischer aus!
Jo, 7.1 ist aktuell.

ethereal schrieb:

War es nicht ein Ziel MS', den Code rustikaler gegenüber eventuellen Fehlern zu machen?

Ich denke Du meinst "robuster"...

ethereal schrieb:

ich will eigentlich nur einen neuen, besseren Compiler (momentan habe ich 6.0! ), und da ich mich bis jetzt halt an die MS-VisualIDE gewöhnt habe, wollte ich da auch bleiben...

Naja gut. Von VS 6.0 auf .NET 2003 ist auch 'ne Umstellungssache!

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.