Войти
ПрограммированиеФорумОбщее

Типизированные int'ы (2 стр)

Страницы: 1 2 3 49 Следующая »
#15
17:07, 13 июля 2019

Suslik
> Какие существуют реализации этой идеи?
Я бы назвал это "разгруженным итератором".
Suslik
>Как реализовать эту идею в более слабых языках вроде glsl?
Это же С. Надеюсь на асм еще ни кто не позарился.

#16
17:09, 13 июля 2019

proposal для C++: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0109r0.pdf

#17
17:14, 13 июля 2019

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

float damage = GetTotalDamage(shipIndex, asteroidIndex);
и всё бы здорово, только функция может быть реализована так:
float GetTotalDamage(int asteroidIndex, int shipIndex);
два аргумента перепутаны местами, при прочтении кода у тебя никаких вопросов не возникнет и он скомпилится, хотя не должен.

#18
17:33, 13 июля 2019

Имхо это надо как то подтянуть к единицам измерения в численных типах.
А может даже и не только в численных.

#19
17:40, 13 июля 2019

=A=L=X=
> Имхо это надо как то подтянуть к единицам измерения в численных типах.
> А может даже и не только в численных.
вполне здравая идея. в реализации https://github.com/joboccara/NamedType можно сказать, что WidthTag — это единица измерения величины типа double:

using Width = NamedType<double, struct WidthTag>;
далее если два типа используют один и тот же тег, то они оказываются совместимы, что имеет смысл.
#20
17:44, 13 июля 2019

Как бы этой идее 100 лет в обед. Все упирается в лень и вирусность такого подхода.

#21
17:50, 13 июля 2019

Suslik
> using Width
Самый геммор будет с вычислениями ([здесь_тип_переменной]):

[Width] + [Width] = [Width] 
[Width] * [Width] /= [Width] 
и т.д.
#22
(Правка: 17:50) 17:50, 13 июля 2019

Suslik
> Почему система не распространилась до того, как я её (пере?)изобрёл?
Потому что можно хранить типизированный указатель вместо индекса в контейнере?
Вообще хранить индекс/итератор контейнера моветон, имхо. Завтра кто-нибудь удалит элемент из контейнера и все сломается. И даже типизированный указатель тебя от этого не спасет.

#23
(Правка: 17:56) 17:55, 13 июля 2019

MrShoor
> Потому что можно хранить типизированный указатель вместо индекса в контейнере?
а хранить raw pointer'ы на что попало — не моветон? да и мало ли существует ситуаций, где указатели применять нельзя? — сериализация, шейдеры, контейнеры с изменяющимся размером, итп. вообще проблема более глобальная, чем хранение индексов, индексы — это только частный случай. в общем случае величины, хранящие разные по смыслу переменные, нет смысла присваивать друг другу, даже если они формально одного типа. не смысла ширине окна присвоить левел персонажа, хотя оба — инты. такой код не должен компилиться.

#24
(Правка: 18:02) 18:01, 13 июля 2019

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

struct Ship //аналог типизированного указателя/индекса. сами данные хранятся в ShipData
{
  int index;
};
struct Asteroid
{
  int index;
};

struct ShipData //тут хранятся данные
{
  Asteroid asteroidTarget; //индекс астероида-цели
}
layout(std430, binding = 0, set = 0) buffer Ships
{
   ShipData data[];
} ships;

float GetTotalDamage(Ship ship, Asteroid asteroid); //нельзя перепутать

#25
(Правка: 18:11) 18:10, 13 июля 2019

Suslik
> в реализации https://github.com/joboccara/NamedType можно сказать, что WidthTag
> — это единица измерения величины типа double:

Ну да, я просто как только твой первопост прочитал у меня сразу же в голове зазвучало "10-ый корабль", "20-ый астероид". Или "10 астероидов" и "20 кораблей" - ведь речь про size_t, здесь это неотличимо по сути. А суть как раз в единицах измерения.
Поэтому если еще правила конверсии единиц измерения увидеть в операциях над кораблями и астероидами - будет вообще попадание более чем в суть и глаз.

#26
18:15, 13 июля 2019

P.S.

А ведь при

almost::vector<Ship> vec 
операция vec.size() должна возвращать как раз именно unit<size_t,Ship> или типа того. Тоже логично.
Имхо да, тут надо некий unit< type, tag >

#27
19:06, 13 июля 2019

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

#28
(Правка: 19:20) 19:18, 13 июля 2019

SDC
> Сразу на ум приходит всякая функциональщина, где нельзя пихать все что угодно
> куда ни попадя.

Lisp нетипизированный язык, так что не надо грязи. А с него всё начиналось в мире ФЯ.
Меня вообще выворачивает от самого такого построения предложения. :)
Но я знаю ответ: в нём речь идёт о Haskell. ФЯ ФЯ рознь, а Haskell - это еще другое дело.

#29
20:04, 13 июля 2019

Suslik
> овершенно нормальным считается 80% времени работы с этим прекрасным API тратить
> на отладку, когда GL_INVALID_OPERATION вываливается, так как image unit был
> передан вместо texture id или texture id был передан вместо texture block или
> texture block вместо sampler index, хотя всех этих проблем вообще бы не
> существовало, если бы они

это ж какие же кривые руки

Страницы: 1 2 3 49 Следующая »
ПрограммированиеФорумОбщее