Концепция имен указателей

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

 

Этот вариант взят из книги человека который принимал ANSI/ISO стандарт С++.

Это не говнокод, а не дописанный вариант, но корректно работающий с ANSI, бред не пишите.

 

И что? Это как-то отменяет тот факт, что 0xDF лучше показывает нам битовую маску для операции and, чем 223?

В какой кодировке? CP-1251? KOI-8? KOI-8R? CP-866? Ведь в каждой из этих таблиц символы с кодами больше 127 различаются (оставаясь при этом все той же кириллицей).

 

Показало это hex число битовую маску и что это вам дало?

 

Более лучшую читаемость кода. Разве не к этому все должны стремиться?

 

rmn, прочитали вы битовую маску и? Понимаю когда у сравниваемого есть битовая маска, то да, польза, а так это вам ничего не дает ровным счетом, что приводит к заведомо логическому выводу: не нужно.

 

Ronin_,
К чему эти нелепые отмазки? Ведь всем уже очевидно, что ты не прав. Разве так сложно это признать?

 

rmn, кому всем? В чем я не прав я уже описал, а вы почему не пишите сейчас что избыточна hex маска?

 

Кстати, по-поводу "inline" из примера выше и всех терок по поводу скорости отсюда же.

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

А по скорости оптимизацию провожу постфактум, используя gperf. Всегда приятно, подсказав компилятору что вот эта ветка условия выполняется явно чаще, чем вот эта, получить двукратное ускорение цикла.

 

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

 

Если он - "Лад", то супруга - "Ладья",
Ежели - "Поп", то жена - "Попадья"...
ASM под DOS - ожидай попандос,
Жуть, - не игра, если из-за бугра.

 

От неча делать решил по-поводу оптимизации еще немного отписаться.

Берем два варианта кода, оптимизированный и просто читабельный, разбитый на функции (все выше в топике) и сравниваем собранные результаты:

Код (C):

1.  
2. // 1:
3. bool non_character(char ch)
4. {
5.   return ch < 0;
6. }
7. bool uppercase(char ch)
8. {
9.   return ch >= 'a' && ch <= 'z';
10. }
11. bool lowercase(char ch)
12. {
13.   return ch >= 'A' && ch <= 'Z';
14. }
15. // бывший checkrange()
16. bool is_valid_character(const char ch)
17. {
18.   return non_character(ch) || lowercase(ch) || uppercase(ch);
19. }
20.  
21. // 2:
22. bool checkrange(const char ch)
23. {
24.   if(ch < 0 || ((ch > 64 && ch < 91) || (ch > 96 && ch < 123)))
25.     return true;
26.   else
27.     return false;
28. }
29.  

====> x86-64 gcc 7.1

Код (ASM):

1.  
2. is_valid_character(char):
3.   test  dil, dil
4.   mov  eax, 1
5.   js  .L5
6.   and  edi, -33
7.   sub  edi, 65
8.   cmp  dil, 25
9.   setbe  al
10. .L5:
11.   rep ret
12.  
13. checkrange(char):
14.   test  dil, dil
15.   mov  eax, 1
16.   js  .L8
17.   and  edi, -33
18.   sub  edi, 65
19.   cmp  dil, 25
20.   setbe  al
21. .L8:
22.   rep ret
23.  

Как видно, скомпилированные функции вышли полностью идентичными.
Спасибо этому сервису.