Forum: PC-Programmierung Visual Studio 2022 Möglichkeiten

Ja, kann man.

Walter L. schrieb:
> Beispielprogramme?

https://learn.microsoft.com/en-us/windows/win32/menurc/dialog-resource

Falls ein Designer benötigt wird und es C, C++ sein muss; dann C++ 
Builder, QT oder tkl, gtk usw..

Walter L. schrieb:

> kann man mit der kostenlosen Version "Visual Studio 2022" in C oder C++
> auch solche "Fenster-Programme" schreiben?

Prinzpiell: ja sicher.

> Wenn ja, woher bekommt man Beispielprogramme?

Beispielprogramme werden dir (alleine) nichts nützen. Man muß schon 
wissen, was man tut.

Wer so fragt, wie du, weiß das nicht. Aber: Man KANN das durchaus 
lernen. Die Frage ist also: willst du das wirklich lernen? Viel 
einfacher wäre: C# benutzen...

Daran wiederum C/C++-Teile anzuflanschen ist zwar auch nicht ganz ohne, 
aber vergleichsweise doch deutlich einfacher.

Das gilt für die Express-Version.

Die kostenlose Community-Edition kann in dem Kontext alles, was die 
Bezahlversionen auch können.

Oliver

Walter L. schrieb:
> offensichtlich kann man in der kostenlosen Visual Studio 2022 Version
> nur Konsolenanwendungen starten.

Nein. Auch damit kann man normale Windows-Anwendungen schreiben; die 
Win32-API lässt sich sowohl mit dem nativen C- als auch mit dem nativen 
C++-Compiler nutzen.

Obacht! "C++/CLI" ist kein C++.

Ja kein Problem, einfach in "Visual Studio" ein neues "WinForms" Projekt 
anlegen. Sollte mit allen unterstützten Programmiersprachen gehen, ich 
empfehle C#.

Johnny B. schrieb:
> einfach in "Visual Studio" ein neues "WinForms" Projekt
> anlegen.
> Sollte mit allen unterstützten Programmiersprachen gehen

Nein, genau das tut es nicht. Es funktioniert ausschließlich mit 
.Net-Sprachen, also nicht mit C++ und natürlich nicht mit C.

Visual Studio 2022 aber unterstützt echtes C++ und auch C (und MS hat 
sich mittlerweile auch getraut, mehr als nur C90 zu unterstützen).

Ad nauseam: "C++/CLI" ist kein C++, sondern eine nur ähnliche 
Spezialsprache für .Net.

Harald K. schrieb:

> Ad nauseam: "C++/CLI" ist kein C++, sondern eine nur ähnliche
> Spezialsprache für .Net.

Nein, das ist schon C++. Mit einigen "Spracherweiterungen", die 
allerdings auch wieder in C++(*) geschrieben sind.

Siehe auch:
https://de.wikipedia.org/wiki/C%2B%2B/CLI

Wenn man viel Langeweile und unendlich Zeit hat, könnte man die auch 
selber schreiben. Man kann sie aber auch einfach so benutzen, wie sie 
von MS mitgeliefert werden...

(*) Natürlich sind die nicht vollständig in C++ geschrieben. Recht viel 
davon ist C, einiges sogar Asm. Aber die C++ler sind ja geneigt, niemals 
soweit in die Tiefe sehen zu wollen, den ganze historischen Schmutz in 
ihrer geliebten Umgebung verdrängen sie nur zu gern, denn so wie bei 
C++/CLI sieht es bei C++ sowieso ziemlich generell aus, jedenfalls 
sobald der Kram in einem praktischen Kontext verwendet wird...

C-hater schrieb:
> Nein, das ist schon C++. Mit einigen "Spracherweiterungen", die
> allerdings auch wieder in C++(*) geschrieben sind.

Nö. Natives C++ erzeugt Binaries für eine Prozessorarchitektur (x86 
etc.), und keinen Code für die CIL ("Common Intermediate Language"), der 
wiederum vom VES ("Virtual Execution System") ausgeführt wird.

Ohne diese Laufzeitumgebung ist auch das primitivste .Net-Programm nicht 
verwendbar.

Nativer C++-Code kann ohne "marshaling" direkt auch in C oder auch 
Assembler geschriebenen Code aufrufen; um das aus einer .Net-Sprache 
heraus zu machen, ist einiger Mehraufwand nötig.

C-hater schrieb:
> Harald K. schrieb:
>
>> Ad nauseam: "C++/CLI" ist kein C++, sondern eine nur ähnliche
>> Spezialsprache für .Net.
>
> Nein, das ist schon C++. Mit einigen "Spracherweiterungen", die
> allerdings auch wieder in C++(*) geschrieben sind.

Die Java-Runtime ist in manchen Fällen auch in C++ geschrieben. Das 
heißt noch lange nicht, dass Java C++ ist.
Und diese "Spracherweiterungen" haben sehr weitreichende Folgen. Die 
ganzen .net-Bibliotheken zwingen zur exzessiven Nutzung dieser 
"Erweiterungen". Ohne sie funktioniert keine einzige davon.
Es ist also eine an C++ angelehnte Sprache, aber es ist kein C++.

Harald K. schrieb:
> C-hater schrieb:
>> Nein, das ist schon C++. Mit einigen "Spracherweiterungen", die
>> allerdings auch wieder in C++(*) geschrieben sind.
>
> Nö. Natives C++ erzeugt Binaries für eine Prozessorarchitektur (x86
> etc.), und keinen Code für die CIL ("Common Intermediate Language"), der
> wiederum vom VES ("Virtual Execution System") ausgeführt wird.

Das hat erst mal nichts damit zu tun, ob es C++ ist. Die Sprache legt 
nicht fest, was aus dem Code genau erzeugt wird oder wie das dann zur 
Ausführung gebracht wird, sondern nur, wie es sich am Ende verhalten 
soll. Mit cling gibt es sogar einen Interpreter für echtes C und C++.

Harald K. schrieb:
> Nö. Natives C++ erzeugt Binaries für eine Prozessorarchitektur (x86
> etc.), und keinen Code für die CIL ("Common Intermediate Language"), der
> wiederum vom VES ("Virtual Execution System") ausgeführt wird.

> Nativer C++-Code kann ohne "marshaling" direkt auch in C oder auch
> Assembler geschriebenen Code aufrufen; um das aus einer .Net-Sprache
> heraus zu machen, ist einiger Mehraufwand nötig.

Ist der Witz an und Sinn von C++/CLI nicht gerade, dass es beides kann?

"Eine Besonderheit von C++/CLI ist die Mischbarkeit von Code, der auf 
der virtuellen Maschine läuft, und Code, der direkt auf der CPU 
ausgeführt wird. Beide Arten von Programmcode können in einer einzigen 
Programmdatei zusammengestellt werden. Mit dieser Möglichkeit nimmt 
C++/CLI bislang eine Sonderstellung unter den .NET-Sprachen ein."

Deswegen kann man damit ja, soweit ich weiß, relativ einfach Layer 
schreiben, die auf der einen Seite (mit ""richtigem"" C++) auf native 
Bibliotheken wie OpenCV zugreifen, auf der anderen Seite über die 
C++/CLI-Erweiterungen eine Schnittstelle für .NET anbieten, z.B. für 
C#-GUI-Anwendungen.
GUI-Anwendungen mit C++/CLI und Windows Forms waren eher eine 
Merkwürdigkeit (die von MS schon lange nicht mehr unterstützt wird).

Sabi schrieb:
> Harald K. schrieb:
>> Nö. Natives C++ erzeugt Binaries für eine Prozessorarchitektur (x86
>> etc.), und keinen Code für die CIL ("Common Intermediate Language"), der
>> wiederum vom VES ("Virtual Execution System") ausgeführt wird.
>
>> Nativer C++-Code kann ohne "marshaling" direkt auch in C oder auch
>> Assembler geschriebenen Code aufrufen; um das aus einer .Net-Sprache
>> heraus zu machen, ist einiger Mehraufwand nötig.
>
> Ist der Witz an und Sinn von C++/CLI nicht gerade, dass es beides kann?

Ganz genau, du hast es erlickt wozu das gut sein soll.
Bleibt nur anzufügen dass der .NET code nicht in einer VM läuft, sondern 
mit JIT auch zu native code verwurstet wird (zur Laufzeit natürlich).

Harald K. schrieb:

> Nö. Natives C++ erzeugt Binaries für eine Prozessorarchitektur (x86
> etc.), und keinen Code für die CIL ("Common Intermediate Language"), der
> wiederum vom VES ("Virtual Execution System") ausgeführt wird.

Das steht wo genau im C++-Standard? Nirgendwo, natürlich nicht!

Nein, das ist natürlich völliger Bullshit. Einer Hochsprache selber 
sollte es natürlich von Hause aus so weit wie irgend möglich egal sein, 
was die Zielmaschine ist, genau das ist schließlich ein ganz 
wesentliches Designziel einer Hochsprache...

Nichts in der C++ Sprachdefinition erfordert, dass die Scheiße letztlich 
auf irgendeiner (oder gar einer konkreten) physischen CPU/MCU zu 
laufen vermag. Es ist absolut zulässig auch eine "VM" zu betreiben. Wenn 
halt ein passender Codegenerator den Code dafür erzeugen kann.

Und genau das ist, was C++/CLI tut.

C-hater schrieb:
> Nichts in der C++ Sprachdefinition erfordert

Aber die C++ - Sprachdefinition erfordert, dass

1

Klasse^ handle;

nicht compilieren darf.