[C++] -1, если число отрицательное; 1, если положительное

Зависит от компилятор и может быть даже от процессора. Вообще, в моём представлении первое должно происходить без участия сопроцессора, а второе — с участием (если без оптимизаций), поэтому зависит от того, что быстрее.

А скомпилировать в асм-код лень? Просто там всё равно jump'ы будут.

П.С. return std::signbit(x) ? -1 : 1; П.П.С. кроме более читабельной записи надо следовать правилу, что желательно в функции иметь только один return

>А скомпилировать в асм-код лень? Просто там всё равно jump'ы будут.

Необязательно. man cmovcc

Просто там всё равно jump'ы будут.

Будут, но короткие:

знаковый бит старший. return reinterpret_cast<uint64_t>(x) & ((uint64_t)1<<63);

return -1 + (reinterpret_cast<uint64_t>(x) & ((uint64_t)1<<63)) >> 62;

а если big-endian?

return -1 + (*(reinterpret_cast<uint64_t*>(&x)) & ((uint64_t)1<<63)) >> 62;

>The CMOVcc instructions are new for the Pentium® Pro processor family; however, they may not be supported by all the processors in the family.

Так что gcc вряд ли будет его использовать. Да и потом, вроде как с double не должен работать (костыль то можно сделать, но без оптимизации вряд ли будет).

>>знаковый бит старший.

Хаха, такие спецы :) Он всегда старший хоть на мидлэндиан. Это всего лишь повлияет на то как данные хранятся в памяти.

:))))) а почему бы не просто:

Тьфу - понял, там надо -1 по условию :)

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

На x86 ?: в cmov завернётся.

> На x86 ?: в cmov завернётся.

А что с [code] return (x > 0 ? 1 : -1);[/code] ?

(Вариант x == 0 как я понял, считается несуществующим?)

> (Вариант x == 0 как я понял, считается несуществующим?)

может соответствовать или -1, или +1 — не важно

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

> надо следовать правилу, что желательно в функции иметь только один return Не надо.

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

П.С. а сайт жутко авторитетный - ага

> несколько точек выхода при обработке - вероятная утечка ресурсов RAII. В заголовке стоит [C++].

а сайт жутко авторитетный - ага

Таки да. Кроме того, там есть ссылки на весьма авторитетных авторитетов.

А программы это гуманитарщина, чтобы авторитетам в рот заглядывать? Не лучше ли пользоваться логикой?

Если очень хочется изобрести велосипед, можно и не заглядывать.

Своей логики нет анализировать разные мнения? Надо всё делать как авторитет сказал?

> Не лучше ли пользоваться логикой?

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

Это в философии может быть школа одноретурнов и школа многоретурнов с томами словесного поноса на эту тему. А в программах должно быть логическое обоснование, а логика не зависит от авторитетности её излагающего.

Ну да, авторитеты ведь никогда не аргументируют, почему нужно делать так, а не иначе. Самому-то не смешно? Пора уже остепениться.

1. Есть. 2. По ситуации.

Если это существенно облегчит жизнь в дальнейшем, почему бы и нет? Если задача сделать код exception safe, то почти обязательно.

> Если это существенно облегчит жизнь в дальнейшем, почему бы и нет?

т.е. вы к любой сишной библиотеке пишете свою обвязку?

В их рассуждениях не рассматриваются все ситуации

Таким образом «многоретурность» необходима. «Одноретурность» является её частным случаем. Поэтому все общие рассуждения про 1 или несколько return идут на йух. Только конкретные ситуации можно рассматривать. А если кто-то раскорячивается в программах ради 1 return потому что так Сам Авторитет сказал, то такой кодер просто тупой дебил.

Тупой дебил - это. Ах. Это guard statements.

я уже написал про то, что проверка входных условий - это отдельный случай, никак не связанный обработкой данных, если в твоем примере будет:

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

кто-то раскорячивается в программах ради 1 return

это ваша фантазия, я написал, что желательно иметь одну точку выхода, а не обязательно должна быть

И чё? Как ни назови это всё равно несколько return. Значит общий принцип «сдохни, но сделай только один ретурн» не действует.

Не принимай близко к сердцу. Пользуйся логикой.

lester, такое ощущение,что вы программ то в жизни не писали, хех:-/

Вот, чтоб далеко не ходить, без всяких авторитетов, просто из жизни, возьмите любой лексический анализатор написанный на C. Примеров в репозитории GNU масса, и убедитесь.

Избегать многих ретурнов это то же, что и избегать continue, break, и goto - в некоторых случаях лишь запутывает.

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

В целом же, многоретурность естественна, это следствие использования анализа use case-ов, для проектирования ваших процедур. Избегать ее-это значит наживать себе лишние сложности из пустого места.

* вручную написанный на С (без lex/flex).

Лопухом не надо быть чтоб такое не писать.

Есть идиоматические конструкции, привычные всем, пользуйтесь ими.

Любой сможет написать while ((c = getchar()) != EOF) { . }

Достали книги, в которых говорится, как нам следует писать программу. Но ни одной более-менее серьёзной программы не приводится. Последние 10 лет я только и занимаюсь, что анализирую чужой код с 18-00 до 00-00 и изучаю чужие методы проектирования, а с 08-00 до 16-00 пишу свой код, так что парни-не надо говорить мне, как я должен делать:-)

Школьные правила я много лет назад изучил (типа-см. например книгу Голуба), но одно только знание их не поможет вам работать с 10-метровым проектом. Здесь нужно знать почему правила получились такими, какие они есть, их природу изучить.

Так вот скажу вам по правде-действительно, точка выхода как правило одна, и средняя длина не более 40 строк. Но это-следствие правильного проектирования функции, не более.

Если вы просто будете стремиться тупо выполнять правила подобные этим, то уподобитесь туземцам (см. Культ Карго) :-)

уважаемый анонимус - я очень ценю ваше ЧСВ и то что вы так долго расписывали свое мнение, но:

1. «действительно, точка выхода как правило одна, и средняя длина не более 40 строк» - здорово, что вы это признали 2. примеры неудобности одноретурного подхода где? ( ес-но без учета проверки параметров )

📎📎📎📎📎📎📎📎📎📎