ну и как вы обходитесь без shared_ptr?

Приведи пример, когда он нужен.

Я знаю дай Бог один, в котором нам пришлось сделать исключение.

Если знать кто владелец, и время жизни объектов, то можно обойтись unique_ptr и простыми указателями

Можно

И я призываю писать код, посмотрев на который ты можешь сказать кто владеет объектом.

У С++ большое преимущество перед растом - куча библиотек, надёжных инструментов и прочие плюшки устроявшегося языка

можно сесть и писать реальный софт

плюсы можно было бы сделать идентичными расту

если запретить использовать объект после move

и запретить делать копии некостнатных референсов и поинтеров

получится в точности раст

Но ты и так, если хочешь, можешь писать код без этого!

Но ты и так, если хочешь, можешь писать код без этого!

блин, я очень рад, что ты тут у нас в чате есть)

https://www.youtube.com/watch?v=hEx5DNLWGgA

тут чувак показывает софт для статического анализа кода

так... я ща инглишский не поймц

как раз для того чтобы следить за такого рода штуками

Да, вот.

Всё правильно.

Для «недисциплинированных» програсммистов есть статические анализаторы кода.

Cppcheck у меня в старом проекте том ничего не нашел

А еще там где я работал у нас их заменяло обязательно peer-rewiev кода всей командой.

начиная с 43 минуты

правда это майкрософтовская хрень

А еще там где я работал у нас их заменяло обязательно peer-rewiev кода всей командой.

А я один пишу тот проект, хедертиз которого я те показал

хотел одному чуваку показать

у меня идея возникла

писать небольшие проги на современном С++14 и на haskell

и сравнивать

тем самым можно продвинуть и С++, и хаскель

Хорошая идея

и много чему научиться

И потом писать разборы реализаций

вообще да

в блоге

на английском

Ммм... блог...

со ссылками на код

Так удобнее для тех кто хочет следить за новыми постами

Бартош покусал?

:D

Он ведь уже это делает.

где?

ну он фактически пишет в своём блоге о функциональных парадигмах в с++

или ты хочешь произвольные задачи решать?

я про небольшие задачки, и лучшие решения на С++ и хаскель

в идиоматичном стиле для обоих языков

то есть не надо пытаться писать на С++ в функциональном стиле

а на хаскелле в императивном

Ну эээ

невероятно, но факт, простая программа на Ди содержащая строки void main(){} весит...

внимание....

полагаю, там весь glibc слинкован статически

Скажем на хаскелле функцию которая вычисляет какое-нибудь там число фиббоначи, за логарифм, оптимально было бы писать используя StateT

Так что без монадок не обойдешься.

С состояниями.

ты посчитай сколько бинарник в go весит)

ты посчитай сколько бинарник в go весит)

сколько?

и почему?

там тоже статическая линковка

всё пихается в один бинарник

разве монадические вычисления это императивщина?

они просто эмулируют императивщину

особенно в do нотации

Да.

ERROR: S client not available

Я про это и говорю.

Ты говоришь идеоматически.

я имею ввиду согласно лучшим практикам

Идеоматически вычисления в IO монаде(которая называется также монада строго последовательных вычислений) ничем с практической точки зрения не отличается от императивщины.

Хотя конечно правда в том, что всё что можно делать с монадами можно делать без них.

ну тогда просто сравним код

это же будет интересно

Просто мне кажется примеры бинарно разделятся на хаскеллевские и на с++-ные

Разве лишь за исключением простейших.

блин, с другой стороны на rosettacode.org уже куча задач есть на любых языках

кошмар

там есть страшные решения

очень плохие

@AndreiC поделись своим гайдлайном? Если не секретный

Не уверен, что он у меня еще остался, может остался только codestyle :c

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

Всмысле на то, как они в команде трудятся

По ограничениям в коде было очень мало правил. Не использовать shared_ptr, по минимуму шаблонов, не использовать new\delete, там где надо не стесняться использовать move, избегать копирований, аккуратно работать c future\promise, кидать runtime_exception. И всё такое.

Потом мы писали уже целиком код на корутинах, на библиотеке которую я запилил для всего проекта

Там уже были корутиновые приколы.

У нас были крутые самоучки, но там старые делфисты и ушли давно. Вот мы теперь с напарником в плюсы переезжаем все

EventLock-и, RemoteContext-ы и прочее.

Ну и по дороге улучшайзинги пилим по мере сил

EventLock-и, RemoteContext-ы и прочее.

Круто. У нас огромный ворох проблем изза модульности и плагинов

Собсно это И сгубила прошлой версии системы потому что часть года было написно на DELFI часть на плюсах часть ещё на чем-то были даже вызовы управляемого кода нв точкеНет

Сорри за грамматику и орфографию голосовой набор

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

Потому что у нас сейчас все на динамических библиотеках

В принципе неплохо, однако костыли местами подставлены.

По ограничениям в коде было очень мало правил. Не использовать shared_ptr, по минимуму шаблонов, не использовать new\delete, там где надо не стесняться использовать move, избегать копирований, аккуратно работать c future\promise, кидать runtime_exception. И всё такое.

Мы вообще изначально все аллокейты выкинули и за каждый new чуть ли не война была

Все в угоду скорости