pumuckl schrieb:
pumuckl schrieb:
Ich hab MSVC2008, englisches Sprachpaket.
Beantwortet das die Frage?
Nein, sonst hätte ich nicht gefragt ;o
Express oder andere.
Edit:
Ist das Tutorial im Internet? Gibst eine URL?
Debuggen und Compilieren sind unterschiedliche Sachen. Debuggen dient der Überprüfung/dem Testen des Programmes zur Laufzeit (Grob gesagt). Compilieren erzeugt das Programm (eine ausführbare Datei) aus Deinem Code (*.cpp).
Wenn Du F5 (Debuggen) drückst, kompiliert VC++ aber automatisch den Code und führt ihn dann auch aus -> Du siehst sofort das Ergebnis. Das der Debugger dabei läuft, braucht Dich eig. erstmal nicht zu stören.
Hmm... Ob es jetzt der Linker oder der Compiler ist - davon habe ich in der Tat keine Ahnung. Habe das Konzept vom Linker auch noch gar nicht verstanden (bzw. mich noch nie damit beschäftigt).
Dass sich dir meine Logik nicht erschließt liegt wohl daran, dass du im Gegensatz zu mir schon lange verstanden hast, wie die Systeme der Fehlerausgabe, Logging etc. funktionieren. Für mich ist das wie gesagt völliges Neuland.
Ich versuche es mal zu erklären, wie ich da rangehe: Da ich neu bin und all die Konzepte noch nicht kenne habe ich es immer so gemacht (egal ob im Hauptprogramm oder in einer Klasse oder was auch immer):
if (i < 0) {
cout << "Fehler: Negativer Index" << endl;
}
Da das auf Dauer zu aufwädig ist habe ich mir gedacht schreibe ich mir doch eine Klasse, die mir Methoden wie msg(), warn(), error() u.s.w. bereitstellt, sodass ich nur noch einen String als Parameter übergeben müsste.
Da aber cuot << xxx nicht immer richtig ist, müsste die Klasse den Projekttyp erkennen (über Makros dachte ich mir). Wie das geht wollte ich in diesem Thread fragen.
Ich habe zwar schon mal was von "Exceptions" gehört, habe aber nur eine sehr ungefähre Vorstellung davon und wüsste nicht, wie ich damit... ich sag mal "zusammengesetzte Fehlermeldungen" ausgeben könnte, so was wie das:
cout << "Error: Index " << i << " out of Range (" << range << ")" << endl;
Wenn so was mit Exceptions etc. möglich wäre, würde ich mir das vllt mal anschauen ansonsten würde ich wohl dabei bleiben, eine eigene Ausgabeklasse zu schreiben.
Ich hoffe damit ist meine Situation jetzt etwas verständlicher...
Danke schonmal für eure Hilfe bis jetzt!
Wenn Zeiger über Modulgrenzen hinweg erzeugt und zerstört werden musst Du die DLL Version der CRT verwenden. /MTd verwendet die statisch gelinkte CRT.
Das Problem ist entsprechend hausgemacht. Und es ist giut dokumentiert:
http://msdn.microsoft.com/en-us/library/ms235460.aspx
Zitat aus http://msdn.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx
Because a DLL built by linking to a static CRT will have its own CRT state, it is not recommended to link statically to the CRT in a DLL unless the consequences of this are specifically desired and understood.
Grundsätzlich würdeich niemals Objekte über DLL Grenzen austausachen schon gar keine STL Objekte. Denn das geht nur wenn die gleiche Compilerversion und Code-Basis verwendet wird und auch nur mit der DLL Version der CRT.
Wenn die EXE die Library auch verwendet, dann werden auch die Funktionen eingebunden...
Der Linker schmeißt alles raus, was nicht benötigt wird, bzw. nimmt aus der LIB nur das was die EXE refernziert.
dgrat schrieb:
Hat jemand Erfahrungen mit dem Intel-Compiler? Es steht in der Beschreibung, dass er automatisch für Multi-Cores optimiert. Heißt das, dass ich bei manchen Programmen auf Boost::threads verzichten kann?
Hat jemand allgemeine Erfahrungen mit der Geschwindigkeit?
Da sprichst Du von verschiedenen Ebenen. Die Parallel-Optimierungen gibt's ja auf diversen Ebenen, z.B. grob:
Der Compiler optimiert auf Assemblerebene den Code so, daß er den Multicore besonders effizient nutzt - das erreicht man alleine durch die Verwendung eines anderen Compilers mit gleichem Code. Zusätzlich bringt der Compiler eine Stdlib mit, die ebenfalls für Multicore optimiert ist.
Die Ebene von "parallel_for", also dort wo sich OpenMP bewegt, man benutzt auf der Hochsprache eine spezielle Lib, die für parallele Bearbeitung eigene Konstrukte bietet.
Die Ebene der Architektur, Messagebearbeitung und/oder die Datenverarbeitung werden durch Aufteilung auf parallele Threads zur Laufzeit besser skalierbar.
Du sprichst mit dem "Verzicht auf Threads" die Ebene 3) an, der Intel-Compiler arbeitet zunächst aber Optimierungen auf Ebene 1) ab.
Ich war letzte Woche auf der Intel Software Conference 2010, und da wurde dieses Thema sehr ausgiebig erörtert. Die Anwender sprechen alle von deutlichen Performancegewinnen alleine durch den Intel-Compiler, aber trotzdem muß man auch auf den Ebenen 2) + 3) einiges tun, um schneller zu werden.
Jochen Kalmbach schrieb:
Projekttemplates sind wieder etwas anderes... das geht in VC++ leider nicht per IDE...
Ok, dann habe ich dich falsch verstanden. Habe mir gerade mal diese PropertySheets angeschaut. Sieht interessant aus. Aber wäre halt praktischer, wenn ich sowas gleich bei der Erstellung des Projektes auswählen könnte
Hat VS2010 eigentlich immer noch kein Export Template für VC++?
Und wenn wir gerade dabei sind: Kennt jemand ein gutes Buch, bzw. eines das kommt, welches die IDE VS2010 umfassend erklärt? Das letzte Mal als ich etwas umfassendes über die VS IDE gelesen habe, war bei 6.0. Wäre daher langsam mal wieder an der Zeit
Grüssli
Hallo,
BTW: Hat sich eigentlich was in Sachen WPF+MVVM geändert? Gibt es da Projektschablonen und (Lib-)Erweiterungen oder ist immer noch der Wildwuchs aus Codeplex und Konsorten angesagt?
Ad aCTa schrieb:
Was mir noch auffällt: Wieso steht da 29 days remaining? Muss man jetzt auch noch für Express bezahlen?
Nein, aber man muss sich registrieren.
Aaahh! Danke es geht! Ich wusste doch das es mit new zu tun hat das man dafür noch was machen muss damits einwandfrei funktioniert ^^
Danke!
Gut Schuß
VuuRWerK
[edit]
Es ist aber wirklich wichtig dass das ganze in einem extra Header steht, sonst ist es nicht kombilierbar!
Für die Nachwelt
#ifndef __MEMORY_HPP__
#define __MEMORY_HPP__
#if defined(_DEBUG)
# define _CRTDBG_MAP_ALLOC
# include <crtdbg.h>
void*
operator new(size_t nSize, char const* lpszFileName, int nLine)
{
return ::operator new(nSize, 1, lpszFileName, nLine);
}
# define DEBUG_NEW new(THIS_FILE, __LINE__)
# define MALLOC_DBG(x) _malloc_dbg(x, 1, THIS_FILE, __LINE__);
# define malloc(x) MALLOC_DBG(x)
# define new DEBUG_NEW
#endif
#endif // __MEMORY_HPP__
Und in jede *.cpp Datei:
#if defined(_DEBUG)
# include "memory.hpp"
# undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
Wobei ich mir mal was einfallen lasse das man das eventuell ohne dem Extra definieren von THIS_FILE machen kann. Gemacht wird es ja nur weil sonst __FILE__ in 2 Macros verwendet werden würde und somit nur die Header-Datei als Filename gespeichert wird.
[/edit]
[edit2]
Ok, es ist einfacher als gedacht Man kann THIS_FILE einfach weglassen und in den Macros durch __FILE__ ersetzen. Mir fiel auf das es in 2 verschiedenen Macros verwendet wird die man aber selber aufruft und somit immer da wo man auch allokiert. Demnach steht in filename dann auch immer der richtige Name
[/edit2]
Wen's interessiert: C::B scheint wohl Probleme mit Headern ohne passende Sourcen zu haben. Wenn man für jeden Header eine (leer) Source-Datei mit gleichem Namen erstellt, geht es kurioser Weise.
sapere aude schrieb:
Wie kann ich das beheben?
Wenn du BCC mit dem "-A"-Switch aufrufst (bzw. die gleichwertige Option "ANSI-Kompatibilität" in den Projektoptionen aktivierst), akzeptiert er nur reines ANSI-C++, was zu derartigen Fehlermeldungen führt. Laß den Switch einfach weg.
