forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Обзор проблем в коде на C/C++, вызванных неопределённым пове..., opennews (ok), 07-Июл-17, (0) [смотреть все]

Во-первых -- 3 галлона пива господину Регеру за очень краткие и ёмкие кусочки ко, A.Stahl (ok), 11:12 , 07-Июл-17, (1) +31 //

Как думаете, почему профессионалы подвержены болезни усложнения кода У них крыш, Zoolander (?), 11:38 , 07-Июл-17, (2) //

Тоже вижу слишком часто неоправданное усложнение Может не солидно , что я как, Iaaa (ok), 11:45 , 07-Июл-17, (3) +3
Многие профессионалы сталкиваются с ситуацией, когда они сами пишут и проектирую, A.Stahl (ok), 12:04 , 07-Июл-17, (4) +16 //

А exception safety, move semantics, вот это всё - тоже игноришь Их без умных ук, Crazy Alex (ok), 12:15 , 07-Июл-17, (7) +3

Исключения не люблю, а вот move semantics почти не нужно если у тебя всё хорошо , A.Stahl (ok), 12:50 , 07-Июл-17, (11) +9

Создать объект и отдать его контейнеру - это редкая операция А если нет - то ли, Crazy Alex (ok), 13:57 , 07-Июл-17, (17) +3

Я обычно передаю указатель Редко бывает, когда объект нужен много кому и непоня, A.Stahl (ok), 15:04 , 07-Июл-17, (21) +4

А у меня - как-то через раз Лежит себе вектор указателей на объекты, чему-то од, Crazy Alex (ok), 15:36 , 07-Июл-17, (26)

Код является простым когда простой инспекцией удается выловить границы жизни объ, Аноним (-), 15:58 , 07-Июл-17, (29) +5

Красиво казал Меня там минусуют, но они не совсем понимают суть Я не против но, A.Stahl (ok), 16:15 , 07-Июл-17, (31) +6

Фишка в том, что очевидный для сишников и очевидный для плюсовиков - вещи ра, Crazy Alex (ok), 21:58 , 07-Июл-17, (54)

Это лишь ваше представление которое основано, к сожалению, на незнании или малоо, Аноним (-), 22:33 , 07-Июл-17, (60) +1
Ох как забавно Подход узнаем как должно работать и реализуем сразу велосипед,, Crazy Alex (ok), 01:40 , 08-Июл-17, (69) +1
Очень забавно потому что вот это - вменяемый разработчик вообще на любом языке , Аноним (-), 04:17 , 08-Июл-17, (74)
броо А вообще я редкостный хейтер всего кроме Си хотя писал на 100 языках , pripolz (?), 11:34 , 08-Июл-17, (80)
А вы и так не знаете, не переживайте Даже пишущий на ассемблере не знает, как о, Vkni (ok), 17:51 , 08-Июл-17, (100)
Это и не нужно, во-первых Во-вторых речь не о машинном исполнении была Ложное у, Аноним (-), 01:44 , 09-Июл-17, (124)
Ну да, на каком-то уровне приходится останавливаться Ну можно остановиться на а, Vkni (ok), 02:08 , 09-Июл-17, (127)
Зачем вообще вы снова асм тянете, я не пойму Вот люди пишут на java и не парятс, Аноним (-), 02:46 , 09-Июл-17, (129) –1
Ветка такая См несколько комментов выше , Vkni (ok), 02:56 , 09-Июл-17, (130)
В 12 54 Crazy Alex написал свое ОГРАНИЧЕННОЕ понимание программирования в Си, Аноним (-), 05:48 , 09-Июл-17, (133)
Я писал недавно зарегистрировавшемуся товарищу на букву p , Vkni (ok), 07:29 , 09-Июл-17, (135)
Точно, сообщение 12 80 от пользователя pripolz Но это не меняет ситуацию с пост, Аноним (-), 16:14 , 09-Июл-17, (140)

Я не кравиво сказал, а рассказал как оно обстоит в реальном программировании У , Аноним (-), 22:41 , 07-Июл-17, (61) +2

Умные указатели сложность, в общем, не особо прибавляют, если дать себе труд раз, Crazy Alex (ok), 21:45 , 07-Июл-17, (52)

Я хорошо знаю и умею использовать умные указатели и для меня это уже пройденный , не программист (?), 22:23 , 07-Июл-17, (59)

Единственная Ситуация, когда от них больше вреда, чем пользы - это когда в про, Crazy Alex (ok), 01:31 , 08-Июл-17, (68) –1
Вы вообще программировали что-нибудь серьезное Когда вы будете думать о том как, Аноним (-), 03:55 , 08-Июл-17, (71)

А как же Вы обрабатываете ошибки Я Плюсы знаю неплохо, но пишу на чистом Си Пр, Аноним (-), 22:19 , 07-Июл-17, (58) –1

я всю обработку ошибок кладу в макрос, в котором и печать в лог номера строки ко, pripolz (?), 11:52 , 08-Июл-17, (81) +2

Ну, у Вас по сути примерно такая же обработка ошибок, как и у нас А про плюсови, Аноним (-), 22:47 , 08-Июл-17, (119)
Их должно быть несколько, если выделяются сразу несколько ресурсов И не перепут, Vkni (ok), 23:54 , 08-Июл-17, (121)

инициализация нулями спасёт мирfor int i 0 i 5 i if f i f, pripolz (?), 02:08 , 09-Июл-17, (126) –1

Это костыль под конкретный случай Взять какую-нибудь другую структуру и опа , Vkni (ok), 02:14 , 09-Июл-17, (128)
упс, не по теме написал Сори , pripolz (?), 03:29 , 09-Июл-17, (131)

У нас на метки с освобождением ресурсов и восстановлением уходит до половины тел, Аноним (-), 09:15 , 09-Июл-17, (136)

Бред , yet another anonymous (?), 12:56 , 07-Июл-17, (13) –2

Говорю же - можно, но морока Придётся самому отслеживать все случаи, когда надо, Crazy Alex (ok), 14:00 , 07-Июл-17, (18)

move не имеет к _ptr отношения _ptr подразумевают move при достаточно полно, yet another anonymous (?), 15:05 , 07-Июл-17, (22)

Нет Подразумевалось умные указатели радикально упрощают реализацию move-семант, Crazy Alex (ok), 15:31 , 07-Июл-17, (23)

Т е второй вариант Мне нравится такой подход неявно подразумевается вполне опр, yet another anonymous (?), 17:18 , 07-Июл-17, (35)

Оно везде так Называется best practices Использование ничего-то отличающегос, Crazy Alex (ok), 21:51 , 07-Июл-17, (53)

Или ещё вариант на этапе проектирования закладывается больше гибкости и универс, kai3341 (ok), 15:35 , 07-Июл-17, (25)
Они будут правы А вот вы не будете Будете старым пердуном, который не успевает , anonymous (??), 17:13 , 07-Июл-17, (34) –3

Почитайте книгу Современный и эффективный С Там автор докажет вам, что auto, pripolz (?), 12:30 , 08-Июл-17, (82)

Правда Может вы что-то не так вычитали А если так, то замените auto на что-то , anonymous (??), 17:32 , 08-Июл-17, (97)
Можно ссылку , Vkni (ok), 17:46 , 08-Июл-17, (99)

Там ниже в беседе кидали на магаз О-Райли Effective Modern C Майерса , pripolz (?), 19:29 , 08-Июл-17, (105)

А-аа, Майерс Просто modern C - это в разные времена совершенно разное , Vkni (ok), 19:57 , 08-Июл-17, (110)

1 Профессионалы часто пишут что-то большое, и долго Со временем качество кода , Crazy Alex (ok), 12:08 , 07-Июл-17, (5) –2 //

Если будет падать качество кода, то упадёт и скорость разработки, и проект упрёт, Алконим (?), 01:23 , 08-Июл-17, (66)

Любой проект постепенно обрастает заплатками и требует специальных мер от команд, Вареник (?), 08:08 , 08-Июл-17, (76)
Написать модуль по спеку - не совсем жизненный цикл проекта Тот же проект потом, Вареник (?), 08:13 , 08-Июл-17, (77) +1
Полностью поддерживаю В нашей команде качество кода растёт со временем Во-перв, Аноним (-), 11:22 , 08-Июл-17, (79) +1

Желание того что-бы их код работал так как они решили, а не как вздумается компи, Аноним (-), 12:30 , 07-Июл-17, (9) –1
я за 15 лет вокруг как раз вижу что становясь профессионалами люди начинают упро, anonymous (??), 22:26 , 08-Июл-17, (117) +1

Скажи это новым появляющимся языкам программирования или таким языкам как C , у , Аноним (-), 13:15 , 07-Июл-17, (14) //

Ну, в этом есть и один плюс - C либы екзешники из-за этого очень легко восстано, Анончик (?), 16:04 , 07-Июл-17, (30) +1 //

Я про JIT говорил Первоначальная компиляция в CIL как и у Java в их промежуточ, Аноним (-), 17:29 , 07-Июл-17, (36) +2
У нормальных людей есть исходники с комментами, дока, и мэйл лист с аффтарами Но, _ (??), 17:54 , 07-Июл-17, (37) –5

RE занимаются не только вантузятники и не только на вантузе , Анончик (?), 22:13 , 07-Июл-17, (57) +1

Это не отменяет 100500 вариантов написания popcnt, для начала, которые хер компе, Ivan_83 (ok), 15:32 , 07-Июл-17, (24)
Это проблема восприятия маленьких понятных примеров Для того, чтобы показать пр, Comdiv (ok), 16:53 , 07-Июл-17, (33) +2

Ещё один с С С То, о чём он говорит, ловится любым приличным современным ли, Crazy Alex (ok), 12:13 , 07-Июл-17, (6) //

Каким образом линтер ловит выход за пределы массива и use after free , RazrFalcon (ok), 12:34 , 07-Июл-17, (10) //

Очень просто - ругается на попытки использовать сишные массивы и голые сишные ук, Crazy Alex (ok), 14:29 , 07-Июл-17, (19) +1 //

Ну то есть никак не находит выход за пределы массива Что показывает практическу, Анонимный Алкоголик (??), 10:20 , 10-Июл-17, (145) –1

Ну это ты загнул , A.Stahl (ok), 13:26 , 07-Июл-17, (15) +1 //

Не загибал https github com isocpp CppCoreGuidelines blob master CppCoreGuide, Crazy Alex (ok), 14:36 , 07-Июл-17, (20) +1
Нет, это не он загнул Просто кто-то отстал от развития практик применения C л, Ordu (ok), 15:46 , 07-Июл-17, (28) //

Это отдельная тема Специфическая тема Не моя тема , A.Stahl (ok), 18:02 , 07-Июл-17, (38) +1

При чём здесь моя или не моя Из наблюдений за копошением вокруг разных язык, Ordu (ok), 18:42 , 07-Июл-17, (41) +4

Хмм Что-то в вашей позиции есть интересное По крайней мере, даже Страуструпу, yet another anonymous (?), 19:09 , 07-Июл-17, (43) +2

Пинок инженера инженеру это всегда хорошо Хотя я и не рад смотря куда развиваютс, A.Stahl (ok), 19:58 , 07-Июл-17, (45) +1

Плюсы с самого начала были не до конца продуманным костылем Почитайте труды кри, Аноним (-), 22:59 , 07-Июл-17, (62) +1

Можно поподробнее Авторство, ссылочку С удовольствием бы почитал, интересуюсь , pripolz (?), 14:01 , 08-Июл-17, (85)

К сожалению я не могу дать вам ссылок, т к не нашел и не сохранил Я это читал , Аноним (-), 17:08 , 08-Июл-17, (94)
Unix Haters Handbook, страница 203 и далее Но надо понимать, что сейчас ЦэПэПэ , Vkni (ok), 17:43 , 08-Июл-17, (98)

gt оверквотинг удален Рекоммендую к прочтению код какого-нибудь авторитетного , pripolz (?), 14:06 , 08-Июл-17, (87)

gt оверквотинг удален Да-да, я знаю Всё можно написать на ассемблере Но заче, Ordu (ok), 14:29 , 08-Июл-17, (88) –1

Чтобы кода было меньше, а технологий больше Вообще все любители высокоуровневых, pripolz (?), 14:43 , 08-Июл-17, (90) +1

На ассемблере будет меньше кода Ха Ты попробуй писать на ассемблере Или на C , Ordu (ok), 15:32 , 08-Июл-17, (91) –2

именно так На си будет меньше кода Ты себя-то называешь умным человеком Речь о , pripolz (?), 16:02 , 08-Июл-17, (92)

Только если не использовать ООП и шаблоны там, где это не надо Ручная эмуляция , Vkni (ok), 17:53 , 08-Июл-17, (101)

1 Фишки Glib не пересекаются с фишками компилятора С вообще начнём с этого , pripolz (?), 18:38 , 08-Июл-17, (103) +2
Тем не менее, их эмуляции классов можно было бы сделать на С проще Вместо пре, Vkni (ok), 20:07 , 08-Июл-17, (111)
Практика показывает что ненадо чуть менее чем везде , Аноним (-), 22:24 , 08-Июл-17, (116) +1

Ты специально учился где-то демагогии или самоучкой Очень похоже на второе спе, Ordu (ok), 19:49 , 08-Июл-17, (107) –1

Если держать себя в руках, то на ООП на С получится лучше, т к не надо вручну, Vkni (ok), 17:55 , 08-Июл-17, (102)

1 то, что ты называешь возможностями я называю ограничениями 2 Пример очень пе, pripolz (?), 19:21 , 08-Июл-17, (104)

Вот конкретно здесь мы его неоднократно поднимали с CrazyАлексом, arisu и д р Си, Vkni (ok), 20:09 , 08-Июл-17, (112)

Опыи фортрана, лиспа, кобола и кучи других - выкинули Ну в таком ключе С тоже , _ (??), 18:16 , 07-Июл-17, (39) –1

Я не совсем понял к чему это Но опыт фортрана, лиспа, кобола и кучи других непр, Ordu (ok), 18:54 , 07-Июл-17, (42) +1

Да, Степанов свои идеи сначала на Lisp е реализовывал C как мультипарадигменн, yet another anonymous (?), 19:13 , 07-Июл-17, (44) –1

Можно пару-тройку ссылок на литературу хотя хватит и имен названий, отсутсвие п, Аноним (-), 20:22 , 07-Июл-17, (47)

Из того, что я видел - лучше всего именно гайд под редакцией Страуструпа Саттера, Crazy Alex (ok), 21:31 , 07-Июл-17, (50) +1

Благодарю Будем посмотреть , Аноним (-), 22:00 , 07-Июл-17, (55) –1

Мейерс http shop oreilly com product 0636920033707 do, Ordu (ok), 22:09 , 07-Июл-17, (56)
Очень рекомендую к просмотру, т к без нормальной критики вы не поймете язык пол, Аноним (-), 23:19 , 07-Июл-17, (65)

Как бы наоборот Для того, кто не поварился в плюсах с пол-года хотя бы этот тек, Crazy Alex (ok), 01:24 , 08-Июл-17, (67) +1
Там, мягко говоря, далеко не всё описано И по шаблонам с STL он как-то очень сл, Vkni (ok), 03:58 , 08-Июл-17, (72) +1

Согласен и поэтому автор предусмотрительно написал, Аноним (-), 04:21 , 08-Июл-17, (75)

Лучшая практика применения современного C - это можешь на нём не писать - не , Vkni (ok), 04:02 , 08-Июл-17, (73) +1

И чё с того Ты в курсе что предпочтения в эргономике тренируются Они не просто, Ordu (ok), 12:33 , 08-Июл-17, (83)

Зачем нужно видеть красоту в примерах из boost а, где в глазах просто рябит от с, Vkni (ok), 16:43 , 08-Июл-17, (93)

Для того, чтобы использовать C максимально эффективно Может быть другие отказы, Ordu (ok), 19:54 , 08-Июл-17, (108) –1

Кто это вам сказал Это потому, что вы не хотите видеть другие причины С другой , Vkni (ok), 20:16 , 08-Июл-17, (113)

Опыт десятков и сотен тысяч программистов, которые писали на C в различных сти, Ordu (ok), 20:58 , 08-Июл-17, (114) –1

Я совершенно не уверен в том, что статистика наведена правильно Вообще, руковод, Vkni (ok), 21:57 , 08-Июл-17, (115)

Да, это заговор ZOG Они подтасовывают данные, пишут лжеруководства и вообще вво, Ordu (ok), 23:43 , 08-Июл-17, (120) –1

Это не заговор Просто некоторые люди варятся в одном и том же добре уже довольн, Vkni (ok), 00:09 , 09-Июл-17, (122)
А Ну да Наконец-то всем на радостьМы теперь нашли слова такиеТе что лучше отра, Ordu (ok), 01:14 , 09-Июл-17, (123) –1
Конечно, import uses open значительно лучше Они ведь подразумевают развитую сис, Vkni (ok), 01:57 , 09-Июл-17, (125)
Видимо, опыт опыту рознь , Ordu (ok), 14:04 , 09-Июл-17, (138) –1
Разумеется - я и другие языки знаю , Vkni (ok), 16:22 , 09-Июл-17, (141)
Превед, GOLD , yet another anonymous (?), 11:35 , 10-Июл-17, (148)
С этой точки зрения разницы между ld и ld gold нет Одна, в целом, фигня , Vkni (ok), 07:45 , 12-Июл-17, (162)

gt оверквотинг удален Ещё через 5 лет стиль ещё сильнее отточится на 200 ст, pripolz (?), 12:50 , 08-Июл-17, (84)

Да Программирование не стоит на месте, развивается Методов всё больше Какой к, Ordu (ok), 14:05 , 08-Июл-17, (86) –1

программирование стоит на месте Хорошие программы, взрывающие мозг - это bash, , pripolz (?), 14:32 , 08-Июл-17, (89)

Очень, очень костная штука Хиндли-милнер, несчастный, был открыт за 20 двадцат, Vkni (ok), 17:20 , 08-Июл-17, (96)
Если тебе так кажется, то разуй глаза и посмотри по сторонам Даже алгоритмы сор, Ordu (ok), 19:32 , 08-Июл-17, (106) –1

Ага Потому, что формулы разные По крайней мере для евклидовой метрики , Vkni (ok), 19:57 , 08-Июл-17, (109)
Именно так, совершенно непонятно При чём тут принудительная связь между данными, pripolz (?), 04:53 , 09-Июл-17, (132) +1

В C это можно сделать разными методами и использовать ООП совершенно не обязат, Vkni (ok), 05:55 , 09-Июл-17, (134)

а в рантайме такой темплейт подхватит заранее неизвестный тип фигуры , pripolz (?), 11:11 , 09-Июл-17, (137)

Нет, конечно Но основная проблема тут не в языке, а в предметной области - у ва, Vkni (ok), 16:39 , 09-Июл-17, (142)

Ты путаешь каноны ООП с канонами C Современный C не любит наследование и с , Ordu (ok), 14:50 , 09-Июл-17, (139) –1

Очередная порция словесного поноса , Аноним (-), 18:26 , 09-Июл-17, (143) +1
Исключительно забавное заявление Во первых потому, что ООП - это шаблон проекти, pripolz (?), 23:33 , 09-Июл-17, (144) +1

Окститесь, 20 лет прошло с тех пор , Vkni (ok), 14:59 , 10-Июл-17, (150)

То есть, современный С не просто не любит наследование, а ДАВНО не любит насле, pripolz (?), 18:24 , 10-Июл-17, (151) +1
Ещё более забавно См Elements of Programming by A Stepanov , yet another anonymous (?), 20:06 , 10-Июл-17, (152) –1
Хуже - ОЧЕНЬ ДАВНО не любит наследование Если бы не Степанов с STL, а дальше Ал, Vkni (ok), 03:05 , 11-Июл-17, (153)
А шаблоны, несмотря на ряд косяков синтаксис, отсутствие раздельной компиляции , pripolz (?), 12:14 , 11-Июл-17, (154)
Во-первых, нет Он понятен только до определённого момента - пара ступеней вложе, Vkni (ok), 12:21 , 11-Июл-17, (155)
Ни разу в жизни не сталкивался Вообще шаблоны - большая редкость Применение ша, pripolz (?), 13:30 , 11-Июл-17, (156)
В каком чудном мире вы живете PS Это же вы где-то в этой теме сказали, что прог, anonymous (??), 14:01 , 11-Июл-17, (157) –1
Было преувеличение Если по порядку, тоDark Basic,Visual Basic 98 VB6 ,Free Bas, pripolz (?), 14:25 , 11-Июл-17, (158)
Ну почти всё закрыто Не хватает JavaScript а, языков семейства ML и Пролога , Vkni (ok), 02:25 , 12-Июл-17, (161)
Дневник молодого поэта Всю ночь писал стихи о любви Закрыл тему , anonymous yet another (?), 08:29 , 12-Июл-17, (163)
А вот это уже мешки синтаксического сахара Так и до диабета недалеко , anonymous yet another (?), 23:06 , 11-Июл-17, (160)

Вы не поняли Речь была о том, что в языке вам не хватает средства выразить неки, Анонимный Алкоголик (??), 11:48 , 10-Июл-17, (149) –1

Haskell, классы типов и т д instance Show Double where show d Проблема в, Vkni (ok), 22:28 , 08-Июл-17, (118)
- Когда захотите, изложите как полагается Выдающееся может получиться желание, Анонимный Алкоголик (??), 11:12 , 10-Июл-17, (147) –1

Совершенно верно Вон Наплодилось вас, проталкивателей стилей Норовящих поя, Анонимный Алкоголик (??), 10:39 , 10-Июл-17, (146)

Полезно, спасибо , Игорь (??), 13:56 , 07-Июл-17, (16) –1
И все таки почему например chromium начинает притормаживать, захлебываться и с т, manster (ok), 15:45 , 07-Июл-17, (27) –1 //

Потому что по сложности современный браузеры вплотную приблизились к операционны, _ (??), 18:18 , 07-Июл-17, (40) –3 //

Абсолютная чушь Вдумайся в значение слова браузер что означает обозреватель , Аноним (-), 20:21 , 07-Июл-17, (46) –2 //

Ойййй Для начала хотелось бы посмотреть на полноценную динамику в офисном реда, anomymous (?), 21:17 , 07-Июл-17, (48)

Вы кроме WordPad что-нибудь встречали , Аноним (-), 23:02 , 07-Июл-17, (63) –2

Тем не менее вся эта webня выглядит ужасающе сложно Даже потрясающе сложно для , Соня (??), 21:24 , 07-Июл-17, (49)

Это для вас лично Скрипты - это вообще огромный туnой костыль В целом там ниче, Аноним (-), 23:06 , 07-Июл-17, (64) –1

Тебя совсем не смущает, что аллокаторы памяти были созданы для многих десятков О, angra (ok), 09:01 , 08-Июл-17, (78)

Столь дилетантская попытка сравнения позорна для технического ресурса Вы дейтви, Аноним (-), 17:13 , 08-Июл-17, (95) –1

Много всего что по отдельности не сложно, но со странным поведением и так далее,, Соня (??), 19:19 , 11-Июл-17, (159)

Потому что современные браузеры - безумная попытка сделать рантайм для GUI-при, Crazy Alex (ok), 21:36 , 07-Июл-17, (51) +3 //

Нет, с пару тройкой вкладок все относительно хорошо Проблемы начинаются когда, manster (ok), 03:04 , 08-Июл-17, (70) –1

Сообщения [Сортировка по времени | RSS]

28. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Ordu (ok), 07-Июл-17, 15:46

Нет, это не он загнул. Просто кто-то отстал от развития практик применения C++ лет на десять. Как минимум лет на десять: в принципе boost с друзьями лет пятнадцать-двадцать уже как проталкивает современный стиль в C++. Как при этом можно писать на C++, считать себя квалифицированным профессионалом, и не понимать того, как и зачем C++ пришёл к современному стилю, и отказываться от него под предлогами вида "мне синтаксис не нравится"? Мне непонятно, как всё это может непротиворечиво жить в одной голове.
Когда десять лет назад я сталкивался со старыми пердунами, которые не принимали назначения шаблонов, и говорили что, мол, они из без шаблонов могут, это выглядело... ну, естественно, что ли? Чё скрывать, я сам тогда предпочитал C, к темплитам относился с подозрением, и уважительно заглядывал в рот этим старым пердунам, вещающим о том, насколько красивее оказывается их код, по сравнению с кодом всяких хипстеров, которые городят темплит на темплите. Но, когда я вижу такого рода людей сегодня, вообще не знаю, что думать. Сейчас же есть литература, которая объясняет, что в C++ есть, как это следует использовать, и почему именно так, а не как-нибудь иначе. Литература, обобщающая опыт всех тех тысяч (или десятков/сотен тысяч) программистов, которые писали на C++, которые читали чужой код, которые занимались рефакторингом кода, поддержкой его, которые много думали о том как лучше писать, которые экспериментировали с C++ с момента его появления. И вот так брать и выкидывать этот опыт в окно с формулировкой "мне синтаксис не нравится"... Вон из профессии, ничтожество.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

38. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +1 +/–

Сообщение от A.Stahl (ok), 07-Июл-17, 18:02

>boost
Это отдельная тема. Специфическая тема. Не моя тема.

Ответить | Правка | Наверх | Cообщить модератору

41. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +4 +/–

Сообщение от Ordu (ok), 07-Июл-17, 18:42

>>boost
> Это отдельная тема. Специфическая тема. Не моя тема.
При чём здесь "моя" или "не моя"? Из наблюдений за копошением вокруг разных языков я понял одну вещь: создатели любого языка, как правило, не знают как надо писать программы на их языке. Для того, чтобы выяснить как надо, требуются годы работы многих программистов, которые попробуют _все_ возможные способы, которые приходят на ум, выяснят к чему приводят эти разные способы, и сделают выводы о том, как надо писать код и как не надо.
Я видел это в haskell, и в C++. Я наблюдал за этим процессом в C, правда не в real-time, а в ретроспективе. Сейчас я наблюдаю подобное в rust -- куча мартышек, заражённых энтузиазмом, использует методы монте-карло для поиска оптимальных способов написания кода на rust. Но если говорить о C++, то он с приходом C++0x11, в общем определился с тем, в каком стиле должен писаться код на C++. boost же -- это один из примеров тех "мартышек", которые волею ли случая или благодаря недюжинному интеллекту или дару предвидения "угадали" как на C++ можно писать код, который будет и эффективным, и в то же время поддаваться поддержке, рефакторингу и расширению.
И мне выглядит невероятно странным и непрофессиональным заявление вида "мало ли, что они нарыли, исследуя язык, мне неинтересно, это не моё". Моё/не моё должно иметь какой-то прагматический подтекст. Программирование может быть и искусство, но критерии красоты в этом искусстве задаются практикой, а когда они отрываются от практики, получается может быть и красиво, но гoвнo.

Ответить | Правка | Наверх | Cообщить модератору

43. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +2 +/–

Сообщение от yet another anonymous (?), 07-Июл-17, 19:09

Хмм... Что-то в вашей позиции есть интересное. По крайней мере, даже Страуструпу понадобился пинок в виде ребят из университета Ватерлоо и Степанова.

Ответить | Правка | Наверх | Cообщить модератору

45. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +1 +/–

Сообщение от A.Stahl (ok), 07-Июл-17, 19:58

Пинок инженера инженеру это всегда хорошо.
Хотя я и не рад смотря куда развиваются плюсы.

Ответить | Правка | Наверх | Cообщить модератору

62. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +1 +/–

Сообщение от Аноним (-), 07-Июл-17, 22:59

Плюсы с самого начала были не до конца продуманным костылем. Почитайте труды критиков в адрес плюсов и Страуструпа конца 80х и середины 90х. Сила критики бывает такой что иногда это даже затягивает.

Ответить | Правка | Наверх | Cообщить модератору

85. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от pripolz (?), 08-Июл-17, 14:01

> Плюсы с самого начала были не до конца продуманным костылем. Почитайте труды
> критиков в адрес плюсов и Страуструпа конца 80х и середины 90х.
> Сила критики бывает такой что иногда это даже затягивает.
Можно поподробнее? Авторство, ссылочку? С удовольствием бы почитал, интересуюсь этой темой. Сам искал что-то подобное, но кроме эмоциональных экспрессий Линуса ничего не нашёл.

Ответить | Правка | Наверх | Cообщить модератору

94. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Аноним (-), 08-Июл-17, 17:08

К сожалению я не могу дать вам ссылок, т.к. не нашел и не сохранил. Я это читал много лет назад когда знакомился с обероном. Не думал что со временем будет сложно найти в интернете знания, себе не скачивал.

Ответить | Правка | Наверх | Cообщить модератору

98. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 08-Июл-17, 17:43

> Можно поподробнее? Авторство, ссылочку? С удовольствием бы почитал, интересуюсь этой темой.
Unix Haters Handbook, страница 203 и далее. Но надо понимать, что сейчас ЦэПэПэ движется в несколько другую сторону - тащит всё из ML/Haskell'а, как и хотели авторы UHH.

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

87. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от pripolz (?), 08-Июл-17, 14:06

>[оверквотинг удален]
> определился с тем, в каком стиле должен писаться код на C++.
> boost же -- это один из примеров тех "мартышек", которые волею
> ли случая или благодаря недюжинному интеллекту или дару предвидения "угадали" как
> на C++ можно писать код, который будет и эффективным, и в
> то же время поддаваться поддержке, рефакторингу и расширению.
> И мне выглядит невероятно странным и непрофессиональным заявление вида "мало ли, что
> они нарыли, исследуя язык, мне неинтересно, это не моё". Моё/не моё
> должно иметь какой-то прагматический подтекст. Программирование может быть и искусство,
> но критерии красоты в этом искусстве задаются практикой, а когда они
> отрываются от практики, получается может быть и красиво, но гoвнo.
Рекоммендую к прочтению код какого-нибудь авторитетного проекта с 10 летним возрастом. openssl например, или ffmpeg. Вы там найдёте всё: ООП, шаблоны, фабричные функции, и многое другое. Всё это на си. Огромные задачи, закрывающие целые разделы (openssl - - криптографию, ffmpeg - медиа) решены невероятно компактно, красиво и понятно.
А что сделано на boost ? Я вот видел внутри Adobe Premiere его например. Продукт тормозит и глючит на каждом шагу, что мене лично не удивляет. Как и буст в нём.

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

88. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от Ordu (ok), 08-Июл-17, 14:29

>[оверквотинг удален]
>> на C++ можно писать код, который будет и эффективным, и в
>> то же время поддаваться поддержке, рефакторингу и расширению.
>> И мне выглядит невероятно странным и непрофессиональным заявление вида "мало ли, что
>> они нарыли, исследуя язык, мне неинтересно, это не моё". Моё/не моё
>> должно иметь какой-то прагматический подтекст. Программирование может быть и искусство,
>> но критерии красоты в этом искусстве задаются практикой, а когда они
>> отрываются от практики, получается может быть и красиво, но гoвнo.
> Рекоммендую к прочтению код какого-нибудь авторитетного проекта с 10 летним возрастом.
> openssl например, или ffmpeg. Вы там найдёте всё: ООП, шаблоны, фабричные
> функции, и многое другое. Всё это на си.
Да-да, я знаю. Всё можно написать на ассемблере. Но зачем?
> Огромные задачи, закрывающие
> целые разделы (openssl - - криптографию, ffmpeg - медиа) решены невероятно
> компактно, красиво и понятно.
> А что сделано на boost ?
Десять секунд использования гугла и: http://www.boost.org/users/uses_open.html
Там ещё есть ссылочки на не-OSS проекты, если интересно глянь туда.
> Я вот видел внутри Adobe Premiere
> его например. Продукт тормозит и глючит на каждом шагу, что мене
> лично не удивляет. Как и буст в нём.
Продукция Adobe вообще тормозит вся и глючная до безобразия, вне зависимости от того, на чём она написана.

Ответить | Правка | Наверх | Cообщить модератору

90. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +1 +/–

Сообщение от pripolz (?), 08-Июл-17, 14:43

> Да-да, я знаю. Всё можно написать на ассемблере. Но зачем?
Чтобы кода было меньше, а технологий больше. Вообще все любители высокоуровневых языков тыкают в ассемблер. Это от незнания реалий ассемблера. Где он применяется и зачем.
> Десять секунд использования гугла и: http://www.boost.org/users/uses_open.html
> Там ещё есть ссылочки на не-OSS проекты, если интересно глянь туда.
сплошной ноунейм

Ответить | Правка | Наверх | Cообщить модератору

91. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –2 +/–

Сообщение от Ordu (ok), 08-Июл-17, 15:32

>> Да-да, я знаю. Всё можно написать на ассемблере. Но зачем?
> Чтобы кода было меньше, а технологий больше.
На ассемблере будет меньше кода? Ха. Ты попробуй писать на ассемблере. Или на C будет меньше кода? Ну-ну.
> Вообще все любители высокоуровневых языков
> тыкают в ассемблер. Это от незнания реалий ассемблера. Где он применяется
> и зачем.
Ой, ну ладно. Давай я буду тыкать в C? Тебе от этого полегчает? Какая тебе разница, скажу я "всё можно написать на ассемблере", или "всё можно написать на C", или "всё можно написать в машинных кодах", или "всё можно реализовать на машине Тьюринга"?
Что за манера вообще лезть со своей демагогией в разговор умных людей? Я тебе на яйца наступил упомянув ассемблер? Как я посмел своим грязным языком упомянуть ассемблер, в котором ты, судя по твоим словам, мнишь себя великими специалистом? Как я мог, да? Так вот я тебе скажу одну вещь: специалистом в ассемблере можно стать за полгода активного изучения архитектуры железа и системы команд этого процессора. Ещё полгода практики сделают из тебя окончательно сформировавшегося специалиста, которому в общем-то уже и некуда развиваться. С одной стороны это хорошо, конечно -- подготовка специалистов обходится дёшево, двух лет путяги после школы будет достаточно. С другой стороны, что этот специалист нам напишет? Килобайт прошивки для микроконтроллера? Который в случае чего проще написать заново, чем править написанный код? Какое это имеет отношение этот килобайт имеет к обсуждаемому предмету, в котором примерами софта выступает Adobe Premier?
>> Десять секунд использования гугла и: http://www.boost.org/users/uses_open.html
>> Там ещё есть ссылочки на не-OSS проекты, если интересно глянь туда.
> сплошной ноунейм
Опять демагогичный перевод стрелок. Речь идёт о гипотетической тормознутости кода, использующего boost, ты начинаешь говорить о распространённости кода, использующего boost. Разницы ты не видишь вообще или только прикидываешься идиотом?

Ответить | Правка | Наверх | Cообщить модератору

92. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от pripolz (?), 08-Июл-17, 16:02

> Или на C будет меньше кода? Ну-ну.
именно так. На си будет меньше кода.
> Что за манера вообще лезть со своей демагогией в разговор умных людей?
Ты себя-то называешь умным человеком?
> Опять демагогичный перевод стрелок. Речь идёт о гипотетической тормознутости кода, использующего
> boost, ты начинаешь говорить о распространённости кода, использующего boost.
Речь о том, что за свои "15 лет продвижения программирования вперёд" буст ничего не добился.

Ответить | Правка | Наверх | Cообщить модератору

101. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 08-Июл-17, 17:53

> именно так. На си будет меньше кода.
Только если не использовать ООП и шаблоны там, где это не надо. Ручная эмуляция компилятора C++ аля Glib2 и прочие извращения код только раздувают.

Ответить | Правка | Наверх | Cообщить модератору

103. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +2 +/–

Сообщение от pripolz (?), 08-Июл-17, 18:38

1) Фишки Glib не пересекаются с фишками компилятора С++ вообще начнём с этого.  У компилятора С++ что, есть сигналы? А может сообщения? Так же, обращаю внимание на то, что наследование в Glib - не то же самое, что наследование в C++, это динамическое наследование объектов, типа как в JavaScript.
API проектов на Glib, таких как GTK+ и GStreamer сложен потому, что ставит перед собой сложную задачу - понаделать биндингов для языков с динамическим ООП типа питона.
2) Лишний код С++ достигается из-за архитектурных проблем языка, которые напрямую приводят к костылям из-за своих необоснованных ограничений. Вот например метапрограммирование. Это по сути - "сгенерировать много функций с повторяющимися кусками кода из одной". В си достигается использованием препроцессора (лучше всего на include + ifdef, т.к. по такому коду можно ходить в старых версиях отладчика, но можно и чистыми дефайнами, если куски небольшие). В С++ метапрограммирование привязали к системе типов, что есть необоснованная ошибка архитектуры языка. Это приводит к тому, что приходится создавать шаблонные классы и перегружать у них функции просто для того, чтобы сгенерить пару функций, внутри которых часть кода будет принципиально отличаться. В итоге, шаблонный класс - это и есть тот самый лишний код.
Я много работаю с авторитетными С++ проектами и вижу одно и то же: огромные каскады из классов, которые ещё и вынесены в отдельные файлы, и эти классы не несут в себе никакой логики и функции вообще, их назначение - обойти ограничения, которые лежат в основе С++.

Ответить | Правка | Наверх | Cообщить модератору

111. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 08-Июл-17, 20:07

> 1) Фишки Glib не пересекаются с фишками компилятора С++ вообще начнём с
> этого.  У компилятора С++ что, есть сигналы? А может сообщения?
Тем не менее, их эмуляции классов можно было бы сделать на С++ проще. Вместо префиксов уж точно можно было использовать пространства имён. Без фанатизма, короче.
С другой стороны, С++ ный ABI не определён.
> и эти классы не несут в себе никакой логики и
> функции вообще, их назначение - обойти ограничения, которые лежат в основе
> С++.
Не совсем, цель - обойти ограничения ООП. Аналогичная фигня с паттернами в Java. Ну и навороты на шаблонах тоже никто делать не заставляет. Хотя, временами, ловлю себя на том, что пишу двух-трёхстрочный макрос вместо шаблонной функции.
Кроме того, очень многое зависит от культуры программиста. Культура текущих С++ных программистов - это делать излишние переусложнения на ровном месте. Например, не использовать printf, хотя он уже во всей большой тройке современных компиляторов полностью typechecked, а по интерфейсу значительно удобнее потоков.

Ответить | Правка | Наверх | Cообщить модератору

116. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +1 +/–

Сообщение от Аноним (-), 08-Июл-17, 22:24

> Только если не использовать ООП и шаблоны там, где это не надо.
Практика показывает что ненадо чуть менее чем везде.

Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

107. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от Ordu (ok), 08-Июл-17, 19:49

>> Опять демагогичный перевод стрелок. Речь идёт о гипотетической тормознутости кода, использующего
>> boost, ты начинаешь говорить о распространённости кода, использующего boost.
> Речь о том, что за свои "15 лет продвижения программирования вперёд" буст
> ничего не добился.
Ты специально учился где-то демагогии или самоучкой? Очень похоже на второе: специально обученные делают это не столь очевидно.

Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

102. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 08-Июл-17, 17:55

> Рекоммендую к прочтению код какого-нибудь авторитетного проекта с 10 летним возрастом.
> openssl например, или ffmpeg. Вы там найдёте всё: ООП, шаблоны, фабричные
> функции, и многое другое.
Если держать себя в руках, то на ООП на С++ получится лучше, т.к. не надо вручную возиться с vptr/vtable. Другое дело, что от обилия возможностей у многих в руках начинает свербить.

Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

104. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от pripolz (?), 08-Июл-17, 19:21

> Если держать себя в руках, то на ООП на С++ получится лучше,
> т.к. не надо вручную возиться с vptr/vtable. Другое дело, что от
> обилия возможностей у многих в руках начинает свербить.
1) то, что ты называешь возможностями я называю ограничениями.
2) Пример очень печального ограничения, вводимого ПРИНУДИТЕЛЬНЫМ НАЛИЧИЕМ vptr/vtable - это невозможность в некоторых случаях сохранить совместимость разных версий API/ABI после расширения. Этот вопрос у С++ников как правило вообще не поднимается, потому, что чтобы достугнуть хоть какой-то совместимости API между версиями нужно уже обратиться к Си: вынести конструктор класса в отдельную сишную функцию, а сам класс описать как набор виртуальных ф-ий.
Под совместимостью АПИ я подразумеваю, что можно подложить либу новой версии к старой версии программы, после добавления новых функций.
т.е. кошерный API на си - это:
typedef struct obj_s obj;
obj * new_obj(void); // construct
void delete_obj(obj*); // destruct
int method1(obj*, int);
void method2(obj*);
При таком оформлении АПИ можно добавить новый метод с сохранением работы новой либы на старой версии программы (которая была скомпилена ещё со старым .h и стоит где-то на объекте. Скажем, на газовой станции.).
На С++ приходится исхищряться:
extern "C" {
obj * new_obj(void);
void delete_obj(obj*);
}
class obj {
virtual method1(int) = 0;
virtual method2() = 0;
};

Как видишь, уже начинается костылизация. Но основная печаль не в этом.
Если от класса obj что-то унаследуется в API (в сишном случае можно просто применить уже имеющиеся методы к наследуемому классу), то ничего ты уже в obj не добавишь.
Поэтому самые крутые С++сники просто забивают на совместимость версий, и хреначат описание всего класса прямо в хедер. Техподдержка от этого страдает.

Ответить | Правка | Наверх | Cообщить модератору

112. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 08-Июл-17, 20:09

> - это невозможность в некоторых случаях сохранить совместимость разных версий API/ABI
> после расширения. Этот вопрос у С++ников как правило вообще не поднимается,
Вот конкретно здесь мы его неоднократно поднимали с CrazyАлексом, arisu и д.р.
Ситуация даже хуже, чем вы излагаете. Если я беру один и тот же проект с плагинами, компилирую их разными версиями gcc/clang и т.д. бинарная совместимость не гарантирована. Даже с учёто того, что исходник абсолютно один и тот же.
Но, возможно, это действительно ситуация разряда "сгорел сарай, гори и хата" - с С++ной реализацией наследования и обратной бинарной совместимостью действительно полный Пэ.

Ответить | Правка | Наверх | Cообщить модератору

39. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от _ (??), 07-Июл-17, 18:16

Опыи фортрана, лиспа, кобола и кучи других - выкинули?
Ну в таком ключе С++ тоже выкинут.

И кстати, то как ты это описал - это не профессия, это - религия.

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

42. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +1 +/–

Сообщение от Ordu (ok), 07-Июл-17, 18:54

> Опыи фортрана, лиспа, кобола и кучи других - выкинули?
> Ну в таком ключе С++ тоже выкинут.
Я не совсем понял к чему это. Но опыт фортрана, лиспа, кобола и кучи других неприменим непосредственно в C++. Этот опыт надо переосмыслить, надо попробовать его привнести в C++ и так, и эдак, надо почистить этот опыт от того, что не нужно в C++. А после этого опыт фортрана, лиспа, кобола и кучи других станет опытом C++.
И да, C++ тоже выкинут со временем. Но не в обозримом будущем.
> И кстати, то как ты это описал - это не профессия, это
> - религия.
Что именно? Я описал два разных взгляда на ситуацию, какой из них для тебя выглядит религией? Вера старых пердунов в то, что те практики, которые они применяли десятилетиями всегда будут лучше любых новых? Или вера в то, что программирование развивается и как искусство, и как ремесло, и как профессия, что развитие это неизбежно, а борьба с ним бесполезна и контрпродуктивна?

Ответить | Правка | Наверх | Cообщить модератору

44. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от yet another anonymous (?), 07-Июл-17, 19:13

> ... Но опыт фортрана, лиспа, кобола
> и кучи других неприменим непосредственно в C++. Этот опыт надо переосмыслить,
> надо попробовать его привнести в C++ и так, и эдак, надо
> почистить этот опыт от того, что не нужно в C++. А
> после этого опыт фортрана, лиспа, кобола и кучи других станет опытом
> C++.
Да, Степанов свои идеи сначала на Lisp'е реализовывал. C++ как мультипарадигменный язык подошёл лучше.

Ответить | Правка | Наверх | Cообщить модератору

47. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Аноним (-), 07-Июл-17, 20:22

> Литература, обобщающая опыт всех тех тысяч (или десятков/сотен
> тысяч) программистов, которые писали на C++,
Можно пару-тройку ссылок на литературу (хотя хватит и имен/названий, отсутсвие перевода не помеха) "как писать на современных плюсах"?
А то ведь графоманов-любителей много, без опыта нарвешься на какой нибудь "шыдевр", от которого у тех, кто в теме, волосы на *опе дыбом становятся.

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

50. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +1 +/–

Сообщение от Crazy Alex (ok), 07-Июл-17, 21:31

Из того, что я видел - лучше всего именно гайд под редакцией Страуструпа/Саттера на https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC.... В C++ Faq также есть и рекомендуемые книги причём разные варианты с учётом бэкграунда. Ну и Мейерс, "Effective Modern C++".

Ответить | Правка | Наверх | Cообщить модератору

55. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от Аноним (-), 07-Июл-17, 22:00

Благодарю. Будем посмотреть.

Ответить | Правка | Наверх | Cообщить модератору

56. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Ordu (ok), 07-Июл-17, 22:09

> Можно пару-тройку ссылок на литературу (хотя хватит и имен/названий, отсутсвие перевода
> не помеха) "как писать на современных плюсах"?
> А то ведь графоманов-любителей много, без опыта нарвешься на какой нибудь "шыдевр",
> от которого у тех, кто в теме, волосы на *опе дыбом
> становятся.
Мейерс. http://shop.oreilly.com/product/0636920033707.do

Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

65. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Аноним (-), 07-Июл-17, 23:19

Очень рекомендую к просмотру, т.к. без нормальной критики вы не поймете язык полностью: https://flyx.org/2014/04/24/cpp_sucks/

Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

67. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +1 +/–

Сообщение от Crazy Alex (ok), 08-Июл-17, 01:24

Как бы наоборот. Для того, кто не поварился в плюсах с пол-года хотя бы этот текст - бессмысленный набор слов. А вот потом можно и поглядеть. Правда, тогда будет понятно, что это всё либо чушь, либо мелочные придирки - а так не интересно.

Ответить | Правка | Наверх | Cообщить модератору

72. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +1 +/–

Сообщение от Vkni (ok), 08-Июл-17, 03:58

> Очень рекомендую к просмотру, т.к. без нормальной критики вы не поймете язык
> полностью: https://flyx.org/2014/04/24/cpp_sucks/
Там, мягко говоря, далеко не всё описано. И по шаблонам с STL он как-то очень слабо проехался. Нет, например, классического упрёка, что в STL везде торчат итераторы, а должны быть регионы. Ну, а синтаксис шаблонов - это просто редкостное уродство.

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

75. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Аноним (-), 08-Июл-17, 04:21

Согласен и поэтому автор предусмотрительно написал
> Disclaimer: This list is not and will never be complete (but I may update it if I'm bored). It also contains strong language.

Ответить | Правка | Наверх | Cообщить модератору

73. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +1 +/–

Сообщение от Vkni (ok), 08-Июл-17, 04:02

> Нет, это не он загнул. Просто кто-то отстал от развития практик применения
> C++ лет на десять.
Лучшая практика применения современного C++ - это "можешь на нём не писать - не пиши".
> под предлогами вида "мне синтаксис не нравится"?
Синтаксис - это, вообще-то, первое, что видно в программе. Ну зачем же сразу в дерьмо читателя макать со всеми std::...? И это, надо сказать, подход boost'a.

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

83. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Ordu (ok), 08-Июл-17, 12:33

>> под предлогами вида "мне синтаксис не нравится"?
> Синтаксис - это, вообще-то, первое, что видно в программе.
И чё с того? Ты в курсе что предпочтения в эргономике тренируются? Они не просто приобретённые, они приобретаемые. Разговоры про на вкус и цвет разные фломастеры -- это разговоры неудачников. Научиться видеть C++ код как красивый не сложнее, чем научиться им пользоваться. Даже если этот код видится тебе уродливым. Отказываться от инструмента потому, что тебе не нравится его внешний вид -- это очень странно. Можно отказываться потому, что инструмент не подходит для круга решаемых задач. Могут быть другие разумные причины. Но отказываться исходя сугубо из личных предпочтений, не связанных с тем, насколько этот инструмент полезный -- это очень странно.

Ответить | Правка | Наверх | Cообщить модератору

93. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 08-Июл-17, 16:43

> Научиться видеть C++ код как красивый не сложнее, чем научиться им пользоваться.
Зачем нужно видеть красоту в примерах из boost'а, где в глазах просто рябит от символов <, >, ::, {} и адового кол-ва подчёркиваний?
> Отказываться от инструмента потому, что тебе не нравится его внешний вид -- это очень странно.
Отказываются не по этому, а потому, что язык безумно переусложнён. И поэтому не так хорошо предсказуем, как более простые.

Ответить | Правка | Наверх | Cообщить модератору

108. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от Ordu (ok), 08-Июл-17, 19:54

>> Научиться видеть C++ код как красивый не сложнее, чем научиться им пользоваться.
> Зачем нужно видеть красоту в примерах из boost'а, где в глазах просто
> рябит от символов <, >, ::, {} и адового кол-ва подчёркиваний?
Для того, чтобы использовать C++ максимально эффективно.
>> Отказываться от инструмента потому, что тебе не нравится его внешний вид -- это очень странно.
> Отказываются не по этому, а потому, что язык безумно переусложнён. И поэтому
> не так хорошо предсказуем, как более простые.
Может быть другие отказывают по этим причинам. Но в этом треде я не слышал ни одной причины, кроме "мне не нравится внешний вид".

Ответить | Правка | Наверх | Cообщить модератору

113. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 08-Июл-17, 20:16

> Для того, чтобы использовать C++ максимально эффективно.
Кто это вам сказал?
> Может быть другие отказывают по этим причинам. Но в этом треде я
> не слышал ни одной причины, кроме "мне не нравится внешний вид".
Это потому, что вы не хотите видеть другие причины. С другой стороны, синтаксис, приводящий к излишней многословности - это недостаток языка. Сравните, например:
template< class RandomIt, class Compare >
void sort( RandomIt first, RandomIt last, Compare comp );
и
val sort : ('a -> 'a -> int) -> 'a array -> unit
или
sortBy :: (a -> a -> Ordering) -> Seq a -> Seq a

Ответить | Правка | Наверх | Cообщить модератору

114. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от Ordu (ok), 08-Июл-17, 20:58

>> Для того, чтобы использовать C++ максимально эффективно.
> Кто это вам сказал?
Опыт десятков и сотен тысяч программистов, которые писали на C++ в различных стилях. У меня есть склонность считать себя умнее всех остальных, но когда этих остальных на несколько порядков больше чем меня, и работа ими проделанная ещё больше, я всё же склонен засунуть своё ЧСВ поглубже с глаз долой и доверять специалистам. И вам, кстати, рекомендую поступать так же.
>> Может быть другие отказывают по этим причинам. Но в этом треде я
>> не слышал ни одной причины, кроме "мне не нравится внешний вид".
> Это потому, что вы не хотите видеть другие причины.
Ссылки в студию. Где тут упоминаются другие причины, которые я не хочу видеть? В последних двух комментариях в данном треде? Или где-то ещё?
> С другой стороны, синтаксис, приводящий к излишней многословности - это недостаток языка. Сравните, например:
> template< class RandomIt, class Compare >
> void sort( RandomIt first, RandomIt last, Compare comp );
> и
> val sort : ('a -> 'a -> int) -> 'a array ->
> unit
Замените 'a на 'RandomIt, добавьте комментарий, который заменит ту информацию для программиста, которую несут имена идентификаторов first, last, comp. И, смотрите-ка, разница уже не столь велика оказывается. Лишние слова всё же есть, да. Но их вполне можно потрепеть -- в конце-концов, привычка -- отличная штука, лишние слова просто не замечаешь со временем. Я предпочитаю rust вовсе не из-за этих слов, мне они не мешают.

Ответить | Правка | Наверх | Cообщить модератору

115. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 08-Июл-17, 21:57

> У меня есть склонность считать себя умнее всех остальных, но когда этих остальных на несколько порядков больше чем меня, и работа ими проделанная ещё больше, я всё же склонен засунуть своё ЧСВ поглубже с глаз долой и доверять специалистам.
Я совершенно не уверен в том, что статистика наведена правильно. Вообще, руководства, пестрящие std:: и прочими излишними многословиями заствляют задуматься.
> Ссылки в студию. Где тут упоминаются другие причины, которые я не хочу видеть?
Ну вот проблемы с ABI были, обсуждалось выше. Отсутствие pattern-matching'а (я знаю про библиотеку одного моего знакомого), слишком сильное использование препроцессора.
> И, смотрите-ка, разница уже не столь велика оказывается.
Разница в объёмах двукратная при том же объёме информации. И никуда от неё не деться.
Разделение на first/last - это в 99% лишняя информация. Но там, где это нужно, делают срезы - slice, аля SML - http://sml-family.org/Basis/vector-slice.html#VECTOR_SLICE:S...

Ответить | Правка | Наверх | Cообщить модератору

120. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от Ordu (ok), 08-Июл-17, 23:43

>> У меня есть склонность считать себя умнее всех остальных, но когда этих остальных на несколько порядков больше чем меня, и работа ими проделанная ещё больше, я всё же склонен засунуть своё ЧСВ поглубже с глаз долой и доверять специалистам.
> Я совершенно не уверен в том, что статистика наведена правильно. Вообще, руководства,
> пестрящие std:: и прочими излишними многословиями заствляют задуматься.
Да, это заговор ZOG. Они подтасовывают данные, пишут лжеруководства и вообще вводят нас всячески в заблуждение.
Когда что-то заставляет задуматься -- это хорошо, но когда процесс мышления не приводит в результате к развитию, то это был не процесс мышления, а интеллектуальная мастурбация.
>> Ссылки в студию. Где тут упоминаются другие причины, которые я не хочу видеть?
> Ну вот проблемы с ABI были, обсуждалось выше. Отсутствие pattern-matching'а (я знаю
> про библиотеку одного моего знакомого), слишком сильное использование препроцессора.
У C++ есть проблемы с ABI, но не те, о которых говорили. Матчинг -- да, это удобно, но эмм... в C матчинга больше? А насчёт слишком много препроцессора -- это о чём? О количестве #define и #ifdef или о темплитах? Первое совсем уж идиотизм, предположу про второе, и скажу вот что: какая разница сколько там препроцессора? Как по мне, так в C++ как раз не хватает нормального препроцессора, который будет работать именно с синтаксисом. Темплиты слишком специализированы, а C'шный пережиток динозавров вообще ни на что не годиться. Надо больше препроцессора, но не такого.
>> И, смотрите-ка, разница уже не столь велика оказывается.
> Разница в объёмах двукратная при том же объёме информации.
Мы продолжаем спорить о том, что красиво, а что нет? Или таки примем за факт, что красота в инженерном деле должна служить исключительно инструментальным целям и, таким образом, быть починена другим целям?

Ответить | Правка | Наверх | Cообщить модератору

122. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 09-Июл-17, 00:09

> Да, это заговор ZOG. Они подтасовывают данные, пишут лжеруководства и вообще вводят
> нас всячески в заблуждение.
Это не заговор. Просто некоторые люди варятся в одном и том же добре уже довольно долгое время, глаз замылился.
> Когда что-то заставляет задуматься -- это хорошо, но когда процесс мышления не
> приводит в результате к развитию, то это был не процесс мышления,
> а интеллектуальная мастурбация.
> У C++ есть проблемы с ABI, но не те, о которых говорили.
> Матчинг -- да, это удобно, но эмм... в C матчинга больше?
С давно уже тоже пора на помойку.

> А насчёт слишком много препроцессора -- это о чём?
Это об #include в первую очередь.
> или о темплитах? Первое совсем уж идиотизм, предположу
> про второе, и скажу вот что: какая разница сколько там препроцессора?
Такое ощущение, что вы не очень понимаете, о чём пишете - шаблоны и препроцессор, это совершенно разные и независимые вещи.
> Как по мне, так в C++ как раз не хватает нормального
> препроцессора, который будет работать именно с синтаксисом.
Пробовали в Ocaml'е - Camlp4/p5. Не взлетело, т.к. слишком сложно. Более правильный подход в Хаскеле - мощный основной язык с разными "deriving" + Cшный препроцессор, который может слегка изменить код, подточив под версию языка или библиотеки. Но не больше, чем пара-тройка #ifdef'ов на файл.
Совсем без препроцессора плохо, но заменять им основной язык невозможно - они рассинхронизуются, разделены и т.д.
> Мы продолжаем спорить о том, что красиво, а что нет? Или таки
> примем за факт, что красота в инженерном деле должна служить исключительно
> инструментальным целям и, таким образом, быть починена другим целям?
Ну вот в данном случае Ocaml и Haskell явно красивее C++-а, т.к. инженерная цель - максимально простое, экспрессивное и краткое описание одной и той же полиморфной функции лучше даётся им.

Ответить | Правка | Наверх | Cообщить модератору

123. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от Ordu (ok), 09-Июл-17, 01:14

>> Да, это заговор ZOG. Они подтасовывают данные, пишут лжеруководства и вообще вводят
>> нас всячески в заблуждение.
> Это не заговор. Просто некоторые люди варятся в одном и том же
> добре уже довольно долгое время, глаз замылился.
А. Ну да.
Наконец-то всем на радость
Мы теперь нашли слова такие
Те что лучше отражают
Положение вещей
Мы всех лучше, мы всех краше,
Всех умнее, и скромнее всех,
Превосходим в совершенствах
Всевозможные хвалы
https://www.youtube.com/watch?v=j6NImmmYtlA
>> Когда что-то заставляет задуматься -- это хорошо, но когда процесс мышления не
>> приводит в результате к развитию, то это был не процесс мышления,
>> а интеллектуальная мастурбация.
>> У C++ есть проблемы с ABI, но не те, о которых говорили.
>> Матчинг -- да, это удобно, но эмм... в C матчинга больше?
> С давно уже тоже пора на помойку.
>> А насчёт слишком много препроцессора -- это о чём?
> Это об #include в первую очередь.
А. Да. Я понял. Вам опять синтаксис не нравится? import в java/python лучше? (require ..) в CL? use в rust?
>> или о темплитах? Первое совсем уж идиотизм, предположу
>> про второе, и скажу вот что: какая разница сколько там препроцессора?
> Такое ощущение, что вы не очень понимаете, о чём пишете - шаблоны
> и препроцессор, это совершенно разные и независимые вещи.
Препроцессор и темплиты -- это способы кодогенерации. Они решают в общем одни и те же задачи -- писать код за программиста, но темплиты с одной стороны более мощный инструмент, чем C'шный препроцессор, с другой стороны более узко заточены.
>> Как по мне, так в C++ как раз не хватает нормального
>> препроцессора, который будет работать именно с синтаксисом.
> Пробовали в Ocaml'е - Camlp4/p5. Не взлетело, т.к. слишком сложно. Более правильный
> подход в Хаскеле - мощный основной язык с разными "deriving" +
> Cшный препроцессор, который может слегка изменить код, подточив под версию языка
> или библиотеки. Но не больше, чем пара-тройка #ifdef'ов на файл.
Я не знаю, как там в Ocaml'е, но в lisp'е макроязык -- это что-то с чем-то. В racket его ещё довели до ума, типизацию ему приделали -- вообще няшка. В rust тоже очень неплохо получается. Так что на один неудачный опыт ocaml'а, есть три удачных опыта других. Может они там в ocaml'е что-то не то делали?
> Совсем без препроцессора плохо, но заменять им основной язык невозможно - они
> рассинхронизуются, разделены и т.д.
Да, препроцессор без основного языка -- бессмыслица. Препроцессор -- это кодогенератор, но на каком языке он будет генерить код, если нет основного?
>> Мы продолжаем спорить о том, что красиво, а что нет? Или таки
>> примем за факт, что красота в инженерном деле должна служить исключительно
>> инструментальным целям и, таким образом, быть починена другим целям?
> Ну вот в данном случае Ocaml и Haskell явно красивее C++-а, т.к.
> инженерная цель - максимально простое, экспрессивное и краткое описание одной и
> той же полиморфной функции лучше даётся им.
Ещё раз скажу вам: красивым будет любой привычный язык. Он при этом может быть сколь угодно галимым языком, но если он привычен, то он будет восприниматься как красивый. Это особенности человеческой психологии так сказываются. Поэтому поймите наконец одну вещь: аргументы типа "красиво" для меня -- пустой звук. Аргументы типа "красиво" -- отражают не положение дел в реальности, а свойства вашей психики. Причём даже не какие-то фундаментальные и неизменные свойства психики, а приобретённые и постоянно изменяющиеся свойства. Эти свойства не имеют никакого отношения к тому, насколько удачен тот или иной язык программирования для той или иной задачи.

Ответить | Правка | Наверх | Cообщить модератору

125. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 09-Июл-17, 01:57

> А. Да. Я понял. Вам опять синтаксис не нравится? import в java/python
> лучше? (require ..) в CL? use в rust?
Конечно, import/uses/open значительно лучше. Они ведь подразумевают развитую систему модулей, а не паразитирование на допотопном однопроходном линковщике.
> Препроцессор и темплиты -- это способы кодогенерации.
Вы не поверите, но любой ЯВУ - это способ кодогенерации. Чересчур широко обобщаете. :-)
> Я не знаю, как там в Ocaml'е, но в lisp'е макроязык --
> это что-то с чем-то. В racket его ещё довели до ума,
> типизацию ему приделали -- вообще няшка.
> В rust тоже очень неплохо получается. Так что на один
> неудачный опыт ocaml'а, есть три удачных
> опыта других. Может они там в ocaml'е что-то не то делали?
Да у них тоже нормально типа получилось, ан люди не пользуются.
Переехали на ppa. Посмотрим, что у этих будет лет через 5.
> Ещё раз скажу вам: красивым будет любой привычный язык.
У меня опыт владения ЦэПэПэ где-то лет 20 уже. Ocaml'а - десяток.

Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

138. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от Ordu (ok), 09-Июл-17, 14:04

>> Ещё раз скажу вам: красивым будет любой привычный язык.
> У меня опыт владения ЦэПэПэ где-то лет 20 уже. Ocaml'а - десяток.
Видимо, опыт опыту рознь.

Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

141. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 09-Июл-17, 16:22

Разумеется - я и другие языки знаю.

Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

148. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от yet another anonymous (?), 10-Июл-17, 11:35

> Конечно, import/uses/open значительно лучше. Они ведь подразумевают развитую систему модулей, а не паразитирование на допотопном однопроходном линковщике.
Превед, GOLD! ;)

Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

162. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 12-Июл-17, 07:45

> Превед, GOLD! ;)
С этой точки зрения разницы между ld и ld.gold нет. Одна, в целом, фигня.

Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

84. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от pripolz (?), 08-Июл-17, 12:50

>[оверквотинг удален]
> код, по сравнению с кодом всяких хипстеров, которые городят темплит на
> темплите. Но, когда я вижу такого рода людей сегодня, вообще не
> знаю, что думать. Сейчас же есть литература, которая объясняет, что в
> C++ есть, как это следует использовать, и почему именно так, а
> не как-нибудь иначе. Литература, обобщающая опыт всех тех тысяч (или десятков/сотен
> тысяч) программистов, которые писали на C++, которые читали чужой код, которые
> занимались рефакторингом кода, поддержкой его, которые много думали о том как
> лучше писать, которые экспериментировали с C++ с момента его появления. И
> вот так брать и выкидывать этот опыт в окно с формулировкой
> "мне синтаксис не нравится"... Вон из профессии, ничтожество.
Ещё через 5 лет стиль ещё сильнее "отточится" на +200 страниц к стандарту. И выйдет ещё литература, объясняющая новые костыли проблемами старых.
Сейчас я тебе кое-что покажу:
Вот класс - это изначально структура данных + набор методов с ней. В с++ структура и методы принудительно жёстко связаны. А если я захочу написать один метод для 3х классов? А если я захочу подгрузить метод из динамически загруженной либы, которую пользователь выбрал где-то? Это уже проблема архитектуры языка. Приятного времяпрепровождения в профессии.

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

86. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от Ordu (ok), 08-Июл-17, 14:05

> Ещё через 5 лет стиль ещё сильнее "отточится" на +200 страниц к стандарту. И выйдет ещё литература, объясняющая новые костыли проблемами старых.
Да. Программирование не стоит на месте, развивается. Методов всё больше. Какой кошмар.
> Сейчас я тебе кое-что покажу:
> Вот класс - это изначально структура данных + набор методов с ней.
> В с++ структура и методы принудительно жёстко связаны. А если я
> захочу написать один метод для 3х классов?
Если ты захочешь, то это значит что ты неудачник. Либо тебе досталась уродская задача, либо ты выбрал не тот подход к её решению. Если у тебя есть три аргумента, каждый из которых является дочерним от класса A, и таких дочерних классов у A три штуки -- B, C, D, то тебе придётся писать 3^3 реализаций методов -- (B, B, B), (B, B, C) (C, D, B), (C, C, D), и так далее. 27 долбаных функций. Если ты добавишь к A ещё один дочерний класс, то количество методов скакнёт до 64. Поверь мне, ты повесишся раньше, чем допишешь эту программу. Причём вне зависимости от выбранного языка: этот заморочный диспатч можно сделать хоть на ассемблере, проблем-то? Но вот степенная зависимость количества реализаций методов от количества типов -- это убийственно.

Ответить | Правка | Наверх | Cообщить модератору

89. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от pripolz (?), 08-Июл-17, 14:32

> Да. Программирование не стоит на месте, развивается. Методов всё больше. Какой кошмар.
программирование стоит на месте. Хорошие программы, взрывающие мозг - это bash, qemu, openvpn. Там поставлена интересная абстрактная задача. Сегодня "революцией" называют docker. Это просто смешно.
> Если ты захочешь, то это значит что ты неудачник. Либо тебе досталась
> уродская задача, либо ты выбрал не тот подход к её решению.
Типичный пример ограниченности мышления. Если я захочу, чтобы моя программа легко собиралась на любом железе и ос, то наверное я.. псих? А если я захочу, чтобы она потребляла меньше 200 мб оперативки, то я кто? Романтик? А если я захочу не писать каскад из классов-хелперов?

> Если у тебя есть три аргумента, каждый из которых является дочерним
> от класса A, и таких дочерних классов у A три штуки
> -- B, C, D, то тебе придётся писать 3^3 реализаций методов
> -- (B, B, B), (B, B, C) (C, D, B), (C,
> C, D), и так далее. 27 долбаных функций. Если ты добавишь
> к A ещё один дочерний класс, то количество методов скакнёт до
> 64.
Намёк не понят. Хочешь наследование - положи структуру в структуру.

Ответить | Правка | Наверх | Cообщить модератору

96. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 08-Июл-17, 17:20

> программирование стоит на месте.
Очень, очень костная штука. Хиндли-милнер, несчастный, был открыт за 20 (двадцать) лет до возникновения шаблонов в С++.

Ответить | Правка | Наверх | Cообщить модератору

106. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от Ordu (ok), 08-Июл-17, 19:32

>> Да. Программирование не стоит на месте, развивается. Методов всё больше. Какой кошмар.
> программирование стоит на месте.
Если тебе так кажется, то разуй глаза и посмотри по сторонам. Даже алгоритмы сортировки, которые проходят в школе развиваются, меняются, подстраиваются под новые реалии. Я уж молчу про структуры данных. Ты в курсе, например, что списки устарели морально лет двадцать назад, и теперь применять их в программах, которым требуется производительность не стоит?
> Хорошие программы, взрывающие мозг - это bash, qemu,
> openvpn. Там поставлена интересная абстрактная задача.
Ещё упомяни R, Perl, PHP и тому подобную гадость, которая дожила до современности со своим взрывающим мозг синтаксисом.
>> Если ты захочешь, то это значит что ты неудачник. Либо тебе досталась
>> уродская задача, либо ты выбрал не тот подход к её решению.
> Типичный пример ограниченности мышления. Если я захочу, чтобы моя программа легко собиралась
> на любом железе и ос, то наверное я.. псих? А если
> я захочу, чтобы она потребляла меньше 200 мб оперативки, то я
> кто? Романтик? А если я захочу не писать каскад из классов-хелперов?
Смотри, чуть ниже ты пишешь, что не понял о чём я. Но если ты не понял о чём я, то зачем тогда ты гадаешь, делаешь неверные выводы, придумываешь себе соломенное чучело, которое блестяще побеждаешь? Ты действительно думаешь, что использование демагогии позволяет тебе выглядеть умнее, чем ты есть на самом деле? Если ты так думаешь, то ты выглядешь тупее, чем есть на самом деле.
>> Если у тебя есть три аргумента, каждый из которых является дочерним
>> от класса A, и таких дочерних классов у A три штуки
>> -- B, C, D, то тебе придётся писать 3^3 реализаций методов
>> -- (B, B, B), (B, B, C) (C, D, B), (C,
>> C, D), и так далее. 27 долбаных функций. Если ты добавишь
>> к A ещё один дочерний класс, то количество методов скакнёт до
>> 64.
> Намёк не понят. Хочешь наследование - положи структуру в структуру.
Если у тебя есть метод класса, то его реализация определяется конкретным типом этого класса: родительский, дочерний, внучатый, каждый из них будет иметь собственную реализацию. Если у тебя метод двух классов, то его реализация определяется комбинацией конкретных типов двух классов. Количество этих комбинаций считается как произведение количества разных типов, которые могут быть на месте первого класса, на количество разных типов, которые могут быть на месте второго класса. Каким образом при этом ты реализуешь наследование -- вкладываешь структуру в структуру, или оставляешь эти вложения компилятору, ничего существенно не меняют.
Если ты не понимаешь о чём я, то возьми CLOS и повтыкай туда, в Common Lisp он такой -- там всё можно. В том числе и методы двух, трёх, да хоть десяти классов.
Если тебе просто абстрактные рассуждения слишком сложны, я могу тебе дать задачку на подумать.
Объявим абстрактный класс Figure, который будет представлять собой геометрическую фигуру. Объявим грядку конкретных классов -- Point, Line, LineSegment, Circle, Arc, BezierCurve, Polygon, Spline ... ну и вообще все которые нам нужны.
А теперь объявим generic метод от двух аргументов:
double distance(Figure &f1, Figure &f2);
Идея этой функции в том, что она является методом двух классов, она выбирает конкретную реализацию на основании типов f1 и f2. Она будет позволять нам взяв две произвольных фигуры найти расстояние между ними одним вызовом.
Если всё ещё не понятно, о чём я, то возьми ассемблер, C, bash, или любой другой язык, который тебе по душе, и попробуй реализовать такую функцию. В процессе написания кода ты быстро поймёшь, о чём я вещаю. Кстати тут вариант ещё щадящий, потому что функция коммутативна, и тебе придётся писать не N^2 конкретных реализаций метода distance, а N*(N-1)/2.

Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

109. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 08-Июл-17, 19:57

> Кстати тут вариант ещё щадящий, потому что функция
> коммутативна, и тебе придётся писать не N^2 конкретных реализаций метода distance,
> а N*(N-1)/2.
Ага. Потому, что формулы разные. По крайней мере для евклидовой метрики.

Ответить | Правка | Наверх | Cообщить модератору

132. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +1 +/–

Сообщение от pripolz (?), 09-Июл-17, 04:53

> Если всё ещё не понятно, о чём я, то возьми ассемблер, C,
> bash, или любой другой язык, который тебе по душе, и попробуй
> реализовать такую функцию. В процессе написания кода ты быстро поймёшь, о
> чём я вещаю. Кстати тут вариант ещё щадящий, потому что функция
> коммутативна, и тебе придётся писать не N^2 конкретных реализаций метода distance,
> а N*(N-1)/2.
Именно так, совершенно непонятно. При чём тут принудительная связь между данными и методами, которые применимы к этим данным?
Я указал на то, что если будет метод "расстояние между точкой и прямой" - то его по канонам С++ нужно будет обязательно выполнить либо в классе "прямая", либо в классе "точка", либо в классе "фигура". Что приведёт к ОГРАНИЧЕНИЯМ на уровне языка. Эти ограничения будут касаться ABI, и приведут к появлению всякого лишнего кода. Возможно придётся использовать такую "возможность", как friend class, короче думать о реализации.
Твой пример с generic расстоянием между фигурами мне ни о чём не сказал. Ну допустим будет много реализаций. Что это меняет? Если тебе предложат написать такую программу, ты что, откажешься? Не функцию, а программу. Расстояние между фигурами. Фигур 10 типов. Это задача для неудачников по твоему?

Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

134. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 09-Июл-17, 05:55

> Я указал на то, что если будет метод "расстояние между точкой и прямой" - то его по канонам С++ нужно будет обязательно выполнить либо в классе "прямая", либо в классе "точка", либо в классе "фигура".
В C++ это можно сделать разными методами и использовать ООП совершенно не обязательно. В частности, в данном случае лучше всего использовать шаблоны.
template <class A, class B> double distance( const A &, const B &)
И инстанциировать это хозяйство для разных пар, поскольку формулы для разных пар действительно разные.

Ответить | Правка | Наверх | Cообщить модератору

137. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от pripolz (?), 09-Июл-17, 11:11

> В C++ это можно сделать разными методами и использовать ООП совершенно не
> обязательно. В частности, в данном случае лучше всего использовать шаблоны.
> template <class A, class B> double distance( const A &, const B
> &)
> И инстанциировать это хозяйство для разных пар, поскольку формулы для разных пар
> действительно разные.
а в рантайме такой темплейт подхватит заранее неизвестный тип фигуры?

Ответить | Правка | Наверх | Cообщить модератору

142. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 09-Июл-17, 16:39

> а в рантайме такой темплейт подхватит заранее неизвестный тип фигуры?
Нет, конечно. Но основная проблема тут не в языке, а в предметной области - у вас нет единой формулы для расчёта дистанций между фигурами разной формы.
А вот если она найдётся, то значит можно её написать с учётом каких-то встроенных свойств фигур, и сделать всё на шаблонах.
Например, если можно написать функцию расстояния от фигуры до точки, то можно написать единый алгоритм вычисления минимизацию суммы этих расстояний. И тогда он подхватит в compile-time заранее неизвестный тип фигуры, у которого будет distanceToPoint.
Но это не ООП, а generic, т.е. шаблоны, т.е. практически функциональное программирование.

Ответить | Правка | Наверх | Cообщить модератору

139. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от Ordu (ok), 09-Июл-17, 14:50

> Я указал на то, что если будет метод "расстояние между точкой и прямой" - то его по
> канонам С++ нужно будет обязательно выполнить либо в классе "прямая", либо в классе
> "точка", либо в классе "фигура".
Ты путаешь каноны ООП с канонами C++. Современный C++ не любит наследование и с подозрением относится к ООП. Rust, который писался во многом по мотивам C++, вообще не имеет наследования. C++ его таки использует, но называть принципы ООП каноничными для C++? Вы на C++ вообще пишите, или на C с классами?
> Твой пример с generic расстоянием между фигурами мне ни о чём не
> сказал. Ну допустим будет много реализаций. Что это меняет? Если тебе
> предложат написать такую программу, ты что, откажешься? Не функцию, а программу.
> Расстояние между фигурами. Фигур 10 типов. Это задача для неудачников по
> твоему?
Я тебе привёл пример ситуации, когда нужны методы для двух классов. Это единственное, что пришло мне в голову и требует метода для двух классов. Ну, точнее, не то чтобы требует, но как-то возникает желание использовать наследование для выбора нужной реализации функции, а значит круто было бы реализовать это методами классов, а не просто глобальной функцией. Всё остальное, что мне приходит в голову, либо сводится к тому, что методом класса оказывается обычная глобальная функция, с красивым *this указателем промежь аргументов, либо там вполне достаточно наследования от одного класса, либо ещё что-нибудь.
> Если тебе предложат написать такую программу, ты что, откажешься? Не функцию, а программу.
> Расстояние между фигурами. Фигур 10 типов. Это задача для неудачников по
> твоему?
Да. В такой постановке (надо именно этих десять фигур, и именно законченной программой) задача может возникнуть только как задача для студенческой курсовой. Если ты зарабатываешь денег написанием курсовых для студентов, то как программист ты неудачник.
В реальных задачах всегда есть tradeoffs между функциональностью кода, сложностью его, производительностью, потреблением памяти и рядом других параметров. Здесь же, совершенно определённо видна безумная квадратичная зависимость количества реализаций методов от количества примитивов, а это значит, что надо очень и очень аккуратно обходиться с подбором этих примитивов. Потому что если нам когда-нибудь вдруг понадобится ещё один, причём конкретно понадобится, станет ясно что без него никуда, а у нас к тому моменту будет уже два десятка примитивов, то нам придётся писать ещё 21 реализацию метода distance. Да, это будет ради одного и самого главного примитива, но 21 реализацию. А если при этом ещё каждая из этих реализаций окажется нетривиальной, то написание и отладка этих методов может потребовать нескольких недель.
Поэтому сама идея неудачна и имеет смысл вернуться к исходной задаче, которая породила такую идею, и переосмыслить её ещё раз, поискать какую-нибудь менее очевидную, но более реализуемую идею.

Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

143. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +1 +/–

Сообщение от Аноним (-), 09-Июл-17, 18:26

Очередная порция словесного поноса.

Ответить | Правка | Наверх | Cообщить модератору

144. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +1 +/–

Сообщение от pripolz (?), 09-Июл-17, 23:33

> Современный C++ не любит наследование и с подозрением относится к ООП.
Исключительно забавное заявление.
Во первых потому, что ООП - это шаблон проектирования. FILE * стандартной библиотеки Си - типичный ООП.
Во вторых заявление забавно потому, что получается, что С++ комьюнити начинает соглашаться с тем, что всё это время двигалось не в ту сторону. Вчера они объясняли тебе, ПОЧЕМУ наследование - это хорошо, а сегодня.. они вернулись обратно. Программирование стоит на месте.
Потому что у него нет причин куда-то двигаться. Был ассемблер, всё было нормально. Но есть у ассемблера недостаток - он непереносим на другой проц по определению. И появился Си. Именно поэтому.
Си сегодня выкинуть невозможно. Представь, что удалили все программы, написанные на си (пусть не считая ОС и драйверов). Что останется?
А вот Джаву например удалить можно. Вообще ничего не изменится. И С++ тоже. И Rust с его отсутствием наследования.

Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

150. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 10-Июл-17, 14:59

> Вчера они объясняли тебе, ПОЧЕМУ наследование - это хорошо
Окститесь, 20 лет прошло с тех пор.

Ответить | Правка | Наверх | Cообщить модератору

151. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +1 +/–

Сообщение от pripolz (?), 10-Июл-17, 18:24

> Окститесь, 20 лет прошло с тех пор.
То есть, современный С++ не просто не любит наследование, а ДАВНО не любит наследование?
Ещё более забавно.
Вы не говорите, что "ordu преувеличил, С++ всё ещё любит наследование".
Как же специальные костылики для решения проблемы ромба?

Ответить | Правка | Наверх | Cообщить модератору

152. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от yet another anonymous (?), 10-Июл-17, 20:06

> То есть, современный С++ не просто не любит наследование, а ДАВНО не любит наследование?
Ещё более забавно.
См.:
Elements of Programming by A. Stepanov.

Ответить | Правка | Наверх | Cообщить модератору

153. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 11-Июл-17, 03:05

> а ДАВНО не любит наследование?
Хуже - ОЧЕНЬ ДАВНО не любит наследование. Если бы не Степанов с STL, а дальше Александреску с метапрогразмом, этот С++ давно бы выкинули на помойку. Ибо наследование, виртуальные функции и т.д. лучше реализовано в Яве, в С#, Delphi, ну и других языках.
У С++ ниша языка с относительно мелким рантаймом и возможностью очень глубокой оптимизации. Классы же с виртуальными функциями, наследованием, указателями и т.д. сильно тормозят. А шаблоны, несмотря на ряд косяков (синтаксис, отсутствие раздельной компиляции), позволяют делать с одной стороны достаточно высокуровневый, а с другой стороны, оптимизированный код.
Есть даже места, где RTTI вообще нафиг отключают, а значит выключают и "объектно-ориентированное-программирование на С++".

Ответить | Правка | Наверх | Cообщить модератору

154. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от pripolz (?), 11-Июл-17, 12:14

А шаблоны, несмотря на ряд косяков (синтаксис, отсутствие раздельной компиляции),
> позволяют делать с одной стороны достаточно высокуровневый, а с другой стороны,
> оптимизированный код.
Должен признать, С++ (но только на самом новом GCC) может кое-что, чего не может Си:
заполнять секцию данных (имеется ввиду большой и сложный массив) из кода с помощью constexpr и пары шаблонов. Из-за этого в коде Си можно встретить огромные заранее посчитанные массивы. Иногда они генерируются каким-нибудь скриптом на этапе сборки. Но всё же, было бы неплохо делать это компилятором. В случае С++, замечу, тоже не так уж удобно, и (на сегодняшний день) мало чем можно такое собрать.
Вот простейший пример кода:
http://coliru.stacked-crooked.com/a/944b535a8131ab77
(секцию данных можно проверить, указан компиляции -O3 -S main.s && cat main.s)
Обсуждение вопроса было здесь:
https://toster.ru/answer?answer_id=949231

Что касается простых шаблонных функций, на Си они легко делаются так:
- создал файл func.h, и записал туда
FUNC_DECL
{
// common code...
TYPE tralala;
#ifdef F_CASE1
// unique code
#endif
#ifdef F_CASE2
// unique code
#endif
// common code...
}
#undef F_CASE1
#undef F_CASE2
#undef FUNC_NAME
потом, там, где нужно нагенерить функций, просто инклудишь файл несколько раз:
#define FUNC_NAME int abc(int * a, int * b)
#define F_CASE1 1
#include func.h
#define FUNC_NAME int abc2(int * a, int * b)
#define F_CASE2 1
#include func.h
По такому шаблону можно ходить в отладчиках, как VS, так и gdb.
Кто-то скажет "фу, препроцессор", а на мой взгляд здесь всё гораздо лучше чем в темплейтах:
- потому что процесс генерации прозрачен и понятен.
- тут не нужно вспоминать тонкости синтаксиса, минимальное кол-во боли при ревизии.
- самое важное: гибкость. Можно нагенерить любую идею. В темплейтах не так. Можно абстрагироваться от типов, но если функции должны отличаться уникальными кусками кода (как в этом примере), что, замечу, ТРИВИАЛЬНЫЙ СЛУЧАЙ, тогда в С++ требуется создавать вспомогательные шаблонные классы.
- соберётся любой версией компилятора на любом железе.
Короче, препроцессор - это свобода.

Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

155. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 11-Июл-17, 12:21

> - потому что процесс генерации прозрачен и понятен.
Во-первых, нет. Он понятен только до определённого момента - пара ступеней вложенности, после чего это всё превращается в лапшу.
> - тут не нужно вспоминать тонкости синтаксиса, минимальное кол-во боли при ревизии.
В С++ тонкости синтаксиса - это STL с её идиотскими back_inserter и прочей фигнёй. Шаблоны, всё-таки, очень даже обозримы.
> - самое важное: гибкость. Можно нагенерить любую идею.
Если потребовалось что-то серьёзное, берём любой лёгкий высокоуровневый язык, и генерируем себе спокойно нормальный Cшный или C++ный код значительно лучше, чем на языке препроцессора или шаблонов.
> Короче, препроцессор - это свобода.
Свободы в Питоне хоть попой ешь, в результате приходится тестировать всё, что может сломаться и даже не может сломаться.

Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

156. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от pripolz (?), 11-Июл-17, 13:30

> пара ступеней вложенности
Ни разу в жизни не сталкивался. Вообще шаблоны - большая редкость. Применение шаблонов ИМХО обосновано только из соображений производительности. Тогда, когда нельзя использовать указатель на функцию потому, что это запорет оптимизацию в сильно вложенном цикле.
Так или иначе, у меня лично есть большие сомнения, превратится ли при таком подходе код в кашу. Ну будет иерархия из нескольких файлов, что такого.

Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

157. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от anonymous (??), 11-Июл-17, 14:01

>> пара ступеней вложенности
> Ни разу в жизни не сталкивался. Вообще шаблоны - большая редкость.
В каком чудном мире вы живете?
PS. Это же вы где-то в этой теме сказали, что программировали на 100 языках? Можно список из ТОП-30 хотя бы?

Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

158. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от pripolz (?), 11-Июл-17, 14:25

> PS. Это же вы где-то в этой теме сказали, что программировали на
> 100 языках? Можно список из ТОП-30 хотя бы?
Было преувеличение. Если по порядку, то
Dark Basic,
Visual Basic 98 (VB6),
Free Basic,
Matlab,
CMD/BAT,
VBScript,
Bash,
Python,
fasm,
Java (совсем-совсем немного),
Emacs Lisp.
Всё кроме BAT/CMD по мелочам.
В профессиональном С/С++ 2 года.
Вот и раскрыта таенка))

Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

161. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 12-Июл-17, 02:25

Ну почти всё закрыто. Не хватает JavaScript'а, языков семейства ML и Пролога.

Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

163. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от anonymous yet another (?), 12-Июл-17, 08:29

> Было преувеличение. Если по порядку, то
Дневник молодого поэта: "Всю ночь писал стихи о любви. Закрыл тему."

Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

160. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от anonymous yet another (?), 11-Июл-17, 23:06

> ... а дальше Александреску
А вот это уже мешки синтаксического сахара. Так и до диабета недалеко.

Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

149. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от Анонимный Алкоголик (??), 10-Июл-17, 11:48

> Если тебе предложат написать такую программу, ты что, откажешься? Не функцию, а программу.
> Расстояние между фигурами. Фигур 10 типов. Это задача для неудачников по
> твоему?
Вы не поняли. Речь была о том, что в языке вам не хватает средства выразить некий метод (функцию) для трёх классов хотя бы. Один при чём. Метод. Предлагать нам за вас разработать и представить к рассмотрению такого рода метод не стоит...

Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

118. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Vkni (ok), 08-Июл-17, 22:28

> Вот класс - это изначально структура данных + набор методов с ней.
> В с++ структура и методы принудительно жёстко связаны. А если я
> захочу написать один метод для 3х классов?
Haskell, классы типов и т.д.
instance Show Double where
    show d = ...
Проблема в том, что даже с ними хочется большей гибкости. Например, определить два разных вариантов печати числа.

Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

147. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." –1 +/–

Сообщение от Анонимный Алкоголик (??), 10-Июл-17, 11:12

> А если я захочу написать один метод для 3х классов?
:-) Когда захотите, изложите как полагается. Выдающееся может получиться желание.
Потому что пока это выглядит довольно бессмысленно. "один метод для 3х классов". Поэтому вряд ли вы сможете таки захотеть...

Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

146. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..." +/–

Сообщение от Анонимный Алкоголик (??), 10-Июл-17, 10:39

>Вон из профессии, ничтожество.
Совершенно верно. Вон. Наплодилось вас, проталкивателей "стилей"...
Норовящих пояснить о плохой практике массивов... :-)

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	28. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Ordu (ok), 07-Июл-17, 15:46
	Нет, это не он загнул. Просто кто-то отстал от развития практик применения C++ лет на десять. Как минимум лет на десять: в принципе boost с друзьями лет пятнадцать-двадцать уже как проталкивает современный стиль в C++. Как при этом можно писать на C++, считать себя квалифицированным профессионалом, и не понимать того, как и зачем C++ пришёл к современному стилю, и отказываться от него под предлогами вида "мне синтаксис не нравится"? Мне непонятно, как всё это может непротиворечиво жить в одной голове. Когда десять лет назад я сталкивался со старыми пердунами, которые не принимали назначения шаблонов, и говорили что, мол, они из без шаблонов могут, это выглядело... ну, естественно, что ли? Чё скрывать, я сам тогда предпочитал C, к темплитам относился с подозрением, и уважительно заглядывал в рот этим старым пердунам, вещающим о том, насколько красивее оказывается их код, по сравнению с кодом всяких хипстеров, которые городят темплит на темплите. Но, когда я вижу такого рода людей сегодня, вообще не знаю, что думать. Сейчас же есть литература, которая объясняет, что в C++ есть, как это следует использовать, и почему именно так, а не как-нибудь иначе. Литература, обобщающая опыт всех тех тысяч (или десятков/сотен тысяч) программистов, которые писали на C++, которые читали чужой код, которые занимались рефакторингом кода, поддержкой его, которые много думали о том как лучше писать, которые экспериментировали с C++ с момента его появления. И вот так брать и выкидывать этот опыт в окно с формулировкой "мне синтаксис не нравится"... Вон из профессии, ничтожество.
	Ответить \| Правка \| К родителю #15 \| Наверх \| Cообщить модератору


	38. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от A.Stahl (ok), 07-Июл-17, 18:02
	>boost Это отдельная тема. Специфическая тема. Не моя тема.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+4 +/–
	Сообщение от Ordu (ok), 07-Июл-17, 18:42
	>>boost > Это отдельная тема. Специфическая тема. Не моя тема. При чём здесь "моя" или "не моя"? Из наблюдений за копошением вокруг разных языков я понял одну вещь: создатели любого языка, как правило, не знают как надо писать программы на их языке. Для того, чтобы выяснить как надо, требуются годы работы многих программистов, которые попробуют _все_ возможные способы, которые приходят на ум, выяснят к чему приводят эти разные способы, и сделают выводы о том, как надо писать код и как не надо. Я видел это в haskell, и в C++. Я наблюдал за этим процессом в C, правда не в real-time, а в ретроспективе. Сейчас я наблюдаю подобное в rust -- куча мартышек, заражённых энтузиазмом, использует методы монте-карло для поиска оптимальных способов написания кода на rust. Но если говорить о C++, то он с приходом C++0x11, в общем определился с тем, в каком стиле должен писаться код на C++. boost же -- это один из примеров тех "мартышек", которые волею ли случая или благодаря недюжинному интеллекту или дару предвидения "угадали" как на C++ можно писать код, который будет и эффективным, и в то же время поддаваться поддержке, рефакторингу и расширению. И мне выглядит невероятно странным и непрофессиональным заявление вида "мало ли, что они нарыли, исследуя язык, мне неинтересно, это не моё". Моё/не моё должно иметь какой-то прагматический подтекст. Программирование может быть и искусство, но критерии красоты в этом искусстве задаются практикой, а когда они отрываются от практики, получается может быть и красиво, но гoвнo.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+2 +/–
	Сообщение от yet another anonymous (?), 07-Июл-17, 19:09
	Хмм... Что-то в вашей позиции есть интересное. По крайней мере, даже Страуструпу понадобился пинок в виде ребят из университета Ватерлоо и Степанова.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	45. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от A.Stahl (ok), 07-Июл-17, 19:58
	Пинок инженера инженеру это всегда хорошо. Хотя я и не рад смотря куда развиваются плюсы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	62. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от Аноним (-), 07-Июл-17, 22:59
	Плюсы с самого начала были не до конца продуманным костылем. Почитайте труды критиков в адрес плюсов и Страуструпа конца 80х и середины 90х. Сила критики бывает такой что иногда это даже затягивает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	85. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от pripolz (?), 08-Июл-17, 14:01
	> Плюсы с самого начала были не до конца продуманным костылем. Почитайте труды > критиков в адрес плюсов и Страуструпа конца 80х и середины 90х. > Сила критики бывает такой что иногда это даже затягивает. Можно поподробнее? Авторство, ссылочку? С удовольствием бы почитал, интересуюсь этой темой. Сам искал что-то подобное, но кроме эмоциональных экспрессий Линуса ничего не нашёл.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	94. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Аноним (-), 08-Июл-17, 17:08
	К сожалению я не могу дать вам ссылок, т.к. не нашел и не сохранил. Я это читал много лет назад когда знакомился с обероном. Не думал что со временем будет сложно найти в интернете знания, себе не скачивал.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	98. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok), 08-Июл-17, 17:43
	> Можно поподробнее? Авторство, ссылочку? С удовольствием бы почитал, интересуюсь этой темой. Unix Haters Handbook, страница 203 и далее. Но надо понимать, что сейчас ЦэПэПэ движется в несколько другую сторону - тащит всё из ML/Haskell'а, как и хотели авторы UHH.
	Ответить \| Правка \| К родителю #85 \| Наверх \| Cообщить модератору


	87. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от pripolz (?), 08-Июл-17, 14:06
	>[оверквотинг удален] > определился с тем, в каком стиле должен писаться код на C++. > boost же -- это один из примеров тех "мартышек", которые волею > ли случая или благодаря недюжинному интеллекту или дару предвидения "угадали" как > на C++ можно писать код, который будет и эффективным, и в > то же время поддаваться поддержке, рефакторингу и расширению. > И мне выглядит невероятно странным и непрофессиональным заявление вида "мало ли, что > они нарыли, исследуя язык, мне неинтересно, это не моё". Моё/не моё > должно иметь какой-то прагматический подтекст. Программирование может быть и искусство, > но критерии красоты в этом искусстве задаются практикой, а когда они > отрываются от практики, получается может быть и красиво, но гoвнo. Рекоммендую к прочтению код какого-нибудь авторитетного проекта с 10 летним возрастом. openssl например, или ffmpeg. Вы там найдёте всё: ООП, шаблоны, фабричные функции, и многое другое. Всё это на си. Огромные задачи, закрывающие целые разделы (openssl - - криптографию, ffmpeg - медиа) решены невероятно компактно, красиво и понятно. А что сделано на boost ? Я вот видел внутри Adobe Premiere его например. Продукт тормозит и глючит на каждом шагу, что мене лично не удивляет. Как и буст в нём.
	Ответить \| Правка \| К родителю #41 \| Наверх \| Cообщить модератору


	88. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Ordu (ok), 08-Июл-17, 14:29
	>[оверквотинг удален] >> на C++ можно писать код, который будет и эффективным, и в >> то же время поддаваться поддержке, рефакторингу и расширению. >> И мне выглядит невероятно странным и непрофессиональным заявление вида "мало ли, что >> они нарыли, исследуя язык, мне неинтересно, это не моё". Моё/не моё >> должно иметь какой-то прагматический подтекст. Программирование может быть и искусство, >> но критерии красоты в этом искусстве задаются практикой, а когда они >> отрываются от практики, получается может быть и красиво, но гoвнo. > Рекоммендую к прочтению код какого-нибудь авторитетного проекта с 10 летним возрастом. > openssl например, или ffmpeg. Вы там найдёте всё: ООП, шаблоны, фабричные > функции, и многое другое. Всё это на си. Да-да, я знаю. Всё можно написать на ассемблере. Но зачем? > Огромные задачи, закрывающие > целые разделы (openssl - - криптографию, ffmpeg - медиа) решены невероятно > компактно, красиво и понятно. > А что сделано на boost ? Десять секунд использования гугла и: http://www.boost.org/users/uses_open.html Там ещё есть ссылочки на не-OSS проекты, если интересно глянь туда. > Я вот видел внутри Adobe Premiere > его например. Продукт тормозит и глючит на каждом шагу, что мене > лично не удивляет. Как и буст в нём. Продукция Adobe вообще тормозит вся и глючная до безобразия, вне зависимости от того, на чём она написана.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	90. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от pripolz (?), 08-Июл-17, 14:43
	> Да-да, я знаю. Всё можно написать на ассемблере. Но зачем? Чтобы кода было меньше, а технологий больше. Вообще все любители высокоуровневых языков тыкают в ассемблер. Это от незнания реалий ассемблера. Где он применяется и зачем. > Десять секунд использования гугла и: http://www.boost.org/users/uses_open.html > Там ещё есть ссылочки на не-OSS проекты, если интересно глянь туда. сплошной ноунейм
	Ответить \| Правка \| Наверх \| Cообщить модератору


	91. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–2 +/–
	Сообщение от Ordu (ok), 08-Июл-17, 15:32
	>> Да-да, я знаю. Всё можно написать на ассемблере. Но зачем? > Чтобы кода было меньше, а технологий больше. На ассемблере будет меньше кода? Ха. Ты попробуй писать на ассемблере. Или на C будет меньше кода? Ну-ну. > Вообще все любители высокоуровневых языков > тыкают в ассемблер. Это от незнания реалий ассемблера. Где он применяется > и зачем. Ой, ну ладно. Давай я буду тыкать в C? Тебе от этого полегчает? Какая тебе разница, скажу я "всё можно написать на ассемблере", или "всё можно написать на C", или "всё можно написать в машинных кодах", или "всё можно реализовать на машине Тьюринга"? Что за манера вообще лезть со своей демагогией в разговор умных людей? Я тебе на яйца наступил упомянув ассемблер? Как я посмел своим грязным языком упомянуть ассемблер, в котором ты, судя по твоим словам, мнишь себя великими специалистом? Как я мог, да? Так вот я тебе скажу одну вещь: специалистом в ассемблере можно стать за полгода активного изучения архитектуры железа и системы команд этого процессора. Ещё полгода практики сделают из тебя окончательно сформировавшегося специалиста, которому в общем-то уже и некуда развиваться. С одной стороны это хорошо, конечно -- подготовка специалистов обходится дёшево, двух лет путяги после школы будет достаточно. С другой стороны, что этот специалист нам напишет? Килобайт прошивки для микроконтроллера? Который в случае чего проще написать заново, чем править написанный код? Какое это имеет отношение этот килобайт имеет к обсуждаемому предмету, в котором примерами софта выступает Adobe Premier? >> Десять секунд использования гугла и: http://www.boost.org/users/uses_open.html >> Там ещё есть ссылочки на не-OSS проекты, если интересно глянь туда. > сплошной ноунейм Опять демагогичный перевод стрелок. Речь идёт о гипотетической тормознутости кода, использующего boost, ты начинаешь говорить о распространённости кода, использующего boost. Разницы ты не видишь вообще или только прикидываешься идиотом?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	92. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от pripolz (?), 08-Июл-17, 16:02
	> Или на C будет меньше кода? Ну-ну. именно так. На си будет меньше кода. > Что за манера вообще лезть со своей демагогией в разговор умных людей? Ты себя-то называешь умным человеком? > Опять демагогичный перевод стрелок. Речь идёт о гипотетической тормознутости кода, использующего > boost, ты начинаешь говорить о распространённости кода, использующего boost. Речь о том, что за свои "15 лет продвижения программирования вперёд" буст ничего не добился.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	101. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok), 08-Июл-17, 17:53
	> именно так. На си будет меньше кода. Только если не использовать ООП и шаблоны там, где это не надо. Ручная эмуляция компилятора C++ аля Glib2 и прочие извращения код только раздувают.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	103. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+2 +/–
	Сообщение от pripolz (?), 08-Июл-17, 18:38
	1) Фишки Glib не пересекаются с фишками компилятора С++ вообще начнём с этого. У компилятора С++ что, есть сигналы? А может сообщения? Так же, обращаю внимание на то, что наследование в Glib - не то же самое, что наследование в C++, это динамическое наследование объектов, типа как в JavaScript. API проектов на Glib, таких как GTK+ и GStreamer сложен потому, что ставит перед собой сложную задачу - понаделать биндингов для языков с динамическим ООП типа питона. 2) Лишний код С++ достигается из-за архитектурных проблем языка, которые напрямую приводят к костылям из-за своих необоснованных ограничений. Вот например метапрограммирование. Это по сути - "сгенерировать много функций с повторяющимися кусками кода из одной". В си достигается использованием препроцессора (лучше всего на include + ifdef, т.к. по такому коду можно ходить в старых версиях отладчика, но можно и чистыми дефайнами, если куски небольшие). В С++ метапрограммирование привязали к системе типов, что есть необоснованная ошибка архитектуры языка. Это приводит к тому, что приходится создавать шаблонные классы и перегружать у них функции просто для того, чтобы сгенерить пару функций, внутри которых часть кода будет принципиально отличаться. В итоге, шаблонный класс - это и есть тот самый лишний код. Я много работаю с авторитетными С++ проектами и вижу одно и то же: огромные каскады из классов, которые ещё и вынесены в отдельные файлы, и эти классы не несут в себе никакой логики и функции вообще, их назначение - обойти ограничения, которые лежат в основе С++.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	111. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok), 08-Июл-17, 20:07
	> 1) Фишки Glib не пересекаются с фишками компилятора С++ вообще начнём с > этого. У компилятора С++ что, есть сигналы? А может сообщения? Тем не менее, их эмуляции классов можно было бы сделать на С++ проще. Вместо префиксов уж точно можно было использовать пространства имён. Без фанатизма, короче. С другой стороны, С++ ный ABI не определён. > и эти классы не несут в себе никакой логики и > функции вообще, их назначение - обойти ограничения, которые лежат в основе > С++. Не совсем, цель - обойти ограничения ООП. Аналогичная фигня с паттернами в Java. Ну и навороты на шаблонах тоже никто делать не заставляет. Хотя, временами, ловлю себя на том, что пишу двух-трёхстрочный макрос вместо шаблонной функции. Кроме того, очень многое зависит от культуры программиста. Культура текущих С++ных программистов - это делать излишние переусложнения на ровном месте. Например, не использовать printf, хотя он уже во всей большой тройке современных компиляторов полностью typechecked, а по интерфейсу значительно удобнее потоков.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	116. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от Аноним (-), 08-Июл-17, 22:24
	> Только если не использовать ООП и шаблоны там, где это не надо. Практика показывает что ненадо чуть менее чем везде.
	Ответить \| Правка \| К родителю #101 \| Наверх \| Cообщить модератору


	107. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Ordu (ok), 08-Июл-17, 19:49
	>> Опять демагогичный перевод стрелок. Речь идёт о гипотетической тормознутости кода, использующего >> boost, ты начинаешь говорить о распространённости кода, использующего boost. > Речь о том, что за свои "15 лет продвижения программирования вперёд" буст > ничего не добился. Ты специально учился где-то демагогии или самоучкой? Очень похоже на второе: специально обученные делают это не столь очевидно.
	Ответить \| Правка \| К родителю #92 \| Наверх \| Cообщить модератору


	102. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok), 08-Июл-17, 17:55
	> Рекоммендую к прочтению код какого-нибудь авторитетного проекта с 10 летним возрастом. > openssl например, или ffmpeg. Вы там найдёте всё: ООП, шаблоны, фабричные > функции, и многое другое. Если держать себя в руках, то на ООП на С++ получится лучше, т.к. не надо вручную возиться с vptr/vtable. Другое дело, что от обилия возможностей у многих в руках начинает свербить.
	Ответить \| Правка \| К родителю #87 \| Наверх \| Cообщить модератору


	104. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от pripolz (?), 08-Июл-17, 19:21
	> Если держать себя в руках, то на ООП на С++ получится лучше, > т.к. не надо вручную возиться с vptr/vtable. Другое дело, что от > обилия возможностей у многих в руках начинает свербить. 1) то, что ты называешь возможностями я называю ограничениями. 2) Пример очень печального ограничения, вводимого ПРИНУДИТЕЛЬНЫМ НАЛИЧИЕМ vptr/vtable - это невозможность в некоторых случаях сохранить совместимость разных версий API/ABI после расширения. Этот вопрос у С++ников как правило вообще не поднимается, потому, что чтобы достугнуть хоть какой-то совместимости API между версиями нужно уже обратиться к Си: вынести конструктор класса в отдельную сишную функцию, а сам класс описать как набор виртуальных ф-ий. Под совместимостью АПИ я подразумеваю, что можно подложить либу новой версии к старой версии программы, после добавления новых функций. т.е. кошерный API на си - это: typedef struct obj_s obj; obj * new_obj(void); // construct void delete_obj(obj); // destruct int method1(obj, int); void method2(obj); При таком оформлении АПИ можно добавить новый метод с сохранением работы новой либы на старой версии программы (которая была скомпилена ещё со старым .h и стоит где-то на объекте. Скажем, на газовой станции.). На С++ приходится исхищряться: extern "C" { obj new_obj(void); void delete_obj(obj*); } class obj { virtual method1(int) = 0; virtual method2() = 0; }; Как видишь, уже начинается костылизация. Но основная печаль не в этом. Если от класса obj что-то унаследуется в API (в сишном случае можно просто применить уже имеющиеся методы к наследуемому классу), то ничего ты уже в obj не добавишь. Поэтому самые крутые С++сники просто забивают на совместимость версий, и хреначат описание всего класса прямо в хедер. Техподдержка от этого страдает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	112. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok), 08-Июл-17, 20:09
	> - это невозможность в некоторых случаях сохранить совместимость разных версий API/ABI > после расширения. Этот вопрос у С++ников как правило вообще не поднимается, Вот конкретно здесь мы его неоднократно поднимали с CrazyАлексом, arisu и д.р. Ситуация даже хуже, чем вы излагаете. Если я беру один и тот же проект с плагинами, компилирую их разными версиями gcc/clang и т.д. бинарная совместимость не гарантирована. Даже с учёто того, что исходник абсолютно один и тот же. Но, возможно, это действительно ситуация разряда "сгорел сарай, гори и хата" - с С++ной реализацией наследования и обратной бинарной совместимостью действительно полный Пэ.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	39. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от _ (??), 07-Июл-17, 18:16
	Опыи фортрана, лиспа, кобола и кучи других - выкинули? Ну в таком ключе С++ тоже выкинут. И кстати, то как ты это описал - это не профессия, это - религия.
	Ответить \| Правка \| К родителю #28 \| Наверх \| Cообщить модератору


	42. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от Ordu (ok), 07-Июл-17, 18:54
	> Опыи фортрана, лиспа, кобола и кучи других - выкинули? > Ну в таком ключе С++ тоже выкинут. Я не совсем понял к чему это. Но опыт фортрана, лиспа, кобола и кучи других неприменим непосредственно в C++. Этот опыт надо переосмыслить, надо попробовать его привнести в C++ и так, и эдак, надо почистить этот опыт от того, что не нужно в C++. А после этого опыт фортрана, лиспа, кобола и кучи других станет опытом C++. И да, C++ тоже выкинут со временем. Но не в обозримом будущем. > И кстати, то как ты это описал - это не профессия, это > - религия. Что именно? Я описал два разных взгляда на ситуацию, какой из них для тебя выглядит религией? Вера старых пердунов в то, что те практики, которые они применяли десятилетиями всегда будут лучше любых новых? Или вера в то, что программирование развивается и как искусство, и как ремесло, и как профессия, что развитие это неизбежно, а борьба с ним бесполезна и контрпродуктивна?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от yet another anonymous (?), 07-Июл-17, 19:13
	> ... Но опыт фортрана, лиспа, кобола > и кучи других неприменим непосредственно в C++. Этот опыт надо переосмыслить, > надо попробовать его привнести в C++ и так, и эдак, надо > почистить этот опыт от того, что не нужно в C++. А > после этого опыт фортрана, лиспа, кобола и кучи других станет опытом > C++. Да, Степанов свои идеи сначала на Lisp'е реализовывал. C++ как мультипарадигменный язык подошёл лучше.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Аноним (-), 07-Июл-17, 20:22
	> Литература, обобщающая опыт всех тех тысяч (или десятков/сотен > тысяч) программистов, которые писали на C++, Можно пару-тройку ссылок на литературу (хотя хватит и имен/названий, отсутсвие перевода не помеха) "как писать на современных плюсах"? А то ведь графоманов-любителей много, без опыта нарвешься на какой нибудь "шыдевр", от которого у тех, кто в теме, волосы на *опе дыбом становятся.
	Ответить \| Правка \| К родителю #28 \| Наверх \| Cообщить модератору


	50. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от Crazy Alex (ok), 07-Июл-17, 21:31
	Из того, что я видел - лучше всего именно гайд под редакцией Страуструпа/Саттера на https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC.... В C++ Faq также есть и рекомендуемые книги причём разные варианты с учётом бэкграунда. Ну и Мейерс, "Effective Modern C++".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	55. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Аноним (-), 07-Июл-17, 22:00
	Благодарю. Будем посмотреть.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Ordu (ok), 07-Июл-17, 22:09
	> Можно пару-тройку ссылок на литературу (хотя хватит и имен/названий, отсутсвие перевода > не помеха) "как писать на современных плюсах"? > А то ведь графоманов-любителей много, без опыта нарвешься на какой нибудь "шыдевр", > от которого у тех, кто в теме, волосы на *опе дыбом > становятся. Мейерс. http://shop.oreilly.com/product/0636920033707.do
	Ответить \| Правка \| К родителю #47 \| Наверх \| Cообщить модератору


	65. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Аноним (-), 07-Июл-17, 23:19
	Очень рекомендую к просмотру, т.к. без нормальной критики вы не поймете язык полностью: https://flyx.org/2014/04/24/cpp_sucks/
	Ответить \| Правка \| К родителю #47 \| Наверх \| Cообщить модератору