jankowalski25 |
» 2018-04-08 22:16:15 Ja z kolei zakładam, że do mnie, a konkretniej do fragmentu: | Nie ma problemu, wystarczy sprawić, by całość trwała równie długo dla każdego przypadku (ale chyba nie o to chodziło). Wszystko da się zrobić ze złożonością O(1), ale nie zawsze jest to dobrym pomysłem i lepiej wybrać inną złożoność, jeśli stałe będą mniejsze (lub przechowywać dane w innej formie, na przykład zmieniając kodowanie znaków). |
Jeśli chodzi o ten kawałek, to celowo tak napisałem, ale przecież w praktyce nikt tak nie robi! Nie ma sensu wymuszać złożoności O(1) z jakąś gigantyczną stałą (bo do tego się sprowadza mój pomysł). Złożoność O(n) może być w praktyce lepsza od O(1), jeśli stałe będą odpowiednio dobrane. A co do zmiany kodowania, to raczej miałem na myśli robienie tego statycznie, a nie dynamicznie (jeśli w ogóle zajdzie taka potrzeba). Ten przykład miał pokazać tyle, że lepiej nigdzie nie pisać, że czegoś nie da się zrobić ze złożonością O(1), bo z tego co mi wiadomo, to każdy algorytm można sprowadzić do takiej postaci, tylko to będzie strasznie niepraktyczne. Takie tam czepianie się w moim stylu testera, który chce zrobić coś inaczej niż przeciętny człowiek i szuka dziury w całym, którą można byłoby załatać... W tym przypadku zamiast napisać po prostu:
SetWindowTextW( L"łąka" );
::SetWindowTextW( Utils::convert( MalaLiteraLzOgonkiemWUtf8 + MalaLiteraAzOgonkiemWUtf8 + "ka" ).c_str() )
|
Nie, jeśli już, to SetWindowTextW( GET_TRANSLATED_STRING( meadow ) ) , gdzie GET_TRANSLATED_STRING może być podstawiane w czasie kompilacji (napisałem to wielkimi literami sugerując makro, ale równie dobrze można byłoby spróbować użyć szablonów lub w jakiś inny sposób podstawiać tutaj właściwy tekst zanim nastąpi faza kompilacji wkładająca luzem surowe bajty do binarki). Ewentualnie można mieć jakiś plik z napisami w UTF-8, który przy kompilacji pod Windowsa zostanie przekonwertowany na UTF-16, a następnie zaciągnięte stamtąd napisy trafią bezpośrednio do exeka. | Wnioskuję, może błędnie, że akceptują one UTF-8, a UTF-16 już nie. |
Akceptują const char * , a co się z tym dalej dzieje, to zależy już od implementacji, do której trzeba się po prostu dopasować (lub użyć czegoś innego jeśli standardowa implementacja nie spełnia oczekiwań). Ten temat powinien się chyba nazywać
| std::wstring and UTF-16 is [CENSORED]. Change my mind. |
|
Dlaczego? Dyskusja o kodowaniach się rozwinęła, bo to jest jeden z problemów zamiatanych pod dywan, który później odbija się czkawką, ale skoro wspomniałeś też o innych zagadnieniach związanych z bibliotekami, to chyba nic nie stoi na przeszkodzie, aby zadać pytanie tego dotyczące i skierować rozmowę w biblioteki przeznaczone do innych celów niż obsługa Unikodu. |
|
RazzorFlame Temat założony przez niniejszego użytkownika |
» 2018-04-08 22:41:48 | Akceptują const char * , a co się z tym dalej dzieje, to zależy już od implementacji, do której trzeba się po prostu dopasować (lub użyć czegoś innego jeśli standardowa implementacja nie spełnia oczekiwań). |
Masz rację, ale UTF-8 raczej muszą teraz wspierać, przecież specjalnie do tego jest w C++17 std::filesystem::u8path . Mam przynajmniej nadzieję, że gdzieś jest to oficjalnie napisane. |
|
DejaVu |
» 2018-04-08 22:47:34 Qt => QString => QChar => 16bit. Bang! Bang! http://doc.qt.io/qt-5/qchar.htmlProponuję podyskutować jeszcze o innych problemach jak np. GUI w C++. Niektórym nie odpowiada np. licencja typu LGPL co eliminuje używanie np. takiego Qt-a. Jakie alternatywy proponujecie do GUI? |
|
jankowalski25 |
» 2018-04-08 22:51:04 SFGUI? wxWidgets? WinAPI? To tak na początek, z tych co już padły w tym temacie. Dopisano:| UTF-8 raczej muszą teraz wspierać |
Chyba nie muszą. System plików może być dowolny, a implementacja może po prostu szukać takiego pliku, gdzie przekazane bajty zgadzają się z tymi, które są zapisane na dysku. Sam jestem ciekaw, jak przenośnie sprawdzić, jaki format jest tutaj oczekiwany. Ogólnie czasami mam takie wrażenie, że słowa "w razie wątpliwości zachowanie jest niezdefiniowane" należy sobie napisać na żółtej karteczce, przykleić do monitora i spoglądać na nią w razie jakichkolwiek wątpliwości podczas pisania w C++. | Niektórym nie odpowiada np. licencja typu LGPL |
Zastanawiam się nad skutkami ubocznymi linkowania wszystkiego statycznie i dostarczenia narzędzia umożliwiającego podmianę niektórych kawałków na takie, jakich ktoś mógłby sobie życzyć. Chyba jednak to byłoby zbyt skomplikowane, chociaż teoretycznie pewnie możliwe... Nieważne, może lepiej wrócić na razie do bibliotek graficznych. |
|
Elaine |
» 2018-04-08 23:11:36 | Zastanawiam się nad skutkami ubocznymi linkowania wszystkiego statycznie |
Linkowanie statyczne to relikt z uniksów z lat siedemdziesiątych, niech tam pozostanie. :P | Zastanawiam się nad skutkami ubocznymi linkowania wszystkiego statycznie i dostarczenia narzędzia umożliwiającego podmianę niektórych kawałków na takie, jakich ktoś mógłby sobie życzyć. Chyba jednak to byłoby zbyt skomplikowane, chociaż teoretycznie pewnie możliwe... |
Takie narzędzie już wymyślono, nazywa się linker. |
|
RazzorFlame Temat założony przez niniejszego użytkownika |
» 2018-04-08 23:16:29 | Proponuję podyskutować jeszcze o innych problemach jak np. GUI w C++. |
Ja nie mam nic przeciwko, rozwija się ciekawy temat. | Chyba nie muszą. System plików może być dowolny, a implementacja może po prostu szukać takiego pliku |
Warto jednak też poczynić jakieś rozsądne założenia. W praktyce, pewnie nie wszystko obsługuje ASCII :P W ogóle mam wrażenie, że C++ tak bardzo chce być "do wszystkiego", że przez to zostaje w tyle. A co do GUI: Może z tego się coś rozwinie. Bazowane na wxWidgets: Boost.UIJestem ciekaw, kiedy ktoś przygotuje jakąś szanującą się, wielką bibliotekę do GUI dla C++, o takich możliwościach jak np. WPF w C#. C++ ma cholernie duże możliwości, ale z tego co zauważyłem to rzadko powstają takie narzędzia "generalnego użytku". Wiecie, coś co może się przydać większości. Jak już to powstają jakieś molochy jak UE4, Qt, Unity itd. Mój wishlist do biblioteki standardowej, który pewnie nigdy się nie spełni: A tak jeszcze offtopując, to marzy mi się, że kiedyś będę mógł np. napisać tak: template < typename CharType >
void Log::flush()
{
if constexpr( $ System.Console.Available )
{
std::cout < CharType > << m_buffer;
}
else
{
$ Compiler.Error( "Your OS does not provide console as standard output target." );
}
}
Aww... |
|
jankowalski25 |
» 2018-04-08 23:24:50 Co do GUI, to może zacznę od najprostszego, czyli od samej konsoli. W wielu przypadkach narzędzia z #include <iostream> całkiem nieźle się sprawdzają i są wystarczająco ogólne i przenośne, aby z nich korzystać. Kodowanie znaków zostało przed chwilą dość dokładnie opisane, więc to pominę (zwykle nie powinno być większych problemów z ustawieniem tego tak, aby wczytywać i zapisywać odpowiednie bajty, a to wystarczy do tego, by konsola wyświetliła to, co chcemy zobaczyć, byleby czcionka miała odpowiednie glify). Z tych przenośnych to ncurses, ewentualnie nieco mniej przenośne jest WinAPI (ale wineconsole sobie z tym poradzi), pod dystrybucjami Linuksa są odpowiednie terminale, w zależności od środowiska graficznego, w którym działają, a napisanie własnego graficznego terminala nie powinno stanowić większego problemu i można zrobić go tak samo, jak każdą inną aplikację okienkową. Raczej chodziło o to, aby mając jeden, poskładany i zoptymalizowany plik binarny w wersji Release, użytkownik mógł dostarczyć własną implementację jakiejś biblioteki (jeśli jakaś licencja tego wymaga) i otrzymać jeden plik binarny, analogiczny do tego, gdyby sam skompilował wszystko statycznie od zera. Ale jak już wspomniałem, to jest dość wydumane i raczej nieopłacalne (chyba że znasz jakiś prosty sposób, aby to zrobić). | Refleksja (to w sumie i biblioteka standardowa i zmiany w core) |
Dlaczego? Elaine podobno zaimplementował dynamic_cast działające w czasie kompilacji (co jest lepszym pomysłem niż robienie tego samego w czasie wykonania, o ile założenia pozwalają na napisanie programu tak, aby dało się z tego skorzystać). A jakiś czas temu chyba podawał pod dywanem przykład, gdzie otrzymał refleksję w czasie kompilacji za pomocą boosta i preprocesora (jak znajdę, to wstawię link). A co do tego kodu, który podajesz, to trochę mnie to dziwi. Nie lepiej użyć std::cout << GET_TRANSLATED_STRING( cokolwiek ); zgodnie z tym, co wcześniej napisałem? |
|
RazzorFlame Temat założony przez niniejszego użytkownika |
» 2018-04-08 23:29:30 | Nie lepiej użyć std::cout << GET_TRANSLATED_STRING( cokolwiek ); zgodnie z tym, co wcześniej napisałem? |
Też można :) W każdym razie nie zawsze można w czasie kompilacji określić co będzie wypisywane. Tak tylko napisałem. Ciekawie by było, gdyby z std::cout zrobili template variable. | A jakiś czas temu chyba podawał pod dywanem przykład, gdzie otrzymał refleksję w czasie kompilacji za pomocą boosta i preprocesora (jak znajdę, to wstawię link). |
No właśnie jest to możliwe... tylko jakim nakładem pracy. Z refleksją można by było zrobić to samo ładniej, szybciej i przyjemniej. Mi się marzy też bardziej zaawansowana refleksja :P np. coś takiego:
namespace foo::bar::baz
{
void hey()
{
$f = $this_function();
for($ns : $namespace_iterator( f ))
{
std::cout << $ns.name() << "::";
}
std::cout << $f.name() << std::endl;
}
}
// Wynik:
// "foo::bar::baz::hey"
Może to troche abstrakcyjne, ale jakie fajne! I wyobraźcie sobie jak takie ficzery ułatwiłyby np. logowanie błędów. |
|
| 1 2 3 « 4 » 5 |