Pfad der .exe herausfinden

Nexus schrieb:

Heisst das Makro nicht "_T"? "T" wäre ziemlich übel, da das wohl der meistgenutzte Bezeichner für Templateparameter ist. Was nicht heisst, das "_T" gut wäre.

Auch mir ist nur die _T Variante bekannt.

taurus

schau ich mir gleich mal an..
noch ne andere geschickte.. (grundlagen :- ) )

EDIT: da ich später ja ein char* brauche muss ich wohl strcpy und strlength verwenden..

char inipathtmp[_MAX_PATH];
    std::string inipathcut;
    size_t pospathcut;
    GetModuleFileNameA(NULL, inipathtmp, _MAX_PATH);

    pospathcut = inipath.rfind("//"); //sollte natürlich so heißen :-)
    inipathcut = inipathtmp.substr(pospathcut);
    //std::cout << inipathcut << std::endl;

Nexus

Es existiert eine implizite Konvertierung von char* nach std::string (und eine von char[size] nach char* ).

Allerdings ist der zweite Parameter von std::string::rfind() kein std::string , sieh hier.

unskilled

das geht z.bsp. so:

char inipathtmp[_MAX_PATH];
    DWORD length = GetModuleFileNameA(NULL, inipathtmp, _MAX_PATH);

    std::string inipathcut(inipathtmp, inipathtmp+length);

/*...*/

bb

taurus

mmhh das versteh ich nun aber nicht

char inipathtmp[_MAX_PATH];
    //std::string inipathcut;
    //size_t pospathcut;
    GetModuleFileNameA(NULL, inipathtmp, _MAX_PATH);

    inipathtmp.ReverseFind("//");

gibt mir auch wieder den selben fehler zurück:

error: request for member 'ReverseFind' in 'inipathtmp', which is of non-class type 'char [260]'

Nexus

Wie kommst du darauf, dass ein char -Array (!) eine Memberfunktion namens ReverseFind() haben könnte?

Baba Yaga

taurus schrieb:

aber: wieso kann das cout nicht ausgeben? welche grundlagen hab ich hier nicht gelesen?

cout versucht anhand des Typs zu entscheiden, was es tun soll. IMHO wäre es besser, wenn der Compiler einen Fehler melden würde, wenn er für cout << keine passende überladung findet. Ich kann mich dunkel an einen ähnlichen Fall erinnern, bei dem der MSVC die seltsame Ausgabe "performance warning - conversion to bool" von sich gab und cout einfach eine 1 anzeigte.

xor

Man sollte eigentlich immer mit UNICODE arbeiten. Sobald man mit Dateinamen aus anderen Ländern konfrontiert ist wird die ANSI-Implementierung problematisch - es ist ein Überbleibsel aus der Win16- und Win9x- Zeit. Es ist aber leicht möglich mit TCHAR kompatibel zu programmieren.

Was den Umgang mit STL + WINAPI anbelangt, kann man sich das TCHAR-Schema auf die STL erweitern.

Kleines Beispiel:

#include <iostream>
#include <string>
#include "wchar.h"
#include "windows.h"
#include "tchar.h"

#if defined(UNICODE)
#  define tcout wcout
#  define tstring wstring
#else
#  define tcout cout
#  define tstring string
#endif

int _tmain(int argc, TCHAR* argv[])
{
  TCHAR strTemp[MAX_PATH];
  DWORD len = GetModuleFileName(NULL, strTemp, MAX_PATH);
  if(len)
  {
    std::tstring strExe(strTemp);
    size_t szPos = strExe.rfind(_T("\\"));
    if(std::tstring::npos != szPos)
    {
      std::tcout << _T("File: ") << strExe.substr(szPos + 1);
      return 0;
    }
    else
    {
      std::tcout << _T("failed");
      return 2;
    }
  }
  else
  {
    return 1;
  }
}

Kompiliert man für UNICODE, sind wchar_t, wstring, wcout und GetModuleFileNameW im Einsatz. Braucht man das Programm doch noch für ein altes Windows 98, dann arbeitet man automatisch mit char, string, cout und GetModuleFileNameA ohne dass man etwas am Quellcode ändern müsste.

Also: Am besten statt char immer TCHAR benutzen und eine TCHAR-string-Klasse benutzen, dann braucht man sich nicht um Konvertierungen kümmern. Mit den Funktionen WideCharToMultiByte und MultiByteToWideChar hätte man die Möglichkeit zur Konvertierung, falls es wirklich nicht ohne geht.

Man kann diese UNICODE-typedefs natürlich auch mit anderen STL-Klassen durchführen und dann ohne Probleme mit der WINAPI kombinieren.

lg XOR

taurus

ja die grundlagen.. wird zeit für ein buch

std::tstring strExe(strTemp);

was bewirkt das denn??

Dravere

xor schrieb:

Also: Am besten statt char immer TCHAR benutzen und eine TCHAR-string-Klasse benutzen, dann braucht man sich nicht um Konvertierungen kümmern.

Also ich würde eher empfehlen Win98 zu vergessen und auf Windows gleich wchar_t , std::wstring , usw. zu verwenden. Auch finde ich dieses Makro UNICODE ein wenig gefährlich benannt. Ich verwende noch oft std::string , char , usw. für UTF-8 und das ist auch Unicode

Grüssli