Ich habe etwas mit C++ Builder programmiert. Existiert etwas (RAD:Rapid Application Development) was C++ Builder ähnelt?
Ja der C++ Builder wird von der Firma Embarcadero weiter geführt, jedoch sind die Versionen nicht billig. Ansonsten wenn du bei C++ bleiben willst probier mal QT + QTCreator aus, welches kostenlos ist. Ansonsten für Oberflächen unter Windows würde ich C#/VB.Net + Visual Studio empfehlen. (Ist in der Community Edition auch kostenlos)
Hallo skorpionx, ich programmiere auch mit C++-Builder von Borland. VisualC++ von Microsoft ist sehr ähnlich und dazu kostenlos zu haben. Kann man bei Microsoft oder Anderen (z.B: Computerbild) einfach herunterladen. Die Versionen nach 8 müssen bei Microsoft registriert werden. Deshalb ist mir die Version 8 am liebsten, sie läuft ohne Registrierung. Gruß. Tom
as schrieb: > Ansonsten für Oberflächen unter Windows würde ich C#/VB.Net + Visual > Studio empfehlen. Das hat dann nur mit der Programmierung in C++ nichts mehr zu tun. toma schrieb: > Kann man bei Microsoft oder Anderen (z.B: Computerbild) einfach > herunterladen. Warum sollte man das bei "Anderen" machen, undnicht bei Microsoft selbst?
Rufus Τ. Firefly schrieb: > Warum sollte man das bei "Anderen" machen, undnicht bei Microsoft > selbst? Weil man dabei noch einen proprietären Downloader kostenlos dazu bekommt? Georg
Hmm. Ist da "Softonic" nicht noch besser? Oder irgendeine WareZ-Seite?
Ich nehme gerne mingw32, das ist aber ein bisschen anders als Borland-Builder und Co.
C++ und "rapid" application development? Wenn's schnell gehen soll, verwende Java und eclipse oder IntelliJ o.ä...
J. Wa. schrieb:
> Ich nehme gerne mingw32
Dazu passend: CodeBlocks IDE
Rainer V. schrieb: > J. Wa. schrieb: >> Ich nehme gerne mingw32 > > Dazu passend: CodeBlocks IDE Sehr schön. Und wo ist dann das Rapid Application Development? Der Borland-Compiler war (ist?) einer der schnellsten C++-Compiler, die IDE ist immer noch eine der IDEs, die am besten zu benutzen sind, die Code-Generatoren und GUI-Tools ebenso. Was hat davon mingw32 oder CodeBlocks? Nichts. Für Konsolenprogramme oder Bare-Metal ist das eine wirklich gute Kombination, aber für GUIs, Datenbankanwendungen etc. eher nicht. @Java: "Java is the most distressing thing to happen to computing since MS-DOS." Alan Kay
:
Bearbeitet durch User
Arc Net schrieb:
> ... Was hat davon mingw32 oder CodeBlocks? Nichts.
Es kostet ja auch nichts. Für den Zweck des TE aber wohl nicht geeignet.
Lazarus wär noch ein ernstzunehmender Konkurrent. Du musst (oder darfst) dann aber was anderes (manche würden sagen besseres) als C++ verwenden.
Versuch mal das aktuelle, kostenlose Microsoft Visual Studio Express 2013 for Windows Desktop. Das kann von Haus aus auch aus C++ native EXE's (also Projekte ohne .NET) erzeugen. https://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx Du wirst gewisse Ähnlichkeiten von Visual Studio und den alten Borland Tools feststellen. Das kommt daher, dass Microsoft im Jahr 1996 den Chefentwickler von Borland geholt hat, welcher vieles in die Entwicklungstools hat einfliessen lassen. https://de.wikipedia.org/wiki/Anders_Hejlsberg
:
Bearbeitet durch User
Die Hauptarbeit bei Windows und seinem .NET liegt ja eher im Einstieg bzw. Umgang mit all den Klassenbibliotheken. Daher kann ich den zusätzlichen Einstieg, quasi die Mitnahme von C# nur empfehlen. Nachher willst Du nicht mehr in C++ programmieren. C# ist die native Programmiersprache für .NET
Es gibt den C++ Builder auch kostenlos. Aber nur die 32 Bit Version funktioniert auch, die 64 Bit Version sollte man nicht herunterladen, wenn man nicht neu installieren möchte. Zur Zeit in Arbeit ist ein Tool für wxWidgets, damit kann man dann Windows-, Linux- und Mac-Programme erstellen. Leider ist das heute noch nicht fertig. Die Variante mit Visual Studio habe ich nicht erprobt, auf YouTube gibt es ein Video, wie man auch damit C++ Programme mit Windows Forms erstellt : https://www.youtube.com/watch?v=gB51Tla5pPI .
> den C++ Builder
Von welcher Version reden wir eigentlich?
Vor ein paar Jahren konnte man den Borland C++ Builder
fuer 49 Euro kaufen.
Ist es die?
Wer heute noch GUIs in C++ entwickelt, ist in den 90ern stecken geblieben.
Proktologe schrieb: > Wer heute noch GUIs in C++ entwickelt, ist in den 90ern stecken > geblieben. https://www.qt.io/develop "Qt Creator IDE Responsive and intuitive cross-platform development environment for creating C++ and declarative QML applications with integrated tools for WYSIWYG UI design, code editor with syntax completion, and visual debugging & profiling tools." Da kommt noch ganz viel C++ vor... @Proktologe: Was würdest du verwenden? Was ist deiner Meinung nach State-of-the-Art in 2021? Objective-C?
:
Bearbeitet durch User
Servus ich arbeite auch immer noch mit nem Borland C++ Builder, Version 4 von 1999; Ein olles 32-Bit Produkt. Läuft aber immer noch und da ich nicht oft Aufgaben für nen PC habe, wüsste ich nicht warum ich auf was anderes umsteigen soll. Hab auch mal mit der frein Ausgabe von Microsoft Visual Studio C# gearbeitet. Aber C# is was für Sados, im Vergleich zum alten Borland. :-) Aber eine freie Version vom Borland Builder ist mir nicht bekannt. Es gab mal nen Builder V6 Personal, der mit nem Buch mitgeliefert wurde, der muss aber trotzdem freigeschaltet werden und das geht meines Wissens nicht mehr. Gruß gerhard
Marie M. schrieb: > Da kommt noch ganz viel C++ vor... Das ist fast schon ein Sonderfall weil Qt die ganzen hässlichen Ecken von C++ überdeckt, im Idealfall entwickelt man nur gegen die Qt-API die viel mehr als nur GUI mitbringt.
Proktologe schrieb: > Das ist fast schon ein Sonderfall weil Qt die ganzen hässlichen Ecken > von C++ überdeckt, im Idealfall entwickelt man nur gegen die Qt-API die > viel mehr als nur GUI mitbringt. Ist genau andersrum... Im Prinzip ist Qt so C++ - 90er, daß das schon fast wehtut. Den ganzen Kram ausser dem GUI brauchts heutzutage nicht mehr, die schaffen es nur nicht, die ganzen Altlasten rauszuwerfen. Oliver
Wenn ich mir das Qt-Zeug so ansehe, erinnert mich das an statisch gelinkte X-Applikationen. Vor allen Dingen gross. Vom Rest verstehe ich gottseidank nichts. Aber das Ei des Kolumbus sollte irgendwie anders aussehen.
Was ist denn eurer Meinung nach eine "state-of-the-art" GUI-Entwicklungsumgebung? Nicht dass ich ein QT-Fan bin, es erscheint mir auch riesig.
:
Bearbeitet durch User
winforms mit c# ist meiner Meinung nach ausgewogen zwischen Enfachheit und Funktionalität entweder mit visual studio community oder sharp develop ich greife immer noch zu sharp develop, leider wird es nicht weiterentwickelt
... schrieb: > Wenn ich mir das Qt-Zeug so ansehe, erinnert mich das an > statisch gelinkte X-Applikationen. Man kann das statisch linken, wenn es unbedingt sein muß, üblich ist das aber eher nicht. Dafür muß man dann halt die (vom Programm benötigten) Qt-libs mit ausliefern. Wer nur für Windows entwickelt, kann bei C# mit dem dazugehörigen .net-Gedöns bleiben. Das ist "schlank", weil Windwos dafür halt schon alles mitbringt. Qt läuft plattformübergreifend auf Windows, Linux, und Mac. Hat alles seine Vor- und Nachteile. Oliver
Ohne eine Wahl zu haben, nutze ich VS. Das ist völlig Ok. Ich hatte vor Jahren einmal NetBeans ausprobiert. Fand ich damals nicht schlecht.
Oliver S. schrieb: > Man kann das statisch linken, wenn es unbedingt sein muß, üblich ist das > aber eher nicht. Dafür muß man dann halt die (vom Programm benötigten) > Qt-libs mit ausliefern. Ja. Das können dann mal ein paar Dutzend Megabyte sein. So what? > Wer nur für Windows entwickelt, kann bei C# mit dem dazugehörigen > .net-Gedöns bleiben. Das ist "schlank", weil Windwos dafür halt schon > alles mitbringt. Oder anders gesagt: Die Gigabytes an Bibliotheken und Laufzeitumgebung, die dafür benötigt werden, sind halt schon installiert. Das Zeug ist auch nicht schlank. Das Fett wurde nur besser versteckt. > Qt läuft plattformübergreifend auf Windows, Linux, und Mac. Und Android
> Wer nur für Windows entwickelt, kann bei C# mit dem dazugehörigen > .net-Gedöns bleiben winforms port gibt es auch unter linux mit mono. Ich hatte es mal unter rasp pi angetestet und keine probleme bisher gehabt.
Da auch eine Taschenlampen App 60 MByte auf dem Handy belegt, muss man etwas grosszuegig sein.
Oliver S. schrieb: > Im Prinzip ist Qt so C++ - 90er, daß das schon fast wehtut. Den ganzen > Kram ausser dem GUI brauchts heutzutage nicht mehr, die schaffen es nur > nicht, die ganzen Altlasten rauszuwerfen. Hm, dann muss ich was verpasst haben. Oder seit wann hat die C++ Standardbibliothek - einen XML-Parser - einen JSON-Parser - Filesystem-Handling - eine URL-Klasse - ein Settings-Framework - Netzwerk-Unterstuetzung - eine RegExp-Engine mit brauchbarer Performance (nein, std::regex ist das nicht) - ... Klar, QVector braucht eigentlich keiner mehr. Musst du aber auch quasi nicht benutzen, mein neuer Qt-Core benutzt ausschliesslich STL-Container.
:
Bearbeitet durch User
Sven B. schrieb: > Klar, QVector braucht eigentlich keiner mehr. Musst du aber auch quasi > nicht benutzen, mein neuer Qt-Core benutzt ausschliesslich > STL-Container. Ich bezog das auch eher auf die „hässlichen Ecken“ von C++, nicht auf die libs drumherum. Qt hat halt aus historischen Gründen einige Überschneidungen mit der Standardbibliothek, die heute wehtun. Neben den Containern inzwischen auch das ganze Multithreading-Gedöns. Und solange deren Container int als size-type und index-Type benutzen, ist ein nahtloser Austausch mit der Standardlib mühsam. Von deren Standardtypen ist alleine QString nett, daß dann allerdings wirklich. Olivet
Oliver S. schrieb: > Sven B. schrieb: > Qt hat halt aus historischen Gründen einige Überschneidungen mit der > Standardbibliothek, die heute wehtun. Das stimmt. > Neben den Containern inzwischen > auch das ganze Multithreading-Gedöns. Das weiß ich nicht, ob ich dem zustimmen würde. std::thread ist eher zwei als eine Abstraktionsebene unter QtConcurrent. Schon QThread hat diverse Funktionalität, die in der STL keinen Sinn macht, z.B. die QObject Thread Affinity, eine Event Loop, und das Signal/Slot Queueing. > Und solange deren Container int als size-type und index-Type benutzen, > ist ein nahtloser Austausch mit der Standardlib mühsam. Da liegt der Fehler allerdings in der STL, wie inzwischen auch das Standardisierungskommitee eingesehen hat. ;)
Sven B. schrieb: > std::thread ist eher > zwei als eine Abstraktionsebene unter QtConcurrent. Ich war da gedanklich schon bei C++20 ;) QtConcurrent ist leider eine der eher wackeligen libs in Qt. So ganz komplett und konsistent ist das nicht, und auch die Doku ist arg verbesserungswürdig. Aber egal, das wird jetzt OT. Oliver
Benutze einfach die Rad Studio Community Edition. Die ist kostenfrei, (Registrierung aber notwendig) und auf dem Stand 10.3.2 Einfach mal bei Embarcadero auf die Seite gehen und staunen. Es lohnt sich! mfg
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.