C++ und Longhorn?

Morgen!

Ich wüsste gerne wie die Zukunft mit C++ aussieht wenn Windows Longhorn erscheint.
Dann wird es so langsam wohl nur noch 64 Bit Maschinen geben, allerdings habe ich gehört / gelesen (und fand es sinnig) das z.B. Assemblercode nicht mehr so einfach lauffähig ist, da sich ja die ganzen Registergrößen (etc. pp.) ändern.
Im Prinzip ist C++ wenn es compiliert wird ja nichts weiter als Assembler.

Wird sich nun etwas für die C++ Gemeinde ändern?

Naja soweit ich weiss

1. C++ ist nicht nur für die WIN-Welt
2. C++ bei 64 Bit kein Problem! Longhorn wird ja auch in C++(oder doch C-Sharp) programmiert.
3. Dann werden halt dein int ( 4 Bytes ) 8 Bytes betragen.
4. Sonst ändert sich nicht viel.

Ich wüsste gerne wie die Zukunft mit C++ aussieht wenn Windows Longhorn erscheint.

Unverändert, wenn es Compiler geben sollte, die Longhorn-Programme erzeugen (was wahrscheinlich ist).

Dann wird es so langsam wohl nur noch 64 Bit Maschinen geben, allerdings habe ich gehört / gelesen (und fand es sinnig) das z.B. Assemblercode nicht mehr so einfach lauffähig ist, da sich ja die ganzen Registergrößen (etc. pp.) ändern.

Auf einem reinen 64Bit - Prozessor läuft x86 Code nicht mehr, das ist korrekt.

Wird sich nun etwas für die C++ Gemeinde ändern?

Bei den meisten Compilern wird sich wohl die Größe des Datentyps 'long' von 32 Bit auf 64 Bit erhöhen.
Wer auf böse Hacks wie int in pointer casten und damit was auch immer tun verzichtet, wird in den meisten Fällen einfach nur neu compilieren müssen.

Das klingt doch schon sehr gut, meine Angst war ja das MS dann die C++ Programmierer ein wenig in die C# Ecke drängen möchte.

Möglicherweise haben die das auch ein bisschen versucht, eine Zeit lang. Zwar nicht mit 64 Bit oder Longhorn, aber mit .Net.
In C++ mit managed extensions hat AFAIK nicht mal die STL (das einzig gute an der stdlib ) anständig funktioniert und die Syntax für managed Elemente war butterhässlich. Also praktisch null Attraktivität um bei der .Net Entwicklung bei C++ zu bleiben.

Das ist jetzt aber nur eine böse Vermutung von mir, oder besser gesagt, der Glaube daran, dass die Möglichkeit besteht, dass es so gewesen sein könnte.

C++/CLI sieht ja jetzt schon sehr viel ordentlicher aus, eigentlich fast schon benutzbar. Ich glaube nicht, dass du dir wegen Microsoft Sorgen um die Zukunft von C++ machen musst.

das mit dem 32 bitter code ist richtig

Deswegen kann man das "emmeded" mässig so machen das man einmal im projekt seine eigenen datentypen deklariert die dann auf allen kisten laufen sollen

so in der art wie

UINT8 // hier unsiged 8 bit

INT16 // hier int 16 bit

dann muss man es einmal ändern und läuft dann dementsprechend auf 32 und 64 ohne probs

bitte berichtigt mich wenn dies nicht so gehen sollte

rüdiger

@newkid
*würg* komplett großgeschrieben Bezeichner sind hässlich. Macht die Standard Library ja auch nicht

In C++0x kommen hoffentlich die stdint.h-Typen aus C99. Die lauten int32_t etc. Der GCC bietet die Datei zB. schon an und Boost enthält auch so eine Datei.

grossschreiben rulez

wenn man in einer firma arbeitet gibts da ja bestimmt restriktionen, da kann man eh nicht das so machen wie man will.

wie geht das dann mit

COLORREF oder anderen datentypen. gehen die dann auf 32/64/128 ? oder muss ich unter c++ wie bei int auch was ändern?

rüdiger

das hängt von der Internen Struktur des Typs ab

Artchi

Ehm, es wird VisualC++ 2005 erscheinen und MS hat sogar ein neues Compilier- und Link-Verfahren erarbeitet, das nativen C++ Programmen sogar nochmal einen drastischen Performanceschub geben soll! Also nicht die bisher gewohnten Codeoptimierungen, sondern der Programmablauf soll vorhergesehen werden (ähnlich einem Hotspot, nur das es nicht zur Runtime passiert). Also MS investiert bzgl. C++ schon sehr viel, und MS ist ja im C++-Standardisierungs-Kommittee und die erarbeiten den nächsten C++-Standard mit aus.

64bit-Optionen gibts schon in VisualC++ 2003.. ich sehe jedenfalls die Option immer in meinen Projekt-Optionen, hab sie aber nie aktiviert (da ich eh nur einen Celeron habe).

Die STL wird an .NET angepasst, ist also auch kein Gegenargument mehr. Die C++/CLI-Syntax wurde von MS verbessert, weil es die Kunden so gefordert haben, wie MS selbst sagt.

Das MS kein C++ damals unterstützen wollte, kann ja auch nicht richtig sein. Hätten sie sonst ihren Compiler endlich standardkonform gemacht? (bis auf das export-Schlüsselwort) Und hätten sie Stanlay Lippmann und Herb Sutter angeheuert, wenn sie nicht mehr mit C++ zu tun haben wollen?

http://www.microsoft.com/PressPass/press/2001/Oct01/10-19lippmanpr.asp
http://www.microsoft.com/presspass/press/2002/Mar02/03-13SutterPR.asp

.NET ist einfach nur ein Java-Gegner, mehr nicht. C++ ist da einfach außer Konkurrenz.

rüdiger

@Artchi

Also nicht die bisher gewohnten Codeoptimierungen, sondern der Programmablauf soll vorhergesehen werden

meinst du so was wie Profiling mit dem Optimizer zu verbinden? Der GCC 3.x hat ja irgend wie so ein Feature.

Und um deine Links zu ergänzen
MSDN:C++: The Most Powerful Language for .NET Framework Programming

Artchi

Kann sein das es das gleiche Feature des GCC 3.x ist. Wer etwas darüber erfahren will, kann sich diese beiden Texte mal reinziehen:

Native C++:
http://msdn.microsoft.com/visualc/default.aspx?pull=/library/en-us/dv_vstechart/html/profileguidedoptimization.asp

C++/CLI:
http://msdn.microsoft.com/visualc/default.aspx?pull=/msdnmag/issues/04/05/visualc2005/default.aspx

Ich hab versucht es zu verstehen, ist mir aber etwas zu viel englischer Text. Zeigt aber sehr schön, das C++ bei MS eine bedeutende Rolle spielen wird! Man darf aber auch nicht vergessen, das alleine die ganzen Spieleentwickler auf PC und Xbox für MS ein sehr großer Markt sind. Kann mir nicht vorstellen, das MS es gut finden würde, wenn die auf einmal kein VisualStudio abonieren würden.

Artchi

Finde dieses Zitat über PGO sehr beeindruckend:

General Effectiveness
The current implementation of PGO has proven to be extremely effective in getting real-world performance. For example, we've seen 30%+ improvement on large real-world applications such as Microsoft SQL Server, and 4-15% gains on the SPEC benchmarks (depending on the architecture).

Über C++ in einer .NET-Umgebung:

You might choose C++ over other languages, however, if you're doing any sort of interop. The experience in C++ is almost certain to be nicer than other languages due to the extensive interop support built directly into the language. In addition, the deterministic cleanup it provides through destructors is invaluable when it comes to eliminating resource leakage and ensuring the correctness of your applications. C++ also has many powerful features that can be used in combination with those provided by the CLR.

Wer C# immer noch für den C++-Killer hält, sollte wieder schlafen gehen.

operator void

kingruedi schrieb:

@newkid
*würg* komplett großgeschrieben Bezeichner sind hässlich. Macht die Standard Library ja auch nicht

Außer bei FILE. Beim Rest eine bunte Mischung aus typ, typ_t und typ_type. Die Standardbibliothek ist kein gutes Vorbild :p

SCNR...

SideWinder

Finde Unterstriche allgemein hässlich und '_t' ist bei mir genauso beliebt wie 'C' am Beginn des Klassennamens und klingende Namespace-Namen wie myspace

MfG SideWinder

rüdiger

@operator void
ja, FILE ist eben daneben gegangen. Das die STL _type nimmt liegt wohl daran, da sie ja zunächst extern entworfen wurde.

@SideWinder
heheh, hoffentlich arbeiten wir nie zusammen an einem Code. Ich benutze immer Unterstriche (obwohl ich langsam auch ein wenig Attraktivität an CamleCase entdecke) und typedefs haben bei mir idr. auch ein _t am Ende. Zum einen, weil mein Editor den Typen dann auch bunt macht und zum anderen, weil ich das aus der Standard-Lib abgeguckt habe

Aber C am Anfang von Klassennamen mag ich auch nicht und Namespaces haben bei mir IMHO auch gute Namen

SideWinder

Ist CamleCase der Fachbegriff für:

getValue();
setValue();
doSomething();
isConnectionDead();

?

ja, FILE ist eben daneben gegangen.

*g*

MfG SideWinder

interpreter

SideWinder schrieb:

Ist CamleCase der Fachbegriff für:
getValue();
setValue();
doSomething();
isConnectionDead();
?

Ja, auch wenn es "Camel Casing" heißt

"Camel Casing convention capitalizes the first character of each word except the first word, as in the following examples.

propertyDescriptor
ioStream
htmlTag

http://blogs.msdn.com/brada/archive/2004/02/03/67024.aspx

operator void

kingruedi schrieb:

@operator void
ja, FILE ist eben daneben gegangen. Das die STL _type nimmt liegt wohl daran, da sie ja zunächst extern entworfen wurde.

Ist eigentlich egal, eklig ist es trotzdem: Es heißt vector::iterator, aber vector::value_type. Da sollte die WinAPI mit GROSSEN_TYPEN und MicrosoftCaseFunktionen sich lieber eine Scheibe von Java, Ruby usw. abschneiden.

Jester

operator void schrieb:

Es heißt vector::iterator, aber vector::value_type.

Was hattest Du erwartet? vector::iter_ator?

operator void

vector::iterator_type, vector::pointer_type usw. - nein, ich will das nicht, aber es wäre konsequent. Wollen tu ich Vector::Iterator, Vector::Pointer und Vector::Value.