Моё ИМХО: в нынешней реализации Си тип bool не имеет смысла, т.к. операнды операций равно/неравно не приводятся к одному типу (bool), а используются как есть. Вот и получается что 42 != true, а (bool)42 == true в зависимости от компилятора

Буратино, сообщите нам смысл Ваших вопросов. Что конкретно их породило?

(Не понял, почему операнды в выражении (0.5 != 'A') должны приводиться к bool)

Это тоже не должно зависеть от компилятора. Т.е. если у конкретного компилятора «зависит», то он не соответствует стандарту.

В выражении, ну пусть уж (42 != true), операнды используются не «как есть», а приводятся к int.
Была бы она твёрдая — я бы её жевал Было бы 42UL, тогда бы true приводилось бы к unsigned long int :-)

Но зато вот (42 != true) имеет значение true и в
bool b = 5;
в переменную будет занесено 1 даже в C99 c <stdbool.h>, не говоря уже о C++.

А зачем тут скобки?


А почему вы пишите

Это с терминатором строки связано?

А какой смысл объявлять и инициализировать "с" внутри операторного блока while?
Как Вы думаете, что передается в функцию: массив или строка? Мне кажется что не очень корректно формальный аргумент сотрица, ну как будет тот-же strlen с массивом то? Может правильнее описать аргумент так: char * s ?

demiurg_spb, мне не очень понравилось. читаемость отвалилась, а скилов не добавилось как по мне.

Может тогда что из победителе The International Obfuscated C Code Contest выберете

Во-первых, пишете (изъявительное наклонение вместо повелительного)
А во-вторых, я однажды написал
* temp ++ ;
имея в виду инкремент значения по указателю, а потом долго не мог понять, почему это "бесполезная операция", с т.з. компилятора.

а как же жи ,ши через и?



* temp++ сначала плюсанется указатель, а затем получим значение по плюсанутому указателю ,постави(е)те скобки и все будет так как запланированио, но в нашем то случае именно что и не нужны они! Я так думаю

Я б пример А оптимизировал за счет второго буфера.
То есть не делал тройную пересылку a=>c b=>a c=>b
а однократную b[j--] => a[i++] но при этом a и b это разные массивы
"b" это исходная строка, "a" это пустой массив для записи строки в обратном порядке.
За счет использования второго буфера резко увеличивается скорость собственно операции.

Сообщение отредактировал telix - Jan 25 2013, 09:31

по поводу тройной пересылки мы еще поговорим, а вот второй буфер не айс однозначно. во первых b[j--] => a[i++] в 2 раза больше нужно а во вторых место под буфер.

1. Во-первых, без скобок оно не работало, во вторых, имею недостаток в виде "хронического плавания " в приоритетах, тк Си "не родной язык", по сему не брезгую лишними скобками, тем более, что в 80% случаев это правильный подход.
2. MrYuran ответил, именно после его сообщения, не помню когда и не скажу где этот случай навечно впечатался в мозг. А делов-то всего пробел...
3. Как-раз смысл произошел из давних разговоров о свойствах GCC, что чем больше нагрузки на локальные переменные, тем будет правильнее. Листинг AVR это демострирует
4. Прототип функции кривоват, т.к. выпадает из общепринятой практики и заставляет задуматься о языке а не о том, что нужно.

Я думаю не так.


Я выписал на листок приоритеты операций, и держу его перед мор над монитором. А иногда еще в текстовые файлы - заметки по проекту - вставляю. И теперь безошибочно пишу что-то вроде a << 4 | b;
А Буратино может набить себе тату - таблицу с приоритетами. Лучшего вряд ли можно посоветовать!

Хорошо ,мне нравится ваш вариант с указателями давайте его допилим и перейдем ко второй задачке!?
Итак: давайте формальный аргумент заменим на "char * s", это правильнее будет судя по всему. Раз так, то тогда зачем приводить &(s[0]); к (char *) да еще и скобки использовать!? Сначала индекс ,а только потом одноместные унарные!

жи это жи, а ше это ше )
Насчет скобок - лучше явно указать.
И самому спокойнее, и читателю понятнее будет.

Дык я это расцениваю(для себя) как write only style Тем более, не встречал случаев, когда лишние скобки влияют не результат.
--
Закномерность: чем более пустяковый вопрос, тем оживленнее тема. Насчет замечания Herz. Только штука в том, что здесь из простейшего произрастают интересные вещи. Довольно часто.

Нет, давайте так: в этих "задачках" сделаем все правильно ,а в жизни будем беспокоится о читателях. Ищу самую правильную и изящную реализацию, хочу вот именно так и не иначе.