Модели данных

Вы можете написать в Austin Group и потребовать вернуть любимый семибитный байт.

семибитный мне не нужен, спасибо.

А потом мы удивляемся, «почему у нас юникод не работает?»

Это у вас он не работает (-: У кого надо всё работает.

Да потому, что 99.99% программистов считают «символ» == «байт» == «8 бит»

Вы только что подошли на шаг ближе к истине. Если 99.99% считают, что в байте 8 бит, то это и есть стандарт. Хотите байт с плавающей длиной — вводите новую терминологию.

Попытки уместиться жопой на всех стульях как раз и порождает таких франкенштейнов, как стандарт C++. В котором std::vector::size() на 64-разрядной платформе возвращает беззнаковое (!) 64-битное (!) целое ради виртуальной совместимости вашего кода с какими-то микроконтроллерами, добавляя при этом гору реальных проблем с потенциальным underflow. Если в далёком будущем где-то в прикладных задачах и понадобится массив с 2 млрд+ элементов, то для этого будет использоваться всё что угодно, кроме стандартной библиотеки.

Применительно к вопросу главной темы. Можно писать код и по чистому стандарту. Но если он больше мешает, чем помогает, смело сужайте стандарт до целей вашего проекта.

Это у вас он не работает (-: У кого надо всё работает.

ну вы просто не в курсе, видать не юзали никогда. JFF попробуйте в <любимом ЯП> сделать что-то типа

$ echo "гыгыгы" | sed 's/./-/g'
------

Вы только что подошли на шаг ближе к истине. Если 99.99% считают, что в байте 8 бит, то это и есть стандарт. Хотите байт с плавающей длиной — вводите новую терминологию.

это называется совсем НЕ стандарт. Стандарты для того и вводят, что-бы разночтений не было. И что-бы была возможность расширения, ибо например в utf-8, символ≠байт.

В котором std::vector::size() на 64-разрядной платформе возвращает беззнаковое (!) 64-битное (!) целое

возвращает оно size_type aka std::size_t. Да, это uint64_t, но я не очень понимаю, ЧТО вам в этом не понравилось? Беззнаковое? Дык размер всегда такой, ибо беззнаковый может быть шире(и обычно так и есть), и размер может тупо не влезть в знаковый тип. Например нельзя выделить больше 2Гб на 32х битной платформе. Тупо потому, что стандартиризаторы захотели зачем-то знаковость. Что вам в 64х битности не понравилось на 64х битной же платформе — вообще не понимаю.

ради виртуальной совместимости вашего кода с какими-то микроконтроллерами

при чём тут контроллеры?

добавляя при этом гору реальных проблем с потенциальным underflow.

ЩИТО?

Если в далёком будущем где-то в прикладных задачах и понадобится массив с 2 млрд+

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

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

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

Да и если «нельзя» (да, я не применяю std::vector для такого, по инерции), то почему size() должен выдавать не размер типа «размер»(size_t), а размер типа Dendy_type?

Применительно к вопросу главной темы. Можно писать код и по чистому стандарту. Но если он больше мешает, чем помогает, смело сужайте стандарт до целей вашего проекта.

ну вот именно с этим я и не спорил. Применительно к случаю ТС, я уже говорил, что можно и нужно использовать специальные типы вроде uint32_t. Если речь о файлах(как у ТС), то POSIX вполне оправдан ИМХО.

у меня уже много лет такие массивы

Массивы с 2 млрд+ элементов в std::vector? И какой тип элемента?

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

Чего? :)

Массивы с 2 млрд+ элементов в std::vector? И какой тип элемента?

char например.

ну а как ты передашь 32х битный знаковый размер в malloc? Таких чисел не бывает, они все меньше 2`147`483`647.

malloc получает size_t, он беззнаковый.

char например.

Я бы сказал, char это потолок. Отсюда вопрос, зачем вам std::vector, а не, скажем, std::unique_ptr<char[]>? Ведь единственный функционал, который используется — доступ к элементу по индексу. Ну и это вектор, но ведь такое же беззнаковое 64-битное используется и в std::map.

malloc получает size_t, он беззнаковый.

вот и я про то. Это был ответ на:

std::vector::size() на 64-разрядной платформе возвращает беззнаковое (!) 64-битное (!) целое

Я не знаю, на что это был ответ, только на 32битной платформе можно выделять через malloc/new более 2 Гб. :)

Я бы сказал, char это потолок. Отсюда вопрос, зачем вам std::vector, а не, скажем, std::unique_ptr<char[]>?

а зачем мне unique_ptr, если нужен vector?

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

ну и что? Почему это должно мне помешать брать std::vector::size() ?

Ну и это вектор, но ведь такое же беззнаковое 64-битное используется и в std::map.

почему в std::map::size() должен использоваться какой-то другой размер? А в std::unordered_map::size() что, третий?

В C/C++ уже давно везде используется size_t в качестве размера (и числа эл-тов), на кой ляд это менять?

только на 32битной платформе можно выделять через malloc/new более 2 Гб.

вот потому и можно, что size_t беззнаковый. Был-бы он знаковый, было-бы нельзя. Потому мне удивление и непонятно.

А, это был пример «что было бы, если ...»

Имхо не стоит для таких примеров, начинать предложение с «Вот например». ;)

а зачем мне unique_ptr, если нужен vector?

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

В C/C++ уже давно везде используется size_t в качестве размера

Вот это и есть единственный аргумент: давно используется. Ну, а то что в прикладных задачах от этого одни проблемы — смиритесь.

Считаю, что нужно было в своё время утвердить тип размера как int. В 0.01% случаях, когда нужен другой тип пользоваться basic_vector, basic_map и так далее с возможностью задать свой тип размера. Миллионы программистов сказали бы спасибо.

Я сильно сомневаюсь, что вы пользуетесь вектором как вектором.

зря сомневаетесь. Это действительно массив маленьких чисел 0..255. Такая огромная «текстовая строка».

Вот это и есть единственный аргумент: давно используется.

«давно используется» это не аргумент, а следствие того, что это нужно и годно.

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

использовали-бы что-то другое, например signed char. Не вижу проблемы. Сам можешь определить typedef signed char size_t; и пересобрать все библиотеки, если это по твоему «удобно».

Считаю, что нужно было в своё время утвердить тип размера как int. В 0.01% случаях, когда нужен другой тип пользоваться basic_vector, basic_map и так далее с возможностью задать свой тип размера. Миллионы программистов сказали бы спасибо.

тебя-бы убили, изнасиловали и съели. За порядок не ручаюсь, как и за кратность.