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

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

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

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

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

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

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

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

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

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

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

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

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

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

I hereby pronounce you guilty in having side effects!

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

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

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

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

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

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

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

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

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

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

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

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

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

>I hereby pronounce you guilty in having side effects!

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

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

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

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

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

Пятницо ест твой мозг, анонимный собрат! К 12 ты осознаешь файловость идеи ЭВМ :-Р

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, кстати аппаратная поддержка 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

сказочный долбоёб. (ц)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>Тебе объяснили, что парсить всю строку неэффективно,

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

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

Сам дурак. :p

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

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

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

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

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

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

школиё.