Короче, так ты потоки не создашь.

они выполняются, все норм

Короче, так ты потоки не создашь.

хотя....

не понимаю про поддержку полиморфизма

ну, ладно, пардон, это, похоже, я недопонимаю.

на поддержку полиморфизма для всех наследников INotFinal. Кроме того, так можно связать в одну иерархию классы, которые по смыслу между собой не связаны.

я не очень понимаю, как единственный предок создает нагрузку по vtbl а создание класса Object в иерархии никому еще не помешало, вроде

я не очень понимаю, как единственный предок создает нагрузку по vtbl а создание класса Object в иерархии никому еще не помешало, вроде

а, единственный. упустил.

ща скину профилировку

а, единственный. упустил.

там условие - либо final, либо потомок INotFinal, так что он всегда единственный

т.е. QueryInterface тривиален и vtbl расширенная поверх лежит

вот в начале было 55кб, потом стало 65 кб. эти 10 кб - потоки те самые, которые не удается освободить\

ща скину профилировку

/cppref@FailsBot

/cppref@FailsBot std::thread::~thread

Search results for "std::thread::~thread" 1. std::thread 2. std::this_thread::yield 3. std::atomic_thread_fence 4. std::this_thread::get_id 5. std::this_thread::sleep_for 6. std::this_thread::sleep_until 7. std::notify_all_at_thread_exit 8. std::promise::set_value_at_thread_exit 9. std::promise::set_exception_at_thread_exit 10. std::packaged_task::make_ready_at_thread_exit 11. std::fstream::read 12. std::istream::read 13. std::ifstream::read 14. std::iostream::read 15. std::wfstream::read 16. std::wistream::read 17. std::strstream::read 18. std::wifstream::read 19. std::wiostream::read 20. std::istrstream::read 21. std::stringstream::read 22. std::basic_fstream::read 23. std::basic_istream::read 24. std::istringstream::read 25. std::wstringstream::read

Search results for "std::thread::~thread" (Page 2) 26. std::basic_ifstream::read 27. std::basic_iostream::read 28. std::wistringstream::read 29. std::basic_stringstream::read 30. std::basic_istringstream::read

/cppref@FailsBot std::thread::~thread

при вызове явно деструктора тоже вылетает

как же он ищет!

https://en.cppreference.com/w/cpp/thread/thread/%7Ethread

If *this has an associated thread (joinable() == true), std::terminate() is called.

ща скину профилировку

Очень быстро такая программа должна работать!

Очень быстро такая программа должна работать!

??? там я слипы вручную просто добавил

Очень быстро такая программа должна работать!

Особенно если оптимизацию включишь

Интересно, clang сможет оптимизировать до xor eax, eax?

Интересно, clang сможет оптимизировать до xor eax, eax?

Интересно, а может clang ВООБЩЕ ПОЛНОСТЬЮ это оптимизировать?

Интересно, а может clang ВООБЩЕ ПОЛНОСТЬЮ это оптимизировать?

Выкинет полностью?)

не может

не смог

а, clang не считает стандартный std::terminate как __builtin_unreachable

Выкинет полностью?)

Ну, да, в идеале автора просто должны послать в (_._)

А не, там же потоки реальные создаются, сори...

не заметил

там еще new/free пара

О боги, какой же бред!

всё, я домой

Привет ребят, Я пишу свою первую библиотеку. До этого писал разумеется, но не библиотеки. Мало того, это должна быть публичная open source библиотека, доступная для большинства не экзотических платформ. Я решил выбрать по старинке autotools. В том состоянии, в котором проект сейчас (еще не дописан) - оно уже собирается в *.so файл (make build) и даже прогоняются unit-тесты (make check). Чегоб мне хотелось - системой сборки делать например *.dll или *.so с одной и той же кодовой базы, автоматически на CI и по успешной сборке делать деплой в облако для Windows, Linux, BSD, etc. К своему стыду я никогда не далал такие амбициозные проекты в виде расширяемых библиотек. То ,что я уже нагуглил, уже позволяет делать мне библиотеку. Но я беспокоюсь что я чего-то не учел, может быть делаю что-то, в архитектурном плане ,что я вляется дурным тоном. Я не могу сейчас точно сформулировать свои опасения, но предположим я эспортирую лишнее или не делаю что-то что облегчит работу с моим api или что-то еще... Черт его знает в общем :) На что посмотреть как на эталон? Есть какой-то гайд или там набор проверок какой-то, который позволит мне быть спокойным и считать что библиотеку моего api можно выпускать в открытый мир смело?

Я пишу на C89 но думаю что это не принципиально ,в контексте вопроса

Привет ребят, Я пишу свою первую библиотеку. До этого писал разумеется, но не библиотеки. Мало того, это должна быть публичная open source библиотека, доступная для большинства не экзотических платформ. Я решил выбрать по старинке autotools. В том состоянии, в котором проект сейчас (еще не дописан) - оно уже собирается в *.so файл (make build) и даже прогоняются unit-тесты (make check). Чегоб мне хотелось - системой сборки делать например *.dll или *.so с одной и той же кодовой базы, автоматически на CI и по успешной сборке делать деплой в облако для Windows, Linux, BSD, etc. К своему стыду я никогда не далал такие амбициозные проекты в виде расширяемых библиотек. То ,что я уже нагуглил, уже позволяет делать мне библиотеку. Но я беспокоюсь что я чего-то не учел, может быть делаю что-то, в архитектурном плане ,что я вляется дурным тоном. Я не могу сейчас точно сформулировать свои опасения, но предположим я эспортирую лишнее или не делаю что-то что облегчит работу с моим api или что-то еще... Черт его знает в общем :) На что посмотреть как на эталон? Есть какой-то гайд или там набор проверок какой-то, который позволит мне быть спокойным и считать что библиотеку моего api можно выпускать в открытый мир смело?

если твоя библиотека нужна, её будут строить, использовать, и напихают тебе триллион багрепов

Ну, это да, конечно.. Хотелось бы наперед знать, за что напихают и не делать этого

Ну, это да, конечно.. Хотелось бы наперед знать, за что напихают и не делать этого

Типа только практика)

Ты не всевидящее око)))

Привет ребят, Я пишу свою первую библиотеку. До этого писал разумеется, но не библиотеки. Мало того, это должна быть публичная open source библиотека, доступная для большинства не экзотических платформ. Я решил выбрать по старинке autotools. В том состоянии, в котором проект сейчас (еще не дописан) - оно уже собирается в *.so файл (make build) и даже прогоняются unit-тесты (make check). Чегоб мне хотелось - системой сборки делать например *.dll или *.so с одной и той же кодовой базы, автоматически на CI и по успешной сборке делать деплой в облако для Windows, Linux, BSD, etc. К своему стыду я никогда не далал такие амбициозные проекты в виде расширяемых библиотек. То ,что я уже нагуглил, уже позволяет делать мне библиотеку. Но я беспокоюсь что я чего-то не учел, может быть делаю что-то, в архитектурном плане ,что я вляется дурным тоном. Я не могу сейчас точно сформулировать свои опасения, но предположим я эспортирую лишнее или не делаю что-то что облегчит работу с моим api или что-то еще... Черт его знает в общем :) На что посмотреть как на эталон? Есть какой-то гайд или там набор проверок какой-то, который позволит мне быть спокойным и считать что библиотеку моего api можно выпускать в открытый мир смело?

Autotools (он же автокрап) - далеко не лучший выбор. Со сборкой под винду будет страшная, ни с чем не сравнимая боль. Советую сменить на cmake, пока проект ещё не слишком большой.

Autotools (он же автокрап) - далеко не лучший выбор. Со сборкой под винду будет страшная, ни с чем не сравнимая боль. Советую сменить на cmake, пока проект ещё не слишком большой.

+1

У autotools есть преимущество перед cmake, что в роли генератора bash скрипт

А значит можно это пускать на устаревших странных юниксах

А значит можно это пускать на устаревших странных юниксах

На устаревших странных юниксах и крестов новых нет. Предлагаешь писать на C++03 каком-нибудь?

На устаревших странных юниксах и крестов новых нет. Предлагаешь писать на C++03 каком-нибудь?

Человек на C89 собрался писать

Причем тут новые кресты?

земля пухом...

Ну успехов ему, что. Голый Си в 2018 году - такое себе удовольствие.

nginx говорят очень популярен

в 2018 году

и postgresql

и еще что-то

Ааа

Linux, точно

Не за флуд, а за правду

int i; for (i = 0; i < n; i++)

как же, наверное, приятно

как же, наверное, приятно

Ручное выделение памяти и проверки границ забыл. ?

ну я о том, что в 2018 ниже С99 — это как-то странно

Человек на C89 собрался писать

Ну уже пишу, скажем так из задуманного работает ожадаемого 20%. Так что собрался - мягко сказано. Месяца полтора уже занимаюсь )

https://github.com/bitcoin/bitcoin - использует autotools в 2018 году :)

у меня задумка в числе прочего мочь быть запущеным на любой платформе, поддерживающей ANSI C

по этому C89

Autotools (он же автокрап) - далеко не лучший выбор. Со сборкой под винду будет страшная, ни с чем не сравнимая боль. Советую сменить на cmake, пока проект ещё не слишком большой.

под винду многое боль. но да, cmake неплох, и получше автоужаса

а ведь 40 минут назад было «большинство не экзотических платформ»

ANSI C это же не экзотика :)

https://github.com/bitcoin/bitcoin - использует autotools в 2018 году :)

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

nginx говорят очень популярен

смотря где. вот на парковке тухлых доменов очень любят IIS :)

Я иногда смотрю на проекты типа вот таких: - https://github.com/alperakcan/fuse-ext2 - https://github.com/json-c/json-c - https://github.com/Storj/libstorj - https://github.molgen.mpg.de/git-mirror/cairo и вижу, что они продолжают развиваться в 2018 году. Меня вовсе не смущает что это Си там, а не например что-то более ванильное )) Нет, ну серьезно, какая разница на чем писать библиотеку, если ты это делаешь +/- одинаково на языке "А" или "Б"? С точки зрения ручного управления памятью меня пока не особо парит. У меня есть некторые проекты на плюсах, где от меня требовалось сделать за неделю рабочий вариант. Здесь я сам себе хозяин, не вижу ничего криминально в C89 :)

Еще скажите что я должен теперь снести Emacs и поставить VS Code

Emacs должен снести в любом случае

И поставить vim

Есть у меня vim

мне Vimscript не заходит, Emacs Lisp приятнее

Я иногда смотрю на проекты типа вот таких: - https://github.com/alperakcan/fuse-ext2 - https://github.com/json-c/json-c - https://github.com/Storj/libstorj - https://github.molgen.mpg.de/git-mirror/cairo и вижу, что они продолжают развиваться в 2018 году. Меня вовсе не смущает что это Си там, а не например что-то более ванильное )) Нет, ну серьезно, какая разница на чем писать библиотеку, если ты это делаешь +/- одинаково на языке "А" или "Б"? С точки зрения ручного управления памятью меня пока не особо парит. У меня есть некторые проекты на плюсах, где от меня требовалось сделать за неделю рабочий вариант. Здесь я сам себе хозяин, не вижу ничего криминально в C89 :)

Что у тебя за проект то?

DSL в си

парсер, сканер, ast, ir и все дела

как же он ищет!

Через жопу, да. Думаю уже свой индекс построить

Привет ребят, Я пишу библиотеку, вот, оформил пост на ЛОР. До этого писал, разумеется, посты, но не на ЛОР. Мало того, что это должен быть качественный анонс, так я решил выбрать по старинке именно ЛОР. В том состоянии, в котором пост сейчас (уже написан и опубликован), - он уже просматривается форумчанами. К своему стыду, я никогда не участвовал в срачиках на ЛОРе. То, что я уже там прочитал, уже позволяет мне морально подготовиться. Но я беспокоюсь, что мои ожидания слишком радужные. Я не могу сейчас точно сформулировать свои опасения, но предположим, я получу много критики. Черт его знает в общем :) Какие подводные камни у опубликования на ЛОРе? Есть како-то гайд или там набор правил какой-то, который позволит мне быть спокойным и считать, что мой пост можно выпускать на ЛОР смело? Хотелось бы наперед знать, за что напихают, и быть готовым к этому https://www.linux.org.ru/forum/development/14365968?lastmod=1532458694561

?

зачет

Привет ребят, Я пишу библиотеку, вот, оформил пост на ЛОР. До этого писал, разумеется, посты, но не на ЛОР. Мало того, что это должен быть качественный анонс, так я решил выбрать по старинке именно ЛОР. В том состоянии, в котором пост сейчас (уже написан и опубликован), - он уже просматривается форумчанами. К своему стыду, я никогда не участвовал в срачиках на ЛОРе. То, что я уже там прочитал, уже позволяет мне морально подготовиться. Но я беспокоюсь, что мои ожидания слишком радужные. Я не могу сейчас точно сформулировать свои опасения, но предположим, я получу много критики. Черт его знает в общем :) Какие подводные камни у опубликования на ЛОРе? Есть како-то гайд или там набор правил какой-то, который позволит мне быть спокойным и считать, что мой пост можно выпускать на ЛОР смело? Хотелось бы наперед знать, за что напихают, и быть готовым к этому https://www.linux.org.ru/forum/development/14365968?lastmod=1532458694561

а qmake то зачем О_О

Быстрый MVP :)

qmake ?

Ага, сборщик от Qt

INCLUDEPATH += /usr/include/x86_64-linux-gnu/c++/7 INCLUDEPATH += /usr/include/c++/7 брр

а зачем?

ну ребята надо сказать спасибо, что не автотулзы и не scons какой-нибудь

или... кастомыные баш скрипты!

как буд-то это что-то плохое )