LINUX.ORG.RU

Каково мнение местной аристократии об iso646.h?

 , , ,


1

4

Я с удивлением обнаружил, что в стандартной библиотеке Си с 95-го года существует этот файл, который определяет ряд стандартных макросов, а именно (скопипастил из GCC):

#ifndef __cplusplus
#define and	&&
#define and_eq	&=
#define bitand	&
#define bitor	|
#define compl	~
#define not	!
#define not_eq	!=
#define or	||
#define or_eq	|=
#define xor	^
#define xor_eq	^=
#endif

В C++ все эти операторы (and, and_eq, bitand, bitor и проч.), оказывается, вообще встроенные.

Изначальная цель введения этих «альтернативных операторов» была в том, чтобы на клавиатурах/в кодировках, где нет символов типа & или | можно было бы писать код на Си. Однако, мне кажется, у них есть и иное применение. Если писать «and» вместо «&&», сильно уменьшается вероятность перепутать с «&». То же насчёт «or» и «||». not вместо восклицательного знака тоже может предотвратить ошибки в логике.

Так вот, что местные цари, короли и прочая аристократия думает по этому поводу? А простые батраки? Использует ли кто-нибудь эти операторы в своём коде?

★★★★★

Иногда по инерции применял после питонов, потом удивлялся что оно так работает.

PolarFox ★★★★★
()

Не спец в сишечке, конечно, но кой-чего корябал. Имхо, чтобы спутать в коде «&&» и «&» нужно приложить большие усилия. Так что

на клавиатурах/в кодировках, где нет символов типа & или | можно было бы писать код на Си

This.

Lilly
()
Ответ на: комментарий от tailgunner

Полагаю, о триграфах ты не знаешь %)

Незадолго до твоего сообщения и о них узнал. Вот ведь какие костыли в те времена были...

proud_anon ★★★★★
() автор топика
Ответ на: комментарий от Lilly

Имхо, чтобы спутать в коде «&&» и «&» нужно приложить большие усилия.

Опечатка — и всё. Хотя компилятор или анализатор может иногда выдать варнинг.

proud_anon ★★★★★
() автор топика
Последнее исправление: proud_anon (всего исправлений: 2)

Да, использую, но для тех типов, для которых их назначение соответствует названию (т.е. для встроенных и с Boost.Phoenix). Если библиотека перегружает оператор (как например Boost.Range), то использую традиционную запись.

Операторы <op>_eq не использую, предпочитаю x = x <op> y.

Begemoth ★★★★★
()
Ответ на: комментарий от kravich

А ещё есть диграфы, так скажем запись std::vector<::std::size_t> означает не то же, что std::vector< ::std::size_t>. А ещё можно вспомнить про \ перед концом строки:

// la-la-la \
int x = 42;

или так

// what the fuck ?????????????????/
int y = 42;
Begemoth ★★★★★
()
Последнее исправление: Begemoth (всего исправлений: 1)
Ответ на: комментарий от proud_anon

Опечатка — и всё.

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

Lilly
()

not вместо восклицательного знака тоже может предотвратить ошибки в логике

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

q11q11 ★★★★★
()

Не использую, дольше печатать ведь! Ни разу не было ошибок, связанных с путаницей в & и &&, или | и ||.

Полагаю, о триграфах ты не знаешь %)

Не знал, почитал. Это жесть, код совершенно нечитаемый :)

solovey ★★
()
Ответ на: комментарий от q11q11

если слепой и руки кривые - зачем тогда вообще за компом сидеть?

Какой ты неполиткорректный! А как же равные возможности и универсальный доступ?

proud_anon ★★★★★
() автор топика
Ответ на: комментарий от Begemoth

как ты прямиком с википедии вспоминаешь

anonymous
()
Ответ на: комментарий от tailgunner

Полагаю, о триграфах ты не знаешь %)

педивикия: В Паскале с этой же целью используются диграфы: (. .) (* *) вместо [] {}.
тема сисек в паскале раскрыта...

q11q11 ★★★★★
()
Ответ на: комментарий от proud_anon

А как же равные возможности и универсальный доступ?

возможности то равные, а вот на выхлопе огромные отличия
если ты программер, пишешь & вместо && и не замечаешь этого... ну ты понял

q11q11 ★★★★★
()

Не использую. Иначе придется уж слишком осторожным быть с именованием переменных и функций.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от q11q11

если ты программер, пишешь & вместо && и не замечаешь этого... ну ты понял

Чаще всего я пишу на языках, которые это самостоятельно замечают. Но когда приходится...

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

Ну ага, вот все такие все из себя ходят, пальцы гнут, мол, настоящие кодеры программируют путём «cat > a.out», а потом получается heartbleed. Или проверка SSL-сертификатов методом Apple.

proud_anon ★★★★★
() автор топика

Использую and, or, not, иначе нечитабельно.

unsigned ★★★★
()

По всей видимости, в массы не пошло, но идея была неплоха.

pathfinder ★★★★
()

Харбисон и Стил покурил или сам стандарт?

qulinxao ★★☆
()

Знаю давно, не использую ибо пока не понадобилось.

nanoolinux ★★★★
()
Ответ на: комментарий от qulinxao

в современные асмы оно из формулатранслятора пришло.

а с чего ты решил что я говорю про СОВРЕМЕННЫЕ асмы?
я вообще-то говорю про управляющие je, jne, jg, jge... и ещё 28 команд.

q11q11 ★★★★★
()

И тут С превращается в Паскаль...

UVV ★★★★★
()
Ответ на: комментарий от q11q11

дык в мнемоники eq neq ge le асмов (любых) пришло из фортрана ибо до фортрана не было асмов - были машкоды без мнемоник.

т.е в этом смысле язык высокого уровня (фортран) появился раньше любого языка нижнего|низкого уровня ибо были машкоды - ибо не было возможности переносить проги - а так как свои алго транслировали в ручную то знаки могли быть юзеро(кодеро)выбраными произвольными.

и тока формулатранслятор закрепил .

qulinxao ★★☆
()
Ответ на: комментарий от Eddy_Em

Не использую. Иначе придется уж слишком осторожным быть с именованием переменных и функций.

Так же. А пых так вообще имеет разный приоритет для таких писюлек. Нет уж, увольте, я по возможности придерживаюсь одного «стиля» написания. Работать приходится с несколькими ЯП, и вот еще питон придется скоро разбирать. Лучше побольше скобочек расставить, чем потом втуплять почему условие не так работает. Ну и вот это из той же серии - лучше развернуть в более понятную конструкцию которая везде взлетит. А башка она такая - сразу на контекст другого ЯП не переключается.

deep-purple ★★★★★
()

Мнение неоднозначное.

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

С другой, я полагаю, что на Си всё же надо писать в стиле, естественном для Си. Если проект закрытый - надо придерживаться соглашений о кодировании, принятых в корпорации, которые вряд ли одобряют эти синонимы. Если проект открытый - писать так, чтобы тебя поняло большинство Си-программистов, для которых вряд ли эти самые and и not являются естественным выбором. И уж совсем жесть, если ты патч с этими синонимами посылаешь в большой чужой открытый проект. И с обычным-то синтаксисом приходится доказывать нужность патча...

В общем, для любого проекта, который пишет более одного человека - я бы не стал...

hobbit ★★★★★
()
Ответ на: комментарий от cattail

Хороший хедер

Так много ошибок в первом слове: только х и й правильно написаны.

anonymous
()
Ответ на: комментарий от hobbit

Соглашусь. Хотя я вообще на С писать бы не стал. Есть же годные альтернативы. (Ну если нету неких очень хитрых требований по архитектуре, на которую компилять или не легаси).

anonymous
()
Ответ на: комментарий от hobbit

И тоже нинужны. Хотя тут чисто дело вкуса, естественно. )

anonymous
()
30 июня 2015 г.
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.