Visual C++.net 2003 Standard oder Visual C++ Express 2005

Willst du vermeiden, .NET mit an Bord des Entwicklungssystems zu nehmen, 
oder willst du es nur auf den Zielsystemen des Produkts vermeiden? 
Letzteres geht auch mit VS200x.

> Wenn du VS2003 oder 2005 verwendest benutzt du zwangsläufig .NET.
> Wenn du einen "nativen" C Compiler willst mußt du VS6 nehmen

Glücklicherweise irrt "Clifford" hier.
VS2003 und VS2005 enthalten durchaus "native" 
nicht-dot-net-C/C++-Compiler, und die sind sogar vorzüglichst und dem 
C/C++-Compiler aus VS6 deutlich überlegen.

@MicroMann:
Sofern Du auf die MFC verzichten kannst, kannst Du die 2005er 
Express-Version nutzen (da die MFC-Unterstützung nur in der gegen Kohle 
zu bekommenden Version enthalten ist).

Hi

wen du MFC machen mußt (würg) dann die 2003er Standard da die Express 
Editions MFC nicht unterstützen. Wenns um reine Windows-API 
(doppelwürg) geht kannst du auch zur 2005er Express + Platform SDK 
greifen. Beide IDEs benötigen zwar .NET man kann damit aber problemlos 
native Programme compilieren (bei der Express brauchts das Platform SDK)

Matthias

Nun, es gibt Leute, die wollen C-Programme schreiben. Oder 
C++-Programme.

Und das geht nicht mit dem .Net-Geraffel.

Mit C lässt es sich gar nicht nutzen, und anstelle von C++ muss man eine 
Microsoft-Perversion namens "Managed C++" nutzen, die mit C++ nicht viel 
mehr als den Namen gemein hat.
Auch will nicht jeder die 20MB+ große .Net-Library auf jedem Rechner 
installieren. Auch wenn das "keinem weh tut".

Clifford wrote:

> Andererseits weiß ich nicht was gegen das .NET Framework spricht.

Ich will nicht, dass mir jede 'Nasenpopel-Applikation' den
Speicher erst mal Gigabyteweise zumüllt, bevor denn der
Garbage Kollektor erst mal wieder aufräumt.

Schön, daß wir das jetzt geklärt haben.

Es gibt Situationen, in denen man C programmieren können sollte - und in 
denen man wissen sollte, was ein Pointer ist und wie man damit umgeht.

Das lernt man mit einer Programmiersprache wie "Managed C++", C# oder 
auch Java nicht - und das sieht man deutlich, wenn man sich so die 
diversen Anfängerfragen hier im Forum ansieht.

Clifford wrote:
> Ich meinte damit wer ernsthaft Software für Windows (am besten noch mit
> grafischer Oberfläche) in C programmiert ist selber Schuld. C++ lass ich
> von mir aus noch angehen.

Das Witzige ist, dass eine gewisse Kenntnis dessen, wie das C-API
für Windows funktioniert ungemein hilfreich sein kann, wenn man
spezielle Dinge in Windows erreichen will. Wer noch nie eine
WndProc in Action gesehen hat, sucht sich manchmal dumm und dämlich.

Hi

das mag für MFC noch gelten aber die .NET Klassen kapseln dieses ganze 
Zeug derart weg das man sich darum wirklich keine Gedanken mehr machen 
brauch. GUI Programmierung ist damit erstmals (mit einem M$ Produkt) so 
einfach wie man sich das vorstellt (und wie es andere weit, weit früher 
ermöglichten). Den 10MB RAM Sockelbedarf und den nicht gerade 
berechenbaren GC zahlt man eben als Preis dafür. Aber hey, wenn ich ein 
Windowsprogramm schreibe das keine hohen Ansprüche stellt und etwas GUI 
haben soll -> Nichts einfachers als .NET. Für die absolute Kontrolle muß 
man aber immer noch die gute, alte Windows-API bemühen.

Matthias Weißer wrote:
> Hi
>
> das mag für MFC noch gelten aber die .NET Klassen kapseln dieses ganze
> Zeug derart weg das man sich darum wirklich keine Gedanken mehr machen
> brauch.

Du hast noch nie Controls für das Compact Framework programmiert :-)

> Aber hey, wenn ich ein
> Windowsprogramm schreibe das keine hohen Ansprüche stellt und etwas GUI
> haben soll -> Nichts einfachers als .NET.

Da geb ich dir allerdings recht.

Karl heinz Buchegger wrote:
> Matthias Weißer wrote:
>> Hi
>>
>> das mag für MFC noch gelten aber die .NET Klassen kapseln dieses ganze
>> Zeug derart weg das man sich darum wirklich keine Gedanken mehr machen
>> brauch.
>
> Du hast noch nie Controls für das Compact Framework programmiert :-)

Richtig. Compact Framework ist doch das für PDAs und Co. gedachte 
abgespeckte .NET Framework? Das ist mir bis jetzt erspart geblieben (und 
bleibt es hoffentlich auch)

Matthias