LINUX.ORG.RU

Qt доступна теперь и под LGPL

 , ,


0

0

Компания Nokia объявила о том, что, начиная с версии 4.5, кросс-платформенная библиотека Qt будет доступна также под лицензией LGPL.

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

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

Коммерческая лицензия и лицензия GPL также останутся доступными.

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

>>> Подробности

★★★★★

Проверено: Dimez ()

Ответ на: комментарий от Bohtvaroh

>Да всё с ним не так. А в сравнении с виндовым - просто смех

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

MYMUR ★★★★
()
Ответ на: комментарий от anonymous

>> > Но к Си это никак не относится, там мужественно перелопатят char'ы пока нолик найдут. > И в чём проблема?

>В чём проблема найти конец 2х гигабайтной строки? В ДНК проблема, в ДНК..

Если это большой текстовой файл, то его все равно придется последовательно парсить.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> Если это большой текстовой файл, то его все равно придется последовательно парсить

достаточно просто попробовать нарезать строку на перекрывающиеся подстроки чтобы осознать всю фейловость сишных строк.

miroku108
()
Ответ на: комментарий от miroku108

> достаточно просто попробовать нарезать строку на перекрывающиеся подстроки чтобы осознать всю фейловость сишных строк.

Тебе на первой лекции по программированию не рассказывали, что не все языки удобны для реализации всех типов задач?

gaa ★★
()
Ответ на: комментарий от anonymous

>И много ты GUI-приложений с помощью этой хренотени написал?

если Tcl можно считать полноценным языком, то много :)

впрочем, на Haskell тоже было,- но значительно меньше. и на SWI-Prolog + XPCE в своё время вполне себе GUI лепилось :)

jtootf ★★★★★
()
Ответ на: комментарий от Minoru

>В полноценных языках, таких как Лисп, хорошо развиты лямбды и функции высшего порядка

I hereby pronounce you guilty in having side effects!

jtootf ★★★★★
()
Ответ на: комментарий от gaa

> Тебе на первой лекции по программированию не рассказывали, что не все языки удобны для реализации всех типов задач?

сишные строки вообще ни для каких задач не удобны.

miroku108
()
Ответ на: комментарий от miroku108

>> Если это большой текстовой файл, то его все равно придется последовательно парсить

>достаточно просто попробовать нарезать строку на перекрывающиеся подстроки чтобы осознать всю фейловость сишных строк.

Я забыл как в glibc называется аналог strdup с двумя дополнительными параметрами - offset + length. При желании можно написать свой. Если нет желания привлекать кучу для этого дела можно написать макрос вокруг _alloca() который разместит срез строки в стеке. Идея написать макрос конечно фэйлова для чистоплюя, но С++ тут ничем не поможет, т.к С++-ные коллекции аллоцируются строго в куче.

Absurd ★★★
()
Ответ на: комментарий от Absurd

>Кстати, в D массив это спаренный указатель на начало и на конец секвенции. Алексанреску говорит что кучу рулезов можно извлечь из такого подхода.

Кстати похоже неплохая идея. И размер легко вычисляется и всегда известно начало и конец.

jump
()
Ответ на: комментарий от miroku108

> int a[10];
> int s = sizeof(a);


Уууу... как все грустно. Луговский был толковее.

eXOR ★★★★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от Absurd

> На PDP это был тип данных поддерживающийся аппаратно.

А еще там аппаратно поддерживался автоинкремент (автодекремент) регистров при косвенной адресации. Поэтому появилась в Си появилась операция ++ .

anonymous
()
Ответ на: комментарий от jtootf

>I hereby pronounce you guilty in having side effects!

Кстати, да. Вот сейчас пилю мод srt для emacs-а, и это становится серьезной проблемой ~_~

Minoru ★★★
()
Ответ на: комментарий от Minoru

...Но вообще, технологии обработки текста в Emacs чем-то мне напоминают автоматное программирование.

Minoru ★★★
()
Ответ на: комментарий от anonymous

> Аллокаторы не осилил? :) Фейловость идеи аллокаторов уже давным-давно понятно всем кроме самых тугих анонимусов.

anonymous
()
Ответ на: комментарий от anonymous

>PS. Не тролль, не лжец, не бородат.

Это даже на советских калькуляторах было

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от anonymous

Прежде чем пятницо окончательно схавает твой моск (мозгом такое назвать у меня такое рука не поднимается), скажи мне, на каком основании инстансы string'ов с одинаковыми типами char'ов, но разными аллокаторами несравнимы, если вручную не написать два вида операторов сравнения?

anonymous
()
Ответ на: комментарий от anonymous

Пока мой моск не растворился в пиве, отвечу. Они сравнимы ) Просто твоя реализация STL не умеет их сравнивать. Почему так? Это вопрос не ко мне. Не я писал.

anonymous
()
Ответ на: комментарий от anonymous

> Просто твоя реализация STL не умеет их сравнивать.

Реквестирую реализацию, которая умеет или не было!

anonymous
()
Ответ на: комментарий от anonymous

гугл тебе в помощ, или сам сделай ;)

anonymous
()
Ответ на: комментарий от Minoru

> Из этой фразы непосредственно следует, что быдлокодерам удобнее писать на C++ чем на C.

На С пишут тоже одни лишь быдлокодеры потому, что не осилили даже ассемблер. ТруЪ кодеры пишут в машинных кодах!

anonymous
()
Ответ на: комментарий от anonymous

>> Из этой фразы непосредственно следует, что быдлокодерам удобнее писать на C++ чем на C.

> На С пишут тоже одни лишь быдлокодеры потому, что не осилили даже ассемблер. ТруЪ кодеры пишут в машинных кодах!

Тумблеры решают.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>>> Из этой фразы непосредственно следует, что быдлокодерам удобнее писать на C++ чем на C.
>> На С пишут тоже одни лишь быдлокодеры потому, что не осилили даже ассемблер. ТруЪ кодеры пишут в машинных кодах!

> Тумблеры решают.


Это для быдла, неосилившего намагничивание ферритовых колец вручную!

gaa ★★
()
Ответ на: комментарий от anonymous

> А еще там аппаратно поддерживался автоинкремент (автодекремент) регистров при косвенной адресации. Поэтому появилась в Си появилась операция ++ .

Вообще-то и в Intel x86 тоже есть отдельные однобайтовые инструкции inc/dec для инкремента/декремента регистра.

anonymous
()
Ответ на: комментарий от anonymous

Да, кстати аппаратная поддержка C-строк, с автоинкрементом/декрементом указателей на строки есть и в x86 начиная с 16-битных камней. Более того в камнях есть специальные оптимизации под это дело(Fast Strings), что, наверное, будет открытием для фанатов древнего артефакта PDP таких как Absurd. Это инструкции lods, stos, scas, работающие с байтами/словами/двойными словами/восемью байтами с указателями в SI/DI, ESI/EDI или RSI/RDI, длиной строки в CX/ECX/RCX и автоинкрементом/декрементом в зависимости от флага Destination(cld/std). Но это не оправдывет сишных строк, из-за которых вообще возможны переполнения буфера с выполнением кода из буфера на стеке или в куче и ужасную неэффективность, выражающуюся в засирании кеша и прожигании драгоценных тактов процессора на пробегание всей строки лишь для того, чтобы определить её размер. PDP и C-строки R.I.P.

anonymous
()
Ответ на: комментарий от anonymous

> Но это не оправдывет сишных строк, из-за которых вообще возможны переполнения буфера с выполнением кода из буфера на стеке или в куче

Если руки растут из жопы, никакие квазибезопасные строки не помогут.

> и ужасную неэффективность, выражающуюся в засирании кеша и прожигании драгоценных тактов процессора на пробегание всей строки лишь для того, чтобы определить её размер. PDP и C-строки R.I.P.


Кеширование значений придумали трусы, не так ли?

gaa ★★
()
Ответ на: комментарий от anonymous

> В чём проблема найти конец 2х гигабайтной строки? В ДНК проблема, в ДНК..

А в чём проблема транспортировать воду в решете? Вот тут также. В ДНК проблема у того, кто не понимает жуткой неэффективности дизайна С-строк, которая требует пробегать всю строчку от начала до конца, чтобы определить её размер, чем и занимаются, strlen(), wcslen(), strcat() и др. В топку сишные строки! Только "благодаря" им и расплодилось миллионы эксплоитов, использующих переполнения в дурацких сишных строках на стеке и на куче. Только из-за этого дебилизма пришлось выдумывать костыли Fast Strings, SSP, DEP и Execution Disable.

anonymous
()
Ответ на: комментарий от anonymous

>под вистой сегфолтятся.

сделай фикс. тут хотя бы можно. а для fork() надо фиксы в ядро винды коммитить.

anonymous
()
Ответ на: комментарий от gaa

> Если руки растут из жопы, никакие квазибезопасные строки не помогут.

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

anonymous
()
Ответ на: комментарий от gaa

а нынешние продвинутые пишут ногами? оно и видно.

anonymous
()
Ответ на: комментарий от miroku108

благодарю, невозбранно упёр код.

а ты тупица, кстати. чуть не забыл, да.

anonymous
()
Ответ на: комментарий от anonymous

а он не понял разницу между «реализацией» и «использованием реализации». в их быдлопту это ещё не проходили.

anonymous
()
Ответ на: комментарий от gaa

> Кеширование значений придумали трусы, не так ли?

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

anonymous
()
Ответ на: комментарий от anonymous

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

з.ы. пища для размышления: пошто в некоторых ЯП есть листы, но нет массивов.

Minoru ★★★
()
Ответ на: комментарий от anonymous

> Вопрос в другом: почему ни С-строки ни С-массивы не содержат информации ни о длине строки ни о кол-ве элементов в массиве и почему средства С не проверяет на основании этой информации выход за границы строки или массива?! Давно пора переделать этот уродливый дизайн. Не ошибается только тот, кто ничего не делает, поэтому возражение про руки из жопы, которое как бы должно оправдать убогий С не принимается.

Высер и классической ситуации, описанной в замечательном пособии "как разпознать в собеседнике идиота": собеседник игнорирует все опровержения и продолжает твердить своё, в данном случае "нультерминальные строки убоги".

gaa ★★
()
Ответ на: комментарий от gaa

>Высер и классической ситуации, описанной в замечательном пособии "как разпознать в собеседнике идиота": собеседник игнорирует все опровержения и продолжает твердить своё, в данном случае "нультерминальные строки убоги".

Этот собеседник - обычное невменяемое форумное быдло. Да из него метан так и пыщет!

Minoru ★★★
()
Ответ на: комментарий от Minoru

Может направим этот метан замерзающей европе, тольку ведь больше будет?

anonymous
()
Ответ на: комментарий от anonymous

>будет открытием для фанатов древнего артефакта PDP таких как Absurd

Метанизирующий тролль такой метанизирующий тролль. Речь шла о том что K&R профнепригодны по причине того что они придумали ASCIIZ-строки.

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

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

Absurd ★★★
()
Ответ на: комментарий от anonymous

>>т.к С++-ные коллекции аллоцируются строго в куче.

>Аллокаторы не осилил? :)

Ну ты и идиот. Напиши аллокатор для std::string который работает через _alloca(). Hint: указатель полученный через _alloca() невалиден после выхода из блока.

Absurd ★★★
()
Ответ на: комментарий от Absurd

>Ну ты и идиот. Напиши аллокатор для std::string который работает через _alloca(). Hint: указатель полученный через _alloca() невалиден после выхода из блока.

Ага, клинический :) Что мешает использовать контейнер внутри одного блока?

А воще по теме даже в убогом МєФєЦє строки имеют как счетчик так и 0 в конце.

anonymous
()
Ответ на: комментарий от anonymous

>>Ну ты и идиот. Напиши аллокатор для std::string который работает через _alloca(). Hint: указатель полученный через _alloca() невалиден после выхода из блока.

>Ага, клинический :) Что мешает использовать контейнер внутри одного блока?

Из аллокатора надо вернуть адрес аллокированной памяти. А выход из аллокатора - это выход из блока.

Absurd ★★★
()
Ответ на: комментарий от gaa

> Высер и классической ситуации, описанной в замечательном пособии "как разпознать в собеседнике идиота": собеседник игнорирует все опровержения и продолжает твердить своё, в данном случае "нультерминальные строки убоги".

Тебе объяснили, что парсить всю строку неэффективно, что отсутствие контроля выхода за пределы создало благоприятную почву для bof эксплоитов, а ты упёрся как баран. Ни одного опровержения от тебя не было и быть не может. В C#, кстати, эту угребищность строк С пофиксили. Адекватные люди, а не быдлофанатики ретро, предпочитающие ездить на гужевой повозке в 21 веке.

anonymous
()
Ответ на: комментарий от Absurd

> Метанизирующий тролль такой метанизирующий тролль.

Сам дурак. :p

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

Если в этих случаях Pascal-style строки не дают никаких преимуществ, то это еще не значит, что разницы нет. Разница есть в определении длины строки, в конкатенации, не говоря уже про то, что не пришлось бы давать рекоменлации ни в коем случае не использовать "опасные функции" strcpy, sprintf и т.д. и лепить костыли DEP и SSP после того как клюнет жареный эксплоит.

anonymous
()
Ответ на: комментарий от Absurd

> Зачем для битья строки на токены знать ее длину?

А зачем для определении длины строки пробегать каждый раз ее до нуля? Зачем изобретать strcpy(), strcat(), sprintf(), а затем запрещать их? Зачем выдумывать такой тупой дизайн, а затем прикручивать костыли один другого краше для контроля не перетёрт ли адрес возврата при выходе из функции и блокирования исполнению шеллкода? Это называется "дурная голова ногам покою не даёт".

anonymous
()

Это наверняка связано с тем, чтоб не ослаблять позиции QT. Конкурентов много, конкуренты растут. Взять тот же пресловутый mono.

anonymous
()
Ответ на: комментарий от anonymous

блеснул знаниями? молодец. теперь иди учи матчасть. в частности, отсутствие инструкций типа "load-and-increment", на которые 1:1 отображалось "++", например.

школиё.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.