dateiliste

ISO/ANSI C++ unterstützt nur eine minimale Anzahl an Operationen auf Dateien, und das Konzept eines Verzeichnisses kommt im Standard AFAIK nicht einmal vor.

Das heißt jetzt nicht, dass es keine Möglichkeit gibt, die gewünschten Operationen auszuführen; allerdings ist die Lösung abhängig vom verwendeten Compiler/dem verwendeten Betriebssystem/der verwendeten Klassenbibliothek.

Eine Lösung, die dem Standard entspricht, gibt es nicht.

Wenn Du uns sagst, welche Entwicklungsumgebung Du verwendest, können wir Dir wahrscheinlich weiterhelfen.

mfg,

Jeremy

Bezüglich gcc:
http://www.gnu.org/manual/glibc-2…tem%20Interface

Unter Windows:
http://msdn.microsoft.com/library/defaul…t_functions.asp
-> FindFirstFile() et al.

Die MFC (die Klassenbibliothek von Visual C++) wird wohl noch eigene Funktionen für sowas zur Verfügung stellen. Da ich jedoch nicht mit Visual C++ arbeite, konnte ich Dir nur die relevanten Windows API Funktionen raussuchen.

unter Windows mit FindFirstFile(...) und dann FindNextFile(...) in einer while() schleife.

EDIT: hab die seite schon vor einer stunde oder so geladen, bevor die antwort schon gepostet wurde, daher das duplikat.

dann schreibst du eine FUnktion
GetFilenames(char directory[260], hier ein pointer zu einem array der dateinamen)
{
#ifdef LINUX
hier den spezifischen linux code zum schreiben der filenames in den array
#else
hier den spezifischen Windows code zum schreiben der filenames in den array
#endif

}

und du kannst dann über den vorher als array erstellte dateinamenliste auf die einzelnen dateien zugreifen und ohne probleme das programm unter beiden OS kompilieren. MFC würd ich auch nicht verwenden, die ist nur scheisse!

Eine Variante wäre auch noch, einen Portability Layer zu verwenden.

Beispielsweise könntest Du mit Cygwin unter Windows entwickeln, und somit POSIX Funktionen für Verzeichnisoperationen, etc. verwenden. Dann könntest Du das Programm unter Unix nativ kompilieren, und unter Windows eben mit Hilfe von Cygwin, das eine POSIX Schnittstelle um das Windows API anbietet.

Alternativ sei auch noch Qt erwähnt, eine crossplatform Library, die von Userinterface bishin zu Dateioperationen usw. unter Unix, Windows und MacOS X eine einheitliche Schnittstelle anbietet - also genügt eine einzige Codebasis für die 3 Plattformen.

Wenn Dein Programm nicht zu viel plattformspezifischen Code enthält, würde ich es aber einfachhaltshalber so machen, wie MaxAuthority es vorgeschlagen hat.

Zitat

(also irgendwas.cpp.win und irgendwas.cpp.linux) und beim make die entsprechende Datei umbenennen).

Sowas in der Art hab ich mir auch schon gedacht, und wäre IMHO auch eine sehr elegante lösung. Diese hätte sogar den vorteil, dass du das programm auf mehr als 2 OS portieren kannst, ohne dass der code arg unübersichtlich wird.

Zitat

Ein großes DANKE an alle, die hier gepostet haben und das noch tun werden.

bitte gerne - sonst ist informatikern in den ferien doch eh nur fad

Ich hätte da auch noch eine frage: Wie schaut Qt eigentlich unter windows aus? Mapped es die Qt-Befehle auf native Windows-Widgets, oder verwendet es - wie unter linux - sein eigenes toolkit, und skinnt es unter windows so halbwegs auf "native"?

Qt zeichnet die Widgets unter Windows selbst. IOW, die ganzen Widgets werden mit den Qt eigenen Canvas Klassen, etc. gezeichnet.

Das hat den Vorteil, dass auf den diversen Plattformen nur die Canvas Klasse mit Hilfe der OS spezifischen Grafikfunktionen implementiert werden muss.

Allerdings sehen Qt basiert Programme wirklich *genau* so aus, wie native Windows Programme. Es werden sogar Windows XP Themes unterstützt, wie das genau funktioniert, weiß ich aber nicht.

Qt 2.3 steht in einer non-commercial Version auch für Windows gratis zur Verfügung.

Als Alternative zu Qt kann ich auch Wx Windows empfehlen (http://www.wxwindows.org/). Allerdings ist diese Library den MFC sehr ähnlich, und AFAIK erstreckt sich der crossplatform Support auch nur auf die Entwicklung des User Interface.

Mir persönlich war Qt wesentlich sympathischer.

hmm, wie ist eigentlich Opera unter windows geschrieben? Weil die meisten Controls (ausnahmen sind toolbar, statusbar und die erweiterte ListView für die Mails und Bookmarks) sind laut meiner auffassung echte native controls (schon mal probiert auf die freie Stelle der Scrollbar mit der rechten maustaste zu drücken - an so ein Context-Menü denkt sonst kein GUI-Nachprogrammierer, außerdem sind die Classnames die der "echten" Controls), aber Opera ist unter Linux ja mit Qt geschrieben. Deshalb frag ich mich, ob sie unter windows auch Qt verwenden, oder ob sie es schaffen, das GUI von der logik des programms so gut zu separieren, dass es recht leicht ist das Programm auf fast 10 plattformen zu portieren.

hab zwar weder wxWindows verwendet, noch Qt, nur find ich wxWindows vom Ansatz her noch besser, weil es OpenSource ist, und außerdem wirklich die nativen Widgets verwendet.

Keine Ahnung, wie Opera implementiert ist ...

wxWindows ist vielleicht von der Idee her Qt überlegen, dafür finde ich es wesentlich unangenehmer zu benutzen (sprich: WxWindows besteht zu großen Teilen aus Macros und lässt eine schön abstrakte, objektorientierte Schnittstelle missen, ähnlich wie MFC).

Qt ist - zumindest unter Unix - ebenfalls OpenSource, und kann je nach belieben unter der QPL oder unter der GPL verwendet werden.

Nun... ich versuche mit Judas das projekt zu entwickeln.. nachdem ich von der linux-seite komme, wollte ich einmal fragen, inwieweit solche funktionen von GTK / GTK+ unterstützt werden (diese sind meines wissens frei für windows erhältlich)... und gibt es andere ähnliche systeme?

GTK+ ist zwar für Windows frei erhältlich, ABER:
Das Programm sieht dann halt nicht wie ein Windows Programm aus, sondern hat eben den GTK+ Look. Für mich ist sowas weder als Programmierer noch als User akzeptabel.

Welche Bereiche und Funktionen GTK+ außer GUI abdeckt, kann ich leider nicht beantworten, da ich noch nie mit GTK+ gearbeitet habe (bis auf minimale Versuche).

Zitat

Original geschrieben von jjan
Das Programm sieht dann halt nicht wie ein Windows Programm aus, sondern hat eben den GTK+ Look. Für mich ist sowas weder als Programmierer noch als User akzeptabel.

Full Ack.