p
Айфонопроблемы
Size: a a a
2020 May 07
B
Тогда вместо шарика от пинг-понга должна быть 32-х киллограмовая гиря :-D
Лол😂
B
Айфонопроблемы
У меня на ведре то-же саиое, я уже репортил
B
типа такого
protocol Container₀: TypedObject {}
protocol Container₁: TypedObject {
associatedtype ContainedObject
}
protocol Container₂: TypedObject {
associatedtype ContainedObject₁
associatedtype ConatainedObject₂
}
extension Int: Container₀ {}
extension Array: Container₁ {
typealias ContainedObject = Element
}А в телеге рендерит
2020 May 08
B
NL
Переслано от Dr. Friedrich von Ne...
Сегодня мне приснилось, как я дебажу кота. Он почему-то завис на инициализации, и мне пришлось разбираться, в чём проблема. Оказалось — дедлок где-то в конфигурации DI-контейнера. Зачем в коте был DI-контейнер — блин, не знаю. Но кот был на сишарпе написан!
NI
Ммммм
NI
Мсье с опечаткой пришел к нам
NI
Переслано от Dr. Friedrich von Never
Сегодня мне приснилось, как я дебажу кота. Он почему-то завис на инициализации, и мне пришлось разбираться, в чём проблема. Оказалось — дедлок где-то в конфигурации DI-контейнера. Зачем в коте был DI-контейнер — блин, не знаю. Но кот был на сишарпе написан!
Знатно
NI
Кхм, строка есмь массив символов, символ есмь байт или череда оных
S
фак еах
S
заебенил хаерордер тайпс
S
S
Ммммм
Вот секс?
S
на изичах
S
завидуйте
p
Зацените мои наркоманские мысли по поводу менеджмента памяти:
1. По умолчанию объекты хранятся на стеке.
2. Есть Copy и не-Copy типы. Первые при передаче в функции копируются всегда, вторые муваются (типо как в расте).
3. Есть Movable и не-Movable типы данных. По умолчанию тип Movable - значит при передаче в качестве аргумента он будет муваться. Если объект не Movable, значит его владение нельзя никуда передавать.
4. Предыдущий пункт нужен чтобы провернуть следующую штуку. Будет встроенный тип Ref (ссылка), который сам Movable, а внутри держит не-Movable тип (ну обычный указатель, хули). Но как вы уже поняли внутрь него нельзя поместить обычный тип так как он Movable. Для того чтобы сделать !Movable тип, можно использовать:
1. Pin, который гарантирует что данные не уйдут со стека.
2. Box, который гарантирует что данные хранятся в динамической памяти и не сдвинутся.
3. Rc.
Ну и может ещё пару умных указателей если понадобятся.
5. Итого как это будет работать: если вам необходимо передать из метода ссылку в другой метод на данные на стеке, вам нужно их припинить. Сам пин это просто маркер, то есть он зиро кост и нужен только для борроу чекера. Затем создаётся ссылка и передается в функцию. Там функция делает чё она хочет с ссылкой как с обычным объектом (как в расте).
6. Если хочется передать ссылку в другой поток то будешь огорчён потому что ссылки не Send, поэтому создавай что-то другое.
7. У меня нет никаких глобальных переменных от слова совсем, так что передать ссылку куда-то так чтобы она стала невалидной невозможно (ну на самом деле не оч так, смотри следующий пункт).
И все вроде заебись (или нет), но я хз чё делать с возвратом ссылки из метода наверх. Как проверить, закончилось время жизни внутренних данных или нет. Вообще зачем я это все придумал - чтобы избавиться от лайфтаймов. Но хз как чекать возвращаемую ссылку без лайфтаймов. Не ну я представляю как это можно сделать, но кмк это сильно удлинит время компиляции из-за проверки всего лайфтайма объекта и ссылок на него.
Оцените по шкале юзабкльности от 1 до 10
1. По умолчанию объекты хранятся на стеке.
2. Есть Copy и не-Copy типы. Первые при передаче в функции копируются всегда, вторые муваются (типо как в расте).
3. Есть Movable и не-Movable типы данных. По умолчанию тип Movable - значит при передаче в качестве аргумента он будет муваться. Если объект не Movable, значит его владение нельзя никуда передавать.
4. Предыдущий пункт нужен чтобы провернуть следующую штуку. Будет встроенный тип Ref (ссылка), который сам Movable, а внутри держит не-Movable тип (ну обычный указатель, хули). Но как вы уже поняли внутрь него нельзя поместить обычный тип так как он Movable. Для того чтобы сделать !Movable тип, можно использовать:
1. Pin, который гарантирует что данные не уйдут со стека.
2. Box, который гарантирует что данные хранятся в динамической памяти и не сдвинутся.
3. Rc.
Ну и может ещё пару умных указателей если понадобятся.
5. Итого как это будет работать: если вам необходимо передать из метода ссылку в другой метод на данные на стеке, вам нужно их припинить. Сам пин это просто маркер, то есть он зиро кост и нужен только для борроу чекера. Затем создаётся ссылка и передается в функцию. Там функция делает чё она хочет с ссылкой как с обычным объектом (как в расте).
6. Если хочется передать ссылку в другой поток то будешь огорчён потому что ссылки не Send, поэтому создавай что-то другое.
7. У меня нет никаких глобальных переменных от слова совсем, так что передать ссылку куда-то так чтобы она стала невалидной невозможно (ну на самом деле не оч так, смотри следующий пункт).
И все вроде заебись (или нет), но я хз чё делать с возвратом ссылки из метода наверх. Как проверить, закончилось время жизни внутренних данных или нет. Вообще зачем я это все придумал - чтобы избавиться от лайфтаймов. Но хз как чекать возвращаемую ссылку без лайфтаймов. Не ну я представляю как это можно сделать, но кмк это сильно удлинит время компиляции из-за проверки всего лайфтайма объекта и ссылок на него.
Оцените по шкале юзабкльности от 1 до 10
p
заебенил хаерордер тайпс
Ты говорил у тя только лексер готов
S
Ты говорил у тя только лексер готов
это для лексера
B
Зацените мои наркоманские мысли по поводу менеджмента памяти:
1. По умолчанию объекты хранятся на стеке.
2. Есть Copy и не-Copy типы. Первые при передаче в функции копируются всегда, вторые муваются (типо как в расте).
3. Есть Movable и не-Movable типы данных. По умолчанию тип Movable - значит при передаче в качестве аргумента он будет муваться. Если объект не Movable, значит его владение нельзя никуда передавать.
4. Предыдущий пункт нужен чтобы провернуть следующую штуку. Будет встроенный тип Ref (ссылка), который сам Movable, а внутри держит не-Movable тип (ну обычный указатель, хули). Но как вы уже поняли внутрь него нельзя поместить обычный тип так как он Movable. Для того чтобы сделать !Movable тип, можно использовать:
1. Pin, который гарантирует что данные не уйдут со стека.
2. Box, который гарантирует что данные хранятся в динамической памяти и не сдвинутся.
3. Rc.
Ну и может ещё пару умных указателей если понадобятся.
5. Итого как это будет работать: если вам необходимо передать из метода ссылку в другой метод на данные на стеке, вам нужно их припинить. Сам пин это просто маркер, то есть он зиро кост и нужен только для борроу чекера. Затем создаётся ссылка и передается в функцию. Там функция делает чё она хочет с ссылкой как с обычным объектом (как в расте).
6. Если хочется передать ссылку в другой поток то будешь огорчён потому что ссылки не Send, поэтому создавай что-то другое.
7. У меня нет никаких глобальных переменных от слова совсем, так что передать ссылку куда-то так чтобы она стала невалидной невозможно (ну на самом деле не оч так, смотри следующий пункт).
И все вроде заебись (или нет), но я хз чё делать с возвратом ссылки из метода наверх. Как проверить, закончилось время жизни внутренних данных или нет. Вообще зачем я это все придумал - чтобы избавиться от лайфтаймов. Но хз как чекать возвращаемую ссылку без лайфтаймов. Не ну я представляю как это можно сделать, но кмк это сильно удлинит время компиляции из-за проверки всего лайфтайма объекта и ссылок на него.
Оцените по шкале юзабкльности от 1 до 10
1. По умолчанию объекты хранятся на стеке.
2. Есть Copy и не-Copy типы. Первые при передаче в функции копируются всегда, вторые муваются (типо как в расте).
3. Есть Movable и не-Movable типы данных. По умолчанию тип Movable - значит при передаче в качестве аргумента он будет муваться. Если объект не Movable, значит его владение нельзя никуда передавать.
4. Предыдущий пункт нужен чтобы провернуть следующую штуку. Будет встроенный тип Ref (ссылка), который сам Movable, а внутри держит не-Movable тип (ну обычный указатель, хули). Но как вы уже поняли внутрь него нельзя поместить обычный тип так как он Movable. Для того чтобы сделать !Movable тип, можно использовать:
1. Pin, который гарантирует что данные не уйдут со стека.
2. Box, который гарантирует что данные хранятся в динамической памяти и не сдвинутся.
3. Rc.
Ну и может ещё пару умных указателей если понадобятся.
5. Итого как это будет работать: если вам необходимо передать из метода ссылку в другой метод на данные на стеке, вам нужно их припинить. Сам пин это просто маркер, то есть он зиро кост и нужен только для борроу чекера. Затем создаётся ссылка и передается в функцию. Там функция делает чё она хочет с ссылкой как с обычным объектом (как в расте).
6. Если хочется передать ссылку в другой поток то будешь огорчён потому что ссылки не Send, поэтому создавай что-то другое.
7. У меня нет никаких глобальных переменных от слова совсем, так что передать ссылку куда-то так чтобы она стала невалидной невозможно (ну на самом деле не оч так, смотри следующий пункт).
И все вроде заебись (или нет), но я хз чё делать с возвратом ссылки из метода наверх. Как проверить, закончилось время жизни внутренних данных или нет. Вообще зачем я это все придумал - чтобы избавиться от лайфтаймов. Но хз как чекать возвращаемую ссылку без лайфтаймов. Не ну я представляю как это можно сделать, но кмк это сильно удлинит время компиляции из-за проверки всего лайфтайма объекта и ссылок на него.
Оцените по шкале юзабкльности от 1 до 10
Я не шибко эксперт, но вроде в хрусте Pin не для стека, а для кложур и футурок