Softwareentwicklung!
-
Wenn Du GUI's programmieren willst, dann loes Dich von dem "C++ Lernen" !
Egal welche GUI DU hernimmst, keine erlaubt dir so "richtig gut" C++ zu programmieren. Alles was Du mühevoll an guten Design für C++ aneignest/angeeignet hasst, kannst Du bei GUIs vergessen. Die GUI Biblios muessen sich viel zu sehr dem BS-API oder dem drunterliegenden Framework beugen (XServer, GTK, Motif ... )
Beispiel:
MFC - ist C-Programmieren mit paar Objecten. Iss halt wirklich nur nen dünner Wrapper um eine C-Schnittstelle (Win32-API).
QT - hat mehr mit Java Programmierung zu tun als mit C++ (Stichwort: selbstloeschende Objecthirarchien, implizietes sharing ... )Anders sieht es z.b. mit GUI-freien modulen und Consolen-Anwendungen aus. Da hasst mehr freiheiten um besseres c++ programmieren zu koennen.
Praxis:
Viele Projecte sind in c++ geschrieben, nicht weil c++ dafuer perfekt waer, sondern weil die Programmierer-ressourcen dafuer vorhanden sind.
GUIs wuerde man bestimmt besser mit ner anderen Sprache schreiben koennen, aber Programme nur aus GUI's sind seltener.
Wenn man soweiso lowlevel in c++ programmieren muss, und meist das selbe team dann auch fuer die GUI zustaendig ist ... wird man die GUI auch gleich in c++ machen.Bei Projecten wo sich die GUI haeufig aendert, bzw mehrere GUIs fuer unterschiedliche Plattformen benoetigt werden, bzw web-guis nen thema sind, faehrt man meist besser die GUI abzutrennen und in ner anderen Sprache zu implementieren.
Firmen haben ned so oft die Wahl um perfekt wählen zu koennen! Man hat Programmiererressourcen, die meist auf eine Zielplattform ausgerichtet sind, und man hatt "Haus-Standards".
Beispielsweisse:
Datenbank backend - immer Oracle
GUI Framework - immer .Net / MFC (da M$ first level partner)
...C++ iss halt das vielseitigste durch seine vielen Bibliotheken. Und es deckt performanceanforderungen halt gut ab ... das macht es ein bissi universell, auch wenn in bestimmten anderen bereichen der Entwicklungsaufwand eben höher wird ...
Ciao ...
-
hier (in deutschland) gibts ÄÖÜäöüß und weitere sonderzeichen. könntest die beim nächsten mal verwenden? danke
-
Ich bin Programmierer, kein Deutsch-Lehrer
Und ich steh dazu!
Als Ich noch lernfähig(er) war, konnte weder meine Tastatur noch mein Compiler (in dem Ich zugegebener Maßen auch deutsche Texte als Kommentare eingepflegt habe) so ein Schnickschnack :p
Und nach diesen tollen Rechtschreib-Reformen find ich, tut dieses ae statt ä z.b. weniger weh wie einige der neuen Schreibweisen.
Wenn ich meine Muttersprache noch mal neu wählen könnte, würd ich eher was stabileres und mit einer eindeutigereren Syntax(Grammatik) wählenIch hoffe Ihr habt ein bisschen Nachsicht!
Ciao ...
-
Gibt es echt noch Leute die mit dem C++ Builder arbeiten müssen?
-
SchrottBuilder schrieb:
Gibt es echt noch Leute die mit dem C++ Builder arbeiten müssen?
Der C++ Builder wird durchaus noch eingesetzt. Und grundsätzlich halte ich ihn auch nicht für schlecht (wohl aber fehlen ihm imho zu viele Features, sei es bezogen auf die Sprache C++ oder die Produktivität jenseits der RAD-Oberfläche).
-
ihr habt doch alle keine ahnung
-
asc schrieb:
audacia schrieb:
Es ist alles auch eine Frage, wie man mit den Tools arbeitet. C++Builder kann sehr produktiv sein, wenn man ihn richtig einzusetzen weiß. Und Code Completion kann auch sehr performant funktionieren, wenn man die Anleitung liest und sich an die Regeln hält.
Ach so, also ist das ein Fehler des Einsatzes, wenn eine zufällige Mausbewegung über den Code die IDE teilweise für eine halbe Minute lahmlegt.
Das passiert, wenn du
- keine vorcompilierten Header verwendest (für die gibt es seit C++Builder 2009 einen Wizard)
- allzu viele Header-Abhängigkeiten in einzelnen Quelldateien kumulierst.asc schrieb:
Und für mich gehört eine akzeptable Codevervollständigung und zumindest grundlegende Refactoringwerkzeuge inzwischen zu einer IDE
Das dachte ich auch, bis ich Visual C++ 2010 gesehen habe (kein IntelliSense für C++/CLI
).asc schrieb:
Es mag sein, das die Investitionen und die Neuerungen nicht weniger sind, wenn aber die Punkte die man an dem Compiler bemängelt, sich nicht im geringsten geändert haben
Der Compiler ist tatsächlich ein Problem. Das Frontend ist strukturell nicht in der Lage, die Grundlage für 2-way-Features wie Modeling oder Refactoring zu liefern, und das Backend ist in der Codegeneration nicht besonders zeitgemäß. Insbesondere erschwert die Tatsache, daß die Infrastruktur des Delphi-Compilers nicht mit dem C++-Compiler übereinstimmt, die Interaktion der beiden Compiler. Weiter ist es - die Bemühungen der letzten Jahre haben es gezeigt - zwar möglich und mittlerweile wieder recht erfolgreich, einen Compiler, der in den Grundlagen noch auf Turbo C basiert, zu einem hinreichend konformen C++-Compiler zu machen, jedoch erfordert das Ressourcen, die man gut in anderen Bereiche (etwa in der IDE) brauchen könnte.
Embarcadero ist sich dessen bewußt, und deshalb arbeitet man an der Ablösung des althergebrachten BCC-Frontends. (Das Backend bekommt durch die Mac- und 64-Bit-Pläne ohnehin eine Überarbeitung.) Auf der Delphi Live sagte Michael Swindell, daß man die Verwendung eines externen Frontends (natürlich um die Borland-Spracherweiterungen angereichert) beabsichtige.
-
audacia schrieb:
asc schrieb:
Ach so, also ist das ein Fehler des Einsatzes, wenn eine zufällige Mausbewegung über den Code die IDE teilweise für eine halbe Minute lahmlegt.
Das passiert, wenn du
- keine vorcompilierten Header verwendest (für die gibt es seit C++Builder 2009 einen Wizard)
- allzu viele Header-Abhängigkeiten in einzelnen Quelldateien kumulierst.Vorkompilierte Header verwenden wir, letzteres ist leider meinem Chef zu verdanken.
audacia schrieb:
asc schrieb:
Und für mich gehört eine akzeptable Codevervollständigung und zumindest grundlegende Refactoringwerkzeuge inzwischen zu einer IDE
Das dachte ich auch, bis ich Visual C++ 2010 gesehen habe (kein IntelliSense für C++/CLI
).Gegen C++/CLI spricht ohnehin sehr viel, wobei ich das Fehlen tatsächlich als peinlich ansehe. Unter C++ selber habe ich aber keinerlei Probleme.
audacia schrieb:
asc schrieb:
Es mag sein, das die Investitionen und die Neuerungen nicht weniger sind, wenn aber die Punkte die man an dem Compiler bemängelt, sich nicht im geringsten geändert haben
...Embarcadero ist sich dessen bewußt, und deshalb arbeitet man an der Ablösung des althergebrachten BCC-Frontends.
Dann sollte Embarcadero aber dies auch deutlicher zeigen. Einzelne Veranstaltungen werden nicht wirklich von vielen wahrgenommen. Und selbst wenn: das Problem existiert jetzt, und auch schon die letzten Jahre, ohne wesentliche Besserung. Ist ja nicht so, das dieses Problem nicht längere Zeit bekannt war, und die Frage ist einfach: wie lange ist man bereit zu warten?
-
asc schrieb:
Vorkompilierte Header verwenden wir
Wie? Habt ihr einfach nur den Switch aktiviert, oder habt ihr mal den PCH-Wizard einen PCH erstellen lassen?
audacia schrieb:
das Problem existiert jetzt, und auch schon die letzten Jahre
Offenbar existiert aber die Lösung noch nicht so lange.
-
audacia schrieb:
asc schrieb:
Vorkompilierte Header verwenden wir
Wie? Habt ihr einfach nur den Switch aktiviert, oder habt ihr mal den PCH-Wizard einen PCH erstellen lassen?
Da dieses Projekt schon viele C++ Builder hinter sich hat, mag der Aufbau nicht dem aktuellen Stand entsprechen (Es läuft über einen selbstgepflegten Header der in den Projekteinstellungen entsprechend angegeben wurde). Sobald das Projekt in seiner Gänze auf den 2010er Builder portiert werden konnte, habe ich aber auch vor dies mal probeweise zu ändern (Bzw. das Projekt mal im ganzen neu aufzubauen).
Die Probleme hatte ich aber auch schon in einigen kleineren Projekten (z.B. den zu überarbeitenden Komponenten, wovon ein paar C++ Projekte sind - hier kann ich aber nicht garantieren welche Einstellungen in den Projekten stehen, da es mir nur um die Anpassungen von 2007 auf 2010 ging).
-
audacia schrieb:
Embarcadero ist sich dessen bewußt, und deshalb arbeitet man an der Ablösung des althergebrachten BCC-Frontends. (Das Backend bekommt durch die Mac- und 64-Bit-Pläne ohnehin eine Überarbeitung.) Auf der Delphi Live sagte Michael Swindell, daß man die Verwendung eines externen Frontends (natürlich um die Borland-Spracherweiterungen angereichert) beabsichtige.
So sehr ich mir einen neuen Compiler für den BCB wünsche, weil damit wieder eine Alternative zu Visual Studio entstehen könnte, die er im Moment einfach nicht ist, fürchte ich die neuen Entwicklungen doch etwas.
Die Erfahrung mit dem C++ Builder X hat doch gezeigt, dass die Anwender, die auch mit anderen Compilern und IDEs vertraut sind und relativ VCL unabhängigen Code haben, schnell wechseln können.
Geblieben sind doch vor allem Anwendungen und Anwender mit enger Bindung an die VCL. Ein neuer Compiler und Crossplattform-Erweiterungen in den Bibliotheken bedeuten dort ein großes Risiko für Kompatibilitätsprobleme.
Die erste Gruppe, glücklicherweise gehöre ich dazu, wird nach den Erfahrungen mit Kylix und dem CBX erstmal abwartend zusehen, wie sich das Spektakel entwickelt.
Die zweite wird auch sehr konservativ an die Sache herangehen.
Beides zusammen sind Risiken für die Umsätze, die mit dem neuen Produkt gemacht werden. Und mangelnde Einnahmen waren die Gründe für das Ende von Kylix und CBX...
-
nn schrieb:
Ein neuer Compiler und Crossplattform-Erweiterungen in den Bibliotheken bedeuten dort ein großes Risiko für Kompatibilitätsprobleme.
Das stimmt. Entgegen den damaligen Versuchen, eine compilerunabhängige IDE (C++BuilderX) und einen neuen modernen Compiler (der experimentelle BCC v6.0 mit EDG-Frontend; er konnte sogar
export template
) zu erstellen, ohne groß auf Abwärtskompatibilität zur VCL und den BCC-Spracherweiterungenzu achten, soll die kommende Modernisierung des Compilers sehr evolutionär gehalten werden. Natürlich wird man ein wenig zu kämpfen haben, wenn das neue Frontend die Marotten des BCC nicht durchweg imitiert. Aber ich glaube nicht, daß sich das als ein signifikantes Problem erweisen wird; viel gravierender sind da andere Faktoren, beispielsweise die Frage: was bekommt man dafür? Und da tun sich mit einem geeigneten Frontend ungeahnte Möglichkeiten auf.nn schrieb:
Die erste Gruppe, glücklicherweise gehöre ich dazu, wird nach den Erfahrungen mit Kylix und dem CBX erstmal abwartend zusehen, wie sich das Spektakel entwickelt.
Klar. Ich würde vermutlich auch eine Weile warten, bevor ich die Crossplatform-Bibliothek, die für Delphi und C++Builder geplant ist, produktiv einsetze - die Erfahrung mit Kylix gemahnt hier zur Vorsicht.
Andererseits sollte man berücksichtigen, daß die Umstände bei Kylix etwas anders waren. Es gab dazu von Michael Swindell, Allen Bauer und anderen ausführliche Kommentare in den Newsgroups, die ein wenig Licht ins Dunkel der Kylix-Geschichte warfen: während Kylix bei weitem nicht den Umsatz von Delphi oder C++Builder erreicht habe, sei es durchaus rentabel gewesen, und als wesentliches Problem sei geblieben, daß das Borland-Management nicht bereit gewesen sei, das R&D-Budget derart aufzustocken, daß sowohl Delpi/C++Builder als auch Kylix parallel entwickelt hätten werden können. Um das Kerngeschäft nicht zu gefährden, wurde dann entschieden, Kylix bis auf weiteres auf Eis zu legen und sich auf Delphi und C++Builder zu konzentrieren. Insofern ist die Behauptung
nn schrieb:
Und mangelnde Einnahmen waren die Gründe für das Ende von Kylix
nicht ganz richtig.
-
audacia schrieb:
Das passiert, wenn du
- keine vorcompilierten Header verwendest (für die gibt es seit C++Builder 2009 einen Wizard)
- allzu viele Header-Abhängigkeiten in einzelnen Quelldateien kumulierst.Ich benutz zwar kein C++ Builder, aber für mich hört sich das eher nach einem designfehler an. Schließlich schaffen andere IDEs sowas auch problemlos. In IntelliJ hab ich die ganze JRE Klassenbibliothek + alles im aktuellen Projekt immer verfügbar per Autovervollständigung, auch ohne imports. Kein Grund dass das dann im C++ Builder nicht funktionieren sollte.
-
C/C++ Forum __ Rund um d schrieb:
Ich benutz zwar kein C++ Builder, aber für mich hört sich das eher nach einem designfehler an. Schließlich schaffen andere IDEs sowas auch problemlos.
Ist es auch, selbst unter C++ gibt es IDEs die besser mit den Daten umgehen können, trotz entsprechener Einschränkungen. Und ich kenne weit größere Projekte (unseres liegt aktuell bei etwa 185.000 Codezeilen).
Ein Vergleich mit einer IDE & Sprache die Reflection unterstützt ist aber nicht sinnvoll, da dies schlicht und ergreifend andere Möglichkeiten erlaubt. Die Analyse von C++ Code ist komplexer.