Wer von Euch verwendet Eclipse CDT für C/C++ Projekte und wie ist Eure Meinung dazu?
:
Verschoben durch Admin
Spinnerter Müll. Kann man, so man genügend schmerzfrei ist, zuviel Geld und Zeit, oder ggf. keine andere Wahl hat EVENTUELL einsetzen. Aber in ernsthaften Projekte ist es eine Quälerei und nur in sehr begrenztem Maße zu gebrauchen. Ich denke gerade bei der Wahl der Arbeitsmittel sollte man auf den Nutzen achten. Klump
Klump schrieb: > Spinnerter Müll. Deine Antwort? Ja, kommt mir auch so vor. > zuviel Geld Eclipse kostet keinen Cent. Okay die Geschwindigkeit ist wirklich nicht berauschend. Da schneiden in C++ geschriebene IDEs definitiv besser ab. Für lau kann man aber eben auch nicht alles erwarten. Die Erweiterbarkeit ist sehr gut. Außer Eclipse verwende ich noch Notepad++ und vi. Old school! ;-)
Ich finde IDE's sind irgendwie für Daus. Benutzen für Projekte Sublime-Text als Editor, GCC+GDB, Make und Git. Was braucht man mehr ?
Kauming schrieb: > Ich finde IDE's sind irgendwie für Daus. Das kommt doch vollkommen auf die Art des Projekts an. Meinst du, dass irgendwo in großen Unternehmen mit Sublime-Text etc. programmiert wird? IDE heißt ja nicht, dass man durch drücken von Buttons seinen Programmcode zusammensetzt.
IDEs von Compilerherstellern können schon vieles mehr, was man sich in Eclipse erst mühselig selber schreiben muss.
Für GCC Derivate klappt das ja einigermaßen mit Eclipse, aber für sonstige Compiler ist es meist Gefrickel. Auch die Projekt-Erstellung ist meist gruselig und mit viel Handarbeit verbunden.
Schwierigkeiten machen gerade auch die alten Plugins, weil mit der neuen Eclipse 4 die Extension Points nicht mehr funktionieren :-(
Ich habe mal eine Zeit lang mit Eclipse C++ programmiert und es war nicht besonders angenehm. Das ist aber jetzt ein paar Jahre her und ich weiß nicht mehr, wo genau die Probleme lagen und ob sich das inzwischen gebessert hat. Deshalb war ich skeptisch, als ich Java mit Eclipse programmieren sollte. Das geht aber damit deutlich besser.
Hallo zusammen Ich habe eine Zeit lang mit Eclipse C Programmiert. Die GUI ist wirklich gut aufgebaut und man findet sich nach kurzer Einarbeit gut zurecht. Man hat eine Konsole, in der man ein Terminal Programm gleich ausführen kann. Der Quellcode ist farblich hinterlegt und Klammernpaare werden gleich als Gruppe angezeigt und können ggf. auch geschlossen werden. Eclipse kommt mit diversen Compiler klar. Ich habe jedoch immer den GNU GCC verwendet. Alles in allem ist GCC für Einsteiger und vortgeschrittene eine Gute Wahl. Seit ich nun öfters mit Solaris 10 arbeite habe ich angefangen mit dem Texteditor zu Programmieren und direkt in der Konsole zu Compilieren. Daher mache ich es nun auch unter Linux so. Gruss Ferenc
Ich finde den Qt-Creator (auch für nicht Qt Projekte) deutlich gelungener, übersichtlicher, schlanke und schneller. Und der ist auch für lau...
Ich schreibe ja meine makefiles auch selbst. Aber wieso sollte ich deswegen auf Komfort verzichten? Eclipse ist die Rundum-Sorglos Lösung. Eine IDE für sämtliche Programmiersprachen mit einem einheitlichen (Compilerunabhängigen) Look & Feel. In der Firma setzen wir btw. auch auf Eclipse, im Hintergrund werkelt der Green Hills Compiler. Dessen IDE (MULTI) ist einfach nur schrecklich.
Ich hab Eclipse damals in der Uni als portable IDE verwendet. Der Start war langsam aber zur Laufzeit fande ich es nicht zäh. Lediglich das Debugging ging ziemlich schlecht (war allerdings unter Windoofs mit Mingw). Wenn man aus Versehen in ein printf reinstepte, hing sich teilweise das Debugging auf. Man musste dann das Programm von vorn debuggen. So sehr ich Kleinweich nicht mag: Visual Studio mit einigen Extensions ist schon sehr komfortabel. Wenn man dann für die kommerzielle Entwicklung noch Tools wie Resharper (für Cpp gibts irgendwas mit Tomaten) einsetzt, geht es richtig ab.
Nutze Eclipse seit vielen Jahren, u.a. für C mit avr-gcc. Finde die IDE sehr gut. Auch im Vergleich zu VS oder NetBeans. Die Plugins für den AVR und für Subversion (Subclipse) sind für mich die wichtigsten (nach CDT natürlich für C). Auch damit bin ich sehr zufrieden. gruß cyblord
Hier verwenden wir Eclipse ebenso, bisher für AVRs, jetzt praktisch nur noch für STM32. Aber auch Tcl-Code lässt sich damit gut schreiben. Einarbeiten muss man sich überall und mit Eclipse haben wir ein Werkzeug für alle Programmieraufgaben. Das ist einfach praktisch.
pks schrieb: > Ich finde den Qt-Creator (auch für nicht Qt Projekte) deutlich > gelungener, übersichtlicher, schlanke und schneller. Und der ist auch > für lau... Das ist ja auch nur ein Eclipse untendrunter. Wie bei vielen anderen IDEs auch (Android und TI fallen mir ein). Max
Max G. schrieb: > pks schrieb: >> Ich finde den Qt-Creator (auch für nicht Qt Projekte) deutlich >> gelungener, übersichtlicher, schlanke und schneller. Und der ist auch >> für lau... > > Das ist ja auch nur ein Eclipse untendrunter. Wie bei vielen anderen > IDEs auch (Android und TI fallen mir ein). > > Max Und da bist Du sicher? Ich würde jetzt mal erwarten, dass der mit Qt/C++ implementiert ist. Und Eclipse ist doch Java!?
pks schrieb:
> Und Eclipse ist doch Java!?
Mein Orakel sagt etwas anderes. Es schwört auf NetBeans für Java. Die
Bohnen hab ich schon ausprobiert, war für meinen Bedarf nichts. Viel zu
aufgeblasen, nur um einen Compiler oder ähnliches aufzurufen. Das geht
mit einer einfachen Batchdatei auch. Aber wenn hier so viele Eclipse gut
finden, dann werde ich es mal testen. Ich hoffe, daß Download und
Installation nicht den halben Tag dauern, wie bei den Bohnen.
Naja, Eclipse ist nicht ganz schlecht, aber die Lernkurve ist zumindest für C++ recht steil. Installiert werden muss es zum Glück gar nicht. Download geht meist sehr schnell.
Für Kleinigkeiten nehme ich Notepad++, aber wenn's etwas größer wird kommt eclipse zum Einsatz. So Sachen wie Refactoring oder einfach nur die Suche nach einer globalen Variable in allen Sourcedateien des Projektes mit einem einzigen Shortcut vereinfachen die Arbeit schon ganz schön (vor allem bei fremden Code). Wer bbehauptet eclipse sei langsam hat entweder ein paar Jahre geschlafen, einen steinalten Rechner oder verwechselt IDE mit Editor. Wer was langsames sehen will, sollte sich Visual Studio anschauen - und das kann auch nicht wirklich mehr als eclipse (ich rede von der IDE, nicht von Compiler, Framework, etc.).
Martin schrieb: > Wer bbehauptet eclipse sei langsam hat entweder ein paar Jahre > geschlafen, einen steinalten Rechner oder verwechselt IDE mit Editor. > Wer was langsames sehen will, sollte sich Visual Studio anschauen - und > das kann auch nicht wirklich mehr als eclipse (ich rede von der IDE, > nicht von Compiler, Framework, etc.). Also bei meinen Tests auf dem selben System (Sandy Bridge Notebook, Linux, 4gb RAM) empfand ich Eclipse als relativ langsam. Dagegen getestet habe ich NetBeans und QTCreator. NetBeans war leicht zügiger zu Bedienen als Eclipse und von der Bedienung her kommt es Eclipse etwa gleich. (Finde persönlich beides nicht optimal) Mit QTCreator bin ich zur Zeit glücklich. Läuft zügig, integrierte Dokumentation, übersichtliche Oberfläche. Das ein oder andere nützliche Feature aus Eclipse fehlt zwar, ist aber meiner Meinung nach durch die (für mich) bessere Bedienbarkeit ausgeglichen. Getestet wurden immer die aktuellen Versionen aus dem standard Arch Linux Repo mit den entsprechenden C++ Plugins. Visual Studio lief auf dem selben System unter Windows 7 etwas langsamer, aber das kann auch an dem Windows selbst liegen (kein Test der anderen IDE dort), aber vom Prinziep ist das auch benutzbar. Auf einem älteren Rechner mit P4 Prozessor konnte ich mit Visual Studio 2008 zwar etwas betaglich aber doch gut ein Projekt entwickeln. So long
Zelmi schrieb: > Wer von Euch verwendet Eclipse CDT für C/C++ Projekte und wie ist Eure > Meinung dazu? Ich persönlich benutze Eclipse nur für JAVA (naja ist eher eine Vorgabe) im Android Umfeld. Für C(++) nutze ich Code::Blocks ist finde ich wesentlich zügiger und selbsterklärender. Für kleine Programme gerne auch der Texteditor und die Konsole, aber bei Programmen mit mehreren Klassen und Dateien ist mir eine IDE lieber. Da habe ich dann schnell alle Dateien im Blick ohne die Taskleiste zu zumüllen. Nachher dann natürlich makefiles selber (muss ja irgendwie die RPM und DEB bauen). MfG
Kauming schrieb: > Ich finde IDE's sind irgendwie für Daus. Benutzen für Projekte > Sublime-Text als Editor, GCC+GDB, Make und Git. Was braucht man mehr ? Darf ich raten, du trägst eine Goldkette und fährst Opel Manta? Bist ja ein richtig harter SW-Cowboy.
Drosophila schrieb: > Kauming schrieb: >> Ich finde IDE's sind irgendwie für Daus. Benutzen für Projekte >> Sublime-Text als Editor, GCC+GDB, Make und Git. Was braucht man mehr ? > > Darf ich raten, du trägst eine Goldkette und fährst Opel Manta? > Bist ja ein richtig harter SW-Cowboy. Ne das isn Frickel-Nerd der nie produktiv Entwickeln kann. Leute die mit modernen Tools nicht klar kommen. Kenn ich zuhauf. Alles außer Kommandozeile ist für DAUs. Auslachen und weitergehen. So handhabe ich das.
@Chris D. (myfairtux) (Moderator) >Hier verwenden wir Eclipse ebenso, bisher für AVRs, jetzt praktisch nur >noch für STM32. Aber auch Tcl-Code lässt sich damit gut schreiben. Ich habe erfolglos versucht, eine aktuelle Windows Eclipse-IDE für den STM32F4 (inkl. debugging via SWD) aufzusetzen. Dabei habe ich schon verschiedene Anläufe unternommen, aber die diversen Beschreibungen im Web (auch bei Mikrokontroller.net) sind entweder fehlerhaft, inkonsistent, unvollständig und/oder veraltet (bzw. funktionieren nicht mehr mit den aktuellen Paketen) Wer kann mir eine Kombination bzw. Setup-Variante (Reihenfolge) angeben, die auch tatsächlich funktioniert bzw. welche Pakete braucht es wirklich bzw. passen zueinander? -Eclipse mit CDT? (Juno? Helios? Keppler? welche Zusatzpakete) -Eclipse Plugin für ARM? (notwendig, nützlich oder störend?) -Compiler? Der offizielle gcc-arm-none-eabi-V..? Yagarto? Oder..? -Compilieren + linken: Automatische Makefiles? CPU-Typ definieren etc..? -Programieren+Debuggen (J-Link GDB-Server? oder SWD? wie einrichten?) Ich habe mir auch CoCoox angeschaut, klappt zunächst recht gut aber leider haben die CoCoox-Macher das dahintersteckende Eclipse regelrecht kastriert: Es fehlen viele praktische Feautures+Menues: (Mehrere Projekte im Projekt-Explorer, Anpassung der Synthax/Darstellung/Keywörter, das Handling von Projektverzeichnissen ist eine Zumutung, etc-etc)
Oder lohnt es sich, auch mal emIDE auszuprobieren? Wer hat hier noch Erfahrung gesammelt? Beitrag "Neue Toolchain emIDE" p.s. Der verlinkte Thread stammt von einem anderen Mike, nicht von mir! ;o)
Ja, lohnt sich auf jeden Fall, vor allem weil anscheinend gerade noch stark daran weiterentwickelt wird und viele tolle neue Features ständig dazu kommem. Aber selbst in dem jetzigen Zustand finde ich das besser als Eclipse.
Echt lustig, auch Jahre später stelle ich immer noch viele Probleme in Eclipse CDT fest und dieselben bekannten Bugs werden/können einfach nicht gefixt werden.
Darth Vader schrieb: > Echt lustig, auch Jahre später stelle ich immer noch viele Probleme in > Eclipse CDT fest und dieselben bekannten Bugs werden/können einfach > nicht gefixt werden. Doch, Du kannst einen Bug auch selbst fixen. Open Source macht's möglich.
:
Bearbeitet durch User
Steckt da ei n Entwicklugsprozess hinter wenn ich Eclipse OPen Source Code bugfixe oder wird das einfach von einem Volunter nach 4 Bier übernommen?
Ich habe mit Eclipse eigentlich sehr gute Erfahrungen gemacht. Natürlich kommt bei größeren Projekten der Indexer ins Schwitzen, aber wenn man diesem brauchbare Vorgaben macht dann läuft das Ganze akzeptabel. Aber allein die automatische Vervollständigung, die Anzeige der mittels Doxygen hinterlegten API-Dokumentationen, die Refaktoring-Möglichkeiten und natürlich der Debugger sind eine große Hilfe.
Darth Vader schrieb: > Echt lustig, auch Jahre später stelle ich immer noch viele Probleme in > Eclipse CDT fest und dieselben bekannten Bugs werden/können einfach > nicht gefixt werden. CDT wurde und wird von der HSR Rapperswil entwickelt. Leider ist da seit langem einen Stillstand. Sie sind aber derzeit dabei eine neue Version zu veröffentlichen (Abteilung Peter Sommerlad). Ich habe hier eine Version des neuen CDTs, habe es aber nach kurzem Prüfen wieder verworfen. C11 ist zum Beispiel nicht unterstützt, resp. nicht vollständig. Und das ganze stürzt permanent ab (auf Linux). Sie haben da auch mehrheitlich auf die Unterstützung von scons gesetzt, statt cmake. Für die "Industrie" meiner Meinung nach so nicht zu gebrauchen. Also zurück zu vi, ctags, cmake und die gute alte Konsole. Auch wenn ich gerne eine vernünftige IDE hätte, aber wenn sie mich bei der Arbeit behindert und nicht unterstützt, hilft das nichts. Grüsse, René
Mark Brandis schrieb: > Doch, Du kannst einen Bug auch selbst fixen. Open Source macht's > möglich. Erstmal, ich bin ein großer Anhänger von Freier Software und auch selber engagiert. Das was du hier ablässt ist aber leider nur das übliche Totschlagargument. Das klingt immer alles so romantisch: "Hach, Open Source, jeder kann alles so anpassen wie er will, jeder kann Bugs fixen und Features implementieren." Tatsache ist aber, dass das in der Praxis nicht so ist. Ich selbst kompiliere sehr ungern Anwendungen aus den Sourcen. Denn leider ist da oft der Wurm drin, auch wenn autotools/autoconf verwendet wurden. Oft darf man dann ewig googeln und in (generierten) makefiles rumwurschteln bis das Zeugs mal kompiliert. Ich arbeite beruflich mit C-Buildumgebungen und kann mir deswegen selber helfen. Viele andere, vor allem Hobbyisten dürften sich da wesentlich schwerer tun. Und wenn das Zeugs irgendwie kompiliert ist der Bug ja noch nicht gefixt. Ein Projekt von der Größe von Eclipse muss erstmal überblickt werden, bevor sinnvoll eine Veränderung vorgenommen werden kann. (Klar kann ich auf jegliche Architektur scheißen und irgendwie mit Hilfskonstrukten und globalen Variablen irgendwas hinpfuschen...) Wenn ich an einem Projekt wie Eclipse mitwirken will werde ich mich erstmal Tage oder Wochen einarbeiten müssen. Nein Mark Brandis, du machst es dir schon sehr einfach. Auch wenn etwas umsonst oder "frei" ist darf man Kritik äußern. Dass das Geschwurbel von Darth Vader natürlich keine Kritik sondern Getrolle war steht auf einem anderen Blatt.
Rene H. schrieb: > CDT wurde und wird von der HSR Rapperswil entwickelt. Komisch, weder Rapperswil noch Sommerlad tauchen in der offiziellen Committers-Liste auf: https://wiki.eclipse.org/CDT/whoswho Rene H. schrieb: > Leider ist da seit langem einen Stillstand. Ebenso komisch. In letzter Zeit gab es so alle 6 Monate eine neue Version. Oliver
Oliver S. schrieb: > Rene H. schrieb: > CDT wurde und wird von der HSR Rapperswil entwickelt. > > Komisch, weder Rapperswil noch Sommerlad tauchen in der offiziellen > Committers-Liste auf: > > https://wiki.eclipse.org/CDT/whoswho > > Rene H. schrieb: > Leider ist da seit langem einen Stillstand. > > Ebenso komisch. In letzter Zeit gab es so alle 6 Monate eine neue > Version. > > Oliver Hmm... Ok. Sehe ich. Ok, dann haben sich die Wege wohl getrennt. http://sconsolidator.com
Rene H. schrieb: > Also zurück zu vi, ctags, cmake und die gute alte Konsole Wieso ? Es gibt dutzende gute und supportete IDEs zur C++ Entwicklung, dafür muss man halt bezahlen weil deren Entwickler auch leben wollen. Lieder macht so ein Projekt wie Eclipse die alle kaputt, weil die Meisten doch lieber kostenlos nehmen, egal wie es quält.
MaWin schrieb: > Wieso ? > Es gibt dutzende gute und supportete IDEs zur C++ Entwicklung, dafür > muss man halt bezahlen weil deren Entwickler auch leben wollen. > Lieder macht so ein Projekt wie Eclipse die alle kaputt, weil die > Meisten doch lieber kostenlos nehmen, egal wie es quält. Kannst Du welche nennen? Am Besten etwas, was auch in einer 4000 Mann Firma stand hält. Privat, kaufe ich alles. Das ist nicht das Problem. In der Firma ist das aber ein gedöns. Grüsse, René PS: Ich steh nicht auf Gratis! Ich stehe auf das, dass es funktioniert und mich in meiner Arbeit unterstützt.
MaWin schrieb: > Es gibt dutzende gute und supportete IDEs zur C++ Entwicklung Was haben wir gelacht.
MaWin schrieb: > Es gibt dutzende gute und supportete IDEs zur C++ Entwicklung Jetzt musst aber nachlegen.
:
Bearbeitet durch User
> Jetzt musst aber nachlegen.
Ich habe immer gerne HEW genutzt. Wenn ich mich recht erinnere hat da
die Einzelplatzlizenz 2kEuro gekostet. Ist Renesas aber wohl von
abgekommen weil die ganzen Geizlinge lieber Eclipse benutzen auch wenn
es schlechter und zehnmal langsamer ist.
Olaf
Olaf schrieb: > Ist Renesas aber wohl von > abgekommen weil die ganzen Geizlinge lieber Eclipse benutzen auch wenn > es schlechter und zehnmal langsamer ist. Oder weil sie Insellösungen meiden. Letztens hatte ich z.B. die "Ehre", das erste mal mit MPlab zu arbeiten. Das wird ja immer so gelobt hier. Mein Eindruck war eher gemischt. Es lief zwar alles out-of-the-box, von dem her für einen Einsteiger/Bastler durchaus zu empfehlen. Aber wenn man sich über Jahre hinweg an eine IDE gewöhnt hat die für alle Sprachen und Prozessoren gleich benutzbar ist dann bleib ich doch lieber bei der. Olaf schrieb: > schlechter und zehnmal langsamer - über "gut" und "schlecht" lässt sich streiten - über Geschwindigkeit auch. OK ich geb zu: bei 15k LOC in einer Datei und aktiviertem Indexer wirds zäh. Solche Dateien sind aber üblicherweise generiert und müssen selten angefasst werden.
:
Bearbeitet durch User
Olaf schrieb: > die ganzen Geizlinge lieber Eclipse benutzen Für pures Hobby, wo kein Geld verdient wird finde ich es OK. Da macht es sogar Spaß den ganzen Abend Eclipse einrichten und die einzelnen Bestandteile mal kennenzulernen. Aber professionell lieber sowas wie Keil. Vor allem, da es einfacher zu installieren ist. Von der Bedienung finde ich persönlich Eclipse gut. Nach dem ewigen Startvorgang läuft es bei mir auch fix und bietet in der Zwischenzeit gute Unterstützung. Insbesondere das ARM GCC Plugin macht die Arbeit zum Einstieg recht einfach. Was am meisten nervt ist das Projektgedöns. Gefühlte Tausend Dateien, die man irgendwie nie so richtig auf einem anderen System wieder richtig importiert bekommt. Schön wäre der Export als Zip. Und bei einem Import sollte es dann einen wizard geben, der die lokalen Eigenheiten einpflegt (Wo liegt der compiler, wo ist doxygen, Vorschlag welche Plugsins noch nachinstalliert werden sollten, was war die GCC Version auf dem exportierenden System, ...). Was mir noch fehlt ist so eine kompakte Zusammenfassung, wo es eine Zip gibt, die alle notwendigen Plugsins, die Installation des Compilers, Doxygen inkl. Bilderzeugung, usw. bereits zur Verfügung stellt und keine richtige Installation mehr notwendig ist.
le x. schrieb: > MaWin schrieb: >> Es gibt dutzende gute und supportete IDEs zur C++ Entwicklung > > Jetzt musst aber nachlegen. Wenn man mal hier schaut: http://en.wikipedia.org/wiki/Comparison_of_integrated_development_environments#C.2FC.2B.2B und danach sortiert, dass der letzte Release nicht länger her ist als ein Jahr, dann bleiben übrig: CodeLite Eclipse KDevelop Microsoft Visual Studio Qt Creator Xcode MaWin meinte wahrscheinlich "ein halbes Dutzende". :-)
Mark Brandis schrieb: > CodeLite > Eclipse > KDevelop > Microsoft Visual Studio > Qt Creator > Xcode Mein Fehler, ich habe MaWins Zitat zu früh gekürzt. Er behauptete ja, dass es so viele tolle kommerzielle Lösungen gäbe, siehe hier: > Es gibt dutzende gute und supportete IDEs zur C++ Entwicklung, dafür > muss man halt bezahlen Die Ausbeute deiner IDE-Recherche ist eh schon dürftig. Aber wenn dann auch noch die Anforderung "kommerziell" im Raum steht ist MaWins Aussage wohl endgültig nicht mehr haltbar. Mark Brandis schrieb: > MaWin meinte wahrscheinlich "ein halbes Dutzende". :-) MaWin wollte, wie immer, nur bisl trollen und Dampf ablassen.
Christopher schrieb: > (Wo liegt der compiler, wo ist doxygen, Vorschlag welche Plugsins noch > nachinstalliert werden sollten, was war die GCC Version auf dem > exportierenden System, ...). Ersteres erlaubt das ARM-GCC-Plugin, zweiteres Eclox, für 3 und 4 kenne ich keine Lösung.
> Insbesondere das ARM GCC Plugin macht die Arbeit zum > Einstieg recht einfach. Dafür ist das Emacs-Plugin leider irgendwie hakelig. > Was am meisten nervt ist das Projektgedöns. Noch schlimmer ist das Chaos bei den ganzen Einstellungen. Wenn du im Abstand von einer Woche 10x Eclipse installierst ist es sehr unwahrscheinlich das sich zwei Installationen gleichen. Man merkt deutlich das es bei der Entwicklung von Eclipse kein Ziel gibt, jeder bastelt gerade an der Ecke die ihm wichtig ist. Olaf
Olaf schrieb: > Noch schlimmer ist das Chaos bei den ganzen Einstellungen. Wenn du im > Abstand von einer Woche 10x Eclipse installierst ist es sehr > unwahrscheinlich das sich zwei Installationen gleichen. Man kann doch einfach den kompletten Eclipse Ordner kopieren. Das einzige was ich an Eclipse nicht mag, ist die Tatsache das es wirklich fett ist und auf einem langsamen Rechner ewig brauch um in die Gänge zu kommen. Dannach läufts aber in der Regel flüssig. Auch macht es auf dem kleinen Laptop weniger Spass als auf einem richtig grossen FullHD+x Monitor. Ansonsten schätze ich die Tatsache das man damit alles und jedes programmieren kann. Für alles halbwegs verbreitete Szenario gibt es ein Plugin. Das spart auch Einarbeitung und vor allem hat noch lange nicht jede IDE Features wie SVN Integration. Wieviele IDEs unterstützen z.B. Cross-compiler und remote debug wie ich es für ein aktuelles RPI Projekt gerade nutze?
Hi Scelumbro, Scelumbro schrieb: > Man kann doch einfach den kompletten Eclipse Ordner kopieren. > > Das einzige was ich an Eclipse nicht mag, ist die Tatsache das es > wirklich fett ist und auf einem langsamen Rechner ewig brauch um in die > Gänge zu kommen. Dannach läufts aber in der Regel flüssig. Auch macht es > auf dem kleinen Laptop weniger Spass als auf einem richtig grossen > FullHD+x Monitor. > > Ansonsten schätze ich die Tatsache das man damit alles und jedes > programmieren kann. Für alles halbwegs verbreitete Szenario gibt es ein > Plugin. Das spart auch Einarbeitung und vor allem hat noch lange nicht > jede IDE Features wie SVN Integration. Wieviele IDEs unterstützen z.B. > Cross-compiler und remote debug wie ich es für ein aktuelles RPI Projekt > gerade nutze? Ein Emacs und eine ordentliche Kommandozeilenumgebung können all das schon seit Jahrzehnten. Natürlich: die Lernkurve ist sehr viel steiler, aber die Produktivität steht der mit einer IDE letzten Endes in nichts nach und die Flexibilität läßt jede IDE alt aussehen. Obwohl man beim Emacs sicherlich trefflich darüber streiten kann, ob das nun ein Editor auf Steroiden, eine besonders ausgereifte und leistungsfähige IDE oder doch ein Betriebssystem mit eingebautem Editor und eigener Programmiersprache ist. Seit über zwanzig Jahren probiere ich immer wieder diverse IDEs aus, weil ich annehme, daß es gute Gründe dafür geben muß, warum so viele erfahrene und fähige Entwickler auf diese Dinger stehen. Aber eine IDE, mit der ich mit verschiedenen Programmier- und Markup-Sprachen (hier: C, C++, Python, Bash, Perl, JavaScript, HTML, LaTeX, SQL), mit diversen SCM-Werkzeugen (hier: Subversion, Mercurial, Git), auf verschiedenen Systemen (Linux, FreeBSD, AIX5-7) und nötigenfalls auch mit einem 80x24-Zeichen-Terminal über eine 9600-Baud-Satellitenverbindung arbeiten kann, ist mir bis dato leider immer noch nicht begegnet. Also kehre ich dann jedesmal wieder zu Werkzeugen zurück, deren Flexibilität und Leistungsfähigkeit unerreicht ist und die ich -- der angenehmste Nebeneffekt -- seit zwanzig Jahren im Schlaf vor-, rück- und seitwärts beherrsche. Letzten Endes ist das IMHO auch eine philosophische Frage. IDEs verfolgen eher die Windows-Philosophie der monolithische Werkzeuge und können immer nur das, was ihre Hersteller vorgesehen haben. Ein ordentlicher Editor in Verbindung mit den klassischen Shellwerkzeugen sind hingegen eine große, immer wieder neu zusammensetzbare Sammlung von Werkzeugen, die dem Könner buchstäblich unendliche Möglichkeiten eröffnet -- das entspricht eher der UNIX-Philosophie kleiner, miteinander kombinierbarer Programme, von denen jedes zwar nur eine einzige Aufgabe kann, aber die so gut wie möglich. Aber, ok, ich bin eh ein bekennender Shelljunkie. Am Anfang haben meine Kollegen noch darüber gelächelt und bezweifelt, daß ich mit meiner Shell mindestens genauso und oft sogar deutlich schneller bin als sie mit ihren tollen GUI-Tools. Von denen, die mir mal bei der Arbeit über die Schulter geschaut haben, lächelt aber mittlerweile keiner mehr. ;-) Liebe Grüße, Karl
So sehr ich Emacs für VHDL mag - aber emacs beherrscht doch weder eine vernünftige automatische Vervollständigung noch die Unterstützung bei der Auswahl von Methoden bzw. Parameterisierung der Methoden. Ich kann auch nicht per Tastendruck einfach zur Deklarierung/Definition einer Klasse springen, wenn ich den Typparameter mit der Maus markiert habe.
Rüdiger Knörig schrieb: > Ich kann auch nicht per Tastendruck einfach zur Deklarierung/Definition > einer Klasse springen Lol? Nachdem der Emacs ja jeder IDE so überlegen sein soll bin ich schon leicht verwundert dass er so ein grundlegendes Feature nicht beherrscht. Wie macht dass der Emacs-User denn? Per File_search?
Rüdiger Knörig schrieb: > So sehr ich Emacs für VHDL mag - aber emacs beherrscht doch weder eine > vernünftige automatische Vervollständigung noch die Unterstützung bei > der Auswahl von Methoden bzw. Parameterisierung der Methoden. > Ich kann auch nicht per Tastendruck einfach zur Deklarierung/Definition > einer Klasse springen, wenn ich den Typparameter mit der Maus markiert > habe. Klar kann das Emacs, mithilfe der ctags. Ob das allerdings mit VHDL geht, weiss ich nicht. Grüsse, René
Karl Käfer schrieb: > Letzten Endes ist das IMHO auch eine philosophische Frage. IDEs > verfolgen eher die Windows-Philosophie der monolithische Werkzeuge und > können immer nur das, was ihre Hersteller vorgesehen haben. Bei Eclipse ist das ja eben nicht der Fall. Ursprünglich eine Java IDE, eröffnen Plugins Möglichkeiten in alle Richtungen. Karl Käfer schrieb: > Seit über zwanzig Jahren probiere ich immer wieder diverse IDEs aus, > weil ich annehme, daß es gute Gründe dafür geben muß, warum so viele > erfahrene und fähige Entwickler auf diese Dinger stehen. Einfach mal eine IDE probieren funktioniert bei einer so komplexen Software einfach nicht. Als Shelljunkie sieht man dann nur was alles nicht (- genauso wie auf der Shell - ) geht und nicht die zusätzlichen Möglichkeiten. Investiere mal annäherend so viel Zeit in die Einarbeitung in Eclipse wie du in die Einarbeitung für dein EMCAS System investiert hast und vergleichen wir dann deine Produktivität.
Mladen G. schrieb: > Echte Programmierer brauchen keine IDE zum entwickeln.. ;) > > https://xkcd.com/378/ Immer wieder gut. :)
Karl Käfer schrieb: > Letzten Endes ist das IMHO auch eine philosophische Frage. Na ja, es ist auch eine Frage, ob der erfahrene Entwickler solch neumodischen Kram wie eine Maus als Eingabeinstrument oder Fenster auf dem Bildschirm akzeptiert. Manch einer scheitert ja schon daran, daß Disketten nicht in den Lochkartenleser passen. Oliver
Rüdiger Knörig schrieb: > So sehr ich Emacs für VHDL mag - aber emacs beherrscht doch weder > eine vernünftige automatische Vervollständigung noch die Unterstützung > bei der Auswahl von Methoden bzw. Parameterisierung der Methoden. > Ich kann auch nicht per Tastendruck einfach zur Deklarierung/Definition > einer Klasse springen, wenn ich den Typparameter mit der Maus markiert > habe. Bullshit. Siehe Autocomplete/company für Vervollständigung und Cedet (ede/semantics) für den Sprung. Und das ist nur ein Beispiel, das zu erledigen. Gibt noch mehr Möglichkeiten.
Hauptprobelm bei eclipse für ARM C++ finde ich, dass es nie so läuft, wie man es erwartet. Immer wieder fehlt was, etwas ist falsch,... Sowohl bei der Installation als auch beim Betrieb. Die Autovervollständigung funktioniert nur halb (oder mal auch wieder nicht, dann wieder) oder es fehlt mir das "String Highlighting" aus Em::Blocks: Einen string angeklickt und alle anderen gleichen strings sind grau hinterlegt - sehr praktisch! Sprünge zu den Deklarationen funktioniert auch manchmal nicht, keiner weiß warum, usw. Wirkt halt irgendwie "zusammengschustert". Vorteil ist, man kann das alles gut im Internet recherchieren. Kostet aber Mühe und sehr viel Zeit. Fazit: Man verbringt oft viel Zeit mit der IDE anstatt sich um sein eigentliches Problem kümmern zu können. Karl Käfer schrieb: > Aber, ok, ich bin eh ein bekennender Shelljunkie. Am Anfang haben meine > Kollegen noch darüber gelächelt und bezweifelt, daß ich mit meiner Shell > mindestens genauso und oft sogar deutlich schneller bin als sie mit > ihren tollen GUI-Tools. Dem kann ich nur zustimmen! Mag sein, dass ich damit einen shitstorm gegen mich auslöse, ist aber einfach meine Meinung! (Mein "Problem": STM32F4xx Programmierung mit FreeRTOS und lwIp)
Hallo Rüdiger, Rüdiger Knörig schrieb: > So sehr ich Emacs für VHDL mag - aber emacs beherrscht doch weder eine > vernünftige automatische Vervollständigung noch die Unterstützung bei > der Auswahl von Methoden bzw. Parameterisierung der Methoden. > Ich kann auch nicht per Tastendruck einfach zur Deklarierung/Definition > einer Klasse springen, wenn ich den Typparameter mit der Maus markiert > habe. Äh... Die Autocompletion gibts bei http://auto-complete.org/ (oder unter Ubuntu als Paket "auto-complete-el" und für die Sprünge gibt es mehrere Lösungen, etwa den Imenu-Mode. Liebe Grüße, Karl
Hallo Scelumbro, Scelumbro schrieb: > Karl Käfer schrieb: >> Letzten Endes ist das IMHO auch eine philosophische Frage. IDEs >> verfolgen eher die Windows-Philosophie der monolithische Werkzeuge und >> können immer nur das, was ihre Hersteller vorgesehen haben. > > Bei Eclipse ist das ja eben nicht der Fall. Ursprünglich eine Java IDE, > eröffnen Plugins Möglichkeiten in alle Richtungen. Ja, ich weiß, aber auch die können natürlich immer nur das, was ihre Hersteller vorgesehen haben. Klar: man kann sich natürlich auch eigene Plugins schreiben, aber angesichts des dazu nötigen Aufwandes ist dann der angestrebte Produktivitätsvorteil schon dahin. Allerdings kann man den Emacs natürlich auch um Plugins erweitern, und eine eigene Programmiersprache hat er auch eingebaut (auch wenn ich LISP nicht sonderlich mag, aber das ist natürlich Geschmackssache)... ;-) > Karl Käfer schrieb: >> Seit über zwanzig Jahren probiere ich immer wieder diverse IDEs aus, >> weil ich annehme, daß es gute Gründe dafür geben muß, warum so viele >> erfahrene und fähige Entwickler auf diese Dinger stehen. > > Einfach mal eine IDE probieren funktioniert bei einer so komplexen > Software einfach nicht. Natürlich nicht. Deswegen habe ich den jeweils ausprobierten IDEs durchaus realistische Chancen gegeben und jeweils ein paar Wochen oder sogar Monate damit gearbeitet. Letztlich hielt sich der Aufwand, herauszufinden, wie der Hersteller der IDE etwas umgesetzt hatte und wo ich für was anderes ein Häkchen zu setzen hatte, in etwa die Waage mit dem Aufwand, dasselbe für die Shell-Umgebung nachzuschauen. Andererseits: hast Du denn mal ein paar Wochen ohne IDE, nur mit einem guten Texteditor und einer leistungsfähigen Shellumgebung gearbeitet? > Als Shelljunkie sieht man dann nur was alles > nicht (- genauso wie auf der Shell - ) geht und nicht die zusätzlichen > Möglichkeiten. Investiere mal annäherend so viel Zeit in die > Einarbeitung in Eclipse wie du in die Einarbeitung für dein EMCAS System > investiert hast und vergleichen wir dann deine Produktivität. Naja, ich kann meine Produktivität mit der von Kollegen vergleichen, die IDEs benutzen und sehe keine Vorteile, die signifikant genug wären, mich zu einem Wechsel meiner Arbeitsumgebung zu bewegen. Klar: die Lernkurve ist bei einer integrierten Lösung nicht so steil und man kann schneller loslegen. Aber was dem Anfänger über die Einstiegshürde hilft, ist für Fortgeschrittene sicherlich nicht so wichtig. Aus meiner ganz persönlichen Perspektive liegen die Vorteile von Emacs und Shelltools natürlich vor allem darin, daß ich damit die meiste Erfahrung, die völlige Kontrolle über alle Entwicklungsprozesse und eine konsistente Handhabung über alle von mir verwendeten Programmier- und Markupsprachen habe. Im Emacs kann ich meinen Quellcode schreiben, aber natürlich gleich auch die Konfigurationsdatei(en) und die Dokumentation, ohne mich dabei umgewöhnen zu müssen. Versteh' mich bitte nicht falsch: ich will hier nicht gegen IDEs meckern, sondern schildere nur meine eigenen Erfahrungen. Die Auswahl solch einer Software ist IMHO immer eine sehr persönliche Sache, die jeder für sich nach den eigenen, ganz persönlichen Vorlieben treffen muß. Meine Wahl ist aus den genannten Gründen eben so, wie ich es geschildert habe. Wenn ein anderer eine andere Wahl trifft: kein Problem. Liebe Grüße, Karl
Karl Käfer schrieb: > Hallo Rüdiger, > > Rüdiger Knörig schrieb: >> So sehr ich Emacs für VHDL mag - aber emacs beherrscht doch weder eine >> vernünftige automatische Vervollständigung noch die Unterstützung bei >> der Auswahl von Methoden bzw. Parameterisierung der Methoden. >> Ich kann auch nicht per Tastendruck einfach zur Deklarierung/Definition >> einer Klasse springen, wenn ich den Typparameter mit der Maus markiert >> habe. > > Äh... Die Autocompletion gibts bei http://auto-complete.org/ (oder unter > Ubuntu als Paket "auto-complete-el" und für die Sprünge gibt es mehrere > Lösungen, etwa den Imenu-Mode. > > Liebe Grüße, > Karl Um es mal so auszudrücken - ein Ford Model T und ein 7er BMW implementieren beide die Funktionalität "motorisiertes Fahren". Die automatische Vervollständigung von emacs ist leider grausig, wenn das Projekt etwas komplexer wird. Zum einen erfaßt er dann nicht mehr alle Möglichkeiten, scheitert schnell an Überladungen und Templates und ist auch nicht so komfortabel - ich erwarte ein Drop-Down-Menü mit Anzeige der Doxygen-Dokumentation und die folgende Unterstützung bei der Ausfüllung der Parameterliste. Genau das ist es aber, was ich in komplexen Projekten zur zügigen Arbeit brauche. Ebenso die Möglichkeit, schnell und unkompliziert Variablen, Klassen oder Methoden einfach umzubenennen - Eclipse paßt die Verwendungen dann auch zuverlässig projektübergreifend an. Nur so bleibt der Quelltext auch verständlich, denn oft ändert sich durch spätere Einsicht oder geänderte Zielsetzung die Bedeutung dieser Elemente. Und nichts ist verwirrender als ein Name, der nicht mehr zu der Verwendung paßt.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.