Jammer-Thread

[glassbear]

Ich versteh gerade nicht, was zur Hölle daran so schwer ist, halbwegs vernünftige C/C++-Code Completion zu machen. Von "Advanced Features", die die meisten Java-IDEs bieten, will ich gar nicht erst reden... Hab mir gerade in 2h was mit clang+gvim zusammengehackt, was wesentlich besser funktioniert als der Quatsch in CDT 8 :evil: :evil:

[Chromanoid]

Probier doch mal NetBeans aus, ich finde den C++-Support da ziemlich ausgereift.

[glassbear]

Das läuft mit der Java-Version hier nicht. Und eine andere geht nicht zu installieren, weil es sonst Probleme mit irgendwelchen Eclipse-Sachen gibt :roll:
Ich hatte mir mal kurz qtcreator angeschaut: Das lässt sich hier mit den alten Software-Versionen gar nicht erst kompilieren :roll:

[Schrompf]

QCreator gibt's auch precompiled. Ich mag die IDE, auch wenn ich sie bisher nur für kleinere Sachen benutzt habe. Selbst deren Autocompletion ist erstaunlich verlässlich gewesen. Versteht nur leider noch kein C++11, nach meinem letzten Kenntnissstand.

[glassbear]

Lässt sich über das Qt SDK nicht installieren:

./Qt_SDK_Lin64_online_v1_2_en.run: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./Qt_SDK_Lin64_online_v1_2_en.run)

Gleiches Problem bei qt creator als separates Package:

Failed to load core: /data/qtcreator-2.4.1/lib/qtcreator/plugins/Nokia/libCore.so: Cannot load library /data/qtcreator-2.4.1/lib/qtcreator/plugins/Nokia/libCore.so: (/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /data/qtcreator-2.4.1/lib/qtcreator/plugins/Nokia/../../libBotan.so.1))

Hab ich alles schon probiert ;)

Und selber kompilieren ist ... aufwendig: Erstmal git, dann Qt, dann alles andere :| und wer weiß, was dazwischen noch an Abhängigkeiten fehlen oder an alten Versionen da ist :|

[Chromanoid]

Das läuft mit der Java-Version hier nicht. Und eine andere geht nicht zu installieren, weil es sonst Probleme mit irgendwelchen Eclipse-Sachen gibt :roll:
Ich hatte mir mal kurz qtcreator angeschaut: Das lässt sich hier mit den alten Software-Versionen gar nicht erst kompilieren :roll:

http://wiki.netbeans.org/FaqPortableWorkingEnvironments Machs einfach "portable" und pack dir nen JDK irgendwo anders hin :) (ohne Installation).

[eXile]

Nein, sie haben neben der Farbe auch gleich noch den Kontrast abgeschafft. Dagegen war jede Windows-95-Oberfläche Hochglanz.

Hey cool, Visual C++ 6.0.

[kaiserludi]

Ja, VS 2010 sieht schrecklich aus, aber warum nicht einfach zum Style von 2005 und 2008 zurückkehren? Den empfinde ich sowohl als weit angenehmer als den von 2010 als auch wird er nach dem, was man bisher sieht, angenehmer sein als der von VS11.

[dot]

Also ich persönlich mag den Style von VS 2010 sehr gern, bekomm nun immer Augenkrebs wenn ich nochmal VS 2008 aufmachen muss. VS 2011 schaut genau gleich aus wie 2010.

[antisteo]

Meine Engine hatte ich anfangs nur unter Linux entwickelt und das kleine Detail vergessen, dass msvc noch keine variadischen Templates unterstützt. Resultat ist, dass ich wohl die kompletten Reflections nochmal neubauen muss. -.-

Wenn du unter Linux entwickelst, wirst du doch sowieso MinGW via Code::Blocks oder sonstewas nutzen, aber doch nicht MSVC...

[dot]

Meine Engine hatte ich anfangs nur unter Linux entwickelt und das kleine Detail vergessen, dass msvc noch keine variadischen Templates unterstützt. Resultat ist, dass ich wohl die kompletten Reflections nochmal neubauen muss. -.-

Wenn du unter Linux entwickelst, wirst du doch sowieso MinGW via Code::Blocks oder sonstewas nutzen, aber doch nicht MSVC...

Wieso? MSVC ist nunmal der native Compiler unter Windows!?

[j.klugmann]

Nochmal etwas eindeutiger: Ich habe anfangs nur unter Linux entwickelt( mit dem GCC ) und mir ist dann bei der Portierung auf Windows( unter Windows wollte ich den MSVC nutzen ) das Problem mit den variadischen Templates aufgefallen, welches mir vorher noch nicht so präsent war.

[dot]

Ja, leider unterstützt MSVC noch keine variadic templates (ich vermiss sie auch ständig). Es gibt aber Hoffnung, dass sich das in nicht all zu ferner Zukunft ändern wird.

[CodingCat]

Ich hasse das Beobachter-Muster. In jeden verdammten Setter zumindest einen Zweig einbauen, der in 99.5% aller Fälle garantiert nie genommen wird. Eine mögliche zweiglose Alternative, nämlich veränderte Objekte in eine Notifikationswarteschlange zu setzen, wäre noch schlimmer, bei jeder Änderung fielen Zugriffe auf weit entfernten Speicher an. Am liebsten wäre mir, wenn alle informationsbedürftigen Objekte einfach regelmäßig ihre beobachteten Objekte auf Änderungen prüfen würden (z.B per simplem Revisionsattribut, welches in jedem Setter erhöht wird); aber deshalb an den fraglichen Stellen alles mit Timern zuschütten, passt mir auch nicht. :evil:

[dot]

Ja, das Problem kenn ich nur zu gut (vor allem aus C#). Wenn man sicherstellt, dass ein Event nur ausgelöst wird wenn sich auch tatsächlich was verändert hat, kann man die Sache meiner Erfahrung nach einigermaßen gut beherrschen. Ist aber nervig und geht natürlich auch nicht immer wirklich gut. Eine bessere Lösung hab ich aber leider auch nicht -.-

[CodingCat]

Ich meinte nicht mal die Überprüfung auf tatsächlich Änderung, sondern die Überprüfung, ob überhaupt Beobachter angemeldet sind (was im Falle von Entities in einer 3D-Welt wirklich fast nie der Fall sein sollte, geht vor allem um Tool-Unterstützung), um dann in dem außergewöhnlichen Fall, dass tatsächlich Objekte zuhören, eine entsprechende teurere (und non-inline) Benachrichtigungsfunktion mit einer Schleife über die Beobachter aufzurufen.

Allerdings werden Setters eigentlich auch gar nicht so oft aufgerufen. Die Zahl dynamischer Objekte hält sich in der Regel in Grenzen. Außerdem ist mir gerade ein positiver Nebeneffekt der Beobachterfunktionalität in den Sinn gekommen: Ich kann die Synchronisation selten veränderter "statische" Objekte vollständig aus dem Frameloop nehmen, was mir wesentlich mehr CPU-Zeit sparen dürfte, indem ich solche Objekte zu ihren eigenen Beobachtern mache und die Synchronisation hier nur auf Änderungsbasis durchführe.

[dot]

Ah, ja das Problem kenn ich auch nur zu gut ;)
Genau aus diesen Gründen bau ich eigentlich keine Event/Listener Systeme mehr. Wenn, dann gibts ein einfaches Listener-Interface, das Callbacks für alle Events bietet und jedes Objekt hat genau einen Pointer auf einen Listener. Wenn tatsächlich mal mehr als einer zuhören will (was auch meiner Erfahrung nach eher die Ausname als die Regel ist), dann soll der Listener sich ums Dispatchen kümmern.

Ein System wo es tatsächlich für jedes Event separate Signals/Slots gibt, halt ich für nutzlosen Overhead. Ich würd sogar so weit gehen, sowas als Fehldesign zu betrachten (Yes, I'm looking at you Qt, WinForms, ...).
Es mag zwar auf den ersten Blick praktisch aussehen, aber eigentlich regt sowas nur dazu an, unötig komplizierte Systeme mit völlig undurchschaubaren Abhängigkeiten zusammenzuklicken.
Und umgekehrt ergibt sich die Notwendigkeit so eines Systems erst, wenn das restliche Design bereits derart verstrickte Abhängigkeiten enthält.
Egal von welcher Seite man es betrachtet, gibt es also keinen Grund sowas zu machen, denn in einem sauberen Design hat man imo notwendigerweise maximal genau einen Listener und an allen Events den gleichen.

[CodingCat]

Ja, mein Beobachter ist auch ein einfaches Interface, und es gibt eins pro Objekt, nicht pro Eigenschaft. Allerdings sehe ich keinen Nachteil, beliebig viele Beobachter zu unterstützen, wenn die Funktionalität denn wirklich implementiert wird. Zumindest in dem Fall, in dem Beobachter äußerst selten sind, kommt mit einer einfach verketteten Liste im Schnitt auch nicht mehr als ein Zeiger an Datenoverhead hinzu. Den Signalcode möchte ich in diesem Fall so wie so nicht geinlinet haben, dann tut mir auch die Schleife nicht wirklich weh.

[dot]

Ja, rein technisch gesehen macht es auf den ersten Blick vielleicht keinen Unterschied. Ich find es aber vom designerischen Standpunkt aus absolut nicht gut.
Interessant wirds auch, wenn Multithreading das Spielfeld betritt. Denn dann willst du natürlich das Adden/Removen der Listener threadsafe gestalten. Zum Glück reicht eine einfach verkettete Liste, sowas ist relativ einfach ohne Locks hinzubekommen. Denn mit dem üblichen Mutex wäre man wohl eher schlecht beraten, das schreit nach Deadlock...

[CodingCat]

Ja, rein technisch gesehen macht es auf den ersten Blick vielleicht keinen Unterschied. Ich find es rein vom Design her einfach nicht gut.

Ja, das mag für sehr viele Bereiche, insbesondere UIs, zutreffen, in meinem Fall von vielen dezentral geteilten Objekten ist es jedoch ziemlich problematisch.

Momentan leide ich bisweilen auch so schon unter der wirklich äußerst losen Kopplung (das Design ist super, mancherorts leidet jedoch die Benutzbarkeit etwas darunter, dass noch Hilfsfunktionen fehlen, welche die explizite Kopplung vorbildlich gezielt für bestimmte Zwecke übernehmen). :mrgreen:

Thread-Safety ist für mich an dieser Stelle im Moment kein Thema, sollte ich Threads benötigen, werden sich diese ausschließlich auf isolierten Speicherbereichen oder unveränderlichen Versionen der geteilten Objekte bewegen.

[dot]

Ja, meine Erfahrungen beziehen sich da vor allem auf UIs.
Das mit den Threads wollt ich auch vorsichtshalber nur mal erwähnt haben. Ich hatte schon viel Spaß mit so Konstrukten, wo dann ein Event ausgelöst wird infolgedessen ein Listener sich selbst removen will oder etwas tut, dass ein anderes Objekt dazu veranlasst, seinen Listener zu removen. Zum Glück noch nie in Verbindung mit threading issues, aber ich kann mir vorstellen, dass man sich da sehr schnell Deadlocks zusammenschraubt bei denen man ohne tiefgreifendes Verständnis über die Innereien des Eventsystems kaum überhaupt auf die Idee kommt, mal dort nachzuschauen...

[CodingCat]

Ja, Event-Systeme sind einfach zu benutzen und bieten viel Funktionalität mit wenig Code, aber zu überblicken sind sie kaum. Ich musste in Qt auch schon mehrfach den Verbindungstyp von 'direkt' auf 'queued' umstellen, weil bei Message Box im zugehörigen Event eine Kaskade von Fokus-Events losging, die irgendwo tief in Qt für das vorzeitige Entfernen temporärer Objekte sorgte, wodurch das Programm unmittelbar nach Rückkehr des eigentlichen Events aufgrund von Folgezugriffen auf diese bereits gelöschten Objekte irgendwo anders tief in Qt mit einer Zugriffsverletzung abschmierte. Und das war single-threaded. ;-)

Aber über den Qt-Source wollte ich mich hier eigentlich gar nicht auslassen, aus diesem zustandsüberladenen Saustall habe ich ja schon oft genug live berichtet. :mrgreen:

[dot]

Haha, das hört sich richtig toll an. Freut mich, dass es nicht nur mir so geht :D

[CodingCat]

So, und jetzt hast du mich auch mal beim Edit erwischt. :D

[CodingCat]

Ich habe gerade 2 Stunden lang mit unzähligen Tools eine MS DOS 6-Boot-CD aus dem Internet und einen MSDN Academic Alliance MS DOS 6-Dateihaufen zu einem halbwegs bootbaren ISO-Abbild vermatscht, welches ich dann in Virtual Box als virtuelle Boot-CD laden konnte, um mit der Setup.EXE des Dateihaufens diesen endlich auf die virtuelle Festplatte zu installieren. Dem Original-Microsoft-Download einfach bootbare Diskettenabbilder beizulegen, wäre ja auch wirklich zu viel verlangt gewesen.

[CodingCat]

Ich möchte die Fehlerbenachrichtigung in der Tool-UI automatisieren. Bisher hatte ich an allen Stellen, an denen in der UI Fehler auftreten können, immer dasselbe Muster:

Code: Alles auswählen

bool error = true;

try
{
   // Operation mit ungewissem Ausgang
   error = false;
}
catch (const exception &error)
{
   // Messagebox mit Fehlermeldung inklusive Exception-String
}
catch (...)
{
   // Messagebox mit allgemeinerer Fehlermeldung
}

if (error)
   // Fehlerbehandlung

Das wird mir jetzt zu bunt, und ich bin zu folgendem übergegangen:

Code: Alles auswählen

try
{
   // Operation mit ungewissem Ausgang
}
catch (...)
{
   exceptionToMsg();
   // Fehlerbehandlung
}

// mit ...

void exceptionToMsg()
{
   try
   {
      throw;
   }
   catch (const exception &error)
   {
      // Messagebox mit Fehlermeldung inklusive Exception-String
   }
   catch (...)
   {
      // Messagebox mit allgemeinerer Fehlermeldung
   }
}

Hässlich, aber tut was es soll. Wenn ihr ne bessere Idee habt, sagt Bescheid. Und ja, ich weiß ganz sicher, dass die Engine immer nur runtime_error wirft, aber wer weiß, auf welche Ideen weiß Gott wer irgendwann mal kommt.

[joggel]

Blos mal ne Frage.
Die Zeile in der "exceptionToMsg"-Funktion die da lautet

Code: Alles auswählen

throw;

Damit wird sie, egal was für eine Exception es ist, "weiter geworfen"?
btw:
Finde ich eigentlich ne gute Lösung, zumal ich das hässlich finde, wenn man zig catch-blocks hat. Einfach einen (...)-Catch-Block und das spezielle Verhalten dann in eine Funktion auslagern.

@Jammern:
Ich glaube ich hab ne Grippe :(

[CodingCat]

Genau, throw in einem catch-Block wirft die zuletzt gefangene Exception erneut.

[joggel]

Ah okay. Danke!

[CodingCat]

Qt überzeugt mich seit zwei Stunden, dass es in Bezug auf die Behandlung von Fokus-Ketten und Tab-Order genauso unfähig ist wie all die anderen tollen UI Frameworks, in denen sich ach so toll Widgets beliebig in anderen Widgets gruppieren und zu logisch wertvollen Widget-Bäumen zusammenstecken lassen. Wie ich auch mit setFocusProxy(), setFocusPolicy(), setFocus() und setTabOrder() um mich werfe, Qt springt munter umher, und hierarchisch weitergeleitet wird schon dreimal nichts.

The User Moves the Focus to This Window
In this situation the application must determine which widget within the window should receive the focus.

This can be simple: If the focus has been in this window before, then the last widget to have focus should regain it. Qt does this automatically.

If focus has never been in this window before and you know where focus should start out, call QWidget::setFocus() on the widget which should receive focus before you call QWidget::show() it. If you don't, Qt will pick a suitable widget.

Ahahaha! Wie gut, dass Qt seine aufgeblasene Klassenhierarchie nicht nutzt, um sinnvolle gemeinsame Funktionalität überall zur Verfügung zu stellen. Stattdessen implementieren QMainWindow, QGroupBox und weiß Gott wer immer dieselbe Funktionalität. Wie auch der ganze Rest von Qt, der sich daran ergötzt, mit minimalem Code Reuse und maximaler Fehlertoleranz noch den letzten glücklichen UI-Programmierer in den Wahnsinn zu treiben.