Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Киса, какие конструкторы, i in [s] для константного S компилируется в простую проверку i-го бита у константы.
Это как лиса и виноград, сишники сочиняют сказки о неоптимальности конструкций, которых у них нет.
Вы так утверждаете, что как будто в Си нельзя так сделать. Можно создать эту табличку, только потребность в этом не настолько велика ,чтобы делать это как в паскале. Иными словами в подавляющем числе случаев имеются более подходящие решения.
Конечно, можно.
Берёшь, и пишешь
if ((1 << i) & ((1 << 32)|(1<<48)|итд))
Только писанины намного больше.
Ещё можно написать так:
case i of
65533, 65534, 65535: begin
...
end;
end;
>В Delphi это не скомпилится. Только для перечислимых типов и чисел до 255.
>Хочешь больше - используй свои карты.
В С++ так же можно. 🙂
Раз есть ограничение в 255, то скорее всего и там и там придётся писать велосипед, так что эта дельфовская возможность не защитана...
Тем более, в С++ есть готовые удобные оптимизированные и проверенные годами тестирования и эксплуатации библиотеки.
В дельфи, если и удастся найти компонент, то он будет очень не проверенный и написаный абы как. (Так называемая проблема языка из не крупнопроизводственных отраслей).
>в С++ есть готовые удобные "библиотеки".
Оговорился. Не только С++, а во всех крупнопроизводственных меинстримовых языках (к коим дельфи, наверное к счастью, не относится).
Впрочем, думаю, это было и так понятно, извиняюсь за КЭПерство.
Да. Лучше просто его выкинуть и переписать полностью заного, если понадобится его отрефакторить или найти в нём ошибки. Многостраничные кейсы разрушают нервные клетки быстрее, чем те успевают востанавливаться. Понимаю. 🙂
Дельфи7 действительно УГ, даже битовые сдвиги неправильные делает. Но проблема в том, что большая часть сишников делится на 2 группы - те, кто думают, что Паскаль - это только Д7 (Пушков из таких), и ещё более дремучие, кто думает, что Паскаль - это ТП7.
На самом деле Паскаль, как язык, превосходит Си/Си++ во всех отношениях. То, что слов больше надо писать - это полная фигня по сравнению со временем отладки. Отсутствие мощных оптимизирующих компиляторов - тоже не вина языка.
Распространение Си - это большая историческая ошибка. Надо было убить Ритчи в 70м.
Разница в производительности такая только из-за политики Ботланда. Паскаль - это не скриптовый язык с динамической типизацией, у него нет объективных причин тормозить.
>На все символы однострочных функций не напасёшься.
Тем более, что это не требуется. Если нужен конкретный символ, то его и следует проверить, обычным символьным сравнением, а не через ascii-коды. А если нужен диапазон, то в адекватных случаях используются функции, о которых я говорил выше.
Такие же варианты как в ГК или в твоем примере изобилуют магическими числами, что не есть гуд.
лол) а какого болта прогер должен об этом задумываться? есть инварианты 'a' < 'b' < ...< 'z' и они должны выполняться независимо от того, как они хранятся.
>Такого не видел, но мне интересно. Давайте порассуждаем.
в лингвистике как бы не поощряется рассуждать. это вполне формально определенная область.
1) конечно есть. любой язык имеющий алфавит (с логографией отдельные истории). все идет с времен зарождения письменностей, когда литерам соответствовали еще и числовые значения. следовательно, порядок следования важен или господа отрицают, что числовые множества обладают отношением порядка?
странно, что многие не стесняясь называющие себя программистами, не знают даже тривиальных основ лингвистики.
2) по большому счету эти величины не могут быть сравнимы, т.к. принадлежат разным множествам. но на практике это может быть реализовано, например в соответствии с ISO-14651 / DUCET
1) 'a' < 'b' это и в pure c верное выражение
2) проблемы разработчиков платформ. если не способны для алфавита реализовать отношение порядка, нечего им в этой профессии ошиваться.
В С 'a'/'b'/etc это есть просто целочисленные константы, со значением соответствующим коду символа в ASCII. (В С++ - char константы, но с тем же значением.)
"2)ое не верно, т к для национальных алфавитов аски не стандартизирует такое."
верно, потому что по стандарту ты и не можешь написать например 'ё'. С и С++ гарантируют только ASCII. в новых версиях языков для этого есть U'~'/L'~' (U'' - 32bit Unicode, L'' - 16bit Unicode).
Для С, смотри в стандарте 6.4.4.4 - Character constants. Для С++ - 2.14.3 - Character literals. К слову, рекомендую почитать, сам много нового узнал 😉
>ты и не можешь написать например 'ё'
Что-то мне кажется, что могу.
Даже если не могу, но в char лежит "йо" и мне его надо сравнить с другими символами, то что тогда? Где выполняется?
Или Вы предлагаете выкинуть интернациональные кодовые страницы только из-за того, что в Си по стандарту только ASCII?
ага. куча ненужного копирования. два ненужных (пере)выделения памяти. потому что в XML в принципе только три символа имеют специальное значение: &, >, <.
ну и самое главное достижение этого кода: превращение utf-8 в мусор. как собственно этот шедевр и попал мне на радар.
(ascii >= 48 && ascii <= 57) ||
(ascii >= 65 && ascii <= 90) ||
(ascii >= 97 && ascii <= 122) ) )
Бедняги, у них же нет возможности написать
if not (ascii in [32, 48..57, 65..90, 97..122]) then...
А попки у сишников болят, я смотрю... Больной вопрос у них - убогость некоторых конструкций.
Это как лиса и виноград, сишники сочиняют сказки о неоптимальности конструкций, которых у них нет.
да ты что?
Т.е. if (65534 in [65533, 65534, 65535]) будет создавать в памяти константу на 64 кбит?
Это не скомпилится. Только для перечислимых типов и чисел до 255.
Хочешь больше - используй свои карты.
Либо пиши
if i-65500 in [33,34,35]
Берёшь, и пишешь
if ((1 << i) & ((1 << 32)|(1<<48)|итд))
Только писанины намного больше.
Ещё можно написать так:
case i of
65533, 65534, 65535: begin
...
end;
end;
1,2, 512, 30000..32000, 12541212..12545000: begin
end;
end;
>Хочешь больше - используй свои карты.
В С++ так же можно. 🙂
Раз есть ограничение в 255, то скорее всего и там и там придётся писать велосипед, так что эта дельфовская возможность не защитана...
Тем более, в С++ есть готовые удобные оптимизированные и проверенные годами тестирования и эксплуатации библиотеки.
В дельфи, если и удастся найти компонент, то он будет очень не проверенный и написаный абы как. (Так называемая проблема языка из не крупнопроизводственных отраслей).
Оговорился. Не только С++, а во всех крупнопроизводственных меинстримовых языках (к коим дельфи, наверное к счастью, не относится).
Впрочем, думаю, это было и так понятно, извиняюсь за КЭПерство.
Ага,
if ((1 << i) & ((1 << 32)|(1<<48)|итд))
не удобно, но без глупых ограничений...
можно еще тоже самое сделать на битовых таблицах, будет медленнее но съест меньше памяти и опять таки без ограничений
Чем не стандартное средство? 🙂
Часто такое решается на более высоком уровне, например фабриками или полиморфизмом.
Эта конструкция просто становится не нужна.
А если Вам понадобиться исправить этот код в будующем - с вашим подходом потратите несколько недель, отлаживая код и разбираясь в нем.
Но вот вместо if ((i > 1 && i<1000) || итд
куда проще сделать нормальный паскалевский case
if i in [float(x*y+x/y) for x in range(0,10,2) for y in range(2,5)]:
что еще раз доказывает что паскаль - говно!
Откуда такие цифры? Всё зависит от задачи, компилятора и метода её решения.
На С++ можно так наговнякать... И легче, чем в дельфи.
цифра от Тараса, он в последнее время жирнеет продвигая делфи...
Помоему он просто над нами стебётся, естественно зная, что дельфи УГ.
На самом деле Паскаль, как язык, превосходит Си/Си++ во всех отношениях. То, что слов больше надо писать - это полная фигня по сравнению со временем отладки. Отсутствие мощных оптимизирующих компиляторов - тоже не вина языка.
Распространение Си - это большая историческая ошибка. Надо было убить Ритчи в 70м.
Изобретите машину времени и исправьте эту досадную ошибку. 😀
>На самом деле Паскаль, как язык, превосходит Си/Си++ во всех отношениях
Вывод из ваших слов:
Си++ - УГешное УГ?
😀
Тем более, что это не требуется. Если нужен конкретный символ, то его и следует проверить, обычным символьным сравнением, а не через ascii-коды. А если нужен диапазон, то в адекватных случаях используются функции, о которых я говорил выше.
Такие же варианты как в ГК или в твоем примере изобилуют магическими числами, что не есть гуд.
Инварианты такие от лукавого, особенно для символов, не принадлежащих латинице.
1)Есть ли такие языки, где это реализовано, при этом для различных лингвистических языков и для разных платформ?
2)Как выглядит такой инвариант при сравнении, скажем, 'а' и 'A' или латинской 'A' и русской 'А'?
(xXx_totalwar, Вы, наверное, помните о моём хобби, поэтому знаете, что мне это может пригодиться. 🙂
в лингвистике как бы не поощряется рассуждать. это вполне формально определенная область.
1) конечно есть. любой язык имеющий алфавит (с логографией отдельные истории). все идет с времен зарождения письменностей, когда литерам соответствовали еще и числовые значения. следовательно, порядок следования важен или господа отрицают, что числовые множества обладают отношением порядка?
странно, что многие не стесняясь называющие себя программистами, не знают даже тривиальных основ лингвистики.
2) по большому счету эти величины не могут быть сравнимы, т.к. принадлежат разным множествам. но на практике это может быть реализовано, например в соответствии с ISO-14651 / DUCET
Вы же понимаете, что я жду примера языка программирования, где реализован данный порядок?
>'a' < 'b' && 'b' < 'c'
2)Подобное сравнение верно и для национальных алфавитов на всех платформах?
2) проблемы разработчиков платформ. если не способны для алфавита реализовать отношение порядка, нечего им в этой профессии ошиваться.
Насколько я помню, в стандарте языка Си это не указано, значит не верное.
В С 'a'/'b'/etc это есть просто целочисленные константы, со значением соответствующим коду символа в ASCII. (В С++ - char константы, но с тем же значением.)
Верно лишь утверждение 1)
2)ое не верно, т к для национальных алфавитов аски не стандартизирует такое.
верно, потому что по стандарту ты и не можешь написать например 'ё'. С и С++ гарантируют только ASCII. в новых версиях языков для этого есть U'~'/L'~' (U'' - 32bit Unicode, L'' - 16bit Unicode).
Для С, смотри в стандарте 6.4.4.4 - Character constants. Для С++ - 2.14.3 - Character literals. К слову, рекомендую почитать, сам много нового узнал 😉
Что-то мне кажется, что могу.
Даже если не могу, но в char лежит "йо" и мне его надо сравнить с другими символами, то что тогда? Где выполняется?
Или Вы предлагаете выкинуть интернациональные кодовые страницы только из-за того, что в Си по стандарту только ASCII?
ЗЫ гугл, искать "мак буква ё" - альтернативная раскладка с буквой ё.
а так на говнокод не тянет. задора нет
ну и самое главное достижение этого кода: превращение utf-8 в мусор. как собственно этот шедевр и попал мне на радар.
> - ??!
o_O
Планету Нибиру на говнокод, срочно!
А я-то, наивный, всю сознательную жизнь думал, что 0°K - это абсолютный ноль, так сказать...