Jammer-Thread
- Krishty
- Establishment
- Beiträge: 8343
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
Obwohl ich mich zurückgehalten habe, haben wir in den ersten fünf Monaten des laufenden Jahres fast so viel gejammert wie in den andernhalb Jahren davor. Und darum finde ich nun meinen 2¹⁰ten Beitrag nicht mehr, an den ich mich nochmal wehmütig zurückerinnern wollte, bevor ich den 2¹¹ten hinspamme :( Diesmal aber bloß nicht im Jammer-Thread, das wäre mir echt z…
Oh.
Oh.
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Jammer-Thread
Damit der Strom nicht abbricht: Der Visual C++ Compiler wertet __alignof(T) für kompliziertere Template-Konstrukte T manchmal mit 0 aus, wenn T mangels vorangegangener anderweitiger Nutzung intern noch nicht vollständig bestimmt ist. Abhilfe schafft eine Auswertung von sizeof(T) kurz vor __alignof(T):
Ein gravierender Fehler mit verblüffend einfachem Workaround, offenbar ist __alignof() auch nur irgendwie nachträglich reingehackt worden.
Nebenbei bemerkt: Der Compiler legt eine Maximallänge von 4096 Zeichen pro Bezeichner fest, was bei einigen geschachtelten typedefs schnell mal erreicht ist. Nun meckert er mir bei jedem Build mit entsprechenden Warnungen die Fehlerausgabe voll.
Code: Alles auswählen
/// Workaround for Visual Studio bug: Alignment of some template classes not available until size has been evaluated
template <size_t Size, size_t Alignment>
struct alignof_fix
{
STATIC_ASSERT(Size != 0U && Alignment != 0U);
static const size_t alignment = Alignment;
};
/// Emulated alignof using MSVC-specific alignof operator extension.
#define alignof(type) ::alignof_fix<sizeof(type), __alignof(type)>::alignment
Nebenbei bemerkt: Der Compiler legt eine Maximallänge von 4096 Zeichen pro Bezeichner fest, was bei einigen geschachtelten typedefs schnell mal erreicht ist. Nun meckert er mir bei jedem Build mit entsprechenden Warnungen die Fehlerausgabe voll.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Re: Jammer-Thread
Juhuuuu, kann auch mal Jammern:
Aaaaaalso:
Ich hasse Qt!
Ja, heute HASSE ich Qt so abgrund tief!
Nicht nur heute, nein, IMMER wenn ich irgendwie diese verf*** QTableWidget auf Content resizen will.
Diese bekloppte Ka*** funktioniert nie wie es soll! Was wird da intern gemacht, wenn man QTableWidget::resizeColumnToContents(int) aufruft? :?:
Und ich weigere mich den Grund dieses Verhaltens bei mir zu suchen!!!
Nochwas:
Und überhaupt... das eigenartige verhalten mit den Scrollbars :x .
Selbst im Qt-Designer is das einfach nur .... "besonders".
Aaaaaalso:
Ich hasse Qt!
Ja, heute HASSE ich Qt so abgrund tief!
Nicht nur heute, nein, IMMER wenn ich irgendwie diese verf*** QTableWidget auf Content resizen will.
Diese bekloppte Ka*** funktioniert nie wie es soll! Was wird da intern gemacht, wenn man QTableWidget::resizeColumnToContents(int) aufruft?
Code: Alles auswählen
QTableWidget::resizeColumnToContents(int col)
{
int newWidth(rand())
resizeColumnToSize(col,newWidth);
}
Und ich weigere mich den Grund dieses Verhaltens bei mir zu suchen!!!
Nochwas:
Und überhaupt... das eigenartige verhalten mit den Scrollbars :x .
Selbst im Qt-Designer is das einfach nur .... "besonders".
- Top-OR
- Establishment
- Beiträge: 330
- Registriert: 02.03.2011, 16:32
- Echter Name: Jens H.
- Wohnort: Esslingen/Dessau
- Kontaktdaten:
Re: Jammer-Thread
So, es ist Zeit, mich abzuholen!
Ich arbeite gerade an einem LOD-Feature für Objekte.
Seit ner guten Stunde suche ich nen Bug:
Alles klappt gut und läuft fein. Wenn ich das Objekt jedoch eine bestimmte Distanz bewege, verschwindet es plötzlich; in der Wasserspiegelung ist es noch da. Was nun?
Ich habe mich jetzt mit lustigen Modelview und Projektionsmatrizen rumgeschlagen. Ohne Erfolg.
Plötzlich fällt mir auf, dass ich beim Rendern des Objektes den Point-of-Interest mit (0,0,0) angebe, anstatt mit den Koordinaten der Kamera.
DAS war GEWOLLT: DAS IST ein FEATURE, was ich vor einiger Zeit eigebaut habe, welches Objekte in Abhängigkeit von Größe und Distanz zur Kamera nicht mehr rendert. Man muss eben nur die RICHTIGEN Koordinaten mitgeben... :shock: :shock: :shock:
Kann mir bitte jemand sagen, wo es GEHIRN zum Download gibt? Meins scheint alle zu sein ...
Ich arbeite gerade an einem LOD-Feature für Objekte.
Seit ner guten Stunde suche ich nen Bug:
Alles klappt gut und läuft fein. Wenn ich das Objekt jedoch eine bestimmte Distanz bewege, verschwindet es plötzlich; in der Wasserspiegelung ist es noch da. Was nun?
Ich habe mich jetzt mit lustigen Modelview und Projektionsmatrizen rumgeschlagen. Ohne Erfolg.
Plötzlich fällt mir auf, dass ich beim Rendern des Objektes den Point-of-Interest mit (0,0,0) angebe, anstatt mit den Koordinaten der Kamera.
DAS war GEWOLLT: DAS IST ein FEATURE, was ich vor einiger Zeit eigebaut habe, welches Objekte in Abhängigkeit von Größe und Distanz zur Kamera nicht mehr rendert. Man muss eben nur die RICHTIGEN Koordinaten mitgeben... :shock: :shock: :shock:
Kann mir bitte jemand sagen, wo es GEHIRN zum Download gibt? Meins scheint alle zu sein ...
--
Verallgemeinerungen sind IMMER falsch.
Verallgemeinerungen sind IMMER falsch.
- Krishty
- Establishment
- Beiträge: 8343
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
Viel gruseliger ist, dass mir ein quasi identischer Fehler vor einer halben Stunde passiert ist. Nur ohne Wasserreflexion.
Ist das ansteckend? Oder ist das der Ehec-Schnelltest, den sie heute entdeckt haben? Probant LOD schreiben lassen und wenn er den Betrachter auf 0;0;0 lässt, sofort mit der Behandlung beginnen?
Ist das ansteckend? Oder ist das der Ehec-Schnelltest, den sie heute entdeckt haben? Probant LOD schreiben lassen und wenn er den Betrachter auf 0;0;0 lässt, sofort mit der Behandlung beginnen?
- Top-OR
- Establishment
- Beiträge: 330
- Registriert: 02.03.2011, 16:32
- Echter Name: Jens H.
- Wohnort: Esslingen/Dessau
- Kontaktdaten:
Re: Jammer-Thread
Es ist Zeit, mit erhobenen Armen schreiend im Kreis zu laufen!
EDIT: Frag sich bloss, welche Behandlung? Ich hab da letztens am Krankenhaus sonen Förster mit Flinte rumlaufen sehen ...
EDIT: Frag sich bloss, welche Behandlung? Ich hab da letztens am Krankenhaus sonen Förster mit Flinte rumlaufen sehen ...
--
Verallgemeinerungen sind IMMER falsch.
Verallgemeinerungen sind IMMER falsch.
- Chromanoid
- Moderator
- Beiträge: 4286
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Jammer-Thread
Die deutschen bibtex styles dinat und natdin sind für die Katz. Es wird zwar die Bandnummer angegeben, aber der Reihenname wird weggelassen und Herausgeber werden nicht nur drei sondern alle aufgelistet :evil: und diese komische sprache mit der die styles gemacht sind, ist widerlich zu lesen.
-
- Moderator
- Beiträge: 2151
- Registriert: 25.02.2009, 13:37
Re: Jammer-Thread
apastyle ftw
- Chromanoid
- Moderator
- Beiträge: 4286
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Jammer-Thread
Joa, habe mir jetzt apalike lokalisiert... Naja die DIN finde ich eigentlich nicht schlecht, schade nur, dass es keinen sauberen style dafür gibt.
- Schrompf
- Moderator
- Beiträge: 5153
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: Jammer-Thread
HASSSSSSS. Irgendwo in den Redmine-Sourcen, 20 Ruby Gems, Ruby selbst, Ajax, Javascript, Apache oder sonstwo hängt ein Fehler, der dafür sorgt, dass Redmine beim Einloggen mit einer Fehlermeldung abkackt. Mit der Fehlermeldung findet Google ein Rudel Bugtracker-Einträge, die die Autoren von Redmine auf "Won't fix" gestellt haben. Zusammen dem diffusen Hinweis, dass ja evtl. Rake 1.5.20 einen Fehler enthält, oder AJAX in der FeuchteTüten-Version, oders Rails <2.3.10, aber unbedingt nicht mehr als 2.3.15 benutzen!!! Aktuell ist ja die 3.0.5, aber die können wir auch nicht leiden...
Ich schmeiß jetzt alles wieder runter und nehm eine Fertig-Install. Ich hab so die Schnauze voll von diesem Mist. Wenn man 20 nicht ganz planare Bausteine aufeinanderstapelt, dann wackelt es halt irgendwann. Das weiß jedes Kind. Webentwickler aber finden das anscheinend geil.
Ich schmeiß jetzt alles wieder runter und nehm eine Fertig-Install. Ich hab so die Schnauze voll von diesem Mist. Wenn man 20 nicht ganz planare Bausteine aufeinanderstapelt, dann wackelt es halt irgendwann. Das weiß jedes Kind. Webentwickler aber finden das anscheinend geil.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Jammer-Thread
Und das, das war noch gar nichts. Ab Windows 8 werden Desktop-Anwendungen in HTML5 und JavaScript geschrieben. Endlich keine lästigen Compiler-Fehler mehr.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
- Krishty
- Establishment
- Beiträge: 8343
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
Nach 13 Tagen Laufzeit ist mein Rechner nun doch noch abgestürzt
Offenbar reichten die zwölf Neuinstallationen, acht Treiberaktualisierungen und zwei Firmware-Updates, die ich heute durchgeführt habe, aus, um den Ruhezustand inkonsistent werden zu lassen
Offenbar reichten die zwölf Neuinstallationen, acht Treiberaktualisierungen und zwei Firmware-Updates, die ich heute durchgeführt habe, aus, um den Ruhezustand inkonsistent werden zu lassen
- dot
- Establishment
- Beiträge: 1746
- Registriert: 06.03.2004, 18:10
- Echter Name: Michael Kenzel
- Kontaktdaten:
Re: Jammer-Thread
Ich habs grad gesehn und kann mir irgendwie nicht vorstellen damit effizient zu arbeiten. Von mir aus auf meinem Handy oder Tablet, aber doch bitte nicht auf meinem PC. Ich vermut aber auch mal dass es genau dafür gedacht is (bedenkt man dass ARM als neue Plattform dazugekommen ist), den normalen Desktop wirds ja zum Glück weiterhin geben sonst wär Windows 8 ja wohl effektiv unbrauchbar...CodingCat hat geschrieben:Und das, das war noch gar nichts. Ab Windows 8 werden Desktop-Anwendungen in HTML5 und JavaScript geschrieben. Endlich keine lästigen Compiler-Fehler mehr.
- Chromanoid
- Moderator
- Beiträge: 4286
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Jammer-Thread
Maven ist nervig :evil:
- Krishty
- Establishment
- Beiträge: 8343
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
Als ich letztens nach Chromes GPU-Problemen gesurft habe, bin ich über dieses Ticket gestolpert. Es geht darum, dass die GPU-Beschleunigung bei neuen Tabs abgeschaltet werden soll – weil die Erzeugung eines Direct3D-Kontextes eine „significant latency (~0.5 sec)“ bedeuten würde.
Ich dachte erst, die seien bekloppt: Meine Anwendung hier erzeugt ein Fenster, ein Direct3D-Device, lädt eine Handvoll Dateien, rendert den Inhalt des ersten Frames und zeigt diesen an – in durchschnittlich 0,11, minimal 0,105 s. Und ist dabei absolut nicht synthetisch und – man höre und staune – an ihren Flaschenhälsen gänzlich unoptimiert.
Ich habe dann versucht, die Startzeit ein wenig zu drücken. Und es ging nicht. Diese Typen hatten nämlich vollkommen recht: Einen Direct3D-Kontext zu erzeugen bedeutet eine gewaltige Verzögerung. Von den 0,105 s Initialisierungszeit verbrachte die Anwendung nämlich 0,09 s mit der Initialisierung des Direct3D 9-Devices.
Da war ich echt baff – sogar mit Lazy Loading von Texturen aus Dateien war das Rendern des ersten Frames absolut verschwindend gering gegenüber der Initialisierung.
Nun ist Direct3D 9 langsamer als 11 und bei 11 hat man nicht die vielen API-Aufrufe um zu prüfen, welche Features unterstützt werden; da ist das sicher ein wenig schneller. Aber ich kann mich erinnern, dass die Ladezeit gefühlt deutlich verkürzt wurde, als ich auf vorkompilierte Shader umgestiegen bin. Ich vermute mal, dass das Kompilieren von Shadern ähnlich lang dauert wie das leidige Initialisieren des Direct3D-Devices (aber zum Benchen habe ich keine Zeit mehr). Und wenn man dann keinen Core i7 am strampeln hat sondern irgendeine alte Karre, sind Hopfen und Malz verloren.
tl;dr: D3D zu initialisieren ist scheiße lahm, erst recht, wenn man seine Shader von HLSL kompiliert.
Ich dachte erst, die seien bekloppt: Meine Anwendung hier erzeugt ein Fenster, ein Direct3D-Device, lädt eine Handvoll Dateien, rendert den Inhalt des ersten Frames und zeigt diesen an – in durchschnittlich 0,11, minimal 0,105 s. Und ist dabei absolut nicht synthetisch und – man höre und staune – an ihren Flaschenhälsen gänzlich unoptimiert.
Ich habe dann versucht, die Startzeit ein wenig zu drücken. Und es ging nicht. Diese Typen hatten nämlich vollkommen recht: Einen Direct3D-Kontext zu erzeugen bedeutet eine gewaltige Verzögerung. Von den 0,105 s Initialisierungszeit verbrachte die Anwendung nämlich 0,09 s mit der Initialisierung des Direct3D 9-Devices.
Da war ich echt baff – sogar mit Lazy Loading von Texturen aus Dateien war das Rendern des ersten Frames absolut verschwindend gering gegenüber der Initialisierung.
Nun ist Direct3D 9 langsamer als 11 und bei 11 hat man nicht die vielen API-Aufrufe um zu prüfen, welche Features unterstützt werden; da ist das sicher ein wenig schneller. Aber ich kann mich erinnern, dass die Ladezeit gefühlt deutlich verkürzt wurde, als ich auf vorkompilierte Shader umgestiegen bin. Ich vermute mal, dass das Kompilieren von Shadern ähnlich lang dauert wie das leidige Initialisieren des Direct3D-Devices (aber zum Benchen habe ich keine Zeit mehr). Und wenn man dann keinen Core i7 am strampeln hat sondern irgendeine alte Karre, sind Hopfen und Malz verloren.
tl;dr: D3D zu initialisieren ist scheiße lahm, erst recht, wenn man seine Shader von HLSL kompiliert.
Re: Jammer-Thread
Das wird bei den anderen APIs genauso sein....GLES, VG, CL....Resourcenerzeugung ist nunmal etwas aufwaendiger. Was mich eher wundert ist der Vorschlag, es deswegen abzuschalten. Eh ich meine Favoriten gewaehlt oder gar eine Adresse eingetippelt habe, sind 0,1 s locker vorbei. Und fuer das Darstellen eines weissen Hintergrundes kann ich auch eine 2D-API akzeptieren, solange die Erzeugung eines GPU-Kontexts im Hintergrund noch nicht abgeschlossen ist.
PS: Schon mal OpenCL-Kontext-Erzeugung gemessen? Da sind deine 0,1 nuescht dagegen. 2 s bei mir....sei froh, dass Du nur 1 API nutzt.
PS: Schon mal OpenCL-Kontext-Erzeugung gemessen? Da sind deine 0,1 nuescht dagegen. 2 s bei mir....sei froh, dass Du nur 1 API nutzt.
- Krishty
- Establishment
- Beiträge: 8343
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
Mag ja sein, dass das immer kostet – aber wenn die Zeit, den GPU-Context zu erzeugen, die Zeit, die das Betriebssystem braucht um einen CPU-Context zu erzeugen und alle benötigten Abhängigkeiten und Ressourcen zu laden um das Zehnfache übertrifft, zweifle ich daran, dass es nicht schneller ginge.
Übrigens braucht die Kompilierung eines einfachen Vertex Shaders zu HLSL schon 0,03 s; d.h. drei Shader zu kompilieren dauert ähnlich lange wie das Erzeugen des GPU-Context. Ich wüsste zu gern, was der Compiler da macht. Oder vielleicht doch nicht; besser für meinen Blutdruck.
Übrigens braucht die Kompilierung eines einfachen Vertex Shaders zu HLSL schon 0,03 s; d.h. drei Shader zu kompilieren dauert ähnlich lange wie das Erzeugen des GPU-Context. Ich wüsste zu gern, was der Compiler da macht. Oder vielleicht doch nicht; besser für meinen Blutdruck.
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Jammer-Thread
Ein halbwegs kontrollierbares __FILE__-Makro ist ja wohl wirklich zu viel verlangt. Also in jede Datei ein #line __LINE__ "filename.cpp" an den Anfang setzen und damit IntelliSense in den Wahnsinn treiben. I love my Visual Studio.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Jammer-Thread
WOW! 2 Stunden zum Fenster raus, um diese seltsamen WinAPI-oder-wasimmer-Ressourcen zusammen mit einer statischen Bibliothek in eine Anwendung einzubinden. Automatisch geht das natürlich nur bei DLLs und EXEs, letztlich kann man jedoch einfach die in resource.res-Objektcode vorkompilierte Ressourcen-Datei (resource.rc) mit der zugehörigen statischen Bibliothek in den Linker werfen (diesen Vorschlag macht mal wieder ein stackoverflow.com-Post, was würde ich nur ohne dieses Portal machen).
Und bevor hier jetzt wieder jemand kommt, sowas gäbe es nur im antiquierten nativen C++, dass man sich länger mit Linking beschäftig als mit der eigentlichen Programmierung - Pustekuchen, das Einbinden und Auffinden von Ressourcendateien hat mich schon auf jeder verdammten Plattform, die ich bis jetzt getestet habe (u.a. C# Win Forms / WPF, Java Swing) Tage gekostet, sobald die Dinge nicht mehr dort lagen, wo sie in jeder verkackten Easy-Peasy-Einmodul-Beispiel-Anwendung liegen.
Und bevor hier jetzt wieder jemand kommt, sowas gäbe es nur im antiquierten nativen C++, dass man sich länger mit Linking beschäftig als mit der eigentlichen Programmierung - Pustekuchen, das Einbinden und Auffinden von Ressourcendateien hat mich schon auf jeder verdammten Plattform, die ich bis jetzt getestet habe (u.a. C# Win Forms / WPF, Java Swing) Tage gekostet, sobald die Dinge nicht mehr dort lagen, wo sie in jeder verkackten Easy-Peasy-Einmodul-Beispiel-Anwendung liegen.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
- Krishty
- Establishment
- Beiträge: 8343
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
Resource const & resource() {
unsigned char const data[2875536] = { … };
return *reinterpret_cast<Resource const *>(data);
}
1995 hat uns solche Probleme beschert, also werden sie auch wie 1995 gelöst
unsigned char const data[2875536] = { … };
return *reinterpret_cast<Resource const *>(data);
}
1995 hat uns solche Probleme beschert, also werden sie auch wie 1995 gelöst
- CodingCat
- Establishment
- Beiträge: 1857
- Registriert: 02.03.2009, 21:25
- Wohnort: Student @ KIT
- Kontaktdaten:
Re: Jammer-Thread
Ich habe leider keinen blassen Schimmer, wo ich diese Byte-Daten herbekomme, Dialogboxen liegen vor dem Kompilieren in Form von Resource-Script vor, nach dem Kompilieren mit viel Glück als DLGITEMTEMPLATE-Bytes irgendwo im *.res-Objektcode. CreateDialogIndirect erwartet genau diese gefüllten WinAPI-Strukturen, deren Byte-Repräsentation ich jedoch wohl erstmal zeitintensiv zusammenkratzen müsste.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
- Krishty
- Establishment
- Beiträge: 8343
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
Irgendwo wird das Format ja dokumentiert sein. Zur Not einfach selber mit dem Hex-Editor ran. Und wenn du richtig 1337 bist, baust du dir noch einen Preprocessor, der in dem ganzen Kram Redundanzen sucht und zusammenfasst. So habe ich selbst bei PCM-Audio noch 6 % gespart.
Du solltest dir natürlich sicher sein, dass sich die Ressourcen so selten wie möglich ändern werden. Aber Entwürfe packt man ja auch nicht als erstes in statische Bibliotheken.
Oh und: Oben habe ich vergessen, das static zu deklarieren. Ich dumm. Mache es normalerweise ohne die Wrapper-Funktion.
Du solltest dir natürlich sicher sein, dass sich die Ressourcen so selten wie möglich ändern werden. Aber Entwürfe packt man ja auch nicht als erstes in statische Bibliotheken.
Oh und: Oben habe ich vergessen, das static zu deklarieren. Ich dumm. Mache es normalerweise ohne die Wrapper-Funktion.
- Krishty
- Establishment
- Beiträge: 8343
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
(Quelle)Der frühere Kopf der Eclipse-Entwicklung und Design-Patterns-Autor Erich Gamma wird ab August bei Microsoft das Visual-Studio-Entwicklerteam unterstützen.
Ich saug’ dann mal Code::Blocks
Re: Jammer-Thread
Die Wahl zwischen Pest und Cholera. Wobei ich zwangsweise Eclipse für Python verwende, da das Visual Studio Python-Plugin bei 'yield'-Statements abschmiert :evil:. Dabei mag ich Generatoren so gerne.
Und zu GPU-Kontexten: duration([](){init(OpenGL);init(OpenCL);init(Direct3D9);}) = ?
Und noch mehr: unser Router von 2003 ist der Meinung, dass mehr als 5 parallele Verbindungen SYN-flood darstellen. Der wird bald in Rente gehen.
Und zu GPU-Kontexten: duration([](){init(OpenGL);init(OpenCL);init(Direct3D9);}) = ?
Und noch mehr: unser Router von 2003 ist der Meinung, dass mehr als 5 parallele Verbindungen SYN-flood darstellen. Der wird bald in Rente gehen.
- Chromanoid
- Moderator
- Beiträge: 4286
- Registriert: 16.10.2002, 19:39
- Echter Name: Christian Kulenkampff
- Wohnort: Lüneburg
Re: Jammer-Thread
Netbeans ftw :) ups hab gerade gesehen, dass python erst mal nicht mehr unterstützt wird ^^ schade...
- Top-OR
- Establishment
- Beiträge: 330
- Registriert: 02.03.2011, 16:32
- Echter Name: Jens H.
- Wohnort: Esslingen/Dessau
- Kontaktdaten:
Re: Jammer-Thread
WAAAAAAAAAAAAAAS? Och nööööö ....Krishty hat geschrieben:(Quelle)Der frühere Kopf der Eclipse-Entwicklung und Design-Patterns-Autor Erich Gamma wird ab August bei Microsoft das Visual-Studio-Entwicklerteam unterstützen.
Ich saug’ dann mal Code::Blocks
Gute Entscheidung: Code::Blocks benutze wir in der Firma für unseren Linux/C/C++-Krams.
Vor einigen Jahren war ich privat auch mal auf nem Bloodshed Dev-C++-Trip, weiß aber nicht, wie es da heute aussieht. Bestimmt nicht so gut ... Vielleicht ist Chinook noch ne Alternative?
Eclipse nutzen wir für unseren Java Kram und es gibt keine Schimpfworte und Kraftausdrücke, die die negativen Gefühle ausdrücken, die ich öfters habe, wenn ich mit ECLIPSE arbeiten darf.
Sicher, Assistenten und Wizards gibts da für jeden Dreck. Es gibt bestimmt nen passenden Assistenzen, der auf Knopfdruck SOFORT GENAU den PROGRAMMCODE für GENAU DAS PROBLEM erzeugt, welches ich gerade bearbeite, aber diese Assistent stürzt gern ab bzw. "rebuildet danach den workspace".
Und Autovervollständigung gibts auch ... Die vervollständigt jedoch nur das, was du gerade NICHT brauchst bzw. ist unvollständig. Vielleicht mal den Workspace rebuilden ....
Ich hatte teilweise bei Ecplise angebliche Probleme bei abhängigen Packages. Rebuilden half nix. Workspace manuell entleeren und Sourcen neu hinzufügen hat dann plötzlich geholfen - quasi der manuelle rebuild des Workspace. Naja, wahrscheinlich bin ich zu blöde oder mir fehlt das Java-Eclipse-Gen.
R.I.P. Visual Studio .... ich werde dich vermissen!
--
Verallgemeinerungen sind IMMER falsch.
Verallgemeinerungen sind IMMER falsch.
-
- Establishment
- Beiträge: 324
- Registriert: 08.04.2003, 18:09
- Alter Benutzername: Enrico_
- Echter Name: Enrico
- Wohnort: San Diego
- Kontaktdaten:
Re: Jammer-Thread
SlickEdit ist eine super Sache. Kostet halt ein bischen Geld...
Privat bin ich bei vim + clang (oder cscope), Eclipse weigert sich permanent, den Code richtig zu parsen und damit funktionieren dann die restlichen Features kaum noch...
So, ich jetzt auch: Netzwerk kaputt und schon sitzen 100+ Entwickler rum und können nicht mehr arbeiten. Jarrrr, das richtige VCS macht sowas möglich :evil:
Privat bin ich bei vim + clang (oder cscope), Eclipse weigert sich permanent, den Code richtig zu parsen und damit funktionieren dann die restlichen Features kaum noch...
So, ich jetzt auch: Netzwerk kaputt und schon sitzen 100+ Entwickler rum und können nicht mehr arbeiten. Jarrrr, das richtige VCS macht sowas möglich :evil:
Ein Hoch auf uns Männer... Auf die Frau, die uns HAT ( oder hat, und nicht weiß, dass sie uns hat ) ...auf die Idiotinnen ... besser gesagt VOLLPFOSTINNEN ... die uns hatten und uns verloren haben ... und auf die GLÜCKLICHEN, die das Vergnügen & Glück haben werden uns kennenzulernen!
- Schrompf
- Moderator
- Beiträge: 5153
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: Jammer-Thread
Vor geraumer Weile hat hier Krishty über die implizite Konvertierung von enums zu int geschimpft, weil die ihm die Funktionsüberladung versaut hat. Ich bin hier gerade über "Strongly typed enumerations" gestolpert, die ein Feature von C++0x sind. Ist angeblich schon seit Visual Studio 2008 implementiert, der GCC hat es seit der 4.4. Das wäre also eine sympathisch einfache und mehrdeutigkeitsfreie Lösung für das damalige Problem.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
- Krishty
- Establishment
- Beiträge: 8343
- Registriert: 26.02.2009, 11:18
- Benutzertext: state is the enemy
- Kontaktdaten:
Re: Jammer-Thread
Aber nur in C++/CLI <hier beliebiges Pupsgeräusch einfügen>. Dennoch danke für die Anteilnahme :)Schrompf hat geschrieben:Ist angeblich schon seit Visual Studio 2008 implementiert
- Schrompf
- Moderator
- Beiträge: 5153
- Registriert: 25.02.2009, 23:44
- Benutzertext: Lernt nur selten dazu
- Echter Name: Thomas
- Wohnort: Dresden
- Kontaktdaten:
Re: Jammer-Thread
Nein, nach meinem Wissen seit VC2010 auch im normalen C++.Krishty hat geschrieben:Aber nur in C++/CLI <hier beliebiges Pupsgeräusch einfügen>. Dennoch danke für die Anteilnahme :)Schrompf hat geschrieben:Ist angeblich schon seit Visual Studio 2008 implementiert
[edit] Mein Kommentar bezog sich auf http://blogs.msdn.com/b/vcblog/archive/ ... table.aspx - ich bastle jetzt hier aber gerade damit rum und Visual Studio spuckt mir verschiedene spannende Fehlermeldungen an den Kopf. Es scheint, als wäre der Support dafür doch noch nicht drin und der verlinkte Beitrag hätte gelogen.
Zuletzt geändert von Schrompf am 07.06.2011, 18:54, insgesamt 1-mal geändert.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.