Jammer-Thread

[Aramis]

Ja ok, das kann natuerlich sein.

[Helmut]

Hach, das waren noch Zeiten, als der Überlauf von GetTickCount() alle möglichen Anwendungen geschrottet hat. Seit Vista und 7 schafft mein Rechner nur noch ne Woche Uptime, vielleicht zwei, bis aus den verschiedensten Gründen neugetartet werden muss...

[kimmi]

Ich kriegen einen Hals. Kaum ist die Garantie abgelaufen, raucht mir meine Kiste ab und ich steh im Wald. Selbstredenderweise passiert das natürlich erst dann, wenn man überhaupt keine Zeit hat, das Problem zu lösen! *Superrumgrummel*...

Gruß Kimmi

[Krishty]

cout << (0 == NumberOfSymbols) ? '-' : '+';
cout << Name << endl;

1Global Namespace
  0Symbol A
  1Symbol B
    0Symbol C

[Jörg]

Operator-Vorrang-Folge?

[eXile]

cout << (0 == NumberOfSymbols) ? '-' : '+';
cout << Name << endl;

1Global Namespace
  0Symbol A
  1Symbol B
    0Symbol C

Bastelsts mal wieder an Reflectionzeugs, gell? (Oder an einem Tool, welches alle deine Symbole übersichtlich auflistet, so dass man überprüfen kann, ob alle nicht benötigten Symbole rausgeflogen sind.) ;)

[Krishty]

Operator-Vorrang-Folge?

Japp. Man beachte, dass es nicht kompiliert hätte, wenn ich das << Name direkt dahinter geschrieben hätte – aber ich fand die Zeile eben schon unübersichtlich genug (im Original war die Null-Abfrage etwas länger); bittere Ironie.

Bastelsts mal wieder an Reflectionzeugs, gell?

Was heißt hier, „mal wieder“? :D War nur das erstbeste Beispiel, was mein sich über C++ ärgernder Verstand parat hatte.

[AnfängerProgammierer]

Hey leute,
möchte jetzt auch mal jammern :D
hab ja letzt mal wieder angefangen zu coden,
benutze die Visual C++ 2008 Express Edition.
Und hab alles normal gemacht, und jetzt kommt immer:
Da fehlt aber ja #include <stdafx.h>!
Aber bis jetzt hab ich immer nur iostream.h eingebunden??

Kann mir nohmal jemand sagen was ich genau machen muss? Neues Projekt -> Win32-Konsolenanwendung -> udn dann einfach fertigstellen? weil wenn man eine Win32-Konsolenanwendung erstellt, kommt ja erstmal ncoh so ein Fenster, wo man noch einstellungen ändern kann, aber wenn ich dann wie im buch beschrieben, ein leeres projekt wähle, kann ich das projekt nicht öffnen.

Was hab ich falsch gemacht?
Will einfach eine Konsolenanwendung machen.

Freue mich ber Antworten?
MfG


PS: Fühle mich hier schon wieder als Noob. Alle so, bei mir läuft das schief, das,...

und ich weiß nichtmal wie ich ANFANGE zu coden :D

[Jörg]

Dein Projekt wird wohl auf "vorkompilierte Header" eingestellt sein...also entweder stdafx.h einbinden, das ganze abschalten oder entsprechend auf einen Dir genehmen Namen einstellen.

[Krishty]

Projekteigenschaften -> C/C++ -> Precompiled Headers -> Precompiled Header leeren
Da war ich auch schonmal ;)

[AnfängerProgammierer]

EDIT:entschuldigung: funktionert schon :D hab nur nicht bemerkt das die fehler die angezeit wurden, garnet fehler waren die an dem header liegen, sondern am code :D da stand einfach ein float ohne einen namen rum :D

Also danke : funktioniert jetzt wieder!

Also jetzt eigentlich sinnlos:

habs geändert.
Projekt -> "Projektname"-Eigenschaften -> C/C++ -> Vorkomplimierte Header -> vorkompilierte Header nicht verwenden.
funzt aber trotzdem nicht.

[dowhilefor]

Ich muss hier auch mal mit machen :(

Ich hasse WPF! Wieso kann man nicht mehr wie früher GUIs programmieren?
Ständig alles verzögert, Controls im Code zu erzeugen ist die reinste Qual, bindings/styles/templates die später aufgelöst werden. verbuggtes DragAndDrop, Expression Blend mit unseren WPF Controls zusammen zubringen eine Unmöglichkeit, XAML Editor in VS sowieso für die Katz. Um performance aus WPF zu holen wenn man mal ein paar Controls mehr hat endet mit grauen Haaren.
Hach früher war alles besser ich vermisse all die ganzen WinAPI, MFC, wxWidgets, QT und WinForms ausflüge meiner Vergangenheit.


musste auch mal sein hihi

[eXile]

Moment, seit wann sind die Bäume von der Startseite weg?!

Jetzt muss ich mir ein Greasemonkey-Skript basteln, dass das wieder rückgängig macht …

[Krishty]

Ich sollte es dowhilefor gleichtun und Pro und Kontra je im entsprechenden Thread posten, aber da das zu sehr verwoben ist und ich Wehleidigkeit bevorzuge, nur hier:

Gut ist, dass der App-Verifier tatsächlich noch eine Zugriffsverletzung sieben Bytes hinter einem allokierten Heap-Block gefunden hat … der Bug war alles andere als offensichtlich, da ganz weit unten in der Speicherverwaltung (in einem Dschungel aus Integerarithmetik auf Zeigern).

Schlecht ist, dass all dieser äußerst menschenfeindliche Code überhaupt erst nötig ist, weil die WinAPI in ihren Heap*-Funktionen keinen Alignment-Support anbietet. Und dass ich deshalb 16 Bytes und 20 Mnemonics Overhead pro Allokation, Reallokation und Freigabe habe. Und dass das alles komplett unnötig ist, weil die WinAPI intern sowieso nur ausgerichtet arbeitet und die unausgerichteten Zeiger, die ich bekomme, wohl nur dafür da sind, damit ich mich brav an die Spezifikation halte. So sehr ich auch MS-Fanboy bin, diesen Aspekt haben sie in jeder Hinsicht verkackt, über mittlerweile ein Jahrzehnt hinweg, und es wird von Tag zu Tag schlimmer.

Edit: Und direkt weiter: Von x64 aus LoadLibrary(Ex)() aufzurufen resultiert in neun von zehn Versuchen in einem Stack-Overflow durch eine Endlosschleife zwischen verifier.dll, shell32.dll und ntdll.dll und im verbleibenden Fall in
AVRF: Core.exe: pid 0xC44: flags 0x80643267: application verifier enabled
AVRF: Exception during verifier.dll init for Core.exe with flags 0x80643267.
AVRF: exception raised in provider verifier.dll initialization routine
… echt fantastisch. Falls es tatsächlich ein Fehler meinerseits ist, habe ich absolut null Anhaltspunkte.

Edit2: Yeeeaaaah. Durch viel Raterei und blasse Erinnerung an irgendeine Empfehlung weiß ich jetzt, dass es böse ist, DLLs von relativen Pfaden zu laden. Warum der Verifier es unter x86 weiterhin zulässt und unter x64 mit einem Stapelüberlauf quittiert statt mit einer Fehlermeldung, weiß hingegen bestimmt niemand.

[Schrompf]

Will auch mal wieder jammern, wenn auch ganz plump:

Manche NVidia-Grafikkarten unterstützen kein anisotropisches Filtern. Wir reden hier nicht von einer Geforce 4 MX oder sowas, sondern von recht aktueller DX10-fähiger Hardware, genauer einer NVidia Quadro NVS 290. Ok, es ist eine kleine Karte, aber sie unterstützt GeometrieShader und den ganzen Scheiß... warum nicht sowas Primitives wie Anisotropisches Filtern? Man kann sich hier echt auf nix verlassen, selbst wenn man nur plump DX9-Vertex und -Pixel auf den Bildschirm bringt.

[Krishty]

Wtf … D3D10-fähige Hardware muss 4×AA unterstützen, aber AF darf sie weglassen?!? Krass.

AF ist sowieso ein sehr, sehr ungeschickt umgesetztes Feature. Dass die Treibereinstellung die Spieleinstellung überschreibt sorgt für sehr schwer auffindbare Fehler, wenn man Lookup-Tables benutzt – diese Fälle zu erkennen ist sauschwierig, es dann abzuschalten unmöglich.

[eXile]

Edit: Und direkt weiter: Von x64 aus LoadLibrary(Ex)() aufzurufen resultiert in neun von zehn Versuchen in einem Stack-Overflow durch eine Endlosschleife zwischen verifier.dll, shell32.dll und ntdll.dll

Dürfte ich hier noch fragen, ob überhaupt noch deine DllMain aufgerufen wurde? Wenn ja: Was machst du dort? Generell sollte man in der DllMain eigentlich nichts machen, was nicht wirklich unbedingt nötig ist - was häufig sehr sehr wenig ist. Ich kopiere hier einfach mal schamlos:

You should never perform the following tasks from within DllMain:

• Call LoadLibrary or LoadLibraryEx (either directly or indirectly). This can cause a deadlock or a crash.
• Synchronize with other threads. This can cause a deadlock.
• Acquire a synchronization object that is owned by code that is waiting to acquire the loader lock. This can cause a deadlock.
• Initialize COM threads by using CoInitializeEx. Under certain conditions, this function can call LoadLibraryEx.
• Call the registry functions. These functions are implemented in Advapi32.dll. If Advapi32.dll is not initialized before your DLL, the DLL can access uninitialized memory and cause the process to crash.
• Call CreateProces. Creating a process can load another DLL.
• Call ExitThread. Exiting a thread during DLL detach can cause the loader lock to be acquired again, causing a deadlock or a crash.
• Call CreateThread. Creating a thread can work if you do not synchronize with other threads, but it is risky.
• Create a named pipe or other named object (Windows 2000 only). In Windows 2000, named objects are provided by the Terminal Services DLL. If this DLL is not initialized, calls to the DLL can cause the process to crash.
• Use the memory management function from the dynamic C Run-Time (CRT). If the CRT DLL is not initialized, calls to these functions can cause the process to crash.
• Call functions in User32.dll or Gdi32.dll. Some functions load another DLL, which may not be initialized.
• Use managed code.

The following tasks are safe to perform within DllMain:

• Initialize static data structures and members at compile time.
• Create and initialize synchronization objects.
• Allocate memory and initialize dynamic data structures (avoiding the functions listed above.)
• Set up thread local storage (TLS).
• Open, read from, and write to files.
• Call functions in Kernel32.dll (except the functions that are listed above).
• Set global pointers to NULL, putting off the initialization of dynamic members. In Microsoft Windows Vista™, you can use the one-time initialization functions to ensure that a block of code is executed only once in a multithreaded environment.

(Auch wenn die DllMain nicht aufgerufen werden sollte - es ist dennoch gut, die obige Liste zu kennen ;).)

Durch viel Raterei und blasse Erinnerung an irgendeine Empfehlung weiß ich jetzt, dass es böse ist, DLLs von relativen Pfaden zu laden. Warum der Verifier es unter x86 weiterhin zulässt und unter x64 mit einem Stapelüberlauf quittiert statt mit einer Fehlermeldung, weiß hingegen bestimmt niemand.

Böse. Im sicherheitstechnischen Sinne. Aber die Funktionalität sollte nicht eingeschränkt sein.

[Schrompf]

Korrektur meines Gejammers: die NVidia Quadro NVS 290 unterstützt Anisotropische Texturfilter. Nur nicht als MagFilter, als MinFilter geht's. ATI-Karten und NVidia-Desktop-Grafikkarten haben mir das durchgehen lassen... hm. Nuja, wieder schlauer.

[Krishty]

Dürfte ich hier noch fragen, ob überhaupt noch deine DllMain aufgerufen wurde? Wenn ja: Was machst du dort?

Ich habe keine geschrieben.

Böse. Im sicherheitstechnischen Sinne. Aber die Funktionalität sollte nicht eingeschränkt sein.

Ja – aber solange mein Programm keine Installation hat, kann ich eben keine absoluten Pfade angeben (zumindest keine, deren Code ich nicht vom Arbeitsverzeichnis zum Programmverzeichnis ändern müsste, sobald ich denn eine Installation habe). Juckt mich also noch nicht.

Korrektur meines Gejammers: die NVidia Quadro NVS 290 unterstützt Anisotropische Texturfilter. Nur nicht als MagFilter, als MinFilter geht's. ATI-Karten und NVidia-Desktop-Grafikkarten haben mir das durchgehen lassen... hm. Nuja, wieder schlauer.

Japp – sie lassen es durchgehen, bei der Enumeration melden sie AF aber explizit nur als für den Min-Filter verfügbar, was ja auch plausibel ist. Weiß ich noch ziemlich sicher von meinem Action-Beitrag und meiner Radeon HD 4850.

[pUnkOuter]

Ist ne Quadro nicht eher eine Profi-Karte für CAD usw.? Falls ja wäre es noch verständlich, dass Anisotropisches Filtern nicht drauf ist...

[exploid]

...

[exploid]

...

[Krishty]

Mein Problem mit der Race-Condition im Compute-Shader ist gelöst, bzw, naja, eher erledigt als gelöst.

Schuld war, dass ich meine Anwendung mit dem App-Verifier gestartet habe. Der HLSL-Optimizer löst Aliasing beim Zugriff auf group-shared-Memory auf, indem er aus uninitialisiertem Speicher liest. Mit aktiviertem App-Verifier geht das schief und der Compiler denkt, eine Race-Condition sei eingetreten.

Warum man das so macht und warum der Bug, obwohl schon früher erkannt, noch nicht behoben wurde, konnte mir auch bei MS niemand sagen. Ironisch auch, weil das Bestehen des App-Verifiers eine Anforderung für das Games-for-Windows-Logo ist … aber mir ist es jetzt egal, weil ich die Shader bei mittlerweile 45 min Kompilier- und Optimierzeit eh offline kompiliere und nur den Bytecode vertreibe.

Eigentlich gehört das in den Anti-Jammer-Thread, weil es ja nun erledigt ist und MS schneller drauf reagiert hat als auf alle meine VCpp-Compiler-Bugs. Aber ich schreibe es trotzdem hierhin, weil es mich beinahe drei Wochen lang aufgehalten hat (ja – ich habe meine Anwendung einen Monat lang nur mit aktiviertem Application Verifier ausgeführt) …

[Krishty]

Schonmal die Deklaration von ::std::vector::resize() angeschaut?
void resize(size_type sz, T c = T());
Der zweite Parameter ist ein riesiger Fehler. Dadurch, dass dort keine Referenz auf ein const-Deklariertes Objekt, sondern by-Value übergeben wird, entsteht nämlich nicht nur u.U. eine unnötige Kopie, sondern ::std::vector ist plötzlich unbrauchbar für ausgerichtete Elemente – für Funktionsparameter, die by-Value übergeben werden, kann nämlich kein Alignment mehr garantiert werden. Peng, Fehler beim Kompilieren, Ende. Willkommen, eigene Vector-Implementierung.

Edit: Da hat schon jemand schneller gejammert als ich. Das ändern von Zeile 869 in <vector> (von void resize(size_type _Newsize, _Ty _Val) zu void resize(size_type _Newsize, _Ty const & _Val)) ist auch erstmal eine ausreichende Lösung.

[eXile]

Da hat schon jemand schneller gejammert als ich. Das ändern von Zeile 869 in <vector> (von void resize(size_type _Newsize, _Ty _Val) zu void resize(size_type _Newsize, _Ty const & _Val)) ist auch erstmal eine ausreichende Lösung.

Na dann sage ich doch mal: Willkommen im Kreise der User mit gepatchen STLs. :) Wenn es dich trotzdem mal in den Fingern juckt, kannst du ja mal in die Vektor-Implementierung der EASTL reinschauen, welche - so weit ich das sehe - ein Haufen sehr feiner Programmierung ist.

[Krishty]

Habe die STL vor ein paar Monaten aus den meisten meiner Programme geschmissen und durch eigene Container ersetzt – schon allein deshalb, weil ich jetzt Objekte ohne Copy-Semantics speichern kann, ist der Code um Dekaden einfacher und schneller geworden. Von vollem UTF-8-Support ganz zu schweigen.

Ja, die EASTL habe ich mir schon angeschaut – lernen kann man ja immer was.

Leider war dieses eine Programm jetzt eine Altlast, die erstmal ohne eigene Container auskommen muss.

[Krishty]

Beim Kompilieren eines Shaders in meiner Anwendung:
First-chance exception at 0x732e4812 in Core.exe: 0xC0000005: Access violation reading location 0x0000000000000048.
Unhandled exception at 0x732e4812 in Core.exe: 0xC0000005: Access violation reading location 0x0000000000000048.
Call Stack:
atidxx64.dll!00000000732e4812()
d3d11.dll!000007feed06db2a()
D3D11SDKLayers.dll!000007feec9e3900()
d3d11.dll!000007feed0692e0()
D3D11SDKLayers.dll!000007feec9e9bd1()
Core.exe!Cric::D3D11::CreateShaderFromByteCode<ID3D11ComputeShader>(…) Line 100 C++

Im GPU ShaderAnalyzer:
Unknown exception. Please save your shader & restart GPU ShaderAnalyzer.

Das ist dann der dritte Fremd-Bug, den ich bei meiner Compute-Shader-Fast-Fourier-Transformation finde. Einer in Visual C++, einer im HLSL-Compiler und einer im ATI-Treiber. Und jedes Mal ist es was Blockierendes. Was bin ich doch für ein Glückspilz. Meine Tastatur ist scheinbar der einzige Teil meiner Tool-Chain, der mich noch nicht im Stich gelassen hat.

[Schrompf]

Und die Maus?

[eXile]

atidxx64.dll!00000000732e4812()
d3d11.dll!000007feed06db2a()
D3D11SDKLayers.dll!000007feec9e3900()
d3d11.dll!000007feed0692e0()
D3D11SDKLayers.dll!000007feec9e9bd1()
Core.exe!Cric::D3D11::CreateShaderFromByteCode<ID3D11ComputeShader>(…) Line 100 C++

Darf ich es merkwürdig finden, warum du keine DirectX-Symboldateien auf dem System hast (mit denen du dir die Namen der aufgerufenen Funktionen aus den Direct3D-DLLs anzeigen lassen kannst)? Ich habe gerade keinen Zugriff auf ein Entwicklersystem, und muss zu meiner Schande gestehen, dass ich mich auch persönlich nicht um die Symboldateien bisher gekümmert habe (Faulheit) - aber mit den Symboldateien solltest du ein bisschen mehr sehen, was da los ist.

[Krishty]

Und die Maus?

Falsche Frage.

aber mit den Symboldateien solltest du ein bisschen mehr sehen, was da los ist.

Nö. Was sollte ich denn sehen? Es ist ein Treiberfehler; zu gültigem D3D-Bytecode lässt sich der Shader schließlich kompilieren. Selbst, wenn ich die Symbol-Files von atileckmichdoch.dll hätte, würde es mir nichts bringen. Ich kann höchstens im Dev-Forum posten, damit sie mir in zwei Wochen bestätigen dass es ein Bug ist und es dann in sechs Monaten beheben. Schnauze voll.