3. C++ und Longhorn?

C++ und Longhorn?

  • R

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

    0
  • ?

    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?

    0
  • R

    das hängt von der Internen Struktur des Typs ab 🙄

    0
  • A

    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.

    0
  • R

    @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

    0
  • A

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

    0
  • A

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

    0
  • O

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

    0
  • S

    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

    0
  • R

    @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 🙂

    0
  • S

    Ist CamleCase der Fachbegriff für:

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

    ?

    ja, FILE ist eben daneben gegangen.

    *g* 🙂

    MfG SideWinder

    0
  • I

    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

    0
  • O

    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.

    0
  • J

    operator void schrieb:

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

    😕 Was hattest Du erwartet? vector::iter_ator?

    0
  • O

    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.

    0
  • T

    Hallo,

    folgender Artikel bezüglich der Zukunft von C++ auf dem .NET - Framework sollte für jemanden mit noch nicht so goßer C++ Erfahrung (wie mich 🙂 ) besser verständlich sein, als die vorgenannten MSDN Artikel (ist allerdings auch nur ein kurzer Abriß):

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/movNETWFX.asp

    0
  • S

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

    Vielleicht meinst du ja C# - .NET ist jedenfalls viel mehr als ein Java-Gegner!!! Java ist eine Programmiersprache, .NET ist ein Framework.

    Mfg, smasher1985

    0
  • W

    smasher1985 schrieb:

    .NET ist jedenfalls viel mehr als ein Java-Gegner!!! Java ist eine Programmiersprache, .NET ist ein Framework.

    Java ist sogar eine Plattform...

    0
  • V

    Marcus hat einmal sehr schoen erklaert, was man sich unter .net vorstellen kann.

    Hier seine Worte:

    Marc++us schrieb:

    Du kannst Dir .NET letztlich als eine Art Betriebssystem vorstellen, das die gesamte Standardbibliothek bereits enthält. Also nicht nur solche Sachen, wie Du sie von MFC, VCL oder STL kennst, sondern auch das was man in C z.B. in math.h findet. Das geht sogar soweit, daß auch Multiplikation und Division in .NET enthalten ist.

    In heutigen BS ist das so tief nicht enthalten - daher bringt z.B. VB eine eigene Lib mit, die sich um Mathematik kümmert, C/C++ bringen je nach Compiler eigene mit, usw.

    Nun ist das alles aber bereits in .NET enthalten - schreibt man also nun für eine beliebige Sprache eine Anwendung unter .NET, so werden die ganzen Operationen durch Aufrufe der Funktionen aus der .NET-Bibliothek umgesetzt. Das hat zur Folge, daß alle Sprachen letztlich die gleiche Bibliothek nutzen, sie sind also nicht nur in der Funktionalität quasi identisch, sondern auch gleich schnell. Eine Multiplikation dauert unter C# genauso lange wie unter VB.NET oder COBOL.NET - es gibt da eine deutliche Vereinheitlichung.

    Die Sprachen unterscheiden sich also im wesentlichen nur noch im Syntax, aber nicht mehr in der Mächtigkeit.

    Das wollte ich euch nicht vorenthalten 🙂

    mfg
    v R

    0
Anmelden zum Antworten