Jawa / Говнокод #26969 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
public static UUID fromString(String name) {
        String[] components = name.split("-");
        if (components.length != 5)
            throw new IllegalArgumentException("Invalid UUID string: "+name);
        for (int i=0; i<5; i++)
            components[i] = "0x"+components[i];

        long mostSigBits = Long.decode(components[0]).longValue();
        mostSigBits <<= 16;
        mostSigBits |= Long.decode(components[1]).longValue();
        mostSigBits <<= 16;
        mostSigBits |= Long.decode(components[2]).longValue();

        long leastSigBits = Long.decode(components[3]).longValue();
        leastSigBits <<= 48;
        leastSigBits |= Long.decode(components[4]).longValue();

        return new UUID(mostSigBits, leastSigBits);
    }

без префикса "0x" написать рабочий код было невозможно, очевидно
это хоть починили

https://github.com/openjdk/jdk/blob/jdk8-b120/jdk/src/share/classes/java/util/UUID.java#L191-L209

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

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

  • - Ох, о-о-о-о, ох, мертвая еда...
    - Леонид Ильич, переверните, у нас бумага кончилась, и мы вам речь на программистской оборотке напечатали...
    Ответить
  • Кстати, есть хоть одна прога, где реально юзаются поля UUID'а?
    Ответить
      • > 128-битное значение

        Ну вот и я об этом. Для 99.99% программ это просто уникальные 16 байт без какой-либо структуры.

        Но все пердолятся с парсингом "полей" разной длины, разделённых чёрточками. Обратная совместимость такая обратная совместимость. Там вроде время когда-то было и ещё что-то.
        Ответить
        • Был RFC с классами UUID'ов. Номер класса обозначался где-то в самой середине. Так вот в одном классе где-то в середине было время, в другом — ещё какая-то фигня.
          Ответить
          • Сейчас вроде везде последний класс, где тупо 124 бита рандома.
            Ответить
            • Смотрим RFC.

              The variant field determines the layout of the UUID.

              Значение 100 и 101 (двоичное) поля вариант означает юниксоидный UUID, описанный в RFC, который содержит время.

              Значение 110 означает UUID, совместимый с «Микрософтом».

              Другие варианты с точки зрения того RFC зарезервированы.
              Ответить
            • Читаю дальше.

              The version number is in the most significant 4 bits of the time stamp (bits 4 through 7 of the time_hi_and_version field).

              Оказывается, у UUID, описанного в RFC, ещё куча вариантов.

              1 The time-based version specified in this document.
              2 DCE Security version, with embedded POSIX UIDs.
              3 The name-based version specified in this document that uses MD5 hashing.
              4 The randomly or pseudo-randomly generated version specified in this document.
              5 The name-based version specified in this document that uses SHA-1 hashing.
              Ответить
              • И получается, что для версий 3, 4, 5 поля Timestamp и Clock Sequence содержат не время, а псевдослучайное число (версия 4) или хэш от какой-нибудь питушни (MD5 или SHA-1).
                Ответить
              • Самое страшное, что та древняя версия 1, которая содержала время, в поле Node должна была содержать MAC-адрес основного сетевого адаптера данной машины, т. е. UUID получался не совсем случайным.
                Ответить
                • Угу, и сливал твой мак. Именно поэтому я за четвёртую версию.
                  Ответить
                  • Надо просканировать ууиды из разного софта, отфильтровать первую версию, тогда есть шанс восстановить маки, принадлежащие разным компаниям (если, конечно, разработчики софта не догадались вместо реального мака вставлять фейковый).
                    Ответить
                    • > фейковый

                      Эээ... дык тогда вся суть пропадает, он уже не уникальный будет. Хотя китайцы и так поди поднасрали с сетевухами, у которых одинаковый мак.
                      Ответить
                      • Сейчас ещё бывают багры из-за китайских мобильников, которые каждые полчаса меняют мак на случайный. Вроде даже у «Айфона» есть такой режим. Теоретически это может вызывать коллизии между пользователями одной точки доступа.
                        Ответить
                        • конечно это вызовет бухор

                          AP пошлет отконнектит STA коли ты смениш мак
                          Ответить
                          • Ну не во время работы же он это делает, между коннектами просто меняет, чтобы не трекали.
                            Ответить
                            • между -- ради бога

                              Но AP тебя не узнает, и может выдать другой IP, например.


                              А дома его не узнали и не пустили в квартиру.
                              — Я столяр Кушаков! — закричал столяр.
                              — Рассказывай! — отвечали из квартиры и
                              заперли дверь на крюк и на цепочку.
                              Столяр Кушаков постоял на лестнице, плюнул и пошел на улицу.
                              Ответить
              • ого, так это я просто так не имею права uuid сгенерить?

                кстати, ты не инью
                Ответить
                      • ты спиздил мой акк
                        мироздание наказало тебя, спиздив твой

                        Олень подстреленный хрипит,
                        Лань, уцелев, резвится,
                        Тот караулит, этот спит -
                        И так весь мир вертится…
                        Ответить
                          • Я и Шекспира не цитировал, особенно в варианте "покровских ворот"

                            Нахватаешься тут у вас
                            Ответить
        • Да кто все-то?

          Кстати в жабе ууид до последнего времени был стремный, с маком и сиквенсом. Чтобы на одной ноде, сука, все были похожи, как сестры в-очёвски, а ты такой ищешь где там разница в 25 разряде. Дико бесило всегда, и лень проверять, стало ли лучше.
          Ответить
          • >а ты такой ищешь где там разница в 25 разряде
            похоже на мой BCD
            Windows Boot Loader
            -------------------
            identifier              {eee0502d-fecb-11e8-8360-a219fc908588}
            device                  partition=C:
            path                    \Windows\system32\winload.exe
            description             Windows 7
            locale                  en-US
            recoverysequence        {eee05031-fecb-11e8-8360-a219fc908588}


            Совсем разные UUID
            Ответить
    • Я юзаю в автоматических тестах как уникальный идентификатор сущности, если зачищать базу перед запуском теста невозможно.
      Ответить
      • Что-то специальное туда пишешь, чтобы отличать тестовые гуиды от боевых?
        Ответить
  • Всеж таки языке "всё-по-ссылке" испортили мне мозг.
    никак не могу привыкнуть к тому, что
    Petuh p(22);
    return p;

    и
    return Petuh(22);

    это две большие разницы.

    Причем начиная с +11 петух может быть некопируемым, но двигаемым (как юник) и тогда первый вариант вообще не скомпилируется.
    Ответить
    • Если тип перемещаемый, то оба варианта будут работать.

      А в третьих, NRVO конпеляторы применяли давным-давно, так что на практике первый вариант был не особо то и хуже.
      Ответить
      • >Если тип перемещаемый, то оба варианта будут работать.
        А почему он может мувнуть p? Потому что это последняя строчка, и оно больше не нужно?

        >NRVO конпеляторы
        да, эта оптимизация была, но компилятор не обязан же был..

        Вот если у меня не копируемый тип и с++03, то я вообще не могу так писать, хотя как-бы в теории он может и RVO
        Ответить
        • > Потому что это последняя строчка

          Именно так. В остальных строчках ты пишешь std::move() вручную, чтобы случайно не спиздить значение. А в момент return'а уже всем пофиг.

          > Не обязан

          Ну да. Но, тем не менее, многие на это надеялись. Иначе вместо возврата придётся юзать явное void foo(Petuh &out), а это некрасиво.

          > не копируемый тип

          Это да. Почти все оптимизации так работают. Сначала проверяется, что при стандартной семантике всё ок. А потом уже код выбрасывается. Более того, твой второй вариант тоже не работает если нечем копировать и/или мувать, проверь.
          Ответить
          • А вот еще пример:

            return Kuratnik{UncopyablePetuh(22)};


            А вот так точно не скококо
            UncopyablePetuh petuh(22);
            return Kuratnik{petuh};


            придется
            UncopyablePetuh petuh(22);
            return Kuratnik{std::move(petuh)};
            да?

            Мув же получает по ссылке, и возвращает по rvalue ref?
            Ответить
            • Все три твоих примера сконпелятся в с++11 и выше. Главное чтобы у них был либо мув либо копирование. Причём вызов мува будет выброшен.

              Да, всё так, невнимательно прочитал код.
              Ответить
              • Ого, даже так..

                ну так вот он точно отсосет, да?

                UncopyablePetuh petuh(22);
                Kuratnik result{petuh};
                return result;
                Ответить
                  • >Да, всё так, невнимательно прочитал код.

                    отож)) а я уже побежал проверять
                    struct Foo {};
                    struct Bar
                    {
                    	std::unique_ptr<Foo> ref;
                    };
                    
                    
                    Bar getFoo()
                    {
                    	auto foo = std::make_unique<Foo>();
                    	return Bar{foo}; //Тут ожидаемый хуй: can't use deleted кококококпирующий коко
                    }
                    Ответить
                      • Тогда он сразу замувает и бар и юника?)

                        А еще мне нравится что недвижимость и некопируемость влияет на дефолтные конструкторы.

                        Если в структуре есть хоть одно некопируемое поле, то дефолтный констнруктор копирования удаляется.
                        Ответить
                        • > сразу замувает

                          Да не, я просто хуйню пишу не думая. Мувалка у Bar и так сгенерится.

                          return Bar{std::move(foo)}; в общем.
                          Ответить
                          • вручную могу мувнуть, да.

                            А как питузы жили до 11? Возвращали через указатель?

                            Клиент выделял память, но не инициализировал ее?
                            Нельзяж там в RAII?

                            Тогда два раза звали котруктор? Или на куче?
                            Ответить
                            • Хуёво жили. Нельзя было например открыть файл и потом куда-то задвинуть или вернуть. Надо было сразу его создавать вложенным в нужное место или на куче.

                              На самом деле, писать на крестах до с++11 - тлен и безысходность.
                              Ответить
                              • понятно.

                                В некотором смысле это цена за RAII.

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

                                  Но это уже не RAII, да. Resource acquisition и initialization оказываются разбиты, надо не забывать что у объекта появилось невалидное состояние.
                                  Ответить
                                  • Дефолтный ктор приведет к методу Initize(), а это кал:)

                                    А вот у шапреев можно так (см ключ слово out):
                                    struct Petuz
                                        {
                                            public readonly int Iq;
                                    
                                            public Petuz(int iq)
                                            {
                                                Iq = iq;
                                                Console.WriteLine("Petz created");
                                            }
                                        }
                                    
                                    
                                        class Class1
                                        {
                                            static void CreatePetuz(out Petuz petuz)
                                            {
                                                petuz = new Petuz(99);
                                            }
                                    
                                            public static void Main(string[] args)
                                            {
                                                Petuz p;
                                                CreatePetuz(out p);
                                                Console.Write(p.Iq);
                                            }
                                        }


                                    Конструктор вызовется ОДИН раз, а структ будет в стеке Main'а.

                                    Охуеть, правда?
                                    Почему нельзя так в крестах?
                                    Ответить
                                    • Потому что в крестах можно так:
                                      Petuz CreatePetuz() {
                                          Petuz p{99};
                                          return p;
                                      }
                                      
                                      int main() {
                                          Petuz p = CreatePetuz();
                                      }
                                      Конструктор вызовется ОДИН раз, а структ будет в стеке main'а. Охуеть, правда? Почему так нельзя в c#?
                                      Ответить
                                      • Это в С++11 можно, и нужно пилить мов конструктор, и если там внешние ресурсы, то нужно их в муве занулять, чтобы не обосраца в деструкторе.
                                        Ответить
                                        • > нужно пилить мов конструткор

                                          Да он сам обычно норм пилится если ты какой-то хуйни в поля не натащил или у тебя не десятая вижуал студия.

                                          И зануление во всяких указателях да контейнерах уже есть. Его только в самых листовых классах надо делать.
                                          Ответить
                                          • А что было в 10-й студии? Не было C++11?
                                            Тогда там и мува не было, тогда вообще можно было соснуть. А в С# уже тогда можно было все;)
                                            out был еще 15 лет назад вроде

                                            >И зануление во всяких указателях да контейнерах уже есть.

                                            Ну если это умный поинтер, то да.
                                            А если это моя обертка вокруг внешних ресурсов, то брать MFC нужно быть оккуратным
                                            Ответить
                                            • > А что было в 10-й студии?

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

                                              То при её написании надо быть аккуратным, да. А дальше уже пользоваться ей можно без проблем.
                                              Ответить
                                              • да, я уже понял главную мудрость RAII: думать нужно при насписании конструкторов, операиторов присваиваня и десктруторов. Причем неподдерживыемые штуки лучше явно запретить.


                                                А когда все это сделано -- кресты уже дальше сами все сделают правильно
                                                Ответить
                                      • > что там под капотом происходит

                                        1) Либо там происходит вызов мув конструкторов, который обычно передаёт немножко указателей из старого объекта в новый, а в старом зануляет.

                                        2) Либо там срабатывает RVO/NRVO и всё работает как с out ссылкой в шарпе.
                                        Ответить
                                        • я ж про шарп и спрашиваю 🙂

                                          не происходит ли там внутри дополнительного копирования
                                          Ответить
                                          • >не происходит ли там внутри дополнительного копирования

                                            нет, зачем?
                                            Ответить
                                      • выделяется память на стеке вызывающей стороны, и вызываемая сторона делает в нее как-бы плейсмент нью.

                                        Довольно просто все

                                        Причем если обратиться к неинициализированной или забыть ее заполнить -- не скомпилируется

                                        В С++ нету такой вот семантики "аут переменных" (или я про нее не знаю: я еще слишком анскилен, чтобы авторитетно что-то заявлять про кресты)
                                        Ответить
                                      • >>>"интересно, что там под капотом происходит"

                                        Под твоим капотом происходят сочные камерунские хуи.
                                        Ответить
    • а почему это две разницы?

      типа в первом варианте может быть какой-то побочный эффект?
      Ответить
      • Во втором варианте древняя оптимизация RVO, которая везде работала. Во первом варианте нужна более свежая NRVO, которой в говне мамонта не было.
        Ответить

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

Семь раз отмерь — один отрежь, guest!

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


    8