ЗАДАЧА А
Есть функция (K&R), которая обращает порядок символов в строке. Вот она:




Вопросы:
1. Какие слабые места у данной реализации.
2. Как можно оптимизировать код. И что конкретно это даст.
3. Какие есть варианты реализации функции.

Спасибо!

В коде ошибка поставьте j--

да ,сори.

ЗАДАЧА Б
Есть реализация функции перевода "типа" bool в строку.



Вопросы:
1. Какие слабые/ошибочные места у данной реализации.
2. Как можно оптимизировать код. И что конкретно это даст.
3. Какие есть варианты реализации функции.

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

По задаче Б.
переменная типа bool принимает значение 0 и !0 (не 0). В зависимости от реализации компиляторе !0 может выглядеть любым целым числом, поэтому "Out Of Range" - некоррекное заявление.

Неправда! Область значений, согласно stdbool.h -это true,false. Отсюда

Исходя из того, что в Си bool это всего лишь костыль для пришедших из других языков, и любое не 0-ое значение является истиной для условных операторов, то, ИМХО редактор прав.

Задачу А можно оптимизировать сильнее всего исходя из контекста.

if(0) - выражение в скобках сейчас == 0
if(!0) - выражение в скобках сейчас == 1
Ы?


Работа непосредственно с двумя указателями выигрывает на любых pic/avr/arm/x51

В задаче А вижу только один недостаток - это нет проверки на пустую строку. Если длина будет 0, то произойдёт переполнение и запись за пределы строки. По производительности тоже проблем не наблюдаю - можно было бы сделать какой-нибудь ассемблерный SWAP или хотя бы промежуточную переменную поместить в регистр, но это от архитектуры зависит.
В задаче Б всякая жесть. Тип заявлен bool, а передаётся char. Сравнение почему-то с 0 и 1, хотя false и true может быть определена иначе. Нужно сравнивать с настоящими false и true, теми которые используются вашим компилятором.

грубовато...

Ага, щаз! А если b например... b=0x0C

Я имел ввиду немного другое

Какая ветка условного оператора будет выполнена? Третьего "outofrange" не дано, увы.

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

Ну так я и сказал что грубовато

В армоводческом смысле reverse() с указателями

Моё ИМХО: в нынешней реализации Си тип 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" это пустой массив для записи строки в обратном порядке.
За счет использования второго буфера резко увеличивается скорость собственно операции.

по поводу тройной пересылки мы еще поговорим, а вот второй буфер не айс однозначно. во первых 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. Только штука в том, что здесь из простейшего произрастают интересные вещи. Довольно часто.

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

Профит есть 2 строчки кода с хорошей читаемостью вместо 6..9 строк кода в другой реализации.
Вы это поймёте, когда будете писать большие программы, в которых становится важна не только выразительность отдельно взятой процедуры, а модуля целиком... Всему своё время.

Кстати В этом кусочке кода три ошибки (три лишних символа &).
А вы говорите хорошая читаемость... Чем лаконичнее, тем ИМХО профессиональнее.

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

Чо там пилить?

Упс... может, они это имели в виду, что при передаче не-указателя не нужно его проверять?

Я бы поспорил насчет в два раза, и про место под буфер
Так что удачи...

Давайте в первом чтении вот такую версию ЗАДАЧИ А от _Pasha обсудим?

Для нелюбителей тройных пересылок есть одна бяка

Строка "сползает", но ее можно искусственно расширить и передать указ. не на начало, а на s[1]
Бред, в общем случае, но.. если у нас не char а нечто более существенное, пересылки могут доставить
ЗЫ вот только для чего эти сферокони, не пойму

Так вы потеряете первый символ строки... и т.д.
++ инкрементирует указатель после использования.

А не надо его терять. Первый символ !=0 и всё, а сама строка начинается со второго. Ассемблерные заморочки
Кстати, такая штуковина со "сползанием и перестановкой" может в графике пригодиться

Т.е. начать переносить на 1 символ левее строки? Тогда в середине появится разрыв.
По-моему, без промежуточной переменной - никак!

Вот немного "заоптимизировал". Теперь переменной "с" нет, но есть 3 дополнительные арифметич. действия. Какие есть мысли, соображения? Спасбио!

Ага, ошибочка вышла. Да простит меня высокое собрание.


На общеприменяемых архитектурах будет хуже. Потому что "лишний" char c есть регистровая переменная. А так - добавляются операции, такие же переменные неявно выделяются компилятором, но самое обидное будет если у нас не char, а long например.
В принципе, вместо + - как у Вас надо бы

с исключающим или мне не очень, хотя красиво конечно a ^= b ^= a ^= b;

Вот еще вариантец, только проверить нужно. Кстати как можно простенькие такие программки потестить? Например в самом ИАРе? Как в отладочное окно выводить результаты всяких printf? Спрашивал однажды и запамятовал к сож(

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

У меня три вивария, с чем работаю, симуляторы
1. C::B + Proteus для аврок - всё в два клика, но создать проект под АРМ - муки творчества, ибо визардов нормальных нету, поэтому
2. Кейл, там тоже элементарно, исключительно из-за stm32 и at91sam7s
3. Mplab
Сыр-бор весь только чтобы глянуть листинг.

UB на двух записях в a в переделах sequence point. Правильно так, как было написано сначала, в три строки. Можно записать в две, но это уже неинтересно.

Вам так хочется UB-иться?
UB на произвольном порядке вычисления подвыражений (тут возможность записи в *end в скобках в правом аргументе операции вычитания до того, как будет прочитано *end в левом операнде).

Что еще за UB? Мы ж так не UBьемся!
Последовательность операций в a ^= b ^= a ^= b; определена точно. Справа налево.

что такое UB? что такое в пределах sequence point?
a ^= b ^= a ^= b;
сначала выполнится a ^= b ,затем b ^= a и в конце a ^= b по идее все верно. Нужно проверить.



тут мне кажется что однозначно от старого *end новое отнимется ,но снова вынужден признать- необходимо проветить

Да вроде всегда была определена последовательность вычислений, но не последовательность записи результатов.
Так как значением выражения (a = B) является не «содержимое а после записи», а «значение b приведенное к неквалифицированному типу а».
А (a ^= B) это «то же, что и (a = a ^ B), за исключением того, что a оценивается один раз»
А порядок записи в пределах между точками следования неопределён.

Но что-то меня LWS поколебал...

http://liveworkspace.org/code/Ll7BX$13

gcc по 4.6.3 выдаёт

в режимах и C, и C++, gcc 4.7.2 только в режиме C, но не в C++

clang 3.2 доволен всем.

Для меня это новость. Первое (и последнее -- больше так не баловался) предупреждение на a ^= b ^= a ^= b; я получил как бы не от BCC5 уже не помню как давно. Почитал стандарт. Вроде понял :-)

Что касается *beg += *end - (*end = *beg);, то все компиляторы единодушны -- UB (undefined behavior).


«тут мне кажется», что Вы рано за такие оптимизации взялись :-)

Sequence_point популярно для начала.

Гнаться за мнимым весом строки - позор