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]

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

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

Многие профессионалы сталкиваются с ситуацией, когда они сами пишут и проектируют.
Соответственно они это делают как им удобно.
Вот, например, я -- терпеть не могу шаблоны. STL использую, но сам не пишу. Это такой мой "бзик". Также я не уловил прелесть смартпоинтеров. У меня и с обычными указателями никаких проблем нет. Нахрена мне умные?
А вот теперь представь, что я  -- тимлимд (а я на плюсах ~10 лет пишу, так что опыт имеется и на такую должность вполне могу упасть). И как себя будет чувствовать молодёжь, которая ни асма ни Си не нюхала? Я со своими требованиями буду для них "придурок, усложняющий код, когда можно написать auto". И они будут правы. И я буду прав. Вот так.
Это разница в поколениях и мировоззрениях. Классическая проблема отцов-сыновей.

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

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

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

А exception safety, move semantics, вот это всё - тоже игноришь? Их без умных указателей не особо реализуешь... То есть можно конечно, но возни же куча.

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

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

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

Исключения не люблю, а вот move semantics почти не нужно если у тебя всё хорошо с обычными указателями. Если писать в Ява-стиле, то да -- эта штука реально спасает. Сишнику это не очень критично. У сишника не часто бывают нюансы когда ты "передаёшь эстафету" и умираешь:) Да и сишник всегда может передать указатель и забыть/забить.
Но да, иногда эта штука крута и прикольна. Но ничего такого.

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

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

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

Создать объект и отдать его контейнеру - это редкая операция? А если нет - то либо умные указатели, либо move semantics, либо с ровного места теряем в производительности на копированиях объектов.

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

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

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

Я обычно передаю указатель. Редко бывает, когда объект нужен много кому и непонятно кто должен его удалять.

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

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

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

А у меня - как-то через раз. Лежит себе вектор указателей на объекты, чему-то один из них понадобился - оно его получило. Сохранило где-то или нет - с умными указателями мне не интересно, как и то, как соотносятся сроки жизней контейнера и клиента. Для стаистики, например - самое оно. Посчитал, сложил, дал интерфейс, забыл.

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

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

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

Код является простым когда простой инспекцией удается выловить границы жизни объекта без того чтобы тратить время на анализ исполнения. Как раз с умными, автоматическими, неявными операциями и указателями код не становится простым и понятным, получается такая "вещь в себе". Так что лучше явно.

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

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

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

Красиво казал. Меня там минусуют, но они не совсем понимают суть. Я не против новых "фишек", просто некоторые нюансы мне не нравятся. Не более того.
Я просто стараюсь оставлять код очевидным. Очевидным даже для сишников (я и сам такой), а не только для плюсовиков, которые следят за последними стандартами.
Я не против. И никогда не использовал положение чтобы что-то запрещать. Просто некоторые вещи я не использую (даже не не использую, а избегаю использовать). Не более того.

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

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

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

Фишка в том, что "очевидный для сишников" и "очевидный для плюсовиков" - вещи разные, и чем больше масса кода, тем больше  в них противоречие.
Подход сишника - "каждый конкретный кусок должен быть ясен вплоть до примерного набора инструкций процессора". Подход плюсовика - "каждый конкретный кусок должен быть ясен в терминах алгоритмики и тех понятий, в которых мы пишем, а ниже лезем только при явной необходимости -  и желательно один раз, добавляя новое понятие". То самое implementation hiding, loose coupling и подобное. Идеальный пример здесь - шаблоны (в которых мы реализуем что-то очень общее) и при нужде - их специализации (где лезем в детали).

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

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

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

>  Фишка в том, что "очевидный для сишников" и "очевидный для плюсовиков" - вещи разные, и чем больше масса кода, тем больше  в них противоречие.
Это лишь ваше представление которое основано, к сожалению, на незнании или малоопытности программирования на Си.
> Подход сишника - "каждый конкретный кусок должен быть ясен вплоть до примерного набора инструкций процессора". Подход плюсовика - "каждый конкретный кусок должен быть ясен в терминах алгоритмики и тех понятий, в которых мы пишем, а ниже лезем только при явной необходимости -  и желательно один раз, добавляя новое понятие". То самое implementation hiding, loose coupling и подобное. Идеальный пример здесь - шаблоны (в которых мы реализуем что-то очень общее) и при нужде - их специализации (где лезем в детали).
Вообще не то. Подход сишника: узнаем как должно работать и реализуем сразу. Подход плюсовика: узнаем как должно работать и соображаем как составить код с "правильным" ООП, шаблонами и прочим трешем.
Разговоры о том что ООП - sucks идут уже давно, и первыми об этом заговорили эксперты программирования которые уперлись в проблемы ООП. Вот и я уперся в свое время и больше я ООП не трогаю если только не приходится.

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

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

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

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

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

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

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

Очень забавно потому что вот это - "вменяемый разработчик вообще на любом языке будет думать не просто "как должно работать", а как обеспечить минимум багов, как упростить поддержку, как дать разумные возможности расширения, как реализовать обработку ошибок, как учесть многопоточныость и прочее" это как бы само-собой разумеющееся, и у опытных решение было уже принято где-то в момент "узнаем как должно работать". Поэтому реализуем сразу.
А то что вы пишете "Подход "узнаем как должно работать и реализуем сразу" (велосипед, как правило) - это студенческая наивность" - это выдало в вас новичка.
> Так вот сюрприз - всякое "правильное" ООП, шаблоны (которые паттерны) и подобное - как раз об этом. Чтобы сделать заведомо известными, проверенными способами. Которые не только сами по себе хороши, но и другие люди их сразу поймут и будут знать, что с этим кодом делать и чего ждать.
Согласен что design patterns на словах выглядит изумительно, но я этим переболел. Но на практике от них часто много разных проблем. Поэтому я не сторонник "размазывать" управляющую логику в паттерны, а формулирую их в юниты. Но
> Ну а "вот и я уперся в свое время и больше я ООП не трогаю если только не приходится" это вообще мило. Может, у вас просто мозгов не хватило? Судя по первой части - вполне может быть.
Судя по вашим ответам - вы тот еще нуб.

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

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

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

> Подход сишника - "каждый конкретный кусок должен быть ясен вплоть до примерного набора инструкций процессора". Подход плюсовика - "каждый конкретный кусок должен быть ясен в терминах алгоритмики и тех понятий, в которых мы пишем, а ниже лезем только при явной необходимости -  и желательно один раз, добавляя новое понятие".
броо! +!!!
А вообще я редкостный хейтер всего кроме Си (хотя писал на 100 языках), потому, что вот эта философия новой школы "я приложу старания, для того, чтобы НЕ ЗНАТЬ, как это работает внутри" это ... сами понимаете. Не просто палка в колесо, а супер заумная палка, героически внедряемая под покровом ночи.

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

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

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

> А вообще я редкостный хейтер всего кроме Си (хотя писал на 100
> языках), потому, что вот эта философия новой школы "я приложу старания,
> для того, чтобы НЕ ЗНАТЬ, как это работает внутри" это ...
> сами понимаете. Не просто палка в колесо, а супер заумная палка,
> героически внедряемая под покровом ночи.
А вы и так не знаете, не переживайте. Даже пишущий на ассемблере не знает, как оно будет выполняться на современном процессоре унутре. Даже в каком порядке.
Более того, язык Цэ разработан для однопроцессорной машины типа PDP, как известно. Соответственно, на других машинах, типа Itanium/Эльбрус или видеокарты или многопроцессорные Sparc/Power, он работает несколько неоптимально.

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

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

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

> А вы и так не знаете, не переживайте. Даже пишущий на ассемблере не знает, как оно будет выполняться на современном процессоре унутре. Даже в каком порядке.
Это и не нужно, во-первых. Во-вторых речь не о машинном исполнении была.
> Более того, язык Цэ разработан для однопроцессорной машины типа PDP, как известно. Соответственно, на других машинах, типа Itanium/Эльбрус или видеокарты или многопроцессорные Sparc/Power, он работает несколько неоптимально.
Ложное утверждение. Как будет работать на процессорах зависит от того как напишешь, что напишешь и во что это будет оттранслировано в конечном счете. Кстати, в отличии от С++, на Си можно формировать нужные для компилятора единицы трансляции которые нельзя и нельзя будет сформулировать в рамках новомодных и "правильных" догм С++. Надеюсь вы сами догадаетесь почему оно так.

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

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

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

> Это и не нужно, во-первых. Во-вторых речь не о машинном исполнении была.
Ну да, на каком-то уровне приходится останавливаться. Ну можно остановиться на ассемблере, можно выше, можно ещё выше. В зависимости от задачи оптимальность той точности, с которой разработчик понимает, что будет происходить, разная.
> Ложное утверждение. Как будет работать на процессорах зависит от того как напишешь,
> что напишешь и во что это будет оттранслировано в конечном счете.
Да. Только есть языки более приспособленные, есть менее приспособленные для определённой задачи. И слабая приспособленность С к многопроцессорным машинам приводит к тому, что приходится обвешиваться pthread'ами и соблюдать чудеса внимательности, растрачивая своё время и силы.
А в более приспособленных к параллельным вычислениям языках можно это делать значительно легче. Например, один из самых приспособленных языков к ним - это make. Чтобы распараллелить задачу на нём требуется задать один ключ -j.
Понятно, что у make слишком слабый контроль за параллелизацией вычислений для системного языка, но ясно, что, тем не менее, у такого языка параллелизация может быть сделана лучше, чем у теперешнего С.

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

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

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

> Ну да, на каком-то уровне приходится останавливаться. Ну можно остановиться на ассемблере, можно выше, можно ещё выше. В зависимости от задачи оптимальность той точности, с которой разработчик понимает, что будет происходить, разная.
Зачем вообще вы снова асм тянете, я не пойму. Вот люди пишут на java и не парятся что их байткод весь внутри в goto. Или вы из тех кто совсем не умеет в си прикладные задачи алгоримтического плана?

> Да. Только есть языки более приспособленные, есть менее приспособленные для определённой задачи. И слабая приспособленность С к многопроцессорным машинам приводит к тому, что приходится обвешиваться pthread'ами и соблюдать чудеса внимательности, растрачивая своё время и силы.
> А в более приспособленных к параллельным вычислениям языках можно это делать значительно легче. Например, один из самых приспособленных языков к ним - это make. Чтобы распараллелить задачу на нём требуется задать один ключ -j.
> Понятно, что у make слишком слабый контроль за параллелизацией вычислений для системного языка, но ясно, что, тем не менее, у такого языка параллелизация может быть сделана лучше, чем у теперешнего С.
Если продолжить вашу мысль то можно еще проще сделать - запускать N-процессов и вообще нет проблем. Даже -j не нужен.

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

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

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

> Зачем вообще вы снова асм тянете, я не пойму.
Ветка такая. См. несколько комментов выше.

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

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

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

В 12.54 Crazy Alex написал свое ОГРАНИЧЕННОЕ (!) понимание программирования в Си на что мне пришлось дать в 12.60 ему ортогональный ответ.
Вижу вы согласились с предложенным в 12.54 толкованием, но если если вы следили за веткой 12.54 -> 12.60, то должны были понять что ситуация осталась спорной.
Получается что вы все время апеллируете к асму только из-за ограниченного понимания Си прользователем Crazy Alex ? Ничего не смущает?

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

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

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

> Получается что вы все время апеллируете к асму только из-за ограниченного понимания
> Си прользователем Crazy Alex ? Ничего не смущает?
Я писал недавно зарегистрировавшемуся товарищу на букву p.

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

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

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

Точно, сообщение 12.80 от пользователя pripolz. Но это не меняет ситуацию с постоянным обращением к асму.

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

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

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

Я не кравиво сказал, а рассказал как оно обстоит в реальном программировании. У меня складывается ощущение что местные кто печатает здесь заумные термины, на практике их используют примерно ноль раз. Мне нравится философия Java и еще больше нравится Си, но не вычурное ботанство С++ потому что используя "фишки" С++ ты себя просто заковываешь в кандалы. Я не вижу преимущество в С++, даже банальные перегрузки операции часто вызывают семантическую неоднозначность. То есть надо лезть и разбираться. Убого и долго.

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

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

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

Умные указатели сложность, в общем, не особо прибавляют, если дать себе труд раз в жизни разобраться, как они работают. Поскольку они стандартны - только один раз и надо это сделать. И тоже будет всё просто - только на других предпосылках. Там случаев-то - раз-два и обчёлся - https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... - пяток экранов на все принципы.

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

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

Сообщение от не программист (?), 07-Июл-17, 22:23

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

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

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

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

Единственная "Ситуация, когда от них больше вреда, чем пользы" - это когда в программке пятьсот строк, десяток классов и один автор. Для всего, что сложнее "простой инспекцией выловить границы жизни объекта без того чтобы тратить время на анализ исполнения" - идея заведомо идиотская. Там уже надо думать не о вылавливании сроков жизни, а о том, чтобы гарантировать и существование, и своевременное уничтожение объектов - в том числе в чужом коде, который про ваши внутренние соглашения понятия не имеет и человеком, который впервые видит ваши интерфейсы (а в реализацию в принципе не полезет). Смарт поинтеры дают для этого стандартный, понятный любому квалифицированному плюсовику инструментарий.

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

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

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

> Единственная "Ситуация, когда от них больше вреда, чем пользы" - это когда в программке пятьсот строк, десяток классов и один автор. Для всего, что сложнее "простой инспекцией выловить границы жизни объекта без того чтобы тратить время на анализ исполнения" - идея заведомо идиотская. Там уже надо думать не о вылавливании сроков жизни, а о том, чтобы гарантировать и существование, и своевременное уничтожение объектов - в том числе в чужом коде, который про ваши внутренние соглашения понятия не имеет и человеком, который впервые видит ваши интерфейсы (а в реализацию в принципе не полезет). Смарт поинтеры дают для этого стандартный, понятный любому квалифицированному плюсовику инструментарий.
Вы вообще программировали что-нибудь серьезное? Когда вы будете думать о том как гарантировать существование и своевременное уничтожение объекта в коде, архитектура которой прорабатывается сразу несколькими людьми, то вы будете думать над сроками жизни объекта. Все ваши "смарт поинтеры и соглашения" вылетают в трубу когда вам надо перестроить контроллеры и переработать часть архитектуры.
Я вам на основе практического опыта скажу что самый лучший вариант в подобных случаях - передать управление временем жизни объекта контроллеру. Это позволяет менять архитектуру и код как угодно и во что угодно, не ограничивая себя неповоротливыми "best practices" и не расходуя время на создание ненужных контрукции только потому что в какой-то книжке кто-то написал что это "понятный любому квалифицированному плюсовику инструментарий".
Плюсы:
1) самодокументируемый код снимяющий все неясности из-зя явных операции
2) управляющий код элементарен и может подводиться под условия (оптимизация, кеширование и прочее)
3) теперь граница жизни объекта оторвана от представления програмной конструкции, то есть можно делать что угодно с архитектурой (а мы ведь любим биндинги на другие языки?) и вам не надо думать о времени жизни объекта; можете считать это декомпозицией архитектуры
Подобное делается просто на Си, С++ и любых других языках, и особенно в Java. Скорость исполнения не страдает.

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

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

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

А как же Вы обрабатываете ошибки? Я Плюсы знаю неплохо, но пишу на чистом Си. Простые задачи выношу в Питон. На обработку ошибок в Си, выставления errno и т.п. уходит иногда до половины кода (с учётом библиотеки под эти дела). Мне всегда было интересно, как у серьёзных проектов на плюсах дела с обработкой ошибок обстоят. try... намного увеличивают количество кода и уменьшают читабельность. Я уже не говорю, что я не смогу вызвать конструктор стекового объекта внутри try..., т.к. ограничу объект его областью видимости. Но в то же время программа должна корректно обрабатывать ошибки и реагировать на них. Так как Вы обходитесь без исключений то?

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

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

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

> А как же Вы обрабатываете ошибки? Я Плюсы знаю неплохо, но пишу
> на чистом Си. Простые задачи выношу в Питон. На обработку ошибок
> в Си, выставления errno и т.п. уходит иногда до половины кода
> (с учётом библиотеки под эти дела). Мне всегда было интересно, как
> у серьёзных проектов на плюсах дела с обработкой ошибок обстоят. try...
> намного увеличивают количество кода и уменьшают читабельность. Я уже не говорю,
> что я не смогу вызвать конструктор стекового объекта внутри try..., т.к.
> ограничу объект его областью видимости. Но в то же время программа
> должна корректно обрабатывать ошибки и реагировать на них. Так как Вы
> обходитесь без исключений то?
я всю обработку ошибок кладу в макрос, в котором и печать в лог номера строки кода, и вызов функции-пустышки BreakPointPit - чтобы поставить один брейкпоинт на все ошибки.
Получается универсальная проверка одной строчкой:
CHECK(statement, ERR_CODE);
Освобождение ресурсов при выходе обеспечивается goto ErrorLabel вместо простого return;
Ну я сишник, как ты понял. А плюсовики на моём опыте просто не обращают внимания. Присвоил локальной преременной new, и пошёл дальше. Выделится память или не выделится, бросит ли кто-то эксепшн дальше в функции, да пофигу. Они слишком уверенны в идеальности своих инструментов

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

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

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

Ну, у Вас по сути примерно такая же обработка ошибок, как и у нас. А про плюсовиков, - да, скорее всего такая тенденция есть с языками более высокого уровня. Потому и спрашивал про серьёзные проекты. Ведь выделение памяти в ресурсоёмких приложениях должно быть проверяемым. Я например, в случае невозможности выделить память, просто сбрасываю кэш. Будет работать медленнее, но зато будет. Правда тут тоже нюансы, - другие приложения, на которые идёт завязка могут просто скрешиться. В том же GTK нет смысла обрабатывать полноценно ошибки, т. к. сам GTK в любой момент может сделать assert на невыделенной памяти. Но это проблема частично решаемая разными способами.

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

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

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

> Освобождение ресурсов при выходе обеспечивается goto ErrorLabel вместо простого return;
Их должно быть несколько, если выделяются сразу несколько ресурсов. И не перепутать порядок. А если ресурсы выделяются/освобождаются в цикле, то так уже не получится сделать:
for( int i = 0; i < 5; i++)
{
    f = fopen(file[i],"rt");
    ...
      <глобальная ошибка>
    ...
    fclose(f);
}

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

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

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

инициализация нулями спасёт мир
for (int i = 0; i < 5; i++)
    if (f[i])
        fclose(f[i]);

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

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

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

> инициализация нулями спасёт мир
Это костыль под конкретный случай. Взять какую-нибудь другую структуру и опа.

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

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

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

> инициализация нулями спасёт мир
> for (int i = 0; i < 5; i++)
>     if (f[i])
>         fclose(f[i]);
упс, не по теме написал. Сори.

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

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

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

У нас на метки с освобождением ресурсов и восстановлением уходит до половины тела функций. В функциях инициализации их может быть и 10, и 15. А если цикл с выделением памяти, к примеру,  - то подобные куски кода выгоднее выносить в отдельные функции. По ошибке обходить цикл в обратку и всё освобождать. Тогда код основной функции будет более читабельным.

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

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

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

> exception safety, move semantics, ...  Их без умных указателей не особо реализуешь...
Бред.

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

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

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

Говорю же - можно, но морока. Придётся самому отслеживать все случаи, когда надо прибить указатель - а ради чего?
Что характерно - это ж не я придумал, можете любого плюсового гуру поглядеть - здесь разногласий нет с того самого 11-го года.

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

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

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

move не имеет к *_ptr отношения. *_ptr подразумевают move. (при достаточно полной реализации). Поэтому "для реализации move-семантики нужны умные указатели" --- набор слов, не складывающийся в осмысленную фразу.
Если фраза подразумевала
"при релизации move-семантики объекта обязательно нужны умные указатели", то тоже бред выходит: это зависит от объекта.
> А exception safety, move semantics, вот это всё - тоже игноришь? Их без умных указателей не особо реализуешь...

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

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

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

Нет. Подразумевалось "умные указатели радикально упрощают реализацию move-семантики". Если у тебя поля - обычные указатели, тебе надо для каждого выяснить, как именно он инициализируется, кто им владеет и так далее. Если умные - из типа всё очевидно и есть стандартные правила обращения с ними. Когда речь не о программках из десятка классов - это принципиально.

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

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

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

Т.е. второй вариант.
Мне нравится такой подход: неявно подразумевается вполне определённая реализация с вполне определёнными предположениями/гарантиями/etc. Все остальное объявляется несущественным/неактуальным/безнадёжно устаревшим и т.п. Так держать! Вы победитель!

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

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

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

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

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

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

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

Или ещё вариант: на этапе проектирования закладывается больше гибкости и универсальности.
Если она вся не используется, код переусложнён. Тогда говорят "Фу, оверинжениринг".
А вот если её становится недостаточно, начинается адище.

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

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

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

> И они будут правы.
Они будут правы.
> И я буду прав.
А вот вы не будете. Будете старым пердуном, который не успевает за ритмом развития инструмента, но прикрывается словами о простоте и 10 годах опыта.

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

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

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

>> И они будут правы.
> Они будут правы.
>> И я буду прав.
> А вот вы не будете. Будете старым пердуном, который не успевает за
> ритмом развития инструмента, но прикрывается словами о простоте и 10 годах
> опыта.
Почитайте книгу "Современный и эффективный С++". Там автор докажет вам, что auto - тот ещё фрукт. В конце он приходит к выводу, что инициализируя auto "хорошо бы добавить статик каст". Т.е. уже начинается борьба ради ауто.
Так что, всё как раз наоборот. Они не будут правы (просто не знают проблем), а он прав будет, потому что знает, а не не знает.

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

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

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

> В конце он приходит к выводу, что
> инициализируя auto "хорошо бы добавить статик каст".
Правда? Может вы что-то не так вычитали? А если так, то замените auto на что-то конкретное вот в таком случае, например:
auto local_fn = [&](auto & a) {...};

Ну или static_cast вставьте где-нибудь, где вам больше нравится.
А еще попробуйте обойтись без auto внутри шаблонов, что-то вроде:
template<typename A, typename B> auto f(A a, B b) {
  auto tmp = a + b;
  ...
  return tmp + 1;
}
> Так что, всё как раз наоборот. Они не будут правы (просто не
> знают проблем), а он прав будет, потому что знает, а не
> не знает.
Он как раз не знает. И не использует то, чего не знает и боится.

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

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

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

> Почитайте книгу "Современный и эффективный С++". Там автор докажет вам, что auto
> - тот ещё фрукт.
Можно ссылку?

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

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

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

>> Почитайте книгу "Современный и эффективный С++". Там автор докажет вам, что auto
>> - тот ещё фрукт.
> Можно ссылку?
Там ниже в беседе кидали на магаз О-Райли. Effective Modern C++ Майерса.

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

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

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

> Там ниже в беседе кидали на магаз О-Райли. Effective Modern C++ Майерса.
А-аа, Майерс. Просто modern C++ - это в разные времена совершенно разное.

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

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

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

Партнёры:

Хостинг:

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

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


	4. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+16 +/–
	Сообщение от A.Stahl (ok), 07-Июл-17, 12:04
	Многие профессионалы сталкиваются с ситуацией, когда они сами пишут и проектируют. Соответственно они это делают как им удобно. Вот, например, я -- терпеть не могу шаблоны. STL использую, но сам не пишу. Это такой мой "бзик". Также я не уловил прелесть смартпоинтеров. У меня и с обычными указателями никаких проблем нет. Нахрена мне умные? А вот теперь представь, что я -- тимлимд (а я на плюсах ~10 лет пишу, так что опыт имеется и на такую должность вполне могу упасть). И как себя будет чувствовать молодёжь, которая ни асма ни Си не нюхала? Я со своими требованиями буду для них "придурок, усложняющий код, когда можно написать auto". И они будут правы. И я буду прав. Вот так. Это разница в поколениях и мировоззрениях. Классическая проблема отцов-сыновей.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	7. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+3 +/–
	Сообщение от Crazy Alex (ok), 07-Июл-17, 12:15
	А exception safety, move semantics, вот это всё - тоже игноришь? Их без умных указателей не особо реализуешь... То есть можно конечно, но возни же куча.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+9 +/–
	Сообщение от A.Stahl (ok), 07-Июл-17, 12:50
	Исключения не люблю, а вот move semantics почти не нужно если у тебя всё хорошо с обычными указателями. Если писать в Ява-стиле, то да -- эта штука реально спасает. Сишнику это не очень критично. У сишника не часто бывают нюансы когда ты "передаёшь эстафету" и умираешь:) Да и сишник всегда может передать указатель и забыть/забить. Но да, иногда эта штука крута и прикольна. Но ничего такого.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+3 +/–
	Сообщение от Crazy Alex (ok), 07-Июл-17, 13:57
	Создать объект и отдать его контейнеру - это редкая операция? А если нет - то либо умные указатели, либо move semantics, либо с ровного места теряем в производительности на копированиях объектов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+4 +/–
	Сообщение от A.Stahl (ok), 07-Июл-17, 15:04
	Я обычно передаю указатель. Редко бывает, когда объект нужен много кому и непонятно кто должен его удалять.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Crazy Alex (ok), 07-Июл-17, 15:36
	А у меня - как-то через раз. Лежит себе вектор указателей на объекты, чему-то один из них понадобился - оно его получило. Сохранило где-то или нет - с умными указателями мне не интересно, как и то, как соотносятся сроки жизней контейнера и клиента. Для стаистики, например - самое оно. Посчитал, сложил, дал интерфейс, забыл.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	31. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+6 +/–
	Сообщение от A.Stahl (ok), 07-Июл-17, 16:15
	Красиво казал. Меня там минусуют, но они не совсем понимают суть. Я не против новых "фишек", просто некоторые нюансы мне не нравятся. Не более того. Я просто стараюсь оставлять код очевидным. Очевидным даже для сишников (я и сам такой), а не только для плюсовиков, которые следят за последними стандартами. Я не против. И никогда не использовал положение чтобы что-то запрещать. Просто некоторые вещи я не использую (даже не не использую, а избегаю использовать). Не более того.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	54. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Crazy Alex (ok), 07-Июл-17, 21:58
	Фишка в том, что "очевидный для сишников" и "очевидный для плюсовиков" - вещи разные, и чем больше масса кода, тем больше в них противоречие. Подход сишника - "каждый конкретный кусок должен быть ясен вплоть до примерного набора инструкций процессора". Подход плюсовика - "каждый конкретный кусок должен быть ясен в терминах алгоритмики и тех понятий, в которых мы пишем, а ниже лезем только при явной необходимости - и желательно один раз, добавляя новое понятие". То самое implementation hiding, loose coupling и подобное. Идеальный пример здесь - шаблоны (в которых мы реализуем что-то очень общее) и при нужде - их специализации (где лезем в детали).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	60. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от Аноним (-), 07-Июл-17, 22:33
	> Фишка в том, что "очевидный для сишников" и "очевидный для плюсовиков" - вещи разные, и чем больше масса кода, тем больше в них противоречие. Это лишь ваше представление которое основано, к сожалению, на незнании или малоопытности программирования на Си. > Подход сишника - "каждый конкретный кусок должен быть ясен вплоть до примерного набора инструкций процессора". Подход плюсовика - "каждый конкретный кусок должен быть ясен в терминах алгоритмики и тех понятий, в которых мы пишем, а ниже лезем только при явной необходимости - и желательно один раз, добавляя новое понятие". То самое implementation hiding, loose coupling и подобное. Идеальный пример здесь - шаблоны (в которых мы реализуем что-то очень общее) и при нужде - их специализации (где лезем в детали). Вообще не то. Подход сишника: узнаем как должно работать и реализуем сразу. Подход плюсовика: узнаем как должно работать и соображаем как составить код с "правильным" ООП, шаблонами и прочим трешем. Разговоры о том что ООП - sucks идут уже давно, и первыми об этом заговорили эксперты программирования которые уперлись в проблемы ООП. Вот и я уперся в свое время и больше я ООП не трогаю если только не приходится.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	69. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от Crazy Alex (ok), 08-Июл-17, 01:40
	Ох как забавно. Подход "узнаем как должно работать и реализуем сразу" (велосипед, как правило) - это студенческая наивность. Потому что вменяемый разработчик вообще на любом языке будет думать не просто "как должно работать", а как обеспечить минимум багов, как упростить поддержку, как дать разумные возможности расширения, как реализовать обработку ошибок, как учесть многопоточныость и прочее. И это всё собственно реализацию может превосходить в разы по размерам и сложности. Так вот сюрприз - всякое "правильное" ООП, шаблоны (которые паттерны) и подобное - как раз об этом. Чтобы сделать заведомо известными, проверенными способами. Которые не только сами по себе хороши, но и другие люди их сразу поймут и будут знать, что с этим кодом делать и чего ждать. Ну а "вот и я уперся в свое время и больше я ООП не трогаю если только не приходится" это вообще мило. Может, у вас просто мозгов не хватило? Судя по первой части - вполне может быть.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	74. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Аноним (-), 08-Июл-17, 04:17
	Очень забавно потому что вот это - "вменяемый разработчик вообще на любом языке будет думать не просто "как должно работать", а как обеспечить минимум багов, как упростить поддержку, как дать разумные возможности расширения, как реализовать обработку ошибок, как учесть многопоточныость и прочее" это как бы само-собой разумеющееся, и у опытных решение было уже принято где-то в момент "узнаем как должно работать". Поэтому реализуем сразу. А то что вы пишете "Подход "узнаем как должно работать и реализуем сразу" (велосипед, как правило) - это студенческая наивность" - это выдало в вас новичка. > Так вот сюрприз - всякое "правильное" ООП, шаблоны (которые паттерны) и подобное - как раз об этом. Чтобы сделать заведомо известными, проверенными способами. Которые не только сами по себе хороши, но и другие люди их сразу поймут и будут знать, что с этим кодом делать и чего ждать. Согласен что design patterns на словах выглядит изумительно, но я этим переболел. Но на практике от них часто много разных проблем. Поэтому я не сторонник "размазывать" управляющую логику в паттерны, а формулирую их в юниты. Но > Ну а "вот и я уперся в свое время и больше я ООП не трогаю если только не приходится" это вообще мило. Может, у вас просто мозгов не хватило? Судя по первой части - вполне может быть. Судя по вашим ответам - вы тот еще нуб.
	Ответить \| Правка \| К родителю #69 \| Наверх \| Cообщить модератору


	80. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от pripolz (?), 08-Июл-17, 11:34
	> Подход сишника - "каждый конкретный кусок должен быть ясен вплоть до примерного набора инструкций процессора". Подход плюсовика - "каждый конкретный кусок должен быть ясен в терминах алгоритмики и тех понятий, в которых мы пишем, а ниже лезем только при явной необходимости - и желательно один раз, добавляя новое понятие". броо! +!!! А вообще я редкостный хейтер всего кроме Си (хотя писал на 100 языках), потому, что вот эта философия новой школы "я приложу старания, для того, чтобы НЕ ЗНАТЬ, как это работает внутри" это ... сами понимаете. Не просто палка в колесо, а супер заумная палка, героически внедряемая под покровом ночи.
	Ответить \| Правка \| К родителю #54 \| Наверх \| Cообщить модератору


	100. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok), 08-Июл-17, 17:51
	> А вообще я редкостный хейтер всего кроме Си (хотя писал на 100 > языках), потому, что вот эта философия новой школы "я приложу старания, > для того, чтобы НЕ ЗНАТЬ, как это работает внутри" это ... > сами понимаете. Не просто палка в колесо, а супер заумная палка, > героически внедряемая под покровом ночи. А вы и так не знаете, не переживайте. Даже пишущий на ассемблере не знает, как оно будет выполняться на современном процессоре унутре. Даже в каком порядке. Более того, язык Цэ разработан для однопроцессорной машины типа PDP, как известно. Соответственно, на других машинах, типа Itanium/Эльбрус или видеокарты или многопроцессорные Sparc/Power, он работает несколько неоптимально.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	124. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Аноним (-), 09-Июл-17, 01:44
	> А вы и так не знаете, не переживайте. Даже пишущий на ассемблере не знает, как оно будет выполняться на современном процессоре унутре. Даже в каком порядке. Это и не нужно, во-первых. Во-вторых речь не о машинном исполнении была. > Более того, язык Цэ разработан для однопроцессорной машины типа PDP, как известно. Соответственно, на других машинах, типа Itanium/Эльбрус или видеокарты или многопроцессорные Sparc/Power, он работает несколько неоптимально. Ложное утверждение. Как будет работать на процессорах зависит от того как напишешь, что напишешь и во что это будет оттранслировано в конечном счете. Кстати, в отличии от С++, на Си можно формировать нужные для компилятора единицы трансляции которые нельзя и нельзя будет сформулировать в рамках новомодных и "правильных" догм С++. Надеюсь вы сами догадаетесь почему оно так.
	Ответить \| Правка \| К родителю #100 \| Наверх \| Cообщить модератору


	127. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok), 09-Июл-17, 02:08
	> Это и не нужно, во-первых. Во-вторых речь не о машинном исполнении была. Ну да, на каком-то уровне приходится останавливаться. Ну можно остановиться на ассемблере, можно выше, можно ещё выше. В зависимости от задачи оптимальность той точности, с которой разработчик понимает, что будет происходить, разная. > Ложное утверждение. Как будет работать на процессорах зависит от того как напишешь, > что напишешь и во что это будет оттранслировано в конечном счете. Да. Только есть языки более приспособленные, есть менее приспособленные для определённой задачи. И слабая приспособленность С к многопроцессорным машинам приводит к тому, что приходится обвешиваться pthread'ами и соблюдать чудеса внимательности, растрачивая своё время и силы. А в более приспособленных к параллельным вычислениям языках можно это делать значительно легче. Например, один из самых приспособленных языков к ним - это make. Чтобы распараллелить задачу на нём требуется задать один ключ -j. Понятно, что у make слишком слабый контроль за параллелизацией вычислений для системного языка, но ясно, что, тем не менее, у такого языка параллелизация может быть сделана лучше, чем у теперешнего С.
	Ответить \| Правка \| К родителю #124 \| Наверх \| Cообщить модератору


	129. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Аноним (-), 09-Июл-17, 02:46
	> Ну да, на каком-то уровне приходится останавливаться. Ну можно остановиться на ассемблере, можно выше, можно ещё выше. В зависимости от задачи оптимальность той точности, с которой разработчик понимает, что будет происходить, разная. Зачем вообще вы снова асм тянете, я не пойму. Вот люди пишут на java и не парятся что их байткод весь внутри в goto. Или вы из тех кто совсем не умеет в си прикладные задачи алгоримтического плана? > Да. Только есть языки более приспособленные, есть менее приспособленные для определённой задачи. И слабая приспособленность С к многопроцессорным машинам приводит к тому, что приходится обвешиваться pthread'ами и соблюдать чудеса внимательности, растрачивая своё время и силы. > А в более приспособленных к параллельным вычислениям языках можно это делать значительно легче. Например, один из самых приспособленных языков к ним - это make. Чтобы распараллелить задачу на нём требуется задать один ключ -j. > Понятно, что у make слишком слабый контроль за параллелизацией вычислений для системного языка, но ясно, что, тем не менее, у такого языка параллелизация может быть сделана лучше, чем у теперешнего С. Если продолжить вашу мысль то можно еще проще сделать - запускать N-процессов и вообще нет проблем. Даже -j не нужен.
	Ответить \| Правка \| К родителю #127 \| Наверх \| Cообщить модератору


	130. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok), 09-Июл-17, 02:56
	> Зачем вообще вы снова асм тянете, я не пойму. Ветка такая. См. несколько комментов выше.
	Ответить \| Правка \| К родителю #129 \| Наверх \| Cообщить модератору


	133. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Аноним (-), 09-Июл-17, 05:48
	В 12.54 Crazy Alex написал свое ОГРАНИЧЕННОЕ (!) понимание программирования в Си на что мне пришлось дать в 12.60 ему ортогональный ответ. Вижу вы согласились с предложенным в 12.54 толкованием, но если если вы следили за веткой 12.54 -> 12.60, то должны были понять что ситуация осталась спорной. Получается что вы все время апеллируете к асму только из-за ограниченного понимания Си прользователем Crazy Alex ? Ничего не смущает?
	Ответить \| Правка \| К родителю #130 \| Наверх \| Cообщить модератору


	135. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok), 09-Июл-17, 07:29
	> Получается что вы все время апеллируете к асму только из-за ограниченного понимания > Си прользователем Crazy Alex ? Ничего не смущает? Я писал недавно зарегистрировавшемуся товарищу на букву p.
	Ответить \| Правка \| К родителю #133 \| Наверх \| Cообщить модератору


	140. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Аноним (-), 09-Июл-17, 16:14
	Точно, сообщение 12.80 от пользователя pripolz. Но это не меняет ситуацию с постоянным обращением к асму.
	Ответить \| Правка \| К родителю #135 \| Наверх \| Cообщить модератору


	61. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+2 +/–
	Сообщение от Аноним (-), 07-Июл-17, 22:41
	Я не кравиво сказал, а рассказал как оно обстоит в реальном программировании. У меня складывается ощущение что местные кто печатает здесь заумные термины, на практике их используют примерно ноль раз. Мне нравится философия Java и еще больше нравится Си, но не вычурное ботанство С++ потому что используя "фишки" С++ ты себя просто заковываешь в кандалы. Я не вижу преимущество в С++, даже банальные перегрузки операции часто вызывают семантическую неоднозначность. То есть надо лезть и разбираться. Убого и долго.
	Ответить \| Правка \| К родителю #31 \| Наверх \| Cообщить модератору


	52. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Crazy Alex (ok), 07-Июл-17, 21:45
	Умные указатели сложность, в общем, не особо прибавляют, если дать себе труд раз в жизни разобраться, как они работают. Поскольку они стандартны - только один раз и надо это сделать. И тоже будет всё просто - только на других предпосылках. Там случаев-то - раз-два и обчёлся - https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... - пяток экранов на все принципы.
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


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


	68. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Crazy Alex (ok), 08-Июл-17, 01:31
	Единственная "Ситуация, когда от них больше вреда, чем пользы" - это когда в программке пятьсот строк, десяток классов и один автор. Для всего, что сложнее "простой инспекцией выловить границы жизни объекта без того чтобы тратить время на анализ исполнения" - идея заведомо идиотская. Там уже надо думать не о вылавливании сроков жизни, а о том, чтобы гарантировать и существование, и своевременное уничтожение объектов - в том числе в чужом коде, который про ваши внутренние соглашения понятия не имеет и человеком, который впервые видит ваши интерфейсы (а в реализацию в принципе не полезет). Смарт поинтеры дают для этого стандартный, понятный любому квалифицированному плюсовику инструментарий.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	71. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Аноним (-), 08-Июл-17, 03:55
	> Единственная "Ситуация, когда от них больше вреда, чем пользы" - это когда в программке пятьсот строк, десяток классов и один автор. Для всего, что сложнее "простой инспекцией выловить границы жизни объекта без того чтобы тратить время на анализ исполнения" - идея заведомо идиотская. Там уже надо думать не о вылавливании сроков жизни, а о том, чтобы гарантировать и существование, и своевременное уничтожение объектов - в том числе в чужом коде, который про ваши внутренние соглашения понятия не имеет и человеком, который впервые видит ваши интерфейсы (а в реализацию в принципе не полезет). Смарт поинтеры дают для этого стандартный, понятный любому квалифицированному плюсовику инструментарий. Вы вообще программировали что-нибудь серьезное? Когда вы будете думать о том как гарантировать существование и своевременное уничтожение объекта в коде, архитектура которой прорабатывается сразу несколькими людьми, то вы будете думать над сроками жизни объекта. Все ваши "смарт поинтеры и соглашения" вылетают в трубу когда вам надо перестроить контроллеры и переработать часть архитектуры. Я вам на основе практического опыта скажу что самый лучший вариант в подобных случаях - передать управление временем жизни объекта контроллеру. Это позволяет менять архитектуру и код как угодно и во что угодно, не ограничивая себя неповоротливыми "best practices" и не расходуя время на создание ненужных контрукции только потому что в какой-то книжке кто-то написал что это "понятный любому квалифицированному плюсовику инструментарий". Плюсы: 1) самодокументируемый код снимяющий все неясности из-зя явных операции 2) управляющий код элементарен и может подводиться под условия (оптимизация, кеширование и прочее) 3) теперь граница жизни объекта оторвана от представления програмной конструкции, то есть можно делать что угодно с архитектурой (а мы ведь любим биндинги на другие языки?) и вам не надо думать о времени жизни объекта; можете считать это декомпозицией архитектуры Подобное делается просто на Си, С++ и любых других языках, и особенно в Java. Скорость исполнения не страдает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	58. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Аноним (-), 07-Июл-17, 22:19
	А как же Вы обрабатываете ошибки? Я Плюсы знаю неплохо, но пишу на чистом Си. Простые задачи выношу в Питон. На обработку ошибок в Си, выставления errno и т.п. уходит иногда до половины кода (с учётом библиотеки под эти дела). Мне всегда было интересно, как у серьёзных проектов на плюсах дела с обработкой ошибок обстоят. try... намного увеличивают количество кода и уменьшают читабельность. Я уже не говорю, что я не смогу вызвать конструктор стекового объекта внутри try..., т.к. ограничу объект его областью видимости. Но в то же время программа должна корректно обрабатывать ошибки и реагировать на них. Так как Вы обходитесь без исключений то?
	Ответить \| Правка \| К родителю #11 \| Наверх \| Cообщить модератору


	81. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+2 +/–
	Сообщение от pripolz (?), 08-Июл-17, 11:52
	> А как же Вы обрабатываете ошибки? Я Плюсы знаю неплохо, но пишу > на чистом Си. Простые задачи выношу в Питон. На обработку ошибок > в Си, выставления errno и т.п. уходит иногда до половины кода > (с учётом библиотеки под эти дела). Мне всегда было интересно, как > у серьёзных проектов на плюсах дела с обработкой ошибок обстоят. try... > намного увеличивают количество кода и уменьшают читабельность. Я уже не говорю, > что я не смогу вызвать конструктор стекового объекта внутри try..., т.к. > ограничу объект его областью видимости. Но в то же время программа > должна корректно обрабатывать ошибки и реагировать на них. Так как Вы > обходитесь без исключений то? я всю обработку ошибок кладу в макрос, в котором и печать в лог номера строки кода, и вызов функции-пустышки BreakPointPit - чтобы поставить один брейкпоинт на все ошибки. Получается универсальная проверка одной строчкой: CHECK(statement, ERR_CODE); Освобождение ресурсов при выходе обеспечивается goto ErrorLabel вместо простого return; Ну я сишник, как ты понял. А плюсовики на моём опыте просто не обращают внимания. Присвоил локальной преременной new, и пошёл дальше. Выделится память или не выделится, бросит ли кто-то эксепшн дальше в функции, да пофигу. Они слишком уверенны в идеальности своих инструментов
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


	121. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok), 08-Июл-17, 23:54
	> Освобождение ресурсов при выходе обеспечивается goto ErrorLabel вместо простого return; Их должно быть несколько, если выделяются сразу несколько ресурсов. И не перепутать порядок. А если ресурсы выделяются/освобождаются в цикле, то так уже не получится сделать: for( int i = 0; i < 5; i++) { f = fopen(file[i],"rt"); ... <глобальная ошибка> ... fclose(f); }
	Ответить \| Правка \| К родителю #81 \| Наверх \| Cообщить модератору