Ниша C++.

Чего вы хотите спросить то?

> Чего вы хотите спросить то?

то что и спросил - почему нельзя считать С++ надстройкой на С, в следующий раз разжевывать не буду

> Что такое «простое подмножество»? Не встречал ранее такого термина.

Ты заявил, что Си сложнее, чем подмножество С++. Вот о том самом подмножестве (которое проще, чем Си) речь и идёт.

А что пруфить-то? Пруфить, что мне действительно на C++ удобнее писать, чем на C?

Удобство - отдельно, сложность - отдельно. Пруфить - то, что действительно можно выделить некое подмножество С++, которое было бы существенно проще, чем Си.

Если же тебе нужен линк на «простое подмножество», то сам его ищи, ибо лично я не помню, чтобы обещал кому-то такой линк или же утверждал, что он существует.

Если пруфлинка не будет, то твои рассуждения насчет подмножеств С++ приравниваем к некомпетентному пердежу (коим и без того переполнены толксы).

почему нельзя считать С++ надстройкой на С

Потому что Страуструпу захотелось в свое время расширить возможности С. В результате на основе С он сделал новый язык, но надстройкой над С плюсы не являются.

> Потому что Страуструпу захотелось в свое время расширить возможности С. В результате на основе С он сделал новый язык, но надстройкой над С плюсы не являются.

адресую вопрос и к вам - почему? вот просто по пунктам - в С++ «поломали» 1., 2., 3., не считая того, что я уже написал

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

вот просто по пунктам - в С++ «поломали» 1., 2., 3.

Да ничего существенного не поломали.

адресую вопрос и к вам - почему?

С++ предполагает объектное, обобщенное и (в какой-то степени) мета- программирование, в то время как Си предполагает (в основном) процедурное программировнание. Это принципиальное, качественное отличие.

С++ можно было бы рассматривать как надстройку над Си, если бы писали на нем, как на «Си с фенечками».

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

унитаз - часть квартиры, да :)

С++ можно было бы рассматривать как надстройку над Си, если бы писали на нем, как на «Си с фенечками».

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

Ты заявил, что Си сложнее, чем подмножество С++. Вот о том самом подмножестве (которое проще, чем Си) речь и идёт.

Язык, который «проще, чем Си», вовсе необязательно является «простым». Ну, разве что Си является «простым», но это как бы не очевидно.

Удобство - отдельно, сложность - отдельно.

Мы не договаривались с тобой о терминологии, я говорил про удобство, когда писал «сложнее». Ты легко мог бы это понять, если бы обратил внимание на этот пост, вместо того, чтобы пытаться меня троллить.

Пруфить - то, что действительно можно выделить некое подмножество С++, которое было бы существенно проще, чем Си.

Теперь уже и «существенно».

Если пруфлинка не будет, то твои рассуждения насчет подмножеств С++ приравниваем к некомпетентному пердежу (коим и без того переполнены толксы).

Бла-бла-бла. Ты прочитал то, что хотел прочитать, и теперь требуешь ссылку на авторитетный источник (я для тебя, очевидно, не авторитет, что в общем-то взаимно), который бы подтверждал то, что ты там себе напридумывал, прочитав мои «рассуждения». Приравнивать свои фантазии, а также мой пост, который их вызвал, можешь к чему угодно, мне все равно.

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

> многие так и пишут

Они пишут не на С++, они пишут на «Си с фенечками».

унитаз - часть квартиры, да :)

Си - часть С++, да.

> включая ранее упомянутое «сложнее», которое я употребил в значении «удобнее»

В таком случае, вопрос закрыт.

> Ну, разве что Си является «простым», но это как бы не очевидно.

Не является, к сожалению.

> Си - часть С++, да

Да и то не полностью.

примеры будут?

Какие примеры тебе нужны? То, что в плюсах появился «язык времени компиляции» — шаблоны, уже позволяет говорить о том, что плюсы и няшная сишка отличаются друг от друга чрезвычайно сильно. Введение и развитие шаблонов отодвинуло C++ от C очень далеко, и никакими сишными макросами ты шаблоны не заменишь.

только без придирок кключевым словам

Вопрос не в появлении новых ключевых слов, как таковых, а в возможностях, привносимых ими в язык. Взять, хотя бы, ту-же идиому владения ресурсом — RAII. На C ты подобное если и реализуешь, то через горы макрокостылей. А есть ещё и другие идиомы, принадлежащие плюсам, которые на голом C фиг реализуешь.

без ... необходимости приведения типа указателя

Что? Ужесточение системы типизации ты не считаешь за значительное изменение языка, отдаляющее его от plain C?

И вообще...

> в С++ «поломали» 1., 2., 3.

К большому сожалению, в C++ «поломали» не так уж и много из C. Что и позволяет многим до сих пор писать на плюсах в С-шном стиле. А вот добавлено было очень многое. Читай «Дизайн и эволюция C++» Страуструпа, там всё по шагам описано.

Расширенный С — это Cyclone. По остальному уже весьма доходчиво объяснил тов. Manhunt.

>Я прав?

Нет. Единственная ниша C++ - бэкенд для Qt

> идиомы, принадлежащие плюсам, которые на голом C фиг реализуешь

Введение и развитие шаблонов отодвинуло C++ от C очень далеко, и никакими сишными макросами ты шаблоны не заменишь.

значительное изменение языка, отдаляющее его от plain C

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

Расширенный С — это Cyclone.

struct List<`a::B,`r::R,`q::Q>{ 
    : RESTRICTED >= aquals(`a), RESTRICTED >= `q
    `a hd; 
    struct List<`a,`r,`q> *@aqual(`q) `r tl;
  };
  typedef struct List<`a,`r,`q> *@aqual(`q) `r list_t<`a,`r,`q>;

угу, С как он есть

> Ниша C++.
Ниша C++ - крузисы, старкрафты, майи, тридеэс максы и т.д.

> Единственная ниша C++ - бэкенд для Qt

Не так уж и хорош этот ваш Qt...

> как бы никто и не говорил про совместимость сверху-вниз

Угу, разговор шёл про то, что C++ zвляется «улучшенным C». А он им не является, хоть и включает в себя некоторое подмножество С. Плюсы — это более другой язык.

С проще, С++ сложнее. Но некоторые вещи на С++ писать проще, чем на С.

> Единственная ниша C++ - бэкенд для Qt

Не так уж и хорош этот ваш Qt...

От этого Qt не перестаёт быть единчтвенной нишей для C++

> От этого Qt не перестаёт быть единчтвенной нишей для C++

несомненно - все программы уже давно пишут исключительно на Java, tcl/tk, C#, Python и CL, ну и С еще - хотя он безнадежно устарел

Наследование - очень удобная штука. Решает многие проблемы.

> С еще - хотя он безнадежно устарел

Фига-се заявочки, в контексте того что интерпретаторы «Java, tcl/tk, C#, Python и CL» [...и еще дохренища] написаны на этом самом С и вряд ли ближайшее время что-то в этом плане поменяется. С прочно занял нишу ассемблера (да он и есть по определению создателя кроссплатформенный ассемблер).

> Фига-се заявочки

man ирония

Наследование - очень удобная штука. Решает многие проблемы.

Смотря какое.

Наследование от интерфейса (будем называть этим словом полностью абстрактные классы) - удобная и нужная штука.

Наследование реализации проблемы не решает, а создаёт.

> Наследование от интерфейса (будем называть этим словом полностью абстрактные классы) - удобная и нужная штука.

Да.

Наследование реализации проблемы не решает, а создаёт.

Таки создаёт?

Давно компиляторы стали низкоуровневыми программами? А ниша у С++ очень даже обширна, потому что альтернативы часто не жизнеспособны или завязаны на конкретного vendor'а. Однако радоваться этому не стоит, это говорит о некотором застое.

Таки создаёт?

таки создаёт

>Они пишут не на С++, они пишут на «Си с фенечками».

А это подмножество С++.

такой низкоуровневый, что прям прерываниями запахло и портами набздело трохи :)

>Похоже она существует

С++/Qt4 все остальное для гуя -от лукавого

> таки создаёт

обоснуй

обоснуй

http://lambda-the-ultimate.org/node/2103

обоснуй

http://brainslugs.blogspot.com/2007/08/inheritance-subtyping.html

это если по предыдущей ссылке букв слишком много. смотри также идиому хрупкого базового класса (fragile base class)

> это если по предыдущей ссылке букв слишком много. смотри также идиому хрупкого базового класса (fragile base class)

Как сказали в комментариях: «Если забивать гвозди острым концом молотка, то легко отбить пальцы. Однако это не повод для того чтобы объявлять молоток сложным и опасным механизмом. »

Нет.

Как сказали в комментариях

с той же аргументацией можно писать большие проекты на ассемблере: кто не осилил, тот лох

детский сад

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

Ой други, полнейший ОФФТОПИК, заинсталлил надысь VC++6 под Win XP - это просто счастье - кушает 2(!)Мб(!). Вот Вам и C# c Жабой

> с той же аргументацией можно писать большие проекты на ассемблере: кто не осилил, тот лох

демагогия. :(

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

перечитайте комментарии по своей ссылке ещё раз.

перечитайте комментарии по своей ссылке ещё раз

перечитал. последний оставленный там (автором) комментарий вполне согласуется с моей позицией

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

впрочем, для меня достаточно уже того, что при наследовании реализации в C++ реально выполняется два действия: наследование интерфейса (отношение является) и, собственно, наследование реализации (отношение реализовано посредством) - которые далеко не всегда должны выполнятся одновременно. так, комплексные числа реализуются посредством вещественных, но при этом любое вещественное является комплексным - но не наоборот! единственная же возможность честного разделения этих двух проектных операций в C++ - использование чистого наследования реализации (private-наследование) - которое, во-первых, в подавляющем большинстве случаев может быть заменено агрегацией; и которое, во вторых, оставляет реализацию инкапсулированной между уровнями иерархии

такого комментария достаточно для того, чтобы не обвинять меня в демагогии? или нужны ещё аргументы?

Тем, кто считает что Си проще С++: ассемблер еще проще, а еще проще в машинных кодах сразу.

ниша c++ там, где нужна достаточно высокая вычислительная производительность с возможностью использовать абстракции более высокго уровня (ведь, все таки, c++ дает возможность создавать и оперировать объектной моделью), что в ряде случаев упрощает построение логики. Пляс достаточно большой багаж библиотек (уже упомянутые boost, Qt, etc.).

то-то llvm компилируется по три часа, да пишите на c++

C и C++ разные языки, ИМХО.

> то-то llvm компилируется по три часа

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

> Таки создаёт?

Можешь не сомневаться.