Почему в Qt нет приложений для настольных компьютеров? [закрыто]

Насколько я знаю и понял в своем опыте работы с Qt, это очень хорошая и простая в освоении библиотека. Он имеет очень хорошо разработанный API и является кросс-платформенным, и это всего лишь две из многих функций, которые делают его привлекательным. Мне интересно узнать, почему больше программистов не используют Qt. Есть ли недостаток, который говорит против него? Какая функция делает другие библиотеки лучше, чем Qt? Проблема связана с лицензированием?

172 голоса | спросил Dehumanizer 1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

14 ответов


161

На самом деле я не намереваюсь ответить на этот вопрос, но это причины, по которым я лично не использую Qt. Есть много хороших вещей, чтобы сказать об этом - а именно, что API работает большую часть времени и что он плавно перестраивает платформы. Но я не использую Qt, потому что:

  1. В некоторых случаях это просто не похоже на то, как выглядят родные программы. Проектирование единого пользовательского интерфейса для всех платформ по своей сути не будет выглядеть правильно при переходе с машины на машину для различных визуальных стилей. Например, на машинах Mac разделительные бруски обычно относительно толстые, а кнопки маленькие и округлены значками. На машинах Windows разделенные полосы обычно узкие, а кнопки более текстовые, с более квадратными проектами. Просто потому, что вы можете написать один пользовательский интерфейс для каждой платформы, это не значит, что вы должны использовать большинство приложений.
  2. Qt не является библиотекой C ++. Для этого требуется отдельный этап компиляции, что значительно усложняет процесс сборки по сравнению с большинством других библиотек.
  3. В результате (2), C ++ IDE и инструменты могут указывать выражения Qt как ошибки, потому что они не понимают специфику Qt. Это почти заставляет использовать QtCreator или текстовый редактор, например vim .
  4. Qt - это большой источник, который должен присутствовать и предустановлен на любом компьютере, который вы используете перед компиляцией. Это может сделать настройку среды сборки намного более утомительной.
  5. Он доступен только под LGPL, что затрудняет использование однобиблиотечного развертывания, когда требуется освободить его по более ограничительной или менее ограничительной лицензии.
  6. Он создает чрезвычайно большие скомпилированные двоичные файлы по сравнению с аналогично написанными «обычными» автономными приложениями »(за исключением приложений, написанных для KDE).
ответил Ladislav Mrnka 30 +04002011-10-30T19:46:34+04:00312011bEurope/MoscowSun, 30 Oct 2011 19:46:34 +0400 2011, 19:46:34
94

Как говорят люди, каждый инструмент подходит для каждой проблемы и ситуации ...

Но если вы программист на C ++, Qt - ваша структура. Никакой соперник.

Мы разрабатываем комплексное коммерческое приложение для медицинской визуализации, и Qt имеет место.

Я не говорю, что «минусы», которые люди говорят об этом, ложны, но у меня такое ощущение, что они долго не пробовали Qt (его постоянно улучшается каждая новая версия ...) А также, главным образом, все проблемы, которые они комментируют, не являются проблемой, если вы берете на себя заботу.

Непоследовательность платформы UI:  только если вы используете виджеты пользовательского интерфейса «как есть», без настройки или пользовательского искусства.

Перегрузка препроцессора Qt:  Только если вы злоупотребляете механизмом сигнального слота или наложением QObject, когда нет необходимости.

Кстати, мы все еще пишем приложения на C # .NET и делаем это в течение длительного времени. Поэтому я думаю, что у меня есть перспектива.

Как я уже сказал, каждый инструмент для каждой ситуации,

, но Qt, без сомнения, является последовательной и полезной основой.

ответил Ladislav Mrnka 30 +04002011-10-30T19:46:34+04:00312011bEurope/MoscowSun, 30 Oct 2011 19:46:34 +0400 2011, 19:46:34
34

Из всего, что мне не нравится в Qt, тот факт, что он не играет хорошо с шаблонами, больше всего меня беспокоит. Вы не можете этого сделать:

  template <typename T>
struct templated_widget: QWidget
{
  Q_OBJECT;

общественные сигналы:
  void something_happened (T);
};
 

Он также не очень хорошо работает с препроцессором. Вы не можете этого сделать:

  #define CREATE_WIDGET (имя, тип) \
struct name ## _widget: QWidget \
{\
  Q_OBJECT; \
\
общедоступные сигналы: \
  void something_happened (тип); \
}
 

Это, в сочетании с тем, что все, что реагирует на сигнал, должно быть Q_OBJECT, делает Qt трудным для работы программиста на C ++. Люди, привыкшие к программированию на языке Java или Python, вероятно, действительно лучше.

Я потратил много времени и сил на изучение и разработку способа получения безопасности типа и подключение сигнала Qt к любому объекту-функтору: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals-in-qt-step-1. HTML

То, что я хочу сделать, - это базовая, повседневная разработка на C ++, сделанная почти невозможной с помощью Qt moc ... которая сама по себе совершенно не нужна сейчас дням, если она когда-либо была на самом деле.

Честно говоря, я застрял в этом, потому что, если вы хотите сделать автоматическое тестирование пользовательского интерфейса, Qt - это почти единственная игра в городе, не имеющая MFC ..., которая так 1980 года (это отстойно работать в этом дерьме очень сложно ). Некоторые могут сказать WX, но у него есть еще более серьезные проблемы. GTKmm был бы моим первым выбором, но поскольку он все привлечен к работе и не делает доступность ... не может управляться стандартным программным обеспечением для тестирования. Qt достаточно сложно в этом отношении ( едва работает, когда вы изменяете плагин доступности).

ответил Ladislav Mrnka 30 +04002011-10-30T19:46:34+04:00312011bEurope/MoscowSun, 30 Oct 2011 19:46:34 +0400 2011, 19:46:34
23

Одна из причин не использовать Qt заключается в том, что если вы пишете только одну архитектуру, такую ​​как Windows, вы можете использовать C # /. NET (или Cocoa на Mac), потому что они всегда смогут воспользоваться последними колокола и свистки ОС.

Если вы пишете кросс-платформенные приложения, то вы уже можете получить большую часть других технологий, таких как Java (т. е. вы работаете в «Java-магазине»). Ваш выбор технологии может быть продиктован экосистемой, в которой вы развиваетесь, например, языковыми API. В таких случаях минимизация количества технологий может быть выгодной.

Третья причина, по которой я могу думать, заключается в том, что Qt основан на C ++, а C ++ - довольно сложный /опасный язык для программирования. Я думаю, что это язык для профессионалов. Если вам нужна высокая производительность и вы можете быть дотошными, то C ++, вероятно, по-прежнему является лучшей игрой в городе. На самом деле, Qt улучшает многие проблемы управления памятью, если вы настроите все, чтобы выйти из сферы действия. Кроме того, Qt сама по себе делает хорошую работу, изолируя пользователя от множества неприятных проблем на C ++. У каждого языка и рамки есть свои плюсы и минусы. Это очень и очень сложная проблема, которая обычно может быть сведена путем добавления, часто встречающегося у посетителей: скорость, качество и цена (но вы можете выбрать только два).

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

  1. Qt действительно является файлом библиотеки C ++ /фреймворком /заголовком. Это дополняется макропроцессором (moc), который позволяет передавать сигналы и слоты между многими другими вещами. Он преобразует дополнительные макрокоманды (например, Q_OBJECT), чтобы классы имели интроспекцию и всевозможные другие свойства, которые вы могли бы представить как добавление функциональности Objective-C к C ++. Если вы достаточно осведомлены о C ++, чтобы обижаться на это отсутствие чистоты, то есть вы являетесь профессионалом, то 1) не используйте Q_OBJECT и его ilk или 2) быть благодарными за то, что он делает это, и программировать вокруг очень ограниченных угловых случаев где это создает проблему. Для людей, которые говорят: «Используйте Boost для сигналов и слотов!» то я бы ответил, что вы обмениваетесь одной «проблемой» на другую. Boost огромный, и у него есть свои часто упоминаемые проблемы, такие как плохая документация, ужасающий API и кросс-платформенные ужасы (думаю, старые компиляторы, такие как gcc 3.3 и большие компиляторы железа, такие как AIX).

  2. Для поддержки редактора это также следует из 1, я несколько согласен. На самом деле, Qt Creator является IMHO лучшим графическим редактором C ++, периодом, даже если вы не используете материал Qt. Многие профессиональные программисты используют emacs и vim. Кроме того, я думаю, что Eclipse обрабатывает дополнительный синтаксис. Таким образом, никаких проблем с макросами Qt (Q_OBJECT) или добавлением сигналов /слотов. Вы, вероятно, не найдете эти макросы в Visual Studio, потому что (я соглашаюсь) они являются дополнениями к C ++. Но по большому счету, люди C # /.NET не будут использовать Qt в любом случае из-за того, что у них есть много функций, охватываемых собственными собственными методами.

  3. Что касается размера источника Qt, если он компилируется на ночь, кому это нужно? Я собрал Qt 4 на своем двухъядерном Macbook в «меньше, чем за одну ночь». Я определенно надеюсь, что это не то, что заставляет ваше решение использовать или не использовать определенную технологию. Если это действительно проблема, вы можете загрузить предварительно скомпилированные SDK для Mac, Linux и Windows с веб-сайта Qt.

  4. Лицензирование доступно в трех вариантах: 1) Собственная лицензия в случае, если вы хотите изменить Qt ITSELF и не делиться, или скрыть тот факт, что один использует Qt и не желает давать атрибуция (может быть очень важна для брендинга и изображения!) 2) GPL и 3) LGPL. Да, есть проблемы со статическим связыванием (переключение всех Qt в двоичный файл), но я думаю, что это больше, потому что невозможно заглянуть внутрь и заметить, что вы используете Qt (атрибуция!). Я попытался купить лицензию у Digia, и они сказали мне: «За то, что вы делаете, вам это действительно не нужно». Вау. От бизнеса, который занимается продажей лицензий.

  5. Размер бинарного /пакета - это то, что вам нужно распространять материал Qt для людей, у которых его нет: Windows уже есть? Visual Studio, или вам нужно установить время выполнения. Mac уже поставляется с огромным какао и может быть динамически связан. Хотя я не занимаюсь большим тиражом, я никогда не сталкивался с проблемой распространения статического файла размером 50 мегабайт (что я могу сделать еще меньше с помощью некоторых двоичных утилит для стриптиза /сжатия, таких как UPX). Мне просто все равно, чтобы сделать это, но если пропускная способность когда-либо была проблемой, я бы добавил шаг UPX к моему сценарию сборки.

  6. Что определяет «Родной взгляд и чувство?» Я думаю, что «большинство» согласится с тем, что Mac ближе всего подходит для унифицированного внешнего вида. Но здесь я сижу, глядя на Safari, iTunes, Aperture, Final Cut Pro, Страницы и т. Д., И они выглядятничего подобного, несмотря на то, что они сделаны поставщиком ОС. Я думаю, что «ощущаемый» аспект более уместен: стилизация виджета, отзывчивость и т. Д. Если вы заботитесь о отзывчивости, то здесь есть веская причина использовать C ++, а не Java или какой-либо другой высокодинамичный язык. (Цель C также скалывается, но я пытаюсь развеять мифы о Qt)

Таким образом, это сложная проблема. Но я хотел бы отметить, что я думаю, что существует меньше причин «не использовать Qt», как можно было бы подумать, основываясь на мифах и информации за последние десять лет.

ответил Ladislav Mrnka 30 +04002011-10-30T19:46:34+04:00312011bEurope/MoscowSun, 30 Oct 2011 19:46:34 +0400 2011, 19:46:34
23

Некоторые из них лицензируются. См. https://en.wikipedia.org/wiki/Qt_(software)#Licensing для некоторой истории лицензирования. До 2000 года люди, которые сильно заботились о open source, не использовали Qt. Период. (Это была, по сути, оригинальная мотивация для разработки Gnome.) До 2005 года люди, которые хотели иметь возможность выпускать бесплатное программное обеспечение для Windows, не использовали Qt. Даже после этой даты люди, которые хотели бесплатное программное обеспечение под чем-то, кроме GPL, просто не имели возможности использовать Qt. Таким образом, любой проект бесплатного программного обеспечения, который старше этих дат, не может использовать Qt. И, конечно же, люди, которые пишут проприетарный код, должны были заплатить за эту привилегию.

Кроме того, это не так, как есть недостаток других вариантов. Например WxWidgets , GTK + и Tk - это кросс-платформенные инструментальные средства с открытым исходным кодом.

Кроме того, долгое время Windows была настолько доминирующей на рабочем столе, что многие программы были довольны только для Windows. Если вы устанавливаете инструментальную цепочку Microsoft, проще просто использовать проприетарные материалы Microsoft, чем беспокоиться о чем-либо еще, и многие программисты сделали именно это.

ответил Ladislav Mrnka 30 +04002011-10-30T19:46:34+04:00312011bEurope/MoscowSun, 30 Oct 2011 19:46:34 +0400 2011, 19:46:34
12

Я согласен с почти всеми причинами, о которых говорилось выше, однако многие люди заявили, что не будут использовать Qt из-за дополнительных накладных расходов, которые он несет с собой. Я не согласен с этим, потому что сегодня все наиболее распространенные языки (Java, C # и Python) несут в себе довольно накладные расходы.

Во-вторых, Qt делает программирование на C ++ настолько простым и понятным, что оно компенсирует дополнительные ресурсы, которые он использует. Я встретил довольно много консольных приложений, написанных на Qt, а не на стандартном C ++ из-за простоты, в которой они могут быть написаны.

Я бы сказал, что производительность Qt больше, чем производительность C /C ++, но меньше, чем языки, такие как Python.

ответил Ladislav Mrnka 30 +04002011-10-30T19:46:34+04:00312011bEurope/MoscowSun, 30 Oct 2011 19:46:34 +0400 2011, 19:46:34
7

Это действительно не попытка начать пламенную войну, я просто хотел рассмотреть некоторые из пунктов.

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

  

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

vs-addin для visual studio делает это автоматически, как делает собственную командную строку Qt. Компилятор ресурсов, используемый для создания диалогов для MFC, также является отдельным шагом, но это все еще c ++.

  

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

Существует бинарная загрузка для каждой версии визуальной студии, а сборка из источника - это одна команда. Я не вижу, что размер источника SDK - это большая часть сделки в эти дни. Visual Studio теперь устанавливает все библиотеки C ++, а не позволяет выбирать и выбирать, в результате размер установки компилятора равен> 1Gb.

  

Он доступен только под LGPL, что затрудняет использование   однобитальное развертывание, когда нужно выпускать более   ограничительная или менее ограничительная лицензия.

LGPL применяется только к lib, это не влияет на ваш код. Да, это означает, что вам нужно отправлять DLL, а не одну бинарную (если вы не платите), но в мире, где вам нужно загрузить среду выполнения Java или обновление .Net для крошечного использования, это не так уж и важно. Это также меньше проблем на платформах с одним ABI, так что другие приложения Qt могут совместно использовать библиотеки.

  

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

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

ответил Ladislav Mrnka 30 +04002011-10-30T19:46:34+04:00312011bEurope/MoscowSun, 30 Oct 2011 19:46:34 +0400 2011, 19:46:34
6

Причина проста: у нее нет хороших привязок ко всем основным языкам, и это не магически always подходит для работы.

Используйте правильный инструмент для задания. Если я пишу простую прикладную программу из командной строки, зачем мне раздувать ее с помощью Qt только ради этого?

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

ответил Ladislav Mrnka 30 +04002011-10-30T19:46:34+04:00312011bEurope/MoscowSun, 30 Oct 2011 19:46:34 +0400 2011, 19:46:34
4

Я согласен с тем, что Qt - хорошая структура для работы. Тем не менее, есть ряд проблем, которые у меня есть:

  1. Он написан на C ++, который является языком на самом низком уровне. Только тот факт, что это C ++, сделает каждый Qt-программист значительно менее продуктивным по сравнению с Framework, написанными на других языках. Моя основная говядина с C ++ как языком разработки графического интерфейса заключается в том, что у него нет понятия автоматического управления памятью, что делает процесс разработки намного более подверженным ошибкам. Это не интроспективно, что делает отладку намного сложнее. Большинство других основных инструментов GUI имеют некоторое представление об автоматическом управлении памятью и интроспекции.
  2. Каждый кросс-платформенный инструментарий страдает от проблемы, что он только когда-либо может реализовать наименее общий знаменатель всех поддерживаемых платформ. Это и разные руководства по пользовательским интерфейсам на разных платформах очень часто задают вопрос о желательности кросс-платформенных графических интерфейсов в целом.
  3. Qt очень сосредоточен на кодировании всего вашего пользовательского интерфейса. Даже если вы можете использовать QtDesigner для создания некоторых частей вашего пользовательского интерфейса, он серьезно отсутствует по сравнению с, скажем, (Cocoa /Obj-C) Interface Builder или инструментами .Net.
  4. Несмотря на то, что Qt включает в себя множество низкоуровневых прикладных функций, он не может сравниться с тем, что для конкретной платформы используется каркас. Собственные библиотеки операционной системы для Windows и OSX значительно более мощные, чем реализации Qt. (Подумайте, аудиосистемы, доступ к файловой системе низкого уровня и т. Д.).

Тем не менее, мне нравится использовать PyQt для быстрого прототипирования приложений или внутренних приложений. Использование Python для выполнения всего кодирования облегчает проблемы с C ++ и фактически делает Qt очень приятным местом.


Изменить в ответ на некоторые комментарии:

Когда я писал о написании Qt на C ++, я не столько жаловался на Qt, сколько больше на окружающую среду, в которой он живет. Правда, Qt очень хорошо управляет своими ресурсами, но все ваши GUI-связанные -but-not-Qt-код также должен быть написан на C ++. Даже там Qt предоставляет множество хороших инструментов, но в конечном итоге вам приходится иметь дело с C ++ на этом уровне. Qt делает C ++ допустимым, но он все еще C ++.

Что касается интроспекции, я имею в виду следующее: самые трудные случаи для отладки - это когда у вас есть указатель на какой-то объект, который не ведет себя так, как вы думаете. С C ++ ваш отладчик может немного заглянуть внутрь этого объекта (если он имеет информацию о типе в точке thwt), но даже это не всегда работает. Возьмем, с другой стороны, Какао в той же ситуации. В Cocoa /Obj-C вы можете отправлять сообщения («функции вызова») объекту прямо внутри отладчика. Вы можете изменить состояние объектов, вы можете запросить его для своих атрибутов, вы можете запросить его для своего типа и имен его функций ... Это может сделать отладку намного более удобным. Qt /C ++ не имеет ничего близкого к этому.

ответил Ladislav Mrnka 30 +04002011-10-30T19:46:34+04:00312011bEurope/MoscowSun, 30 Oct 2011 19:46:34 +0400 2011, 19:46:34
4

Рамки, такие как Qt, подходят, когда вы больше озабочены тем, что ваш продукт ищет тот же на всех платформах, чем ваш продукт, выглядящий right на всех платформах. Все чаще и чаще в эти дни такие приложения переходят на веб-технологии.

ответил Ladislav Mrnka 30 +04002011-10-30T19:46:34+04:00312011bEurope/MoscowSun, 30 Oct 2011 19:46:34 +0400 2011, 19:46:34
3

Самая важная, но не упомянутая вещь. В большом проекте одна вещь вызывает столько проблем и ненужного кода. Механизмы слотов сигнала Qt неэффективны. Виджеты Qt не предоставляют необходимые сигналы для простых виджетов событий. Например, вы не можете устанавливать сигналы для onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus и т. Д. Даже самый сложный виджет, такой как QTreeWidget, предоставляет один или два ультра простых бесполезных сигнала.

Да, вы можете использовать события НО !!! вы создаете новый класс для каждого виджета с настраиваемым событием. Это огромная потеря эффективности;

  • Вы переписали каждое настроенное событие объекта виджета, есть небольшие изменения.
  • Вы теряете весь материал Qt Designer. Вы должны продвигать каждый виджет с пользовательскими событиями.
  • Проект стал больше и трудно поддерживать.
  • Из-за этого вы начали не любить qt. И начать говорить о том, как .net предоставляет делегатам, насколько это намного лучше, чем слот сигнала, как компоненты .net (widgets) обычно предоставляют каждое событие, которое вы можете себе представить. И т. Д.

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

Тем не менее, Qt - лучшая C ++ UI-структура до сих пор с сокращениями и ups.

ответил Ladislav Mrnka 30 +04002011-10-30T19:46:34+04:00312011bEurope/MoscowSun, 30 Oct 2011 19:46:34 +0400 2011, 19:46:34
2

Мне очень нравится Qt, но это немного тяжеловес для многих приложений. Иногда вам просто не нужен этот уровень сложности. Иногда вам просто нужно что-то простое без всех накладных расходов Qt. Не каждое приложение должно управляться событиями, а C ++ предоставляет разумный набор шаблонов. Boost обеспечивает еще один очень хороший набор и включает в себя множество низкоуровневых функций (файл, сокет, управляемые указатели и т. Д.), Которые выполняет QT.

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

У некоторых есть соображения безопасности или стабильности, которые не позволяют сложным библиотекам, таким как Qt.

Вам нужно запустить moc для предварительной обработки ваших источников. Это не огромная проблема, но это может быть сложной задачей для нового пользователя. Многие программисты считают, что вам нужно использовать qmake с Qt, но это неправильное название. Можно легко подключить Qt к другим системам сборки.

Некоторые цели ограничены памятью или процессором.

В нем есть определенные платформы. Большинство из этих gotchas недокументированы. Создайте достаточно большое приложение, и вы столкнетесь с ним и зададитесь вопросом, что происходит (отказ от ответственности, последний раз, когда я использовал Qt в гневе, было более 18 месяцев назад, поэтому он может быть улучшен).

Только C ++. Существуют другие языковые привязки, но они, как правило, скрывают или плохо отображают многие функциональные возможности, для которых вам нужен Qt.

Есть много причин не использовать Qt, поэтому есть альтернативы. Если у вас есть молот, тогда каждая проблема будет выглядеть как гвоздь.

ответил Ladislav Mrnka 30 +04002011-10-30T19:46:34+04:00312011bEurope/MoscowSun, 30 Oct 2011 19:46:34 +0400 2011, 19:46:34
1

по моему мнению, изучение программирования на С ++ проще, чем попадание на другие языки, которые скрывают их сложность, а программист не знает, что на самом деле происходит в фоновом режиме. Qt, с другой стороны, добавляет некоторые преимущества по сравнению с C ++, чтобы сделать его более высоким, чем родной C ++. Таким образом, Qt C ++ - отличная основа для тех, кто хочет разработать низкоуровневые задачи или высокоуровневые, таким же образом. C ++ - это (по некоторым практикам) сложный и простой язык. Комплекс для тех, кто хочет не бросить вызов, просто для тех, кому это нравится. Не оставляйте его для его сложности!

ответил Ladislav Mrnka 30 +04002011-10-30T19:46:34+04:00312011bEurope/MoscowSun, 30 Oct 2011 19:46:34 +0400 2011, 19:46:34
0

Фактическая причина не техническая.

Люди случаются иначе. Так и их выбор. Однородность не является человеческой особенностью.

ответил Ladislav Mrnka 30 +04002011-10-30T19:46:34+04:00312011bEurope/MoscowSun, 30 Oct 2011 19:46:34 +0400 2011, 19:46:34

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132