Jammer-Thread

Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Jammer-Thread

Beitrag von CodingCat »

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):

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
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.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
joggel

Re: Jammer-Thread

Beitrag von joggel »

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?

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".
Benutzeravatar
Top-OR
Establishment
Beiträge: 330
Registriert: 02.03.2011, 16:32
Echter Name: Jens H.
Wohnort: Esslingen/Dessau
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Top-OR »

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 ...
--
Verallgemeinerungen sind IMMER falsch.
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

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?
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Top-OR
Establishment
Beiträge: 330
Registriert: 02.03.2011, 16:32
Echter Name: Jens H.
Wohnort: Esslingen/Dessau
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Top-OR »

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 ...
--
Verallgemeinerungen sind IMMER falsch.
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4263
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Jammer-Thread

Beitrag von Chromanoid »

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.
Alexander Kornrumpf
Moderator
Beiträge: 2119
Registriert: 25.02.2009, 13:37

Re: Jammer-Thread

Beitrag von Alexander Kornrumpf »

apastyle ftw
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4263
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Jammer-Thread

Beitrag von Chromanoid »

Joa, habe mir jetzt apalike lokalisiert... Naja die DIN finde ich eigentlich nicht schlecht, schade nur, dass es keinen sauberen style dafür gibt.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4884
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Schrompf »

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.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Jammer-Thread

Beitrag von CodingCat »

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
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

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
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Jammer-Thread

Beitrag von dot »

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.
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...
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4263
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Jammer-Thread

Beitrag von Chromanoid »

Maven ist nervig :evil:
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Jörg
Establishment
Beiträge: 296
Registriert: 03.12.2005, 13:06
Wohnort: Trondheim
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Jörg »

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.
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Jammer-Thread

Beitrag von CodingCat »

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
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Jammer-Thread

Beitrag von CodingCat »

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.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

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
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Jammer-Thread

Beitrag von CodingCat »

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
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Der frühere Kopf der Eclipse-Entwicklung und Design-Patterns-Autor Erich Gamma wird ab August bei Microsoft das Visual-Studio-Entwicklerteam unterstützen.
(Quelle)

Ich saug’ dann mal Code::Blocks
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
anonym
Beiträge: 79
Registriert: 15.07.2009, 07:35
Kontaktdaten:

Re: Jammer-Thread

Beitrag von anonym »

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.
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4263
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Jammer-Thread

Beitrag von Chromanoid »

Netbeans ftw :) ups hab gerade gesehen, dass python erst mal nicht mehr unterstützt wird ^^ schade...
Benutzeravatar
Top-OR
Establishment
Beiträge: 330
Registriert: 02.03.2011, 16:32
Echter Name: Jens H.
Wohnort: Esslingen/Dessau
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Top-OR »

Krishty hat geschrieben:
Der frühere Kopf der Eclipse-Entwicklung und Design-Patterns-Autor Erich Gamma wird ab August bei Microsoft das Visual-Studio-Entwicklerteam unterstützen.
(Quelle)

Ich saug’ dann mal Code::Blocks
WAAAAAAAAAAAAAAS? Och nööööö ....

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.
glassbear
Establishment
Beiträge: 324
Registriert: 08.04.2003, 18:09
Alter Benutzername: Enrico_
Echter Name: Enrico
Wohnort: San Diego
Kontaktdaten:

Re: Jammer-Thread

Beitrag von glassbear »

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:
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!
Benutzeravatar
Schrompf
Moderator
Beiträge: 4884
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Schrompf »

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.
Benutzeravatar
Krishty
Establishment
Beiträge: 8268
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Schrompf hat geschrieben:Ist angeblich schon seit Visual Studio 2008 implementiert
Aber nur in C++/CLI <hier beliebiges Pupsgeräusch einfügen>. Dennoch danke für die Anteilnahme :)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Schrompf
Moderator
Beiträge: 4884
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Schrompf »

Krishty hat geschrieben:
Schrompf hat geschrieben:Ist angeblich schon seit Visual Studio 2008 implementiert
Aber nur in C++/CLI <hier beliebiges Pupsgeräusch einfügen>. Dennoch danke für die Anteilnahme :)
Nein, nach meinem Wissen seit VC2010 auch im normalen C++.

[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.
Antworten