Mě z toho GCC trefí ...

17.8.2006 16:58 | Přečteno: 1435× | Linux | poslední úprava: 17.8.2006 19:58

Tak jsem narazil na další problém s GCC.

template<typename T>
class BaseString{
protected:
  ...
public:
  ...
  T& operator[]( unsigned int pos );
  const T& operator[]( unsigned int pos ) const;
  // V tomhle bude problém
  operator T*();
  operator const T*() const;
};

V kódu je následující:

// pathW je BaseString<wchar_t>, DIR_SLASH je define L'/' nebo L'\\' dle systému
return ( pathW.length() == 1 && pathW[0] == DIR_SLASH );

A co se dá čekat od GCC jiného než

./Toolkit/FileUtils.cpp:120: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
./Toolkit/String.h:378: note: candidate 1: T& Toolkit::BaseString<T>::operator[](unsigned int) [with T = wchar_t]
./Toolkit/FileUtils.cpp:120: note: candidate 2: operator[](wchar_t*, int) <built-in>

Proč dopr*ele se snaží o ten vestavěný operátor. Zase se prostě rozhodl, že je možné přetypovat BaseString<wchar_t> na wchar_t*, tak hned začal dělat chytrého a cpe mi to. Já se ho ale neprosil. Teď jak z toho ven. Ten operátor k přetypování je pro mě životně důležitý a funkci kvůli tomu tam nechci.

       

Komentáře

[Michal Kubeček]

Problém bude někde jinde. Když to napíšu tak, jak to uvádíte, gcc (4.1) s tím nemá žádný problém.

[msk]

Ci to nebude starsou verziou gcc. Jo hold, 4 je 4, ale co tie predosle paskvily?

[Michal Kubeček]

V trojkové řadě skutečně byly v implementaci C++ chyby, ale tipoval bych, že tohle není ten případ. Většinou je totiž čtyřková řada na syntaxi přísnější než starší verze.

[Jardík]

Problém je určitě tady. GCC si to prostě chce přetypovat. Když odstraním "operator T*" tak to funguje. GCC 4.1.1.

[Michal Kubeček]

Ne, není. Zkuste si toto

#define DIR_SLASH L'/'

template<typename T>
class BaseString{
protected:
public:
  unsigned length() const { return 0; }
  T& operator[]( unsigned int pos );
  const T& operator[]( unsigned int pos ) const;
  // V tomhle bude problém
  operator T*();
  operator const T*() const;
};


typedef BaseString<wchar_t> wstr;

bool isslash(const wstr& pathW)
{
  return ( pathW.length() == 1 && pathW[0] == DIR_SLASH );
}

uložit do souboru a přeložit (nelinkovat). Mé gcc ani nepípne, dokonce ani s -Wall Problém je tedy někde jinde než v tom, co jste nám ukázal.

[Jardík]

$ g++ -c -Wall test.cpp
test.cpp: In function ‘bool isslash(const wstr&)’:
test.cpp:20: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
test.cpp:9: note: candidate 1: const T& BaseString<T>::operator[](unsigned int) const [with T = wchar_t]
test.cpp:20: note: candidate 2: operator[](const wchar_t*, int) <built-in>
test.cpp:20: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
test.cpp:9: note: candidate 1: const T& BaseString<T>::operator[](unsigned int) const [with T = wchar_t]
test.cpp:20: note: candidate 2: operator[](const wchar_t*, int) <built-in>

[Michal Kubeček]

Mám-li být upřímný, nechce se mi teď zkoumat specifikaci, zda má gcc pravdu, ale tipoval bych, že spíš ano. Pokud napíšete něco, co lze vyložit podle pravidel jazyka vyložit nejednoznačně - a to jste udělal - vidím problém ve vašem zdrojáku a ne v překladači.

[Jardík]

To je sice hezké, ale ...
Zajímavé je, že vám to ani nepípne. Přitom stejná verze GCC.

[Michal Kubeček]

Úplně stejná není, já mám 4.1.0, takže je možné, že to ve 4.1.1 opravili.

[Jardík]

K tomu nejednoznačně. Já myslím, že je to jednoznačné až dost. Normální kompilátor by si měl nejprve projít operátory té třídy, když se pak hodí, použí je, a poté teprve hledat alternativy. Ale stejně mě deptá, že vám to funguje.

[Michal Kubeček]

Zkuste mu ten index zapsat explicitně jako '0L', pak by to mohlo přesně odpovídat deklaraci.

[Michal Kubeček]

Na druhou stranu je možná právě tohle důvod, proč ve standardní knihovně ten přetypovávací operátor není.

[happy barney]

ved presiel ... ale otazka znie, mal koder na mysli priamo operator [], alebo chcel najprv pouzit operator pretypovania na pointer a potom pouzit [] ?

imho, co tam ten operator pretypovania (a dokonca const) na pointer robi? Kandiduje na uchylku roku?

[Michal Kubeček]

Právě že otázka nezní, co tím měl autor na mysli, ale co to znamená podle specifikace jazyka - a to mu překladač sdělil.

[happy barney]

no tak som to myslel, ze taku otazku si polozi kompilator, ktory, aspon z mojho pohladu, by autorove myslienky mal pochopit spravne. A ak otazku nevie jednoznacne zodpovedat, tak krici.
Zaujimave je, ako sa ludia naucili povazovat programy za zive, rozmyslajuce entity.

Zase se prostě rozhodl, že je možné přetypovat BaseString<wchar_t> na wchar_t*, tak hned začal dělat chytrého a cpe mi to. Já se ho ale neprosil

Hmm, a teraz som si vlastne vsimol, ze autor vlastne ani nevie, co naprogramoval

[Michal Kubeček]

Mne by spíš zajímalo, proč to na x86_64 projde. Ale to by asi chtělo pořádně si přečíst příslušnou část specifikace.

[Jardík]

Zkuste zkompilovat toto:

#include <wchar.h>
#include <memory>

class WideString{
protected:
	wchar_t* buffer;
public:
	WideString( const wchar_t *text )
	{
		buffer = wcsdup(text);
	}
	~WideString()
	{
		free(buffer);
	}
	
	wchar_t& operator[](unsigned int pos)
	{
		return buffer[pos];
	}
	
	const wchar_t& operator[](unsigned int pos) const
	{
		return buffer[pos];
	}
	
	operator wchar_t*()
	{
		return buffer;
	}
	
	operator const wchar_t*() const
	{
		return buffer;
	}
};

int main( int argc, char **argv )
{
	WideString str( L"TESTIK" );
	if( str[0] == L'T' ) str[0] = L't';
	return 0;
}

[Michal Kubeček]

Žádná chyba, žádný warning.

[Mikos]

Jen tak na zkoušku jsem to zkusil (v C ani C++ se moc extra zrovna nevyznam), ale chyb mi to vyhodilo taky.

GCC 4.1.1 (defaultní v Arch Linuxu):

[mikos@tauri temp]$ g++ -c -Wall test.cpp
test.cpp: In function ‘int main(int, char**)’:
test.cpp:41: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst
 conversion for the second:
test.cpp:17: note: candidate 1: wchar_t& WideString::operator[](unsigned int)
test.cpp:41: note: candidate 2: operator[](wchar_t*, int) <built-in>
test.cpp:41: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst
 conversion for the second:
test.cpp:17: note: candidate 1: wchar_t& WideString::operator[](unsigned int)
test.cpp:41: note: candidate 2: operator[](wchar_t*, int) <built-in>
test.cpp:41: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst
 conversion for the second:
test.cpp:17: note: candidate 1: wchar_t& WideString::operator[](unsigned int)
test.cpp:41: note: candidate 2: operator[](wchar_t*, int) <built-in>
test.cpp:41: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst
 conversion for the second:
test.cpp:17: note: candidate 1: wchar_t& WideString::operator[](unsigned int)
test.cpp:41: note: candidate 2: operator[](wchar_t*, int) <built-in>

A jen pro zajímavost GCC 3.3.6:

[mikos@tauri temp]$ g++3 -c -Wall test.cpp
test.cpp: In function `int main(int, char**)':
test.cpp:41: error: ISO C++ says that `wchar_t& WideString::operator[](unsigned
   int)' and `operator[]' are ambiguous even though the worst conversion for
   the former is better than the worst conversion for the latter
test.cpp:41: error: ISO C++ says that `wchar_t& WideString::operator[](unsigned
   int)' and `operator[]' are ambiguous even though the worst conversion for
   the former is better than the worst conversion for the latter
test.cpp:41: error: ISO C++ says that `wchar_t& WideString::operator[](unsigned
   int)' and `operator[]' are ambiguous even though the worst conversion for
   the former is better than the worst conversion for the latter
test.cpp:41: error: ISO C++ says that `wchar_t& WideString::operator[](unsigned
   int)' and `operator[]' are ambiguous even though the worst conversion for
   the former is better than the worst conversion for the latter

[Mikos]

Ale musim říct, že GCC důvěřuji a navíc GCC 4.1.x (alespoň co sem tak všude četl) se normy drží opravdu pěkně, takže chyba asi bude vážně někde v tom kódu

Nicméně je opravdu velmi zvláštní, že vám to prošlo bez problémů...

[David Watzke]

Nicméně je opravdu velmi zvláštní, že vám to prošlo bez problémů...

Vidím to na architekturu...

[Mikos]

Architektura je prachobyčejná x86

[David Watzke]

No právě

[Zdeněk Burda]

Myslíš, že na UltraSPARCu to bude lepší?

[David Watzke]

Nevím, ale na AMD64 je

[Jardík]

To může být třeba tím, že se pro indexování polí nepoužívá int, ale třeba "long long".

[Michal Kubeček]

Spíš to bude souviset s tím, že sizeof(int) != sizeof(long)

[David Watzke]

Jj, když GCC dám ještě -m32, taky hodí chybu.

[Michal Kubeček]

A když se ten index zapíše jako '0U' (nebo operátor [] deklaruje jako int), projde to i s -m32.

[David Watzke]

GCC 4.1.1 na Gentoo/AMD64 v pohodě bez warningů...

[jekub]

No a co si má podle Vás překladač při použití str[0] vybrat? WideString::operator[], nebo WideString::operator wchar_t* ?

Pokud to upravíte na str[0u], mělo by to fungovat. Doporučuju nastudovat implicitní konverze v C++.

[jekub]

A ještě zkuste toto

int main( int argc, char **argv )
{
	WideString str( L"TESTIK" );
   free(str);

	return 0;
}

[David Watzke]

Sorry, ale s/Mně/Mě/g, 2. a 4. pár = mě, 3. a 6. pád = mně.

[David Watzke]

s/pár/pád/

[pasmen]

Prestanou uz lidi nekdy zapraskavat thready temyhle zbytecnymi spam prispevky?

[Michal Kubeček]

Zbytečný není a spam už vůbec ne…

[pasmen]

Zbytecny je. Koho v threadu o gcc zajima lingvisticka vlozka? Nikoho, akorat to rusi to podstatne. Pardon, mozna Vas to zajima...

[Michal Kubeček]

Mne spíš ruší, když vidím tu hrubku na titulní stránce…

[David Watzke]

Taky doufám, že si to všichni zapamatují

[Jardík]

Popraveno.

[Jardík]

s/Popraveno/Opraveno/g.

[Deleted [8409]]

Nemůžu si pomoct, ale jak už jsem upozorňoval v minulém (snad předminulém) blogu, tento kód není multiplatformní. V systému kde je wchar_t pouze 16 bit a znak je větší než 65535 to není schopné fungovat.

[Michal Kubeček]

Není to spíš problém chybně navržené implementace, pokud její wchar_t není schopen pokrýt potřebný rozsah znaků?

[Deleted [8409]]

Myslím že už je příliš pozdě to měnit (ve Win), takže se s tím musíme smířit nebo si udělat vlastní string (můj případ).

[Mikos]

Nebo prostě a jednoduše se vykašlat na rozbité nefunkční platformy :-P

[Michal Kubeček]

Takže se na věky věků bude muset Unicode omezit na necelých 2^16 znaků? Tak to si s ním nemuseli dávat tolik práce…

[Deleted [8409]]

Win 2000 používá UCS2, ale WinXP používá UTF16, to je důvod mé reakce.

Předpoklad že wchar_t je jeden znak je prostě špatný. Jak říkám, v linuxu to funguje, jinde nemusí.

[Michal Kubeček]

To není špatný předpoklad, protože je to předpoklad, vycházející ze specifikace jazyků C

3.7.3 wide character bit representation that fits in an object of type wchar_t, capable of representing any character in the current locale

a C++

3.9.1.5 Type wchar_t is a distinct type whose values can represent distinct codes for all members of the largest extended character set specified among the supported locales (22.1.1).

Takže trvám na tom, že je-li něco špatně, je to implementace widestringů ve Windows (vypadá-li tak, jak tvrdíte). Kdyby totiž měl být wchar_t 16-bitový typ a widestringy by měly být v UTF-16, nemělo by smysl je vůbec zavádět, protože by proti klasickým stringům v UTF-8 naprosto nic nepřinášely.

[Deleted [8409]]

Jenže když se ve windows objevil poprvé unicode (UCS2), tak si mysleli že 16 bit wchar_t bude stačit a ve standardu to tak bylo. Změna proběhla pozděj a to jak jsem psal bylo příliš pozdě na to změnit API (přešli na UTF16).

Jinak máte pravdu, že takový wchar_t nepřináší nic nového oproti UTF8, plný souhlas.

Šlo mi jen o to, že když chci psát program, který poběží ve windows a v linuxu, tak je úvaha že wchar_t = jeden znak špatná, toď vše.

[Michal Kubeček]

Ne. Co je špatné, je windowsová implementace - vypadá-li opravdu tak, jak tvrdíte. V ISO specifikaci obou jazyků je jasně a zřetelně řečeno, že wchar_t je datový typ, který pokrývá celý rozsah znakové sady používaného locale, takže jeden wchar_t podle specifikace jazyka odpovídá jednomu znaku (to je také důvod, proč byly vůbec wchar_t a widestring zaveden). Tak je ten typ definován a tak má fungovat. Pokud tak někde nefunguje, není to korektní implementace ISO C resp. ISO C++.

[Deleted [8409]]

Máte pravdu, není to korektní.

Chtěl jsem jen upozornit na to že to tak je a žádný smrtelník s tím nic neudělá. Jestli má frčet aplikace jen pod linuxem, není co řešit.

Aby jste mi věřili:

#include <stdio.h>
#include <wchar.h>
int main(int arg, char* argv[])
{
	printf("%u\n", sizeof(wchar_t));
	return 0;
}

výstup:

2

kompilováno ve win, pod gcc i ve visual studiu, ahoja

[Mikos]

Jestli má frčet aplikace jen pod linuxem, není co řešit.

Správně jste měl říct: "Jestli má frčet aplikace pod jakýmkoliv rozumným operačním systémem, není co řešit."

[Deleted [8409]]

Já ale nehodlám rýpat do žádného operačního systému, navíc si myslím že na embedded zařízeních je wchar_t také většinou 16 bit.

[Michal Kubeček]

Což o to, 16-bitový wchar_t specifikaci sám o sobě neodporuje. Pokud pokryje celý rozsah použité znakové sady a pokud jeden widechar bude jeden znak, je to v pořádku. Chybou je, pokud bude jeden znak zapisován více widechary, tj. začne se zavádět nějaký "multi-widechar string", který v sobě spojí nevýhody MBS a WCS.

[Michal Kubeček]

Prostě chci říci, že primární důvod, proč byl vůbec typ wchar_t a WCS zaveden, je to, aby bylo možné opět interně pracovat s reprezentací řetězců, kde jedna položka pole odpovídá jednomu znaku. Implementace, kde je jeden znak popsán více widechary, odporuje jednak specifikaci, jednak zdravému rozumu a do třetice je úplně k ničemu.

[Deleted [8409]]

Já s tím ale plně souhlasím a to je důvod, proč jsem si musel napsat svůj string který je vždy 32 bit (byly i jiné důvody)

Pro mě osobně je dobrá implementace řetězců základ

[zde]

Můžete uvést jedinný užitečný a potřebný znak, který je v UTF-{8|16} a není v UCS2 ?

[Deleted [8409]]

Ještě bych jen doplnil že Win má sice 16 bit unicode, ale znaky pojme všechny díky UTF16 kódování, stejný připad je třeba v javě, .net a qt.

[alblaho]

Vzpomněl jsem si, co říkal Martin Fowler na nějaké konfeře o Ruby. "Už jsem v C++ dlouho neprogramoval. Ale ne _dost_ dlouho."

Ne snad, že by bylo C++ nějaké zlo, jen je složité jaxfina.

[zde]

C++ JE zlo.