на cppref уже подьехал обновлённый раздел со временем: http://en.cppreference.com/w/cpp/chrono ссылки пока что не заполнены, но хоть с интерфейсом ознакомьтесь

аааа, я почти допилил статью на хабр... там эта штука идёт первым пунктом

аааа, я почти допилил статью на хабр... там эта штука идёт первым пунктом

дак, тоже збс

аааа, я почти допилил статью на хабр... там эта штука идёт первым пунктом

ну ты давай, пили 😊

допиливай)

изначально проблема была "отучить либкланг искать #include <string> в /usr/include и вместо этого искать в /my/dir/include" проблема частично решилась через -nostdinc++ -isystem /my/dir/include, но builtin headers кланга всёравно лезут в /usr/include

ну тебе надо sysroot менять д

ну тебе надо sysroot менять д

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

или забинди на время в /usr/include

это феерический костыль но в качестве временного решения оно сработало на ура, спасибо

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

Сама либа вроде никаких путей не хардкодит, смотри какой драйвер ты используешь.

а никого не беспокоит, какой размер примет стандарт после внедрения графики, нетворка, ranges, format и прочих либ? не помню, чтобы когда-то в язык впихивали такие крупные либы. в основном всякие мелкие классы из буста - smart ptr, any/optional/variant и прочие

а никого не беспокоит, какой размер примет стандарт после внедрения графики, нетворка, ranges, format и прочих либ? не помню, чтобы когда-то в язык впихивали такие крупные либы. в основном всякие мелкие классы из буста - smart ptr, any/optional/variant и прочие

а как это должно беспокоить?

ну поделят на тома, и то вряд ли

лол, а нам то какое дело до размера стандарта?

а никого не беспокоит, какой размер примет стандарт после внедрения графики, нетворка, ranges, format и прочих либ? не помню, чтобы когда-то в язык впихивали такие крупные либы. в основном всякие мелкие классы из буста - smart ptr, any/optional/variant и прочие

в других языках это норма, почему в плюсах это должно быть проблемой?

а как это должно беспокоить?

борцов за экологию - слишком много бумаги придётся тратить

борцов за экологию - слишком много бумаги придётся тратить

лол 😊

да нет, мне-то тоже всё равно, какого размера стандарт. просто любители холиваров любят тыкать плюсовиков в размер стандарта и говорить "уууу, намудрили". на самом деле вопрос скорее риторический/дискуссионный

ну и пусть тыкают, какая нам разница от мнения умственноотсталых?

а никого не беспокоит, какой размер примет стандарт после внедрения графики, нетворка, ranges, format и прочих либ? не помню, чтобы когда-то в язык впихивали такие крупные либы. в основном всякие мелкие классы из буста - smart ptr, any/optional/variant и прочие

наверное надо бы разделить стандарты

std разделить

не переживай, будет std2

ненадо

будет и у нас разброд аки в питоне

я этот не до конца знаю

> gps_clock (C++20) Clock for GPS time а глонасс будет?

> gps_clock (C++20) Clock for GPS time а глонасс будет?

это надо через Антона пробивать)

китайцы ещё должны подключиться

странно, что такое пролезло

> gps_clock (C++20) Clock for GPS time а глонасс будет?

название плохое

должно быть пофигу же

странно, что такое пролезло

Это просто часы, которые не учитывают високосные секунды

странно назвали 😊

Название и правда очень, но оно устоявшееся, мировое

Это просто часы, которые не учитывают високосные секунды

чем это обосновано? что разработчики гпс не стали их учитывать в самом начале, а теперь нельзя ломать все гпс устройства?

Типа того

Язабан

как скажешь :)

Как вариант

> gps_clock (C++20) Clock for GPS time а глонасс будет?

Глонасс в UTC время хранит ЕМНИП.

Но я не помню детали реализации, как там с учетом ОТО и этим делами

чем это обосновано? что разработчики гпс не стали их учитывать в самом начале, а теперь нельзя ломать все гпс устройства?

это одна из изспользуемых шкал времени. UTC, зафиксированное по состоянию на 80-е года, т.е. некоторое количество високосных секунд по отношению к TAI туда добавлено, но всё что было после - не учитывается. как обычно бывает в таких случаях, нормальному программисту это всё не нужно.

Господа привет. Помогите нубу из F6FD hex получить -522 dec. int a = 0xFD; int b = 0xF6 << 8; int res = a | b; у меня выводит -10 . что не так? А если делать так unsigned int res2 = (unsigned char) 0xFD | (unsigned char) 0xF6 << 8; то выводит 65014 , а требуется -522

вы попутали

и попутали вы endidanness

FDF6 вот -522

FDF6 вот -522

да но в файле идет наоборот я сначала читаю младший байт потом старший. их надо перевернуть и вывести -522

да но в файле идет наоборот я сначала читаю младший байт потом старший. их надо перевернуть и вывести -522

(((-1<<8)|0xFD)<<8)|0xF6

ну или каст в какойнить signed тип сначала но вроде это уб

хотя какая вам разница

(int16_t)((0xFD<<8)|0xF6)

(((-1<<8)|0xFD)<<8)|0xF6

спасибо. а по какому принципу вы это делали? где можно почитать?

(int16_t)((0xFD<<8)|0xF6)

поправьте меня если это не уб

поправьте меня если это не уб

нет работает. спасибо

факт что работает ничего не значит

хм вроде не уб

http://eel.is/c++draft/conv.integral#3 - implementation defined

а почему нельзя просто выполнить инверсию в unsigned?

а, понял

в общем-то я не понимаю, как не пройти в этой операции UB, не написать ифа и не использовать расширение типа

чета сложно вижаку объяснять

в VC++ другие соглашения вызова. Всёравно оно заинлайнится и компилятор выкинет лишнее.

да это еще и не правильно

template <typename T, typename = std::enable_if_t<std::is_unsigned<T>::value>, typename R = std::make_signed_t<T>> constexpr R convert(T in) { return (in > static_cast<T>(std::numeric_limits<R>::max())) ? ( in == static_cast<T>(std::numeric_limits<R>::max()) + 1 ? std::numeric_limits<R>::min() : -static_cast<R>(-in) ) : static_cast<R>(in) ; } а в такой версии вижак ифать начинает

зачем вообще все эти ветвления, используйте обычный каст - будет impl. def. Найдёте платформу где другое поведение - воткнёте #if

чтобы продемонстрировать замечательность ISO C++, очевидно

тогда надо if constexpr

?

как это помогает?

мне надо в явном виде рассматривать три случая

...я хотел сказать "вместо enable_if", потом присмотрелся и не понял зачем он вообще там.

м... чето я вообще не понимаю что этот код делает

convert<unsigned short,void,short>, COMDAT PROC mov eax, 32767 ; 00007fffH cmp cx, ax movsx eax, cx ret 0

чета ржу

вроде флаги не влияют на movsx

...я хотел сказать "вместо enable_if", потом присмотрелся и не понял зачем он вообще там.

это код пытается преобразовать так, как будет делать стандартный 8086... процессор

template <typename T, typename = std::enable_if_t<std::is_unsigned<T>::value>, typename R = std::make_signed_t<T>> constexpr R convert(T in) { return (in > static_cast<T>(std::numeric_limits<R>::max())) ? - static_cast<R>((-in) - static_cast<R>(1)) - static_cast<R>(1) : static_cast<R>(in) ; }

вот такая текущая версия

enable_if очевидно запрещает T быть каким-либо типом, кроме unsigned

static_assert же, зачем тут SFINAE

я не понимаю альтернатив

представьте, что входной параметр T имеет тип char