ЙажаСценарий / Говнокод #25571 Ссылка на оригинал

0

  1. 1
  2. 2
https://habr.com/ru/post/449368/
Ко-ко-ко-ко-ко-кой багор )))

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

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

  • Через 5 лет JS станет сложнее для понимания чем С++
    Он будет как С++ только очень хуевый
    Ответить
    • Верно, но и C++ будет отвергнут. Программисты станут кодить на языке тела.
      Ответить
    • Здравия желаю! Вам выписан штраф в размере 1000 (одной тысячи) рублей по статье 20.1 КоАП РФ за нецензурную брань в общественном месте. Оплатить штраф вы можете в любом отделении «Сбербанка» с восьми утра до девяти утра по чётным четвергам.
      Ответить
    • >Через 5 лет JS станет сложнее для понимания чем С++
      >Он будет как С++ только очень хуевый

      Я ещё джва года назад это ванговал.
      Ответить
  • - Проснитесь, у вас абстракция протекла!
    - А я и нProgram halted due to out of memory exception
    Ответить
    • причем тут висячие указатели?
      Ответить
  • А стандарт C++ как-то регламентирует как устроена в кишках std::string? Можно ли там такую же питушню забубенить?
    Ответить
    • substr там всегда копия


      если бы строки в языке без гц выстраивали бы такие леса зависимостей то была бы жопа
      Ответить
      • > леса зависимостей
        Чем бы дитя не тешилось, лишь бы графы зависимостей не зацикливало. А с лисами и счётчик ссылок вполне справится.
        Ответить
  • в жабе тоже по этим граблям ходили

    ну а что делть? вот есть у тебя строка на гигабайт и я 20 раз взял у нее подстроку на 100 мегабайт

    копировть 100 строк? так память кончица
    не копировать? тогда как загарбиить большую строку?


    всюду жопа!

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

      Мне больше нравится схема с явными string (новая строка) и string_ref (ссылка на кусок существующей строки). И лишних копирований нету и бесполезное говно в памяти не копится.
      Ответить
      • Мне тоже кажется что явное лучше неявного
        Но тогда придется всегда думать

        Сишник и крестовик привыкли думать про память. Каждый раз делая что-то они понимают что вот тут память выделяется и заполняется, а тут у нас просто референс

        А джаверы и джаваскриптеры о таких вещах не думают, потому пришлось сделать для них такое вот упращение
        Ответить
        • Х.з., я бы и для них оставил тупое копирование. Ибо "мне не хватило памяти потому что я сейчас обрабатываю дохуя данных" воспринимается интуитивнее чем "мне не хватило памяти потому что я час назад обрабатывал дохуя данных от которых осталась пара строчек".

          А ref версию всегда можно навернуть поверх обычной. Для тех, кому это реально надо.
          Ответить
      • >Мне больше нравится схема с явными string (новая строка) и string_ref (ссылка на кусок существующей строки).

        Так все в яве и наслаждались O(1), а при необходимости явно писали new String (новая строка).
        Пока светлые умы не решили починить обезьянам «утечки».
        Ответить
    • >ну а что делть? вот есть у тебя строка на гигабайт и я 20 раз взял у нее подстроку на 100 мегабайт

      Это ещё в 7й или 8й версии "починили". Теперь trim работает не за няшные O(1), а за O(N).
      А что делать?
      В случае 100-мегабайтных строк несложно написать свою реализацию CharSequence c ожидаемым поведением.

      >а в стате много воды и петросянства ненужново совершенно
      habr.com — дальше не читал.
      Ответить
      • Да, именно починили, и все соснули

        Абстракция протекла. Нам врали, что в джава можно не думать про память и строки. А оказалось нужно думать.

        И только сраные сшинки, которые привыкли думать ВСЕГДА, посмеиваются себе в усы
        Ответить
        • Да не посмеиваются они. Просто wtfов меньше, в силу большего понимания.

          Вот, те же проблемы в языках с прямым управлением памятью:
          http://govnokod.ru/14458#comment214519

          Потому кстати у крестухов аллергия от одного слова КУЧА.
          На стеке, всё на стеке, лишь бы malloc не тупил и не отдавал null.
          Ответить
    • >ну а что делть? вот есть у тебя строка на гигабайт

      Ошибка уже здесь.
      Строки из-за своего внутреннего устройства чисто алгоритмически не годятся для мутации гигантских объёмов данных. Там же везде O(N) и копирование вылазит. Например та же конкатенация.

      В конечном итоге мы придём к старым-добрым лоу-левел технологиям постраничной адресации в 4k/2Mb. И обёртке в виде CharSequence & Appendable.

      Выделяем память chunkами размером в страницу и наслаждаемся O(1) substring, append и малой перепитушнёй размером не больше двух страниц.
      Ответить
      • А никто и не говорил про мутацию.
        Я считал файл на гигабайт и взял из него несколько байт сабстрингом, положил и в List и потек.

        Конечно, если делать серьезный хайлоад то надо думать о строках и рассматривать их как массив charов, но если это тупая тула то никто так не думает
        Ответить
        • Да не только мутации, но в целом переваривание и хранение.

          Ведь сперва нужно выделить под массив цельный кусок памяти в гигабайт.

          А это не так просто как кажется.

          sudo hugeadm --pool-pages-min 1GB:1
          hugeadm:WARNING: failed to set pool minimum to 1 became 0

          Например, у меня на машине свободно 5-6Gb, а свободного нефрагментированого гигабайта нет.
          Ответить
          • Ну значит тебя ждет свап:)

            Я согласен с тем, что по хорошему надо читать такую штуку кусочками. Но что делать если вчера у тебя было 10 мегабайт, а сегодня вдруг стал гигабайт? Все перпесать>?
            Ответить
            • В С++ те же проблемы с последовательными контейнерами вроде std::string, std::vector. Да и в С проблема никуда не исчезает.

              Потому сишкобляди/крестушки и используют всякие кастомные аллокаторы вроде jemalloc. Не от хорошей жизни это.

              >значит тебя ждет свап
              Не совсем. jvm всё-таки держит свободоное место дефрагментированным.
              Ответить
              • В си мне придется думать где выделять место. Врядли я выделю гиг на стеке, а если я буду выделять его в куче то задумаюсь о размерах.

                Хотя я конечно могу написать код который читает байты и реаллочит память и кладет их туда и наступить на те же грабли

                Про jvm не понял. Джава же резирвирует память для кучи, а не коммитит её.
                Ответить
                • Она при gc фактически дефрагментирует её, выделяя сплошной последовательно идущий блок памяти под объекты в young gen*.

                  А фрагментированные объекты, пережившие сборку, копирует в другое место, уже без фрагментации.

                  *В новых сборщиках оно устроено несколько иначе. Но эти сборщики заточены под 10/100 гигабайтные кучи
                  Ответить
        • >Я считал файл на гигабайт и взял из него несколько байт сабстрингом, положил и в List и потек.

          Да все знали про это.
          Ещё помню очень давно на ГК был пост в стиле
          new String(s)

          На что было указано, что не факт что это говно. Если s=bigString.substring(...)
          Т.к. он выполняет копирование, выделяя новую память.

          Когда люди делали такой конструктор, они ведь что-то соображали.
          /**
               * Initializes a newly created {@code String} object so that it represents
               * the same sequence of characters as the argument; in other words, the
               * newly created string is a copy of the argument string. Unless an
               * explicit copy of {@code original} is needed, use of this constructor is
               * unnecessary since Strings are immutable.
               */
          Ответить

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

Из-за тебя ушел bormand, guest!

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


    8