- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 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);
}
Follow us!
- Леонид Ильич, переверните, у нас бумага кончилась, и мы вам речь на программистской оборотке напечатали...
В ОП десериализация же в 128-битное значение, не?
Ну вот и я об этом. Для 99.99% программ это просто уникальные 16 байт без какой-либо структуры.
Но все пердолятся с парсингом "полей" разной длины, разделённых чёрточками. Обратная совместимость такая обратная совместимость. Там вроде время когда-то было и ещё что-то.
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.
http://govnokod.ru/26969#comment578025
Эээ... дык тогда вся суть пропадает, он уже не уникальный будет. Хотя китайцы и так поди поднасрали с сетевухами, у которых одинаковый мак.
AP пошлет отконнектит STA коли ты смениш мак
Но AP тебя не узнает, и может выдать другой IP, например.
А дома его не узнали и не пустили в квартиру.
— Я столяр Кушаков! — закричал столяр.
— Рассказывай! — отвечали из квартиры и
заперли дверь на крюк и на цепочку.
Столяр Кушаков постоял на лестнице, плюнул и пошел на улицу.
кстати, ты не инью
Сразу видно, да?
икарус спзидил твой акк
мироздание наказало тебя, спиздив твой
Олень подстреленный хрипит,
Лань, уцелев, резвится,
Тот караулит, этот спит -
И так весь мир вертится…
Нахватаешься тут у вас
Кстати в жабе ууид до последнего времени был стремный, с маком и сиквенсом. Чтобы на одной ноде, сука, все были похожи, как сестры в-очёвски, а ты такой ищешь где там разница в 25 разряде. Дико бесило всегда, и лень проверять, стало ли лучше.
похоже на мой BCD
Совсем разные UUID
никак не могу привыкнуть к тому, что
и
это две большие разницы.
Причем начиная с +11 петух может быть некопируемым, но двигаемым (как юник) и тогда первый вариант вообще не скомпилируется.
А в третьих, NRVO конпеляторы применяли давным-давно, так что на практике первый вариант был не особо то и хуже.
Именно так. В остальных строчках ты пишешь std::move() вручную, чтобы случайно не спиздить значение. А в момент return'а уже всем пофиг.
> Не обязан
Ну да. Но, тем не менее, многие на это надеялись. Иначе вместо возврата придётся юзать явное void foo(Petuh &out), а это некрасиво.
> не копируемый тип
Это да. Почти все оптимизации так работают. Сначала проверяется, что при стандартной семантике всё ок. А потом уже код выбрасывается. Более того, твой второй вариант тоже не работает если нечем копировать и/или мувать, проверь.
Да, всё так, невнимательно прочитал код.
Да не, я просто хуйню пишу не думая. Мувалка у Bar и так сгенерится.
return Bar{std::move(foo)}; в общем.
На самом деле, писать на крестах до с++11 - тлен и безысходность.
Но это уже не RAII, да. Resource acquisition и initialization оказываются разбиты, надо не забывать что у объекта появилось невалидное состояние.
Да он сам обычно норм пилится если ты какой-то хуйни в поля не натащил или у тебя не десятая вижуал студия.
И зануление во всяких указателях да контейнерах уже есть. Его только в самых листовых классах надо делать.
А х.з., бага какая-то была, почему-то не умела дефолтный мув генерить если её явно не пнуть.
То при её написании надо быть аккуратным, да. А дальше уже пользоваться ей можно без проблем.
1) Либо там происходит вызов мув конструкторов, который обычно передаёт немножко указателей из старого объекта в новый, а в старом зануляет.
2) Либо там срабатывает RVO/NRVO и всё работает как с out ссылкой в шарпе.
не происходит ли там внутри дополнительного копирования
Под твоим капотом происходят сочные камерунские хуи.
типа в первом варианте может быть какой-то побочный эффект?