Развейте мои сомнения: упростится ли программирование при переходе от C к C++?

[Cfon]

короче я за юнит-тесты в стандартной библиотеке С++
а то что то не въеду как подлючить CPPUnit или Google Test Framework

Добавлено 19.07.16, 13:46
вангую в С++17 добавят таки этот тулз

Добавлено 19.07.16, 13:47
а то ассерты по коду раскидывать надоедло

[DarkEld3r]

Цитата D_KEY @ 19.07.16, 13:30

Даже если они пересекаются, это не отменяет того факта, что простой софт легче развивать и поддерживать.

Звучит логично... в общем случае. Вот только, с одной стороны, поддерживать в согласованном состоянии всё равно придётся несколько "разных мест": компилятор/библиотеку и систему сборки (она у раста "стандартная"). Полностью вынести всё в отдельную тулзу/библиотеку не получится.
С другой стороны, тест - это просто отдельный атрибут. Очень сомневаюсь, что их обработка по всему компилятору размазана. То есть, не считаю, что цена поддержки хоть сколь-нибудь заметно увеличивается.

Цитата D_KEY @ 19.07.16, 13:30

Тогда зачем это защищать?

Потому что в отдельном конкретном случае я не вижу проблем.

[D_KEY]

Цитата DarkEld3r @ 19.07.16, 13:57

Вот только, с одной стороны, поддерживать в согласованном состоянии всё равно придётся несколько "разных мест": компилятор/библиотеку и систему сборки (она у раста "стандартная").

Зачем? Почему плюсовые тулзы справляются без такой поддержки?

Цитата

Очень сомневаюсь, что их обработка по всему компилятору размазана. То есть, не считаю, что цена поддержки хоть сколь-нибудь заметно увеличивается.

Не вижу никакого смысла превращать компилятор в какой-то комбайн, занимающийся помимо своих функций еще и тестированием.

Цитата

Цитата D_KEY @ 19.07.16, 13:30

Тогда зачем это защищать?

Потому что в отдельном конкретном случае я не вижу проблем.

Эм. На мой взгляд отсутствие проблем не является достаточным аргументом в пользу чего-либо, поскольку нужны достоинства.

[OpenGL]

Цитата D_KEY @ 19.07.16, 13:30

Даже если они пересекаются, это не отменяет того факта, что простой софт легче развивать и поддерживать.

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

Цитата D_KEY @ 19.07.16, 13:30

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

Почему, если это одно целое? Ну считай #[test] из раста частью стандартной библиотеки, а опцию компилятора --test - возможностью, подключаемой плагином, если твой перфекционизм не даёт тебе покоя - в чём проблема?

[Flex Ferrum]

Цитата Исмаил Прокопенко @ 15.07.16, 23:25

Взял в руки книжку В.В. Подбельского «язык C++» 2005 года выпуска (знаю, что есть Страуструп, Липман и др. книжки посвежее и по «забористей» - но говорю же: «с самого нуля» решил начать, а в предисловии к книжке как раз написано было, что она для тех, кто изучает C++ “с нуля”) и стал читать. Попутно заглядывая в гугл.

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

Цитата Исмаил Прокопенко @ 15.07.16, 23:25

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

Предлагаю такую аналогию. Вот берём ребёнка-первоклассника. Он хорошо говорит на своём языке, может объяснить, спросить, общаться и т. п. Вопрос: ему надо было для этого изучать институтский курс русского языка и литературы? Он говорит как-то хуже, чем некий профессор-лингвист, который виртуозно использует метафоры, разные обороты, и прочие хитрожопые языковые конструкции? Нет конечно. Так же и с языком программирования. Для написания процентов 70-ти программ потребуется относительно небольшое подмножество языка. Потому как большая часть программ - это что-то конкретное, решение вполне конкретных задач с использованием готовых решений. Безо всяких выкрутасов. И, в общем, если текст программы пишет не новичок и с рассчётом на последующую поддержку, то разобраться в такой программе будет несложно. При условии, конечно, что известен инструментарий. В смысле, библиотеки, которые использовались в процессе разработки. А все эти "многократные перегрузки", сложные наследования, зубодробильные шаблоны и всё прочее в обычной (промышленной) разработке используется не то, чтобы часто. Потому как задача - доехать, а не шашечки. И понимание таких конструкций придёт с опытом. Загружать себе в голову сразу все возможности языка - это всё равно, что грузить того школьника-первоклашку институтским курсом РЯ. Можно попробовать, но выйдет хрень.

Цитата Исмаил Прокопенко @ 15.07.16, 23:25

2) А если сам пишешь программу, то поставленную задачу можно решить на C++ реально проще и быстрей, чем на СИ? Если да, то в каких задачах проявляется преимущество C++? И за счет чего облегчается и ускоряется написание программы?

Всё зависит от задачи, на самом деле. Если программа уровня Hello World, "найти максимум в векторе" и т. п. - будет это C или C++ - монопенисуально. А вот что-то более сложное, где нужно управлять ресурсами, где между разными частями программы предполагается сложное взаимодействие и т. п. - там... Да, может дать выигрыш. Но для написания таких программ ещё надо и проектировать уметь. Хотя бы на начальном уровне. Чтобы ООП - это была не просто аббревиатура, выжженная в мозгу, а реальное понимание: зачем это нужно и для чего. Так то, на самом деле, C++ - мультипарадигменный язык, и использование ООП не навязывает. Можно хоть в процедурном стиле писать. Но соломки, где надо, подложит. И готовые решения предложит, чтобы велосипеды не изобретать. В целом, на С++ сложную программу разработать, наверное, таки легче, чем на С.

Цитата Исмаил Прокопенко @ 15.07.16, 23:25

3) В каких-нибудь задачах (и в каких конкретно) вам приходилось в классе использовать сразу почти все ОО-средства С++ «по полной программе»?

Да. Приходилось. Задачи уровня разработки фреймворков. То есть библиотек, на основе которых будут разрабатываться прикладные программы. Вот там - да. Но такого рода задачи - не уровень новичка. И даже не уровень среднего профессионала.

[D_KEY]

Цитата OpenGL @ 19.07.16, 14:16

Цитата D_KEY @ 19.07.16, 13:30

Даже если они пересекаются, это не отменяет того факта, что простой софт легче развивать и поддерживать.

По-моему "компилятор" и "простой софт" понятия взаимоисключающие.

И поэтому нужно напихать туда еще больше?

Цитата

упростив при этом жизнь пользователей.

Этого можно достичь и не трогая компилятор.

Цитата

Цитата D_KEY @ 19.07.16, 13:30

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

Почему, если это одно целое?

Это не одно целое

[DarkEld3r]

Цитата D_KEY @ 19.07.16, 14:12

Зачем? Почему плюсовые тулзы справляются без такой поддержки?

Возможно, потому что (таких) плюсовых тулзов вообще нет? Нет стандартных тестов ни в библиотеке ни в языке. Как и нет стандартной "системы сборки", а имеющиеся монстры типа CMake как раз комбайнами и вынуждены являться.

Цитата D_KEY @ 19.07.16, 14:12

Эм. На мой взгляд отсутствие проблем не является достаточным аргументом в пользу чего-либо, поскольку нужны достоинства.

В этом конкретном случае достоинства есть: или приходится "раньше времени" стабилизировать атрибуты заодно накапливая груз потенциального легаси или запихнуть тесты в язык.

Цитата D_KEY @ 19.07.16, 14:12

Не вижу никакого смысла превращать компилятор в какой-то комбайн, занимающийся помимо своих функций еще и тестированием.

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

[OpenGL]

Цитата D_KEY @ 19.07.16, 15:07

И поэтому нужно напихать туда еще больше?

Нет, не поэтому.

Цитата D_KEY @ 19.07.16, 15:07

Это не одно целое

Библиотека идёт вместе с компилятором? Да. Всё, значит одно целое - разделять их нет смысла.
Кроме того, в некоторых языках (в С++ в частности) сам компилятор вполне себе обращается к стандартной библиотеке, т.е. ты её не заменишь без внесения изменений в компилятор.

[Исмаил Прокопенко]

Flex Ferrum
Спасибо за развернутый ответ.
А как Вы считаете, за сколько реально освоить С++ чтобы отказаться от СИ-стиля и уверенно кодить в С++ - стиле? И освоить с++ настолько, что не составило бы труда понять работу ЛЮБОЙ С++ программы.

И ещё.
Хочу Вас, как гуру С++ спросить: что в С++ САМОЕ СЛОЖНОЕ именно для Вас?
Чего Вам не хватает в С++?
И что, с Вашей точки зрения, в С++ реализовано откровенно плохо?

[Cfon]

Исмаил Прокопенко чувак много времени надо много!

!

Давайте без оскорблений и взаимного неуважения, хорошо?

<del>

Сообщение отредактировано: OpenGL - 19.07.16, 16:16

[D_KEY]

Цитата DarkEld3r @ 19.07.16, 15:40

Цитата D_KEY @ 19.07.16, 14:12

Зачем? Почему плюсовые тулзы справляются без такой поддержки?

Возможно, потому что (таких) плюсовых тулзов вообще нет?

Эм. Boost.Test, google test, CxxTest и т.д. и т.п. Выбирай по вкусу.

[DarkEld3r]

Цитата Исмаил Прокопенко @ 19.07.16, 15:49

И освоить с++ настолько, что не составило бы труда понять работу ЛЮБОЙ С++ программы.

Надеюсь ты понимаешь, что вопрос провокационный и отношение соответствующее будет?
Давай с другой стороны зайдём: говоришь, что С простой и разобраться легко. Ок, загляни в сорцы какого-нибудь большого проекта. Да хотя бы ядра линукса для гарантированного эффекта. Всё понятно? А ведь ещё можно специально запутанно писать, погляди на досуге - http://www.ioccc.org/. А ведь "простой С".

[D_KEY]

Цитата DarkEld3r @ 19.07.16, 15:40

Как и нет стандартной "системы сборки"

Да, но существующие системы сборки обходятся без поддержки компилятора.

Добавлено 19.07.16, 16:15

Цитата OpenGL @ 19.07.16, 15:45

Библиотека идёт вместе с компилятором? Да.

Но ты можешь взять другую библиотеку.

Цитата

Всё, значит одно целое - разделять их нет смысла.

С точки зрения дизайна языка и его реализации - есть.

Цитата

Кроме того, в некоторых языках (в С++ в частности) сам компилятор вполне себе обращается к стандартной библиотеке, т.е. ты её не заменишь без внесения изменений в компилятор.

Заменишь. Я правда давно таким не занимался. Но раньше можно было прикрутить сторонние реализации.

[OpenGL]

Цитата D_KEY @ 19.07.16, 16:12

Заменишь. Я правда давно таким не занимался. Но раньше можно было прикрутить сторонние реализации.

Как прикрутить, например, сторонний initializer_list, если ты его аналог даже написать не сможешь?
Да и в любом случае - замена стандартной библиотеки языка это возможность не языка, а его конкретной реализации.

[D_KEY]

Цитата OpenGL @ 19.07.16, 16:18

Как прикрутить, например, сторонний initializer_list, если ты его аналог даже написать не сможешь?

Это, кстати, хороший вопрос. По сути, это часть языка, а не стандартной библиотеки.