Welches Framework(?) ist für mich geeignet
-
@SirLant
mach dir nicht so viele Sorgen, dass du etwas falsches oder zu viel lernst. Du wirst in dem Laufe deines Programmiererleben noch mit so vielen Biblihoteken arbeiten müssen. Deswegen such dir das aus, was die einfach am besten gefällt wenn du die API anguckst. Du stehst ja vor keiner ultimativen Entscheidung@Marc++us
Leider wenig Literatur dafür, wenige Tutorials, wenig Infos dazu.
das stimmt so nicht! Mittlerweile gibt es genügend Foren, Tutorials und Bücher zu Qt. Ich glaub nicht, dass da ein enormer Mangel existiert.
@Sovok
die MFC kostet auch Geld
-
SirLant schrieb:
Wenn ich alle Dateien in nem Verzeichnis
auslesen möchte, müsst ich dann trotzdem noch die Winapi nehmen, das will ich ja
möglichst vermeiden.Dafür kann man auch Boost.FileSystem nehmen. Boost würde ich mir in jedem Fall mal angucken, auch wenn es dir für UI nicht viel hilft: http://www.boost.org
-
@Marc++us: Bis auf einen Punkt stimme ich dir uneingeschränkt zu: VB6 und MFC ist keine gute Idee. VB6 wird von MS nicht mehr weiterentwickelt (=> VB.net). Daher sollte man entweder C# oder QT benutzen.
-
-
Dann sag doch mal wo man sie umsonst beziehen kann.
-
hmpf läd dir c++ builder x personal runter, da ist das dabei^^
-
vc++ hätt ich auch so gekauft
qt kostet deutlich mehr und man bekommt nich eine der besten entwicklungsumgebungen dazubtw. was is managed c++
-
-
IDEsupport is currently lacking, compared to other managed languages, since there's little or no designer support (but Everett will change this).
abgesehn davon hört sichs doch gut an
wann wird des gefixt?
-
2003, wenn Everett rauskommen wird?
Das ist einfach der Codename für MSVC7.1/2003, das schon länger in den Läden steht und (uA) einen Windows-Forms-Designer hat.
Viel Spaß macht das damit aber IMHO nicht. Der Designer fühlt sich selbst auf schnellen Kisten eher bloatig an und der erzeugte Quellcode ist nicht gerade dekorativ...
BTW: MS arbeitet schon fleißig an Managed C++s "Nachfolger", CLI/C++. Das ist eine standardisierte und *schöne* Möglichkeit, C++ und .NET miteinander zu verwenden. Dauert aber bestimmt noch ewig
-
dann bleibt halt erstmal mfc
-
mfc jetzt anfangen zu lernen lohnt sich erst recht nicht mehr. MS wird die nicht weiter unterstützen. Das ist verschwendete Zeit. Wobei man sich dann zusätzlich noch mit einem der ekelhaftesten C++ APIs rumschlagen muss.
btw. mit dotNET ist kein Platform unabhängiges GUI programmieren möglich! Die GUI und Datenbank Sachen sind proprietäre Erweiterungen zu dotNET und nicht im EMCA/ISO Standard enthalten AFAIK. Da bleibt dir dann auch nur GTK#!
-
Moment, da habe ich eine Frage zu: gtk# basiert doch aber auch auf den .NET-Forms, oder implementieren die den Fensterkernel selbst (und dann für jede Plattform)?
-
GTK# ist wohl nur ein binding zur GTK Library. Auf WinForms arbeitet das aber nicht!
-
I see
-
@Gtk# The current release is 0.15
das ding in nem ernsthaften projekt einzusetzen is selbstmord
mit einem der ekelhaftesten C++ APIs
is geschmacksache... ich mag mfc. ich hätt zwar nix gegen was aktuelleres. aber es gibt ja noch nix
-
@Gtk# The current release is 0.15
das ding in nem ernsthaften projekt einzusetzen is selbstmord
das zeigt deine Unwissenheit. Die Versionsnummer sagt so nichts über die Qualität des Produktes aus! Gerade im OpenSource Bereich wachsen die Versionsnummern extrem langsam. Du findest ja sogar schone eine Liste von Projekten, die die API benutzen.
ich hätt zwar nix gegen was aktuelleres. aber es gibt ja noch nix
nichts von MS. Ansonsten gibt es viele aktuellere Frameworks, die viel mehr C++ sind. (MFC könnte man ja fast als C bezeichnen)
siehe gtkmm, boost etc.
-
[quote="kingruedi"][quote]@Gtk# The current release is 0.15
das ding in nem ernsthaften projekt einzusetzen is selbstmord
das zeigt deine Unwissenheit. Die Versionsnummer sagt so nichts über die Qualität des Produktes aus! Gerade im OpenSource Bereich wachsen die Versionsnummern extrem langsam. Du findest ja sogar schone eine Liste von Projekten, die die API benutzen.
ich hätt zwar nix gegen was aktuelleres. aber es gibt ja noch nix
nichts von MS. Ansonsten gibt es viele aktuellere Frameworks, die viel mehr C++ sind. (MFC könnte man ja fast als C bezeichnen)
siehe gtkmm, boost etc.
was mich nervt is das alle diese projekte sagen was sie tolles können... aber selten was sie nich können
dann arbeitet man sich da ein, will es einsetzen und stoßt an irgendne kaum optimierte leistungsgrenzedie versionsnummer sagt aber definitiv aus dass es ab 1.0 bugfrei und benutztbar sein sollte ohne irgendwelche "not implemented yet" throws von funktionen die bereits in der doku stehn... nur als beispiel
ich will mich lieber drauf verlassen können, dass es kann was ich will
-
die versionsnummer sagt aber definitiv aus dass es ab 1.0 bugfrei und benutztbar sein sollte ohne irgendwelche "not implemented yet" throws von funktionen die bereits in der doku stehn... nur als beispiel
0.15 heisst nicht, dass die Software Bugs haben muss. Wahrscheinlich sind eben nur noch nicht alle GTK Features gewrapped. Aber das diskutieren bringt uns hier eh nichts, wer Platformunabhängige GUI mit dotNET will kommt zZ. eben nicht um GTK# herum. Die WinForms sind eine Platform abhängige proprietäre Erweiterung von Microsoft. Da ändert es auch nichts dran, ob GTK# in Version 1.0 oder 0.15 ist.
Aber generelle Aussagen über die Stabilität eines Produktes anhand der Versionsnummer sind schwachsinn. Wenn du so etwas behaupten willst, dann leg Beweise vor!
was mich nervt is das alle diese projekte sagen was sie tolles können... aber selten was sie nich können
dann arbeitet man sich da ein, will es einsetzen und stoßt an irgendne kaum optimierte leistungsgrenzeund das passiert bei der MFC nicht? Marc++us hat doch schon ein Beispiel genannt, so wie Buttons mit Icons etc.
-
ich hab nich behauptet dasses bei der mfc ned so is
aber da weiss ich wenigstens was für programme schon damit geschrieben worden sind und aus welcher leistungsklasse die stammenbzgl. Wahrscheinlich sind eben nur noch nicht alle GTK Features gewrapped.
na also dann kann man auch noch nich ordentlich damit arbeiten
ich hab nich behauptet dasses schlecht ist... es is einfach nich die alternative schlechthin... eigentlich isses noch garkeine alternative