Продолжение боёв по теме _Bool, void и всякой квантовой физике

ptr128

ARV писал(а):

как можно назвать добавку поддержки boolean-типа в Си?!?

Точно так же, как можно назвать строительство метро в Москве или КАД в Питере. Ведь в "родной" планировке города о них даже речи быть не могло :)))

Поймите, для любого нормального человека, если речь идет о чем-то, без указания конкретной временной отметки, то подразумевается всегда текущее состояние, а не то, что сохранилось в памяти у говорящего.
А обсуждать правильность или не правильность стандарта (в том числе и языка) я вижу смысл только в процессе разработки новой версии стандарта. В противном случае, это просто бессмысленная трата времени. Стандарт от этого не изменится и никуда не денется :)))

Реклама

prinv

ptr128, как мне на МК AVR получить какую-то выгоду _Bool?

Реклама

ARV

Аlex писал(а):

Но если мы что-то не видим, это не означает, что оного нет

ну да, как суслик :)))

весь сыр-бор разгорелся с моей декларации принципа "раз не вижу - оно и не надо". мы не видим суслика - и это не мешает нам жить. ну есть он где-то там, или его там нет - что меняется в нашей жизни? знание сила только если это знание дает нам выигрыш какой-то, иначе это лишний груз. голова - она не железная, однако... забивать ее лишними знаниями не хочется... тут уже и нужные знания с трудом удерживаются :)))

но в порядке любопытства - я на протяжении нескольких страниц обсуждения пытаюсь получить от тех, КТО ЗНАЕТ, информацию о том, какие же плюсы и удобства дает нам _Bool или его аналоги... нет ответа. делаю вывод, что и ЗНАЮЩИЕ люди не имеют об этом представления.

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

Z_h_e

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

Добавлено after 1 minute 58 seconds:
ptr128, Вы сообщение удалили что ли, а я на него отвечал или я туплю уже? :shock:

Туплю, пока писал этот пост, другие свои навставляли.

ARV

ptr128 писал(а):

Точно так же, как можно назвать строительство метро в Москве или КАД в Питере. Ведь в "родной" планировке города о них даже речи быть не могло

это просто пук в лужу! выгода от кольца и градостроительства вообще очевидна даже дебилам (к ним быстрее скорая прибывает в случае травм по слабоумию), а выгода новшеств в стандартах Си далеко не так очевидна. вы ее видите? поделитесь же, наконец!

ptr128 писал(а):

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

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

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

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

и тут плюсов от нового типа я не вижу, одни минусы, которые уже неоднократно перечислял.

Добавлено after 3 minutes 41 second:

Z_h_e писал(а):

мне кажется ARV не говорил про неправильность стандарта

вот-вот! подчеркиваю это!
если пройтись по истории моих сообщений в теме про программирование, можно найти массу моих утверждений о пользе стандартизации.

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

Реклама

Siarzhuk

ptr128 писал(а):

#define BOOL_TYPE_SIZE 1

Удивляет, что так мало людей намекнуло об очевидной необходимости собирать с этим дефайном не только пользовательскую программу, но и тулчейновские библиотеки. Иначе этому "стандартному" типу в стандартные-же библиотеки вход заказан.

prinv писал(а):

Согласно стандарту переопределено и количество битов типа _Bool, но видимо меньше 8 бит делать её нет смысла.

Ибо стандартная адресация таких переменных идёт лесом. И sizeof этими "плодами любви" давится.

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

Реклама

ptr128

Z_h_e писал(а):

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

Нет, никакой целесообразности применения данного типа на AVR я не вижу. О чем и писал выше:

ptr128 писал(а):

Лично я им никогда не пользуюсь. Может потому, что он и впрямь не нужен. А может потому, что до его появления уже лет 15 на C программировал и привык обходиться без него.
Но так как приходится работать далеко не только со своими исходниками (точнее в основном не со своими), то знание и понимание этого типа необходимо.

Весь сыр бор вокруг этого:

ARV писал(а):

не смотря на все рекомендации стандартов, лично я рекомендую не пользоваться "не родными" (по происхождению) типами. нет в Си "логического" типа данных, есть только результаты логических выражений. и, как ни странно, эти результаты имеют целочисленный тип

ptr128 писал(а):

Я лично понял, что вы утверждаете, что:

ARV писал(а):

нет в Си "логического" типа данных

ptr128 писал(а):

Что для стандарта C99 и позднее является ложными утверждениями.
А значит

ARV писал(а):

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

ptr128 писал(а):

Вы могли внедрить в голову неверную информацию.

Хотя ARV все время демагогией пытается эту тему замять.

Z_h_e писал(а):

ptr128, Вы сообщение удалили что ли, а я на него отвечал или я туплю уже? :shock:

Не удалял я ничего...

ARV писал(а):

очевидна даже дебилам

Ярчайший пример демагогии. В технической дискуссии не бывает ничего "очевидного".
И при чем тут выгода, если я говорю об уже свершившемся факте? Хоть для C, хоть для Москвы или Питера :)))

ARV

ptr128 писал(а):

Ярчайший пример демагогии.

ярчайший пример демагогии - это въехать на белом коне стандарта в тему, для которой этот стандарт никакого смысла не имеет, и давить размером своего ЧСВ людей, высказывающих собственное мнение по этому поводу :)))

как это было не раз - говорить не о том, чему посвящена тема, а о том, что вы считаете правильным.

ptr128 писал(а):

тему замять

замятием темы занимаетесь вы, т.к. ни разу не привели ни одного подтверждения собственным словам. и даже мои слова о том, что начинающему это знание ни к чему, вы не смогли опровергнуть примером, который бы показал, как ЛОЖНЫЕ сведения об отсутствии [в одном из множества действующих стандартов Си] логического булевого типа, могут создать ему большие проблемы.

P.S. совсем уж в порядке оффтопа.
я, наконец, понял, в чем истинная суть возникновения этой, как бы сказать, дискуссии. дело в том, что я, когда говорю, не думаю о том, что говорю со следователем прокуратуры, который видит принципиальную разницу между "а" и "но", и разница эта измеряется тремя годами заключения :)))

а господин ptr128 считает, что формальная буквальная логика - это главное, чем следует руководствоваться при изложении мыслей в свободной беседе. разумеется, с точки зрения формальной логики на вопрос "может ли бегемот летать?" всегда следует отвечать "ДА", т.к. существует масса способов (разной степени применимости) заставить его это сделать. однако в человеческом общении такой подход вызывает сначала недоумение, а потом и раздражение. похоже, меня на этом в очередной раз развели :)))

в формальном разговоре нет места смыслу сказанного, все трактуется исключительно буквально.

ptr128

ARV писал(а):

т.к. ни разу не привели ни одного подтверждения собственным словам.

Приведите цитату моих слов, которые Вы хотите, чтобы я подтвердил. Но именно моих, а не Ваших.
А то Вы все время от меня каких то ошибок хотели, хотя слова "ошибка" я даже не упротреблял.

ARV писал(а):

начинающему это знание ни к чему

А вот это не Вам решать.
И не мне, конечно. А каждому конкретному начинающему лично для себя.

Реклама

FreshMan

Дааааа....., а все началось то с не предсказующего бурю вопроса

FreshMan писал(а):

есть некая переменная _Bool х;
можна ли, и если можно то как, ее инвертировать ?
тоесть 1-0-1-0-1-...........

Прошу покорнейше меня простить за провокационный вопрос, впреть обещаю быть более осмотрительным :))

prinv

Для развития и такое общение тоже полезно.

COKPOWEHEU

ptr128 писал(а):

prinv писал(а):

ptr128, какие преимущества даст использование _Bool?

Выше все описано же!

вот тут? Или я что-то упустил?

ptr128 писал(а):

Оно и есть в стиле C:

Код:

#include <stdbool.h>
...
  bool j = (a > b) + (b < c);
  bool k = i;

сравните типы в стиле Си - char, int, float,... и введенный _Bool

oleg110592 писал(а):

prinv писал(а):

найти ту границу за которой плюсы перевешивают минусы использования _Bool

на тини13/15 - _Bool минус, на мега2560, хмега, авр32 - плюс :))

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

Аlex писал(а):

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

Числа с плавающей точкой введены не для представления каких-то дробных чисел, а именно дробных чисел широкого диапазона. У них своя арифметика, которую не так просто реализовать вручную, а используются они часто. По логике фанатов _Bool'а как раз стоило бы ввести дробные числа с фиксированной точкой. Само собой, в контроллерах использовать даже float нужно редко. Ну так идиотов это не остановит.

ptr128 писал(а):

ARV писал(а):

сделай себе особую сборку компилятора!

Вы что действительно не в курсе, что GCC распостраняется в исходниках?

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

Z_h_e писал(а):

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

И не только он.
[полу-offtop]
Недавно пришлось использовать windows-специфичные функции вроде отображения файла в ОЗУ, или создания FIFO, обратил внимание на качество документации и типы данных по сравнению с linux. Переопределены ВСЕ типы данных. Кто не верит - загляните на msdn. Для примера,

Код:

HANDLE WINAPI CreateFile(
  _In_     LPCTSTR               lpFileName,
  _In_     DWORD                 dwDesiredAccess,
  _In_     DWORD                 dwShareMode,
  _In_opt_ LPSECURITY_ATTRIBUTES lpSecurityAttributes,
  _In_     DWORD                 dwCreationDisposition,
  _In_     DWORD                 dwFlagsAndAttributes,
  _In_opt_ HANDLE                hTemplateFile
);

Они правда считают, что LPCSTR удобнее стандартного const char [], DWORD удобнее uint32_t а HANDLE - void*?
[/полу-offtop]так вот, введение _Bool выглядит не лучше.
Единственное преимущество _может_быть_реализовано_ на ядрах вроде ARM, поддерживающих прямые операции с битами. Но там для отдельных флагов и без того памяти хватает, да и переписывать компиляторы под что-то намного более эффективное, чем #define _Bool char вряд ли кто будет.

ptr128

COKPOWEHEU писал(а):

prinv писал(а):

ptr128, какие преимущества даст использование _Bool?

ptr128 писал(а):

Выше все описано же!

вот тут? Или я что-то упустил?

Да. При сборке GCC с #define BOOL_TYPE_SIZE 1

ptr128 писал(а):

C точки зрения ARM, поддерживющем bit banding, экономия RAM есть, затрат программной памяти нет, есть только расход виртуальной памяти, которой 4ГБ, что для любого МК - выше крыши.

Но для AVR я преимуществ не вижу.

COKPOWEHEU писал(а):

ptr128 писал(а):

Оно и есть в стиле C:

Код:

#include <stdbool.h>
...
  bool j = (a > b) + (b < c);
  bool k = i;

сравните типы в стиле Си - char, int, float,... и введенный _Bool

А что не так? В stdbool.h он задефайнен как bool, а использование именно _Bool напрямую не рекомендуется. С виду все в полном порядке.

В любом случае, еще раз повторюсь про логический тип данных в С:

ptr128 писал(а):

Лично я им никогда не пользуюсь. Может потому, что он и впрямь не нужен. А может потому, что до его появления уже лет 15 на C программировал и привык обходиться без него.
Но так как приходится работать далеко не только со своими исходниками (точнее в основном не со своими), то знание и понимание этого типа необходимо.

oleg110592

ptr128 писал(а):

Но для AVR я преимуществ не вижу

ну если взять, так сказать нашего пророка Атмеля - он булом не брезгует:

Код:

bool value;
value = ioport_get_pin_level(MY_BUTTON);
ioport_set_pin_level(MY_LED, value);

http://asf.atmel.com/docs/3.21.0/uc3a/h ... start.html

ptr128

oleg110592 писал(а):

ну если взять, так сказать нашего пророка Атмеля - он булом не брезгует:

Поэтому я и писал в том же сообщении:
"Но так как приходится работать далеко не только со своими исходниками (точнее в основном не со своими), то знание и понимание этого типа необходимо."

COKPOWEHEU

Цитата:

В любом случае, еще раз повторюсь про логический тип данных в С:

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

Цитата:

Да. При сборке GCC с #define BOOL_TYPE_SIZE 1

Я ваших намеков не понимаю - скажите прямо в чем преимущество даже с пересобранным компилятором? А тем более в нормальных условиях, когда ради бесполезного нововведения пересобирать компилятор никто не будет? Чем специальный тип лучше обычного char'а (возможно, скрытого за #define bool char)?

ptr128

COKPOWEHEU писал(а):

Логического типа данных в Си никогда не было.

Страница 33, глава 6.2.5 пункт 2
Страница 43, глава 6.3.1.2 пункт 1
Страница 253, глава 7.16 пункты с 1 по 4
http://www.open-std.org/jtc1/sc22/wg14/ ... /n1124.pdf

COKPOWEHEU писал(а):

Я ваших намеков не понимаю - скажите прямо в чем преимущество даже с пересобранным компилятором? Чем специальный тип лучше обычного char'а (возможно, скрытого за #define bool char)?

Я же уже отвечал Вам на этот вопрос:

ptr128 писал(а):

При сборке GCC с #define BOOL_TYPE_SIZE 1
C точки зрения ARM, поддерживющем bit banding, экономия RAM есть, затрат программной памяти нет, есть только расход виртуальной памяти, которой 4ГБ, что для любого МК - выше крыши.

И будет каждая логическая переменная занимать 1 бит вместо 8.

COKPOWEHEU писал(а):

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

Почему то у меня на gentoo он регулярно пересобирается. То же самое может сказать почти любой пользователь Arch или Gentoo. Что в этом такого? И в чем отличие, от использования сборки сделанной кем-то за Вас? GCC в любом случае поставляется в исходниках. Официальной сборки GCC я в природе не встречал. К тому же, раз речь идет о конкретной платформе, не удивлюсь, что для target ARM Cortex-M3 и -M4 так многие и собирают.

WiseLord

Думаю, смысл объявлять переменную как bool есть только тогда, когда нужно подчеркнуть её предназначение именно как некоего логического флага. То есть, uint8_t и bool технически могут быть одним и тем же, но первое даёт понять, что переменная предназначена для счёта, а второе - просто флаг. И хотя технически второое тоже можно складывать/умножать, но уж если объявили как bool - то только для логических операций и проверок на (не)равенство и используем.

ARV

WiseLord писал(а):

но уж если объявили как bool - то только для логических операций

я бы мог понять и смысл, и полезность, и необходимость этого типа, если бы в операторе if можно было использовать только этот тип, равно как и в while и на втором месте for, ну и в тернарном операторе - то есть везде, где требуется логическое выражение. однако это не сделано, и, насколько я понимаю, не сделано ровно по той же причине, по которой прикостылили подчеркивание и заглавную букву - для совместимости с накопленными исходниками. то есть в очередной раз подчеркнули костыльность этого нововведения. ломать весь язык ради жалкого типа - на это не решились.

кстати, что там стандарт говорит о _Bool* - это как, существует? и в случае, когда количество битов на этот тип не кратно 8? как в этом случае костылик хромает?

ptr128

ARV писал(а):

я бы мог понять и смысл, и полезность, и необходимость этого типа, если бы в операторе if можно было использовать только этот тип, равно как и в while и на втором месте for, ну и в тернарном операторе - то есть везде, где требуется логическое выражение.

То есть, Вы считаете правильным при новой версии стандарта нарушать совместимость c предыдущими?
Очень спорное мнение. После подобного финта с Python его уже почти лет десять колбасит и завершения перехода с Python 2.x на Python 3.x до сих пор не предвидится.

ARV писал(а):

как в этом случае костылик хромает?

А Вы напишите. Если Вы правы, хоть на йоту, Вам обязательно ответят: http://www.iec.ch/about/contactus/?ref=toplinks
или http://www.iso.org/iso/home/contact_iso.htm

Какой смысл гадко отзываться о результате работы специалистов в уголке, да еще и на русскоязычном форуме? Вы им в лицо скажите, что думаете
Или, хотя бы, для начала, напишите свою версию стандарта. Там всего 550 страниц. До конца следующего года такой профессионал, как Вы, точно управится.

Продолжение боёв по теме _Bool, void и всякой квантовой физике

Кто сейчас на форуме