Разрабатываю класс, который предполагает в качестве исходных данных для создания своего объекта и работы с ним сторонний массив целых чисел, для примера, типа long.
Как бы наиболее простым и явным образом намекнуть пользователю класса (не прибегая к справке), что массив не должен содержать целых, выходящих за 32-разряда (это важно для платформ, где long 64-разрядный)?
[Ограничения связаны с особенностями бинарной сериализации объектов данного класса]


Спасибо.

Здравствуйте, _hum_, Вы писали:

__>Разрабатываю класс, который предполагает в качестве исходных данных для создания своего объекта и работы с ним сторонний массив целых чисел, для примера, типа long.
__>Как бы наиболее простым и явным образом намекнуть пользователю класса (не прибегая к справке), что массив не должен содержать целых, выходящих за 32-разряда (это важно для платформ, где long 64-разрядный)?
__>[Ограничения связаны с особенностями бинарной сериализации объектов данного класса]


Например,

static_assert((sizeof(T)<=sizeof(uint32_t)), "Usage of types longer than uint32_t not allowed") 
и
static_assert(std::is_integral<T>::value,"Non-integral types arent allowed")

Только один момент есть, uint32_t определен не везде, однако количество платформ, где его нет, пренебрежимо мало.

Здравствуйте, SomeOne_TT, Вы писали:

SO_>Здравствуйте, _hum_, Вы писали:

__>>Разрабатываю класс, который предполагает в качестве исходных данных для создания своего объекта и работы с ним сторонний массив целых чисел, для примера, типа long.
__>>Как бы наиболее простым и явным образом намекнуть пользователю класса (не прибегая к справке), что массив не должен содержать целых, выходящих за 32-разряда (это важно для платформ, где long 64-разрядный)?
__>>[Ограничения связаны с особенностями бинарной сериализации объектов данного класса]


SO_>Например,
SO_>

SO_>static_assert((sizeof(T)<=sizeof(uint32_t)), "Usage of types longer than uint8_t not allowed") 
SO_>

Дело в том, что разрядность типа больше 32 как раз-таки допускается. Важно, чтобы сами числа не были больше данной разрядности (то есть, чтобы старший разряд чисел не превосходил 31)

Здравствуйте, SomeOne_TT, Вы писали:

SO_>sizeof(uint32_t)

А подобная конструкция имеет какой-то тайный смысл?

Здравствуйте, T4r4sB, Вы писали:

TB>Здравствуйте, SomeOne_TT, Вы писали:

SO_>>sizeof(uint32_t)

TB>А подобная конструкция имеет какой-то тайный смысл?

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

ну, если char, скажем, шестнадцатибитный , то функция вернет значение 2.

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

Здравствуйте, _hum_, Вы писали:

__>Разрабатываю класс, который предполагает в качестве исходных данных для создания своего объекта и работы с ним сторонний массив целых чисел, для примера, типа long.
__>Как бы наиболее простым и явным образом намекнуть пользователю класса (не прибегая к справке), что массив не должен содержать целых, выходящих за 32-разряда (это важно для платформ, где long 64-разрядный)?
Лучший намёк будет в названии метода или класса.
ClassFor32bitValues
obj->append_32bit(values)

__>[Ограничения связаны с особенностями бинарной сериализации объектов данного класса]

А если бы вы писали метод например mod_sqrt(a,m) который на вход принимает только простое число m. Как бы вы это выразили?
Пишем в комментариях и документации и в debug версии ставим assert.

Здравствуйте, kov_serg, Вы писали:

_>Здравствуйте, _hum_, Вы писали:

__>>Разрабатываю класс, который предполагает в качестве исходных данных для создания своего объекта и работы с ним сторонний массив целых чисел, для примера, типа long.
__>>Как бы наиболее простым и явным образом намекнуть пользователю класса (не прибегая к справке), что массив не должен содержать целых, выходящих за 32-разряда (это важно для платформ, где long 64-разрядный)?
_>Лучший намёк будет в названии метода или класса.
_>ClassFor32bitValues
obj->>append_32bit(values)
У меня сейчас класс имеет название C3DPointsSeries (серия точек в 3-д пространстве). Не хотелось бы название понятия высокого уровня абстракции засорять техническими деталями...

__>>[Ограничения связаны с особенностями бинарной сериализации объектов данного класса]

_>А если бы вы писали метод например mod_sqrt(a,m) который на вход принимает только простое число m. Как бы вы это выразили?
_>Пишем в комментариях и документации и в debug версии ставим assert.
С простыми другая ситуация — там из алгоритма понятно. Да и деться некуда — нет такого типа, как "простые числа".

Я вот думаю, может, ввести какой

typedef long _32_bit_values_restricted_long

или просто 
typedef long restricted_long

и использовать его всюду вместо long?

Здравствуйте, _hum_, Вы писали:

_>>Лучший намёк будет в названии метода или класса.
_>>ClassFor32bitValues
obj->>>append_32bit(values)
__>У меня сейчас класс имеет название C3DPointsSeries (серия точек в 3-д пространстве). Не хотелось бы название понятия высокого уровня абстракции засорять техническими деталями...
Назовите C3D32bitPointsSeries или C3DPointSeriesLimitedEditionWith32bitValues или C3DPointSeries::Impl32bit

__>>>[Ограничения связаны с особенностями бинарной сериализации объектов данного класса]
А что мешает эту явность в сериализваторе добавать, а не в C3DPointSeries? Если значения не возможно представить в сериализаторе пусть кидает исключения или как-то сообщает об ошибке.
log(-1) -- тоже ведь никто не заморачивается добавлением нового типа. Большинство вкурсе что область определения этой фуннкции положительные числа
или factorial(x) он уже после 170 уже в double не лезит. Поэтом используют lfact — логарифм факториала или lgamma.
Что вам мешает если сериализатор не может это записать использовать другой расширенный сериализатор.

_>>А если бы вы писали метод например mod_sqrt(a,m) который на вход принимает только простое число m. Как бы вы это выразили?
_>>Пишем в комментариях и документации и в debug версии ставим assert.
__>С простыми другая ситуация — там из алгоритма понятно.
Вот как из такого алгоритма сходу можно понять что для не простых модулей будет лажа.

__>Да и деться некуда — нет такого типа, как "простые числа".
Всегда можно добавить такой тип. Просто смысла в этом нет.

__>Я вот думаю, может, ввести какой
__>

__>typedef long _32_bit_values_restricted_long
__>

__>

__>или просто 
__>typedef long restricted_long
__>

__>и использовать его всюду вместо long?
тогда уж struct restricted_value. А вы точно уверены что от такого ограждения будет больше пользы чем вреда?

Здравствуйте, _hum_, Вы писали:

__>Разрабатываю класс, который предполагает в качестве исходных данных для создания своего объекта и работы с ним сторонний массив целых чисел, для примера, типа long.

Гуглите strong types.

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