Dieser Thread wurde von Moderator/in pumuckl aus dem Forum C++ (auch C++0x) in das Forum Compiler- und IDE-Forum verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?
Dieses Posting wurde automatisch erzeugt.
Hallo,
ich versuche MASM 8.0 zu installieren..
Habe gelesen das dies nur mit installierter Version von
Microsoft Visual C++ Express Edition 2005 möglich ist..
Genau das habe ich mir von der MS-Website installiert und anschließend
MASM 8.0. Jedoch kommt auch hier immer die Fehlermeldung das MS VC Express Edition installiert sein muss.
Was mache ich denn noch falsch und wie bekomme ich es hin???
Mein OS: Windows7 x64
Gruß,
Nicky
Hallo Leute,
ich hoffe ihr könnt mir helfen.
Ich habe mit C# im VS2010 ein Programm installiert, welches eine Passwort abfrage macht. Wenn das Passwort stimmt, dann wird ein Dialog geladen. Das hat optimal bisher funktioniert.
Nun habe ich mir ein Bild aus dem Netz gesucht und gespeichert in die Projektmappe unter Ressourcen. Dieses Bild habe ich nun in das Projekt eingebunden und dieses dann für den Dialog als Hintergrundbild geladen.
Weenn ich die debuggte Exe nun starte zum Testen, kann ich im Anschluss im VS2010 nach Änderungen nicht mehr debuggen. Bekomme immer die Meldung:
In die Ausgabedatei xxx.exe konnte nicht geschrieben werden -- "Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird."
Wenn ich den Computer neu starte ist alles wieder gut. Dann nehme ich Veränderungen vor, debugge, starte die Testexe und das selbe Spiel beginnt von vorn. Ich will aber nicht immer den restart ausführen müssen, hat jemand eine Idee, was das ein könnte?
this->that schrieb:
Und was soll der Text jetzt beweisen? Dass es illegal ist, das Programm seines Kumpels zu dekompilieren? lol
Lass die Troll-Beiträge. Entweder du argumentierst richtig oder gar nicht. Mensch, verfolgst du mich jetzt oder was?
Ist gut TE, schau bei http://www.woodmann.com/crackz/Tools.htm nach. Der this->that sagt, dass du das darfst
jau, ausgemessen habe ich bei mir schon den code um den es ging (ublas prod vs händische Schleifen). Da kam aber eben raus, dass die blocked variante auch bei meiner aktuelleren CPU und gcc 4.6.1 mit -O3 -mcore2 einen Geschwindigkeitsvorteil von 15% vor dem axpy prod hat, welches exakt genauso schnell ist, wie meine händische Schleife:
void prod2(const RealMatrix& C, const RealMatrix& A, const RealMatrix& B){
for(std::size_t i = 0; i != A.size1(); ++i){
for(std::size_t k = 0; k != A.size2(); ++k){
for(std::size_t j = 0; j != A.size1(); ++j){
C(i,j)+= A(i,k) * B(k,j);
}
}
}
}
Was sich mir aber dann nicht erschließt ist, warum die ganzen numerischen Bibliotheken immer noch so extrem viel schneller sind, obwohl der Compiler die ganzen Vektorisierungen bereits durchführt? Ich bin bislang davon ausgegangen, dass sie einfach per Hand die intrinsics setzen, dadurch "perfekt" vektorisieren, und der Laden läuft.
In der Praxis kriegt man aber solche Graphen:
http://eigen.tuxfamily.org/index.php?title=Benchmark
Gibt es noch mehr Optimierungstricks, die man kennen sollte?
Masterofeye schrieb:
file:///C:/Program%20Files%20%28x86%29/Microsoft%2 ....... zards/AppWiz/MFC/Application/html/1031/default.htm
Auf Dateien auf deiner Festplatte können wir nicht zugreifen. :p
Egal, feststeht das der App-Wizard entweder fehlerhaft ist oder seine Dateien nicht findet.
Probier mal ne Konsolen-App zu erstellen um rauszufinden ob alle Wizards fehlerhaft sind.
Masterofeye schrieb:
Der Installer von 2 Varianten, sehr unwahrscheinlich das der beschädigt ist
Ich schreibe erst und denke dann.
Hallo.
Ich hab die Spezialisierungen inline gemacht, jetzt verschwindet der Fehler und tritt nicht mehr auf.
Ich hab auch das ganze Projekt nochmal neu aufgesetzt seit ich die Frage gestellt hab (Gott was f[r ne Frimelarbeit).
Lustigerweise verbraucht das Programm jetzt ein Zehntel des benötigten Speichers wie das alte Programm
Das scheint wohl ein VS Bug gewesen zu sein, und da das alte Projekt noch nicht mit SP1 erstellt wurde, schätze ich dass das ganze in SP1 gefixed wurde.
Danke für die Antwort,
hab mir die man Page vom ld angeschaut und versucht die lib direkt zu linken, nachdem ich dann auch den Pfad mit dazugeschrieben hab hat alles ohne Probleme geklappt:
TARGET_LINK_LIBRARIES({target} {libs...} /usr/lib/libstdc++.so.5)
Danke und MfG
Pyrokar
Cassiopeia schrieb:
Danke, aber mit /P funktionert der Code im Moment gar nicht mehr, mit oder ohne Header nicht.
Das ist normal. Du solltest einfach nur die Doku lesen...
buntehaare schrieb:
eine dll ist praktisch (einfach ausgedrückt) ein ausführbares programm, es fehlen einfach nur die exe header.
Das stimmt so aber nicht! Zwar ist eine DLL ein "Programm" das in den Speicherbereich des Lade-Prozesses gemappt wird(zumindest der Code), aber sie hat genauso den MZ-Header, den PE-Header("PE\0\0", IMAGE_FILE_HEADER, IMAGE_OPTIONAL_HEADER) usw.! Die Unterscheidung findet anhand des 14. Bits des Characteristics-Words im IMAGE_FILE_HEADERs statt: 0=Programm, 1=DLL
Um es mal einfach zu sagen: Bei Statischen Libs werden während des linkens die benötigten Funktionen in die EXE kopiert, bei DLLs werden nur die Verweise in den .idata-Abschnitt geschrieben beim Laden durch den EXE-Loader geladen(oder ohne .idata während der Ausführung durch LoadLibrary und GetProcAddress). Der Vorteile bestehen darin das die EXE kleiner wird und die DLL für mehrere Prozesse nur einmal geladen werden muss.
Außerdem kann man Programme durch DLLs auch in Module zerlegen (was zum Beispiel beim Updaten Vorteile bietet).
Auf beide Befehle bin ich mittlerweile schon gestoßen.
FILE(COPY ...) ist jedoch nicht in meinem Sinne, da die Dateien schon beim Ausführen des Befehls cmake kopiert werden. Lieber wäre es mir, wenn sie mit make verschoben würden.
Und ein INSTALL(DIRECTORIES ...) gibt funktioniert leider nicht.
EDIT:
Der Befehl lautet natürlich INSTALL(DIRECTORY ...). Warum verwenden sie hier nicht auch die Mehrzahl?
Naja, danke jedenfalls.
Danke für die Antwort. Ich befinde mich zum Glück in der vorteilhaften Position, den Test nicht fixen zu müssen :). Allerdings nervts mich halt so ein wenig, dass die Testsuite die Tests scheinbar ändert.
Einzeln ausführen gibt keinen Fehler und -VV hat leider auch nichts geholfen. Ich werde morgen einmal die env-Geschichte ausprobieren. cTest ist ganz normal konfiguriert. Wir haben da nichts dran gedreht.
naja, der Fehler klingt ganz stark danach, dass da jemand seine Zeigerarithmetik nicht ganz unter Kontrolle hatte . Wie ich höre, hat die entsprechende Person gerade viel Spaß mit Valgrind <3. Wenn sich das Environment ändert und deswegen irgendwelche Speicherabbilder verschoben werden, würde es das Verhalten erklären.
Ich kann dir leider auch nicht helfen, aber will dich zumindest darauf hinweisen, dass - warum auch immer du die deutsche Version nutzt - besser gleich auf die englische Version umsteigst und die "echten" Keybindings lernst.
MfG SideWinder
Dieser Thread wurde von Moderator/in Jochen Kalmbach aus dem Forum C++/CLI mit .NET in das Forum Compiler- und IDE-Forum verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?
Dieses Posting wurde automatisch erzeugt.