Jammer-Thread

[Krishty]

__forceinline funktioniert nicht, wenn man die Definition in eine andere Übersetzungseinheit verlagert. OH RLY?! Wer ist für diesen Dreck verantwortlich?! ICH HASSE ES

Oh und wozu brauche ich das? Weil Visual C++ kein Single Call Site Inlining betreibt. Wenn das entsprechende Microsoft-Connect-Ticket nicht schon gelöscht wäre, könnte man auch nachlesen, dass ihre Politik diesbezüglich ist: „Der Compiler ist schlecht, aber wenn wir das ändern, ist er woanders schlecht“. Dann lasst mich das verbessern! Mit __forceinline oder __declspec(noinline)! Nö – Kaufen Sie doch für eine halbe Million Euro die Professional Edition und optimieren Sie mit PGO!

[antisteo]

__forceinline funktioniert nicht, wenn man die Definition in eine andere Übersetzungseinheit verlagert. OH RLY?! Wer ist für diesen Dreck verantwortlich?! ICH HASSE ES

Oh und wozu brauche ich das? Weil Visual C++ kein Single Call Site Inlining betreibt. Wenn das entsprechende Microsoft-Connect-Ticket nicht schon gelöscht wäre, könnte man auch nachlesen, dass ihre Politik diesbezüglich ist: „Der Compiler ist schlecht, aber wenn wir das ändern, ist er woanders schlecht“. Dann lasst mich das verbessern! Mit __forceinline oder __declspec(noinline)! Nö – Kaufen Sie doch für eine halbe Million Euro die Professional Edition und optimieren Sie mit PGO!

LLVM hat LTO :P
Also jammere lieber mal rum, dass du immer dieses komische Windows-ABI-Format brauchst, anstatt über VS zu meckern, das dir die Clang-Features nicht geben will.

[Krishty]

LTO hat Visual C++ auch. Hast du verifiziert, dass Clang das Inlining externer Funktionen auf Befehl des Programmierers garantiert?

Soweit ich das in der GCC-Dokumentation, auf die Clang verweist, rauslese, geht es dort ebenfalls nicht (das always_inline-Attribut gilt nur für Funktionen mit inline Storage Class).

[antisteo]

LTO hat Visual C++ auch. Hast du verifiziert, dass Clang das Inlining externer Funktionen auf Befehl des Programmierers garantiert?

Soweit ich das in der GCC-Dokumentation, auf die Clang verweist, rauslese, geht es dort ebenfalls nicht (das always_inline-Attribut gilt nur für Funktionen mit inline Storage Class).

Notfalls baust du deinen eigenen LLVM-Pass, der genau das macht, was du brauchst.

[Krishty]

C++ fehlt wirklich ein goto case. Es ist zum Kotzen wie oft ich sowas wie

    case op::abort:
    abort:

schreiben muss weil goto case op::abort nicht geht. Für nichts und wieder nichts.

[Krishty]

Die Sprungleistung von C++’ switch ist eine einzige Blamage. Ich habe hier eine wundervolle datenorientierte Job-Liste, die 30 % ihrer Zeit damit verbringt, in einem switch zu bestimmen, welcher Text angesprungen werden soll.

Wer wissen will, wie es richtig geht, der sollte sich GCCs Labels as Values oder Fortrans assigned GOTO ansehen:

Erstmal wird das switch durch gute alte manuelle Labels ersetzt, so wie im Jammer-Beitrag über mir. Weil es entfällt.

Statt jetzt irgendein scheiß enum in der Job-Liste zu speichern, speichert die Liste Zeiger auf die case-Labels des switch. Da, wo vorher

    jobs.push_back(JobType::a);
    …

    switch(job) { // job == enum
        case JobType:
            …;
        case JobType:
            …;
    }

stand, steht nun

    jobs.push_back(&&a);
    …

    goto *job; // job == pointer to label
        a:
            …;
        b:
            …;

und ZACK haben wir nur noch einen unbedingten Sprung ohne jedwege Adressberechnung oder *würg* Indirektion. Beliebig große switches in einem einzigen Takt.

Ein typisches statisches Problem (wenn ich den Job im Quelltext anlege, weiß ich bereits, welchen dazugehörigen Quelltext ich damit später anspringen will!), das Leute durch Unwissenheit zu einem Laufzeitproblem aufblasen.

Aber nööööööööö – wozu sowas in den Standard übernehmen? Es gibt ja bestimmt auch eine tolle Boost-Lösung für dieses Problem, die mit doppelt logarithmischer Interpolationssuche über eine vom Präprozessor erzeugte Tabelle und vierzehntausend Zeilen Template-Text so was Ähnliches macht. Oder so. Im Notfall kann der Kunde ja auch einfach zwei Jahre auf eine neue CPU-Generation warten.

(Der Vollständigkeit halber: Funktionszeiger speichern geht natürlich auch, aber dann hat der Funktionsaufruf allein schon so viel Unkosten dass das switch dagegen wie eine Rennratte abgeht. Vor allem, wenn man die umgebenden lokalen Variablen als Parameter reinpusten muss.)

[Helmut]

Naja wenn ich der Standard wäre würde ich auch nicht so ein Feature aufnehmen. :) Sobald so eine Adresse raus aus der Funktion gerät, oder Exceptions oder RAII ins Spiel kommen gäbs große Probleme. Auch würden die Optimiermöglichkeiten des Compilers stark eingeschränkt werden.
Aber man könnte dem enum ein neues Attribut verpassen. Ein Attribut, das bewirkt, dass deren Werte an ein Switch gebunden werden und dass der Compiler die Werte vom enum frei wählen darf. So wäre es ein leichtes für den Compiler, das ordentlich zu optimieren.

[Krishty]

Wieso? Fast die gleichen Probleme hat man mit goto oder seinem eingeschränkten Pendant switch doch auch (schmeiß mal Ausnahmen aus einem case, das die Initialisierung lokaler Variablen übersprungen hat). Trotzdem benutzen es alle.

Bei keinem einzigen C++-Feature hat in-den-Fuß-Schießen jemals als Gegenargument gezählt, das ist doch hinlängst bekannt. Zumal man den Fall, in eine andere Funktion zu springen, einfach undefiniert machen kann. Der Compiler kann das zur Hälfte statisch bestimmen und für die andere Hälfte zum Debugging zusätzlichen Text einfügen, der auf diesen Fall prüft und hinweist.

Besser wäre aber noch, das implementierungsabhängig zu machen, weil es durchaus erwünscht sein kann (zum Beispiel, während nach einer Ausnahme der Stack konsolidiert wird – die Visual C++-CRT muss extra Assembler-Module linken, weil es in C++ nicht hinzukriegen ist).

[Helmut]

Beim normalen goto weiß der Compiler, wohin gesprungen wird und kann entsprechend beim Sprung Ctoren und Dtoren aufrufen und den Stack in Ordnung halten. Wenn der Compiler das Ziel des Sprungs nicht kennt geht das einfach nicht.
Außerdem sind goto und switch alt. Bei neuen Features achtet das Komitee schon zu recht darauf, das in den Fuß schießen so schwer wie möglich zu machen. Und wenn man, ohne Casts benutzen zu müssen oder irgendwas anderes verachtenswertes, in eine andere Funktion springen kann, dann überwiegt der Nutzen sicherlich nicht dem Risiko. Zumal goto schon in seiner einfachen Form von vielen verachtet wird.
Dein goto case Vorschlag hat übrigens ein kleines Manko. Was ist, wenn es in einem verschachtelten Switch Statement auftritt? Es gäbe keine elegante Möglichkeit zwischen innerem und äußerem Switch zu unterscheiden.

[Krishty]

Beim normalen goto weiß der Compiler, wohin gesprungen wird und kann entsprechend beim Sprung Ctoren und Dtoren aufrufen und den Stack in Ordnung halten. Wenn der Compiler das Ziel des Sprungs nicht kennt geht das einfach nicht.

Niemand hält die Sprache davon ab, die Labels zu typisieren, wie es mit Funktionen und Lambdas auch gemacht wird.

Außerdem sind goto und switch alt.

Wenn switch alt ist, womit dispatcht man heutzutage? std::map?

Bei neuen Features achtet das Komitee schon zu recht darauf, das in den Fuß schießen so schwer wie möglich zu machen.

    Foo x(std::move(y));
    y.use();

Haben sie geschafft!

Und wenn man, ohne Casts benutzen zu müssen oder irgendwas anderes verachtenswertes, in eine andere Funktion springen kann, dann überwiegt der Nutzen sicherlich nicht dem Risiko. Zumal goto schon in seiner einfachen Form von vielen verachtet wird.

Selbst C# hat goto, obwohl es eine hippe Modesprache ist. Ruby, Python, und die Android Java VM realisieren ihre innerste Schleife über Label-Adressierung.
GCC, ICC, und Clang implementieren furchtbar gefährliche void *-adressierbare Labels. Microsoft erlaubt Sprünge über Konstruktoren hinweg. Sun Studio erlaubt die Adressierung im C-Modus. Wie viel herstellerspezifisches nicht-portables Zeug muss denn noch implementiert werden damit es als nützlich anerkannt wird? Wo ist das sicherer als eine standardisierte Syntax, die für die ganzen Spezialfälle eben implementation-defined ist?

Dein goto case Vorschlag hat übrigens ein kleines Manko. Was ist, wenn es in einem verschachtelten Switch Statement auftritt? Es gäbe keine elegante Möglichkeit zwischen innerem und äußerem Switch zu unterscheiden.

Es würde ja reichen, nur das aktuelle (innerste) switch ansteuern zu können.

[Helmut]

Beim normalen goto weiß der Compiler, wohin gesprungen wird und kann entsprechend beim Sprung Ctoren und Dtoren aufrufen und den Stack in Ordnung halten. Wenn der Compiler das Ziel des Sprungs nicht kennt geht das einfach nicht.

Niemand hält die Sprache davon ab, die Labels zu typisieren, wie es mit Funktionen und Lambdas auch gemacht wird.

Außerdem sind goto und switch alt.

Wenn switch alt ist, womit dispatcht man heutzutage? std::map?

Bei neuen Features achtet das Komitee schon zu recht darauf, das in den Fuß schießen so schwer wie möglich zu machen.

    Foo x(std::move(y));
    y.use();

Haben sie geschafft!

Und wenn man, ohne Casts benutzen zu müssen oder irgendwas anderes verachtenswertes, in eine andere Funktion springen kann, dann überwiegt der Nutzen sicherlich nicht dem Risiko. Zumal goto schon in seiner einfachen Form von vielen verachtet wird.

Selbst C# hat goto, obwohl es eine hippe Modesprache ist. Ruby, Python, und die Android Java VM realisieren ihre innerste Schleife über Label-Adressierung.
GCC, ICC, und Clang implementieren furchtbar gefährliche void *-adressierbare Labels. Microsoft erlaubt Sprünge über Konstruktoren hinweg. Sun Studio erlaubt die Adressierung im C-Modus. Wie viel herstellerspezifisches nicht-portables Zeug muss denn noch implementiert werden damit es als nützlich anerkannt wird? Wo ist das sicherer als eine standardisierte Syntax, die für die ganzen Spezialfälle eben implementation-defined ist?

Dein goto case Vorschlag hat übrigens ein kleines Manko. Was ist, wenn es in einem verschachtelten Switch Statement auftritt? Es gäbe keine elegante Möglichkeit zwischen innerem und äußerem Switch zu unterscheiden.

Es würde ja reichen, nur das aktuelle (innerste) switch ansteuern zu können.

Labels zu typisieren würde in der Tat einige meiner genannten Probleme lösen. Allerdings ist das leichter gesagt als getan. Der Typ müsste pro Funktion individuell sein, aber trotzdem von außerhalb erreichbar sein. Funktionen sind aber keine Klassen oder Namespaces, Typen innerhalb sind also nicht mit dem :: Operator erreichbar. Man müsste so einen Typen auch vorwärtsdeklarieren können. Eine schwierige Angelegenheit, da die Adressen der einzelnen Labels erst bei der Definition bekannt sind. Wie immer liegt der Teufel halt im Detail. (und braucht C++ wirklich noch eine Art von Typ? :))

Wenn etwas alt ist heißt das nicht, dass man es nicht mehr benutzen soll :) Ich wollte nur sagen, dass man heute das switch nicht mit den ganzen Altlasten implementiert hätte. (die komischen Scopes und die Möglichkeit einer Schleife über mehrere cases) Dass goto eine Daseinsberechtigung hat ist mir klar, aber dass man mit goto an eine beliebige void* Adresse springen können soll sehe ich nicht ein.

Die Sache mit std::move: Das resultiert vielleicht nicht in dem, was sich der Autor von solchem Code verspricht, aber nicht zu undefiniertem Verhalten. Vor allem kein undefiniertes Verhalten, dass sehr leicht zur Sicherheitslücke mutieren kann und eine Pest zu debuggen wäre. Stell dir mal vor du musst ein Programm debuggen, dass mit nem falschen Stack in einer anderen Funktion (oder in 'ner zufälligen Adresse) landet. Und nicht immer hat man das Vergnügen mit einer Debugversion.

Das Label-Adressierung eine sinnvolle Sache ist bestreite ich nicht, aber doch nicht mit void* Zeiger. Wenn es genug Nutzungsfälle gäbe, könnte man sowas ordentlich in den Standard übernehmen. Aber ich glaube C++ hat noch größere Probleme als sowas.

[Krishty]

Labels zu typisieren würde in der Tat einige meiner genannten Probleme lösen. Allerdings ist das leichter gesagt als getan. Der Typ müsste pro Funktion individuell sein, aber trotzdem von außerhalb erreichbar sein. Funktionen sind aber keine Klassen oder Namespaces, Typen innerhalb sind also nicht mit dem :: Operator erreichbar. Man müsste so einen Typen auch vorwärtsdeklarieren können. Eine schwierige Angelegenheit, da die Adressen der einzelnen Labels erst bei der Definition bekannt sind. Wie immer liegt der Teufel halt im Detail. (und braucht C++ wirklich noch eine Art von Typ? :))

Afaik gibt es ähnliche Typen in C++14 bereits:

    auto foo() {
        struct MyNameIsWHAT { } chickyChickySlimShady;
        return chickyChickySlimShady;
    }

Und seit C++11 können funktionslokale Typen auch benutzt werden, um Templates zu spezialisieren. Selbst, wenn die Typen nur via auto erreichbar sind: decltype + std::initializer_list == Profit?

Das Label-Adressierung eine sinnvolle Sache ist bestreite ich nicht, aber doch nicht mit void* Zeiger. Wenn es genug Nutzungsfälle gäbe, könnte man sowas ordentlich in den Standard übernehmen. Aber ich glaube C++ hat noch größere Probleme als sowas.

Das hat nichts mit Nutzungsfällen zu tun: Die Musterlösung für das Hauptproblem eines ganzen Haufens von Parser- und VM-Implementierungen ist nicht durch die Sprache beschreibbar. Und das treibt die Leute in die Arme von herstellerspezifischen Lösungen oder zwingt sie zu sowas.

[Krishty]

http://stackoverflow.com/questions/2593 ... stopped-pr

Visual Studios Find in Files funktioniert nicht mehr sondern zeigt nur noch Find was stopped in progress an.

Visual Studio oder das gesamte System neu zu starten bringt nichts.

Microsoft kennt den Fehler von allen Visual Studio-Versionen seit 2004 auf allen Windows-Versionen, kann ihn aber weder reproduzieren noch zu Visual Studio selbst zurückverfolgen.

Die einzige Lösung ist, je nach Visual Studio-Version, Scroll Lock, CTRL+Scroll Lock, Break, CTRL+Break, oder ALT + Break zu drücken.

WTF         WTF   WTFWTFWTFWTFWTF  WTFWTFWTFWTF
WTF         WTF   W     WTF     T   WTF       F
 WTF       WTF          WTF         WTF
 WTF  WTF  WTF          WTF         WTFWTF
  WT FFWTF TF           WTF         WTF
  WTFTF WTFTF           WTF         WTF
   WTF   WTF            WTF         WTF
   WTF   WTF           WTFTF       WTFTF

PS. Microsoft claims that they fixed it in VS 2012.

Am Arsch ich hatte es eben

[Chromanoid]

Das ist bestimmt ein Easter egg :D

[Krishty]

Das ist die Folge davon, dass alle nur noch diese bekackten asynchronen GUIs machen weil wenn ich eine Taste drücke und zu tippen anfange dann soll nicht erst eine 20telsekunde später ein Fenster erscheinen und mit meinem Input gefüttert werden, neeeeeeeeein

es soll SOFORT ein LEERES Fenster aufplöppen, eine 10telsekunde GARNICHTS machen, fünf Tastenanschläge wahlweise verschlucken oder an ein völlig falsches Kontrollfeld weiterleiten, und mich dann nochmal drei Sekunden kosten das alles wieder rückgängig zu machen und Eingaben TATSÄCHLICH zu wiederholen

so und wenn dann der bekackte Build nach 100 Fehlermeldungen asynchron abgebrochen wird, so dass eine verschrottete Log-Datei und eine vom Linker totgeborene Exe in mein Verzeichnis geschissen bleiben, und man mit der richtigen Kompilierzeit und Fehlerposition in einem von 200 Millionen Builds den richtigen Wettlauf zwischen den 20 beteiligten Threads erwischt, DANN lässt sich das nur noch lösen indem man CTRL+Scroll Lock drückt!

Bei CTRL+BREAK könnte ich ja noch einen Zusammenhang erkennen weil BREAK tatsächlich die Übersetzung abbricht, aber CTRL + SCROLL LOCK, WTF WTF WTF, und den Tastendruck dann Wirkung auf die Registry haben lassen, WTF³

Boah ich habe die Fresse so voll von Software

Nachtrag: Jetzt fällt mir auch wieder ein, womit ich es hier zu tun habe: Der Find in Files-Dialog ist seit Visual Studio 2010 so dermaßen laggy, dass ich mir auf meinem Atom angewöhnt habe, den Browser zu aktualisieren bevor ich das Suchwort eintippe! Klar, dass solche Fehler DA herkommen! Dieses Miststück hat bestimmt der Praktikant geschrieben

[hagbard]

Ich hab die Erfahrung gemacht, dass FindInFiles in VS generell (beobachtet bei 2005 und 2008) nicht sonderlich zuverlässig funktioniert und nutze für grössere Suchen eher einen passablen Editior wie Notepad++ :x Bisher dachte ich nur ich bediene das Ding falsch aber ich scheine ja nicht der einzige mit Problemen zu sein.

[Sternmull]

Seltsam, obwohl mir auf Arbeit Visual Assist zur Verfügung steht nehm ich für großräumige Suchen (Projekt, Projektmappe, Verzeichnis) am liebsten die In-Datei-Suchen-Funktion. Die ist normalerweise schneller. Bisher war ich damit auch ganz zufrieden. Zumindest kamen mir trotz quasi täglicher Nutzung in VS2008 bisher keine der genannten Probleme unter. Das einzige was ich ein bisschen seltsam finde: Ist eine Datei mehrfach in einer Projektmappe eingebunden, so werden die Funde in dieser Datei auch mehrfach gemeldet... aber da das eher selten der Fall ist kann ich damit leben.

[Krishty]

Kaum zwei Wochen auf tumblr gebloggt, und schon wird es von Yahoo gekauft.

Yahoo ist der größte Datenvernichter der Menschheitsgeschichte. Jason Scott nennt sie yahoo!locaust – sie kaufen Dienste mit enormem Maß an Kreativität und Benutzerinhalt für viele Milliarden; lassen sie ein Jahr verrotten; und löschen dann alles.

Kann mir jemand eine Plattform empfehlen, die tumblr ähnlich ist? Also, Videos via Drag'n'Drop posten statt in irgendwelchen Tags rumzuwühlen und so? Ich hatte von Anfang an an soup.io gedacht, aber scheinbar sind deren Wartung und Entwicklung quasi nicht existent.

[Chromanoid]

Keine Ahnung ob das gut ist, aber in letzter Zeit ist mir http://pinterest.com/ öfter mal über den weg gelaufen. Finde die landing page irgendwie unsympathisch...

Mmh Yahoo( Japan) ist in Japan populärer als Google, bei denen läuft es recht gut, vielleicht schaut sich ja Yahoo Inc mal was beim besser laufenden Kompagnon ab :).

[glassbear]

Ich hab die Erfahrung gemacht, dass FindInFiles in VS generell (beobachtet bei 2005 und 2008) nicht sonderlich zuverlässig funktioniert und nutze für grössere Suchen eher einen passablen Editior wie Notepad++ :x Bisher dachte ich nur ich bediene das Ding falsch aber ich scheine ja nicht der einzige mit Problemen zu sein.

Ach, Find In ... funktioniert in Eclipse/CDT auch nicht :lol:

[antisteo]

Ich hab die Erfahrung gemacht, dass FindInFiles in VS generell (beobachtet bei 2005 und 2008) nicht sonderlich zuverlässig funktioniert und nutze für grössere Suchen eher einen passablen Editior wie Notepad++ :x Bisher dachte ich nur ich bediene das Ding falsch aber ich scheine ja nicht der einzige mit Problemen zu sein.

Ach, Find In ... funktioniert in Eclipse/CDT auch nicht :lol:

Dazu gibt es ja auch grep ;)

[Florian Keßeler]

Dazu gibt es ja auch grep ;)

Exakt, oder um es auf Code zu beschränken und schneller zu machen: cgvg.

[Sternmull]

grep findet aber keine Strings die sich in ungespeicherten Änderungen befinden, die kennt nämlich nur der Editor in denen sie gemacht wurden.

[Florian Keßeler]

Dann speicher halt? Wie viele Dateien muss man denn ungespeichert offen haben? Kann mir da ehrlich gesagt keinen sinnvollen Anwendungsfall für vorstellen...

[Chromanoid]

Also bei Eclipse/Java funktionier "Search/File..." einwandfrei inkl. nicht gespeicherter Änderungen. "References" finden funktioniert natürlich ebenso gut (inkl. eingebundnener Bibliotheken, was ein deutlicher Vorteil gegenüber meinem Liebling NetBeans ist).

[Sternmull]

Dann speicher halt? Wie viele Dateien muss man denn ungespeichert offen haben? Kann mir da ehrlich gesagt keinen sinnvollen Anwendungsfall für vorstellen...

Deine Vorstellungskraft könnte besser sein ;) Ich wollte nur auf diesen Unterschied zwischen einem externen Tool wie grep und der eingebauten "in allen Dateien suchen"-Funktion aufmerksam machen. Es gibt sicherlich Situationen in denen ein "Dann speicher halt" nicht alle glücklich macht.

[antisteo]

Dann speicher halt? Wie viele Dateien muss man denn ungespeichert offen haben? Kann mir da ehrlich gesagt keinen sinnvollen Anwendungsfall für vorstellen...

Deine Vorstellungskraft könnte besser sein ;) Ich wollte nur auf diesen Unterschied zwischen einem externen Tool wie grep und der eingebauten "in allen Dateien suchen"-Funktion aufmerksam machen. Es gibt sicherlich Situationen in denen ein "Dann speicher halt" nicht alle glücklich macht.

Du kannst ja zur Not ein Versionskontrollsystem benutzen, falls du alte Versionen des Codes nicht überspeichern willst

[glassbear]

Also bei Eclipse/Java funktionier "Search/File..." einwandfrei inkl. nicht gespeicherter Änderungen. "References" finden funktioniert natürlich ebenso gut (inkl. eingebundnener Bibliotheken, was ein deutlicher Vorteil gegenüber meinem Liebling NetBeans ist).

Bei Java ist Eclipse wesentlich besser. In CDT funktioniert hier in 2/3 der Faelle nicht mal der Debugger... Also, er funktioniert schon, nur Breakpoints werden nicht getriggert, die Haelfte im Variables View fehlt (und man kann nix hinzufuegen), etc.

Ein Hoch auf freie Auswahl :(

[Sternmull]

Du kannst ja zur Not ein Versionskontrollsystem benutzen, falls du alte Versionen des Codes nicht überspeichern willst

Mach ich auch grundsätzlich, deshalb ist mir persönlich das Feature auch fast schon egal. Aber ich finde es nicht verkehrt wenn eine Volltextsuche wirklich in dem sucht was ich grad bearbeite, egal ob gespeichert oder nicht. Das heißt aber nicht das ich es toll finden würde wenn mir jemand vorschreibt generell speichern zu müssen bevor ich die Suche ausführen darf (betrifft ja auch gefundene Positionen die durch Änderungen verschoben wurden). Je mehr man beachten muss, desto mehr Chancen gibt es etwas falsch zu machen. In diesem Fall wäre das wahrscheinlich nicht grundsätzlich tödlich... aber es geht mir auch ein bisschen ums Prinzip: Warum sollte ich mich mit Extra-Schritten plagen wenn man mir die abnehmen kann. Es gibt in der Softwareentwicklung nun wirklich schon genug Mist den man falsch machen kann und auch macht. Jeder Stein der von vornehherein aus dem Weg geräumt wird ebnet den Weg. Auch wenn es in diesem Fall nur ein Kiesel ist.

[Chromanoid]

Also bei Eclipse/Java funktionier "Search/File..." einwandfrei inkl. nicht gespeicherter Änderungen. "References" finden funktioniert natürlich ebenso gut (inkl. eingebundnener Bibliotheken, was ein deutlicher Vorteil gegenüber meinem Liebling NetBeans ist).

Bei Java ist Eclipse wesentlich besser. In CDT funktioniert hier in 2/3 der Faelle nicht mal der Debugger... Also, er funktioniert schon, nur Breakpoints werden nicht getriggert, die Haelfte im Variables View fehlt (und man kann nix hinzufuegen), etc.

Ein Hoch auf freie Auswahl :(

Hast Du mal Netbeans (für C++) ausprobiert? Mich würden da die Unterschiede interessieren...