А, да, и это на моей машине. 4720HQ i7

На друго машине плюсы быстрее на 3%

Там проц поновее.

На x86 тоже плюсы побыстрее, но это странное llvm-овское поведение.

Видимо баг им надо зарепортить, или по крайней мере фича-реквест.

Они реально не до конца оптимизируют нативный код. Сравнивали просто ассемблер получившийся, и такие дела, что msvc лучше например генерирует D:

Это просто фронтенд llvm-а.

а, ну llvm годно

При этом код не сложнее плюсового.

код в студию!)

не надо

mersenne длинный

что за язык интересно

Они реально не до конца оптимизируют нативный код. Сравнивали просто ассемблер получившийся, и такие дела, что msvc лучше например генерирует D:

это известная тема

так, ладушки, сорцы телеграма в симейк я загнал

теперь надо скомпилять!

так, ладушки, сорцы телеграма в симейк я загнал

👍👏

опять этот несчастный stdafx.h, где мой cotire

код в студию!)

[] [ { state: 0 624n32 array; index: 624; 5489 state 0 @ set i: 1; [ state i 1 - @ dup 30 rnshift xor 1812433253 * i + state i @ set i 1 + i set i 624 < ] loop } ] [createMt19937] export {state: 0 624n32 array; index: 0;} ptr [ generator:; generator.index 624 = [ state: generator.state ptr; i: 0; [ state i @ 2147483648 and state i 1 + 624 mod @ 2147483647 and or dup 1 rnshift state i 397 + 624 mod @ xor swap 1 and 1 = [ 2567483615 xor ] [ a:; a copy ] if state i @ set i 1 + i set i 624 < ] loop 0 generator.index set ] [] if generator.state generator.index @ generator.index 1 + generator.index set dup 11 rnshift xor dup 7 lshift 2636928640 and xor dup 15 lshift 4022730752 and xor dup 18 rnshift xor ] [useMt19937] export

Да-да. Обратная польская нотация :3

нечитаемо

// we copy some parts of C++11/14/17 std:: library, because on OS X 10.6+ // version we can use C++11/14/17, but we can not use its library :( namespace std_ { да они там наркоманы

нечитаемо

Просто стиль такой. Можно писать и читаемо. Здесь исплоьзуется стековость языка вдоль и поперек.

А к постфиксу быстро привыкаешь. В нём есть свои бенефиты для описания структур данных.

Для какого-нибудь более осмысленного кода будет вполне читаемо.

// we copy some parts of C++11/14/17 std:: library, because on OS X 10.6+ // version we can use C++11/14/17, but we can not use its library :( namespace std_ { да они там наркоманы

Грустный смайлик поставили

// we copy some parts of C++11/14/17 std:: library, because on OS X 10.6+ // version we can use C++11/14/17, but we can not use its library :( namespace std_ { да они там наркоманы

А почемк не могут-то

А почемк не могут-то

Там, вроде, libc++. Она, видимо, меньше новых фич поддерживает в сравнении с libstdc++.

Там, вроде, libc++. Она, видимо, меньше новых фич поддерживает в сравнении с libstdc++.

ты смеешься

libc++ поддерживает больше фич, чем libstdc++ и написана на более современном с++

они там пишут про древнючий 10.6

на нем еще libstdc++ наверное была даже

они там пишут про древнючий 10.6

Там 10.6+ указано же. Или они минорные версии имели в виду?

#minihelp

Там 10.6+ указано же. Или они минорные версии имели в виду?

Да. Там, оказывается, все печально в 10.6-7.

Да. Там, оказывается, все печально в 10.6-7.

А почему бы тогда не нафиг его

Спрошу сразу, чтобы не быть голословным. Пишу на JVM-стеке 5 лет, иногда на C/C++ нативные части. Вопросы могут быть по кросс-компиляции линуксовых либ, и, банально, по языку/stdlib, потому что после Java многое кажется непривычным(знать-то основы знаю, но одно дело знать, что можно написать, другое дело понимать, как оно работает изнутри и какие побочки может нести). Такое в этом чате спрашивать можно?

#supapro

Или как там

Спрошу сразу, чтобы не быть голословным. Пишу на JVM-стеке 5 лет, иногда на C/C++ нативные части. Вопросы могут быть по кросс-компиляции линуксовых либ, и, банально, по языку/stdlib, потому что после Java многое кажется непривычным(знать-то основы знаю, но одно дело знать, что можно написать, другое дело понимать, как оно работает изнутри и какие побочки может нести). Такое в этом чате спрашивать можно?

Про кросс-компиляцию, жни и особенности портирования лучше тут, это уже advanced-вопросы, кмк

А по основам и чутка пофлудить в рамках темы - лучше в #supapro

Жни и портирование не трогаю, только компиляцию

По стдлиб лучше в супапро, хотя шаблонную магию можно и тут

Ну вот я например хочу спросить у вас совета по поводу pre-init singleton в C++. Типа Singleton::init(param), Singleton::get().

Спрошу сразу, чтобы не быть голословным. Пишу на JVM-стеке 5 лет, иногда на C/C++ нативные части. Вопросы могут быть по кросс-компиляции линуксовых либ, и, банально, по языку/stdlib, потому что после Java многое кажется непривычным(знать-то основы знаю, но одно дело знать, что можно написать, другое дело понимать, как оно работает изнутри и какие побочки может нести). Такое в этом чате спрашивать можно?

Про компиляцию, наверное, можно сюда, если у вас что-то интересное там. По языку и stl лучше в др. чат. Если же вам надо алгоритм реализовать через сущ. алгоритмы в stl или с метапрограммированием чего будет, то тоже тут можно пообсуждать.

Как вы привыкли такое писать и так далее

Ну вот я например хочу спросить у вас совета по поводу pre-init singleton в C++. Типа Singleton::init(param), Singleton::get().

по тред-safe вопрос?

по тред-safe вопрос?

В том числе

Как вы привыкли такое писать и так далее

Это вам синглтон майерса нужен.

Это вам синглтон майерса нужен.

а можно сюда сниппет? Толькл просьба тегами пометить

Спасибо! А в целом, вопросы такого уровня под этот чат подходят?

Это вам синглтон майерса нужен.

А с новыми стандартами он все разрастаться должен

Спасибо! А в целом, вопросы такого уровня под этот чат подходят?

Думаю, да

Instance& getInstance() { static Instance instance; return instance; } #singleton #scott #meyers

А с новыми стандартами он все разрастаться должен

В новом стд вообще можно ж тупо статик-переменную юзать

Instance& getInstance() { static Instance instance; return instance; } #singleton #scott #meyers

Да, это оно)

Только мне говорили, что мсвц тут не соблюдает стандарт

std::once_flag - cppreference.com en.cppreference.com hardware_destructive_interference_sizehardware_constructive_interference_size.

Instance& getInstance() { static Instance instance; return instance; } #singleton #scott #meyers

Я это и использую, кстати :) Но мне нужно, чтобы в init инстанс создавался, а в get возвращался :)

std::once_flag - cppreference.com en.cppreference.com hardware_destructive_interference_sizehardware_constructive_interference_size.

Можно эту бню юзануть

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

Ну вот я например хочу спросить у вас совета по поводу pre-init singleton в C++. Типа Singleton::init(param), Singleton::get().

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Ri-singleton

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

Если параметры на этапе компиляции известны, можно обощенный шаблон сделать.

Нет, они в рантайме вычисляются

Нет, они в рантайме вычисляются

Они меняются у одного объекта? Если нет, то лучше, наверное, обычные объекты класса использовать.

Нет, они в рантайме вычисляются

а чоб тебе метод инит не добавить к инстансу? и далее getInstance().init(bla...bla..bla...) ?

Ну я пока так и сделал. Но стремно, такое ощущение, что можно лучше

лучшее - враг хорошего

а чоб тебе метод инит не добавить к инстансу? и далее getInstance().init(bla...bla..bla...) ?

Это не thread safe уже будет. Сужается область применения.

И это тоже

Это не thread safe уже будет. Сужается область применения.

а где это требуется тред-сейф постоянно инициализировать? основной кейс синглтона как такового - getInstance, менеджмент свойств к синглтону не относится никак - они сами по себе

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

код в котором начинается гонка вначале запуска за инициализацию параметров синглтона - какой-то уг кмк)

код в котором начинается гонка вначале запуска за инициализацию параметров синглтона - какой-то уг кмк)

Я пару раз видел, как из синглтона подтягивались параметры в цикл. функции пула потоков.

так ведь "из синглтона", а не "в синглтон в конструктор"

Да, но кто-то увидит в коде get().init(a,b,c), скопипастит в многопоточный код и на старте получит кашу. У меня просто синглтон с thread safe ассоциируется. Если внимательно читать, писать и поддерживать код, то такого, конечно, не будет. Тут уж кому как удобнее.

ну я не спорю, что синхронизацию в сетап можно добавить) лишней не будет)

главное не пытаться смастерить конструктор синглтона с параметрами

Что там, кстати, с конструкторами умных указателей при передаче их в качестве параметров функции? Саттер говорил на одной из конференций, что пофиксили. Я как-то упустил момент. Может кто интересовался текущим статусом в msvc и gcc\clang? Чисто теоретический вопрос, очевидно, что использование make_... функций предпочтительнее тут.

А почему бы тогда не нафиг его

они могут его поддерживать а нам он точно не нужен

Про кросс-компиляцию, жни и особенности портирования лучше тут, это уже advanced-вопросы, кмк

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

главное не пытаться смастерить конструктор синглтона с параметрами

а параметры откуда приходят?