Для чего нужен C++?

Уважаемые, я учу C++ уже 7 лет, зачем нужен C++?

1

Сообщение от _stanislav я устал изучать метапрограммирование, на счет проще могу спорить.

А с обобщённым разобрался? Что касается "проще", то на плюсах много чего проще выразить и безопаснее. А сам язык лесистый, - да.

0

Сообщение от Renji (сарказм on) Зато, в Си можно скомпилировать int twoTimesTwo="стеариновая свечка";. Причем, не факт что с варнингом (например, компилятор видит "я этот файл уже компилировал" и просто пропускает).

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

Язык С здесь ни при чем. Это лишь глюки вашего компилятора.

0

Сообщение от TheCalligrapher Это говорит лишь о том, что ваш компилятор работает в "дырявом" режиме, предназначенном лишь для компиляции старинного "гамнокода".

Стандартный пингвиний gcc с настройками по умолчанию. Сейчас проверил на rextester.com, в стандартной для Форточек Студии, со стандартными настройками, ровно та же фигня. Можно конечно взять нестандартный компилятор, накрутить крутых настроек и сломать в итоге даже полностью соответствующий стандартам код. Только ведь разрабы потом ответят "сам дурак!".

0

Сообщение от IGPIGP А с обобщённым разобрался?

нет конечно, я TMP начал учить что бы повсеместно к обобщенному привыкнуть

Добавлено через 1 минуту

Сообщение от AndryS1 А по вашему проще писать 10, а то и 100 разных функций, нежели использовать шаблоны?

по моему шаблоны это крутая штука

0

Сообщение от _stanislav нет конечно, я TMP начал учить что бы повсеместно к обобщенному привыкнуть

TMP сложнее (имхо) чем GP (обобщённое). GP обобщает ран-тайм алгоритмы на допустимых типах. Причём, на ряде допустимых типов, приходится отказываться от обобщения путём специализации или перегрузки, в пользу более эффективных решений. А TMP ориентировано на вычисления времени компиляции как таковые. Одни списки типов чего стоят... Как по мне, - очень сложная тема по сравнению с GP. Поэтому и спросил. Впрочем, и то и другое можно учить всю жизнь.

1

Сообщение от Renji Стандартный пингвиний gcc с настройками по умолчанию. Сейчас проверил на rextester.com, в стандартной для Форточек Студии, со стандартными настройками, ровно та же фигня. Можно конечно взять нестандартный компилятор, накрутить крутых настроек и сломать в итоге даже полностью соответствующий стандартам код.

Вы так усердно напираете на слово "стандартный" в первом предложении, что у читателя может сложиться впечатление, что все этот имеет какое-то отношение к стандарту языка и что гипотетический компилятор, о котором вы говорите во втором предложении (и который наотрез откажется компилировать такой код) является "нестандартным" )))

Как уже сто раз говорилось: выдача стандартного диагностического сообщения всегда является отказом компилятора компилировать ваш код. Является ли это сообщение "warning" это или "error" - никакого значения не имеет. Вы не смогли скомпилировать вашу "стеариновую свечку" ни в GCC, ни в Студии, о чем вам и тот, и другой компилятор ясно сказали. А ваши "результаты компиляции", которые вы якобы "получили" в результате - это просто мусор, который компилятор "забыл" убрать за собой.

---

Кстати Pelles C в настройках по умолчанию

0

Сообщение от TheCalligrapher Как уже сто раз говорилось: выдача стандартного диагностического сообщения всегда является отказом компилятора компилировать ваш код.

Варнинг может вылететь и на одинокий int x; (unused variable);. Но этот варнинг с нашей теорией не согласуется, так что мы быстренько переименуем его в нестандартный.

Как уже говорилось, ранее скомпилированные файлы при повторной компиляции спокойно пропускаются. Поэтому, открываем QtCreator, тыкаем ctrl+B два раза, варнинг волшебным образом исчезает. Можно сколько угодно кричать "против стандарта!", но популярные компиляторы приведенную конструкцию проглатывают. Причем, в зависимости от обстоятельств - абсолютно незаметно для программиста. Тогда как в плюсах это именно что не компилируется ни под каким соусом.

0

Сообщение от Renji Варнинг может вылететь и на одинокий int x; (unused variable);. Но этот варнинг с нашей теорией не согласуется, так что мы быстренько переименуем его в нестандартный.

Почти верно (см. ниже)

Стандартными называются только те диагностические сообщения, которые требуются стандартом языка (потому что указывают но код, который является ошибочным). Это, например, ваше int twoTimesTwo = "стеариновая свечка";

А варнинг "на одинокий int x; (unused variable);" не требуется стандартом языка. Этот код не является ошибочным кодом. Поэтому и любые варнинги на этот код являются лишь отсебятиной компилятора. "Стандартными" их никто никогда не назвал, поэтому и переименовывать ничего не нужно. (Это ваш первый ляп, обосновывающий мое "почти")

Никаких "теорий" тут нет, есть обыкновенные и общеизвестные букварные азы языка С. С ними никто не спорит. (Это ваш второй ляп, обосновывающий мое "почти")

Вопреки всем надеждам на обратное, жизнь однозначно показывает, что пропускать изучение этих азов не разрешается: страдающий подобными "пропусками" индивидуум никогда уже сможет ничего понять в программировании на С, какими бы титаническими ни были усилия наставников. Что в данном случае и ярко иллюстрируется, например, неспособностью врубиться в фундаментальную разницу между "одиноким int x; (unused variable);" и int twoTimesTwo = "стеариновая свечка";.

В такой ситуации возможно только полное "выжигание напалмом" всего багажа бесполезных мусорознаний из мозга индивидуума до состояния "tabula rasa" и начало с самого начала, с нуля, с элементарных азов. А иначе толку не будет.

0

Сообщение от TheCalligrapher Никаких "теорий" тут нет, есть обыкновенные и общеизвестные букварные азы языка С. С ними никто не спорит. (Это ваш второй ляп, обосновывающий мое "почти")

Если верить букварным истинам, то нельзя записать в union значение double и тут же прочитать его обратно как int. Мануал gcc прямо это разрешает с комментарием "сишники на стандарт все равно клали". "The practice of reading from a different union member than the one most recently written to (called “type-punning”) is common. Even with -fstrict-aliasing, type-punning is allowed, provided the memory is accessed through the union type.".

Если верить букварным истинам, то нельзя создавать flexible array member через CHAR Name[1], не говоря уже о том чтобы пихать потом такие конструкции в C++ код. В WinAPI структурах такое повсеместно (пример), C++ код с этими библиотеками вполне взаимодействует.

Поэтому, это именно что теории. В практических компиляторах увы, имеют место вполне намеренные отступления от стандарта. А отнюдь не "там какой-то варнинг выскакивает. Иногда. Значит, это неправильный код".

0

Сообщение от Renji flexible array member через CHAR Name[1]

Это не flexible array member.
Это затычка, которая позволяет компилировать этот код C++-компилятором без поддержки поддержки C'шных flexible array member.

Сообщение от Renji то нельзя записать в union значение double и тут же прочитать его обратно как int.

Приведение указателя базового типа

Сообщение от Renji Стандартный пингвиний gcc с настройками по умолчанию.

Там много чего можно с настройками по-умолчанию. Там все гнутые расширения включены.
Добавляем -pedantic-errors и получаем error вместо warning.
Но, как уже написали выше, даже warning в данном случае является ошибкой,
т.е. такой код не соответствует спецификации, на этом точка.
Говорить в этом случае "что так можна в C" - нельзя.

0

Сообщение от Renji Если верить букварным истинам, то нельзя записать в union значение double и тут же прочитать его обратно как int.

Кто вам такое сказал? Стандарт языка С явным образом это разрешает, предупреждая вас при этом о возможности наткнуться на trap representation.

(Вот видите, какую кашу представляют из себя ваши домыслы о языке С. Ну нельзя же так подставляться...)

Сообщение от Renji Мануал gcc прямо это разрешает с комментарием "сишники на стандарт все равно клали". "The practice of reading from a different union member than the one most recently written to (called “type-punning”) is common. Even with -fstrict-aliasing, type-punning is allowed, provided the memory is accessed through the union type.".

Комментарий "сишники на стандарт все равно клали" - это целиком и полностью продукт вашего воображения. Он вам, как вы сами уже поняли, в данном случае померещился. Ничего подобного в процитированном вами кусочке даже отдаленно нет и не подразумевается. Именно потому, что такое использование union разрешено стандартом языка, оно не нарушат правил strict aliasing. Именно об этом вам говорит процитированный вами пассаж.

Вот именно таки миражи вызываются отсутствием в этом воображении все тех же элементарных азов языка. Это первый "мираж", которым вы сами себя обманули.

Второй очевидный "мираж": это непонимание фундаментальной разницы между грубыми ошибками уровня исходного кода и кодом, который формально корректен, но, возможно, не определен. Это совершенно разные вещи. int twoTimesTwo = "стеариновая свечка" - это грубая ошибка. Это сразу однозначно запрещено в языке С. Компилятор имеет право разрешить это, но любой компилятор, который вдруг решится разрешить что-то подобное, обязан сопроводить этот код диагностическим сообщением. Что GCC исправно и делает. Никаких отклонений от требований стандарта тут нет.

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

Сообщение от Renji Поэтому, это именно что теории.

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

Сообщение от Renji В практических компиляторах увы, имеют место вполне намеренные отступления от стандарта.

Опять наивная чушь, вызванная непониманием азов. Расширения компилятора не являются отступлениями от стандарта. Никто их никогда так не называл. Стандарт языка открытым текстом разрешает компиляторам иметь расширения.

Сообщение от Renji А отнюдь не "там какой-то варнинг выскакивает. Иногда. Значит, это неправильный код".

Это не боле чем попытка нагнать демагогического дыму.

Речь идет о волне конкретном понимании того, что int twoTimesTwo = "стеариновая свечка" - неправильный код. Это не обсуждается. Если какому-то программисту понадобится воспользоваться гарантиями компилятора GCC на тему преобразования указательных типов в целые, он, разумеется, напишет int twoTimesTwo = (int) "стеариновая свечка" или int twoTimesTwo = (intptr_t) "стеариновая свечка" или еще как (идея, я думаю, ясна).

А за попытки делать int twoTimesTwo = "стеариновая свечка" он тут же получит пинок под зад и больше до программирования допущен не будет. Как минимум пока не пройдет вышеупомянутый курс "выжигания напалмом до состояния tabula rasa" и обучения с нуля.

0

Сообщение от Croessmah Это затычка, которая позволяет компилировать этот код C++-компилятором без поддержки поддержки C'шных flexible array member.

Этот код будет явно или неявно содержать обращение к несуществующему элементу name[1]. На сколько я помню, стандарт C++ такого не допускает.

Сообщение от Croessmah Приведение указателя базового типа

В итоге все же легализовали? Тогда с этим пунктом пардон.

Сообщение от TheCalligrapher Опять наивная чушь, вызванная непониманием азов. Расширения компилятора не являются отступлениями от стандарта. Никто их никогда так не называл. Стандарт языка открытым текстом разрешает компиляторам иметь расширения.

Да хоть горшком назови. Речь о том что реализованный в наиболее популярных компиляторах, а не существующий исключительно на бумаге Си допускает черт знает что. И несмотря на все "Неправильно! Безграмотно!" никто чего-то поддержку этого безобразия не убирает. Вероятно, потому что IRL сишники продолжают лепить такие конструкции и никто их за это ни откуда пока не выгнал.

0

Сообщение от Renji Речь о том что реализованный в наиболее популярных компиляторах, а не существующий исключительно на бумаге Си допускает черт знает что.

Как говорится, как об стенку горох...

Остается лишь повторить: разбираться в языке С можно только изначально не пропустив изучение азов. Если упустил, то потом будет поздно: сколько потом ни пытайся вдалбливать элементарные аксиомы, все равно получится лишь "на колу мочало, начинай сначала".

0

Сообщение от TheCalligrapher Остается лишь повторить: разбираться в языке С можно только изначально не пропустив изучение азов.

Это я после изучения азов. Ну там, "безымянные аргументы функции в callback. Ой, а их нету. Учимся танцам с бубном вокруг (void)param". "Полиморфизм это просто! Делаем каламбур типизации в инициализации сокета через bind". "void function(); function(1,2,3,4). Учимся с выражением говорить "сам дурак", вместо того чтобы запретить наконец компиляцию этой хрени".

Как по мне, так в простоте и элегантности языка разобрался на все сто десять процентов.

0

Renji, стандарт c++ не запрещает обращаться за пределы массива. Результат такого обращения - неопределенное поведение. Если реализация гарантирует коррекность, то никаких проблем.

Приведенные Вами примеры в сообщении выше какие-то стремные и непонятно в чем проблемы.

0

Сообщение от _stanislav я TMP начал учить что бы повсеместно к обобщенному привыкнуть

_stanislav, лучше наоборот. Мета код уже на константных выражениях можно писать. Но и шаблонный подход нужно представлять, конечно. Но может статься, что писать какую-то раскрутку для практики и не каждый год придётся. А GP открывает путь к тёмно-мощной стороне. Там целые контейнеры силы, алгоритмы заклинаний и итераторы. Только так можно овладеть световым кьютом, например. Да - +фреймворк, да, - +IDE. Но это уже два плюса. Инженерия и практика дадут не только знания и умения. Можно полезную программку для себя накатать и получить плюс к самоуважению)
Тут мужики много полезного для новичков рассказывают... Это нужно. Пусть слабонервные сразу умрут или отвянут. Новички должны иметь железные Я. Мощные и несгибаемые Эго, в смысле. Ты молод и у тебя Эго не согнёшь, я думаю. А это главное. Остальное приложится. К той или иной стороне.

1

Сообщение от Croessmah Renji, стандарт c++ не запрещает обращаться за пределы массива. Результат такого обращения - неопределенное поведение. Если реализация гарантирует коррекность, то никаких проблем.

Так все же неопределенное поведение или никаких проблем? Память за пределами name несомненно доступна для чтения. Но если с точки зрения стандарта name[1]=0 это UB, то при оптимизации кода может получиться фигня. По крайней мере, формально. Так то понятно что компилятор подобные костылики учитывает.

Сообщение от Croessmah Приведенные Вами примеры в сообщении выше какие-то стремные и непонятно в чем проблемы.

Сокеты:
Типа, давайте сначала поломаем через колено систему контроля типов, впихнув явное преобразование указателей. А потом конечно сделаем трехкратную проверку то нам передали или не то (тип аргумента кодируется первыми двумя байтами addr, плюс проверяем что в функцию ушло sockaddr*, плюс проверяем размер объекта переданный третьим аргументом).

void function() в C11 волшебным образом превращается в void function(...). А void function(){} еще более удивительным образом никуда не превращается. Принцип наименьшего удивления? Грабли на ровном месте? Не, не слышали. Главное, совместимость с кодом 1347 года, в котором ну никак нельзя просто поменять все () на (...). ("An identifier list declares only the identifiers of the parameters of the function. An empty list in a function declarator that is part of a definition of that function specifies that the function has no parameters. The empty list in a function declarator that is not part of a definition of that function specifies that no information about the number or types of the parameters is supplied.").

Ну и проблема с безымянными параметрами на этом фоне это конечно мелочь.

0

Сообщение от Renji Так все же неопределенное поведение или никаких проблем?

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

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

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

например, стандарт говорит:
"если вы выйдете из летящего самолета без парашюта, то поведение не определено"

и вроде бы тут всё просто.
действительно, по статистике, когда из летящего самолета неправильно выходят,
смертность практически 100%.

конечно это не значит,
что выйдя из самолета без парашюта ты обязательно разобъёшься.
или что у тебя вообще будут какие то проблемы.

может быть самолет летел низко, а под ним было море.
или может быть это вообще учебный самолет-тренажор,
и весь полет происходил только в виртуальной реальности.

я хочу подчеркнуть мысль,
которую всякого рода зануды-буквоеды почему-то не осиливают понять:

поведение не определенно,
потому что нет данных о конкретике конкретных ситуаций.

поведение не определенно в общем случае.

в каком-то очень конкретном случае
поведение становится вполне себе определенным и ожидаемым.
даже если в общем случае стандарт определяет ситуацию как UB.

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

например, ты знаешь что компилятор Visual Studio корректно обрабатывает некоторый кейс.
ты у себя в коде с помощью каких нибудь макросов препроцессора пофиксил,
и использовал специфичное для компилятора решение.

почему бы и нет?
именно так поступают разработчики boost.

со стороны подумаешь: UB на UB, UB погоняет.
но на практике работает на любой кофеварке,
если только туда завезли с++.

Добавлено через 1 минуту

Сообщение от Renji //уродливый костылик для подавления варнинга unused parameter ‘unusedParameter’

а как ещё ты предлагаешь его подавить?

0

Сообщение от hoggy нужно понимать, что на самом деле стандарт имеет ввиду под словом "неопределенное". стандарт описывает не какую то конкретную реализацию языка, а некоторый абстрактную модель, которая в теории должна подходить всем.

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

Сообщение от hoggy а как ещё ты предлагаешь его подавить?

В смысле, как?

0

Сообщение от Renji Это уже "неуточняемое поведение". Тут да, как в реализации сделают, так и будет.

не нужно путать UB и US

UB: мы не знаем, что произойдёт, но скорее всего ничего хорошего.

US: не известно как это реализовано в конкретном компиляторе,
но все будет хорошо

пример UB: выход за пределы диапазона массива
пример US: порядок вычислений аргументов функций не определен

Сообщение от Renji void test(int )//функция принимает число для совместимости сигнатур, но не использует его

тогда уж лучше писать
а то не понятно, к чему этот инт вообще относится.

хотя лично я всё равно предпочитаю (void) arg;,
потому что это удобнее.
(более копипаста-ориентированное).

когда разработка ещё только в процессе,
некоторые аргументы получаются временно не используемыми.

для них я методом копипаста делаю кучку (void) arg;,
и по мере доработки реализации удаляю ненужные маркеры из кода.

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

0