Можно ли узнать хотяб пару конкретных вещей, которые Вы делали и за которые получили вознаграждение.

Разработка на C++ времязатратная и дорогая, программиста учить долго и дорого. Поддерживать тоже дорого. 

Кто потенциальный заказчик? Чего людям не хватает, что они платят за С++?


Я представляю гос компании, где деньги особо не считают. Главное отчитаться что туда-то их списали.

Ну или очень большие негос компании.

И вообще на C++ надо хорошенько поискать заказчика. Или даже сам заказчик сразу себе наймёт на разработку и поддержку несколько программистов...  но не обратится в контору.

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

В моей компании (частная, небольшая) С++ - основной язык разработки коммерческих прикладных программ (инженерное ПО - расчеты и проектирование). 
Конечно, это не единственный используемый язык. Часть кода (в т.ч. библиотечного) на Фортране, небольшая аппаратно-зависимая - на ассемблере.
Для специализированных применений используются специализированные языки. Например, для web используются php+javascript.


Вы себе совершенно неправильно представляете 

И уже сейчас для достижения результата С++, мягко говоря, не лучший вариант.  


Можно С++ заменить на C#, Java, whatever в этом предложении и оно будет верным. Верным настолько же, насколько и для С++.  


Особенно хорош С++ в многопоточности и параллелизме. Просто сказка.  


Да? А ну-ка, расшифруй!


Я ключевые слова выделил. Вы вымрете как мамонты. Или измените приоритеты.  

kemiisto,  тебя когда-то обидели преподаватели С++?

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

инерция  

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

kemiisto, хотел ответить по пунктам, потом решил - детский сад...

В религиозных войнах я не участвую. Но. Говорят, что теория подтверждается практикой. Практика такова - за 15 лет (столько существует компания) тенденции к вымиранию не наблюдается. Конечно, на общность я не претендую 

Нет.  


И опять мимо!  


Ёмко и толсто.  Пригодиццо!

kemiisto, что ж ты такой зануда? 

Зато смотри, как тема сразу оживилась.  

kemiisto, всегда найдутся те, кто тебя не знает.   

инерция и правда велика.
но я, честно говоря, не представляю, на каком ЯП писать системный софт. есть С/С++/асм есть наверное еще какие-то , типа Go. но что-то я бы не решился пока использовать его в проектах.
конечно, для прикладных задач, ЯП о-го-го...

Просто C не подходит? Там, где софт действительно системный.   

P.S. Я бы предложил Forth или Ada, так ведь съедят...

я об этом и написал.

>Просто C не подходит? Там, где софт действительно системный.

Часто бывает приятно писать на си, но с удобством, например с классами. А значит с++:).

Я к тому, что не надо для этих целей использовать С++.

Фантом, я и не использую. хотя иногда бывает очень удобно 

Там где софт системный, там, как правило удобства С++ выходят боком, там не нужна глубокая абстракция, все должно быть явным.
К тому-же, концепция ООП не лишена недостатков, к примеру данные, из которых состоят объекты, могут быть размещены в памяти не оптимально, что приведет к падению производительности из-за большого количества кэш промахов. Объединение данных и методов, а так-же данных одного объекта в одном месте - далеко не всегда эффективно.
http://research.scee.net/files/presentatio...ing_GCAP_09.pdf
Ну в общем, все как обычно - слишком низкая инкапсуляция это плохо, слишком много LOC, из-за чего код сложно понимать. Слишком высокая абстракция - тоже плохо, так как сложнее понять код и можно потерять производительность, может быть даже не понять где это произошло, из-за перегруженности кода ненужными абстракциями.
С++ создавался в первую очередь для разработки сложного прикладного софта, иначе зачем в него включены средства ООП? Но так уж повелось, что на нем нынче пишут в основном не сильно сложный софт. Писать сложный софт на С++, который должен удовлетворять куче бизнес правил, это PITA  

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

Lazin такой трололошка, я диву даюсь:).

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

я считаю, что это проблемы не концепции ООП, а её реализации.

в этой PDF речь идёт об оптимизации кода, который недостаточно быстро работает. и сократили они это время за счёт того, что выбрали другое представление внутренней структуры объектов Node. От С++ они не отказывались. От ООП - тоже. Грубо говоря, сначала они искали запись в упорядоченном массиве за линейное время, потом додумались до бинарного поиска - и решили, что ООП и С++ - отстой, а они самые умные. 
Игру для PS3 они ведь не на .NET или JAVA пишут, а на С++.  


Это сообщение отредактировал(а) zim22 - 4.1.2010, 19:46

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

Это сообщение отредактировал(а) andrew_121 - 4.1.2010, 20:01

программист напишет не кривой, а идиоматичный код, без извратов  


да да да, ты конечно прав, оставайся при своем мнении =)

сложность там не изменилась, они ничего не искали линейно, просто они реорганизовали код, перешли от OOD к Data Oriented Design

  


  

andrew_121, я в тебе и не сомневался, вот только скажи, ты всю жизнь собираешься на С++ писать что-ли?

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

Главное, хорошо знать язык, тогда работа будет спорится. Сторонними библиотеками можно просто пользоваться. Большой недостаток С++,  что-бы узнать его хорошо надо много времени. 
Я вижу его применение в прикладном ПО таким:
Ядро системы, со сложной архитектурой, пишется на С++, с использованием ООП. При аналогичных алгоритмах, скорость выполнения лучше чем у аналогичных императивных языков со статической типизацией. GUI пишется на чём-то поудобнее, С++ для GUI не лучший вариант, wxPython по моему удобнее. Однако не следует забывать что Python сам по себе на порядок медленнее С++, ибо интерпретируемый.

Это сообщение отредактировал(а) Леопольд - 5.1.2010, 11:27

Нет, нельзя, если нужно быстродействие. 



Полностью согласен. 

Вы пробовали когда-нибудь писать проект полностью на ООП? Получилось?   

>Вы пробовали когда-нибудь писать проект полностью на ООП? Получилось?

Если из этой сакраментальной фразы не следует, что писать на ООП вообще не нужно, то к чему она вообще?

нет можно, если нужно быстродействие  

вообще я совсем не против ООП, даже наоборот, у меня ООП головного мозга, я везде его применяю, это просто вопрос реализации, просто ООП должно быть fine grained, если можно так выразиться   

ааа... быстродействие написания.

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

>ааа... быстродействие написания.

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

докажи уже хоть как-нибудь

я даже тему создавал в рел.войнах, но никто не вызвался  

Lazin, ты там сам не вызвался

алсо ты недавно ссылку на сравнение ЯП кидал, это не показатель?

Это сообщение отредактировал(а) GoldFinch - 7.1.2010, 00:29

нет, почему же. но здравый смысл подсказывает, что то, что работает на ВМ(прослойке), не может работать быстрее.



о_О это радует 



т.е. нынче, ВМ уже проводят эвристический анализ кода, и по своему усмотрению, подменяют некоторые куски кода, своим кодом? - сам то веришь? ;)



где? ссылку плиз.

дело не в эвристических способностях, а в языковых средствах..
  

mes, обьясните, пожалуйста, как такое возможно? как ВМ проводит оптимизацию(если проводит) ?


Это сообщение отредактировал(а) andrew_121 - 7.1.2010, 01:20

>т.е. нынче, ВМ уже проводят эвристический анализ кода, и по своему усмотрению, подменяют некоторые куски кода, своим кодом? - сам то веришь? ;)

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

Это сообщение отредактировал(а) djamshud - 7.1.2010, 01:27

http://forum.vingrad.ru/forum/topic-283805/0.html

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


also, у меня интернет зависимость, поэтому я чего только и куда только не кидал, но если ты о great language shootout, то там - синтетические тесты



а как-же JIT?  


Пост превосходства современных ЯП, над олдскульными

Я вот сейчас занимаюсь разработкой программы для расчета течения несжимаемой вязкой жидкости для машущего крыла. Количество ячеек сетки по которым идет расчёт примерно Re^9/4. При числе Рейнольдса(Re) = 300 000, это примерно: 1.8*10^11 ячеек. 
Кроме как на С++ здесь ничего другой не подойдёт.

Добавлено через 3 минуты и 21 секунду
Запускал расчёты на своём домашнем компе - так один у меня длился целую неделю! 

Сейчас нам выделили 16 ядерный кластер, будем распараллеливать под него.

Elfet, твоя задача очень хорошо распараллеливается. Я бы ещё запустил на GPU (топовая видеокарта стоит на порядок дешевле 16 ядерного кластера), тут как минимум на два порядка можно снизить время выполнения. 

гуру ООП (Гради Буч, Роберт Максимчук и другие) в книге "Объектно-ориентированный анализ и проектирование с примерами приложений" привели реализации следующих систем, построенных на ООП:
1) Спутниковая система навигации
2) Система управления трафиком
3) Искусственный интеллект: криптоанализ
4) Сбор данных: метеорологическая станция
5) Web-приложение: система планирования отпусков

так что ООП - живее всех живых. просто перед фазой кодирования нужны фазы анализа и проектирования 

Да прямо. Fortran, это как минимум.   


Вот Lazin вам про это твердит-твердит. А вы...  Ну возьмёшь ты проклятый MPI, начнёшь распараллеливать... Опыть то есть? Смотри, это такой дикий ужос... Вот это и есть олдскулл. Пишем последовательные код, а затем, помолясь, пытаемся распараллелить.

Вообщем, смотри. Есть такая контора DARPA (The Defense Advanced Research Projects Agency). Один из текущих проектов, заканчивающийся в этом году, - HPCS (High Productivity Computing Systems).

В рамках этого проекта идут разработки:

• X10 (IBM) - расширенное подмножество Java. Уже вышла вторая(!) версия. Два бекэнда - Java и С++. Уже есть свой Eclipse-plugin (кто-бы сомневался).
• Chapel (Cray) - пока в разработке. Мне синтаксически понравился больше. Ближе к Pascal.
• Fortress (Sun) - слишком революционно. Смесь Fortran + ФП (в основном Haskell-like). Уже денег лишились. Разработка затянулась, сейчас сделали ставку на open source, на community.

И ведь это не просто там конторки какие-нибудь, а ключевые вендоры в HPC. Видишь как тут всё просто - либо расширать Java, либо разрабатывать что-то с нуля, либо уходить в сторону AG&

The future is now! А вам бы только ++...

Это сообщение отредактировал(а) kemiisto - 7.1.2010, 14:31

zim22, я могу привести примеры систем написанных на ассемблере, но это ничего не говорит о том, стоит ли писать на ассемблере

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

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

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

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

Я имел ввиду что на C# мы этого делать явно не будет-то 

Вот собственно и задача: http://forum.vingrad.ru/index.php?showtopi...t&p=1403455

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

 Ровно как и на других ЯП в необходимых для них степенях.

Курсант, на с++, в полном отрыве от си (т.е. stl,boost,Qt,etc.) - хрен поймешь, что там и как. Микроскопы - это си и ассемблер.

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

ага. только цели преследует несколько иные

Начинающим это знать, имхо, совсем не нужно. Достаточно показать ассемблер, и как на нем решаются элементарные задачи, чтобы было понимание того, как процессор работает.
Интересно, а у процессоров с отличной от x86 архитектурой что-то подобное есть? Или там "защищенный" только и есть? Или только "реальный". Короче, зачем вдаваться в конкретику? Есть ОС, она гарантирует, что один процесс отделен от другого - все.
ну и зачем это изучать? Тогда уж лучше Minix - исходники открыты, и задокументировано все для изучения. Думаю, и костылей меньше.
Сомневаюсь. Разве что только небольшие ассемблерные вставки в код Си. В машинных кодах уже давно никто не программирует с тех пор, как появились устройства ввода продвинутей тумблеров, так как слишком муторно и нечитабельно.

Fortran с легкостью заменит твои расчеты на С(++)

И даже Visual Basic. У нас один знатный спец, не программист, написал конечно-элементную программу на VB, размерность матрицы немаленькая, считает фронтальным методом. И довольно шустро, надо сказать, считает  

Добавлено через 2 минуты и 54 секунды
Что отлично подтверждает мысль о том, что правильный выбор метода, алгоритма, нормальное проектирование важнее оптимизаций на уровне ассемблера.

Думаю, для подобных вещей и существует MatLab...

Кстати, для расчетных задач Fortran подходит лучше, чем С/С++. В нем есть много допущений и соглашений, которые развязывают руки оптимизаторам. А в С есть много поинтеров, которые руки (оптимизаторам) не только связывают, но порой и вообще обрывают   

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