All streams
Search
Write a publication
Pull to refresh
15
0
Send message
Это размер код поинта, а единица анализа — один байт, и следуют он точно один за другим в одном порядке на любой архитектуре. Проще говоря, парсится UTF-8 побайтово, в отличие от того же UTF-16.
Просто BOM — по определению Byte Order Marker. В UTF-8 никакого byte order нет и быть не может, так как единица анализа в нём — один байт. Возможно, очередное гениальное решение Майкрософта?
Если коротко, при использовании pragma once компилятор должен уметь корректно определять уникальность файла, что в общем случае невозможно из-за большого количества файловых систем и их особенностей. Самое простое, возможны ошибки при использовании символических или хард ссылок на один и тот же файл, которые могут генерироваться в процессе построения проекта и тп.
Гм, можно ссылку? И объяснение, зачем он нужен, заодно?
Народ просто, похоже, не понимает, что большинство этих «ненужных» фич принимается именно для того, чтобы была возможность нормально имплементировать широко используемые фичи в стандартной библиотеке. Например, нормальные умные указатели были невозможно без мув-семантики, туплы — без вариадик темплейтов. Отсутствие же вариадик темплейтов не позволило имплементировать аналог printf-а, что привело к возникновению стримов — единственного возможного решения для типизированного ввода-вывода в таких условиях.
Почему не в спортлото?
Даже pragma once(или ее аналог) не могут в язык внести.

Может, потому что эту «фичу» невозможно корректно имплементировать? Уже сто раз оговорено, что pragma once не должна использоваться в нормальном коде.
Интересно другое. Почему только string_view, а не полноценные slice'ы для любых видов контейнеров как в Rust? Предлагается использовать итераторы? Тогда не совсем ясно, зачем отдельно выделять строки.
Само собой, в плюсовом стандарте тоже есть такая строчка.
И кстати, да, по стандарту C (не POSIX, а самого языка) sizeof(char) == 1.
C99, section 6.5.3.4:
When applied to an operand that has type char, unsigned char, or signed char, (or a qualified version thereof) the result is 1.

И это довольно очевидно, потому что в стандарте нет другого типа, который мог бы исполнять роль байта.
Я знаю чем отличается октет от байта. Я имел в виду, что размер байта для первых машин был либо 7 либо 8 бит именно по тем соображениям, что столько бит достаточно, чтобы закодировать один символ. По-крайней мере, так нам рассказывали в ВУЗе. А значит исторически байт и символ — сущности крайне близкие. Само собой, потом понятия разошлись и сейчас не редки случаи, когда тип char в тех или иных языках может достигать размера 4 байт, а в спецификациях всех мастей используется термин "октет" означающий 8 бит, для того чтобы не привязываться к конкретным архитектурам.
Ну, исторически байт — это символ. Он даже состоит из 8 бит именно поэтому. Вводить ещё один синоним в стандарт только для красоты странновато.
Этот тип присутствует там с момента появления языка и называется [un]signed char. Вы, похоже, действительно много пропустили, если этого не знаете.
Вот-вот. Создалось впечатление, что пишет студент первого курса. Во первых, сама идея сравнения двух совершенно разных языков, во-вторых, постоянное удивление банальными вещами. Похоже на недавнее сравнение С++ и С#, сделанное студентом.
Как по мне, так compile-time рефлексии будет вполне достаточно. Сделали бы хотя бы её. Эх...
Честно говоря, я вообще почти не встречал проектов на C++ в которых бы не велосипедили. Никто не любит левые зависимости, как правило.
Rust — это, скорее, замена С, а не С++

Мысль не моя, и я как раз считаю, что Rust — прямой конкурент C++. Просто есть мнение, что Rust сильнее C++ не только в прикладной области, но и в области системного программирования, благодаря чему он также может составить конкуренцию C. Сейчас при написании системных вещей выбор стоит как правило C или C++. Смею надеяться, что в скором времени к кандидатам добавиться и Rust. Хотя, к сожалению, область очень консервативная. Зато серьёзную конкуренцию, как мне кажется, Rust может составить C++ в игрострое.
Согласен полностью. Просто я тут имел в виду именно область системного программирования, в которой по моему мнению C++ чувствует себя наиболее уверенно. И именно поэтому я сказал, что Rust превосходит тут C++, потому как он удобнее плюсов и для системного программирования и для прикладного.
Да чёрт с ними с концептами, где рефлексия? Банальная задача сериализации, возникающая в каждой второй программе на плюсах, без рефлексии нормально не решается.
Вы правы, Rust — замена C, и именно по этому он — конкурент C++, который тоже замена C. По субъективным ощущениям, раст — на голову выше плюсов почти по всем направлениям. Это я как заядлый плюсовик заявляю. Если ещё не пробовали на нём писать, то вам непременно стоит это сделать.
P.S. Swift вообще не о то. Зачем он тут вообще? Какое отношение он имеет к области применимости плюсов?
Что разница есть и так всем понятно. Вопрос стоял о том, в чём эта разница заключается. Ну и вообще, интересна область применения.

Information

Rating
Does not participate
Registered
Activity