а чем все-таки отличаются С и С++?

Почему в стиле С? Если инструкции будут в одном классе, а функции, обрабатывающие их в другом? Все будет в двух классах. Чем не ООП?

 

Есть умные люди, они придумали нам парадигмы программирования - обобщенное программирование, контрактное программирование, etc.
Есть умные люди которые систематизировали нам паттерны программирования.
Много есть умных людей.
А еще есть толпа идиотов, которые всё не осилили, но считают себя умнее всех, и задают тут вопросы "чем Си отличается от С++". Да осиль сначала хоть один язык, а потом спрашивай чем он отличается от другого. Толку таким нубам рассказывать что-то про языки и парадигмы программирования, если они в этом вообще ничего не понимают.
Это как первокласснику рассказывать про логарифм %)

 

На умных людей уповают и возводят в разряд нерушимых авторитетов обычно не самые умные люди.

Прямую цитату, где я считаю себя умнее всех?

А кстати, где твои проекты?

Особенно когда и рассказать то нечего.

Че то я не помню чтобы ты мне че то рассказывал.

 

Си - это подмножество языка Си++.
То есть можно сказать, что Си++ это смесь - на 30% Си и на 70% отдельный объектно-ориентированный язык.

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

 

Nafanya
> Си - это подмножество языка Си++.
если си подмножество плюсов, означает ли это что плюсы откомпилируют сишную программу? хрен там. совместимость была утрачена и пути языков разошлись, а C99 вообще в упор не совместим с плюсами.

> То есть можно сказать, что Си++ это смесь - на 30% Си
> и на 70% отдельный объектно-ориентированный язык.
по крайней мере одного из этих двух языков вы совсем не знаете

> Основные идеи ООП - инкапсуляция, наследование, полиморфизм(динамика и статика).
плюсы это не только ооп. это еще и метапрограммирование, на которое в последнее время сделан основной упор и акцент тяжести сместился с ооп уже давно.

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

 

kaspersky
https://wasm.ru/forum/viewtopic.php?pid=402897#p402897

 

То есть чтобы откомпилировать чиста сишный код, plain C если угодно, нужен чиста сишный компиллятор? И каким вы пользуетесь?

И как же можно научиться этим языкам или по крайней мере одному из них?

 

kaspersky
Си++ в качестве базы использует ANSI C89. ANSI C99, о котором вы упоминаете, отдельный путь развития языка СИ.

<по крайней мере одного из этих двух языков вы совсем не знаете
На далёком втором курсе сдал экзамен по сишняку + курсач БД на сишняке, а на 3-ем экзамен по Плюсам.

 

wsd
GCJ ???
1) мы проигрываем в безопасности, т.к. на выходе получаем машинный код, вам мало атак на JIT ?!
2) все равно плюсы позволяют писать более производительный код, чем жаба, даже если ее откомпилировать...

dZentle_man
> То есть чтобы откомпилировать чиста сишный код, plain C если угодно,
> нужен чиста сишный компиллятор? И каким вы пользуетесь?
MS VC смотрит на расширение -- для .c выбирает Си, для .cpp -- плюсовой компилятор. легко написать программу, которая не будет компилировтаься с расширением .cpp, но сразу же откомпилируется без вопросов после переименования в .c

C99 MS VC не откомпилит. так же как не откомпилит и гнусевый си. вообще.

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

 

Nafanya
> Си++ в качестве базы использует ANSI C89.
ок. тогда как быть с тем, что C89 не проверяет типы аргументов при их передаче функции и потому можно объявить функцию foo(int a, int b){return a+b;}, скоипилить ее, в .h файле написать foo(); и тут же вызывать ее как foo(1, 2, a = b); и это будет работать. но только не в плюсах!!!

так что совместимость с ANSI C89 лишь частичная.

> ANSI C99, о котором вы упоминаете, отдельный путь развития языка СИ.
по крайней мере вы не спорите, что си это подмножество плюсов, а сами признаете, что это два разных языка. плюсы базируются на си, но обратной совместимости нет даже с базой, не говоря про новые версии...

 

А что же его откомпилит?)

То есть разыскивать исходники с расширением .c? И этого расширения достаточно чтобы убедиться, что то, что внутри - чистый С?

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

 

kaspersky
Ну есть такие исключения из правил.
Вот код например:
void func (void)
{
int a;
int b;
a++;
int c;
}
В Си++ компиляторе это скомпилится, а в ANSI C89 нет, так как переменную с по C89 стандарту надо объявлять до инкремента а.

(My - структура)
Для Си++ просто объявление : My variable; а в ANSI C89 надо: struct My variable;

Эти исключения же не главное - всё равно ANSI C89 база для Си++.

 

dZentle_man
>> C99 MS VC не откомпилит. так же как не откомпилит и гнусевый си. вообще.
> А что же его откомпилит?)
ну я понял, что ваш мир ограничен студией http://en.wikipedia.org/wiki/C99 (см. список компиляторов. MS VC -- вообще никак, Intel -- частично, IBM/Sun -- полностью)

>> ковырять чужие исходники
> То есть разыскивать исходники с расширением .c? И этого расширения
> достаточно чтобы убедиться, что то, что внутри - чистый С?
чистоту си определяем путем чтения стандартов. в частности, на линухе си в основном гнутый и как уже говоилось не компилируемый ms vc.

>> юзать разные компиляторы (оказывается написать программу,
>> компилируемую более, чем одним компилятором -- не так-то просто)
> Я не могу привести это аргументом, но у меня смутное ощущение,
> что знание особенностей компилляторов как то совсем боком
ну вы блин даете... в вот щас такое скажу, что хоть ложить, хоть падать. стоп! на каком языке я с вами разговариваю? тот факт, что вы меня понимаете не дает нам права считать, что этот текст написан на русском языке.

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

> относится к знанию языка... Профессионализм - да, но чтобы знание языка...
относится - относится. _язык_ говорит, что знаковость char'a это личное дело компилятора. и если вы пишите char x; ... if (x == 'я') то 'я' будет приведено к int, а содержимое char'а расширено с учетом знака. т.е. это работает только когда char беззнаковый. т.е. примерно на половине компиляторов

Nafanya
> В Си++ компиляторе это скомпилится, а в ANSI C89 нет,
на C89 и не должно. я ж за обратную совместимость говорю. это когда на си компилиться, а на плюсах -- нет. в частности, на си можно не париться с включением заголовочных файлов (там где объявлены только функции) и потому main(){printf("the hell\n");} скомпилиться успешно, а плюсы сразу выпадут на измену.

 

Я знаю чем, двумя крестами.

 

kaspersky
<<
тогда как быть с тем, что C89 не проверяет типы аргументов при их передаче функции и потому можно объявить функцию foo(int a, int b){return a+b;}, скоипилить ее, в .h файле написать foo(); и тут же вызывать ее как foo(1, 2, a = b); и это будет работать. но только не в плюсах!!!
<<

Так в С нет статического полиморфизма, функцию foo() перегрузить нельзя,она одна. Поэтому всегда ясно что вызывать, не зависимо от кол-ва и типов параметров.

А в Си++ есть, и функции с именем foo может быть много. Компилер должен решать по типу параметров и их кол-ву какую foo вызвать. Так как он не может найти foo соответствующую по параметрам вашему вызову он выдаёт ошибку.
Напишите foo(int a=0,int b=0,int c=0){return(a+b+c);} Прекрасно будет вызываться хоть foo(); хоть foo(1,2,3);

 

Че за наезды?) Тогда и ваш мир до недавнего времени был ограничен ей) Ведь вы в упор не хотели и не хотите пользоваться гнутым компилером) И я вас таки понимаю, хотя месье и славится своим знанием толка в извращениях Или вы подразумеваете что пользуетесь еще и компилерами от, прости господи, IBM/Sun? Причем пользуетесь в повседневном кодинге, а не только в проверке концептов и в узкоспециализированных и редко встречающихся задачах?

Ну вот об этом и речь. Если стандарт - это эталон, то логично, что знание языка определяет знание стандарта, а компилеры - это уже особенность реализации стандарта. Знание же компилятора является залогом успешного кодинга под него. Но как то так получается, что знание эталона является лишь основой для сравнения с реализацией. Мы сталкиваеся с чисто философской проблемой - какой язык считать правильным - тот, на котором говорят аборигены, или тот, который по правилам, составленным признанными экспертами в знании языка аборигенов. И вывод, который делается - чем меньше мы знаем наречий аборигенов, тем меньше знаем язык.

 

dZentle_man

Ну-ка, ну-ка. Это уже интересно. Я один из того большинства, и мне очень досадно, что я не вижу пользы в делении на классы. Я был бы тебе очень благодарен, если бы ты опубликовал бы пример на 2k строк, в котором использование классов было бы со всех точек зрения разумным и полезным. Такой маленький пример, я думаю, помог бы мне осознать всю мощь ООП.

 

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

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

Да Си++ это не только классы. А вы взгляните сколько пользы от полиморфизма. Одному интерфейсу соответствует множество методов. Пользователю класса не надо париться с изучением всех методов(тратить время), он изучает только лишь один интерфейс. За счёт свойства виртуальности (указатель на базовый класс ссылается на объект одного из производных классов) во время выполнения программы решается какой метод вызвать.

 

Nafanya
> Так в С нет статического полиморфизма, функцию foo() перегрузить нельзя,она одна.
> Поэтому всегда ясно что вызывать, не зависимо от кол-ва и типов параметров.
это тут непричем. просто добавли контроль типов для ловли ошибок и тут же нашли ошибку в компиляторе ибо сишные программисты часто умышленно объявляют функции _неправильно_.

трюк: если вы не хотите подключать виндоусные хидеры, но хотите вызывать API функции, то просто объявите их как function_name1(); function_name2(); ... на плюсах это уже не прокатит.

> А в Си++ есть, и функции с именем foo может быть много.
> Компилер должен решать по типу параметров и их кол-ву какую foo вызвать.
в плюсы сначала добавили строгую проверку типпов, а уже потом все то, о чем вы пишите.

> Так как он не может найти foo соответствующую по параметрам вашему вызову он выдаёт ошибку.
а тут еще вторая засада. манглин имен, который нестандартный и вообще гадость...

> Напишите foo(int a=0,int b=0,int c=0){return(a+b+c);}
> Прекрасно будет вызываться хоть foo(); хоть foo(1,2,3);
ага щас блин. а если я вызову как char *p; foo(p); -- это тоже будет работать? на си -- будет.

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


dZentle_man
>> ну я понял, что ваш мир ограничен студией
> Че за наезды?)
это не наезды. это факт. как только возникает потребность выйти за студийные рамки, представление о языке сильно меняется. и сразу начинаешь видеть кто чем дышит

> Тогда и ваш мир до недавнего времени был ограничен ей)
никогда не был ей ограничен. компилил и багдадом, и студией, и интелом, и ваткомом, и гнусем, и еще много чем...

> Ведь вы в упор не хотели и не хотите пользоваться гнутым компилером)
гнусь мои программы компилирует без допила. ну практически. эпизодический допил вызван гнутыми странностями, да и те проявляются лишь в виде варнингов там, где ms vc молчит даже на /W4 и стандарт не предписывает ругаться матом. это гнуст отсебятничает.

> Или вы подразумеваете что пользуетесь еще и компилерами
> от, прости господи, IBM/Sun? Причем пользуетесь в повседневном
> кодинге, а не только в проверке концептов и в узкоспециализированных
> и редко встречающихся задачах?
поскольку, использование фич C99 вызывает большие проблемы с компиляторами их не поддерживающими, а сами эти фичи не настолько вкусные, то я их не использую и страшно матерюсь, когда мне попадается исходник, написанный под IBM/Sun...

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

> Знание же компилятора является залогом успешного кодинга под него.
когда язык учиться методом тыка (а чаще всего он так и учится), то человек не знает ни того, ни другого. допустим, он видит, что char тут беззнаковый, но не знает -- толи это фича языка, толи фича компилятора.

плюс еще расширения языка, типа int64 или naked функций. и далеко не все знают, что это specific и что на другом компиляторе работать скорее всего не будет. ну тут ладно, тут хотя бы ошибка будет. а вот как некоторые думают, раз у нас тут long long это 64 бита, значит, он так и везде 64, что опять-таки не факт...

> Но как то так получается, что знание эталона является
> лишь основой для сравнения с реализацией.
кстати, еще учитывайте, что найти ANSI С совместимый компилятор это еще поискать. то есть нужно знать и стандарт, и его практические реализации.

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

> И вывод, который делается - чем меньше мы знаем наречий аборигенов, тем меньше знаем язык.
а толку? ну допустим, вижу я тут gnu specific и понимаю, что переписать это под не-гну компилер будет стоить очень больших трудов.

 

kaspersky
а как относитесь к Boost ?