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

Форум программистов > C/C++: Общие вопросы > Что люди пишут на C++. Кто за это готов платить.

Автор: exceilence 4.1.2010, 09:29

Можно ли узнать хотяб пару конкретных вещей, которые Вы делали и за которые получили вознаграждение. Разработка на C++ времязатратная и дорогая, программиста учить долго и дорого. Поддерживать тоже дорого.  Кто потенциальный заказчик? Чего людям не хватает, что они платят за С++? Я представляю гос компании, где деньги особо не считают. Главное отчитаться что туда-то их списали. Ну или очень большие негос компании. И вообще на C++ надо хорошенько поискать заказчика. Или даже сам заказчик сразу себе наймёт на разработку и поддержку несколько программистов...  но не обратится в контору.

Автор: baldina 4.1.2010, 10:48

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

Автор: kemiisto 4.1.2010, 14:23

Цитата(baldina @  4.1.2010,  11:48 ) Люди платят за результат. И уже сейчас для достижения результата С++, мягко говоря, не лучший вариант.   Цитата(baldina @  4.1.2010,  11:48 ) С++ - язык общего назначения с мощными языковыми возможностями; Можно С++ заменить на C#, Java, whatever в этом предложении и оно будет верным. Верным настолько же, насколько и для С++.   Цитата(baldina @  4.1.2010,  11:48 ) программа на С++ может хорошо поддается автоматической оптимизации; Особенно хорош С++ в многопоточности и параллелизме. Просто сказка.   Цитата(baldina @  4.1.2010,  11:48 ) поддерживаемые парадигмы программирования являются центральными в разработке крупного ПО. Да? А ну-ка, расшифруй! Цитата(baldina @  4.1.2010,  11:48 ) В моей компании (частная, небольшая) С++ - основной язык разработки коммерческих прикладных программ Я ключевые слова выделил. Вы вымрете как мамонты. Или измените приоритеты.

Автор: Static 4.1.2010, 14:53

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

Автор: djamshud 4.1.2010, 14:58

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

Автор: Lazin 4.1.2010, 15:00

инерция

Автор: Lazin 4.1.2010, 15:19

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

Автор: baldina 4.1.2010, 15:20

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

Автор: kemiisto 4.1.2010, 15:54

Цитата(Static @  4.1.2010,  15:53 ) kemiisto,  тебя когда-то обидели преподаватели С++?  Нет.   Цитата(djamshud @  4.1.2010,  15:58 ) Static, скорее всего у него не было преподавателя С++, а учили его обезумевшие дотнетчики. Вот и результат.  И опять мимо!   Цитата(Lazin @  4.1.2010,  16:00 ) инерция Ёмко и толсто.  Пригодиццо!

Автор: W4FhLF 4.1.2010, 15:54

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

Автор: kemiisto 4.1.2010, 15:56

Цитата(W4FhLF @  4.1.2010,  16:54 ) kemiisto, что ж ты такой зануда? Зато смотри, как тема сразу оживилась.

Автор: W4FhLF 4.1.2010, 16:05

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

Автор: andrew_121 4.1.2010, 16:54

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

Автор: Фантом 4.1.2010, 17:02

Цитата(andrew_121 @  4.1.2010,  16:54 ) но я, честно говоря, не представляю, на каком ЯП писать системный софт Просто C не подходит? Там, где софт действительно системный.    P.S. Я бы предложил Forth или Ada, так ведь съедят...

Автор: andrew_121 4.1.2010, 17:36

Цитата(Фантом @  4.1.2010,  17:02 ) Просто C не подходит? я об этом и написал.

Автор: djamshud 4.1.2010, 17:39

>Просто C не подходит? Там, где софт действительно системный. Часто бывает приятно писать на си, но с удобством, например с классами. А значит с++:).

Автор: Фантом 4.1.2010, 17:46

Цитата(andrew_121 @  4.1.2010,  17:36 ) я об этом и написал. Я к тому, что не надо для этих целей использовать С++.

Автор: andrew_121 4.1.2010, 18:03

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

Автор: Lazin 4.1.2010, 19:11

Цитата(djamshud @  4.1.2010,  17:39 ) >Просто C не подходит? Там, где софт действительно системный. Часто бывает приятно писать на си, но с удобством, например с классами. А значит с++.  Там где софт системный, там, как правило удобства С++ выходят боком, там не нужна глубокая абстракция, все должно быть явным. К тому-же, концепция ООП не лишена недостатков, к примеру данные, из которых состоят объекты, могут быть размещены в памяти не оптимально, что приведет к падению производительности из-за большого количества кэш промахов. Объединение данных и методов, а так-же данных одного объекта в одном месте - далеко не всегда эффективно. http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf Ну в общем, все как обычно - слишком низкая инкапсуляция это плохо, слишком много LOC, из-за чего код сложно понимать. Слишком высокая абстракция - тоже плохо, так как сложнее понять код и можно потерять производительность, может быть даже не понять где это произошло, из-за перегруженности кода ненужными абстракциями. С++ создавался в первую очередь для разработки сложного прикладного софта, иначе зачем в него включены средства ООП? Но так уж повелось, что на нем нынче пишут в основном не сильно сложный софт. Писать сложный софт на С++, который должен удовлетворять куче бизнес правил, это PITA

Автор: djamshud 4.1.2010, 19:35

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

Автор: zim22 4.1.2010, 19:46

Цитата(Lazin @  4.1.2010,  18:11 ) концепция ООП не лишена недостатков, к примеру данные, из которых состоят объекты, могут быть размещены в памяти не оптимально я считаю, что это проблемы не концепции ООП, а её реализации. Цитата(Lazin @  4.1.2010,  18:11 ) Объединение данных и методов, а так-же данных одного объекта в одном месте - далеко не всегда эффективно. http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf в этой PDF речь идёт об оптимизации кода, который недостаточно быстро работает. и сократили они это время за счёт того, что выбрали другое представление внутренней структуры объектов Node. От С++ они не отказывались. От ООП - тоже. Грубо говоря, сначала они искали запись в упорядоченном массиве за линейное время, потом додумались до бинарного поиска - и решили, что ООП и С++ - отстой, а они самые умные.  Игру для PS3 они ведь не на .NET или JAVA пишут, а на С++.

Автор: andrew_121 4.1.2010, 20:00

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

Автор: Lazin 4.1.2010, 20:40

Цитата(djamshud @  4.1.2010,  19:35 ) Кэш-промахи вы упомянули вообще зря, их можно нахвататься и в си, т.е. тут вопрос не в том, что плюсовый компилятор скомпилирует "кривой" машкод, а в том, что программист напишет "кривой" код.  программист напишет не кривой, а идиоматичный код, без извратов   Цитата(andrew_121 @  4.1.2010,  20:00 ) а прикладной софт можно писать на яве, на пайтоне, и еще на чем-то. это не показатель. прикладные ЯП имеют свойство умирать, однодневки так сказать. в этой области программирования, нет уверенности в завтрашнем дне. при том, рынок труда, перенасыщен прикладными программистами. и им совсем не просто найти работу, будучи новичками. отсюда следует, что смысла учить прикладной ЯП становится все меньше. работу все равно не найдешь. если ты конечно не гений. да да да, ты конечно прав, оставайся при своем мнении =) Цитата(zim22 @  4.1.2010,  19:46 ) в этой PDF речь идёт об оптимизации кода, который недостаточно быстро работает. и сократили они это время за счёт того, что выбрали другое представление внутренней структуры объектов Node. От С++ они не отказывались. От ООП - тоже. Грубо говоря, сначала они искали запись в упорядоченном массиве за линейное время, потом додумались до бинарного поиска - и решили, что ООП и С++ - отстой, а они самые умные.  сложность там не изменилась, они ничего не искали линейно, просто они реорганизовали код, перешли от OOD к Data Oriented Design

Автор: andrew_121 4.1.2010, 20:45

Цитата(Lazin @  4.1.2010,  20:40 ) ты конечно прав    Цитата(Lazin @  4.1.2010,  20:40 ) оставайся при своем мнении

Автор: Lazin 4.1.2010, 20:49

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

Автор: andrew_121 4.1.2010, 20:54

Цитата(Lazin @  4.1.2010,  20:49 ) ты всю жизнь собираешься на С++ писать что-ли?  нет. сейчас учу пайтон. для прикладных задач. ибо что-то сваять на скорую руку на с++, бывает весьма не элегантно.

Автор: Леопольд 5.1.2010, 11:24

Цитата(Lazin @  4.1.2010,  20:49 ) andrew_121, я в тебе и не сомневался, вот только скажи, ты всю жизнь собираешься на С++ писать что-ли?  Главное, хорошо знать язык, тогда работа будет спорится. Сторонними библиотеками можно просто пользоваться. Большой недостаток С++,  что-бы узнать его хорошо надо много времени.  Я вижу его применение в прикладном ПО таким: Ядро системы, со сложной архитектурой, пишется на С++, с использованием ООП. При аналогичных алгоритмах, скорость выполнения лучше чем у аналогичных императивных языков со статической типизацией. GUI пишется на чём-то поудобнее, С++ для GUI не лучший вариант, wxPython по моему удобнее. Однако не следует забывать что Python сам по себе на порядок медленнее С++, ибо интерпретируемый.

Автор: Elfet 6.1.2010, 23:02

Цитата(kemiisto @  4.1.2010,  15:23 ) Можно С++ заменить на C#, Java, whatever в этом предложении и оно будет верным. Верным настолько же, насколько и для С++. smile Нет, нельзя, если нужно быстродействие.  Цитата(Lazin @  4.1.2010,  20:11 ) К тому-же, концепция ООП не лишена недостатков,  Полностью согласен.  Вы пробовали когда-нибудь писать проект полностью на ООП? Получилось?

Автор: djamshud 6.1.2010, 23:36

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

Автор: Lazin 6.1.2010, 23:51

Цитата(Elfet @  6.1.2010,  23:02 ) Нет, нельзя, если нужно быстродействие. нет можно, если нужно быстродействие   Цитата(Elfet @  6.1.2010,  23:02 ) Вы пробовали когда-нибудь писать проект полностью на ООП? Получилось? вообще я совсем не против ООП, даже наоборот, у меня ООП головного мозга, я везде его применяю, это просто вопрос реализации, просто ООП должно быть fine grained, если можно так выразиться

Автор: andrew_121 6.1.2010, 23:55

Цитата(Lazin @  6.1.2010,  23:51 ) нет можно, если нужно быстродействие ааа... быстродействие написания.

Автор: Lazin 7.1.2010, 00:00

Цитата(andrew_121 @  6.1.2010,  23:55 ) ааа... быстродействие написания нет, просто быстродействие как будто только на С++ можно написать программу, использующую мало ресурсов... быстродействие зависит от того, насколько хорошо программист понимает как работает его код, можно и на пайтоне написать хороший код

Автор: djamshud 7.1.2010, 00:02

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

Автор: GoldFinch 7.1.2010, 00:04

Цитата(Lazin @  7.1.2010,  00:00 ) как будто только на С++ можно написать программу, использующую мало ресурсов... быстродействие зависит от того, насколько хорошо программист понимает как работает его код, можно и на пайтоне написать хороший код  докажи уже хоть как-нибудь

Автор: Lazin 7.1.2010, 00:08

Цитата(GoldFinch @  7.1.2010,  00:04 ) докажи уже хоть как-нибудь я даже тему создавал в рел.войнах, но никто не вызвался

Автор: GoldFinch 7.1.2010, 00:28

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

Автор: andrew_121 7.1.2010, 01:09

Цитата(Lazin @  7.1.2010,  00:00 ) нет, просто быстродействие как будто только на С++ можно написать программу, использующую мало ресурсов... нет, почему же. но здравый смысл подсказывает, что то, что работает на ВМ(прослойке), не может работать быстрее. Цитата(Lazin @  7.1.2010,  00:00 ) можно и на пайтоне написать хороший код  о_О это радует  Цитата(djamshud @  7.1.2010,  00:02 ) Часто в явах и прочих дотнетах уже оптимизировано то, что плюсятник будет писать вручную, и что возможно напишет намного хуже.  т.е. нынче, ВМ уже проводят эвристический анализ кода, и по своему усмотрению, подменяют некоторые куски кода, своим кодом? - сам то веришь? ;) Цитата(Lazin @  7.1.2010,  00:08 ) я даже тему создавал в рел.войнах, но никто не вызвался где? ссылку плиз.

Автор: mes 7.1.2010, 01:15

Цитата(andrew_121 @  7.1.2010,  00:09 ) эвристический анализ кода дело не в эвристических способностях, а в языковых средствах..

Автор: andrew_121 7.1.2010, 01:19

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

Автор: djamshud 7.1.2010, 01:27

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

Автор: Oxy 7.1.2010, 01:31

Цитата(andrew_121 @  7.1.2010,  01:09 ) где? ссылку плиз. http://forum.vingrad.ru/forum/topic-283805/0.html

Автор: Lazin 7.1.2010, 01:34

Цитата(GoldFinch @  7.1.2010,  00:28 ) ты там сам не вызвался Цитата(Lazin @  14.12.2009,  11:52 ) В общем, я предлагаю такой challenge - выбираем задачу, но только не синтетическую, а достаточно близкую к жизни, вы пишете реализацию на своем "быстром" %favorite language%, а потом я пишу то-же самое на "тормзном" C# или Java, или еще чем-нибудь. Моя реализация отстает по скорости не более чем на 25%, а скорее всего рвет вашу как тузик тряпку xD. Ну и естественно, приложение должно полностью утилизировать современные многоядерные процессоры, а куда без этого? вот как-то так только задача должна быть не синтетической, это главное условие, ибо на синтетических тестах плюсовый код, естественно, нагнуть не получится  но вообще, у меня сложилось впечатление, что со мной никто не хочет связываться из-за того, что большинство придерживается того-же мнения что и я   Цитата(GoldFinch @  7.1.2010,  00:28 ) алсо ты недавно ссылку на сравнение ЯП кидал, это не показатель? also, у меня интернет зависимость, поэтому я чего только и куда только не кидал, но если ты о great language shootout, то там - синтетические тесты Цитата(andrew_121 @  7.1.2010,  01:09 ) нет, почему же. но здравый смысл подсказывает, что то, что работает на ВМ(прослойке), не может работать быстрее. Цитата(andrew_121 @  7.1.2010,  01:19 ) mes, обьясните, пожалуйста, как такое возможно? как ВМ проводит оптимизацию(если проводит) ? а как-же JIT?   Цитата(andrew_121 @  7.1.2010,  01:09 ) где? ссылку плиз. http://forum.vingrad.ru/forum/topic-283805.html

Автор: Elfet 7.1.2010, 03:58

Цитата(Lazin @  7.1.2010,  01:00 ) нет, просто быстродействие как будто только на С++ можно написать программу, использующую мало ресурсов... быстродействие зависит от того, насколько хорошо программист понимает как работает его код, можно и на пайтоне написать хороший код  Я вот сейчас занимаюсь разработкой программы для расчета течения несжимаемой вязкой жидкости для машущего крыла. Количество ячеек сетки по которым идет расчёт примерно Re^9/4. При числе Рейнольдса(Re) = 300 000, это примерно: 1.8*10^11 ячеек.  Кроме как на С++ здесь ничего другой не подойдёт. Добавлено через 3 минуты и 21 секунду Запускал расчёты на своём домашнем компе - так один у меня длился целую неделю!  Сейчас нам выделили 16 ядерный кластер, будем распараллеливать под него.

Автор: W4FhLF 7.1.2010, 10:11

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

Автор: zim22 7.1.2010, 13:49

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

Автор: kemiisto 7.1.2010, 14:31

Цитата(Elfet @  7.1.2010,  04:58 ) Кроме как на С++ здесь ничего другой не подойдёт. Да прямо. Fortran, это как минимум.    Цитата(Elfet @  7.1.2010,  04:58 ) Сейчас нам выделили 16 ядерный кластер, будем распараллеливать под него.  Вот Lazin вам про это твердит-твердит. А вы...  Ну возьмёшь ты проклятый MPI, начнёшь распараллеливать... Опыть то есть? Смотри, это такой дикий ужос... Вот это и есть олдскулл. Пишем последовательные код, а затем, помолясь, пытаемся распараллелить. Вообщем, смотри. Есть такая контора http://en.wikipedia.org/wiki/DARPA (The Defense Advanced Research Projects Agency). Один из текущих проектов, заканчивающийся в этом году, - http://en.wikipedia.org/wiki/High_Productivity_Computing_Systems (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! А вам бы только ++...

Автор: GoldFinch 7.1.2010, 14:33

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

Автор: nerezus 7.1.2010, 14:44

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

Автор: mes 7.1.2010, 14:57

Цитата(nerezus @  7.1.2010,  13:44 ) Тем более оперирование с сущностями, более абстрагированными от машины, проще для человека, что снижает риск человеческого фактора.  если только абстракция не дырявая, о чем может быть выяснено к сожалению слишком поздно. кстати насчет абстракции - она есть не только у ООП. Я не против ООП, наоборот считаю что это хороший прыжок в структурном программировании, но  имхо он  "в одиночку" уже не справляется с современными задачами..

Автор: Elfet 7.1.2010, 18:28

Цитата(kemiisto @  7.1.2010,  15:31 ) Цитата Кроме как на С++ здесь ничего другой не подойдёт. Да прямо. Fortran, это как минимум. smile   Я имел ввиду что на C# мы этого делать явно не будет-то

Автор: andrew_121 7.1.2010, 19:38

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

Автор: Курсант 14.1.2010, 17:35

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

Автор: nerezus 14.1.2010, 17:43

Цитата потому что когда на нем долго пишешь- начинаешь понимать внутреннее устройство того, что ты пишешь  Ровно как и на других ЯП в необходимых для них степенях.

Автор: djamshud 14.1.2010, 17:49

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

Автор: Курсант 14.1.2010, 17:49

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

Автор: baldina 14.1.2010, 18:55

Цитата майкрософт совсем не дурак со своим дот нет ага. только цели преследует несколько иные

Автор: bsa 14.1.2010, 21:12

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

Автор: Dem_max 15.1.2010, 08:28

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

Автор: baldina 15.1.2010, 11:41

Цитата(Dem_max @ 15.1.2010,  08:28) Цитата Я вот сейчас занимаюсь разработкой программы для расчета течения несжимаемой вязкой жидкости для машущего крыла. Количество ячеек сетки по которым идет расчёт примерно Re^9/4. При числе Рейнольдса(Re) = 300 000, это примерно: 1.8*10^11 ячеек.  Кроме как на С++ здесь ничего другой не подойдёт. Fortran с легкостью заменит твои расчеты на С(++) И даже Visual Basic. У нас один знатный спец, не программист, написал конечно-элементную программу на VB, размерность матрицы немаленькая, считает фронтальным методом. И довольно шустро, надо сказать, считает   Добавлено через 2 минуты и 54 секунды Что отлично подтверждает мысль о том, что правильный выбор метода, алгоритма, нормальное проектирование важнее оптимизаций на уровне ассемблера.

Автор: bsa 15.1.2010, 12:56

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

Автор: xvr 15.1.2010, 13:17

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

Автор: Фантом 15.1.2010, 16:19

Цитата(bsa @  15.1.2010,  12:56 ) Думаю, для подобных вещей и существует MatLab...  Нет, тут MatLab не годится - слишком долго считать будет. Это, конечно, очень неплохой инструмент, но все-таки пригоден он в основном либо для решения не слишком ресурсоемких задач, либо для прототипирования.

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