Ещё про C++ и моё к нему отношение.

Oct 18, 2017 15:27

По следам внесения небольшого кода в большой проект и попыток создания библиотеки ( Read more... )

c++, языки программирования, работа

Leave a comment

Comments 66

kodt_rsdn October 18 2017, 12:51:40 UTC
clang умеет давать подсказки. Находит объявления похожих символов (не знаю, какое у него ограничение на расстояние Левенштейна, но в пару символов точно находит).
Естественно, не с выведенным типом, а с тем, что в исходнике написано. Если исходник не обфускан, то вполне можно догадаться.

Да, gcc и vc такого не умеют.
В clang ещё и линтер какой-то более мощный встроен, чем в gcc. Сильнее докапывается до мелочей и выдаёт более понятную диагностику.

Но это фича компилятора, а не языка. Это всё равно, как мучаться с хаскеллом, используя какой-нибудь hugs вместо ghc.

Reply

thesz October 18 2017, 13:48:46 UTC
Я так и думал.

clang я использовать не хочу по идеологическим соображениям - мне не нравится язык реализации, мне не нравится мой опыт работы с LLVM, мне не нравится его лицензия (она контрпродуктивна) и, последнее по счёту, но не по важности, мне не нравятся прически его создателей.

Reply

kodt_rsdn October 18 2017, 18:25:45 UTC
Тогда придётся отказаться от макоси. Там в xcode именно clang является штатным компилятором.

Мне-то пофиг, я под три платформы сразу собираю - вин, лин, мак - поэтому вижу весь ассортимент и зоопарк.

Reply

thesz October 19 2017, 10:43:27 UTC
Пока я маком не пользуюсь.

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

Reply


kodt_rsdn October 18 2017, 12:58:20 UTC
А что до ООП, тут всё просто. Отвык плюс перфекционизм.
Инкрементный дизайн "быстренько наляпать под текущие нужды" - с потенциально несогласованной инициализацией, протечкой абстракции и т.п., - а потом вычищать и переделывать. Заодно и ООП освежить получится.

Reply

thesz October 18 2017, 13:53:23 UTC
Вы меня перфекционистом не обзывайте. А то и ваша причёска перестанет мне нравится. ;)

Все известные мне перфекционисты объясняли перфекционизмом свои промахи в работе. От Чака Мура до... некоторых бывших коллег. Поэтому для меня это звучит, как обзывательство - "неспособный сделать хорошо".

Быстро наляпать под текущие нужды можно и нужно без ОО.

Reply


pascendi October 18 2017, 13:11:32 UTC
До каких пределов маразма доходит ООП, легко видеть на примере любого из Java-фреймворков...

Reply

thesz October 18 2017, 13:53:45 UTC
Именно.

Reply

filonov October 18 2017, 13:56:30 UTC
Эталонный предел маразма - давно помершая библиотечка ocaml-classes.
Путем нечеловеческих усилий и ряда грязных хаков авторы таки смогли добиться существенного уменьшения функционала контейнеров стандартной библиотеки.
Зато объектненько.

Reply

thesz October 18 2017, 13:58:11 UTC
Подробностей! Подробностей!

ocaml я тоже не люблю. ;)

Reply


Builder bik_top October 18 2017, 18:54:37 UTC
> Можно отделить разбор конфигурации от создания объекта.

Да; буква «S» в аббревиатуре SOLID.

> Можно создавать объект пустым и заполнять его. Однако некоторые варианты заполнения могут оставлять объект в несогласованном состоянии. Стоит ли это разрешать?

Создаёшь пустым и заполняешь сколь угодно грязно и несогласовано не сам объект, а его builder или configuration. Проверку предусловий и инвариантов делаешь при создании целевого объекта в методе `Create()` строителя.

> проблемы синтаксического разбора - должен ли я бросать исключение

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

Reply

Re: Builder thesz October 19 2017, 05:52:28 UTC
То есть, надо потратить время на создание обвязок, вместо написания функционала.

Не люблю я ООП, очень не люблю.

Reply

Правило пяти bik_top October 19 2017, 06:31:00 UTC
> То есть, надо потратить время на создание обвязок, вместо написания функционала.

Тут от языка сильно зависит. C++, конечно, требует лишних церемоний и принятия многих решений, прежде чем до функционала доберёшься: правило пяти, swap, pimpl, etc.

Reply

RE: Правило пяти 4da October 19 2017, 09:05:38 UTC
По моему pimpl это не "функционал", это способ преодоления ущербности C++.

Reply


iamjaph October 19 2017, 13:25:35 UTC

> Можно создавать объект пустым и заполнять его. Однако некоторые варианты заполнения могут оставлять объект в несогласованном состоянии. Стоит ли это разрешать?

А почему возникает такой вопрос? Вы же в haskell на создаете записи с незаполненными полями?

Reply

thesz October 19 2017, 13:51:07 UTC
>Вы же в haskell на создаете записи с незаполненными полями

В Хаскеле значения, а в C++ - объекты. Значения записей могут содержать незаполненные поля, при вычислении значений которых может появиться ⊥ и это позволяет создавать согласованно заполненные записи в любом случае. Объекты с полями могут быть в несогласованном состоянии и это надо отдельно проверять, отдельно написанным кодом.

Reply

kodt_rsdn October 20 2017, 10:58:37 UTC
Какая разница между
createModifiedInconsistentCopy :: SomeValue -> SomeArg -> SomeValue
и
void SomeObject::DoInconsistentModification(SomeArg) ?
Просто кое-кто умеет НЕ говнокодить на хаскелле.

Конечно, в языках с указателями на неконстантные объекты - легче привести систему в неконсистентное состояние:
- создать два объекта
- познакомить их друг с другом (дать второму ссылку на первого)
- изменить состояние одного объекта так, чтобы нарушились ожидания второго

Ну так и в хаскелле, умеючи.
Только в хаскелле (и вообще в языках с неизменяемыми данными) это делается на другом механизме. Не по указателю, а по имени.
- создать согласованную пару данных
- передавать-передавать-передавать её - как в монаде State, скажем
- где-нибудь взять и заменить один из компонентов, не проверив согласованность
- передавать-передавать-передавать дальше
- внезапно использовать оба компонента вместе

Reply

thesz October 20 2017, 11:09:42 UTC
Исчо раз.

Изменяемые данные это неявный канал обмена информацией между частями программы.

Фразу выше перечитайте сто тысяч раз, десять тысяч раз напишите на доске мелом и тысячу раз в тетради.

Если у вас *значение*, то оно никуда не денется, если его как угодно несогласованно копировали, в отличии от объекта, которые один раз изменив несогласованно, уже трудно вернуть в согласованное состояние. Со значениями неявных каналов меньше, чем с объектами (модели актёров это тоже касается).

"Неговнокодить" с неизменными данными проще, чем с изменяемыми. Тикль проще Питона в ежедневном использовании, а с dict вообще почти мечта (если бы не hash table внутре dict, из-за которой квадратичная сложность копирования)..

Reply


Leave a comment

Up