Говорят *int64_t не нужен. float64_t хватит всем

Если бы это был

ты мог бы возмущаться. Но

Так я и сейчас могу, прикинь

Так «мыться» - это как раз делать по-человечески, а не так как ты предлагаешь

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

ну и?

Что и? Вопрос твой в чем?

Что и? Вопрос твой в чем?

Ты истеришь что тебе 23 флажка не выставить. Вот, выставляй.

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

Ты бредишь.

Ты делаешь точно так же: «а если бытов будет…»

Нет. Я предлагаю общее решение. Ты подгоняешь условия под ответ.

Через жопу - это выкинуть простые типы и выдумывать какую то херню.

Самое забавное, что ты даже не понимаешь, какую хрень ты пишешь. Вот взять пример с __int128. Это же чисто подход «у меня есть синяя изолента - значит буду мотать изоленту». Ну т.е. да, так делают, но именно таких мастеров называют рукожопами.

Так мало задач, но так много используется… Что-то не согласуется.

Для тебя новость, что часто решают проблемы через жопу? Напоминаю, оригинальный вопрос: «почему логичнее использовать байты».

Оппонент спорит с доводом, потому что считает его весомым

Так ты не споришь с доводом. Ты пытаешься давить на «удобно сделать тяп-ляп» в узком диапазоне условий. Что характерно, не то что бы реально было удобно. bits &= ~FLAGN - такое не хуже джавоскриптовых перлов, просто привычно.

Да ты че. Видывал я код от js-иков, там все прекрасно, как в китайской грамоте.

Ты видывал некоторое дерьмо и так и не понял, что писать код надо понятным? Ну что ж, это характеризует тебя.

Кстати, заметь, ты всё упорно споришь с какими-то мифическими js-никами потому что в общем-то пришёл ты в эту тему чтоб показать, какой ты крутой от того что не любишь js.

Так я и сейчас могу, прикинь

Ну да, нести чушь невпопад ты действительно можешь, и даже практикуешь

Или ты про такой случай

Я про вот что. Товарищ khrundel пишет, что мол херово использовать инт типы для операций с битами, например uint64. Типа а если нам нужно не 64 бита, а больше или меньше… Типа вот нужно например больше битов? - Тут я скажу ок, для этого уже есть специальные типы (bitset например). А вот нужно меньше типов? Например 61 или 27 - что тогда? Тут я отвечу: хорошо, ну возьми в случае 61 uint64, а в случае 27 uint32 и используй только те, что требуются. Ведь если мы говорим про использование массива uint8 в качестве хранилища бит, то там тоже может быть не кратно 8 и соответственно не все биты будут использоваться.

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

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

• это тяп-ляп

• узкий диапазон условий

Про силу первого довода думаю спорить нет смысла, ведь такая сила аргументации…

А вот по поводу последнего пункта: какой по твоему здесь диапазон случаев применения?

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

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

Давай чтоб понятно объясню тебе оригинальный вопрос: почему не логично. Вот есть у тебя многобайтовый регистр флагов, читать и писать в который можно лишь атомарно. И ты пролетаешь со своим массивом байтиков.

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

А, вот ещё, например, мне нужно реализовать софтварную конвертацию double в int64_t. Чё там по байтикам?

решать должен компилятор

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

Ты истеришь что тебе 23 флажка не выставить. Вот, выставляй

Что, что? Где я это утверждал?

Перечитай это мое сообщение: Говорят *int64_t не нужен. float64_t хватит всем (комментарий)

Что, что?

Орнул представив мамку Кайла.

А, т.е. и cpu должны подстраиваться под это ублюдство?

Да, но в твоём CPU уже есть средства для перевода float в int и обратно)

В JS тип Number - это просто тот же сишный double и ничего больше. Всё по канону IEEE 754. В этом типе целочисленные значения, меньшие 2^53 однозначно отображаются в битовое представление double. То есть, если ты хочешь, чтобы в другом языке было как в JS, то просто используй во всех местах 64-битный float IEEE 754.

При битовых операциях Number конвертируется в знаковый либо беззнаковый 32-битный тип. Например 3.14 ^ 7 даст 4.

Number также может использоваться в качестве индекса массива или строки. В этом случае он конвертируется в строку от беззнакового инта.

Ещё в JS есть настоящий целочисленный тип - BigInt, он ни во что не конвертируется при битовых операциях с ним. Для индексов он всё так же переводится в строку. Размер BigInt в битах не ограничен. Единственное ограничение - нельзя беззнаково сдвигать вправо (оператор >>>), но это ограничение понятно.

TypedArray ещё есть, да, про которые уже упоминали, где можно хранить целые числа до 64 бит включительно.

Ты по делу тоже что-то представил?

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

Я про это Говорят *int64_t не нужен. float64_t хватит всем (комментарий)

не понимаю сути

Да ты тут в принципе не особо в себе

Ответ на вопрос будет, где я утверждал, что не выставить что-то?

проблемы использовать массив байт для флагов нет

Мы тут не про проблемы, а про удобство.

Сам навыдумывал себе тезисов, и с собой дискутируешь.

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

Я про вот что. Товарищ khrundel пишет, что мол херово использовать инт типы для операций с битами, например uint64. Типа а если нам нужно не 64 бита, а больше или меньше… Типа вот нужно например больше битов? - Тут я скажу ок, для этого уже есть специальные типы (bitset например). А вот нужно меньше типов? Например 61 или 27 - что тогда? Тут я отвечу: хорошо, ну возьми в случае 61 uint64, а в случае 27 uint32 и используй только те, что требуются. Ведь если мы говорим про использование массива uint8 в качестве хранилища бит, то там тоже может быть не кратно 8 и соответственно не все биты будут использоваться.

Какой-то эталонный словесный понос. Ты хотел рассказать мне что умеешь находить ближайшую вверх степень двойки что ли? Ну ок, я не спорю, умеешь. Хороший мальчик.

Но речь вообще о другом. Даже как-то неудобно в третий раз повторять, что вопрос был о том, почему для битовых полей байты логичнее чем 64битные целые, нет? Ты как, и в третий раз проигнорируешь это?

Давай чтоб понятно объясню тебе оригинальный вопрос: почему не логично. Вот есть у тебя многобайтовый регистр флагов, читать и писать в который можно лишь атомарно. И ты пролетаешь со своим массивом байтиков.

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

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

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

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

Если хочешь, то можешь рассматривать многобайтовые целочисленные типы как массивы ограниченной длинны с возможностью атомарных операций над «массивом» целиком и над всеми байтиками одновременно.

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

Зачем, скажи, мне твои байтики, если с ними неудобно работать? У меня архитектурно есть определённый размер регистров, позволь мне ими пользоваться не через одно место.

Сильно убедительно?

Ахах, вообще не убедительно. Твой массив байтов здесь просто не работает, архитектурно. Хоть увольняй, хоть не увольняй.

Могу предложить такое решение:

char arr[8];
uint64_t *register;
*register = *(uint64_t*)arr;

Заявление у тебя на столе)

которых хоть контроллеры программируй, хоть сайты пиши.

хоть cve.org наполняй; хех, и даже в этих 3-ёх строчках UB )

даже в этих 3-ёх строчках UB

Я не пойму, ты придрался что ли?)

Твое логичнее потому что что? Потому что логичнее?

Вот я тебе задавал вопрос, который ты проигнорировал, может ответишь все же?

Говорят *int64_t не нужен. float64_t хватит всем (комментарий)

Ответ на вопрос будет, где я утверждал, что не выставить что-то?

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

Мы тут не про проблемы, а про удобство.

Ты так и не смог сформулировать чем set_bit() на массив неудобнее set_bit() на u64.

Есть гипотеза

Чувак, это факт

Какой в жопу факт, если гипотеза? И да, без ссылки это пишется как «есть мнение».

Просто в этой теме ты, видимо, так же некомпетентен, как и в программировании.

Ой-все :) Просто на хуй иди, филолог ты мамкин, jack of all trades master of none.

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

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

Интерпретация байтиков зависит от типа, но на уровне железа всё одно.

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

И умные люди, в своё время, это понимали и создавали прекрасные универсальные языки, на которых хоть контроллеры программируй, хоть сайты пиши.

Ты, пардон, про язык, в котором можно индексировать целое строкой?

Нет, безусловно, мы все любим сишечку, но только за её возраст и былые заслуги. Если бы сейчас кто-то придумал бы подобный язык, его бы смешали с говном.

Зачем, скажи, мне твои байтики, если с ними неудобно работать?

С ними удобно работать. Просто ты, будучи не очень вменяемым, не понимаешь, что flags &= ~FLAG1 - это тупая срань и совсем не похожа на маму-утку.

Твое логичнее потому что что? Потому что логичнее?

Ты вообще зарекомендовал себя человеком, которому надо объяснять по 3 раза и он всё равно ничего не поймёт.

Я уж не знаю как объяснить… Давай ещё раз попробую, с другой стороны.

Что по-твоему представляет собой тип uint32_t?

Если ты думаешь, что 4 байта, то поздравляю, ты - дебил.

uint32_t - это число. Без знака. От 0 до 4+ миллиардов. И это важно, хотя бы потому, что учитывает endianness платформы. Т.е. при простом «старший бит второго байта означает свойство x» твоя программа пойдёт по звезде. Но и это ещё не всё, это число не может, например, переполниться, а это UB. Т.е. если компилятору покажется, что в результате твоих хитрых битовых операций оно может переполниться, то компилятор имеет право решить, что эти операции какие-то не такие и не выполнить их.

Вот я тебе задавал вопрос, который ты проигнорировал, может ответишь все же?

Какой вопрос, тупица? Диапазон применений? Ну как бы из контекста понятно, что тот, который помещается в регистр.

Но и это ещё не всё, это число не может, например, переполниться, а это UB

uint32_t — это беззнаковое число. Переполнение беззнаковых — не UB.

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

Как оно может переполниться в результате битовых операций?

Какой в жопу факт, если гипотеза? И да, без ссылки это пишется как «есть мнение».

Скажи, тебе реально проще написать ответ, опозориться, чем потратить 15 секунд на осмысление текста?

Клоун, факт - это то, что жаргонизмы часто являются исковерканными словами. Примеры приведены.

А гипотеза - это то, что коверканье слов происходит для демонстрации фамильярности с соответствующими понятиями.

А вот твоё мнение, о том что все вокруг - безграмотные идиоты, и один ты - д’Артаньян, как раз является ТУПОЙ гипотезой. Во-первых, потому что «договорА» заключают выпускники факультетов, куда без золотой медали хрен поступишь. Во-вторых, потому что даже простые мужики, занимающиеся «дОбычей» до начала работы говорили «добЫча» и переучились уже по месту работы.

uint32_t — это беззнаковое число. Переполнение беззнаковых — не UB.

Мамой клянёшься?

Как оно может переполниться в результате битовых операций?

От сдвига, клоун.

Ты совсем элементарных вещей не знаешь, получается? Вот стандарт C99, в остальных версиях языков C и C++ написано то же самое:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

§6.2.5, clause 9

The range of nonnegative values of a signed integer type is a subrange of the corresponding unsigned integer type, and the representation of the same value in each type is the same.31) A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type.

От сдвига, клоун.

Стандарт не считает такое поведение «переполнением» вообще, см. выше. В любом случае ты утверждаешь, что поведение, которое определено стандартом, это UB.

Ты совсем элементарных вещей не знаешь, получается? Вот стандарт C99, в остальных версиях языков C и C++ написано то же самое:

Ну и засунь этот стандарт себе в жопу плашмя.

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

Если что, std::byte определён, только вопрос времени, когда тебе объяснят различие между std::byte и uint8_t.

Стандарт не считает такое поведение «переполнением» вообще, см. выше.

А раз не считает, то и проблем нет, верно?

Слив засчитан, короче.

Когда-то и переполнение знаковых не было UB

И когда же это было? Есть какая-нибудь ссылка на стандарт или ещё какой-то документ, где было написано, что это не UB?

ты можешь поручиться, что в следующем стандарте UB не расширят до беззнаковых?

Прецедентов подобного масштаба ещё не было.

Если что, std::byte определён, только вопрос времени, когда тебе объяснят различие между std::byte и uint8_t.

К чему ты упомянул std::byte?

А раз не считает, то и проблем нет, верно?

Верно. И в теории, и на практике с этим нет никаких проблем. Более того, ядро Linux использует эти переполнения. Какие проблемы с этим есть? Ты утверждал, что компилятор что-то может сделать. Покажи.

Слив засчитан, короче.

Ну ты и сектант, чувак! Сначала рассказываешь про UB (термин из стандарта), потом говоришь засунуть стандарт в жопу. В своих попытках самоутверждения в интернете совсем разучился спорить нормально?

И когда же это было? Есть какая-нибудь ссылка на стандарт или ещё какой-то документ, где было написано, что это не UB?

Ну, если бы у тебя были мозги, то ты бы осознал, что как минимум в тот момент, когда не было понятия UB не было и UB в языке C. Логично?

Прецедентов подобного масштаба ещё не было.

Мамой клянёшься?

К чему ты упомянул std::byte?

Ну подумай. Это не больно. Не, серьёзно, вот как ты сам себе объяснишь тот факт, что тебе в язык добавляют специальный тип для байта, хотя тип для байта уже есть? Может для того чтоб отличать байт от 8битного целого?

Верно. И в теории, и на практике с этим нет никаких проблем. Более того, ядро Linux использует эти переполнения.

Что ж ты сразу-то не сказал.

Если ядро использует, тогда конечно.

Слушай, тупица, ты когда-нибудь слышал о проблемах с компиляцией ядра на clang? Вот как бы я вообще от темы далёк, но даже я слышал о проблемах ядра с UB, не помню что там было точно, вроде что-то связанное с кодом типа

int* ptr = &struct_ptr->val;
if (struct_ptr)
   foo(ptr);

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

Ну ты и сектант, чувак! Сначала рассказываешь про UB (термин из стандарта), потом говоришь засунуть стандарт в жопу.

Ну как бы и своя голова на плечах быть должна. Ситуации, когда хитрожопый код вдруг прекращал работать встречались в истории не раз. С чего ты решил, что всё, история остановилась и такого не повторится? Просто для справки: когда-то в плюсовых библиотеках (MFC) разрешалось вызывать методы от нулевого объекта. Вот тупо в начале стояло if (!this)return;. Сейчас любой компилятор эту инструкцию выпилит под предлогом того, что вызов метода нулевого объекта - это UB.

Нет, я понимаю, ты где-то слышал, что UB является только беззнаковое переполнение. И поспешил этим знанием похвастаться. Но как бы это тупо. Беззнаковое число не является принципиально отличным от знакового. И когда-то роль 8битного числа вообще char исполнял, и ничего, жили. С чего вдруг у тебя возникла уверенность, что тебе не сообщат, что uint32_t - это именно беззнаковое целое, и рассчитывать на переполнение не стоит?

Т.е. при простом «старший бит второго байта означает свойство x»

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

Но и это ещё не всё, это число не может, например, переполниться, а это UB

Опять таки, ты подгоняешь условия под ответ. Т.е. точечно притягиваешь за уши странный кейс, при том, что очевидно и стандарта не знаешь, как тебе написали.

Диапазон применений? Ну как бы из контекста понятно, что тот, который помещается в регистр.

Т.е. диапозон 0-64 бит. Это по твоему узкий диапозон. Вот это, если отбросить все твои сумбурные речи единственный твой довод по существу. Остальное - эмоциональщина.

Но, на этот довод я тебе уже отвечал: можно использовать специальные типы при превышении этого порога. А до него удобно использовать.

И да, сам дебил и сам тупица.

Все. С тобой я тоже здесь закончил.

не груби старшим

Не груби младшим.

язык, в котором можно индексировать целое строкой?

В си нет типа-строки. Извини.

Нет, безусловно, мы все любим сишечку, но только за её возраст и былые заслуги. Если бы сейчас кто-то придумал бы подобный язык, его бы смешали с говном.

Нет. Сишечку любят за то, что она уважает программиста, доверяет ему и даёт полную свободу и контроль над ресурсами. Сишка - для реалистов. А ты продолжай мечтать про свои гениальные «байтики», которые, кстати, за столько лет существования языков высокого уровня так никто и не догадался реализовать.

И как бы тебе этого не хотелось, но ни одна современная имитация так и не добралась и навряд ли доберётся до уровня сишечки, в которой

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

Неправда ли?

Ну и засунь этот стандарт себе в жопу плашмя.

🤣 Полехче, чел, не напрягайся так, не молодой ведь уже)

В языках для промышленного применения обсуждаемые вопросы с битами,байтами,интами и более хитрыми типами давно уже решены. Например в ADA:

https://www.adaic.org/resources/add_content/docs/95style/html/sec_10/10-6-3.html https://www.adaic.org/resources/add_content/docs/95style/html/sec_5/5-4-8.html

Но для для большинства программистов это «сложно» и «лень». Потому и пишут так как пишут.

А зачем мне разбивать его на байты?

Ты не в курсе что данные хранятся в памяти разбитыми на байты? Неудивительно, в общем-то.

Опять таки, ты подгоняешь условия под ответ.

Ты был пойман на манипуляции и решил обвинить оппонента в том же?

Т.е. точечно притягиваешь за уши странный кейс

Какой странный кейс? Хранение битовых флагов где-то в памяти?

Т.е. диапозон 0-64 бит. Это по твоему узкий диапозон

«Диапозон». Ну, начнём с того что не 0-64, а 9-64. Случай с 0 флагов нам не интересен, а 1-8 подходит под вариант «храним в байте». Но и с другой стороны тоже проблема: начиная с 33 возникают вопросы не слишком ли большое место отдаётся на выравнивание.

Но, на этот довод я тебе уже отвечал: можно использовать специальные типы при превышении этого порога. А до него удобно использовать.

А я тебе отвечал, что

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

Ну и до кучи: если тебе «логично» использовать специальные типы после 64 бит, то почему вдруг менее логично до? Как на логику влияет количество флагов?

И ты ни на что из этого не нашёлся что возразить.

В си нет типа-строки. Извини.

В си есть строковой литерал, который называется строкой, причём везде, включая библиотечные функции. Опять местный дурачок решил «поймать» на ошибке и сел в лужу?

Нет. Сишечку любят за то, что она уважает программиста, доверяет ему и даёт полную свободу и контроль над ресурсами.

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

А ты продолжай мечтать про свои гениальные «байтики», которые, кстати, за столько лет существования языков высокого уровня так никто и не догадался реализовать.

??? Нет байтиков?

Да даже в современном JS байтики есть.

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

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

Для чего ты меня оскорбляешь? Я повторяю вопрос: в своих попытках самоутверждения в интернете совсем разучился спорить нормально?

Ну, если бы у тебя были мозги, то ты бы осознал, что как минимум в тот момент, когда не было понятия UB не было и UB в языке C. Логично?

По твоей логике в новом стандарте могут изменить поведение конструкции if (something), поэтому её не следует использовать?

И объясни такую вещь: ну хорошо, в новом стандарте что-то поменяют. Но ведь реальный софт собирается с флагами -std=c99 или подобными (то же самое ядро). Как это может повлиять на мою программу, если она собирается с такими флагами?

К чему ты упомянул std::byte?

Ну подумай.

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

Слушай, тупица, ты когда-нибудь слышал о проблемах с компиляцией ядра на clang?

Во-первых, что это за бородатые сказки — Google собирает ядро для Android с помощью clang, лол. Во-вторых, там были проблемы с семантикой GNU-шных расширений, а не с переполнением беззнаковых, о котором мы собственно говорим.

Вот как бы я вообще от темы далёк

От темы программирования на языках C и C++? Это бы многое объяснило. Но не объяснило бы того, почему ты распространяешь ложную информацию про UB в этих языках. Хотя постойте-ка, я знаю: ты сказал про UB потому, что тебе нужно было любыми средствами отстоять свою позицию в споре (подобно тому, как ты сейчас сказал какую-то чушь про шланг и ядро).

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

Во-первых, кто мне может об этом сообщить или не сообщить? Во-вторых, что «рассчитывать на переполнение не стоит» тут говоришь ты, а не я.

Я тоже больше не собираюсь с тобой спорить. Сам дурак, да.

Ладно, забей. Мы напрасно тратим время. Ни ты меня, ни я тебя не хотим или, в силу индивидуального опыта, не можем понять. Удачи.

В си есть строковой литерал, который называется строкой, причём везде, включая библиотечные функции.

литерал есть. и тип его char*, будто это один символ в памяти, и никаких нулей сзади там нет.

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

типа «строка» реально нет, и это правильно. уж много раз говорилось почему. строковый литерал есть. но это не строка, а char*.

в памяти оно хранится постранично, 4кб-1гб

Лучше предлагаю тебе (и остальным) пройти коротенький тест на знание языка Си: https://wordsandbuttons.online/so_you_think_you_know_c.html

:)

указатель на область памяти в float64_t? ты упрт?

Это ты наверное не мне хотел ответить?

Для чего ты меня оскорбляешь?

Потому что я возмущён. Я пришёл сюда поучаствовать в философской дискуссии, объяснить, почему хранить флаги в инте - это вообще говнокод. Мне привели ровно 3 возражения. Одно - «а мне написать int удобно», что вообще к любому говнокоду относится. И 2 других - это чисто попытки наехать на меня, одно за то что я слово компилятор исковеркал, второе вот от тебя, что «распространяю дезинформацию про UB».

Я повторяю вопрос: в своих попытках самоутверждения в интернете совсем разучился спорить нормально?

Ты на серьёзных щах это? Ты ворвался поймать на мелкой ошибке, которая вообще никак не влияет на обсуждаемый вопрос и сейчас обвиняешь меня в самоутверждении в интернете?

Ну молодец,чё.

По твоей логике в новом стандарте могут изменить поведение конструкции if (something), поэтому её не следует использовать?

Нет. Но когда у тебя x + 1 < x уже воспринимается компиляторами как «всегда ложно» для знаковых типов, и оставлено в виде исключения для беззнаковых, ты всерьёз лепишь мне про «это навсегда»?

И объясни такую вещь: ну хорошо, в новом стандарте что-то поменяют. Но ведь реальный софт собирается с флагами -std=c99 или подобным

Ничего тупее не слышал. Вот серьёзно.

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

Ну и я уж не вспоминаю, что темой обсуждения язык C вообще не является.

Я не собираюсь над этим думать

Неудивительно. Ведь сложно не заметить тенденцию развития языков C/C++ идёт от «ну у нас же есть 8битовый char, зачем нам другой тип на 8 бит» к «нам нужны семантически-определённые типы, и даже псевдоним через typedef не катит». Единственный способ как-то вырулить - это «из принципа» отказаться смотреть в эту сторону. Я виноват в том, что ты не хочешь задуматься, зачем вводят std::byte.

Во-первых, что это за бородатые сказки — Google собирает ядро для Android с помощью clang, лол. Во-вторых, там были проблемы с семантикой GNU-шных расширений, а не с переполнением беззнаковых, о котором мы собственно говорим.

Не, ты реально тупой как пробка. Ты заявил: это никогда не поменяется, потому что в ядре используется. Было? Было. Я тебе ответил, что вон, даже clang ядро нормально не компилирует. Т.е. вопрос совместимости с ядром не беспокоит особо не то что комитет, но и разработчика альтернативы для gcc. Если ядро не компилируется соответствующим стандарту компилятором, то это не проблема компилятора, не то что стандарта.

Ну и ты сам себе противоречишь: ты же сам написал, что в ядре используется флаг совместимости с c99. Это значит, что если завтра примут стандарт С24, в котором совместимость с ядром сломают, это никак не повлияет на работу ядра, из-за параметра компиляции. Т.е. ты сам понимал, почему твой аргумент нелеп, но всё равно написал его.

От темы программирования на языках C и C++? Это бы многое объяснило.

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

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

Сколько напускного возмущения-то, ты там от напряжения не обосрись смотри. «Распространяет ложную информацию», минимум 10 лет строгого режима.

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

Про UB только один из аргументов. В принципе и big/little endian хватило бы. И на C/C++ свет клином не сошёлся. И нет никаких гарантий, что UB не расширят, в конце концов когда-то уже приняли решение, что отказываться от оптимизации выражений со знаковыми числами ради сохранения эффектов переполнения не стоит, почему бы в будущем стандарте не починить и оптимизацию беззнаковых?

Так что в реальности всё ровно наоборот. Твой аргумент, если предположить что ты - добросовестный спорщик, должен был бы звучать так: «часть про UB не валидна в отношении языков C/C++ текущего стандарта, там переполнение беззнаковых не является UB». Но ты уже раскрылся как ad hominem спорщик, так что твой аргумент такой: «да ты не знаешь что только переполнение знаковых является UB, о чём вообще с тобой говорить».

Заметь, ни один из защитников флагов в интах ничего лучше и не придумал. Чисто защита своей любимки от нападок вебмакак.

Во-первых, кто мне может об этом сообщить или не сообщить? Во-вторых, что «рассчитывать на переполнение не стоит» тут говоришь ты, а не я.

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

Я тоже больше не собираюсь с тобой спорить.

Эй, постой, мы ещё не обсудили в чём логичнее хранить флаги, в инте или в последовательности байтов… Ну чисто чайка-спорщик, прилетел, насрал, улетел.

литерал есть. и тип его char*, будто это один символ в памяти, и никаких нулей сзади там нет.

А как же нуль терминатор в конце?

литерал есть. и тип его char*, будто это один символ в памяти, и никаких нулей сзади там нет.

Спасибо, я тоже книжку «Язык C за 21 день» читал.

Вопрос был о том, можно ли считать язык, в котором валидно выражение 2["abc"] эталоном следования логики. Ну т.е. мне заявляют абсурдное утверждение, я привожу пример нелепости, и дальше начинается «а «abc» - это не строка, в С вообще нет строк, ко-ко-ко».

И да, в C, безусловно, есть строки. Ну такой вот язык был придуман, с максимальными переиспользованием типов, char для символов и байтов, int для целых и логики. И строки там были char*, с терминатором в конце. Единственная причина, почему эти клоуны тему подняли, что надо хоть что-то возразить, а кроме увода в «является ли char* строкой» вариантов не было. Если в соседней теме кто-то спросит как конкатенировать в C строки они без вопросов расскажут.