Блуждая на просторах всемирного интнрнета, стал часто встречать статьи и обсуждения о том, что С++ постепенно начинает сбавлять обороты, в плане разработки современного ПО. Мотивируется это неоправданными затратами времени для реализации той или иной задачи. 
Многие пишут, что будущее за С# .NET. Хотелось бы узнать ваше мнение, дорогие посетители форума, что же ждет нас в будущем и может не стоит больше тратить драгоценное время на изучение  С++, а постепенно становиться дотнетчиком?

сейчас C++ в его областях применения может потеснить только С   

Звучит как приговор.

ну а кто/что еще?   

Да ты прав. Только это говорит лишь о том, что этих областей применения всё меньше и меньше:( Получается С++ затыкает "высокоуровневые" дыры С.

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

смотри сам: TIOBE index

посмотрите как С# набирает обороты http://www.tiobe.com/index.php/paperinfo/tpci/C_.html

и как падает С++ http://www.tiobe.com/index.php/paperinfo/tpci/C__.html

Это сообщение отредактировал(а) yngwie19 - 5.11.2008, 22:57

скорее как анекдот  

Добавлено через 3 минуты и 54 секунды

слабенько C# растет, если учитывать кто его спонсирует   
данный рейтинг скорее показывает моду, нежели эффективность

Добавлено через 11 минут и 43 секунды

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

Она есть! Это Си.   

Это сообщение отредактировал(а) bsa - 6.11.2008, 00:58

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

Что у нас тут?

а. Игры (особенно под консоли)
б. Софт под handheld devices - кпк, смартфоны, Sony PSP, iPhone и т.п.
в. Мультимедиа софт - конвертеры, кодеки и т.п.
г. Сетевой софт

С играми ясно, никакого С, API под все современные консоли на С++.

Софт под handhelds - у каждого девайса свой API, в 90% случаев на С++

Кодеки пишут на C, насколько я смог понять из увиденного (xvid, ffmpeg).

Насчёт пункта г) неуверен, просветите   

тролль   

Бред. Это всё равно что сказать что асм не нужен. Люди так стали любить делать меньше работы, что я удивляюсь как мы ещё обратно в шемпанзе не привратились? Нагоами не ходим - ездим на машине, в спорт залах жрут стероиды, так теперь и программистам лень мозгами воротить где что надо вычистить и как построить архитектуру - им подавая готовые паттерны и решения, а мотивируют всё тем, что якобы это уже давно найденные эффективные решения, лучше которых быть не может. Мне жаль таких людей. ИМХО

Это сообщение отредактировал(а) Rickert - 6.11.2008, 05:29

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

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

Это да))) Еще моего бывшего начальника (начальника отдела web-разработок) ввела в ступор конструкция public static)))) Я, конечно, все понимаю, но это уже слишком... короче, уволился я оттуда

Добавлено через 1 минуту и 34 секунды
Это оффтоп. А вообще, дотнет, конечно, удобная штука, но слишком много ресурсов кушает и память за собой чистить не умеет нормально, поэтому при разработке ресурсоемких систем все равно с++ юзать будут

Лично я попав на C#, после C++, когда там стали выскакивать подсказки и половину кода за меня писал автомат, ужаснулся. Не могу я так. Вот что хотите делайте, а мне нужны задачи и сложные комплексные решения с навороченными алгоритмами - работа мысли, пот и кровь; а не дома - матрёшки, в 256 этажей.

Это сообщение отредактировал(а) Rickert - 6.11.2008, 09:51

жжешь   



ну сколько можно повторять, причем здесь ОО языки?   
повторное использование кода != ОО язык
это вообще разные понятия
все либы на С - есть повторное использование кода, к примеру   

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


а это проблема любой крупной системы. Как я уже писал, возможности человеческого интеллекта весьма ограниченны. В крупной системе невозможно знать все с уровнем детализации до машинных кодов. Именно здесь и работает ООД, позволяя абстрагироваться на любой уровень детализации системы.


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

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

Безусловно МОЖНО все это организовать и на структурных языках (ты нам уже приводил этот пример если помнишь   ), НО - молотком закручивать шурупы, согласись, не очень удобно   

все оно позволяет   
главное, чтобы руки были ровные и голова на плечах

пример






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

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

не хочу заново начинать   

ps. молотком мы шуруп вряд ли _закрутим_  

Добавлено через 10 минут и 51 секунду

ага

забить гвоздь молотком или потребовать у молотка забить гвоздь   
кто не понял
work(m) и m.work()

J0ker, 
кстати, я так и не понял, причем здесь повторное использование к ОО языку?   
очевидно, что мы с тем же успехом можем повторно использовать структуры и работающие с ними функции (кстати, не зная их внутреннюю организацию)
пример - cURL

пардон за самоцитирование


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


абстракции невозможно достич без виртуальных функций


ну надо-же, хоть в чем-то мы пришли к общему мнению   



worker.DoWork(hammer);
мы пожалуй обойдемся без волшебных самозабивающих молотков 

Добавлено через 2 минуты и 3 секунды

эээ... я тоже не понял
еще я не понял почему ты ко мне с этим пристаешь  

Добавлено через 4 минуты и 9 секунд

безопасность типов???   

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


а ops здесь что по-твоему?   
для каждого типа сокета свои операции
по сути ops - набор виртуальных методы базового абстрактного класса struct socket (в терминах ООП)




человек не может обладать работой, т. к сущность "работа" - не материальна
это просто последовательность действий с объектами работы
так что 
DoWork(worker, hammer) aka работа выполняется при помощи рабочего и молотка   


твоя цитата?

"достаточно знать как работают уже изобретенные и области их применимости" != повторное использование кода?   



читай самый первый абзац

Что пузырь? Если ему это не мешает выполнять свои обязяности, то зачем ему это знать? Да, в качестве повышения общей образованности полезно, но не критично.

В жизни есть дела не менее прекрасные чем программирование. И зацикливаться на нем не стоит. И всё что помогает достичь цели с минимальными сроками и при этом не потерять в функционале - это благо и к этому надо стремиться.

этого достаточно для компрометации   


ну вот видите - если бы вы мне это сейчас не сказали, я бы не знал, что для каждого свои   


а он и не обладает - работа - это его поведение
для создания более сложного поведения (ака обучения) работу можно инкапсулировать в сущьность - скилл - но даже тут работа будет поведением


ага, а хвост вертит собакой? или собака вертит хвостом?   


безусловно


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




читай самый первый и самый второй абзацы   

сочувствую
на С ты точно не программировал, имхо  


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


я не понял, в хорошем или плохом смысле это сказано?
также я не понял, как связан контекст и структурное/ОО программирование
и наконец, "структурный программист" это тот кто пишет на структурных ЯП или тот, кто пишет в структурном стиле?   


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

не
я просто мысли читать не умею   


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




ты не находишь некоторого противоречия?


в нейтральном
я просто факт констатирую


не верю, что не понял
ты при цитировании вырезал фразу определяющую контекст
ну если хочется перечитай тот пост, который цитировал


программист, который ДУМАЕТ в структурном стиле   


ну для ОО программиста - огромная   


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


в свете вышесказанного я теряюсь в догадках   

не
скорее всего я прав 
 



неа
работа не материальна, 
это последовательность действий связанных с объектами этих действий
последовательность описывает, что делать с объектами
в данном случае материальны объекты   
термин "знает" здесь был применен не в контексте того, что работа материальна, а
в контексте того, последовательность действий _предусматривает_ наличие объектов

  


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



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




тогда возвращаемся к вопросу




объясняю
начнем с конца

т. е чтобы осуществить

но в то же время

ведет к тому, что

и в то же время устраняет


теперь видно?   

а теперь сравним с:
объект А совершает некоторое действия используя объект Б
причем ИМЕННО объект А совершает - т.к. он это умеет
правда нативней? (для нормального человека конечно   )   
а вот у тебя получается, что есть какая-то работа-не-пришей-кобыле-хвост, которая то-ли совершается объектом А над Б, то-ли совершается объектом Б над А, то-ли совершается дружными усилиями А и Б (ага, рабочего и молотка  ), то-ли совершается сама по себе над объектами А и Б


ну знаешь дАрАгой товарищ, совесть надо иметь
этот "по тексту" - единственная строка из цитируемого тобой абзаца, которую ты вырезал
тут уж трудно не заподозрить намерение   


да он (вывод) может быть каким угодно - главное что к делу он не относится, ибо злостный поклёп   


не совсем понимаю, о чем вопрос - о моем высказывании или о контексте в программировании?


видно ЧТО????
как с этим "видно" сообразуется фраза 

???
я все больше и больше в непонятках   

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

SVN74,

-1

а ты сможешь написать свой велосипед?  

Если страна потребует, напишу....  + несколько тысяч таких, как я и "Винда" готова....  


Это сообщение отредактировал(а) SVN74 - 9.11.2008, 16:32

SVN74, успехов тебе... Давай проведи исследования сначала на академическом уровне, потом реализуй с максимальной эффективностью твой алгоритм, опробуй в сотне проектов, потом хвастайся. С чего ты бы начал "дорогу к идеальному коду"?  

Шутка конечно.   
Все реально, если есть "маньяки - кодеры", ну и как известно в создании Windows XP участвовало около 50000 человек, правда это подсчитали вместе с уборщиками даже.   



Это сообщение отредактировал(а) SVN74 - 9.11.2008, 21:06

Незнай как вы.А я изучая С++ доволен  

Будущее С++ - увеличение статических возможностей, добавление небольших фич by popular demand, расширение поддержки шаблонов, расширение стандартной библиотеки за счет буста. Вряд ли будет что-то кардинально новое.

Не, это не так, за C# настоящее, а будущее, на мой взгляд, за языками параллельного программирования и за функционально- и аспектно-ориентированными языками. Однако Си изучать надо, так же как и ассемблер, для того, чтобы понимать как "это" работает на низком уровне, а вот использовать на практике вряд ли стоит, исключением будет лишь небольшой ряд узкоспециализированных областей.
А на поле "завтрашней битвы" мы скорее увидим MC#, AspectJ, Erlang, Alice, etc. Список претендентов весьма велик, их не один десяток, но лидеры ещё чётко не определились...
Так же стоит отметить тенденцию к переходу на тонкие клиенты, т.е. вероятнее всего веб-сервисы и в будущем продолжат укреплять свои позиции.

В принципе это уже его настоящее, которое можно выразить одним словом - стагнация. Я думаю, что сейчас разумно сравнивать позиции С++ с позициями ассемблера 10-15 лет назад. Пока ещё много поклонников, изучить желательно, но лишь для расширения кругозора. 

Заблуждаешься. С++ - язык для написания высокопроизводительных программ с низким футпринтом памяти. И в этом классе он давно вне конкуренции, а с новым стандартом станет еще лучше. Ты просто сравниваешь его с языками, предназначенными совсем для другого, да еще пытаешься самоутвердиться. Со стороны выглядит глупо.

Java - язык для написания переносимых и легко распределяемых систем, и в своем классе он лучший, в том числе и по производительности. C# - Delphi с наработками Джавы, предназначен для RAD. Python и Ruby - языки, предназначенные для макисимизации продуктивности программиста, во многом они достигают этого за счет полного отказа от претензий на производительность. И это я только коснулся классификации императивных языков, а ведь есть еще и логические (Prolog, для решения оптимизационных задач), функциональные (Haskell, для решения широкого круга математических задач), декларативные (SQL, для унификации запросов к реляционным базам данных) и еще многие, о которых мне не известно 

Kallikanzarid, можно примеры?

Я в этом предложении согласился с твоим пассажем, и ты же говоришь, что ты заблуждаешься... Определись уж, а то твои метания выглядят весьма глупо... Сам сказал - сам опровергаешь   
это и есть стагнация!!!




где?   
Где я в этом топике что-то с чем-то сравнивал? О возможности сравнения языков даже речи не шло,  читай внимательнее, если с первого раза не понял смысл прочитанного..

Лучше б ты вообще этой классификации не касался, умнее выглядел бы  

Декларативные языки поставил в один ряд с логическими и функциональными, хотя функциональная и логическая парадигмы - подвиды декларативной парадигмы, а SQL кстати относится к ещё одному подвиду декларативных языков - языки предметной области (DSL)

Сравнивать парадигмы не стоит, но каждой своя пространственно-временная область, вот как раз об этом и топик, что время императивных структурно-ориентированных языков, таких как С, С++, Delphi уходит, а область их применения стремительно сокращается. На смену им приходят другие парадигмы, в данный момент мы наблюдаем господство ОО-парадигмы, но и оно лишь временное явление...
"Всё течёт - всё изменяется" (с) Гераклид

Интерестно какой язык можно изучить и быть увереным что он не устареет?  

Развели дяденки спор - можно ставки ставить?  

теперь моя очередь идти в   

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

2. Чтобы молоток начал завинчивать шурупы в стены совсем не важен язык программирования с++ или с#, потому что на любом языке программирования (c++/c#) это можно реализовать достаточно легко и непринужденно. Тогда встает вопрос - зачем мне молоток который может завинчивать шурупы когда у меня есть отвертка? ведь молоток завинчивающий шурупы в корни ломает все мои стериотипы - а стало быть извращение. и тут тоже вопрос спорный - потому что допустим пиво я пью с лимоном и солью - я извращенец? нет скорее у меня вкус такой и мироощущение. Так что не важно какой язык - че удобно то и пользуем (оглядываясь на девелоперов из команды и главного архитектора с менегерами и есесно заказчика который как обычно хочет сразу все и за меньшие деньги).

3. Архитектура, защита типов данных и конечно же гребаные утечки памяти.
     А вот тут С++ ошень проигрывает С#. Только не надо бить меня сейчас палкой - вы сами понимаете что многие проблемы которые вылезают в процессе эксплуатации програмного обеспечения можно было избежать - причем методом банального чтения отладочных сообщений вашего компилятора и поиска этих ошибок и БЛИН КОМПОТ исправлений онных. Не секрет что многие "ворнинги" у компила с++ в таком же коде на с# просто спаткнется с ошибкой или выкидоном исключения. Это уже вопрос профессионализма - не так ли?

Что косается кто помер - кто не помер - кто гламурней и красивше: То тут неизвесно что будет. Ведь вы сами понимаете что потдержка языка непосредственно завязана на компиле - а компил завязан на архитектуре машины. Вот я ж не заю полечу я завтра на алфацентавру потому что сегодня изобрели гравицапу?

  

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

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


Ошибки в архитектуре не зависят от языка, так что при обсуждении языков их рассматривать нет смысла. Я бы немного переформулировал текст цитаты: "в сложных проектах, утечки памяти возникают не только из-за ручного управления памятью."  

используемого довольно редко

А теперь по ближе к теме - "Будущее С++"  

Когда Н. Вирта спросили: "Ваше мнение о языке C#?",  он ответил - "...C# гораздо лучше чем C++."

Подробнее тут.

Avaj, дык конечно, пытается пропихнуть свой проект(он учавствует в разработке C#).

а разве не Андерс Хейлсберг?

nerezus, Вирт?   Что ты, что ты!  


  

Пардон, что-то попутал.

на данный момент сам C++ ведь исползуеться разработчиками?

Как прикажите понимать?

Я имел ввиду что на данный момент то есть 2008-2009 год на языке С++ осуществляются большие проекты?

А то как же.

Я даже не представляю на чем еще вести проекты для промышленности. Только старик С/С++ и выручает.

Это сообщение отредактировал(а) mrbrooks - 21.1.2009, 17:14

Обнадеживает что мои накапливающиеся знания будут полезны.

mrbrooks, ой, ну умоляю не надо таких громких заявлений. Только... Слишком широко обощил! Холивара хошь?

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

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

Драйвера на заводах это да, но это максимум 1% рынка труда для программиста, а скорее даже гораздо меньше...
Те же программы автоматизации производства могут быть когда-то давно написаны на С++ и сейчас руководство завода просто не захочет переходить на что-то более надёжное...
Это нормальная эволюция главного языка отрасли, выглядит она примерно так:
C++ -> Java -> C# -> ...

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

Это так же как математика, пока ты решаешь задачи на уровне арифметики, ты не поймёшь зачем нужно дифференциально-интегральное исчисление... И тут два пути: 
1) понять самому что для интегрирования пользоваться арифметикой не удобно и найти альтернативу; 
2) с самого начала узнать, что существует дифференциально-интегральное исчисление, и пытаться с его помощью решать арифметические задачи.
Первый путь правильнее, хотя второй и короче...   

 Java на одном уровне с C# все же.

я бы сказал так
C++ -> Java
  

Думаю С++ потом С (хотя...) потом подумаю  

haskell  

Lazin  а хаскел в какой области применяется?