Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2007.12.16;
Скачать: [xml.tar.bz2];

Вниз

delphi = pascal = языки для начинающих   Найти похожие ветки 

 
Piter ©   (2007-11-15 15:04) [280]

Юрий Зотов ©   (15.11.07 15:00) [279]
Чи-го? Программа завершилась, ресурс остался открытым - и это не чушь?


программа завершилась, а библиотека так и не была выгружена из памяти, впрочем как и образ EXE. Это же вы чушью не считаете почему-то?

Программа завершилась, а ресурс остался открытым?


 
Юрий Зотов ©   (2007-11-15 15:12) [281]

> Piter ©   (15.11.07 15:04) [280]

Миш, в третий раз тебе уже говорю - сначала разберись, что такое ресурс, потом будешь спорить (если после этого не расхочется). Только что ты смешал в одну кучу логическое и физическое освобождение ресурса.


 
reonid ©   (2007-11-15 15:18) [282]

DiamondShark ©   (15.11.07 13:57) [276]

> Не класс, а программист.

> У тебя есть контракт класса, в котором сказано: уходя гасите всех.
> В чём проблема?

Проблема в том, что у каждого класса, никаких ресурсов не использующих,
может быть потомок, которому нужны для внутреннего
функционирования какие-нибудь нетривиальные ресурсы.
Совершенно у любого.

И что тогда? Или писать в документации класса
"Потомкам класса запрещается выделение
любых ресурсов, кроме памяти, потому что
для них в контракте не предусмотрены методы освобождения".
Так, что ли?


 
Плохиш ©   (2007-11-15 15:23) [283]

прикольная ветка :-))
даже прикольней веток "Windows vs. Lunix" :-)))
пустой бесконечный цикл...


 
Romkin ©   (2007-11-15 15:25) [284]


> прикольная ветка :-)) даже прикольней веток "Windows vs.
>  Lunix" :-)))пустой бесконечный цикл...

:(


 
Юрий Зотов ©   (2007-11-15 15:33) [285]

> reonid ©   (15.11.07 15:18) [282]

Лень, сейчас тебе ответят, что потомок должен опубликовать свой собственный контракт.

Притом каждый потомок публикует свой собственный контракт, потому что потомков этих сколько хошь, пишут их разные люди в разное время и один может ничего не знать о другом. И у одного потомка этот контракт будет называться Close, у другого - Cleanup, у третьего - Dispose, у четвертого - Free, у пятого - FinalizeAll, а у шестого вообще по-китайски. А ты, юзер всей этой кучи потомков, должен сидеть и изучать их контракты.

И это вместо того, чтобы ввести ОДИН контракт в самый базовый класс (уж не говоря о том, что было бы неплохо еще и обеспечить его автоматический вызов).


 
имя   (2007-11-15 15:49) [286]

Удалено модератором


 
Игорь Шевченко ©   (2007-11-15 16:21) [287]

Юрий Зотов ©   (15.11.07 15:33) [285]
reonid ©   (15.11.07 15:18) [282]

Эта...я не понимаю. Есть у меня хороший базовый класс с некой функциональностью. Сдуру или спьяну кому-то пришло в голову сделать потомка, который начал требовать о базового же класса дополнительной функциональности.

И нафига такое надо ?


 
@!!ex ©   (2007-11-15 16:22) [288]

> [283] Плохиш ©   (15.11.07 15:23)

С появлением поста [282] все должно стать интереснее.
Ибо отмазаться как отмазывались раньше, уже не получиться..


 
Romkin ©   (2007-11-15 16:29) [289]


> С появлением поста [282] все должно стать интереснее.Ибо
> отмазаться как отмазывались раньше, уже не получиться..

Да щаз! см [209] и ниже.


 
Юрий Зотов ©   (2007-11-15 16:32) [290]

> Игорь Шевченко ©   (15.11.07 16:21) [287]

> Есть у меня хороший базовый класс

Хороший базовый класс думает о своих потомках загодя. Иначе он не хороший, а очень даже плохой.

Пример хорошего базового класса - TObject. Он вводит пустой виртуальный деструктор, который лично ему на фиг не нужен - но тем самым он дает потомкам возможность освобождать любые ресурсы перед своим уничтожением. А юзеру (т.е., программеру) тем самым дается возможность не заботиться об освобождении чужих ресурсов, т. к. все происходит автоматически.


 
Romkin ©   (2007-11-15 16:46) [291]

Игорь Шевченко ©   (15.11.07 16:21) [287] Игорь, ну посмотри сам, на TStream: внутре у него хендла нет. У его потомка TFileStream он уже есть. При этом в работе с ним не меняется ничего.
А тут предлагают, что у аналога TFileStream в java должен появиться метод Close, или Dispose или еще какой, чтобы закрывать поюзанный ресурс. Когда им указывают, что это как-бы не очень, ответ - введи Close в аналог TStream. Шоб було.
И все, кто его юзает, должны знать, что надо вызывать метод Close, когда работа закончена.


 
Игорь Шевченко ©   (2007-11-15 16:49) [292]

Юрий Зотов ©   (15.11.07 16:32) [290]


> Пример хорошего базового класса - TObject. Он вводит пустой
> виртуальный деструктор, который лично ему на фиг не нужен
> - но тем самым он дает потомкам возможность освобождать
> любые ресурсы перед своим уничтожением. А юзеру (т.е., программеру)
> тем самым дается возможность не заботиться об освобождении
> чужих ресурсов, т. к. все происходит автоматически.


И чего мне с этого виртуального деструктора ? А почему он не заботится о предсказании погоды ?


> Хороший базовый класс думает о своих потомках загодя. Иначе
> он не хороший, а очень даже плохой.


Ага. Думает. В рамках заявленной функциональности.

TObject это вообще костыль. Вон KOL написан без TObject - ничего, справляются люди.


 
Игорь Шевченко ©   (2007-11-15 16:53) [293]

Romkin ©   (15.11.07 16:46) [291]

Давайте отвлечемся от деструкторов, в конце концов на них свет клином не сошелся.

Насколько я понял из флейма в ветке, речь о том, что исходя из возможных средств, предоставляемых различными языками, думать при написании на них, следует все-таки по-разному. Вот тут я целиком и полностью согласен.


 
Юрий Зотов ©   (2007-11-15 16:57) [294]

> Игорь Шевченко ©   (15.11.07 16:49) [292]

Игорь, пожалуйста, выдели в посте [292] те свои слова, которые по сути и доказательно. А не о предсказании погоды или декларативно.

Иначе я не смогу ответить. Потому что  не нашел, на что.


 
Игорь Шевченко ©   (2007-11-15 17:00) [295]

Юрий Зотов ©   (15.11.07 16:57) [294]


> Игорь, пожалуйста, выдели в посте [292] те свои слова, которые
> по сути и доказательно. А не о предсказании погоды или декларативно.
>
>
> Иначе я не смогу ответить. Потому что  не нашел, на что.
>


Вопрос, собственно, был задан в [287]. И еще раз - давайте отвлечемся от деструкторов, на них свет клином не сошелся.


 
Черный Шаман   (2007-11-15 17:02) [296]


> Юрий Зотов ©   (15.11.07 16:57) [294]
>
> > Игорь Шевченко ©   (15.11.07 16:49) [292]
>
> Игорь, пожалуйста, выдели в посте [292] те свои слова, которые
> по сути и доказательно. А не о предсказании погоды или декларативно.
>
>
> Иначе я не смогу ответить. Потому что  не нашел, на что.


Извините, но тот же SQL вы не ругаете, что он не поддерживает текущее состояние глобальных переменных при выполнении запроса, а обычный ограниченный функциональный язык.


 
@!!ex ©   (2007-11-15 17:10) [297]

> И еще раз - давайте отвлечемся от деструкторов, на них свет
> клином не сошелся.

ну собственно весь спор именно о деструкторах...


 
Eraser ©   (2007-11-15 17:11) [298]


> DiamondShark ©   (15.11.07 12:19) [256]


> Да-а?! Ну, пусть так. Тогда и для ручного вызова деструктора
> в дельфях и плюсах "существуют практически те же проблемы",
>  потому что классический деструктор и метод close ничем
> не отличаются.

отличаются. тем, что destroy есть гарантированно у всех объектов.

вообще это серьезный недостаток системы с GC. По-сути задекларировано, что объекты освобождать не надо, их автоматически освободит сборщик муссора, только гарантии на это никто не дает ) странно как-то.
ну и пес бы с ним, если бы они предусмотрели возможность удалить объект явно, через тот-же сборщик муссора, думаю это не сложно реализовать было бы.. но они так не сделали. данная ситуация нивилирует многие прелести концепции GC.


 
Romkin ©   (2007-11-15 17:15) [299]


> ну собственно весь спор именно о деструкторах...

Вот уж они тут совершенно не при чем. И речи о них давно уж нет.
Да, в Delphi деструктор обычно выполняет роль финализатора.
Но речь-то о том, что в java у объекта нет метода финализации. Точнее, он есть, но... см выше.


 
@!!ex ©   (2007-11-15 17:16) [300]

Удалено модератором


 
clickmaker ©   (2007-11-15 17:17) [301]


> Еще чуть-чуть и LInux vs Windows будет повержен

может, вернемся к той теме? :)


 
Romkin ©   (2007-11-15 17:17) [302]


> ну и пес бы с ним, если бы они предусмотрели возможность
> удалить объект явно, через тот-же сборщик муссора, думаю
> это не сложно реализовать было бы.. но они так не сделали.
>  данная ситуация нивилирует многие прелести концепции GC.
>

Да хотя бы не удалить, пес с ним, пусть этим GC занимается. Нужна возможность финализировать объект. Однообразная. Либо явно, либо автоматом, сразу, как только нужда в данном объекте отпала.


 
Игорь Шевченко ©   (2007-11-15 17:19) [303]

Eraser ©   (15.11.07 17:11) [298]


> вообще это серьезный недостаток системы с GC. По-сути задекларировано,
>  что объекты освобождать не надо, их автоматически освободит
> сборщик муссора, только гарантии на это никто не дает )
> странно как-то.


А что странного ? Сборщик мусора не выполняет свою работу, да ?


 
Azize ©   (2007-11-15 17:21) [304]


> Мля... уже 300 сообщений....
> Еще чуть-чуть и LInux vs Windows будет повержен...
>

Тут война миров происходит. революция можно сказать


 
Piter ©   (2007-11-15 17:21) [305]

Юрий Зотов ©   (15.11.07 15:12) [281]
Миш, в третий раз тебе уже говорю - сначала разберись, что такое ресурс, потом будешь спорить


Юрий, давайте вы будете говорить в чем я неправ вместо того, чтобы говорить, что мне не надо писать?
Или в другом случае просто не отвечать на мои посты.

Юрий Зотов ©   (15.11.07 15:12) [281]
Только что ты смешал в одну кучу логическое и физическое освобождение ресурса.


ничего я не смешивал. Да, логически вы считаете что библиотека выгружена, но физически то это не так, не правда ли? И кстати нет никакой функции физически выгрузить ее.

Ну и с java тоже самое - считайте, что логически ресурса больше нет, вот и все. Да, да, так и считайте.

Просто вы знаете, что он есть, вас это и тревожит. Но вы также знаете, что библиотека тоже осталась в памяти, хоть вы и вызвали FreeLibrary. Но если в случае с Windows вы это считаете скрытым механизмом реализации, кеширование и что вам угодно - и не паритесь, то с java вы решили попариться.

Это пережитки логики так сказать native-языков. Как раз проблема с утечками ресурсов в грамотных специалистов забила раскаленными гвоздями рефлекс, если создал - уничтожь, выделил - освободи, на каждый New должен быть свой Dispose, на каждыый GetMem - свой FreeMem. Это настолько вдолблено в голову, что мозг противится тому, что может быть иначе. Столько ошибок и ожогов было на этом поприще - что работа по иному не представляется возможным.

Но Java - язык с другой идеологией, религией если хотите. Возникают серьезные дебаты на тему, а кто лучше - Иисус или Будда? И приводятся куча аргументов, анализ деятельности и прочее... Но как можно сравнивать несравнимое? Вот я предлагаю и также относится к этой проблеме.

не нравится вам такой подход - на здоровье, каждый выбирает что нравится. Но имеет ли такой подход право на жизнь? Имеет несомненно. И даже более того, он скорее всего будет развиваться и станет доминирующим подходом. И возможно через 10 лет с вами уже будут спорить - "а зачем нужен деструктор? А зачем нужно освобождать память, ресурсы, что это за бред вы придумали?"

В чем я с вами согласен, дядь Юра, так это в том, что нефиг вообще было включать в Java такое понятие как finalize, если оно имеет такой глючный механизм исполнения. Может выполнится, а может и нет, это считай говорит о том, что никакого кода туда лучше вообще не писать, а тогда и само понятие нафиг не нужно.


 
clickmaker ©   (2007-11-15 17:23) [306]


> Либо явно, либо автоматом, сразу, как только нужда в данном
> объекте отпала

Жадные до ресурсов (которых дефицит обычно) объекты имеют Dispose(). Например, Brush/ Pen и т.п. нужно явно освобождать. А то легко можно схлопотать Out of memory, хотя ее, казалось бы завались.
А за остальными мусорщик придет. Вопрос времени только )


 
@!!ex ©   (2007-11-15 17:23) [307]

> [305] Piter ©   (15.11.07 17:21)

Ответьте на [282]?


 
Romkin ©   (2007-11-15 17:25) [308]

Piter ©   (15.11.07 17:21) [305] Хм. Тогда зачем в java сборщик мусора?


 
Eraser ©   (2007-11-15 17:26) [309]


> Игорь Шевченко ©   (15.11.07 17:19) [303]

вполне выполняет, но меняется весь смысл деструктора..
по-сути разработчики должны были предусмотреть какой-нибудь виртуальный finalize в джавовском TObject, как правильно заметил Romkin ©   (15.11.07 17:17) [302]. Чтобы с ресурсами можно было работать по аналогии с классическим подходом.
а так GC конечно хорошо, но могло бы быть и лучше... в идеале деструктор должен вызываться сразу после того, как пишем
obj_instance = null;и т.п.


 
Юрий Зотов ©   (2007-11-15 17:26) [310]

> Игорь Шевченко ©   (15.11.07 17:00) [295]

А ответ был дан в [290]. И от деструкторов можно отвлечься, и без них примеров достаточно. Скажем, это все методы диспетчеризации событий - да и вообще, по сути, все виртуальные (динамические) методы. Разработчик некоего класса ведь не просто так объявил их виртуальными - тем самым он дал возможность разработчикам возможных потомков модифицировать их поведение.

Игорь, ты смотришь на класс, как его юзер, как прикладник. И с этой точки зрения тебе по барабану, позаботился этот класс о своих потомках, или нет. Но как только ты начнешь писать этих самых потомка, так тебе это тут же станет вовсе не безразлично.

> Черный Шаман   (15.11.07 17:02) [296]

Про SQL - это замечательный аргумент. Еще можно о Фортране вспомнить. Правда, ни в том, ни в другом никаким ООП даже и не пахнет, но ведь это же неважно, да?


 
Romkin ©   (2007-11-15 17:33) [311]


> Eraser ©   (15.11.07 17:26) [309]
> по-сути разработчики
> должны были предусмотреть какой-нибудь виртуальный finalize
> в джавовском TObject, как правильно заметил Romkin ©   (15.
> 11.07 17:17) [302]. Чтобы с ресурсами можно было работать
> по аналогии с классическим подходом.а так GC конечно хорошо,
>  но могло бы быть и лучше... в идеале деструктор должен
> вызываться сразу после того, как пишем obj_instance = null;
> и т.п.

Нет, в духе java, думаю, подошло бы решение из Romkin ©   (15.11.07 10:34) [234], когда о финализации просят позаботится окружение, виртуальная машина же есть?


 
Юрий Зотов ©   (2007-11-15 17:38) [312]

> Piter ©   (15.11.07 17:21) [305]

Миша, как ты наверняка знаешь, я человек крайне вежливый, поэтому не могу не отвечать на посты, прямо мне адресованные. Поэтому, если ты хочешь, чтобы я на них не отвечал, то ты их просто не пиши, ладно?

А уж если пишешь, то хотя бы разберись сначала, почему бывают такие программы, что если ее запустить сто раз (каждый раз завершая), то на сто первый окажется, что ресурсы системы кончились. А еще разберись с тем, почему после срубания программы, юзающей Paradox"овскую БД, коннект к этой БД окажется  невозможным. А еще разберись с тем, почему бывает невозможно удалить файл, хотя программа, которая его юзала, уже завершилась.

Короче, разберись с тем, что такое освобождение ресурсов. Или не спорь.


 
Reindeer Moss Eater ©   (2007-11-15 17:38) [313]

С философской точки зрения все просто.
Если ресурсы в ява приладе остались неосвобожденными, то надо привлечь к ответственности ИИ (сборщик мусора), а программист не виноват.
:)


 
Piter ©   (2007-11-15 17:39) [314]

@!!ex ©   (15.11.07 17:23) [307]
Ответьте на [282]?


а что там отвечать? Это логика программиста на native-языке, привыкшего работать напрямую с памятью, с байтами, битами

reonid ©   (15.11.07 15:18) [282]
Проблема в том, что у каждого класса, никаких ресурсов не использующих,
может быть потомок, которому нужны для внутреннего
функционирования какие-нибудь нетривиальные ресурсы


не должно быть у класса никаких нетривиальных ресурсов, которые не сможет убрать сборщик мусора.
Я продолжу это логику, попытаюсь провести параллель. С тем же успехом можно заявить:

"У каждого класса может быть потомок, который захочет напрямую взаимодействовать с видео-картой. Совершщенно у любого.

И что тогда? Или писать в документации класса
"Потомкам класса запрещается напрямую работать с видео-картой?".


И это чистая правда. Да, может быть такой потомок и будет, но мы почему-то привыкли к стандартным ограничениям windows, мы приемлем прослойку в виде драйвера и более того набора специальных функций DirectX для работы с графикой. Но почему-то ограничения языка с автоматической сборкой мусора мы не приемлем и прослойку в виде java-машины отторгаем. А почему? А потому что не привыкли.

Я уверен, что с появлением Windows тысячи программистов занимающихся разработками игр плевались, когда им захотели запретить напрямую работать с видеокартами. А сейчас ничего, без существующей иерархии и представить что-то сложно работающее в 3D.


 
Piter ©   (2007-11-15 17:42) [315]

Romkin ©   (15.11.07 17:25) [308]
Piter ©   (15.11.07 17:21) [305] Хм. Тогда зачем в java сборщик мусора?


на такой незатейливый вопрос у меня есть только один незатейливый ответ:

"чтобы собирать мусор" ;)


 
Romkin ©   (2007-11-15 17:44) [316]

Piter ©   (15.11.07 17:39) [314]

> не должно быть у класса никаких нетривиальных ресурсов,
> которые не сможет убрать сборщик мусора.


О как!
Юра, помнишь, ты код с Stream приводил? Так вот: метод close ты вызывать не должен был! Нет у этого класса никаких ресурсов, которые не уберет сборщик мусора!


 
Юрий Зотов ©   (2007-11-15 17:45) [317]

> Piter ©   (15.11.07 17:39) [314]

> не должно быть у класса никаких нетривиальных ресурсов, которые не
> сможет убрать сборщик мусора.

Миша, ну я тебя умоляю - помолчи. Пойми - сейчас над тобой уже просто смеяться начнут. Ты даже не представляещь, сколько откровенной чуши ты уже тут наморозил...


 
DiamondShark ©   (2007-11-15 17:48) [318]


> reonid ©   (15.11.07 15:18) [282]
>
> Проблема в том, что у каждого класса, никаких ресурсов не
> использующих,
> может быть потомок, которому нужны для внутреннего
> функционирования какие-нибудь нетривиальные ресурсы.
> Совершенно у любого.


Во-первых, это неверно. Есть куча базовых классов, у которых использование нетривиальных ресурсов может присниться только в страшном сне. Так что не у любого, а у некоторых. Так точнее.

Во-вторых, давайте будем разбираться, что это могут быть за ресурсы, и откуда они возьмутся.

Обычно у ресурсов есть некое внешнее имя (путь для файла, сетевой адрес для сокета, строка подключения для бдконнекта, ID устройства для аудиомикшера и т.п.), это естественно, т.к. для того, чтобы захватить ресурс его надо сначала как-то идентифицировать.
Являются ли имена ресурсов жестко зашитыми в коде класса? Если да, то это плохой класс: тупой, непереносимый, накладывающий неоправданные ограничения на окружение. Вообще, я слабо представляю себе полезность класса, работающего с файлом с жестко заданным именем, или с жестко заданным сетевым адресом и т.п.
Значит, классу должны быть переданы имена (идентификаторы) ресурсов. Стоп. А зачем передавать имена? Гораздо лучше передать объект-обёртку для какого-то ресурса. Причём, объект самого абстрактного типа, насколько возможно, например, абстрактный стрим вместо файла. Это увеличит гибкость класса, расширит область его возможного применения. Посмотрите на имеющиеся библиотеки: именно так очень часто и делают.
Таким образом, владеть нужными ресурсами объекту вовсе даже не обязательно, можно только ссылаться.

Конечно, может объекту понадобятся какие-то ресурсы для временного использования. Такие надо использовать по принципу открыл-поюзал-закрыл в месте непосредственной надобности.

В общем, в подавляющем большинстве я не вижу случаев, не укладывающихся в две вышеозначенные стратегии.

Конечно, один раз на тысячу может попасться какой-либо совсем нетривиальный случай. По-человечески я сочувствую столкнувшемуся с ним разработчику, но это не повод считать упавшие боинги.


 
Игорь Шевченко ©   (2007-11-15 17:51) [319]

Юрий Зотов ©   (15.11.07 17:26) [310]


>  Разработчик некоего класса ведь не просто так объявил их
> виртуальными - тем самым он дал возможность разработчикам
> возможных потомков модифицировать их поведение


А если не объявил ?


> Игорь, ты смотришь на класс, как его юзер, как прикладник.
>  И с этой точки зрения тебе по барабану, позаботился этот
> класс о своих потомках, или нет. Но как только ты начнешь
> писать этих самых потомка, так тебе это тут же станет вовсе
> не безразлично.


Вот! В свое время, в момент выхода первых версий Delphi народ очень возмущался - а чего это в VCL слишком много полей объявлено, как private - когда надо почесать левой ногой правое ухо, совсем не получается такое чесание. Даже мода была писать свои классы, объявляя чуть ли все содержимое минимум protected, ну а методы, натурально, виртуальными - а вдруг кому-то понадобится доступ, а вот и он, как на ладони.

А потом, знаешь ли, привыкли чесать уши так, как дядя Фрэнк Борланд разрешает чесать, потому как дело делать надо и желательно без дополнительных путей для ошибок. И в своих классах стали разграничивать уровень доступа и то, что не должно быть виртуальным, не стали делать виртуальным.

А что до деструкторов - то, насколько мне известно, программисты  каждой строке в Delphi в конце работы с ней не присваивают пустое значение, освобождая ейную память. И в голову наверное им не приходит, потому как знают, что RTL вкупе с компилятором сама о строках позаботится.
Ну и со сброкой мусора тоже самое.


 
Romkin ©   (2007-11-15 17:51) [320]


>  А зачем передавать имена? Гораздо лучше передать объект-
> обёртку для какого-то ресурса. Причём, объект самого абстрактного
> типа, насколько возможно, например, абстрактный стрим вместо
> файла. Это увеличит гибкость класса, расширит область его
> возможного применения. Посмотрите на имеющиеся библиотеки:
>  именно так очень часто и делают.Таким образом, владеть
> нужными ресурсами объекту вовсе даже не обязательно, можно
> только ссылаться.

Продолжи мысль пожалуйста.
1. Где мне взять этот объект-обертку.
2. Ну ссылаюсь я на него, дальше что?



Страницы: 1 2 3 4 5 6 7 8 9 
10 11 вся ветка

Форум: "Прочее";
Текущий архив: 2007.12.16;
Скачать: [xml.tar.bz2];

Наверх




Память: 1.11 MB
Время: 0.106 c
2-1195735467
Ростик
2007-11-22 15:44
2007.12.16
Пример программы


2-1195515747
ht9
2007-11-20 02:42
2007.12.16
Форма bsnone


2-1195843770
Knob
2007-11-23 21:49
2007.12.16
Браузер и соединение с ним


15-1195461860
lehich
2007-11-19 11:44
2007.12.16
html и использование баз ACCESS


2-1195648487
kudatsky
2007-11-21 15:34
2007.12.16
Ограничение на количество открытых DBF-файлов





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский