<iostream.h>

Ubuntu 7.10

0. Выкинуть книжку эту. 1. Выучить С 2. Забыть C++.

#include <iostream>

>#include <iostream>
Та же история.. 
sudo apt-get install libc6-dev
sudo apt-get install build-essential
делал.. 

sudo aptitude install g++

> 0. Выкинуть книжку эту. 1. Выучить С 2. Забыть C++.

3. пойти работать либо embedded or/and kernel девелопером или двроником на улицу, если на первое не потянешь.

3. Выучить Python/Java.

> 3. Выучить Python/Java.

Этого не было указано, а на чистом C, не имея сверхспособностей в kernel/embedded разработке, далеко не уедешь.

P.S. что же касается C++, то до сих пор весьма востребованны люди, знающие плюсы, далеко не для всех задач подходит Java или Python.

Большинство высокопроизводительных серверов написано на чистом C. БОльшая часть гнома так же написана на C.

> Большинство высокопроизводительных серверов написано на чистом C. БОльшая часть гнома так же написана на C.

Это не о чем не говорит, найти сейчас работу, зная только C, очень сложно. К тому-же, ваше высказывание про "большинство высокопроизводительных серверов" полностью лишено смысла, т.к. совершенно не ясно, что же именно скрывается за этим термином: либо это сервероное ПО, почтовые демоны/web сервера, либо что-то еще может быть.

К тому-же, надо отметить, что производительность кода на C++ будет ничуть не ниже, при правильном его использовании, а в ряде случае даже выше, как например в известном примере с сортировкой массива C-шной qsort и STL-ным std::sort

apache,lighttpd,squid,sendmail,qmail,vsftpd - список продолжать? Найти работу, ОТЛИЧНО зная C и posix - не проблема. Если изучать технологии по спросу на рынке, то надо учить .net и c#.

>sudo aptitude install g++

делал..

> apache,lighttpd,squid,sendmail,qmail,vsftpd - список продолжать?

Вот с этого и надо было начинать, с указания конкретного списка софта, который написан на С и работает быстро.

> Найти работу, ОТЛИЧНО зная C и posix - не проблема.

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

> Вот с этого и надо было начинать, с указания конкретного списка софта, который написан на С и работает быстро.

Отвлекся, не дописал, что хотел:

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

* отлично изучить C намного проще, а нормальным программистом на C++ можно стать только после года-двух непрерывного его исползования и обучения. Для Open Source этот момент критичен, т.к. если для проекта будет высокий порог вхождения, никто не будет собственно его разрабатывать, т.к. будет некому.

* Далеко не для всех платформ существует C++ компилятор.

А производительность, тут далеко не самый решающий фактор.

+ еще один важный момент, почему C популярнее:

* соплежуи считают, что программировать на чистом C это круто, и сложно, "а раз я на нем пишу, значит я крутой", а C++ - это для дураков, они не в курсе, что грамотный код на C++ писать -- это задача не такая уж и тривиальная, и здесь опыт куда больший нужен :)

По-твоему Линус - соплежуй? Или создатели gtk - тоже соплежуи? Хватить пороть чушь.

Как раз для грамотного программирования на C нужно иметь культуру программирования, иметь много опыта, строго следовать единому стилю, при этом не ограничивая возможности разработки. Более того, в C нет подводных камней, значительно проще спрогнозировать поведение программы, так же как и временные характеристики. Для C++ всё это можно сделать, но намного сложнее.

Как раз для грамотного программирования на C++ нужно иметь культуру программирования, иметь много опыта, строго следовать единому стилю, при этом не ограничивая возможности разработки. Более того, в C++ нет подводных камней, значительно проще спрогнозировать поведение программы, так же как и временные характеристики. Для C всё это можно сделать, но намного сложнее.

> >#include <iostream> Та же история.. sudo apt-get install libc6-dev sudo apt-get install build-essential делал..

а по каким признакам ты решил что этого хедера нет? Первичные признаки в студию

> P.S. что же касается C++, то до сих пор весьма востребованны люди, знающие плюсы, далеко не для всех задач подходит Java или Python.

примеры задач в студию.

> * соплежуи считают, что программировать на чистом C это круто, и сложно, "а раз я на нем пишу, значит я крутой", а C++ - это для дураков, они не в курсе, что грамотный код на C++ писать -- это задача не такая уж и тривиальная, и здесь опыт куда больший нужен :)

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

a) сфера применения языка стремительно уменьшается.
b) язык болтается между "нижним уровнем"(c) и "верхним уровнем"(java/python/and so on). вопрос: что на нём писать? высокоуровневые приложения? в данном случае слишком много времени теряется на отладку. низкоуровневые приложения? увольте, c делает ++ по производительности, зачем изголяться?
c) хотите ооп - objective c в разы логичнее и изящнее, правда аналога stl и boost нема.
d) насчёт опыта. фраза "и здесь опыт куда больший нужен" вызывает улыбку. парадигмы используемые языками абсолютно разные. это то же самое, что сказать: "программирование в fp парадигме требует гораздо большей длины члена программиста, нежели в tp, oop or sp".

> А производительность, тут далеко не самый решающий фактор.

Тогда надо поступать по совету Пола Грэма: выбирать самый мощный из доступных языков, и это будет не C++.

> Более того, в C++ нет подводных камней,

чуть не выплюнул кофе на монитор.

> при этом не ограничивая возможности разработки.

как другие языки более низкого уровня вас ограничивают?

> так же как и временные характеристики.

вы мало времени теряете, отлаживая мемлики и прочие траблы с памятью?

> Для C всё это можно сделать, но намного сложнее.

учитывая то, что ваше описание c++ очень по хоже на содержание предвыборных плакатов, которые можно видеть на каждой захудалой улочке a la: "с партия X пенсии будут возрастать в геометрической прогрессии, безработные будут работать, алкоголики не будут пить, и россия побидит марсиан(tm). с партией Y, всё это можно будет сделать гораздо сложнее...", ваши доводы можно проигнорировать.

Люди делятся на две категории: на тех, кто осилил SICP, и на тех, кто не знает, что это такое.

ну напиши тестовую программу в консоли, делов то - 

$ cat test.cpp
#include <iostream>

int main(int argc, char **argv)
{
    std::cerr << "It works!" << std::endl;

    return 0;
}

$ g++ -o test test.cpp
$ ./test

>>учитывая то, что ваше описание c++ очень по хоже на содержание предвыборных плакатов

заметь, плакат первым поднял не я :) а все доводы можно направить и к тов. krum, получится тоже самое, только про С - и про языки более низкого уровня, и про траблы с памятью ;)

Structure and Interpretation of Computer Programs — книга книг, по значению превосходящая все остальные книги, вместе взятые. Только прочитав ``SICP'', можно достигнуть сатори, очистив свой разум и его окружение от туринг-полных проблем.

Краткое описание В компьютерах живут духи, выполняющие программы и заклинания. Пусть истинного компьютерного учёного — приносить лулзы и не продавать библий. Правильные кавычки ставятся ``вот так''. В книгата са описани редица практики и медитации, позволяващи на практикуващия да зареди енергийно тялото и ума си и да се отвори към вътрешния съкровен смисъл на програмиското учение. Авторите подкрепят своя възглед относно традиционните математистки постулати с потвърждаващите ги съвременни научни открития. Не следует избегать скобок.

>хотите ооп - objective c в разы логичнее и изящнее

ну вот с этим можно ой как поспорить, objective-c выглядить, имхо, каким-то костылем(правда и ++ тоже)

можно и на чистом си в парадигме ооп писать "логично и изящно", было бы желание

a,b,d - полностью согласен

на плюсах вообще трудно найти красивый большой проект(и а плане архетектуры и в плане кода)

aptitude install libstdc++<версия>-dev

> примеры задач в студию. Любые задачи, где числодробление играет важную роль.

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

> a) сфера применения языка стремительно уменьшается.

> b) язык болтается между "нижним уровнем"(c) и "верхним уровнем"(java/python/and so on). вопрос: что на нём писать? высокоуровневые приложения? в данном случае слишком много времени теряется на отладку.

Если требуется писать высокоуровневое приложение, то отдаем memory handling на boost-овские умные поинтеры, пользуемся прочими вкусностями boost-а, и имеем то-же время, потраченное на отладку, в итоге.

> низкоуровневые приложения? увольте, c делает ++ по производительности, зачем изголяться?

Как уже я не раз упоминал, C++ по производительности может вполне делать С, пример тому хороший - quick sort методами ANSI-шной qsort и std::sort, STL-ный вариант будет быстрее, при прочих равных, вопрос на 3 с плюсом: почему? :)

> c) хотите ооп - objective c в разы логичнее и изящнее, правда аналога stl и boost нема. > d) насчёт опыта. фраза "и здесь опыт куда больший нужен" вызывает улыбку. парадигмы используемые языками абсолютно разные. это то же самое, что сказать: "программирование в fp парадигме требует гораздо большей длины члена программиста, нежели в tp, oop or sp".

C++ это мультипарадигмный язык, который совмещяет в себе и ООП, и даже элементы ФП, и кучу прочего всего, в умелых руках это очень мощный язык, единственное требование -- им нужно уметь пользоватся, а так получаешь инструмент пригодный для очень широких областей применения.

P.S. Вообще я не люблю C++, просто в этом топике на него наехали абсолютно необоснованно.

> ну напиши тестовую программу в консоли, делов то - 
Работает.. А как мне тогда заставить Eclipse ее использовать? Ведь он то пишет warning: iostream: No such file or directory

Не использовать пока eclipse. Когда прийдёт понимание, как делается makefile, что такое autoconf и automake, тогда почитать документацию в eclipse, каким образом сделать автоматизацию этого процесса. Вполне возможно, что вам eclipse вообще не понядобиться, как мне, и вы поймёте, что vimа выше крыши:)

>пример тому хороший

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

>даже элементы ФП

ух как вас занесло

>C++ это мультипарадигмный язык, который совмещяет в себе и ООП, и даже элементы ФП, и кучу прочего всего, в умелых руках это очень мощный язык, единственное требование -- им нужно уметь пользоватся, а так получаешь инструмент пригодный для очень широких областей применения.

это же можно сказать и про php...

>>пример тому хороший

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

данный пример показывает не то, что std:: лучше стандартной библиотеки C++, а то, что C++ позволяет более оптимальный в бинарном виде код получать, не пользуясь при этом костылями вроде препроцессора. Вы кстати 3+ не получите, т.к. видимо не знаете, почему решение на C++ будет быстрее :)

>>даже элементы ФП

> ух как вас занесло

А как-же. Конструкция вроде

std::transform(v.begin(),v.end(),v.begin(), std::bind2nd(std::divides<double>(),2.0));

больше уще на ФП смахивает, с его

newlist v = map v (\x-> x/2.0)

А с появлением лямбда оператора в грядущем C++ стандарте, так вообще им станет :)

> это же можно сказать и про php...

Неа, у php только одна парадигма - быдлокодинг ;)

> А с появлением лямбда оператора в грядущем C++ стандарте

Проснитесь, поезд уехал, догонять бесполезно.

> Проснитесь, поезд уехал, догонять бесполезно.

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

Синтаксический шугар в плюсах - это где смотреть: в потрохах буста или на выхлоп error при пропущенной запятой после использования этого буста? Вот, кстати, интересный пост про качество такого шугара: http://migun.livejournal.com/22664.html

> заметь, плакат первым поднял не я :) а все доводы можно направить и к тов. krum

прогрлядел первый комментарий, прошу прощения.

> получится тоже самое, только про С - и про языки более низкого уровня, и про траблы с памятью ;)

абсолютно не то же самое. ниша где вертится c работа с памятью необходима, ниша где вертится c++(а она вообще есть?), витая где-то межно low level & high level, это является проблемой.

> Как уже я не раз упоминал, C++ по производительности может вполне делать С, пример тому хороший - quick sort методами ANSI-шной qsort и std::sort, STL-ный вариант будет быстрее

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

> C++ это мультипарадигмный язык, который совмещяет в себе и ООП, и даже элементы ФП, и кучу прочего всего, в умелых руках это очень мощный язык

уважаемый, чистого fp на плюсах нету(будут элементы fp только в следующем стандарте(http://en.wikipedia.org/wiki/C%2B%2B0x#Other_major_C.2B.2B0x_language_features)). а псевдо fp и псевдолямбду, я вам и на с смогу сделать. вместе с псевдооп и тд и тп. но оно надр?

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

замечательно. умею пользоваться c++. скажите, где мне *выгодно* его применять? для какой сферы мне его действительно *выгоднее* использвать нежели c, python, perl, java?

> P.S. Вообще я не люблю C++, просто в этом топике на него наехали абсолютно необоснованно.

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

> у вот с этим можно ой как поспорить, objective-c выглядить, имхо, каким-то костылем(правда и ++ тоже)

Objective-C is a very "thin" layer on top of C. Objective-C is a strict superset of C. That is, it is possible to compile any C program with an Objective-C compiler. Objective-C derives its syntax from both C and Smalltalk.(http://en.wikipedia.org/wiki/Objective_c#Syntax)

вы вообще smalltalk пробовали? неужели он не логичен и не изящен? а objective c впитал в себя много смолтолковского.

> можно и на чистом си в парадигме ооп писать "логично и изящно", было бы желание

в том-то и проблема: она *не нужно*.

> на плюсах вообще трудно найти красивый большой проект(и а плане архетектуры и в плане кода)

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

> кхм... вообще-то тут дело в реализации, а не в производительности кода.

Дело в том, что C++ позволяет инлайнить параметры шаблонов, и тем самым избегать многочисленных вызовов функции compare, а C нет.

> уважаемый, чистого fp на плюсах нету(будут элементы fp только в следующем стандарте

ну я вроде так и написал "совмещяет в себе и ООП, и даже элементы ФП"

> замечательно. умею пользоваться c++. скажите, где мне *выгодно* его применять? для какой сферы мне его действительно *выгоднее* использвать нежели c, python, perl, java?

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

> Objective-C is a very "thin" layer on top of C. Objective-C is a strict superset of C. That is, it is possible to compile any C program with an Objective-C compiler. Objective-C derives its syntax from both C and Smalltalk.(http://en.wikipedia.org/wiki/Objective_c#Syntax)

При этом, зачастую чистый код на Objective-C получается куда более обьемный, чем код на Objective-C++ ;)

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

Реальный пример, пожалуйста. В стандарте C99 есть inline.

> Дело в том, что C++ позволяет инлайнить параметры шаблонов, и тем самым избегать многочисленных вызовов функции compare, а C нет.

в си не нужны шаблоны. либо мы сортируем определённый тип данных, либо void*'ы. в первом и во втором случае при использовании стандартного квиксорта теряется несколько циклов на обращение к ф-ии сравнения по адресу, во втором случае также теряется время на приведение типов.

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

сомнительно. ядро и asterisk большие проекты? тогда почему они не на плюсах? замечу, что оба написаны на довольно высоком уровне и очень легкорасширяемы. (в ядре проблема с расширяемостью network вещей). есть один большой костыль net_device, который пора бы переписать...

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

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

> Реальный пример, пожалуйста. В стандарте C99 есть inline.

Для глухих: qsort vs std::sort, речь идет не о наличии/отсутствии inline-а, а о том, что переданную в шаблон функцию или функтор, компилятор заинлайнит, а вызов по указателю, функции сравнения -- никак ни осилит.

Я говорю о __ПРОЕКТЕ__. А не о сравнении двух функций.... Из проектов, которые я знаю, это KDE, но это десктоп, а вот высокопроизводительных приложений что-то не припомню.

> Для глухих: qsort vs std::sort, речь идет не о наличии/отсутствии inline-а, а о том, что переданную в шаблон функцию или функтор, компилятор заинлайнит, а вызов по указателю, функции сравнения -- никак ни осилит.

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

>вы вообще smalltalk пробовали? неужели он не логичен и не изящен?

почему на вы? smalltalk щупал, красив..

>а objective c впитал в себя много смолтолковского.

это же можно сказать и про ++, только имхо в плюсах классы смотрятся как закончиная языковая конструкция(хреновая, многосложная & etc), а в obj-c просто как "добавка" к си

> несколько циклов на обращение к ф-ии сравнения по адресу,

далеко не несколько, надо сказать.

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

В C? поподробнее пожалуста, я всегда считал, что в C операция приведения типов делается в compile time ;)

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

С ядром существует ряд тонкостей, C++ не очень подходит для кернельного кода "в дефолтной конфигурации", хотя для Mac OS X можно писать на урезанном диалекте C++ драйвера ядреные (KEXT-ы). В любом случае, наличие нескольких большин проектов на C ни доказывает абсолютно ничего. Причин выбора языка могло быть очень много разных, но для коммерческой разработки обычно выбирают C++, т.к. в случае с коммерческой разработкой, время разработки имеет важное значение, -- чем оно меньше, тем проект дешевле обойдется.

> насчёт времени разработки - сильно сомневаюсь. учитывая, что не все йогурты одинаково полезны, те не все компиляторы одинаково *адекватно* компилируют ++...

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

> К чему болтовня, давай примеры сортировки на си и плюсах, проверим.

http://theory.stanford.edu/~amitp/rants/c++-vs-c/