Метатабличный / Говнокод #19976 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
a = nil
--или так
a = {nil}

Встречал несколько раз, не понимаю зачем эдакое делать

Запостил: Sfabrikan Sfabrikan, (Updated )

Комментарии (75) RSS

  • Египтяне ведь будут голодать! Нил ведь не резиновый!
    Ответить
  • Только сейчас узнал, что nil расшифровывается как not in list.
    Ответить
  • Ну если переменные имеют уже какие то значения, то эдакое имеет смысл. Но если так "объявлять" то не имеет смысла, луа автоматом любой неведомой хуйне выдаст нил
    Ответить
      • god = nil
        Интересно, если найдут такую строчку в исходниках, привлекут ли к ответственности?
        Ответить
        • А если написать allah = nil, то проснёшься с перерезанным горлом?
          Ответить
          • Можно даже не объявлять так. Lua - атеист, он не верит в существования неопределенных переменных.

            print(allah) --nil
            Ответить
          • if not allah then --кто-то сказал нет аллаха?
                       jihad() --Запускаем джихад
            end
            Ответить
  • Видел такое в JS. Так добрые люди помогали сборщику мусора.
    Особенно полезно было так делать, чтобы большую переменную не засосало в замыкание вместе с остальными.
    Ответить
    • О помощи сборщику в C# - финализаторы! Блядские финализаторы!

      Все считают, что если у объекта есть финализатор, то он сдохнет быстрее. А объект с финализатором после смерти попадает в очередь на финализацию и живет там неопределенное время, для того, что бы запустить свой финализатор. Пустой финализатор, Карл!

      А диспоз? Диспоз, вызванный в конце метода, продлевает жизнь объекту до конца метода, особенно это бредово, когда в объекте нечего диспозить. Просто - "а пошел ты нахуй, сборщик мусора, пусть объект еще поживет, и может даже попадет в следующее поколение!"
      Ответить
      • > Диспоз, вызванный в конце метода, продлевает жизнь объекту до конца метода

        это ведь ненадолго, верно?
        Ответить
        • Смотря какой метод

          public async void SomeMethod()
                  {
                      var sc = new SomeClass();
                      //.... some code with sc
                      var x = await SomeAsyncMethod();
                      //.... some code without sc
                      sc.Dispose();
                      
                  }
          
                  class  SomeClass: IDisposable
                  {
                      public void Dispose()
                      {
                         //just for lulz
                      }
                  }


          GC спокойно удалил бы объект до асинхронного вызова, так как на него нет ссылок. Так придется ждать пока await вернет результат, а когда это произойдет никто не знает.
          Ответить
          • Эм... А в этом плане Dispose() как-то отличается от любого другого метода? Если в конце будет sc.DoSomethingUseless(), что-то изменится?
            Ответить
            • Dispose ничем не отличается от любого другого метода. Кроме того, что это единственный метод интерфейса IDisposable и является необходимым условием для одноимённого паттерна, для которого, в свою очередь, существует в грамматике языка конструкция using.

              Кегги просто не разобрался, вот и хуйню пишет.
              Ответить
              • >>Кегги просто не разобрался, вот и хуйню пишет.

                Твой ник читается иначе
                Ответить
            • Нет, но вызывает он в контексте "уничтожения" обьекта
              Ответить
          • Потому что только мудаки так пишут. Нормальные пишут так:
            public async void SomeMethod()
                {
                    using (var sc = new SomeClass());
                    {
                        //.... some code with sc
                    }
                    var x = await SomeAsyncMethod();
                    //.... some code without sc    
                }
            
                class  SomeClass: IDisposable
                {
                    public void Dispose()
                    {
                       //just for lulz
                    }
                }
            Ответить
            • То есть ты вообще не читаешь комментарии?

              Я изначально говорил, что так пишут мудаки, не?
              Ответить
      • так только пидарасы считают

        каждый знает что финализации тебе не гарантируется
        Ответить
          • то!

            финализацяи вызовеца когда случится GC, а он может случиться никогда

            или это в jvm так, а в clr иначе?
            Ответить
            • А еще может как ебануть ядерной ракетой в сервер и тогда даже присвоение не сработает.
              Ну так и что ты изначально хотел сказать?
              Ответить
              • что существует так мало ситуаций, когда нужен финализатор, что можно считать что их нет вовсе

                ну приведи мне пример зачем он нужен


                ну а делать пустой финализатор "чтобы сдох быстрее" это даже не пидарство в квадрате, это факториал
                Ответить
                • просто перечитай. Внимательно. По слогам

                  "О помощи сборщику в C# - финализаторы! Блядские финализаторы!

                  Все считают, что если у объекта есть финализатор, то он сдохнет быстрее. А объект с финализатором после смерти попадает в очередь на финализацию и живет там неопределенное время, для того, что бы запустить свой финализатор. Пустой финализатор, Карл!

                  А диспоз? Диспоз, вызванный в конце метода, продлевает жизнь объекту до конца метода, особенно это бредово, когда в объекте нечего диспозить. Просто - "а пошел ты нахуй, сборщик мусора, пусть объект еще поживет, и может даже попадет в следующее поколение!""
                  Ответить
                  • я никогда не читаю комменты, на которые отвечаю

                    вот еще баловаться
                    Ответить
                  • Не шуми, сам же в зелёный не оформил, люди путаются.

                    А вообще говно, да. Я про финализаторы уже напрочь забыл, ибо они не нужны. Вообще не нужны. Вообще за использование финализаторов в шарпе нужно больно бить по рукам линейкой, а то и пинком под сраку назад, к крестоблядям.
                    Ответить
                    • > не нужны
                      Ну почему... Можно сделать, чтобы они убивали прогу нахуй, если ты ресурс забыл освободить. Быстро приучит юзать using и не забывать про Dispose 😉
                      Ответить
                      • А еще есть люди, которые в финализаторе диспоз вызывают. Это приводит к тому, что ты думаешь, что файл закрылся, а он только собирается... Очень приятно попытаться его открыть и охуеть
                        Ответить
                        • Не поверишь, но этому сам мелкомягкий учит.
                          https://msdn.microsoft.com/ru-ru/library/b1yfkh5e(v=vs.100).aspx

                          Но несмотря на то, что это МС, так делать низя.
                          Во-первых, заебёшься финализаторы писать. Которые нахуй не нужны, ага.
                          Во-вторых, ресурсы кончатся, а GC не будет нихуя убирать. Потому что ему похуй на ресурсы, он будет курить бамбук, пока память есть.
                          В следствие, и это самое страшное, на тестовой машине будут убираться ресурсы, потому что памяти мало, а GC убирается часто, а вот в продакшене с 256Гб оперативы, финалайзеры будут вызываться чуть реже, чем никогда. То есть весь спектр утекающих ресурсов доступен теперь и в шарпике!
                          Ответить
                          • Лол. Я больше чем уверен, что на мсдн не описан подробно процесс сборки мусора. В итоге все новички будут юзать указание M$ потому что они авторы техи... Как это все-таки печально...
                            Ответить
                          • > никогда
                            А там разве нет костыля с вызовом гц и финалайзеров по таймеру, а не только по нехватке памяти?
                            Ответить
                            • гц по таймеру, а вот финализаторы, емнип, выполняется как Бог на душу положит

                              Возможна даже ситуация, что у тебя ООМ намечается, из кучи выкинуть нечего, GC лезет в очередь на финализацию, пытается вызвать финализатор некоторого класса, а он ни разу не вызывался и не скомпилен, а памяти на компиляцию уже нет...
                              Ответить
                            • Там нет таймера, как такового. У ГЦ довольно сложная логика вызова, но факт остаётся фактом: если программа не создаёт множества объектов, то ГЦ не вызывается. Или чистит только поколение 0 (свежесозданные мелкие объекты).
                              Ответить
                              • >> Там нет таймера, как такового.

                                Ну вообще да. Там время вызова регулируется от результатов предыдущих сборов. Гибкость

                                >> Или чистит только поколение 0 (свежесозданные мелкие объекты).

                                До того момента, пока не сожрется больше энного количества памяти, потом прихватывает первое. а второе только в преддверии ООМ
                                Ответить
      • Диспоз вообще к сборщику мусора и к жизни объекта не имеет никакого отношения. Он нужен для освобождения неуправляемых ресурсов.
        Ответить
    • я обжси для этого есть вик референс

      собственно он почти в любом ЯП с RC или GC есть
      Ответить
  • А помните, как строятся числа в теории множеств...

    0 == nil
    1 == { nil }
    2 == { nil, { nil } }
    ...
    N == { nil } + { N-1 }
    Ответить
  • Надо было вот так вот:
    null = nil
    -- или null = {nil}
    ...
    -- далее в коде...
    a = null
    Ответить
  • В голове пролетали отрывки из прошлой ночи. Что на меня нашло? Я знаю, что все люди бисексуальны и даже самого натурального натурала можно соблазнить. Но Паша не очень-то меня и соблазнял. Я же мог отказаться.
    Ответить

Добавить комментарий

Я, guest, находясь в здравом уме и твердой памяти, торжественно заявляю:

    А не использовать ли нам bbcode?


    8