Sklejanie wierszy kodu w C++

2010-04-06 22:24

Języki programowania o składni podobnej do C nie narzucają specjalnych ograniczeń na to, jak pisany w nich kod formatujemy wizualnie. Możemy więc robić dowolne wcięcia, a także w dowolny sposób dzielić poszczególne instrukcje między wiersze w pliku źródłowym. Jest tak dlatego, że to inne znaki - jak średniki czy nawiasy klamrowe - nadają listingowi strukturę odczytywaną przez kompilator.

W C/C++ są jednak przynajmniej dwie sytuacje, w których "fizyczne" wiersze w pliku z kodem mają znaczenie. Przekonał się o tym każdy, kto próbował zdefiniować (dyrektywą #define) makro rozciągające się na kilka linijek. Ściśle rzecz ujmując, w ogóle nie da się tego zrobić - dyrektywy preprocesora z założenia zajmują zawsze dokładnie jeden wiersz. Można jednak sprawić, by ów wiersz... rozciągał się na kilka linijek:

#define FUNCTOR(name,params,code) class name { \
public: \
void operator()(params) \
code \
};
// disclaimer: nie należy zakładać, że powyższe makro
// ma jakikolwiek praktyczny sens ;)

Znak \ (backslash) robi właśnie ten rodzaj magii. "Skleja" on mianowicie dwie linijki kodu tak, że dla kompilatora stają się one jedną. Używając go, możemy więc rozbić makro preprocesora na wiele wierszy.

Druga sytuacja, w której tak stosowany backslash jest przydatny, to długie ciągi znaków pisane w kodzie:

std::cout <<"To jest bardzo długi komunikat, który w konsoli pojawi się \
w pojedynczym wierszu mimo tego, że tutaj w pliku źródłowym jest on podzielony \
na kilka następujących po sobie linijek." <<std::endl;

Potrafi on bowiem także "oszukać cudzysłów". Jednak identyczny efekt można też osiągnąć, jeśli wiemy, że kompilator sam skleja następujące po sobie napisy. "a" "b" daje na przykład to samo "ab". Dlatego też backslash w wielolinijkowych napisach jest stosunkowo rzadko używany.

Facebook, gry webowe i problem inwestycji

2010-04-01 17:12

No i stało się - kierowany zapewne diabelskimi podszeptami, zarejestrowałem się na Facebooku. Zło (a nawet Zuo) w najczystszej postaci żem uczynił i oprócz formułowania próśb o przebaczenie mogę jedynie usprawiedliwiać się, co mnie do tego zgubnego w skutkach czynu popchnęło. A owym skutkiem (a "zupełnie przypadkiem" również przyczyną) było to, że przyjrzałem się największemu bogactwu tego serwisu, czyli... grom, rzecz jasna :)
Gry na Facebooku dzielą się w sumie na dwie kategorie. Pierwsza z nich to wyewoluowana forma małych, szybkich gier flashowych, które służą do zabijania tych krótkich odcinków czasu, gdy akurat nie chce się nam robić czegoś pożytecznego. Ewolucja polegała tutaj na wykształceniu możliwości porównywania wyników ze znajomymi, co oczywiście natychmiast podnosi grywalność przynajmniej o 120% i jednocześnie uspokaja nas, że nie jesteśmy jedynymi osobami, które się obijają :)
Drugi typ to zabawa w systematyczne klikanie: należy mniej więcej raz na kilkanaście godzin zalogować się i coś zrobić, by posunąć rozgrywkę do przodu. Cokolwiek to jest, nie możemy tego zrobić częściej, bo nie pozwala na to mechanika gry pod postacią regenerującej się w czasie energii/many/itp. (jak choćby w Mafia Wars) czy też nierealistycznie krótkiego okresu wegetacyjnego truskawek (tak, mam tu na myśli oczywiście Farmville).

Jak widać w obu przypadkach nie jest to specjalnie absorbujące zajęcie. Z gier pierwszego typu do gustu przypadła mi Word Challenge, dzięki której wydatnie (czyli o jakieś 5%) poszerzył się mój zasób angielskich słówek (niestety jedynie takich, które mają co najwyżej sześć liter). Wybraną przeze mnie pozycją z kategorii drugiej jest z kolei Castle Age - coś w rodzaju MMORPG-a przez przeglądarkę, całkiem zresztą udanego. I właśnie z tym związany jest pewien ciekawy problem...

W rzeczonej grze oprócz niewątpliwie ekscytującego odklikiwania kolejnych questów mamy też - że powiem nieco na wyrost - wątek ekonomiczny. Należy tam bowiem kupować nieruchomości, które później co godzinę generują nam przypływ świeżej gotówki. Budynki różnią się ceną i uzyskiwanym z nich przychodem, a ponadto możemy kupować je nie tylko pojedynczego, ale i w pakietach (po 5 lub 10).
Jak pewnie nietrudno się domyślić, nasuwającym się tu od razu pytaniem jest to o optymalną strategię nabywania kolejnych budynków, skutkującą największym zyskiem w dłuższej perspektywie czasowej. Tak naszkicowany problem inwestycji (nazwa brzmi cokolwiek poważnie!) miałby więc następujące założenia:

Istnieje $n \in \mathbb{N}$ rodzajów budynków z przypisanymi cenami początkowymi $c_1, \ldots, c_n$ i zyskiem generowanym na jednostkę czasu: $z_1, \ldots, z_n$ . Początkowo posiadamy $k_1 = \ldots = k_n = 0$ budynków i pieniędzy, ale w każdej jednostce czasu możemy dokonać dowolnej liczby zakupów, o ile posiadane środki na to wystarczają.
Każdorazowo po dokonaniu zakupu budynku danego rodzaju, jego cena wzrasta o ustaloną wartość dla $i \in {1, \ldots, n}$ . Zakupu możemy dokonywać pojedynczo lub też w ilościach określonych przez zbiór $L \subset \mathbb{N}$ (w Castle Age mamy $L = \{ 5, 10 \}$ ), jednak zawsze tylko jednego rodzaju budynków naraz.
Istnieje ograniczenie $k \in \mathbb{N}$ na maksymalną posiadaną liczbę budynków jednego rodzaju - zatem zawsze zachodzi: $\forall i \le n, i \in \mathbb{N} \quad k_i \le k$ . Dla ułatwienia możemy przyjąć, że ograniczenie to jest stałe (w Castle Age jest ono związane z poziomem doświadczenia).

Pytamy tutaj o to, kiedy, ile i jakie budynki powinniśmy kupować, aby zmaksymalizować swój zysk w długim (najlepiej dowolnie długim) przedziale czasu. W szczególności zastanawiamy się, czy działa tu prosta strategia zachłanna - podobna do rozwiązania ciągłego problemu plecakowego - polegająca na zbieraniu zawsze takiej ilości gotówki, aby kupować maksymalną ilość najbardziej "efektywnych" budynków, tj. tych o największym ilorazie zysku do bieżącej ceny. Intuicja podpowiadałaby, że nie dla wszystkich zestawów danych musi tak być...

Zostawiam więc to zadanie jako materiał do przemyśleń na wolne dni. Nagroda za jego rozwiązanie będzie wielka: udowodni się w ten sposób, że gry z Facebooka mogą się do czegoś przydać!

Tagi: algorytmy, Facebook, Web 2.0
Autor: Xion w Gry, Internet, Programowanie » Komentarz (1)

Może być tylko jeden… shader

2010-03-26 20:42

Nie tak znowu dawno temu napisałem notkę na temat kilku typowych nieporozumień, jakie czasami pojawiają w temacie shaderów oraz związanych z nimi (przynajmniej w DirectX) plików .fx. Nie wspomniałem w niej jednak o pewnej kwestii, która jest kluczowa, dla wielu oczywista, a jednocześnie bywa nielichym i do tego niezbyt przyjemnym zaskoczeniem dla kogoś, kto dopiero zaczyna bliższe spotkanie z tematem programowania grafiki 3D.

Scenariusz wyglądać tu może mniej więcej tak. Na początku pracowicie zgłębiamy tajniki posługiwania się graficznym API (dla ustalenia uwagi możemy założyć, że będzie to DirectX :]), w idealnym przypadku zaznajamiając się też dogłębnie ze związaną z tym matematyką. Umiemy obiekty wyświetlać, teksturować, oświetlać, kontrolować ich widoczność, a może nawet i wczytywać skomplikowane modele z plików. Wydaje się, że to wszystko nie jest takie trudne... aż do momentu, gdy doznamy Szoku Typu Pierwszego i dowiemy się, że większość tych wszystkich technik opartych na fixed pipeline jest nam zupełnie niepotrzebna. Żeby bowiem osiągnąć jakiekolwiek sensowne i godne pokazania efekty, w tym chociażby te tak oczywiste jak dynamiczne światła czy cienie, trzeba używać shaderów...
No cóż, mówi się trudno i kodzi się dalej :) Pracowicie eksperymentujemy więc z różnymi efektami graficznymi, pisząc dla nich odpowiednie vertex i pixel shadery, ucząc się przekazywania danych od jednych do drugich, renderowania różnego rodzaju materiałów, korzystania z poszczególnych typów oświetlenia czy efektów postprocessingu i całej masy różnych innych, interesujących rzeczy. Aż w końcu przychodzi taki moment (i to raczej wcześniej niż później), że proste, pojedyncze efekty przestają nam wystarczać - i tutaj właśnie doznajemy Szoku Typu Drugiego.

A wszystko przez pewien prosty fakt. Staje się zresztą on tym bardziej oczywisty, im większą wiedzą na temat działania potoku graficznego dysponujemy. Ale nawet gdy zostaniemy już ekspertami od grafiki 3D, jest on - jak przypuszczam, rzecz jasna :) - wciąż irytujący i trudny do pogodzenia się. Co powoduje tego rodzaju rozterki egzystencjalne?...
To, że naraz można używać co najwyżej jednego shadera danego rodzaju (vertex lub pixel shadera). Tak, shader może być tylko jeden. Jeden, one, ein, un, uno, один, li pa (to ostatnie jest w lojbanie, rzecz jasna ;>). Dlatego właśnie nie istnieje jeden łatwy i szybki, a przede wszystkim ogólny sposób na to, by połączyć ze sobą dwie techniki, z których każda wymaga wykonania kawałka kodu na karcie graficznej dla wierzchołka i/lub piksela.

Nie znaczy to oczywiście, że sprawa jest beznadziejna - dowodem jest choćby to, że przecież gry 3D wciąż jakoś powstają ;) Różne rozwiązania są tu możliwe, jak choćby te opisane kiedyś przez Rega. Wahają się one na skali między złożonością i elastycznością, ale żadne z nich nie jest idealne.

Tagi: programowanie grafiki, shadery
Autor: Xion w Programowanie » Komentarze (6)

Wiązania zmiennych w anonimowych delegatach

2010-03-24 17:10

Możliwość używania delegatów w C# to fajna rzecz. Przyjemne jest zwłaszcza definiowanie ich "w locie", czyli bez konieczności tworzenia zupełnie nowej funkcji. Takiego delegata nazywamy wówczas anonimowym:

btnOK.Click += delegate (object sender, EventArgs e) { MessageBox.Show("Bu!"); }

Przydaje się to zwłaszcza to podawana różnego rodzaju predykatów do funkcji sortujących lub wyszukujących. Takie nienazwane funkcje są zwykle krótkie i bardzo proste.

A co jeśli jest inaczej?... W szczególności interesująca sytuacja jest wtedy, gdy nasz delegat odwołuje się do zmiennej zewnętrznej - czyli takiej, która nie została w nim zadeklarowana, ale której zasięg zawiera definicję delegata. Oto przykład:

public MainForm_Load(object sender, EventArgs e)
{
int x; // to jest zmienna zewnętrzna dla poniższego delegata
// ...
btnFoo.Click += delegate (object sender, EventArgs e)
{
if ((int)(sender as Control).Tag <x)
MessageBox.Show ("Bu!");
});
}

Pomyślmy teraz, że kliknięcie na przycisk btnFoo na pewno nastąpi już po zakończeniu funkcji MainForm_Load. Zmienna x jest w niej zmienną lokalną... Czy to oznacza, że stanie się wtedy coś złego, bo delegat spróbuje odwołać się do wartości zmiennej, która już nie istnieje?
Otóż nie; na szczęście nic złego się nie zdarzy. Kompilator potrafi wykryć taką sytuację zawczasu i przenieść zmienną zewnętrzną na zarządzaną stertę, gdzie czas jej życia może zostać wydłużony. Nawet jeśli jest to zmienna lokalna, będzie ona dostępna tak długo, jak długo chociaż jedno odwołanie do wykorzystującego ją delegata nie jest możliwe do uprzątnięcia przez garbage collector. Wszystko będzie więc dobrze i - co więcej - zupełnie przezroczyście: w powyższym przykładzie nie widać przecież żadnych oznak tego, że zmienna x jest w rzeczywistości znacznie mniej lokalna niż się na pierwszy rzut oka wydaje ;)

Widać zatem, że anonimowe delegaty w C# wiążą się ściśle ze swoimi zmiennymi zewnętrznymi, odwołując się do nich w razie potrzeby. Naturalnym efektem ubocznym jest fakt, że wobec tego wszystkie zmiany wartości zmiennych zewnętrznych są widoczne w kolejnych wywołaniach delegatów, które z nich korzystają:

delegate void Procedure();
//...
int i = 0;
Procedure p = delegate() { MessageBox.Show(i.ToString()); };
p();

i = 1;
p();

Powyższy kod (skompilowany pod .NET co najmniej 3.0) pokaże 0 i 1, bowiem anonimowy delegat wiązany jest z samą zmienną i, nie zaś jej wartością w momencie definicji funkcji (czyli 0). Że zachowanie to nie jest znowu tak oczywiste, można uzasadnić podając przykład biblioteki Boost.Lambda dla C++, gdzie jest odwrotnie. Tam domyślnie wiązane są same wartości zmiennych zewnętrznych (w momencie tworzenia anonimowej funkcji), ale można to zmienić niewielkim wysiłkiem (używając modyfikatora var, jeśli kogoś to interesuje).
W C# podobnej możliwości nie ma, a do anonimowych delegatów wiązane są zawsze same zmienne, a nie ich wartości. Jeśli jednak potrzebowalibyśmy czegoś takiego, to prostym wyjściem jest wprowadzanie zmiennej pomocniczej, zainicjowanie jej wartością zmiennej pierwotnej i używanie jej wewnątrz delegatu:

Procedure p;
int i = 0;
{
int j = i;
p = delegate() { MessageBox.Show(j.ToString()); };
}
p(); // 0

i = 1;
p(); // również 0

Zarówno delegata, jak i deklarację owej zmiennej dobrze jest też zamknąć w osobnym bloku kodu - tak jak powyżej. Dzięki temu eliminujemy możliwość przypadkowej jej modyfikacji, która oczywiście zostałaby "zauważona" przez delegata.

Tagi: C#, delegaty
Autor: Xion w Programowanie » Komentarze (6)

Aby nie śmiecić

2010-03-20 19:32

Jako moderator forum Warsztatu mam wątpliwą przyjemność kontaktu z różnymi przejawami - nazwijmy to eufemistycznie - niepożądanych zachowań. A to mamy jakieś pytanie, na które odpowiedzią jest pierwszy rezultat, jaki wyszukiwarka wyrzuca w reakcji na prostą kwerendę. Innym razem może to być klasyczne "No i co tu jest źle?!", opatrzone wysokim na kilka ekranów kawałkiem kodu, dla którego właściwym miejscem jest /dev/null. Kiedy indziej będzie to pojawiający się po raz 2⁵¹². problem w rodzaju unresolved external... I tak dalej, i tak dalej. Ot, zwyczajne przypadki, gdy napisanie posta poprzedza (lub zastępuje) myślenie.

Stuprocentowo uzasadnione.

Może nie jestem w stanie tego zrozumieć, ale przynajmniej potrafię się z tym pogodzić - po części pewnie dlatego, że sprzątanie po tego rodzaju twórczości nie jest specjalnie kłopotliwe. Jest jednak przynajmniej jedna rzecz, która skłania mnie do poważnych rozważań na temat intelektualnej kondycji rodzaju ludzkiego - a przynajmniej tej jego części, która się na forum pojawia - połączonych z co najmniej jednokrotnym wykonaniem znanego i lubianego gestu kapitana Picarda.

O co chodzi?... O dołączanie nowych pytań do istniejących wątków, z uzasadnieniem, że czyni się tak po to, aby nie zaśmiecać forum nowymi tematami. Czy jest to dobra praktyka? Czy ma to jakikolwiek sens? I wreszcie, czy skutkiem jej stosowania jest faktycznie większy porządek forum?
Otóż nie - i to po trzykroć nie. Paradoks tu występujący polega właśnie na tym, że - dokładnie przeciwnie do intencji osób tak postępujących - podczepianie się pod istniejące tematy skutkuje tylko i wyłącznie jeszcze większym bałaganem! Dzieje się tak co najmniej z kilku powodów:

Wprowadzanie nowego pytania w istniejący wątek odcina możliwość dodania czegokolwiek do oryginalnego tematu dyskusji. Jeśli ktoś mimo wszystko będzie próbował to robić, najprawdopodobniejszym rezultatem jest przeplatanka odpowiedzi na stare i nowe pytanie. Czytanie czegoś takiego to czysta przyjemność, nieprawdaż? 8-)
Jeśli jeden wątek zawiera więcej niż jeden temat/dyskusję/pytanie, to jego tytuł staje się mylący. Po niedługim czasie podczepione posty mogą być już zupełnie niezwiązane z tym, o czym wątek był oryginalnie. Istny synonim porządku, co nie? :)
Podczepione pytanie jest o wiele trudniejsze do znalezienia przez forumową wyszukiwarkę - jeśli to w ogóle jest możliwe. Co więcej, utrudnia ono też wyszukanie wszystkich informacji z oryginalnej dyskusji - choćby dlatego, że trzeba wpierw ustalić, gdzie się ona kończy...
Przywrócenie radośnie zepsutego wątku do stanu używalności jest pracochłonne: wymaga zlokalizowania wszystkich postów odnoszących się do nowego pytania (które mogą się przeplatać z tymi od pierwotnego), wydzielenia ich do nowego wątku i nadania mu sensownego tytułu. To wszystko da się zresztą zrobić tylko przy założeniu, że nie istnieją już posty, które odwołują się do obu pytań naraz. Jeszcze bardziej daleko idące jest przypuszczenie, że istnieje jakikolwiek moderator, któremu chciałoby się takich podziałów dokonywać :)

Widać zatem wyraźnie, że skutek doczepiania się do istniejących wątków jest dokładnie odwrotny do zamierzonego. Nie ma to najmniejszego sensu i jest wybitnie niepożądane. Wciąż jednak nie mogę się nadziwić, jakaż to dziwna logika podsuwa ludziom pomysły, że może być inaczej...

Tagi: forum Warsztatu
Autor: Xion w Internet, Przemyślenia » Komentarze (3)

Domyślna inicjalizacja zmiennych

2010-03-17 1:57

Używanie zmiennych bez uprzedniego nadania im wartości to stosunkowo częsty błąd. Wiele języków kompilowanych będzie z tego powodu stroiło fochy wahające się od ostrzeżeń podczas kompilacji przez błędy tejże aż po wyjątki w czasie wykonania programu (przynajmniej w wersji debugowej). To zresztą bardzo dobrze, gdyż alternatywą jest korzystanie ze zmiennej, której zawartością są jakieś losowe śmieci w pamięci.

Tak więc zmienne trzeba inicjalizować i w niemal każdym języku da się to zrobić mniej więcej tak:

int x = 5;

W C++ oczywiście też. Jednak w C++ mamy też feature, który nazywa się inicjalizacją domyślną. Opiera się on założeniu, że dany typ (tj. obiekt tego typu) może się sam zainicjalizować bez żadnych dodatkowych informacji - czyli że np. ma rozsądną wartość domyślną albo bezparametrowy konstruktor. Stąd T() będzie "domyślnym obiektem typu T", który możemy łatwo uzyskać, nie mając w ogóle pojęcia, czym ów typ T w istocie jest (codzienność szablonów, swoją drogą).
Inicjalizacja zmiennej tego typu domyślną wartością będzie więc wyglądała mniej więcej tak:

T foo = T();

Co bardziej spostrzegawczy zauważą jednak, że mamy tutaj dwie operacje: konstrukcję obiektu i kopiowanie go. Nie radzę jednak próby "optymalizacji" w postaci zamiany na deklarację T foo(); - można się nielicho zaskoczyć. Najlepiej pozostawić to zadanie kompilatorowi; przynajmniej w teorii powinien on sobie z nim bez problemu poradzić.

W powyższy sposób możemy domyślnie inicjalizować dowolne typy zmiennych. Dla pewnej ich podgrupy - zwanej agregatami - możemy jednak zastosować inne rozwiązanie. Cóż to jednak są te agregaty? Otóż są to typy złożone (tablice, struktury, itp.), które nie posiadają zdefiniowanych przez programistę konstruktorów. Mimo że instrukcja T() działa zupełnie dobrze również dla nich, dopuszczalne jest stosowanie nieco innej formy inicjalizacji.
Formą ta jest lista inicjalizacyjna. Można ją niekiedy spotkać w kodzie korzystającym z jakiegoś API, które operuje na dużych strukturach:

WNDCLASSEX wc = { sizeof(WNDCLASSEX) }; // {...} to inicjalizator
wc.lpszClassName = TEXT("MyVeryOwnAndCuteWindow");
wc.hInstance = hInstance;
// itd.

Chodzi tu po prostu o podanie wartości dla kolejnych elementów agregatu, czyli pól w strukturze/klasie lub komórek tablicy; całą tę listę zamykamy w nawiasy klamrowe. Nie musi ona być przy tym pełna: jeśli jakieś pozycje zostaną pominięte, to odpowiadające im pola/komórki zostaną automatycznie zainicjalizowane w sposób domyślny. W przykładzie powyżej inicjalizujemy więc strukturę tak, że pierwsze pole zawiera jej rozmiar, a reszta domyślne wartości (czyli pewnie zera).
Dane dla pierwszego pola zostały wprawdzie tutaj podane jawnie, jednak w ogólności nie jest to wymogiem. Na liście inicjalizacyjnej możemy równie dobrze opuścić wszystkie pozycje i to właśnie jest ten drugi, uniwersalny sposób inicjalizacji agregatu. Wygląda on więc po prostu tak:

D3DVECTOR v = {};

Jakkolwiek nietypowo (jak na kod C++) linijka ta wygląda, jest ona najzupełniej poprawna. W wyniku jej wykonania nowo zadeklarowany wektor v będzie miał wszystkie współrzędne wyzerowane.

Tagi: agregaty, C/C++, inicjalizacja
Autor: Xion w Programowanie » Komentarze (10)

mi pu facki fi la lojban.

2010-03-11 15:40

Przeglądanie Wikipedii może mieć jeden ciekawy efekt uboczny. Otóż wystarczy kliknąć jeden lub dwa linki "w złym kierunku" i już lądujemy w obszarze wiedzy znajdującym się kilometry od tego, z którego zaczynaliśmy. To ma swoje wady (bardzo, bardzo łatwo jest stracić mnóstwo czasu na niezupełnie pożyteczne lektury - co obrazowo pokazuje jeden z komiksów na xkcd), ale ma i jedną podstawową zaletę: można przy okazji odkryć coś ciekawego.

Znalezisko, na jakie natrafiłem ostatnio, to dość nietypowy język. I bynajmniej nie mam tu wcale na myśli języka programowania; chodzi tu jak najbardziej o język naturalny (chociaż pewnie niektórym to określenie będzie się wydawało nadużyciem...).
Delikwent nazywa się lojban (wym. lożban) i należy do klasy tzw. języków logicznych. Zanim wyjaśnię, co w nim jest takiego nietypowego, wspomnę o tym, czego w nim nie ma. Liczby pojedynczej i mnogiej, odmiany wyrazów, czasów, podziału na rodzaje gramatyczne, jak również interpunkcji i ortografii, a nawet... tradycyjnych części mowy (czasowniki, przymiotniki, itp.) - tego wszystkiego w nim nie ma i nie jest to brak specjalnie zauważalny. Wręcz przeciwnie: lojban ma - przynajmniej częściowo dzięki temu - niezaprzeczalne zalety:

jest jednoznaczny pod względem gramatyki, tzn. zawsze można dokładnie powiedzieć, co dana wypowiedź znaczy
jest jednoznaczny pod względem sposobu zapisu słów (czyli ortografii), który jest fonetyczny (zgodny z wymową)
jest regularny - od jego zasad nie ma żadnych wyjątków

Wszystko to brzmi całkiem obiecująco. Teraz jednak nasuwa się pewnie pytanie: skoro w tym języku tylu rzeczy nie ma, to co tak naprawdę w nim jest?...

Już spieszę z odpowiedzią. Odpowiedniki zdań w lojbanie (zwane bridi) wyrażają mianowicie pewne relacje między pojęciami. Związki te nazywamy selbri i mogą one odpowiadać zarówno czasownikom, jak i przymiotnikom czy nawet rzeczownikom (wtedy są to relacje 'bycia czymś') z "normalnych" języków. Z kolei argumenty dla tych relacji nazywają się sumti. Mówiąc o lojbanie używa się powszechnie tych, jak i kilku innych terminów.
W tym momencie jest doskonały czas na przykład - a jakim lepszym zdaniem przykładowym można się posłużyć niż tradycyjne "Ala ma kota."? Proszę bardzo, oto jego odpowiednik w lojbanie:

la .alas. ponse le mlatu

Kropka nie oznacza tu końca zdania, ale krótką przerwę w wypowiedzi na końcu nazwy własnej (którą jest bez wątpienia 'Ala'). Poprzedzające ją 's' jest wymogiem gramatyki: wszystkie nazwy (cmene, wym. szmene) w lojbanie muszą kończyć się spółgłoską. ponse, jak nietrudno się domyślić, oznacza "mieć", tj. relację posiadania czegoś przez coś/kogoś. A le mlatu to "coś, co zwiemy kotem". Czemu nie po prostu "kot"? Ano dlatego, że pod tym słowem może się kryć wiele różnych osobników, a nam chodzi o pewnego, ale konkretnego kota. To między innymi z takich konstrukcji - na początek niezbyt może intuicyjnych - bierze się jednoznaczność lojbanu.

Oczywiście ponse i mlatu to nie jedyne słowa, mogące służyć jako selbri. Są one tylko dwoma z około 1300 podstawowych wyrazów tego typu (nazywanych gismu), które mogą być łączone na wiele sposobów w celu otrzymywania bardziej złożonych znaczeń. Wspominany kot Ali może być na przykład biały i wtedy możemy go określić jako le blabi mlatu. Tak swoją drogą, jeśli ktoś się zastanawia, skąd właściwie wzięły się te wszystkie słowa, to spieszę z odpowiedzią, iż zostały one wygenerowane algorytmicznie z odpowiednich wyrazów w którychś z sześciu najpopularniejszych językach świata: chińskim, angielskim, hiszpańskim, hinduskim, arabskim i rosyjskim.
Ważną cechą lojbanu jest też to, że selbri mają w nim określoną strukturę związaną z położeniem argumentów. Innymi słowy, to nie przypadek, że w naszym bridi Ala jest pierwsza, a kot drugi; gdyby było odwrotnie, to kot miałby Alę. selbri mogą mieć jednak zarówno mniej, jak i więcej argumentów niż dwa. Chcąc na przykład wysłać naszą Alę na wycieczkę samochodem z Krakowa do Wrocławia, powiedzieliśmy coś w stylu:

la .alas. klama la vrotsuav. la krakuf. zo'e lo karce

gdzie lo karce (wym. lo karsze) jest samochodem. klama znaczy "iść/jechać" (jak angielskie go) i ma aż 5 sumti (argumentów), z których każdy ma ściśle określone znaczenie. Jeśli komuś w tej chwili skojarzyło się to z prototypem funkcji w języku programowania, to podpowiem, że skojarzenie jest jak najbardziej słuszne :) lojban ma nawet swojego nulla: zo'e (wym. zohe) oznacza opuszczenie danego sumti, w tym przypadku czwartego. Nie trzeba jednak z niego korzystać; zdanie powyżej da się również powiedzieć i bez "wypełniacza".

Naturalnie mógłbym kontynuować ten wywód jeszcze bardzo długo - i kto wie, może później to zrobię :) W tym miejscu jednak każdy powinien mieć już jako-takie pojęcie o tym, jak wygląda język lojban - i przy okazji znać już sporą część jego gramatyki. Zachęcam aczkolwiek do przejrzenia poniższych źródeł:

Oficjalna strona języka lojban

albo przynajmniej zerknięcia na wspomniany na początku artykuł na Wikipedii. Jeśli zaś komuś przez cały czas na końcu języka gnieździ się pytanie "A po co mi to?", to jako odpowiedź rzucę... oczywiście kolejny komiks z xkcd :) co'o

...co oczywiście znaczy "do widzenia". A tytuł notki? "Odkryłem lojban", rzecz jasna :)

Tagi: języki, lojban
Autor: Xion w Kultura » Komentarze (3)

Strona 8 z 64
« Poprzednia
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
...
64
Następna »

Produkcje

Ostatnie notki

Wyszukiwarka

Tagi

błędy C# C/C++ debugowanie DirectX forum Warsztatu funkcje GUI IGK języki Java klasy kontenery Linux operatory PowerShell programowanie gier programowanie grafiki projektowanie shadery STL Visual Studio Warsztat Windows World of Warcraft

Kategorie

Archiwum