- 1
- 2
- 3
a = nil
--или так
a = {nil}-
Lua / Говнокод #19976
+13
Встречал несколько раз, не понимаю зачем эдакое делать
Запостил:
Sfabrikan,
10 Мая 2016
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
print(a)
Назначил ему нил, но выдало нил.
ну и 0 != 0.0, но 1 == 0.999999
И прочей хуеты
Когда ObjC придумывали, не было еще у геев моды на apple, да и ЯП для Apple он еще не стал
вот http://nshipster.com/nil/
nil -- указатель в нуль
NULL это от сей досталось
NSNull это объект такой (нулбожект паттерн)
А еще у нас там есть YES, NO, true, false и 0
Им Dylan дали - пиши! Не хочу писать, хочу надстройку над сишкоблядством
сейчас они все свифтят
Интересно, если найдут такую строчку в исходниках, привлекут ли к ответственности?
print(allah) --nil
Xyu = nil
Особенно полезно было так делать, чтобы большую переменную не засосало в замыкание вместе с остальными.
Все считают, что если у объекта есть финализатор, то он сдохнет быстрее. А объект с финализатором после смерти попадает в очередь на финализацию и живет там неопределенное время, для того, что бы запустить свой финализатор. Пустой финализатор, Карл!
А диспоз? Диспоз, вызванный в конце метода, продлевает жизнь объекту до конца метода, особенно это бредово, когда в объекте нечего диспозить. Просто - "а пошел ты нахуй, сборщик мусора, пусть объект еще поживет, и может даже попадет в следующее поколение!"
это ведь ненадолго, верно?
GC спокойно удалил бы объект до асинхронного вызова, так как на него нет ссылок. Так придется ждать пока await вернет результат, а когда это произойдет никто не знает.
Кегги просто не разобрался, вот и хуйню пишет.
Твой ник читается иначе
Я изначально говорил, что так пишут мудаки, не?
каждый знает что финализации тебе не гарантируется
нет не так
ЧТООООООО?!!!!
финализацяи вызовеца когда случится GC, а он может случиться никогда
или это в jvm так, а в clr иначе?
Ну так и что ты изначально хотел сказать?
ну приведи мне пример зачем он нужен
ну а делать пустой финализатор "чтобы сдох быстрее" это даже не пидарство в квадрате, это факториал
"О помощи сборщику в C# - финализаторы! Блядские финализаторы!
Все считают, что если у объекта есть финализатор, то он сдохнет быстрее. А объект с финализатором после смерти попадает в очередь на финализацию и живет там неопределенное время, для того, что бы запустить свой финализатор. Пустой финализатор, Карл!
А диспоз? Диспоз, вызванный в конце метода, продлевает жизнь объекту до конца метода, особенно это бредово, когда в объекте нечего диспозить. Просто - "а пошел ты нахуй, сборщик мусора, пусть объект еще поживет, и может даже попадет в следующее поколение!""
вот еще баловаться
А вообще говно, да. Я про финализаторы уже напрочь забыл, ибо они не нужны. Вообще не нужны. Вообще за использование финализаторов в шарпе нужно больно бить по рукам линейкой, а то и пинком под сраку назад, к крестоблядям.
Ну почему... Можно сделать, чтобы они убивали прогу нахуй, если ты ресурс забыл освободить. Быстро приучит юзать using и не забывать про Dispose ;)
https://msdn.microsoft.com/ru-ru/library/b1yfkh5e(v=vs.100).aspx
Но несмотря на то, что это МС, так делать низя.
Во-первых, заебёшься финализаторы писать. Которые нахуй не нужны, ага.
Во-вторых, ресурсы кончатся, а GC не будет нихуя убирать. Потому что ему похуй на ресурсы, он будет курить бамбук, пока память есть.
В следствие, и это самое страшное, на тестовой машине будут убираться ресурсы, потому что памяти мало, а GC убирается часто, а вот в продакшене с 256Гб оперативы, финалайзеры будут вызываться чуть реже, чем никогда. То есть весь спектр утекающих ресурсов доступен теперь и в шарпике!
А там разве нет костыля с вызовом гц и финалайзеров по таймеру, а не только по нехватке памяти?
Возможна даже ситуация, что у тебя ООМ намечается, из кучи выкинуть нечего, GC лезет в очередь на финализацию, пытается вызвать финализатор некоторого класса, а он ни разу не вызывался и не скомпилен, а памяти на компиляцию уже нет...
Ну вообще да. Там время вызова регулируется от результатов предыдущих сборов. Гибкость
>> Или чистит только поколение 0 (свежесозданные мелкие объекты).
До того момента, пока не сожрется больше энного количества памяти, потом прихватывает первое. а второе только в преддверии ООМ
собственно он почти в любом ЯП с RC или GC есть
0 == nil
1 == { nil }
2 == { nil, { nil } }
...
N == { nil } + { N-1 }
print(a) --nil