LINUX.ORG.RU

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

 , ,


0

0

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

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

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

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

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

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

★★★★★

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

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

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

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

Речь шла не об инструкциях inc,dec, а о том, что параллельно с любой командой можно было автоматически увеличить (уменьшить) на 1 или 2 (в зависимости от типа адресуемых операндов) значение любого регистра.

Операция копирования ASCIIZ строки занимала две команды на ассемблере.

10$: movb (r1)+, (r0)+ ; copy until a null

bne 10$ ; not done

На Си аналогичный код соответственно выглядел так:

while (*dst++ = *src++) {}

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

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

Паскалистам это нужно, чтобы не выпрыгнуть за ее пределы. Вот не могут они в C делать то же самое через проверку на NULL.

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

>> Было бы прикольно посмотреть на Shareware под линукс. :)

> Nero подойдет?

Кстати, да. Хотя мне k3b пока хватает.

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

>Разница есть в определении длины строки

Еще раз - зачем тебе нужна длина строки? Что ты с ней планируешь делать?

>в конкатенации

Зачем тебе их конкатинировать? Просто в си через printf текст выводят обычно.

>не пришлось бы давать рекоменлации ни в коем случае не использовать "опасные функции" strcpy, sprintf и т.д. и

Ну например OpenBSD на Си пишут и не жужжат.

>лепить костыли DEP и SSP после того как клюнет жареный эксплоит.

Почему костыли? Безопасность должна обеспечиваться аппаратно.

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

ЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕ ПЕЗДАТОЕ ПЕТАРДО!!

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

> и -- нет, lods не подходит.

Это с какого это не подходит? Иди учи матчасть, ламерьё.

lods = *p++

inc [ebx] = (*p)++

Для lods можно и "--", после std.

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

Ты наркоман! Сука, я знаю, ты наркоман. Выдай мне последний символ стомегабайтной строки, не зная её длины!

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

>Выдай мне последний символ стомегабайтной строки, не зная её длины!

Откуда ты можешь взять стомегабайтную строку? Я вообще-то думал что текстовые данные читаются с диска или из сети, а там доступ последовательный. Ну, в случае с файлом можно перемотать на сто мегабайт вперед, блочные устройства поддерживают такую операцию.

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

Ах, нельзя стомегабайтную? Тогда по одному мегабайту мне сто штук, последовательно. Ты точно наркоман. Длину знать надо всем, иначе бы её в твоих сях не передавали везде явным образом.

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

Кстати, насчёт аппаратной поддержки ASCIIZ в x86 я прогнал. Уже забыл, что число передаваемых байт/слов/двойных или четверных слов и максимальный размер строки передаются префиксу rep в явном виде в регистре CX/ECX/RCX, что лучшим образом подходит для строк, содержащих в начале свой размер.
Кстати, уже даже до мелкософта дошло, что ASCIIZ строки небезопасны, пока красноглазые кульхацкеры gaa ходят с транспарантами "Долой предохранители!" и "Дайошь увеличение надоев переполнений буфера!", поэтмоу они используют тип UNICODE_STRING:

typedef struct _LSA_UNICODE_STRING {
USHORT Length;
USHORT MaximumLength;
PWSTR Buffer;
} LSA_UNICODE_STRING,
*PLSA_UNICODE_STRING,
UNICODE_STRING,
*PUNICODE_STRING;

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

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

Так их, таких, анонимный брат, этих сишных быдлокодеров фанатов дырявого тормозного ASCIIZ и PDP-шного дерьма мамонтов.

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

>Ах, нельзя стомегабайтную? Тогда по одному мегабайту мне сто штук, последовательно.

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

>Длину знать надо всем, иначе бы её в твоих сях не передавали везде явным образом.

Переход на какие-то абстрактные "везде". Слив засчитан.

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

Пассмотрим, например глупую быдлосишную функцию char * strrev (char * str). Что может быть глупее? Для того, чтобы обратить порядок букв в стомегабайтной строке, содержащей краткий пересказ "Войны и мира" дурной быдло-си, вместо того, чтобы сразу заняться перестановкой букв, побежит определять длину переданной строки с самого первого байта в поисках нулевого байта, нагружая конвейер процессора, кеши, чипсет и модули памяти миллиардами тактов бессмысленной работы, расходуя драгоценное электричество мегаваттами в масштабах планеты, разоряя пользователей счетами за электрожэнергию и провоцируя развитие глобального потепления!

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

>Убедил. Лично ты можешь юзать свой strlen.

Я его не использую. Если мне локально нужна длина я ее передаю отдельным параметром.

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

> Так их, таких, анонимный брат, этих сишных быдлокодеров фанатов дырявого тормозного ASCIIZ и PDP-шного дерьма мамонтов.

Просто классика - приписать оппоненту то, чего он не говорил, и героически опровергать это.

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

Но нет, анонимные братья будут срывать покровы с очевидного и со священным огнем в глазах разоблачать то, что давно разоблачено, заодно демонстрируя длину^Wглубину познаний в архитектурах команд разной степени древности. Детский сад :)

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

> Я его не использую. Если мне локально нужна длина я ее передаю отдельным параметром.

А если не нужна, ты экономишь целое машинное слово! Побольше бы таких!!!

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

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

Почему бы файл с пересказом "войны и мира" не читать с конца чанками по 1Мб, оборачивая порядок букв в каждом чанке? Размер чанка известен.

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

> Просто классика - приписать оппоненту то, чего он не говорил, и героически опровергать это.

Перечитай тред сначала.

"На PDP это был тип(ASCIIZ - прим. анонимуса) данных поддерживающийся аппаратно." (c) Absurd

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

Это и есть попытка фанатика доказать всю труЪшность ASCIIZ в прямых руках. Не удивлюсь, если Absurd бсдшнег потому, что бсдшники в основной массе фанатики-ретрограды с шаблонным мышлением.

> ASCIIZ-строки придумали 35 лет назад, когда проверка выхода за границы массива обычно была отключена даже там, где она была; придуманы ASCIIZ-строки были для языка системного программирования

Вот только лепят С повсюду: grep, awk, sed, bind, apache, gnome - это ПРИКЛАДНЫЕ программы, некоторые из которых занимаются именно ПОТОЧНОЙ обработкой текста. И при этом расплодилось куча забавных фанатов С, которые с блеском в глазах отстаивают гениальное а на самом деле опасное и неэффективное, изобретение - ASCIIZ и свято верят, что С настолько уникален, что быдлокодеры обходят его стороной и не пишут на нем свои сегфолтящиеся глюкалки.

> Детский сад :)

You welcome!

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

>> Я его не использую. Если мне локально нужна длина я ее передаю отдельным параметром.

>А если не нужна, ты экономишь целое машинное слово! Побольше бы таких!!!

Тут еще есть фича в том что я не дублирую строку. Т.е у меня есть буффер размером скажем в 16 Кб и я должен передать функции его фрагмент, я передам сам буффер и lo_bound + hi_bound в нем. Если бы я я пользовался паскалевыми строками, мне пришлось бы дублировать фрагмент буффера чтобы получить строку в формате паскаля.

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

> Еще раз - зачем тебе нужна длина строки? Что ты с ней планируешь делать?

Хватит уже прикидыватся идиотом. Сишные функци ожидают окончания строки нулем, а это значит, что работать с подстрокой сишными функциями ты не можешь. либо модифицировать исходную строку вставляя ноль, либо делать копию. Или продублировать все функции str* для срезов строк.

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

> Перечитай тред сначала.

Я слежу :)

> "На PDP это был тип(ASCIIZ - прим. анонимуса) данных поддерживающийся аппаратно." (c) Absurd

Ну так ведь был? И K&R сторговали память за время, разумный компромисс для тех времен.

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

Ну правильно - есть куча других способов убить прогу, и без манипуляции строками. Runtime-предохранителей в Си нет вообще, и это by design.

> Это и есть попытка фанатика доказать всю труЪшность ASCIIZ в прямых руках.

Ну Абсурд такой Абсурд, но в данном случае он по большей части прав - в прямых руках ASCIIZ вполне работают. Это не значит, что они труЪ. Но их потенциальная опасность и неэффективность также не свидетельствует о том, что Сишники - быдлкодеры, а K&R - лохе профнепригодные. Решения принимались в древние (по компьютерным меркам) времена, и тогда были вполне оправданными. Сейчас tradeoff'ы изменились - ну, пора сделать следующую библиотеку манипуляции строками.

> лепят С повсюду: grep, awk, sed, bind, apache, gnome - это ПРИКЛАДНЫЕ программы, некоторые из которых занимаются именно ПОТОЧНОЙ обработкой текста.

ну grep, awk, sed - это давно написано и вполне работает (насколько часто там есть баги с переполнением буфера?), а Apache, GNOME и прочее... ну что ж, Си++ не смог захватить mindshare Си, а больше писать было и не на чем (да и сейчас тоже не на чем).

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

> Тут еще есть фича в том что я не дублирую строку. Т.е у меня есть буффер размером скажем в 16 Кб и я должен передать функции его фрагмент, я передам сам буффер и lo_bound + hi_bound в нем. Если бы я я пользовался паскалевыми строками, мне пришлось бы дублировать фрагмент буффера чтобы получить строку в формате паскаля.

Теперь этот клоун про паскалевские строки вспомнил. Школьные годы в жопе заиграли? Тебе, наркоману, видно, невдомёк, что тип "строка" может состоять не из одного указателя, а из ДВУХ, на начало и на конец. Либо указатель на начало и длина, что одно то же. Подумай об этом сегодня перед сном, милый.

anonymous
()

Замечание для всех, кто ругает ASCIIZ строки - я ни в коем случае не хвалю их.

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

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

Понятно что в таких условиях счет шел буквально на каждый такт процессора.

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

Копирование строки с явным указание длины выглядело так

1$: MOVB (R0)+,(R1)+

DEC R2

BNE 1$

На одну команду больше, чем для asciiz строк

Также asciiz строки не имели ограничения по длине и могли располагаться по произвольным адресам.

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

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

Я понимаю, что все это смешно для современных 64-битных процессоров имеющих столько кэша, сколько было оперативной памяти у тогдашних компьютеров. Но попробуйте поставить себя на место тех людей и спросите себя, а как бы программировал я?

По поводу оператора REP MOVSB компьютеров с архитектурой x86 .

Оператор REP MOVSB может использовать только строго определенные регистры. Это означает, что перед копированием строки надо обязательно загрузить адреса строк именно в эти регистры и еще обязательно установить флаг направления.

В случае PDP-11 можно было использовать любые регистры.

Для интересующихся можете поискать в интернете orthogonal vs non-orthogonal instruction set .

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

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

Да, можно продублировать в стеке с помощью strndupa() если передать туда адрес начала подстроки и ее длину. Либо поставить '\0' если это локальная строчка, и, следовательно, проблема реэнтерабельности не стоит. А Си++ подход через std::string задействует динамическую память в любом случае. Но и в Си можно задействовать динамическую память если продублировать фрагмент через strndup().

Absurd ★★★
()

Клево.

Теперь основная версия Ubuntu будет KDE'шной.

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

>> Изначально Qt был несвободным инструментарием.

> Изначально - это когда? Можно ссылкой кинуть? Самое раннее, что удалось найти - это архив сайта trolltech.com за май 2000 года. Уже тогда было две версии. Free и Professional. По лицензии free исходники были доступны.

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

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

> Это был gaa

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

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

> Изначально - это когда? Можно ссылкой кинуть? Самое раннее, что удалось найти - это архив сайта trolltech.com за май 2000 года. Уже тогда было две версии. Free и Professional. По лицензии free исходники были доступны.

qt-1.x была не под GPL. Исходники были доступны, но лицензия запрещала их изменять.

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

> В си все через жопу.

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

Offtop: чем меньше шавка, тем громче тявкает. Страуструп тоже нашел недостатки в сях - его реакция тише и результативнее.

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

> В топку сишные строки! Только "благодаря" им и расплодилось миллионы эксплоитов, использующих переполнения в дурацких сишных строках на стеке и на куче. Только из-за этого дебилизма пришлось выдумывать костыли Fast Strings, SSP, DEP и Execution Disable.

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

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

> Offtop: чем меньше шавка, тем громче тявкает.

Или менее вежливо - "наглый, как колымский пидор".

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

>Offtop: чем меньше шавка, тем громче тявкает. Страуструп тоже нашел недостатки в сях - его реакция тише и результативнее.

Да ну. Теперь по ЛОРу ходит куча ООПшных троллей и метанирует.

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

>Страуструп тоже нашел недостатки в сях — его реакция тише и результативнее.

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

зыж капчу в жопу тем, кто её писал! ну нечитабельно же уже пятый раз!

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

> глядишь, сейчас писали бы на ObjC.

Не писали бы - владельцам ObjC это было не нужно. А Страуструп выпустил компилятор почти в опенсорс.

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

кто-то запрещал сделать свой компилятор ObjC? тем более, что это на порядок как минимум проще, чем реализовать C++. если бы не диверсия трупа страуса, ObjC достаточно быстро бы реализовали. сначала — как и C++, препроцессором, а потом и компилятором. потому что удобно, и совместимость с C (чего у C++ нет) на месте.

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

> кто-то запрещал сделать свой компилятор ObjC?

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

> тем более, что это на порядок как минимум проще, чем реализовать C++

Компилятор для Си++ образца 1986 года мог быть реализован одним человеком за несколько месяцев, так что не надо тут.

> если бы не диверсия трупа страуса, ObjC достаточно быстро бы реализовали

Ну понятно. Заговор мировой закулисы...

Люди сделали выбор - не нашлось анонимного аналитика, чтобы предупредить их :)

> и совместимость с C (чего у C++ нет) на месте.

Жж0ш.

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

твои глюки по поводу закулисы каментить не буду. а по поводу совместимости — пожалуйста:

char *c = malloc(256);

скомпилируй-ка мне это без изменений на C++. всякие приведения типов и extern "C" не канают — это уже не совместимость на уровне исходников. а в ObjC это компилируется без изменений — вот чудо, а?!

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

> твои глюки по поводу закулисы каментить не буду

Какая неблагодарность... и это после того, как я честно прокомментировал все твои глюки %)

> char *c = malloc(256);

> скомпилируй-ка мне это без изменений на C++

Не скомпилируется. А зачем компилировать Си-программы компилятором Си++?

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

Странно, раньше ты говорил просто о "совместимости" (сферической и в вакууме, надо полагать). Ну да, Си++98 несовместим с Си99 на уровне исходников, какой сюрприз. И что?

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

а то, что нахера нужно говно, которое кричит «а я совместимо с цэ!» (а что, не для этого цпп делали? чтобы не потерять кодобазу цэ, и при этом поиметь недоООП)?

алсо, я полагал, что даже идиоту очевидно — я имел в виду совместимость именно на уровне исходников. потому что слинковаться с цэ-либой даже FPC умеет.

>А зачем компилировать Си-программы компилятором Си++?

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

зыж а с виду ты был похож на более-менее нормального…

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

> что, не для этого цпп делали? чтобы не потерять кодобазу цэ, и при этом поиметь недоООП

И что? Если не собираешься модифицировать Си-модуль, скомпилируй ее Си-компилятором, и слинкуй с Си++-модулем, какие проблемы?

> алсо, я полагал, что даже идиоту очевидно — я имел в виду совместимость именно на уровне исходников

Ну, насчет того, что очевидно идиотам - спорить не буду.

>>А зачем компилировать Си-программы компилятором Си++?

> а затем, идиот, чтобы использовать наработки сишников. без напильника.

А слабО тебе взять компиляторы конца 80-х иначала 90-х, и попробовать скомпилировать твой же фрагмент? Я же не зря указал, Си99 и Си++98.

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

Зато сами языки - в жопе :D

> зыж а с виду ты был похож на более-менее нормального…

Не могу сказать того же насчет тебя - все вы на одно лицо, а в стиле общения эмулируете Веталега :) Но таки да, меня вечно принимают не за того %)

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

>> глядишь, сейчас писали бы на ObjC.

>Не писали бы - владельцам ObjC это было не нужно. А Страуструп выпустил компилятор почти в опенсорс.

Я бы сказал что дело не в опенсорце, а в MSVC++. На юниксах сие чудо никогда особо не любили.

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

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

>Зато сами языки - в жопе :D

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

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

>И что? Если не собираешься модифицировать Си-модуль, скомпилируй ее Си-компилятором, и слинкуй с Си++-модулем, какие проблемы?

такие, что иногда есть желание использовать *куски* кода, а не *модули*.

>А слабО тебе взять компиляторы конца 80-х иначала 90-х, и попробовать скомпилировать твой же фрагмент?

мимо кассы.

>Зато сами языки — в жопе

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

>а в стиле общения эмулируете Веталега

и не собирался, я сам по себе хамло.

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

ещё «автоуничтожение стековых объектов». ну, потому что нормальный gc ниасилили, и привинтили костыль. точнее, очередные грабли.

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

> иногда есть желание использовать *куски* кода, а не *модули*.

Подозреваю, что при cut'n'paste всё равно куски придется править, так что исправление преобразований ни на что особо не повлияет.

>> А слабО тебе взять компиляторы конца 80-х иначала 90-х, и попробовать скомпилировать твой же фрагмент?

> мимо кассы.

Ничуть. Если моя память мне ни с кем не изменяет, компиляторы Си тех времен на твой пример дали бы ворнинг, так что пришлось бы поставить насильное преобразование типа - и код стал бы Си++-совместимым. Так что во времена, когда это было важно, совместимость по исходным кодам была приличной :)

Но потом Си и Си++ пошли разными путями, что прискорбно. Shit happens.

>>Зато сами языки — в жопе

>потому что говнокодеры считают цпп вершиной технологий

Если бы всё было так просто... Кстати, говнокодерам пох, на чем писать.

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

>Подозреваю, что при cut'n'paste всё равно куски придется править

зачем? а даже если и да — есть разница между «править все места, где цпп тупит» или «поправить пару мест, чтобы сопряжение с существующим кодом было».

>Если моя память мне ни с кем не изменяет, компиляторы Си тех времен на твой пример дали бы ворнинг

не уверен, но по-моему, как раз нет. совместимость void * с чем угодно — базовая фича цэ, вроде как. а цпп тут резко впадает в необоснованную паранойю, заставляя городить преобразование типов там, где оно не надо.

>Кстати, говнокодерам пох, на чем писать.

не совсем. на LISP, например, не пишут. %-)

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

> совместимость void * с чем угодно — базовая фича цэ, вроде как.

IIRC, нет. Но компилятора из тех лет под рукой нет.

> а цпп тут резко впадает в необоснованную паранойю

А еще он не умеет новый синтаксис инициализации :) Но всё это появилось "относительно недавно", уже после массового внедрения и ООП-хайпа.

>>Кстати, говнокодерам пох, на чем писать.

>не совсем. на LISP, например, не пишут. %-)

Говнокодеры не выбирают инструмент - им пох, они напишут на том, что им дадут. Или на том, что попадется под руку.

А с Лиспом всего 2 проблемы - ублюдочный синтаксис и отмороженные на всю голову фанбои ;)

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