[msalov 0]

Дык это несовместимость типов. :laughing: Почему к случаям явного приведения int к указателю всегда люди относятся настороженно, а к "притягиванию" bool к char - типа что это нормально?

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

[Herz 5]

Вопросы:

1. Какие слабые/ошибочные места у данной реализации.

2. Как можно оптимизировать код. И что конкретно это даст.

3. Какие есть варианты реализации функции.

 

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

[ReAl 0]

Моё ИМХО: в нынешней реализации Си тип 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++.

[Буратино 0]

В смысле AVR, может выглядеть так

 

#include <avr/io.h>
#include <string.h>
void reverse(char s[])
{
   char *beg = (char *)&(s[0]);
   char *end = (char *)&(s[strlen(s)]);
   while(beg < end)
   {
       char c = *beg;
       *beg++ = *(--end);
       *end = c;
   }
}

 

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

char *beg = (char *)&(s[0]);
char *end = (char *)&(s[strlen(s)]);
*(--end);

 

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

*(--end);

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

 

А какой смысл объявлять и инициализировать "с" внутри операторного блока while?

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

 

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

[msalov 0]

Выбираю текст для тату, а что?

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

[MrYuran 21]

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

*(--end);

Во-первых, пишете (изъявительное наклонение вместо повелительного)

А во-вторых, я однажды написал

* temp ++ ;

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

[Буратино 0]

Во-первых, пишете (изъявительное наклонение вместо повелительного)

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

 

А во-вторых, я однажды написал

* temp ++ ;

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

 

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

[telix 0]

Я б пример А оптимизировал за счет второго буфера.

То есть не делал тройную пересылку a=>c b=>a c=>b

а однократную b[j--] => a[i++] но при этом a и b это разные массивы

"b" это исходная строка, "a" это пустой массив для записи строки в обратном порядке.

За счет использования второго буфера резко увеличивается скорость собственно операции.

Изменено 25 января, 2013 пользователем telix

[Буратино 0]

Я б пример А оптимизировал за счет второго буфера.

То есть не делал тройную пересылку a=>c b=>a c=>b

а однократную b[j--] => a[i++] но при этом a и b это разные массивы

"b" это исходная строка, "a" это пустой массив для записи строки в обратном порядке.

За счет использования второго буфера резко увеличивается скорость собственно операции.

 

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

[_Pasha 0]

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

 

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

 

А какой смысл объявлять и инициализировать "с" внутри операторного блока while?

 

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

1. Во-первых, без скобок оно не работало, во вторых, имею недостаток в виде "хронического плавания " в приоритетах, тк Си "не родной язык", по сему не брезгую лишними скобками, тем более, что в 80% случаев это правильный подход.

2. MrYuran ответил, именно после его сообщения, не помню когда и не скажу где :) этот случай навечно впечатался в мозг. А делов-то всего пробел...

3. Как-раз смысл произошел из давних разговоров о свойствах GCC, что чем больше нагрузки на локальные переменные, тем будет правильнее. Листинг AVR это демострирует

4. Прототип функции кривоват, т.к. выпадает из общепринятой практики и заставляет задуматься о языке а не о том, что нужно.

[ViKo 1]

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

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

 

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

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

А Буратино может набить себе тату - таблицу с приоритетами. Лучшего вряд ли можно посоветовать! :rolleyes:

[Буратино 0]

1. Во-первых, без скобок оно не работало, во вторых, имею недостаток в виде "хронического плавания " в приоритетах, тк Си "не родной язык", по сему не брезгую лишними скобками, тем более, что в 80% случаев это правильный подход.

2. MrYuran ответил, именно после его сообщения, не помню когда и не скажу где :) этот случай навечно впечатался в мозг. А делов-то всего пробел...

3. Как-раз смысл произошел из давних разговоров о свойствах GCC, что чем больше нагрузки на локальные переменные, тем будет правильнее. Листинг AVR это демострирует

4. Прототип функции кривоват, т.к. выпадает из общепринятой практики и заставляет задуматься о языке а не о том, что нужно.

 

Хорошо ,мне нравится ваш вариант с указателями давайте его допилим и перейдем ко второй задачке!?

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

 

char *beg = (char *)&(s[0]);

[MrYuran 21]

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

жи это жи, а ше это ше )

Насчет скобок - лучше явно указать.

И самому спокойнее, и читателю понятнее будет.

[_Pasha 0]

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

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

--

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

 

[Буратино 0]

жи это жи, а ше это ше )

Насчет скобок - лучше явно указать.

И самому спокойнее, и читателю понятнее будет.

 

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