Softwareentwicklung!
-
Genau das was asdfasdf geschrieben hat meine ich damit!
Naja also eine Grafische Oberfläche liegt mir sehr am Herzen.
Also wenn jetzt die Firma halt auf .NET setzt, empfiehlst du mir das Visual Studio inklusive Compiler oder was?Was für möglichkeiten gibt es denn noch in der Anwendungsentwicklung?
-
asdfasdf schrieb:
Microsoft Compiler unterstützen zum Beispiel kein aktuelles Standard C. Das reicht schon um ihn nicht für C-Projekte einzusetzen. Nicht alles was teuer ist ist auch brauchbar.
Dem Text nach ging es hier um C++, und da gehört der neue C-Standard auch gar nicht dazu.
-
sch0tti schrieb:
Genau das was asdfasdf geschrieben hat meine ich damit!
Wie gesagt: Der aktuell gültige C++ Standard enthält nicht C99!
sch0tti schrieb:
Naja also eine Grafische Oberfläche liegt mir sehr am Herzen.
Soll die Oberfläche möglichst viel Schnickschnack anbieten, oder reicht dir eine rudimentäre Oberfläche. Soll sich die Oberfläche in das jeweilige Betriebssystem einpassen? Wie wichtig ist dir eine Internetanbindung oder gar Weboberfläche? Wie wichtig ist dir Portabilität? Soll die Oberfläche schnelle Grafiken erlauben...
sch0tti schrieb:
Also wenn jetzt die Firma halt auf .NET setzt, empfiehlst du mir das Visual Studio inklusive Compiler oder was?
Wenn eine Firma .Net einsetzt, und du daher .Net einsetzen willst, rate ich grundsätzlich von C++ ab. C++/CLI ist nur in sehr wenigen Bereichen zu empfehlen. Dann greif gleich zu C#.
Und für C# rate ich ganz eindeutig zu den Microsoftprodukten (Die übrigens auch kostenfrei als Expressversionen existieren).
sch0tti schrieb:
Was für möglichkeiten gibt es denn noch in der Anwendungsentwicklung?
Was siehst du bitte als Anwendungsentwicklung?
Unter Anwendungsentwicklung zähle ich alles, was nicht in die Systemnahe Programmierung zählt. Seien es kaufmännische Anwendungen, Spiele...
Wenn ich beispielsweise ERP-Systeme etc. betrachte würde ich inzwischen entweder zu C# oder Java greifen, da einerseits das Internet wichtiger wird, und vieles in diesen beiden Sprachen die Entwicklungszeit massiv verkürzt. Und für Unternehmen ist die Entwicklungszeit eines der wichtigen Themen, gerade bei komplexen Projekten.
Bei der Software, an der ich mitarbeite (und die schon seit etwa 10 Jahren im Einsatz ist), ist wiederum Internet kaum ein Thema. Wir haben zwar einen HTML-Export (inkl. FTP-Anbindung) für das publizieren der Ergebnisse, die Nachfrage nach einer interaktiven Internetschnittstelle ist derzeit aber eher gering. Wobei Internet eher mal nachgefragt wird (wenn auch nur als "nice-to-have" als z.B. andere Betriebssysteme [Wir hatten bislang in den 10 Jahren 2 Anfragen zu MacOS und eine zu Linux], weshalb Portabilität für uns auch keinerlei Rolle spielt.
-
Hm naja also hälst du von C++ ab oder was?
Man kann C++ für das Web einsetzen?Naja also ich finde es sollte schnell Grafikenladen können und möglichst
vielfältig sein wenns ums Layout des Frames geht!
-
sch0tti schrieb:
Naja also ich finde es sollte schnell Grafikenladen können und möglichst vielfältig sein wenns ums Layout des Frames geht!
Man merkt eindeutig das du von Delphi kommst. Wenn du Oberflächen wie beim Delphi zusammenklicken willst, solltest du dir wirklich den C++ Builder* oder z.B. den QT-Creator (oder wie der heißt) anschauen (Oder z.B. die Designer anderer Sprachen).
* Wobei ich von diesen mehr als genügend Negatives kenne (Ich programmiere beruflich derzeit mit dieser IDE). Dir wird er zwar leicht fallen weil die VCL aus Delphi stammt, aber dafür fehlen z.B. Refactoringtools, das CodeInsign (Codevervollständigung usw.) legen teilweise den Builder für mehrere Minuten lahm etc. (Und Embaccadero scheint kaum ein Interesse am C++ Builder zu haben, die Neuigkeiten halten sich in der Regel doch stark in Grenzen). Es gibt hier einige die das sicherlich anders sehen, aber für mich ist der C++ Builder ein totes Pferd, was nur zu Faul zum Umfallen ist.
Völlig davon abgesehen das du zum Lernen von C++ erst einmal die UI gänzlich vergessen solltest! Unter C++ ist die Einarbeitung in ein UI-Framework in der Regel erst sinnvoll, wenn man die Sprache grundsätzlich schon einmal beherrscht. Das liegt auch daran das es keine Standard-UI unter C++ gibt.
sch0tti schrieb:
Hm naja also hälst du von C++ ab oder was?
Man kann C++ für das Web einsetzen?1. Ich rate nicht von C++ ab (ich programmiere schließlich auch vorrangig seit 10 Jahren beruflich mit C++), sondern sage, das man die Wahl der Sprache auch von der Zielsetzung abhängig machen muss.
2. C++ kann man durchaus (wenn auch imho weniger gut) für das Web einsetzen. Stichworte hierbei sind CGI und tntnet, letzteres wird unter anderem von einen der hier im Forum aktiven mitentwickelt.
Wenn man aber eine Sprache für Web und Clientanwendungen haben will, mit je nach Sprache auch noch ähnlichen Bibliotheken (z.B. C# mit WPF auf der einen und Silverlight auf der anderen, die programmiertechnisch recht nahe sind) würde ich zu Java oder C# raten.
-
asc schrieb:
Es gibt hier einige die das sicherlich anders sehen
In der Tat.
asc schrieb:
* Wobei ich von diesen mehr als genügend Negatives kenne (Ich programmiere beruflich derzeit mit dieser IDE). Dir wird er zwar leicht fallen weil die VCL aus Delphi stammt, aber dafür fehlen z.B. Refactoringtools, das CodeInsign (Codevervollständigung usw.) legen teilweise den Builder für mehrere Minuten lahm etc. (Und Embaccadero scheint kaum ein Interesse am C++ Builder zu haben, die Neuigkeiten halten sich in der Regel doch stark in Grenzen). Es gibt hier einige die das sicherlich anders sehen, aber für mich ist der C++ Builder ein totes Pferd, was nur zu Faul zum Umfallen ist.
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.
Im Übrigen investiert Embarcadero in C++Builder und Delphi etwa gleichermaßen (das C++-Compiler-Team ist z.B. sogar etwas größer als das Delphi-Pendant), Neuerungen gab es nicht weniger als für Delphi. Und nur weil du nicht darüber im Bilde ist, heißt das noch lange nicht, daß sich nichts tut. Ich will dich natürlich in keiner Weise hindern, deine Meinung lautstark zu verbreiten - aber derart uninformierte Polemik scheint mir nicht allzu hilfreich.
-
danke
-
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. Oder wenn ich Anfange etwas zu tippen nur das erste Zeichen ankommt, die IDE dann erst einmal eine längere Denkpause einlegt und im schlimmsten Fall die restliche Eingabe einfach nicht annimmt.
Ich habe kein Problem damit, wenn er etwas nicht sofort analysieren kann, nur darf er dann nicht einfach die IDE komplett in einen Wartezustand verfrachten.
Besonders schlimm (aber dies ist erst wegen einer geplanten Umstellung so) wird das ganze noch, wenn man gezwungen ist, den C++ Builder in einer VM einzusetzen - aber leider habe ich, und nicht nur ich, die Probleme auch außerhalb der VM. Und zwar erhöht die VM logischerweise noch die Zeit, aber das ändert nichts daran das es nicht nur in der VM so ist (Die Maschine ist eine 6-Kern Maschine mit 4 GB Arbeitsspeicher und einem RAID-5 System, so das ich das System nicht dafür verantwortlich mache - Nachtrag: Außerhalb der VM habe ich den C++ Builder 2010, innerhalb einer VM den C++ Builder 2007 - unter beiden kann ich das Verhalten konstruieren).
Mein Chef hat die Probleme aber tatsächlich nicht, da er CodeInsign deaktiviert hat. Meine Kollegin hat aber die gleichen Probleme, und kennt wie ich auch mehrere andere IDEs, in denen dies beileibe unproblematischer ist (Und da sie sich nicht mit den C++ Spezialitäten auskennt, ist ihre Programmierung jedenfalls nichts, was die ewigen Wartezeiten erklärt).
audacia schrieb:
Im Übrigen investiert Embarcadero in C++Builder und Delphi etwa gleichermaßen (das C++-Compiler-Team ist z.B. sogar etwas größer als das Delphi-Pendant), Neuerungen gab es nicht weniger als für Delphi.
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 (Auch nicht unter dem 2010; den XE habe ich mir noch nicht angeschaut).
Zudem geht es mir um die Dinge, die bei der Arbeit die Zeit unnötig erhöhen. Und für mich gehört eine akzeptable Codevervollständigung und zumindest grundlegende Refactoringwerkzeuge inzwischen zu einer IDE, zumindest bei einem schon recht "teuren" Produkt.
audacia schrieb:
Und nur weil du nicht darüber im Bilde ist, heißt das noch lange nicht, daß sich nichts tut. Ich will dich natürlich in keiner Weise hindern, deine Meinung lautstark zu verbreiten - aber derart uninformierte Polemik scheint mir nicht allzu hilfreich.
Ich bin zwar nicht in der C++ Builder Entwicklung so tief drin wie du, schaue mir aber durchaus auch mal die neueren C++ Builder an, und prüfe wie gut sie in den Punkten geworden sind, die uns hauptsächlich stören.
-
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.