Klotzkopp

T4 Assembly Directive

Das ist T4 egal. Wenn du eine Klasse benutzt, musst du eine Assembly-Direktive dafür angeben.

Hast du eine assembly-Direktive für die Bibliothek, die Translation enthält?

Also geht's um Translation, nicht um LoadAllForEnum. Was ist Translation und in welchem Namespace liegt es?

Wie lautet die vollständige Fehlermeldung?

Verschoben -> IT-Arbeitswelt

Es sieht mir mehr danach aus, als hättest du das irgendwo abgeschrieben und keinen blassen Schimmer, was das tut. Suchst du einfach nur jemanden, der deine Hausaufgaben macht?

Dann erklär doch mal, was du dir dabei gedacht hast. Vielleicht kommen wir darauf, wo es hakt.

Dann fang doch mal mit dem Funktionskopf an. Überleg dir, welche Parameter die Funktion braucht.

Geht es da um eine bestimmte Programmiersprache? Und wo genau kommst du nicht weiter?

Was ist denn aus letzten Board geworden?

Da reicht eine Schleife über das erste Array. Die Indizes für die einzelnen Optionen erhältst durch wiederholte Division durch die Anzahl der Optionen der jeweiligen Eigenschaft. Der Rest ist der Options-Index, mit dem Divisionsergebnis rechnest du weiter. Beispiel: Für '938' (Index 0): 0 / 2 (Anzahl Optionen Eigenschaft 1) = 0 Rest 0 (=> Eigenschaft 1 Option 0) 0 / 4 (Anzahl Optionen Eigenschaft 2) = 0 Rest 0 (=> Eigenschaft 2 Option 0) 0 / 3 (Anzahl Optionen Eigenschaft 3) = 0 Rest 0 (=> Eigenschaft 3 Option 0) Für '1122' (Index 23): 23 / 2 (Anzahl Optionen Eigenschaft 1) = 11 Rest 1 (=> Eigenschaft 1 Option 1) 11 / 4 (Anzahl Optionen Eigenschaft 2) = 2 Rest 3 (=> Eigenschaft 2 Option 3) 2 / 3 (Anzahl Optionen Eigenschaft 3) = 0 Rest 2 (=> Eigenschaft 3 Option 2) Die Reihenfolge der Eigenschaften ist dabei egal, du musst dich nur auf eine festlegen.

Ich habe ein [ strike ] -Tag hinzugefügt. Test

Lass solche Daten von einem Dienst verwalten, der unter einem Account mit den entsprechenden Rechten läuft.

Ein einzelner Benutzer sollte nur mit Admin-Rechten systemweite Programmeinstellungen ändern können. Logs würde ich nach Temp schreiben.

Das kommt auf den Konstruktor an. Es gibt einen für wchar_t-Zeiger, der nimmt natürlich auch wcslen. Der Konstruktor, den ich oben benutzt habe, verwendet zwei Iteratoren. Die Länge ist damit die Anzahl der Schritte dazwischen. Das liegt daran, dass wcscpy einfach alles kopiert und auf jeden Fall eine Nullterminierung anhängt. wcscpy nimmt aber keine Rücksicht auf die Größe des Zielspeichers und erwartet nullterminierte Quelldaten.

Du hast da einen Zeiger, kein Array. Der Debugger geht bei char- (und verwandten) Zeigern davon aus, dass da nullterminierte Daten drin sind. Darum zeigt er den Inhalt bis zur Nullterminierung an. Wenn keine drin ist, wird der Speicherinhalt dahinter mit angezeigt. Beim wstring passiert das nicht, weil der eine eigene Längeninformation trägt, die der Debugger auswertet. Häng dich nicht so sehr daran auf, was dir der Debugger anzeigt. Was meinst du, wie wcslen die Länge ermittelt? Über die Nullterminierung. Wenn da keine ist, hilft dir auch wcslen nicht. Du musst dir einfach selbst merken, wie lang deine Daten sind. Oder eben nicht mit rohen Zeigern und Arrays hantieren.

wcsncpy. Falls das angegebene Maximum erreicht ist, bevor das Ende der Quelle erreicht wird, hängt diese Funktion keine Nullterminierung an. strncpy verhält sich genauso.

Ein Array ist so groß, wie du es anlegst. Kann es sein, dass du die Daten einfach nur mit einer Funktion weiterverarbeitest, die von Nullterminierung ausgeht?

Wo ist denn da das Problem? Deine Daten sind nicht nullterminiert, das weiß aber der Debugger nicht. Darum stellt er auch den Speicherinhalt hinter deinem Text dar.

Mehrere, aber keine, die das Verhalten erklären, das ich übrigens mit Visual C++ 2012 nicht reproduzieren kann. Dein Code erkennt nicht, ob die Datei überhaupt geöffnet werden konnte. Eof eignet sich nicht als Schleifenbedingung, weil es erst dann true liefert, wenn schon ein Lesevorgang fehlgeschlagen ist. Wenn du eine Leseschleife brauchst, nimm die Leseoperation selbst als Schleifenbedingung. Benutz kein new[] für den Puffer, sondern std::vector. Aber überhaupt ist die ganze Vorgehensweise ziemlich C-artig, wenn ich so sagen darf. Wenn du ohnehin die ganze Datei einlesen willst, brauchst du keine Schleife: std::wifstream wif(filename); wif.imbue(std::locale(std::locale::empty(), new std::codecvt_utf8<wchar_t>)); std::vector<wchar_t> v; std::copy(std::istream_iterator<wchar_t, wchar_t>(wif), std::istream_iterator<wchar_t, wchar_t>(), back_inserter(v)); // oder wenn du es als string brauchst: std::wstring s(v.begin(), v.end()); [/code]

Eine if-Anweisung leitet eine Verzweigung ein, keine Schleife. Schleife bedeutet in der Programmierung eine Wiederholung, bei if wird nichts wiederholt. Daher ist der Begriff "If-Schleife" in sich widersprüchlich.

Du scheinst Objective-C zu benutzen und für iOS zu entwickeln. Gateway_mans Antwort war für Windows. Du solltest immer dazu schreiben, welche Entwicklungsumgebung/GUI-Framework/Zielbetriebssystem du hast.

Du brauchst keinen Default-Konstruktor für Stackframe, wenn du im ExceptionBase-Konstruktor eine Initialisierungsliste verwendest, statt alle Member im Konstruktorrumpf zuzuweisen. Das solltest du dir ohnehin angewöhnen. Und übergib frame als const-Referenz. ExceptionBase::ExceptionBase(int errorcode, int oserrorcode, std::string message, StackFrame const & frame) : _errorcode(errorcode), _oserrorcode(oserrorcode), _message(message), _stackframe(frame) { }[/code] Allgemein solltest du auf const-Correctness achten. Methoden, die den beobachtbaren Zustand des Objekts nicht ändern (z.B. Getter) sollten const sein, denn nur so kannst du sie auch mit einem const-Objekt aufrufen: [code] int Line() const; std::string Assembly() const; // usw. ... int StackFrame::Line() const { return _line; }

Zeig mal StackFrame.