- This topic has 10 hozzászólás, 3 résztvevő, and was last updated 18 years, 6 months telt el by
.
-
Bejegyzés
-
csatolok egy igen konkret kimenetet. (lehet, hogy a sorok szama az elozo csatolt allomannyal nem fog pontosan egyezni)
Code:hworld.cpp:40: error: conversion from `const char[12]’ to `const wxString’ is ambiguousNem lehet a karakter tömböt (a) int címet / b)int számot) konvertálni, mert kétértelmű.
Kód: (cím, érték a címen)
0x25368698: ‘s’
0x25368699: ‘t’
0x25368700: ‘r’
0x25368701: ‘i’
0x25368702: ‘n’
0x25368703: ‘g’
0x25368704: 0Paraméter: (amit megkap a függvény)
0x25368698a)
Ez egy cím.
Pl:
Kiíratás a képernyőre: [0x25368698]
Kiíratás a képernyőre: [0x25368699]
…Eredmény:
user@localhost ~$ stringb)
Ez egy szám.
Pl.:
Összeg = 0x25368698 + 1
Kiíratás: Összeg (hexa számként)
Eredmény:
user@localhost ~$ 0x25368699Akkor, hogyan?
(wxString) int_szam
Akkor a eset. (A függvényt kell figyelembe venni a fordítónak.)(Az c++ oo cucc átka. ;D)
Ugy tunik, a problema nem ilyen egyszeru. Vagyis probaltam mar minenfele cast-operatorral, de nem jutottam sokra. Ha sima wxChar-ra castolotm a karakterlancokat (tudom, nem mukodokepes), DE akkor lefordul a program, viszont a karakterlancok helyen egy rakas kerdojel jelenik meg. Erdekes modon nem segfaultol el.
Kozben utananeztem, hogy mi is van a megadott helyeken a string.h-ban. A kovetkezo constructorok kozott nem tud valasztani a fordito:633:
// these methods are not implemented – there is _no_ conversion from int to
// string, you’re doing something wrong if the compiler wants to call it!
//
// try `s << i' or `s.Printf("%d", i)' instead
wxString(int);644:
// string containing nRepeat copies of ch
wxString(wxChar ch, size_t nRepeat = 1)
: wxStringBase(nRepeat, ch) { }Elolvasva a megjegyzest az elsohoz, a problema egyre furcsabbnak tunik. ???
Nem úgy van az, hogy csak minden izé nélkül…
Bár én nem a wx-et, hanem gtk+-t szoktam használni, de gondolom a wx is támogatja az utf-et (még, ha legjobban windózkompatibilis is). Ennek következtében a sima karakterlánc nem sima karakterlánc.
Továbbmenve ez a bizonyos karakterlánc objektum soha nem a karakterlánc címét jelenti, hanem a karakterlánc tartalmú objektum címét.
Tehát pl. String = int_karakterlánc, nem egy értékadás, hanem egy függvény (így ebben a formában operátorral), mely átkonvertálja az int típusú karakterláncot arra a speciális utf stringre. A kiíratással ugyanez a helyzet (fordítva). (Szerintem ez a wxStringgel sincs másképp.)
(A típuskonverció akkor működik helyesen, ha azt konvertálod, ami konpatibilis… ezt meg neked kell tudni.)Szóval a dokumentumokat nézegesd a megoldásért. (Kár találgatni, amikor olvasni is lehet.)
Mivel nem használom, ezért konkrétan, csak glibes ustring-es példát tudnék csak mondani, de minden bizonnyal hasonlóan működik ez is…Én csupán a technikai részleteket próbáltam megosztani, hogy miért csinálja. Az, hogy milyen „csicsát” okoz a függvény, meg milyen körítést vár, az a doksiban le van írva.
Ezzel mind egyetertek. A nagyon nagy gondom az, hogy ezt a programot egy az egyben egy wxwidgetes oldalrol szerdem le, mint a „Hello world” program wxwidgetben. Es mint irtam, uhu 1.2 alatt siman lefordul, uhu 2.0 alatt mar nem (hanem azt a fura hibat produkalja). Ezert vagyok egy kicsit megakadva rajta, hogy nem megy. (Ha en irtam volna, akkor magamban keresnem a hibat — habar nem kizart, hogy most is tennem van)
Más a wx verzió, más a fordító.
Pl. lehet olyan kódos írni, mely gcc-vel lefordul, g++-szal nem (minden ugyanaz a verzió), és viszont. (Az egyikkel max. egy warningot produkál (vagy azt sem), a másikkal nem fordul.)
Sőt a legtöbb kódban előfordul ilyesmi. Pl. úgy gondolnád, hogy egy c programot simán lefordítasz egy c++ fordítóval, de ez nem igaz… a legtöbb c kód nem kompatibilisen van megírva, noha meg lehetne úgy írni. (De pl. senki nem szeret fölöslegesen gépelgetni, mert a c kód típus konverciójánál elszáll a c++ fordító… Kit érdekel! Ne azzal fordítsd. ;D)Ebből kiindulva pl. én egy c++ kódhoz biztosan nem c fordítót használnék… alapból. (Noha a kiterjesztés miatt tán azt „veszi elő”, de jobb az óvatosság.)
Megyek meg dokumentaciot olvasni, mert leszedtem egy masik peldaprogramot, ami mar mukodott. Ebbol kilestem, hogy hogyan kell a karakterlancokat helyesen hasznalni wxWidgetsel. Tehat a sima
Code:„karakterlanc”helyett mindenutt
Code:_T(„karakterlanc”)-ot kell hasznalni. Hogy miert, pontosan nem tudom, de ugy mukodik
„-ot kell hasznalni. Hogy miert, pontosan nem tudom, de ugy mukodik”
Az a gettex lesz… (minden bizonnyal… a doksiban benne kell, hogy legyen)
_T(String) gettext (String)Vagyis gettext(„karakterlánc”)
ami behelyettesíti a „karakterlánc” C szöveg helyére a lokalizációs file-ban szereplő xx_YY nyelvű szöveget.Hogy miért működik?
Lehet, hogy azért, mert a gettext nyílván (utf) char*-ot csinál a te char[X]-edből.Kiprobaltam, hogy mire helyettesitodik be ez a makro. Gyakorlatilag
Code:_T(„valami”)helyett
Code:L”valami”jelenik meg a forrasban (ez ugy probaltam ki, hogy csak a preprocesszort engedtem ra a forrasra 😉
Igy van ertelmezve:
Code:// —————————————————————————-
// define _T() and related macros
// —————————————————————————-// BSD systems define _T() to be something different in ctype.h, override it
#if defined(__FreeBSD__) || defined(__DARWIN__)
#include
#undef _T
#endif// could already be defined by tchar.h (it’s quasi standard)
#ifndef _T
#if !wxUSE_UNICODE
#define _T(x) x
#else // Unicode
#define _T(x) L ## x
#endif // ASCII/Unicode
#endif // !defined(_T)// although global macros with such names are normally bad, we want to have
// another name for _T() which should be used to avoid confusion between _T()
// and _() in wxWindows sources
#define wxT(x) _T(x)Na megnézetem a neten:
Először is itt van a konkrét megoldás eleve a neten. Nem is kellett volna szívni.Igen úgy működik, mint az ustring, meg stb…: wxString(„whatever”).c_str(), a normál string lekérdezése. A másik meg a wxString (utf) létrehozása.
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz