Доброе утро. Есть приложение которое создаёт объект в куче и отдает указатель в длл, где объект удается. Какие подводные камни могут быть? 11 стандарт, с-апи, posix платформы

Длл, статически слинкованная с системными либами, вследствие чего имеющая свою кучу

То есть если приложение и длл используют std_shared то куча будет одна, так?

То есть если приложение и длл используют std_shared то куча будет одна, так?

Не вижу связи между использованием std::shared_ptr и линковкой

https://doc.lagout.org/security/Hackers%20Delight.pdf https://github.com/jyfc/ebook/blob/master/02_algorithm/Hacker's%20Delight%202nd%20Edition.pdf #books

https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html

Так что рекомендую переписать с C на PHP :)

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

Начал практиковаться в ц++11 и обнаружил, что несмотря на определение конструктора перемещения и применение std::move в std::map улетает копия инстанса. Что я пропустил?

Начал практиковаться в ц++11 и обнаружил, что несмотря на определение конструктора перемещения и применение std::move в std::map улетает копия инстанса. Что я пропустил?

Есть пример кода, где повторяется проблема?

Где-то ошибка, скорее всего в процессоре

Спасибо, что не в ДНК :-)

Всё очень просто, sockets механизм разработаный linus'ом Torvalds'oм изначально для C, плюс C++ не даёт должной производительности из-за высокого уровня абстракции, что насчёт rust'a - в раздумиях про написания аналога на этом языке

Это вовсе не чушь, к чему этот сарказм?

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

Я забанил сразу за такое вот...

Однако большинство людей под С++ понимают так называемый «современный C++», со счетчиками ссылок, классами, исключениями, шаблонами, лямбдами, STL, Boost, и так далее. ... Если вам очень важна скорость, то писать на таком C++ вы не сможете. Если же он вам подходит, то лучше взять Java, Go или любой другой высокоуровневый язык по вкусу. после этого места стало невозможно

Идём далее - "Код на C прекрасно пишется без каких-либо тяжеловесных IDE, в обычном Sublime Text или Vim с ctags. Для сколь-либо серьезного кода на C++ без нормальной IDE жизнь быстро становится очень грустной, потому что автоматический вывод типов, шаблоны, и вот это все, и потому что ctags начинает забрасывать не туда, куда нужно. К счастью, IDE для C++ существуют. CLion, например, довольно неплох. Но не все программисты согласны платить за него деньги и попрощаться с 2 Гб оперативной памяти. К тому же, CLion не все и не всегда подсвечивает правильно, и если открыть в нем сразу два проекта, то даже довольно мощный компьютер начнет тормозить. Есть и другие IDE, но у них свои проблемы, например, привязка к Windows или отсутствие важных возможностей, таких, как вывод типов." Тут всё индивидуально. Тут есть много людей, что в виме сидят и валят кодяру. я их не понимаю, конечно. Но тот же Qt Creator я считаю очень лёгким. и его хватает для базовых вещей

Блять. Пи$дец, днище. Зачем банить? На лицо, что человек запутался или чего то не знает. Почему взять и не объяснить ему в чем он не прав?

Неправ он в двух вещах, в том что собирает велосипед из неподходящих средств и в то что верит что за счёт этого он быстрее поедет

Привет, ребята, извиняюсь сразу за вопрос, но как сложно сделать что-то типа MTA (плагин к GTA: SA) для Mount & Blade (кампания в мультиплеере)?

Человек скорее всего имеет ввиду ООП VS Функциональщина. Тут Си победит.

Всё очень просто, sockets механизм разработаный linus'ом Torvalds'oм изначально для C, плюс C++ не даёт должной производительности из-за высокого уровня абстракции, что насчёт rust'a - в раздумиях про написания аналога на этом языке

Сокеты изобретены ещё до Линуса https://en.wikipedia.org/wiki/Berkeley_sockets Разрабатывались они не для С, а на C. Полученный интерфейс универсален, можно пользоваться на любых языках программирования, хоть на ассемблере, хоть на JS

Как С может победить, если в нем нет ни функциональщины, ни OOP?

Сокеты изобретены ещё до Линуса https://en.wikipedia.org/wiki/Berkeley_sockets Разрабатывались они не для С, а на C. Полученный интерфейс универсален, можно пользоваться на любых языках программирования, хоть на ассемблере, хоть на JS

Так, бред кой то. Человек действительно ошибается. Предлагаю рассказать ему в чем именно и почему. Нежели заклевывать и гнуть и без того сломанную палку дальше.

Как С может победить, если в нем нет ни функциональщины, ни OOP?

какэто нет функциональщины? функции есть? указатели на функции есть? передавать их в другие функции можно? ну вот тебе и функциональщина /s

Он не должен кого-то там побеждать. Есть ниша, которую он занимает. Точка.

Всё очень просто, sockets механизм разработаный linus'ом Torvalds'oм изначально для C, плюс C++ не даёт должной производительности из-за высокого уровня абстракции, что насчёт rust'a - в раздумиях про написания аналога на этом языке

Ниша: поддержка легаси проектов в команде Линуса "неосилятора" Торвальдса

Ниша: поддержка легаси проектов в команде Линуса "неосилятора" Торвальдса

@antoshkka, а какова вероятность, что примут вариант модулей от майков(как я понимаю, они за вариант без макросов) ? И что вообще влияет на выбор(лоббирование компаниями своих интересов, или чёт другое)?

По крайней мере, это OpenSource сайт, и каждый может предложить свой варриант по производительнее

В основе дизайна языка C++ - zero cost abstraction. Все абстракции языка не добавляют никаких накладных расходов (за редким исключением, на которое сложно натолкнуться) Все новые фишки языка тщательно проверяются на соответствие этому принципу. При этом дело доходит до казалось бы абсурдных для других язуков программирования заморочкам. Одну из ключевых новинок языка мучают уже лет 5 из-за того, что там появляется дополнительная косвенность (разадресация указателя). При этом эта новинка в основном для асинхронных задач, тоесть там где цена разадресации указателя ничтожна по сравнению с рядом идущим системным вызовом + синхронизации

? у меня есть ощущения что местами плюсы даже быстрее выйдут

Блин, основной способ повышения производительности С -кода -- инлайнинг функций. Я уж не помню, как там С умеет автоматом иннайнить, может и научился уже давно, но С++ инлайнить умеет очень хорошо. Поэтому да, С++ должен либо выигрывать, либо не проигрывать.

по паре пунктов только согласен

Ага, что взять с автора, который пишет такое: "Трудно ругать язык, на котором написаны Chromium, Skype" ...

Достаточно стремный способ(вспомним лекцию @antoshkka )

Я забанил сразу за такое вот...

Блин, основной способ повышения производительности С -кода -- инлайнинг функций. Я уж не помню, как там С умеет автоматом иннайнить, может и научился уже давно, но С++ инлайнить умеет очень хорошо. Поэтому да, С++ должен либо выигрывать, либо не проигрывать.

нет банил

Ага, что взять с автора, который пишет такое: "Трудно ругать язык, на котором написаны Chromium, Skype" ...

Ну в ядре следят за тем, чтобы функции которые наружу единиц компиляции не показывают, помечали как static. От этого, говорят, C-компилятор начинает их инлайнить.

Да, в C++ для этого так же можно использовать static или анонимные namespace

Там когда Линус успокаивается, он пишет конкретные причины, что ему в C++ не нравится: http://harmful.cat-v.org/software/c++/linus - the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. - any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. - you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

Зачем _вот такие_ подчёркивания?

Там когда Линус успокаивается, он пишет конкретные причины, что ему в C++ не нравится: http://harmful.cat-v.org/software/c++/linus - the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. - any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. - you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

но... 1) Проблема с памятью решается своим аллокатором 2) А что там за crap в ООП? И как там object-oriented на Си? 3) С исключениями дыа, беда. СОгласен

Ну честно говоря можно запретить использовать исключения в ядре просто на уровне гаедлайнов. В Qt же ими не пользуются например.