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

"Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
Сообщение от opennews (ok) on 07-Июл-17, 11:12
Джон Регир (John Regehr (https://en.wikipedia.org/wiki/John_Regehr)), профессор университета штата Юта, участвующий в разработке Clang и занимающийся исследованиями в области неопределённого поведения программ (https://ru.wikipedia.org/wiki/%D0%9D%D0%...), подготовил полезный для разработчиков обзор ситуаций (https://blog.regehr.org/archives/1520), при которых поведение программы становится неопределенным и приводит к получению проблем с использованием памяти и указателями при  сборке разными компиляторами.  В статье не только описаны возникающие проблемы, но и предложены способы для их выявления, а также оценена эффективность применения для обнаружения неопределённого поведения типовых отладочных инструментов, таких как Address Sanitizer (ASAN), UndefinedBehaviorSanitizer (UBSan), MemorySanitizer (MSan), ThreadSanitizer (aka TSan) и Valgrind. URL: https://blog.regehr.org/archives/1520 Новость: http://www.opennet.me/opennews/art.shtml?num=46820
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+31 +/–
Сообщение от A.Stahl (ok) on 07-Июл-17, 11:12
Во-первых -- 3 галлона пива господину Регеру за очень краткие и ёмкие кусочки кода. Во-вторых г-н Регер показал, что UB это обычно результат наркоманского кода. Арифметика указателей? Ок, все мы её в той или иной мере используем, но нужно знать и меру. Самое важное правило (все новички о нём знают[сами для себя и выводят], а вот люди с опытом часто забывают) -- код должен быть простым и понятным. В 21 веке компиляторы лучше оптимизируют под платформу чем человек. Поэтому нужно писать простой и понятный код. Эффективный код -- удел компилятора. Да, некоторые моменты (обход прямоугольной матрицы и т.п.) до сих пор актуальны, но это не усложняет код и вполне вписывается в концепцию здравого смысла.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Zoolander on 07-Июл-17, 11:38
	Как думаете, почему профессионалы подвержены болезни усложнения кода? У них крыша едет? Или они думают, что все могут в памяти держать?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+3 +/–
	Сообщение от Iaaa (ok) on 07-Июл-17, 11:45
	Тоже вижу слишком часто неоправданное усложнение. Может "не солидно", "что я как джун какой-то писать буду"? Ну а вообще, "Real Programmers don't comment their code. If it was hard to write, it should be hard to understand." (c)
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	121. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok) on 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 on 09-Июл-17, 02:08
	инициализация нулями спасёт мир for (int i = 0; i < 5; i++)     if (f[i])         fclose(f[i]);
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	128. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok) on 09-Июл-17, 02:14
	> инициализация нулями спасёт мир Это костыль под конкретный случай. Взять какую-нибудь другую структуру и опа.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	131. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от pripolz on 09-Июл-17, 03:29
	> инициализация нулями спасёт мир > for (int i = 0; i < 5; i++) >     if (f[i]) >         fclose(f[i]); упс, не по теме написал. Сори.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	136. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Аноним (??) on 09-Июл-17, 09:15
	У нас на метки с освобождением ресурсов и восстановлением уходит до половины тела функций. В функциях инициализации их может быть и 10, и 15. А если цикл с выделением памяти, к примеру,  - то подобные куски кода выгоднее выносить в отдельные функции. По ошибке обходить цикл в обратку и всё освобождать. Тогда код основной функции будет более читабельным.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	13. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–2 +/–
	Сообщение от yet another anonymous on 07-Июл-17, 12:56
	> exception safety, move semantics, ...  Их без умных указателей не особо реализуешь... Бред.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	18. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Crazy Alex (ok) on 07-Июл-17, 14:00
	Говорю же - можно, но морока. Придётся самому отслеживать все случаи, когда надо прибить указатель - а ради чего? Что характерно - это ж не я придумал, можете любого плюсового гуру поглядеть - здесь разногласий нет с того самого 11-го года.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	22. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от yet another anonymous on 07-Июл-17, 15:05
	move не имеет к *_ptr отношения. *_ptr подразумевают move. (при достаточно полной реализации). Поэтому "для реализации move-семантики нужны умные указатели" --- набор слов, не складывающийся в осмысленную фразу. Если фраза подразумевала "при релизации move-семантики объекта обязательно нужны умные указатели", то тоже бред выходит: это зависит от объекта. > А exception safety, move semantics, вот это всё - тоже игноришь? Их без умных указателей не особо реализуешь...
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	23. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Crazy Alex (ok) on 07-Июл-17, 15:31
	Нет. Подразумевалось "умные указатели радикально упрощают реализацию move-семантики". Если у тебя поля - обычные указатели, тебе надо для каждого выяснить, как именно он инициализируется, кто им владеет и так далее. Если умные - из типа всё очевидно и есть стандартные правила обращения с ними. Когда речь не о программках из десятка классов - это принципиально.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	35. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от yet another anonymous on 07-Июл-17, 17:18
	Т.е. второй вариант. Мне нравится такой подход: неявно подразумевается вполне определённая реализация с вполне определёнными предположениями/гарантиями/etc. Все остальное объявляется несущественным/неактуальным/безнадёжно устаревшим и т.п. Так держать! Вы победитель!
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	53. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Crazy Alex (ok) on 07-Июл-17, 21:51
	Оно везде так. Называется "best practices". Использование ничего-то отличающегося надо обосновывать, потому что для этого отличающегося нет сто раз проверенных методов применения, возможных граблей и их обходов, оценок эффективности, готовых инструментов и прочего. В софте это, собственно, гораздо слабее выражено, чем в других областях инженерии, так что не вам бы плакаться.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	25. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от kai3341 (ok) on 07-Июл-17, 15:35
	Или ещё вариант: на этапе проектирования закладывается больше гибкости и универсальности. Если она вся не используется, код переусложнён. Тогда говорят "Фу, оверинжениринг". А вот если её становится недостаточно, начинается адище.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	34. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–3 +/–
	Сообщение от anonymous (??) on 07-Июл-17, 17:13
	> И они будут правы. Они будут правы. > И я буду прав. А вот вы не будете. Будете старым пердуном, который не успевает за ритмом развития инструмента, но прикрывается словами о простоте и 10 годах опыта.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	82. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от pripolz on 08-Июл-17, 12:30
	>> И они будут правы. > Они будут правы. >> И я буду прав. > А вот вы не будете. Будете старым пердуном, который не успевает за > ритмом развития инструмента, но прикрывается словами о простоте и 10 годах > опыта. Почитайте книгу "Современный и эффективный С++". Там автор докажет вам, что auto - тот ещё фрукт. В конце он приходит к выводу, что инициализируя auto "хорошо бы добавить статик каст". Т.е. уже начинается борьба ради ауто. Так что, всё как раз наоборот. Они не будут правы (просто не знают проблем), а он прав будет, потому что знает, а не не знает.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	97. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от anonymous (??) on 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; } > Так что, всё как раз наоборот. Они не будут правы (просто не > знают проблем), а он прав будет, потому что знает, а не > не знает. Он как раз не знает. И не использует то, чего не знает и боится.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	99. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok) on 08-Июл-17, 17:46
	> Почитайте книгу "Современный и эффективный С++". Там автор докажет вам, что auto > - тот ещё фрукт. Можно ссылку?
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	105. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от pripolz on 08-Июл-17, 19:29
	>> Почитайте книгу "Современный и эффективный С++". Там автор докажет вам, что auto >> - тот ещё фрукт. > Можно ссылку? Там ниже в беседе кидали на магаз О-Райли. Effective Modern C++ Майерса.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	110. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok) on 08-Июл-17, 19:57
	> Там ниже в беседе кидали на магаз О-Райли. Effective Modern C++ Майерса. А-аа, Майерс. Просто modern C++ - это в разные времена совершенно разное.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	5. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–2 +/–
	Сообщение от Crazy Alex (ok) on 07-Июл-17, 12:08
	1) Профессионалы часто пишут что-то большое, и долго. Со временем качество кода в проекте неизбежно падает, и приходится колдовать. Нет, рефакторинг возможен (точнее, окупается) не всегда. 2) Профессионалы часто правда могут спокойно переварить довольно сложный код, а не только "думают", что могут. И как сложный его не воспринимают. Это вполне развиваемый навык, просто времени много уходит.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	66. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Алконим on 08-Июл-17, 01:23
	Если будет падать качество кода, то упадёт и скорость разработки, и проект упрётся в стену. У професионалов, качество кода к концу проекта растёт а не падает, скорость разработки растёт, возможности растут. Это сложно, это нужно знать и уметь процесы и методики, это геморойно и не связано с програмированием вообще, но оно того стоит когда нужно выиграть клиента. Клиенты сейчас умные пошли — заказывают проект сразу в двух конторах (часть там, часть там), а потом избавляются от неудачника через несколько месяцев и передают их часть третей конторе, и т.д. Так что про «неизбежно падает» рассказывай нашим конкурентам а не нам.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	76. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Вареник on 08-Июл-17, 08:08
	Любой проект постепенно обрастает заплатками и требует специальных мер от команды, чтобы не превратиться в "лапшу".
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	77. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от Вареник on 08-Июл-17, 08:13
	Написать модуль по спеку - не совсем жизненный цикл проекта. Тот же проект потом еще кучу контракторов/сотрудников переживет, сотни патчей и часто - несколько хозяев (т.е. тех самых "заказчиков"). И вот тогда уже можно говорить о качестве кода - когда проект сменил трех владельцев, десятки не связанных между собой сотрудников и в нем все еще можно разобраться и принципы модульности, архитектуры остались соблюдены.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	79. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от Аноним (??) on 08-Июл-17, 11:22
	Полностью поддерживаю. В нашей команде качество кода растёт со временем. Во-первых, программисты становятся более опытными и учатся друг у друга, а во-вторых, приходится делать рефакторинг старого кода при добавлении новых функций. Рефакторинг иногда бывает длительным, но себя полностью окупает, т.к. дальнейшая разработка и внедрение новых функций будет идти на порядок быстрее.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	9. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Аноним (??) on 07-Июл-17, 12:30
	Желание того что-бы их код работал так как они решили, а не как вздумается компилятору ( сегдня быстрее, завтра медленнее)
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	117. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от anonymous (??) on 08-Июл-17, 22:26
	>Как думаете, почему профессионалы подвержены болезни усложнения кода? я за 15 лет вокруг как раз вижу что становясь профессионалами люди начинают упрощать код
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	14. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Аноним (??) on 07-Июл-17, 13:15
	> В 21 веке компиляторы лучше оптимизируют под платформу чем человек. Скажи это новым появляющимся языкам программирования или таким языкам как C#, у которого компилятор в принципе не имеет право заниматься тщательной оптимизацией.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	30. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от Анончик on 07-Июл-17, 16:04
	>> В 21 веке компиляторы лучше оптимизируют под платформу чем человек. > Скажи это новым появляющимся языкам программирования или таким языкам как C#, у > которого компилятор в принципе не имеет право заниматься тщательной оптимизацией. Ну, в этом есть и один плюс - C# либы/екзешники из-за этого очень легко восстановить до нормального кода вплоть до комментариев.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	36. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+2 +/–
	Сообщение от Аноним (??) on 07-Июл-17, 17:29
	> C# либы/екзешники из-за этого очень легко восстановить до нормального кода вплоть до комментариев. Я про JIT говорил. Первоначальная компиляция в CIL (как и у Java в их промежуточный байт код) происходит вообще без оптимизаций, отсюда да, можно всё восстановить. А вот с JIT'ом у C# (ладно-ладно, не C#, а CLR) есть некоторые проблемы вплоть до того, что если в цикле for у тебя стоит return, а не break с последующим return, то разность скорости выполнения этого цикла for достигает чуть ли не 2 раз (возможно, я утрирую, не помню точных цифер, но общий смысл такой).
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	37. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–5 +/–
	Сообщение от _ (??) on 07-Июл-17, 17:54
	У нормальных людей есть исходники с комментами, дока, и мэйл лист с аффтарами. Но вантузятники должны страдать! (С)
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	57. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от Анончик on 07-Июл-17, 22:13
	> У нормальных людей есть исходники с комментами, дока, и мэйл лист с > аффтарами. > Но вантузятники должны страдать! (С) RE занимаются не только вантузятники и не только на вантузе.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	24. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Ivan_83 (ok) on 07-Июл-17, 15:32
	Это не отменяет 100500 вариантов написания popcnt, для начала, которые хер компелятор распознает чтобы заменить на popcnt, да и сам popcnt не везде есть. И получается что лучше один раз хорошо написать этот низкоуровневый кусок руками чтобы он гарантированно работал везде быстро. Есть ещё 100500 разных вумных ручных оптимизаций базовых математических операций, которые нужны для работы с длинными числами. Это всё никакой компелятор тебе не оптимизирует. Но да, там где можно написать понятно и упростить лучше так и делать, с этим трудно спорить.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	33. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+2 +/–
	Сообщение от Comdiv (ok) on 07-Июл-17, 16:53
	> Во-вторых г-н Регер показал, что UB это обычно результат наркоманского кода. Это проблема восприятия маленьких понятных примеров. Для того, чтобы показать примеры, возникающих в настоящих условиях всем придётся потрудиться получше: и автору, и читателю. Гораздо проще накидать наркоманских примеров, но это совсем не значит, что это действительно главная причина появления проблем.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

6. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
Сообщение от Crazy Alex (ok) on 07-Июл-17, 12:13
Ещё один с "С/С++"? То, о чём он говорит, ловится любым приличным современным линтотулзом для плюсов, потому что сейчас на плюсах так писать вообще не принято.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от RazrFalcon (ok) on 07-Июл-17, 12:34
	Каким образом линтер ловит выход за пределы массива и use after free?
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	19. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от Crazy Alex (ok) on 07-Июл-17, 14:29
	Очень просто - ругается на попытки использовать сишные массивы и голые сишные указатели. В плюсах это bad practices, и давно.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	145. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Анонимный Алкоголик (??) on 10-Июл-17, 10:20
	> Очень просто - ругается на попытки использовать сишные массивы и голые сишные > указатели. В плюсах это bad practices, и давно. Ну то есть никак не находит выход за пределы массива. Что показывает практическую негодность этого вашего "линтера".
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	15. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от A.Stahl (ok) on 07-Июл-17, 13:26
	>потому что сейчас на плюсах так писать вообще не принято. Ну это ты загнул.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	20. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от Crazy Alex (ok) on 07-Июл-17, 14:36
	Не загибал: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... https://isocpp.org/wiki/faq/containers
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

	87. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от pripolz on 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) on 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 вообще тормозит вся и глючная до безобразия, вне зависимости от того, на чём она написана.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

	104. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от pripolz on 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 не добавишь. Поэтому самые крутые С++сники просто забивают на совместимость версий, и хреначат описание всего класса прямо в хедер. Техподдержка от этого страдает.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

	67. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от Crazy Alex (ok) on 08-Июл-17, 01:24
	Как бы наоборот. Для того, кто не поварился в плюсах с пол-года хотя бы этот текст - бессмысленный набор слов. А вот потом можно и поглядеть. Правда, тогда будет понятно, что это всё либо чушь, либо мелочные придирки - а так не интересно.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	72. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от Vkni (ok) on 08-Июл-17, 03:58
	> Очень рекомендую к просмотру, т.к. без нормальной критики вы не поймете язык > полностью: https://flyx.org/2014/04/24/cpp_sucks/ Там, мягко говоря, далеко не всё описано. И по шаблонам с STL он как-то очень слабо проехался. Нет, например, классического упрёка, что в STL везде торчат итераторы, а должны быть регионы. Ну, а синтаксис шаблонов - это просто редкостное уродство.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	75. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Аноним (??) on 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.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	73. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от Vkni (ok) on 08-Июл-17, 04:02
	> Нет, это не он загнул. Просто кто-то отстал от развития практик применения > C++ лет на десять. Лучшая практика применения современного C++ - это "можешь на нём не писать - не пиши". > под предлогами вида "мне синтаксис не нравится"? Синтаксис - это, вообще-то, первое, что видно в программе. Ну зачем же сразу в дерьмо читателя макать со всеми std::...? И это, надо сказать, подход boost'a.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	83. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Ordu (ok) on 08-Июл-17, 12:33
	>> под предлогами вида "мне синтаксис не нравится"? > Синтаксис - это, вообще-то, первое, что видно в программе. И чё с того? Ты в курсе что предпочтения в эргономике тренируются? Они не просто приобретённые, они приобретаемые. Разговоры про на вкус и цвет разные фломастеры -- это разговоры неудачников. Научиться видеть C++ код как красивый не сложнее, чем научиться им пользоваться. Даже если этот код видится тебе уродливым. Отказываться от инструмента потому, что тебе не нравится его внешний вид -- это очень странно. Можно отказываться потому, что инструмент не подходит для круга решаемых задач. Могут быть другие разумные причины. Но отказываться исходя сугубо из личных предпочтений, не связанных с тем, насколько этот инструмент полезный -- это очень странно.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	93. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok) on 08-Июл-17, 16:43
	> Научиться видеть C++ код как красивый не сложнее, чем научиться им пользоваться. Зачем нужно видеть красоту в примерах из boost'а, где в глазах просто рябит от символов <, >, ::, {} и адового кол-ва подчёркиваний? > Отказываться от инструмента потому, что тебе не нравится его внешний вид -- это очень странно. Отказываются не по этому, а потому, что язык безумно переусложнён. И поэтому не так хорошо предсказуем, как более простые.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	108. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Ordu (ok) on 08-Июл-17, 19:54
	>> Научиться видеть C++ код как красивый не сложнее, чем научиться им пользоваться. > Зачем нужно видеть красоту в примерах из boost'а, где в глазах просто > рябит от символов <, >, ::, {} и адового кол-ва подчёркиваний? Для того, чтобы использовать C++ максимально эффективно. >> Отказываться от инструмента потому, что тебе не нравится его внешний вид -- это очень странно. > Отказываются не по этому, а потому, что язык безумно переусложнён. И поэтому > не так хорошо предсказуем, как более простые. Может быть другие отказывают по этим причинам. Но в этом треде я не слышал ни одной причины, кроме "мне не нравится внешний вид".
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	113. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok) on 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
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	114. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Ordu (ok) on 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 вовсе не из-за этих слов, мне они не мешают.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

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

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

	122. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok) on 09-Июл-17, 00:09
	> Да, это заговор ZOG. Они подтасовывают данные, пишут лжеруководства и вообще вводят > нас всячески в заблуждение. Это не заговор. Просто некоторые люди варятся в одном и том же добре уже довольно долгое время, глаз замылился. > Когда что-то заставляет задуматься -- это хорошо, но когда процесс мышления не > приводит в результате к развитию, то это был не процесс мышления, > а интеллектуальная мастурбация. > У C++ есть проблемы с ABI, но не те, о которых говорили. > Матчинг -- да, это удобно, но эмм... в C матчинга больше? С давно уже тоже пора на помойку. > А насчёт слишком много препроцессора -- это о чём? Это об #include в первую очередь. > или о темплитах? Первое совсем уж идиотизм, предположу > про второе, и скажу вот что: какая разница сколько там препроцессора? Такое ощущение, что вы не очень понимаете, о чём пишете - шаблоны и препроцессор, это совершенно разные и независимые вещи. > Как по мне, так в C++ как раз не хватает нормального > препроцессора, который будет работать именно с синтаксисом. Пробовали в Ocaml'е - Camlp4/p5. Не взлетело, т.к. слишком сложно. Более правильный подход в Хаскеле - мощный основной язык с разными "deriving" + Cшный препроцессор, который может слегка изменить код, подточив под версию языка или библиотеки. Но не больше, чем пара-тройка #ifdef'ов на файл. Совсем без препроцессора плохо, но заменять им основной язык невозможно - они рассинхронизуются, разделены и т.д. > Мы продолжаем спорить о том, что красиво, а что нет? Или таки > примем за факт, что красота в инженерном деле должна служить исключительно > инструментальным целям и, таким образом, быть починена другим целям? Ну вот в данном случае Ocaml и Haskell явно красивее C++-а, т.к. инженерная цель - максимально простое, экспрессивное и краткое описание одной и той же полиморфной функции лучше даётся им.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	123. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Ordu (ok) on 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++-а, т.к. > инженерная цель - максимально простое, экспрессивное и краткое описание одной и > той же полиморфной функции лучше даётся им. Ещё раз скажу вам: красивым будет любой привычный язык. Он при этом может быть сколь угодно галимым языком, но если он привычен, то он будет восприниматься как красивый. Это особенности человеческой психологии так сказываются. Поэтому поймите наконец одну вещь: аргументы типа "красиво" для меня -- пустой звук. Аргументы типа "красиво" -- отражают не положение дел в реальности, а свойства вашей психики. Причём даже не какие-то фундаментальные и неизменные свойства психики, а приобретённые и постоянно изменяющиеся свойства. Эти свойства не имеют никакого отношения к тому, насколько удачен тот или иной язык программирования для той или иной задачи.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	125. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok) on 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) on 09-Июл-17, 14:04
	>> Ещё раз скажу вам: красивым будет любой привычный язык. > У меня опыт владения ЦэПэПэ где-то лет 20 уже. Ocaml'а - десяток. Видимо, опыт опыту рознь.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	141. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok) on 09-Июл-17, 16:22
	Разумеется - я и другие языки знаю.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	148. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от yet another anonymous on 10-Июл-17, 11:35
	> Конечно, import/uses/open значительно лучше. Они ведь подразумевают развитую систему модулей, а не паразитирование на допотопном однопроходном линковщике. Превед, GOLD! ;)
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	162. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok) on 12-Июл-17, 07:45
	> Превед, GOLD! ;) С этой точки зрения разницы между ld и ld.gold нет. Одна, в целом, фигня.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

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

	86. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Ordu (ok) on 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. Поверь мне, ты повесишся раньше, чем допишешь эту программу. Причём вне зависимости от выбранного языка: этот заморочный диспатч можно сделать хоть на ассемблере, проблем-то? Но вот степенная зависимость количества реализаций методов от количества типов -- это убийственно.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	89. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от pripolz on 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. Намёк не понят. Хочешь наследование - положи структуру в структуру.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	96. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok) on 08-Июл-17, 17:20
	> программирование стоит на месте. Очень, очень костная штука. Хиндли-милнер, несчастный, был открыт за 20 (двадцать) лет до возникновения шаблонов в С++.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	106. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Ordu (ok) on 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) on 08-Июл-17, 19:57
	> Кстати тут вариант ещё щадящий, потому что функция > коммутативна, и тебе придётся писать не N^2 конкретных реализаций метода distance, > а N*(N-1)/2. Ага. Потому, что формулы разные. По крайней мере для евклидовой метрики.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	132. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от pripolz on 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) on 09-Июл-17, 05:55
	> Я указал на то, что если будет метод "расстояние между точкой и прямой" - то его по канонам С++ нужно будет обязательно выполнить либо в классе "прямая", либо в классе "точка", либо в классе "фигура". В C++ это можно сделать разными методами и использовать ООП совершенно не обязательно. В частности, в данном случае лучше всего использовать шаблоны. template <class A, class B> double distance( const A &, const B &) И инстанциировать это хозяйство для разных пар, поскольку формулы для разных пар действительно разные.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	137. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от pripolz on 09-Июл-17, 11:11
	> В C++ это можно сделать разными методами и использовать ООП совершенно не > обязательно. В частности, в данном случае лучше всего использовать шаблоны. > template <class A, class B> double distance( const A &, const B > &) > И инстанциировать это хозяйство для разных пар, поскольку формулы для разных пар > действительно разные. а в рантайме такой темплейт подхватит заранее неизвестный тип фигуры?
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	142. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok) on 09-Июл-17, 16:39
	> а в рантайме такой темплейт подхватит заранее неизвестный тип фигуры? Нет, конечно. Но основная проблема тут не в языке, а в предметной области - у вас нет единой формулы для расчёта дистанций между фигурами разной формы. А вот если она найдётся, то значит можно её написать с учётом каких-то встроенных свойств фигур, и сделать всё на шаблонах. Например, если можно написать функцию расстояния от фигуры до точки, то можно написать единый алгоритм вычисления минимизацию суммы этих расстояний. И тогда он подхватит в compile-time заранее неизвестный тип фигуры, у которого будет distanceToPoint. Но это не ООП, а generic, т.е. шаблоны, т.е. практически функциональное программирование.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	139. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Ordu (ok) on 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 +/–
	Сообщение от Аноним (??) on 09-Июл-17, 18:26
	Очередная порция словесного поноса.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	144. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от pripolz on 09-Июл-17, 23:33
	> Современный C++ не любит наследование и с подозрением относится к ООП. Исключительно забавное заявление. Во первых потому, что ООП - это шаблон проектирования. FILE * стандартной библиотеки Си - типичный ООП. Во вторых заявление забавно потому, что получается, что С++ комьюнити начинает соглашаться с тем, что всё это время двигалось не в ту сторону. Вчера они объясняли тебе, ПОЧЕМУ наследование - это хорошо, а сегодня.. они вернулись обратно. Программирование стоит на месте. Потому что у него нет причин куда-то двигаться. Был ассемблер, всё было нормально. Но есть у ассемблера недостаток - он непереносим на другой проц по определению. И появился Си. Именно поэтому. Си сегодня выкинуть невозможно. Представь, что удалили все программы, написанные на си (пусть не считая ОС и драйверов). Что останется? А вот Джаву например удалить можно. Вообще ничего не изменится. И С++ тоже. И Rust с его отсутствием наследования.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	150. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok) on 10-Июл-17, 14:59
	> Вчера они объясняли тебе, ПОЧЕМУ наследование - это хорошо Окститесь, 20 лет прошло с тех пор.
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	151. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+1 +/–
	Сообщение от pripolz on 10-Июл-17, 18:24
	> Окститесь, 20 лет прошло с тех пор. То есть, современный С++ не просто не любит наследование, а ДАВНО не любит наследование? Ещё более забавно. Вы не говорите, что "ordu преувеличил, С++ всё ещё любит наследование". Как же специальные костылики для решения проблемы ромба?
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	152. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от yet another anonymous on 10-Июл-17, 20:06
	> То есть, современный С++ не просто не любит наследование, а ДАВНО не любит наследование? Ещё более забавно. См.: Elements of Programming by A. Stepanov.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	153. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok) on 11-Июл-17, 03:05
	> а ДАВНО не любит наследование? Хуже - ОЧЕНЬ ДАВНО не любит наследование. Если бы не Степанов с STL, а дальше Александреску с метапрогразмом, этот С++ давно бы выкинули на помойку. Ибо наследование, виртуальные функции и т.д. лучше реализовано в Яве, в С#, Delphi, ну и других языках. У С++ ниша языка с относительно мелким рантаймом и возможностью очень глубокой оптимизации. Классы же с виртуальными функциями, наследованием, указателями и т.д. сильно тормозят. А шаблоны, несмотря на ряд косяков (синтаксис, отсутствие раздельной компиляции), позволяют делать с одной стороны достаточно высокуровневый, а с другой стороны, оптимизированный код. Есть даже места, где RTTI вообще нафиг отключают, а значит выключают и "объектно-ориентированное-программирование на С++".
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	154. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от pripolz on 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) on 11-Июл-17, 12:21
	> - потому что процесс генерации прозрачен и понятен. Во-первых, нет. Он понятен только до определённого момента - пара ступеней вложенности, после чего это всё превращается в лапшу. > - тут не нужно вспоминать тонкости синтаксиса, минимальное кол-во боли при ревизии. В С++ тонкости синтаксиса - это STL с её идиотскими back_inserter и прочей фигнёй. Шаблоны, всё-таки, очень даже обозримы. > - самое важное: гибкость. Можно нагенерить любую идею. Если потребовалось что-то серьёзное, берём любой лёгкий высокоуровневый язык, и генерируем себе спокойно нормальный Cшный или C++ный код значительно лучше, чем на языке препроцессора или шаблонов. > Короче, препроцессор - это свобода. Свободы в Питоне хоть попой ешь, в результате приходится тестировать всё, что может сломаться и даже не может сломаться.
	Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

	156. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от pripolz on 11-Июл-17, 13:30
	> пара ступеней вложенности Ни разу в жизни не сталкивался. Вообще шаблоны - большая редкость. Применение шаблонов ИМХО обосновано только из соображений производительности. Тогда, когда нельзя использовать указатель на функцию потому, что это запорет оптимизацию в сильно вложенном цикле. Так или иначе, у меня лично есть большие сомнения, превратится ли при таком подходе код в кашу. Ну будет иерархия из нескольких файлов, что такого.
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	157. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от anonymous (??) on 11-Июл-17, 14:01
	>> пара ступеней вложенности > Ни разу в жизни не сталкивался. Вообще шаблоны - большая редкость. В каком чудном мире вы живете? PS. Это же вы где-то в этой теме сказали, что программировали на 100 языках? Можно список из ТОП-30 хотя бы?
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	158. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от pripolz on 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) on 12-Июл-17, 02:25
	Ну почти всё закрыто. Не хватает JavaScript'а, языков семейства ML и Пролога.
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	163. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от anonymous yet another on 12-Июл-17, 08:29
	> Было преувеличение. Если по порядку, то Дневник молодого поэта: "Всю ночь писал стихи о любви. Закрыл тему."
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	160. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от anonymous yet another on 11-Июл-17, 23:06
	> ... а дальше Александреску А вот это уже мешки синтаксического сахара. Так и до диабета недалеко.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	149. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Анонимный Алкоголик (??) on 10-Июл-17, 11:48
	> Если тебе предложат написать такую программу, ты что, откажешься? Не функцию, а программу. > Расстояние между фигурами. Фигур 10 типов. Это задача для неудачников по > твоему? Вы не поняли. Речь была о том, что в языке вам не хватает средства выразить некий метод (функцию) для трёх классов хотя бы. Один при чём. Метод. Предлагать нам за вас разработать и представить к рассмотрению такого рода метод не стоит...
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	118. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Vkni (ok) on 08-Июл-17, 22:28
	> Вот класс - это изначально структура данных + набор методов с ней. > В с++ структура и методы принудительно жёстко связаны. А если я > захочу написать один метод для 3х классов? Haskell, классы типов и т.д. instance Show Double where     show d = ... Проблема в том, что даже с ними хочется большей гибкости. Например, определить два разных вариантов печати числа.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	147. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Анонимный Алкоголик (??) on 10-Июл-17, 11:12
	> А если я захочу написать один метод для 3х классов? :-) Когда захотите, изложите как полагается. Выдающееся может получиться желание. Потому что пока это выглядит довольно бессмысленно. "один метод для 3х классов". Поэтому вряд ли вы сможете таки захотеть...
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	146. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Анонимный Алкоголик (??) on 10-Июл-17, 10:39
	>Вон из профессии, ничтожество. Совершенно верно. Вон. Наплодилось вас, проталкивателей "стилей"... Норовящих пояснить о плохой практике массивов... :-)
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

16. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
Сообщение от Игорь (??) on 07-Июл-17, 13:56
Полезно, спасибо!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
Сообщение от manster (ok) on 07-Июл-17, 15:45
И все таки почему например chromium начинает притормаживать, захлебываться и с трудом возвращать память при открытии ~+10 вкладок.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	40. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–3 +/–
	Сообщение от _ (??) on 07-Июл-17, 18:18
	Потому что по сложности современный браузеры вплотную приблизились к операционным системам (С)  ?
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	46. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–2 +/–
	Сообщение от Аноним (??) on 07-Июл-17, 20:21
	Абсолютная чушь. Вдумайся в значение слова "браузер" (что означает обозреватель) и ты поймешь что даже до офисного редактора браузер не подошел. В офисном редакторе кроме проигрывания медиа можно например редактировать БД.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	48. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от anomymous on 07-Июл-17, 21:17
	Ойййй. Для начала хотелось бы посмотреть на полноценную динамику в "офисном редакторе". С возможностью загрузки кусков текста и перехода к другим документам. А там подумаем.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	63. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–2 +/–
	Сообщение от Аноним (??) on 07-Июл-17, 23:02
	Вы кроме WordPad что-нибудь встречали?
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	49. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Соня (??) on 07-Июл-17, 21:24
	Тем не менее вся эта webня выглядит ужасающе сложно. Даже потрясающе сложно для просмоторщика документов со скриптами. Я бы не смог реализовать весь "стандарт"
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	64. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Аноним (??) on 07-Июл-17, 23:06
	Это для вас лично. Скрипты - это вообще огромный туnой костыль. В целом там ничего сложного, просто объем. Примерно сложного: аллокатор памяти в операционной системе.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	78. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от angra (ok) on 08-Июл-17, 09:01
	Тебя совсем не смущает, что аллокаторы памяти были созданы для многих десятков ОС и справляются с этой задачей студенты одиночки, а вот полноценных браузерных движков меньше десятка за всё время получилось?
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	95. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от Аноним (??) on 08-Июл-17, 17:13
	Столь дилетантская попытка сравнения позорна для технического ресурса. Вы дейтвительно думаете что браузерный движок это сложно? - Это очень объемно, но не сложно.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	159. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+/–
	Сообщение от Соня (??) on 11-Июл-17, 19:19
	Много всего что по отдельности не сложно, но со странным поведением и так далее, да? Типа как скопировать настройки столетнего компьютера где использовали костыли, поверх них ещё костыли, потом ещё костыли для частичной нейтрализации эффекта тех костылей, прикручивали новые вещи разными странными способами, так? Я правильно понял? Но там нет особенно непонятных идей, сложных алгоритмов и всего такого? Вся сложность в этой массе и всех возможных способах её работы, сложной логике получившейся ...получившегося продукта. Все так?
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	51. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	+3 +/–
	Сообщение от Crazy Alex (ok) on 07-Июл-17, 21:36
	Потому что современные "браузеры" - безумная попытка сделать рантайм для GUI-приложений из того, что для этого не предназначено в принципе, причём с десятком одновременно реализованных моделей лайаута и логикой на динамическом языке. Кадавр получился - мама не горюй. То, что это вообще как-то ворочается - чудо само по себе.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	70. "Обзор проблем в коде на C/C++, вызванных неопределённым пове..."	–1 +/–
	Сообщение от manster (ok) on 08-Июл-17, 03:04
	Нет, с пару тройкой вкладок все относительно хорошо :) Проблемы начинаются когда некоторые сайты пытаются искать flash-player для прокрутки рекламы, которого давно нет (отключал явным образом из chromium, до этого тормоза были еще больше) ...
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

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

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