Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Общие вопросы > C или C++

Автор: Olexey 18.10.2005, 20:27

Не подскажете в чём разница между C i C++ И что лучше начинать учить(нечем большинство программ для венды); Знаю Pascal и PHP

Автор: DeadSoul 18.10.2005, 20:35

Цитата(Olexey @ 18.10.2005, 20:27) И что лучше начинать учить(нечем большинство программ для венды); С++

Автор: Дмитрий Т 18.10.2005, 20:50

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

Автор: DeadSoul 18.10.2005, 20:54

Цитата Но по большей части C++ это C с дополнительными удобствами ЭТО РАЗНЫЕ ЯЗЫКИ!

Автор: nikitao 18.10.2005, 21:12

Цитата ЭТО РАЗНЫЕ ЯЗЫКИ! ДОКОЖИ! Добавлено @ 21:14 Первоночальное название С++ было "C с классами" делаем выводы во взаимоотношениях C и С++

Автор: Void 18.10.2005, 21:16

С++ - прямой наследник C, но называть его расширением C едва ли возможно.

Автор: SectoR 18.10.2005, 21:26

С#

Автор: nikitao 18.10.2005, 21:34

С++ - прямой наследник C, но называть его расширением C едва ли возможно. Что мы вкладываем в это СЛОВО????????

Автор: Void 18.10.2005, 21:39

nikitao Язык, полученный из другого языка простым добавлением фич. C++, имхо, эту грань перешел (эдак к середине 90-х), хотя почти полная обратная совместимость с Си до сих пор обеспечивается (и зря...).

Автор: nikitao 18.10.2005, 21:45

Цитата хотя почти полная обратная совместимость с Си до сих пор обеспечивается (и зря...). Вот именно этот смысл лично я вкладываю в смысл слова "расширенный". Цитата (и зря...). Why?

Автор: SectoR 18.10.2005, 22:01

Советую учить C#, т.к. платформа ".NET - наше светлое будующее"! (цитата: А.Я. Архангельский <<Программирование в C++ Builder 6>> 2-е издание Бином 2005 стр. 36).

Автор: DeadSoul 18.10.2005, 22:04

http://forum.sources.ru/index.php?showtopic=99204&view=findpost&p=750182 смотрим посты номер 14 и 23

Автор: val 19.10.2005, 14:12

Последнее время С всё больше становится языком для программирования встроенных систем. Ну а С++ больше для персоналок. Но начинать, мне кажется все равно надо С, так как это подмножество С++.

Автор: chipset 19.10.2005, 17:28

А на вопрос так никто и не ответил C++ -- обьектно-ориентированный язык, Си - процедурный.

Автор: Void 19.10.2005, 17:33

Цитата(chipset @ 19.10.2005, 19:28) C++ -- обьектно-ориентированный язык Мультипарадигменный (+ обобщенное программирование), если на то пошло. По крайней мере, Страуструп так утверждает

Автор: chipset 19.10.2005, 17:34

Цитата(Void @ 19.10.2005, 07:33) обобщенное программирование А что это, если не секрет? Добавлено @ 17:36 Цитата(SectoR @ 18.10.2005, 12:01) Советую учить C#, т.к. платформа ".NET - наше светлое будующее"! (цитата: А.Я. Архангельский <<Программирование в C++ Builder 6>> 2-е издание Бином 2005 стр. 36). Советую не оффтопить во избежание неминуемых последствий. Спасибо.

Автор: Void 19.10.2005, 17:42

Цитата(chipset @ 19.10.2005, 19:34) А что это, если не секрет? Подход, благодаря которому мы имеем STL и много других вкусностей http://en.wikipedia.org/wiki/Generic_programming + http://www.research.att.com/~bs/oopsla.pdf

Автор: DeadSoul 19.10.2005, 20:02

Цитата(chipset @ 19.10.2005, 17:28) А на вопрос так никто и не ответил C++ -- обьектно-ориентированный язык, Си - процедурный. А ты ходил по моей ссылке? Добавлено @ 20:03 Цитата(chipset @ 19.10.2005, 17:34) Цитата (Void @ 19.10.2005, 07:33) обобщенное программирование А что это, если не секрет?  http://www.ozon.ru/context/detail/id/1224782/

Автор: nikitao 19.10.2005, 20:42

Цитата C++ -- обьектно-ориентированный язык, Си - процедурный. Ну если уж на то пошло,то еще и в названии,годе выхода(С++ позже),разработчиках

Автор: chipset 19.10.2005, 20:46

Цитата(Void @ 19.10.2005, 07:42) Подход, благодаря которому мы имеем STL и много других вкусностей О, теперь я знаю на одно умное слово больше, спасибо

Автор: yaja 19.10.2005, 21:46

Цитата(Void @ 19.10.2005, 17:42) Подход, благодаря которому мы имеем STL и много других вкусностей smile От таких вкусностей живот пучит... Человек изучай С, а если потянет на ООП писать, то изучишь java, а не язык гибрид

Автор: DeadSoul 19.10.2005, 21:50

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

Автор: nikitao 19.10.2005, 21:53

Цитата От таких вкусностей живот пучит... Не нравится не ешь,они же сами в твой рот (програмный код) не полезут.

Автор: yaja 19.10.2005, 22:05

Цитата(DeadSoul @ 19.10.2005, 21:50) yaja, может не надо религиозных войн? Каждый язык предназначен для своего и спорить о том, что круче бесполезно. Бесспорно, только разве я говорил, что круче Я просто посоветовал человеку, как поступить (имхо) лучше Цитата(nikitao @ 19.10.2005, 21:53) Не нравится не ешь,они же сами в твой рот (програмный код) не полезут. Еще как лезут, особенно, когда начальство за спиной стоит

Автор: DeadSoul 20.10.2005, 19:33

Цитата(yaja @ 19.10.2005, 22:05) Цитата (DeadSoul @ 19.10.2005, 21:50) yaja, может не надо религиозных войн? Каждый язык предназначен для своего и спорить о том, что круче бесполезно. Бесспорно, только разве я говорил, что круче  Я просто посоветовал человеку, как поступить (имхо) лучше В чем лучше?

Автор: Neitron 21.10.2005, 09:08

Лучше всего учить С++, а не СИ. У С++ свой стиль программирования, и испоьзовать стиль из другого языка неприемлено. Это ведет к неуклюжему и сложному коду. С - является лишь подмножеством языка С++. С был лишь основой С++. Но С++ действительно гибрид и других языков. В нем соеденены Simula67, Algo68, Ada и др.

Автор: Neitron 21.10.2005, 09:38

Цитата(Void @ 18.10.2005, 21:39) nikitao Язык, полученный из другого языка простым добавлением фич. C++, имхо, эту грань перешел (эдак к середине 90-х), хотя почти полная обратная совместимость с Си до сих пор обеспечивается (и зря...). Раньше это было не зря. Существует миллионы кода на С, которые могут выиграть от использования С++ На С написано миллионы строк библиотечных ф-ций и утилит, они могут быть использованны на программах С++ сотни тысяч программистов знают С и им придется изучить только новые св-ва С++, не переучивая основы. "С с классами", далеко не С++, оно является также подмножеством языка С++.

Автор: szz 21.10.2005, 18:09

Кароче. Надо разумеется взять книжку Кернигана и Ричи "Язык программирования Си" и проштудировать, сделать все задания оттуда. А потом - С++. Я сам обожаю С++, но основы есть основы. Это - типа классический подход к изучению. Важный момент: на сегодняшний день язык, который создает быстрый и компактный код (кроме, разумеется ассемблеров): Это Си. С++ ориентировочно в 8 раз медленее чем Си и генерит гораздо большие экзешники размерами.

Автор: Void 21.10.2005, 20:06

Цитата(szz @ 21.10.2005, 20:09) С++ ориентировочно в 8 раз медленее чем Си и генерит гораздо большие экзешники размерами. Ну постеснялись хоть бы такой бред говорить...

Автор: DeadSoul 21.10.2005, 20:11

Цитата(szz @ 21.10.2005, 18:09) Я сам обожаю С++, но основы есть основы Абсолютно разные стили программирования. Цитата(szz @ 21.10.2005, 18:09) С++ ориентировочно в 8 раз медленее чем Си и генерит гораздо большие экзешники размерами. В некоторых местах в 19 раз(stringstream vs printf) . Но это скорее исключение. Одна из целей Страуструпа была создать язык программирования по эффективности не уступающий Си(без плюсов)

Автор: Void 21.10.2005, 20:43

Цитата(DeadSoul @ 21.10.2005, 22:11) В некоторых местах в 19 раз(stringstream vs printf) . Но это скорее исключение. Скорее, недоразумение авторов конкретной реализации STL Разницу больше, чем в 3 раза, мне получить не удалось. В большинстве случаев - вполне приемлемая плата за типобезопасность. Даже паталогически тормознутый boost::format проигрывает sprintf раз в 5-7. P.S. Пока писал тестик на 20 строк, успел один раз получить AV из-за buffer overrun в sprintf. Нафиг ее, такую "скорость".

Автор: szz 21.10.2005, 21:25

Цитата(Void @ 21.10.2005, 20:06) Ну постеснялись хоть бы такой бред говорить... Мусьё, вот вы и попались! Постеснялись бы стеснять Спросите любого программиста 3д игр, почему он пишет на Си а не С++? Спросите разработчиков того же самого PHP - что, они ради своего удовольствия колупают на Сях? Ах как было бы удобно построить огроменную иерархию классов для парсера PHP! А вот низя ))) Число 8 не с потолка взято, позвольте заметить. Цитата(DeadSoul @ 21.10.2005, 20:11) В некоторых местах в 19 раз(stringstream vs printf) С++ные потоки - вообще уже притчей во язытцах давным-давно стали Я говорю даже просто об использовании классов. Ну все ладно, хватит пустословить. Человек получил ответ на свой вопрос, Цитата(Void @ 21.10.2005, 20:43) Пока писал тестик на 20 строк, успел один раз получить AV из-за buffer overrun в sprintf. Нафиг ее, такую "скорость". Это ручки ))) нечего sprintf ругать Забавные результаты. Одно включение iostream (супротив stdio.h) должно все на уши поставить. Как, кстати, тестируем? Чем считаем-с?

Автор: Void 21.10.2005, 21:48

Цитата(szz @ 21.10.2005, 23:25) Мусьё, вот вы и попались! Постеснялись бы стеснять smile Спросите любого программиста 3д игр, почему он пишет на Си а не С++? А парни из Remedy не знали, и облажалась, выпустив Max Payne 2, написанный на C++... и движок почему-то летает. Или gamedev == Кармак? Ну так вроде и он потихоньку на плюсы переходит. Цитата(szz @ 21.10.2005, 23:25) Спросите разработчиков того же самого PHP - что, они ради своего удовольствия колупают на Сях? Ах как было бы удобно построить огроменную иерархию классов для парсера PHP! А вот низя ))) Да кто их знает У таких больших и древних проектов свои тараканы. Цитата(szz @ 21.10.2005, 23:25) Число 8 не с потолка взято, позвольте заметить. Ну, выкладывайте свой секрет бенчмаркинга Цитата(szz @ 21.10.2005, 23:25) Я говорю даже просто об использовании классов. Оверхед от косвенности в виртуальных вызовах считать будем? Цитата(szz @ 21.10.2005, 23:25) Это ручки ))) нечего sprintf ругать Ну не смог я с первого раза правильно посчитать в уме необходимый размер буфера. Позор мне за это. Цитата(szz @ 21.10.2005, 23:25) Забавные результаты. Одно включение iostream (супротив stdio.h) должно все на уши поставить. Как?! Цитата(szz @ 21.10.2005, 23:25) Как, кстати, тестируем? Чем считаем-с? clock'ом, однако Код for (int i = 0; i < 1000000; ++i)     p += sprintf(p, "%i = %lf\n", i, static_cast<double>(i)); vs аналоги. P. S. Тема отчетливо запахла Религиозными войнами...

Автор: S.A.P. 21.10.2005, 22:09

Цитата(Void @ 21.10.2005, 21:48) vs аналоги. а какие еще аналоги? Код ostringstream out; for (int i = 0; i < 1000000; ++i)        out << i << " = " << static_cast<double>(i) << endl; дык STL проиграет заведомо .

Автор: Void 21.10.2005, 22:11

Цитата(Perchilla @ 22.10.2005, 00:09) а какие еще аналоги? std::ostringstream и boost::format Цитата(Perchilla @ 22.10.2005, 00:09) дык STL проиграет заведомо Проиграла. В 3 раза. А не в 8-19, как утверждают Про AV см. выше.

Автор: S.A.P. 21.10.2005, 22:16

Void а как тестировал? В случае со sprintf всё в С строку загонял или в string ?

Автор: Void 21.10.2005, 22:21

Цитата(Perchilla @ 22.10.2005, 00:16) В случае со sprintf всё в С строку загонял или в string ? А второй вариант... это как вообще? В C-строку, конечно. В общем, смотрите сами: Код #include <iostream> #include <sstream> #include <cstdio> #include <ctime> #include <boost/format.hpp> using namespace std; int main() {     ostringstream os;     clock_t t0 = clock();     for (int i = 0; i < 1000000; ++i)         os << i << " = " << static_cast<double>(i) << "\n";     cout << "ostringstream: " << 1000.0 * (clock() - t0) / CLOCKS_PER_SEC <<         " ms\n";     t0 = clock();     char *s = new char[24000000], *p = s;     for (int i = 0; i < 1000000; ++i)         p += sprintf(p, "%i = %lf\n", i, static_cast<double>(i));     cout << "sprintf: " << 1000.0 * (clock() - t0) / CLOCKS_PER_SEC <<         " ms\n";     delete s;     os.str("");     t0 = clock();     boost::format fmt("%1% = %2%\n");     for (int i = 0; i < 1000000; ++i)         os << fmt % i % static_cast<double>(i);     cout << "boost::format: " << 1000.0 * (clock() - t0) / CLOCKS_PER_SEC <<         " ms\n"; } Цитата ostringstream: 7721 ms sprintf: 3485 ms boost::format: 15923 ms

Автор: S.A.P. 21.10.2005, 22:33

Void дык понятное дело, ostringstream string использует, ему расширяться надо каждый раз, а под C строки тут сразу память выделяется . Добавлено @ 22:38 А у меня вобще интересные тесты: Цитата ostringstream: 3953 ms sprintf: 3094 ms

Автор: Void 21.10.2005, 22:43

Perchilla Переделал, посмотрел. Прирост на пару процентов. Реаллокация - не самое узкое место. Потоки действительно медленнее, но, повторюсь, эта медленность в большинстве случаев оправдывается (типо)безопасностью.

Автор: S.A.P. 21.10.2005, 22:44

Цитата ostringstream: 3953 ms sprintf: 3094 ms это я на VC 71 компилил а mingw вобще ужас на крыльях ночи выдает Цитата ostringstream: 11500 ms sprintf: 3156 ms

Автор: Void 21.10.2005, 22:46

STLPort, небось?

Автор: S.A.P. 21.10.2005, 22:53

Цитата(Void @ 21.10.2005, 22:46) STLPort, небось? нет, все по старинке .

Автор: DeadSoul 21.10.2005, 23:00

[quote=szz, 21.10.2005, 21:25]Цитата (DeadSoul @ 21.10.2005, 20:11) В некоторых местах в 19 раз(stringstream vs printf) Обшибся... В 9 раз для MS VC 7. В 19.2 - это boost::lexical_cast Источник: Саттер,Новые сложные задачи на С++ [quote=szz, 21.10.2005, 21:25]Цитата (Void @ 21.10.2005, 20:43) Пока писал тестик на 20 строк, успел один раз получить AV из-за buffer overrun в sprintf. Нафиг ее, такую "скорость". Это ручки ))) нечего sprintf ругать[/quote] Это означаят, что я как параноик должен проверять каждый символ.

Автор: S.A.P. 21.10.2005, 23:04

Цитата(DeadSoul @ 21.10.2005, 23:00) Обшибся... В 9 раз для MS VC 7. В 19.2 - это boost::lexical_cast на результаты смотрел? . У меня на VC 71 у sprintf прирост скорости не больше 30 процентов, ни о каких разах и речи нет. . А boost::format в mingw 20625 ms работал

Автор: DeadSoul 22.10.2005, 23:16

Цитата(Perchilla @ 21.10.2005, 23:04) на результаты смотрел? Perchilla, самому прогонять тескты слишком сложно. Современные компиляторы слишком хорошо оптимизируют. И у тебя стоит двойная цель: - оставить компилятору возможность для оптимизациии - убить ненужную оптитмизацию. ПРимер: Код for ( int i=0 ; i<1000000 ; ++i ); компилер может выкинуть

Автор: Void 23.10.2005, 09:26

Цитата(DeadSoul @ 23.10.2005, 01:16) Современные компиляторы слишком хорошо оптимизируют Это недостаток? Цитата(DeadSoul @ 23.10.2005, 01:16) убить ненужную оптитмизацию. ПРимер: Почему же ненужную? Зачем может быть нужен пустой цикл на миллион итераций? В качестве задержки? Так есть способы получше. Вспоминается CRT от древнего TP 7.0, в которой задержки делались именно пустыми циклами, с калибровкой при старте. Прошло время, процессоры стали быстрее, и все это стало нещадно глючить.

Автор: Mayk 23.10.2005, 09:39

Цитата(Void @ 22.10.2005, 00:43) P.S. Пока писал тестик на 20 строк, успел один раз получить AV из-за buffer overrun в sprintf. Нафиг ее, такую "скорость". Не будем столь категоричными. Ведь есть же snprintf! Цитата(DeadSoul @ 22.10.2005, 03:00) Источник: Саттер,Новые сложные задачи на С++ Для сравнения некий дядя Майерс говорил о 20%-200% потерях скорости при использоваии иостреам на разных конфигурациях. При этом он допускал возможность написания вывода столь же быстрого как и сам stdio. (смотреть наиболее эффективное программирование, правило 34 по-моему - "юзайте разные либы")

Автор: DeadSoul 23.10.2005, 12:03

Цитата(Void @ 23.10.2005, 09:26) Цитата (DeadSoul @ 23.10.2005, 01:16) Современные компиляторы слишком хорошо оптимизируют Это недостаток? Цитата (DeadSoul @ 23.10.2005, 01:16) убить ненужную оптитмизацию. ПРимер: Почему же ненужную? Зачем может быть нужен пустой цикл на миллион итераций? В качестве задержки? Так есть способы получше Все это было к тому, что крайне сложно сделать грамотную оченку по скорости

Автор: powerfox 23.10.2005, 12:31

Цитата(SectoR @ 18.10.2005, 22:01) Советую учить C#, т.к. платформа ".NET - наше светлое будующее"! (цитата: А.Я. Архангельский <<Программирование в C++ Builder 6>> 2-е издание Бином 2005 стр. 36). Архангельский - плохой автор!

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)