Wieder neue C++ Version?

dot

314159265358979 schrieb:

Man müsste es eben anschauen...

Exakt, denn dann wüsste man, dass gcnew nur als Schlüsselwort reserviert ist, im Moment aber keine Bedeutung hat...

314159265358979

Hm, okay. Du hast gewonnen.

Ich denke, um das richtig einzuordnen, muss man sehen, was das Ganze eigentlich soll. Ein Ersatz für C++ ist es sicher nicht, aber ich habe auch nicht den Eindruck, dass es so gedacht ist. Der Vergleich mit C++/CLI scheint angebracht; dabei handelt es sich ja auch nicht um eine vollwertige Sprache, sondern um einen C++-zu-.net-Adapter. So, wie ich das verstehe, will die "Windows Runtime" mit dem "abstract binary interface" (dieser Begriff bzw. seine Abkürzung dürfte zu einiger Verwirrung führen) eine Art alles-zu-allem-Adapter sein und außerdem endlich das uralte Problem der DLL-Hölle lösen.

Wenn ich mich nicht sehr täusche, Pi, ist das nicht so gedacht, dass du deine gesamten Programme, damit sie unter Windows funktionieren, in diesem neuen Dialekt schreiben sollst. Wenn du aber eigene Komponenten in Windows registrieren willst (Denkrichtung ActiveX), könnte er die Entwicklung vereinfachen. In diesem Fall läuft die Anbindung aber eh seit den Neunzigern zur Laufzeit.

Es ist ein ambitioniertes Vorhaben, dessen Erfolg stark von der Umsetzung abhängen wird; COM ist ja vor allem an der umständlichen Handhabung gescheitert (gescheitert im Sinne von "Microsoft will es eigentlich los werden, weil alle Programmierer ständig darüber fluchen"), obwohl das Konzept dahinter grundsolide (von CORBA geklaut) war. Ein neuer Anlauf, der es besser machen will, wird sich nur wenige Ärgernisse erlauben können, wenn er nicht als "meh, immer noch der selbe Mist" abgetan werden will, zumal die C++-Community sich inzwischen darauf eingeschossen hat, möglichst viel zur Compilezeit festzuziehen und dem gesamten Vorhaben weit weniger aufgeschlossen gegenüberstehen dürfte als zur Entwicklungszeit von COM. Insofern erfüllt es mich mit wenig Hoffnung, dass ausgerechnet "ref", welches in der C++-Standardbibliothek seit TR1 für andere Zwecke benutzt wird, als Schlüsselwort herhalten soll.

dot

seldon schrieb:

Ich denke, um das richtig einzuordnen, muss man sehen, was das Ganze eigentlich soll. Ein Ersatz für C++ ist es sicher nicht, aber ich habe auch nicht den Eindruck, dass es so gedacht ist.

Es handelt sich lediglich um Spracherweiterungen, die den Umgang mit WinRT erleichtern. Man könnte sich auch eigene Smartpointer basteln, anstatt die ^ Notation zu verwenden und anstatt von ref new die entsprechende Factory-Funktion (wie auch immer das neue CoCreateInstance() nun auch heißen mag) vermutlich direkt aufrufen usw. ref class , interface , etc. generieren wohl einfach nur Klassen, deren Layout eben kompatibel mit dem ABI von WinRT ist. Im Prinzip ist das alles also nicht wirklich was neues, vergleichbares gibts ja schon seit COM ( __interface , __uuidof , __declspec(property) , #import , ...) Ich geh eigentlich davon aus, dass es sich bei WinRT mehr um eine Erweiterung von COM, als um ein völlig neues System handelt.

seldon schrieb:

So, wie ich das verstehe, will die "Windows Runtime" mit dem "abstract binary interface" (dieser Begriff bzw. seine Abkürzung dürfte zu einiger Verwirrung führen) eine Art alles-zu-allem-Adapter sein und außerdem endlich das uralte Problem der DLL-Hölle lösen.

Wär jetzt nicht so, dass der Begriff des Application binary interface eine neue Erfindung von Microsoft ist

So gesehen würde ich sagen, dass mit WinRT das Windows-ABI um einige OOP Konzepte erweitert wurde, ohne jetzt mit irgendwelchen vorhandenen Dingen zu brechen. Eine gute Sache, sieht mir danach aus, als würde die Win32 API langsam in den Ruhestand gehen und durch eine neue objektorientierte API ersetzt werden, hat aber nichts damit zu tun, was C++ ist und nicht ist. Da C++ selbst kein ABI definiert, ist so etwas eben notwendig, wenn man mehr als eine pure C-API will...

krümelkacker

seldon schrieb:

Insofern erfüllt es mich mit wenig Hoffnung, dass ausgerechnet "ref", welches in der C++-Standardbibliothek seit TR1 für andere Zwecke benutzt wird, als Schlüsselwort herhalten soll.

Microsoft hat bei C++/CLI "kontextuelle Schlüsselwörter" verwendet. Es würde mich nicht wundern, wenn die das bei diesem C++/Cx auch so gemacht hätten. Dann würde "ref" nur wie ein Schlüsselwort behandelt, stünde es vor "new" oder vor "class" und könnte sonst weiterhin als Bezeichner verwendet werden.

Ja, es sieht aus wie C++/CLI. Sie haben aber nur die C++/CLI Syntax dafür recycelt, um C++ diesmal mit WinRT statt mit .Net zu verheiraten. Da es im WinRT-Objektmodell statt Garbage-Collection nur Ref-Counting gibt hamse statt "gcnew" eben "ref new" verwendet. Die werden sich schon 'was dabei gedacht haben, WinRT als Spracherweiterung zu verpacken. Da fallen ja diese winmd-Dateien ganz automatisch raus, was eine Art sprachneutrale, binäre Schnittstellenbeschreibung ist. Und diese binäre Schnittstellenbeschreibung unterstützt sogar Generics. So doof finde ich das alles gar nicht.

Wie man jetzt noch WinRT mit C# verheiratet, wäre die nächste Frage.

kk

Man müsste es eben anschauen...

Lol, wenn ich dafür nicht Silverlight oder ne andere proprietäre Kacke installieren müsste, die mir angeboten wurde.
Mach ich unter Linux gleich mal ... oh wait !!11

Zeus

IMO find ich technisch die WinRT überzeugend, scheiße find ich, dass man damit wohl nur Metro Style Apps entwickeln kann

Besonders weil man Template und normalen C++ Ding innerhalb eines Modules benutzen kann und zum Exportieren, sie in WinRT-Objekte/Typen einkapseln muss.

Nun heute mal die fast 5 GB große Dev Preview herunterladen.

Dravere

So, jetzt habe ich doch noch Zeit gefunden, mir das ganze Video anzuschauen. So ganz vom Hocker haut es mich nicht. Definitiv eine Verbesserung gegenüber COM oder auch C++/CLI Interop. Aber ein paar Fragen bleiben mir noch offen:
1. Nur Metro Style Apps?
2. Ist das Ziel mit WinRT die Win32 zu ersetzen? Aktuell ist die Win32 API ja noch daneben verfügbar. Aber aus dem Video hört man leicht heraus, dass mehr Gewicht auf WinRT gelegt wird. Mit WinRT erhält man zusätzliche Bibliotheken. WinRT soll die Verwendung der Computer revolutionieren. usw.
3. Wie offen ist WinRT? Heisst: Können andere Kompilerbauer einen Kompiler für WinRT bauen? Möglichst ohne Gebühren bezahlen zu müssen?
4. Keine eigenen Exceptions über Modulgrenzen?
5. Hätte man diese WinRT Anbindung nicht auch mit normalen C++ erreichen können und einfach einer mordernen C++ API?

Und naja, noch so ein paar Dinge ... irgendwie steht ich dem Zeug noch recht skeptisch gegenüber. Nun weiss man zumindest, wohin die ganze C++ Entwicklungsarbeit bei VS11 geflossen ist. In die auf dem PC unbrauchbare Metro Oberfläche

Ethon__ schrieb:

Man müsste es eben anschauen...

Lol, wenn ich dafür nicht Silverlight oder ne andere proprietäre Kacke installieren müsste, die mir angeboten wurde.
Mach ich unter Linux gleich mal ... oh wait !!11

Schau dir doch die Webseite mal ein wenig genauer an. Vielleicht gleich unter dem Silverlight-Bereich ... den Download-Bereich? Oder kann man auf Linux keinen Download durchführen?

Grüssli

PS: Um 21:50 im Video wird ein Code gezeigt: DatabaseConnection db();
Ist das nun keine Funktionsdeklaration mehr in C++11? Oder ist das ein Fehler im Code?

dot

Dravere schrieb:

1. Nur Metro Style Apps?

Im Moment ja, denk ich.

Dravere schrieb:

2. Ist das Ziel mit WinRT die Win32 zu ersetzen? Aktuell ist die Win32 API ja noch daneben verfügbar. Aber aus dem Video hört man leicht heraus, dass mehr Gewicht auf WinRT gelegt wird.

Ich vermute mal, dass langfristig wohl zumindest alle neuen APIs auf WinRT basieren werden. Im Moment isses wohl so dass Win32 für den Desktop und WinRT für Metro ist.

Dravere schrieb:

3. Wie offen ist WinRT? Heisst: Können andere Kompilerbauer einen Kompiler für WinRT bauen? Möglichst ohne Gebühren bezahlen zu müssen?

War afaik ja bei COM schon so, denke kaum dass es sich mit WinRT da anders verhalten wird. Vor allem hätte MS doch nix davon, die wollen vor allem eines: Möglichst viele Apps.

Dravere schrieb:

5. Hätte man diese WinRT Anbindung nicht auch mit normalen C++ erreichen können und einfach einer mordernen C++ API?

Nein, da "normales" C++ kein ABI definiert und vor allem will man ja nicht nur C++, sondern alle möglichen Sprachen unterstützen.

Dravere schrieb:

PS: Um 21:50 im Video wird ein Code gezeigt: DatabaseConnection db();
Ist das nun keine Funktionsdeklaration mehr in C++11? Oder ist das ein Fehler im Code?

Haha, genau das hab ich mir bei der Slide auch gedacht. Ich vermute mal, dass es ein Typo ist. Wer hätte gedacht, dass Herb Sutter persönlich sowas passiert

audacia

krümelkacker schrieb:

Und diese binäre Schnittstellenbeschreibung unterstützt sogar Generics.

Hast du dazu mehr Infos?

Dravere schrieb:

5. Hätte man diese WinRT Anbindung nicht auch mit normalen C++ erreichen können und einfach einer mordernen C++ API?

Da es letztlich alles COM ist, kannst du schon so eine ATL-artige Bibliothek schreiben, die fast ohne Spracherweiterungen auskommt. Aber die Wartbarkeit von ATL-C++-Code im Vergleich mit einer Sprache, die direkte Unterstützung für COM hat (Delphi, C# etc.), ist einfach miserabel.

Edit: "ist" eingefügt

Zeus

audacia schrieb:

krümelkacker schrieb:

Und diese binäre Schnittstellenbeschreibung unterstützt sogar Generics.

Hast du dazu mehr Infos?

Im Video, dass geht soweit, dass du Template-Instanzierte Objekte mit Hilfe von Generic Interface über die Module propagieren kannst.

generic<typename T, typename U>
interface class IPair {
public:
T getFirst();
U getSecond();

};

template<typename T, typename U>
class Pair : IPair<T, U>
{
....
};

audacia

Zeus schrieb:

Im Video

Verflixt, jetzt muß ich es doch ansehen.

Zeus schrieb:

dass geht soweit, dass du Template-Instanzierte Objekte mit Hilfe von Generic Interface über die Module propagieren kannst.

Ich verstehe kein Wort.

Zeus

audacia schrieb:

Zeus schrieb:

dass geht soweit, dass du Template-Instanzierte Objekte mit Hilfe von Generic Interface über die Module propagieren kannst.

Ich verstehe kein Wort.

Mein nachtragende Code ansehen, eine Instanz von Pair kann aus jede Programmiersprache zugegriffen werden, JavaScript, C#.

audacia

Zeus schrieb:

eine Instanz von Pair kann aus jeder Sprache zugegriffen werden, JavaScript, C#.

Okay, eine Instanz also - aber ich kann nicht cross-boundary instantiations vornehmen, oder?

dot

audacia schrieb:

Zeus schrieb:

eine Instanz von Pair kann aus jeder Sprache zugegriffen werden, JavaScript, C#.

Okay, eine Instanz also - aber ich kann nicht cross-boundary instantiations vornehmen, oder?

Wenn du damit meinst, dass du in JavaScript einen C++ geschriebene WinRT Typ instanzieren kann, dann lautet die Antwort: Doch, natürlich.

Zeus

audacia schrieb:

Zeus schrieb:

eine Instanz von Pair kann aus jeder Sprache zugegriffen werden, JavaScript, C#.

Okay, eine Instanz also - aber ich kann nicht cross-boundary instantiations vornehmen, oder?

Da bin ich unsicher jetzt, ich denke aber schon, aber beschränkt auf Generics.
Der Hauptpunkte,der mir im Kopf geblieben sind, sind die Intregationsfeature vom C++/STL Code.

audacia

dot schrieb:

audacia schrieb:

Zeus schrieb:

eine Instanz von Pair kann aus jeder Sprache zugegriffen werden, JavaScript, C#.

Okay, eine Instanz also - aber ich kann nicht cross-boundary instantiations vornehmen, oder?

Wenn du damit meinst, dass du in JavaScript einen C++ geschriebene WinRT Typ instanzieren kann, dann lautet die Antwort:

Nein. Ich meine das:

// C++ - Modul 1
template[generic?] <typename T>
    class vector
{
    ...
};

// C# - Modul 2
struct MyStruct
{
    public int someData;
}

...

vector<MyStruct> myVector; // Template-/Generic-Instantiierung jenseits der Modulgrenze, speziell mit einem auf der "anderen Seite" definierten Typargument

Zeus

Ja mit Generics, nicht mit Template.
btw das ist doch, was dot beschrieben hat o.O

Dravere

audacia schrieb:

Zeus schrieb:

dass geht soweit, dass du Template-Instanzierte Objekte mit Hilfe von Generic Interface über die Module propagieren kannst.

Ich verstehe kein Wort.

Naja, ca. so:

public ref class TheInterface
{
public:
  void IsHere(IPair<int, int>^ pair);
};

// ...
TheInterface^ interface = GetTheInterface();
interface->IsHere(ref new Pair<int, int>(4, 5));

Die Templateklasse Pair<int, int> wird somit als Genericklasse IPair<int, int> über die Modulgrenze gereicht. Pair<int, int> kann man nicht durchreichen, aber IPair<int, int> schon. Auch ist IPair (ohne Typenangabe) über die Modulgrenze verwendbar, dagegen ist das Klassentemplate Pair nur in C++ verwendbar.
Man kann schlussendlich aus Templates Genericklassen bauen, welche in der Schnittstelle verwendet werden können.

Am besten schaust du dir das Video an
Edit: Wups, da kamen noch ein paar andere Antworten zuvor. Naja, vielleicht ist meine trotzdem noch hilfreich

dot schrieb:

Dravere schrieb:

5. Hätte man diese WinRT Anbindung nicht auch mit normalen C++ erreichen können und einfach einer mordernen C++ API?

Nein, da "normales" C++ kein ABI definiert und vor allem will man ja nicht nur C++, sondern alle möglichen Sprachen unterstützen.

Ich weiss nicht. Klar hat C++ kein ABI, aber man hätte doch etwas in einer Bibliothek zur Verfügung stellen können. Ähnlich wie das andere Bibliotheken, wie zum Beispiel CORBA auch tun. Ich denke, dass es schon möglich gewesen wäre. Man müsste sich das nur mal klar durchdenken, aber dazu fehlt mir aktuell die Zeit.

Grüssli

dot

Ja klar, nach meinem Verständnis sollte das einfach so funktionieren.