Probleme, Probleme, Probleme...

nixversteher

Ne ich verwende eigentlich Dev-C++.
Hab nur auch mal die Fehlerliste von MVC++ 2005 mit angegeben weil da andere Fehler angezeigt werden

nixversteher

Ohhh, hat schon geholfen, ist aber noch nicht ganz weg
Hier die neuen Fehlermeldungen:

in function 'int main((int,_TCHAR**)':
52 cannot convert '_TCHAR*' to 'const wchar_t*' for argument '1'to FILE*_wfopen(const wchar_t*, const wchar_t*)'
52 at global scope:
78 expected declaration before '}' token

Ich bin echt froh wenn ich mit dem Scheiss fertig bin, bin eig. E-Techniker.
Ich hoffe Proggen holt mich nicht zu oft ein...

Danke schonmal

Laut meiner MSDN ist _TCHAR das selbe wie wchar_t. So sollte eine einfaches

FILE *f = _wfopen((wchar_t*)filename, _T("rb") );

reichen.
Und anstatt dem L"string" kannst auch _T("string") nehmen. Ist portabler, wenn UNICODE mal nicht verfügbar ist, weil das Makro dann dementsprechend expandiert.
Zeile 84: Das } ist zuviel soweit ich das sehe.
rya.

CStoll

Wenn du schon mit TCHAR's arbeitest, dann bitte konsequent - das heißt in dieser Zeile benötigst du _tfopen().

(außerdem zähl mal nach, ob du zu jedem { ein passendes } (und umgekehrt) hast)

Braunstein

_TCHAR ist doch auch nur ein Makro. Wenn er UNICODE nicht eingestellt hat ist das eben char und nicht wchar_t.

Braunstein schrieb:

_TCHAR ist doch auch nur ein Makro. Wenn er UNICODE nicht eingestellt hat ist das eben char und nicht wchar_t.

Rchtig, da hab ich jetzt nicht dran gedacht. Bin davon ausgegangen, dass das so ist. Kommt auf die MSVC-Version an, seit 2005 sind alle Projekte eigentlich automatisch UNICODE und nicht mehr MultiByte.
rya.

CStoll

Scorcher24 schrieb:

Rchtig, da hab ich jetzt nicht dran gedacht. Bin davon ausgegangen, dass das so ist. Kommt auf die MSVC-Version an, seit 2005 sind alle Projekte eigentlich automatisch UNICODE und nicht mehr MultiByte.
rya.

Bei MSVC vielleicht, bei anderen Compilern eher nicht. Und der "cannot convert..." Fehler deutet darauf hin, daß in diesem Fall kein UNICODE definiert war.

nixversteher

Ahhh es wird, wenn ich das jetzt richtig verstanden habe müsste es ja dann etwa so aussehen:

_tcsncpy(filename, argv[1], FILENAME_MAX);
	FILE *f = _tfopen((wchar_t*)filename, T("rb"));
	if (f) {
		DEA_ARCHIV_TYP DEARecord;
		while(!feof(f)) {
			fread(&DEARecord, sizeof(DEARecord), 1, f);
			struct tm stm = *localtime(&DEARecord.Startzeit);
			printf("%02d.%02d.%04d %02d:%02d.%02d,%03d : ",

Da wird dann gemeckert, dass das 'T' nicht deklariert währe.
Das 'L' von vorher war aber doch auch nicht, warum wurde da nicht gemeckert und wo müssete ich es deklarieren?

nixversteher

Noch etwas, am Fehler in MVC++ 2005 hat sich noch nichts geändert, da wird immer noch:

1>------ Erstellen gestartet: Projekt: DEAConverter, Konfiguration: Debug Win32 ------
1>Kompilieren...
1>DEAConverter.cpp
1>c:\programme\microsoft visual studio 8\vc\include\stdlib.h(1) : fatal error C1014: Zu viele Headerdateien: Tiefe = 1024
1>Das Buildprotokoll wurde unter "file://u:\Praxissemester\Konvert_c++\DEAConverter\Debug\BuildLog.htm" gespeichert.
1>DEAConverter - 1 Fehler, 0 Warnung(en)
========== Erstellen: 0 erfolgreich, Fehler bei 1, 0 aktuell, 0 übersprungen ==========

ausgegeben. Warum können nicht beide Compiler mit dem gleichen Quellcode umgehen?

Nicht T() sondern _T(). Das wird in <tchar.h> normalerweise definiert.
Das L ist ja nur ein Prefix, das zur Sprache gehört afaik.
Und bei _tfopen() brauchst du den ersten parameter eigentlich auch nicht nach wchar_t* casten, weil das ja die dazugehörige funktion ist.. ist eigentlich relativ, weil TCHAR = wchar_t aber es liest sich dann besser.^^
rya.

CStoll

Der Fehler tritt eigentlich nur auf, wenn sich mehrere Header ohne Include-Guards gegenseitig einbinden - das sollte bei einem Systemheader eigentlich nicht passieren (außer du hast in den Systemheadern rumgespielt).

nixversteher

Hmmm, rumgespielt ist ein weiter Begriff. Möglich wärs. Ne Neuinstallation müsste da dann aber helfen oder? MVC ist ja eigentlich schon besser, alleine der Hilfe wegen

nixversteher

mit _T("rb") bekomme ich wieder:

cannot convert 'wchar_t*' to 'const char*' for argument '1' to 'FILE* fopen(const char*,const char*)

Ich hab das hier eben mit dem MINGW (g++) kompiliert:

#include <fstream>
#include <cstdio>
#include <cstring>
#include <ctime>
#include <iostream>
#include <tchar.h>

#pragma pack(push,2)

typedef float         FLOAT;
typedef unsigned char UCHAR;
typedef char          CHAR;
typedef short int     SHORT;
typedef time_t        DATE_TIME;

typedef union _proz_wert_union {  /* Union für den Prozeßwert */
  FLOAT Wert;               /* für Analogeingänge einen Float  */
  UCHAR Zustand;            /* für Digitaleingänge einen UCHAR */
} PROZ_WERT_UNION;          /* 4 Byte entsprechend dem größen Member */

typedef struct _dea_archiv_typ { /* Bytes Bedeutung                               */
  DATE_TIME       Startzeit;      /*  4  Startzeit des Intervalls                 */
  SHORT           Millisec;       /*  2  Millisec. bei Echtzeitverarb. sonst. -1  */
  PROZ_WERT_UNION Wert;           /*  4  union für den Prozeßwert                 */
  UCHAR           Kennung;        /*  1  Kennung des archivierten Wertes          */
  CHAR            Grund;          /*  1  Archivierungsgrund                              */
} DEA_ARCHIV_TYP;                 /* 12  Byte pro Archiveintrag                   */
#pragma pack(pop)

int _tmain(int argc, _TCHAR* argv[])
{

    _TCHAR filename[FILENAME_MAX + 1];

    if (argc != 2) {
        printf("Unzulaessige Parameterzahl!\n");
        printf("Aufruf:\n");
        printf("DEAConverter <Dateiname>\n");
        return 0;
    }

    _tcsncpy(filename, argv[1], FILENAME_MAX);
    FILE *f = _tfopen(filename, _T("rb"));
    if (f) {
        DEA_ARCHIV_TYP DEARecord;
        while(!feof(f)) {
            fread(&DEARecord, sizeof(DEARecord), 1, f);
            struct tm stm = *localtime(&DEARecord.Startzeit);
            printf("%02d.%02d.%04d %02d:%02d.%02d,%03d : ", stm.tm_mday
                , stm.tm_mon
                , stm.tm_year
                , stm.tm_hour
                , stm.tm_min
                , stm.tm_sec
                , DEARecord.Millisec > 0 ? DEARecord.Millisec : 0);

            printf("DEARecord: Zustand = %d, Kennung = %d, Grund = %c\n", DEARecord.Wert.Zustand
                , DEARecord.Kennung
                , DEARecord.Grund);

        }

        fclose(f);
    }
    system("PAUSE");
    return 0;
}

Ging ohne Warnungen. Ich benutzte GCC 3.4.2 ohne IDE. Deine Systemheader müssen echt nen Problem haben. Am besten mal neu installieren.

edit:
cannot convert 'wchar_t*' to 'const char*' for argument '1' to 'FILE* fopen(const char*,const char*)
Du sollte ja auch _tfopen nehmen..
rya.

nixversteher

Den DEV-C++ hab ich schon neu installiert das hilft in dem Fall nix. Wo bekomm ich denn deinen Compiler her?

nixversteher schrieb:

Den DEV-C++ hab ich schon neu installiert das hilft in dem Fall nix. Wo bekomm ich denn deinen Compiler her?

http://www.mingw.org/
Denk aber dran, dass du den Pfad zum Compiler im Systempfad ablegst, damit du per Kommandozeile von überall Zugriff drauf hast..

CStoll

nixversteher schrieb:

mit _T("rb") bekomme ich wieder:

cannot convert 'wchar_t*' to 'const char*' for argument '1' to 'FILE* fopen(const char*,const char*)

Auch auf die Gefahr hin, mich zu wiederholen - wenn du mit TCHAR arbeitest, dann durchgängig. Du mischst hier TCHAR mit char und/oder wchar_t-Funktionen, das geht je nach Projekteinstellungen gut oder liefert "cannot convert..." Fehler in die eine oder andere Richtung.

(am Beispiel - fopen() erwartet char, _wfopen() erwartet wchar_t - _tfopen() erwartet TCHAR (das ist ein Makro, das je nach Projekteinstellungen auf eine der anderen Funktionen übersetzt wird))

nixversteher

[quote="Scorcher24"]

FILE *f = _wfopen((wchar_t*)filename, _T("rb") );

[quote]

Hatte bis eben genau das da stehen!

Und wennn ich nun

FILE *f = _tfopen(filename, _T("rb"));

nehme geht es auch bei mir!
Vielen Dank!!!!!

Der Teil des Programms ist ja nur zum Konvertieren von Dateien, gibt es irgend ne tolle Funktion mit der ich ein Verzeichnis mit ca. 14000 Dateien einlesen und diese Nacheinander bearbeiten kann?

Jo, gibbet^^. FindFirstFile und FindNextFile. Einfach die MSDN und google bemühen.
rya.

nixversteher

Danke, ich werds morgen mal versuchen, jetzt mach ich erst mal Feierabend