динамические строки Си. Реинкарнация

Что твой велосипед вернёт для «I»? «i» или «ı»?

все интересующие тебя сочетания можно увидеть тута и здеся

я утверждаю бессмысленность этого действия с точки зрения языка

Вообще-то «grep -i» актуален как раз с точки зрения языка. Попробуй представить себе поиск в интернете, где тебе надо фразу набрать именно так, как она на сайте с учётом регистра

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

немцу тоже надо, чтобы на поиск «Panzerarmband mit Gravurflache» в выборку попадало и «PANZERARMBAND MIT GRAVURFLACHE»

Ты предлагаешь использовать undefined behavior.

вероятно, с точки зрения стандарта это UB (в чем я сомневаюсь, но доказать не могу, т.к. стандарт наизусть не зубрил), но увы — каждая вторая сишная программа использует подобные штуки, и если компилятор не может программу правильно собрать — это его проблемы, и использовать его врядли кто-то станет.

Именно. Мало того, что у нас три кейса засчет диграфов, так еще и отображение в каждый из них недетерминированное и необратимое. А все потому, что уникод ни в одном месте не панацея и не лингвистический модуль, когда речь идет о преобразованиях регулярного текста. Для всего остального есть весьма четкий ascii.

все интересующие тебя сочетания можно увидеть тута

Вижу: I, «i». Так вот, хочу заметить, что в турецком языке такая ошибка может привести к смерти: http://telecom.cnews.ru/news/top/sms_ubivayut_lyudej

понятно. сегодня же удалю проект с гитхаба, и у себя с диска, и сожгу бэкапы.

вероятно, с точки зрения стандарта это UB (в чем я сомневаюсь, но доказать не могу, т.к. стандарт наизусть не зубрил),

Почитай http://habrahabr.ru/post/229963/

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

Код с UB успешно выпиливается и gcc и (ещё больше) clang. Хочешь сказать, что их никто не использует?

Код с UB успешно выпиливается и gcc и (ещё больше) clang. Хочешь сказать, что их никто не использует?

все мои программы, которые, на твой взгляд, напичканы UB, собираются gcc и clang, и замечательно работают.

тот пример, что приведен на хабре — действительно UB, и может привести к подобной оптимизации.

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

Ему также надо, чтобы поиск складывал/раскладывал дифтонги и вообще искал без диакритики, поскольку она мерцает в словоформах. Топорный ловер тут никаким боком, он решит лишь ползадачи. Я не в курсе, что именно делает grep -i в немецкой локали, но если это Das richtige Ding, то Respekt ему \о

и не имеет никакого права применять подобные оптимизации.

Он имеет право применять оптимизации к массиву data. Там заведомо можно прочитать только один элемент.

Или читать такую «строку» придётся через (char*)d[i+2*sizeof(size_t)], а не d.data.

Можешь объяснить почему не переходишь на юникод?

Потому же, почему езжу на автомобиле, а не скаковой корове. Каждой задаче — свой инструмент.

Боишься, что символы будут занимать в 2 раза больше памяти?

Хуже: размер памяти под текст вообще неизвестен будет! Нафиг-нафиг!

Он имеет право применять оптимизации к массиву data. Там заведомо можно прочитать только один элемент.

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

О чем только не поспорят, лишь бы не юзать валидный char data[].

Нормальным строкам не хватает поля «размер», что бы strlen был О(1)

Не понял, как связаны два наших коммента, но мне вдруг стало интересно, сколько раз ты при profile-guided оптимизации находил strlen-like код в списке горячих точек? :)

Неизбежно, и нормально. В своё время мне нравилось смешивать функции на C с функциями, написанными на asm, собирать их отдельно, разными компиляторами и затем линковать.

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

Всё верно учит, широко используемая практика едва ли не с начала времён. В том же winapi, который работает очень таки шустро, в отличие от всяких Qt и Gtk подобное сплошь и рядом. Язык он чтобы не дрочить ,а чтобы писать.

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

все мои программы, которые, на твой взгляд, напичканы UB, собираются gcc и clang, и замечательно работают.

С -O2 или -O3 собрать пробовал?

Хуже: размер памяти под текст вообще неизвестен будет! Нафиг-нафиг!

никто не заставляет хранить текст в оперативной памяти в виде UTF-8 или чего-то подобного, можно же использовать строки вида uchar* подобно сишным char* (где uchar - некий тип, хранящий юникодный символ), наверное.

Всё верно учит

автор спорного предложения собственно признал, что написал неподумав. Вы тоже не приходите в сознание в комментариях? :-)

Прихожу переодически:)

вот будучи в сознании, критично рассмотрите ту структуру - это довольно интересно :-)

Нафиг оно мне нужно? Обрабатывать строки мне нужно в трех случаях: JSON на клиент-серверных, POST/GET от браузерного клиента, поток данных от мелкоконтроллера. В последнем случае вообще нафиг не нужен КОИ-8 — все тупо в ASCII гонится или бинарными network order. А в первых двух случаях тоже надобность в кириллице крайне редко возникает. Ну и нафиг мне париться? Я вообще принципиально тупо в ASCII могу при желании работать…

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

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

В C99 можно использовать [] для последнего элемента в структуре (6.7.2.1, п.16). А до этого GCC допускал, если использовать [0].

Вот и точное пояснение подтянулось. Спасибо.

К слову, после того, как я нарвался на то, что STM8 big-endian (а до этого как-то думал, что тупо код с STM32 можно в легкую портировать на STM8), стал к порядку байт серьезней относиться. Особенно если это — сетевое взаимодействие (мало ли, что за клиент будет — вдруг он вообще mid-endian?).

молодец, выучил новые слова - возьми пирожок!

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

Легко эту ситуацию представить: man arduino. Если раньше был только диагноз «атмель головного мозга», сейчас еще один похуже появился — «ардуйня головного мозга». В первом случае больной все пытается решить ногодрыгом и быдлокодом, несмотря на тог, что можно в легкую сделать на основе готовых библиотек и аппаратных решений; во втором же больной вообще не представляет, как этот «чОрный ящик» работает, а тупо наугад собирает с миру по нитке...

Тебе это в легкую, а человеку, всю жизнь писавшему под десктопы и только копающему под микроконтроллеры, пипец как тяжело. Куда из гугла ни зайдешь, везде непонятные местечковые переговоры на инопланетном, замкнутые ниши, и ни одного обзора для тех, кто программить умеет, а паять — нет. Ардуина эту нишу как раз и закрывает, афаик (хотя я глаз пока положил на ESP). Как многим пофигу, что их скрипт тянет за собой питон с линуксом, так многим и пофигу, что их лампочка включается через целую ардуйню с чьим-то быдлокодом. Это куда проще, чем ради нового хобби взаимодействовать с занятым «эмбедщиком от рождения». Советуй тогда овервью на широкие решения, раз уж зашло :)

Ну согласен, даже сталкилвался немного с ардуинниками. Но всё таки надо как-то отделять программистов от вот таких вот людей. Да, есть такие люди, которые пытаются даже какой-нибудь libjpeg скомпилять и загрузить в fpga с помощью ковертирования из С в какой-нибудь verilog, а потом как-то этот весь мрак ещё синтезировать:)

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

Так он не об этом вроде:) Да, бывают люди осуждают за избыточность. Но это так себе осуждение, десктопы можно запросто за тоже самое обругать:) Речь про то, что люди не вникают даже в возможности платформы, а потом плачут почему в моём любимой железяке не хватает памяти и тд. Хорошо то, что сейчас постепенно этой нише контроллеры замещаются полноценными процессорами от arm, на них можно уже расслабиться. Да, пока дороже, но тем кто платит за ардуино это ерунда.

С -O2 или -O3 собрать пробовал?

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

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

что glib не самая портабельная библиотека

Да вроде того же gtk где только нет

Да вроде того же gtk где только нет

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

его на андроид хотя бы портанули?

А оно там нужно?

Забавно, кстати. Я сам недавно стал обладателем андроид устройства. Так вот программы, откомпилированные под демьян, запускаются на телефончике вообще без проблем. Архитектура одна и та же.

Мы вроде о портабельности, а не о нужности. Glib мог бы быть полезен.

А я в таких случаях обычно делаю char data[0]. Заодно sizeof возвращает размер заголовка без данных, что удобно.

Люди, которые из-за одной строчки готовы убить, не нужны. Если речь не идёт, конечно же, о военном приказе.

то вместо рекомендации вы могли бы помочь его развитию

задонанить ТСу на курсы английского?

Для безграмотного анонимуса у меня есть два слова: нормализация и кейсфолдинг.

Я бы, наверное, убивал за size_t в качестве типа для храниения длины, ну и за касты void* тоже убивал бы.

glibc'шная версия strlen работает весьма шустро, чтобы париться из-за кэширования размера. Поэтому для обычных ситуаций можно смело пихать стрлены везде, где хочется.

Как ты такой дохуя грамотный пропустил вот это:

But this isn't a general solution. While true for German, in Finnish the diaerisis marked characters cannot be converted to the base letter followed by 'e': the diaerisis doesn't have the same interpretation in that language.

Что возвращает нас к локали и недетерминированности ловера. Или ты вообще не в курсе темы беседы, чисто понтов швырнуть зашел?

Я бы, наверное, убивал за size_t в качестве типа для храниения длины

Ясн.

задонанить ТСу на курсы английского?

Если на иное вы не способны, то можете задонатить.