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

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

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

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

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

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

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

bne 10$ ; not done

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

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

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

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

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

> Nero подойдет?

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

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

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

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

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

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

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

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

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

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

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

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

lods = *p++

inc [ebx] = (*p)++

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

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

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

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

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

Кстати, насчёт аппаратной поддержки 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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

You welcome!

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

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

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

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

Это был gaa

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

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

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

Я слежу :)

> "На 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 Си, а больше писать было и не на чем (да и сейчас тоже не на чем).

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

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

Замечание для всех, кто ругает 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 .

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

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

Клево.

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

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

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

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

> Это был gaa

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Жж0ш.

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

char *c = malloc(256);

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

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

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

> char *c = malloc(256);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

мимо кассы.

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

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

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

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

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

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

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

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

> мимо кассы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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