Здравствуйте, CreatorCray, Вы писали:
CC>>>С 2005-й тоже сравнивал, если ты не заметил. AVK>>2004 год. CC>2010 еще не вышла.
Зато вышла 2008. Примерно в то же время, что и icc 10.1.
AVK>>А, религия. Ну тогда ладно. CC>Т.е. нормальным считается понаставить кучу совершенно ненужного говна?
Нормальным считается сравнение инструментов одного возраста. А уж, учитывая что сейчас ты занимаешься разработкой на C#, твои отмазки про то, что VS 2003 самое оно, выглядят ну очень неубедительно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, VladD2, Вы писали:
E>>Другими задачами ИИ... VD>А, можно подробнее?
Зачем тебе?
E>>Думаю, при нужде, мог бы порешать и эти (кроме СУБД. Там решать уже нечего ) VD>Ага. 640 Кбайт хватит всем (с) Бил Гейтс
Ну, сейчас, если и развивать СУБД, то лучше из уже имеющейся, работающей системы...
А они, сюрприз-сюрприз -- обычно на С/С++ написанны...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, AndrewVK, Вы писали:
CC>>Document Explorer AVK>MSDN Library и внутренняя справка VS.
при установке ТОЛЬКО C++ без MSDN.
CC>>Web Authoring AVK>Team Suite ставил?
Нет
CC>>SQL Server Compact + SQL Server Design tools AVK>А разве его нельзя отменить?
Нет
CC>>SDK for .Net framework tools AVK>Как такового, отдельного .NET SDK в 2008 студии уже нет, есть Windows SDK 6.0A.
И тем не менее в процессе инсталляции 2008й нечто под таким названием пытается ставиться
CC>>SQL publishing Wizard AVK>Функционал самой студии.
Зачем он при установке только С++
CC>>А оно ставится всегда и без спросу. AVK>Ужос просто.
И не говори
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, AndrewVK, Вы писали:
AVK>А уж, учитывая что сейчас ты занимаешься разработкой на C#, твои отмазки про то, что VS 2003 самое оно, выглядят ну очень неубедительно.
Ты читаешь вообще что я пишу?
в 2003-ю у меня поставлен ICC
Что это означает?
Теперь касательно С#
На работе установлены 2003,2005 и 2008
Из них быстрее всех работает 2003я
На ее фоне 2008 — обнять и плакать.
Отладчик в ней чутка поудобнее, да.
Dual Core, 2Gb ram...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, VladD2, Вы писали:
VD>Я правильно понял, что ответ на мой вопрос — "нет"?
Нет, неправильно. Ответ на твой вопрос -- "не важно".
E>>И в наших задачах, например, С++ очень удобен, так как представляет довольно адекватную абстракцию компьютера, с одной стороны, и при этом позволяет писать довольно абстрактный код, при этом имеющий строго определённую и понятную процедурную семантику...
VD>Как ты можешь судить об удобстве чего-то не попробовав альтернативы?
Я пробовал разные альтернативы в разных экспериментах. IMHO выигрыш несущественен. Возможно потому, что С++ я знаю очень-очень-очень хорошо, а альтернативы просто знаю. Но я много разных средств разработки использую при проведении экспериментов. Мало того, я использую для некоторых задач языки и средства собственной разработки
Но чаще всего С++ всё же, так как тупо удобнее. Опять же есть хорошее и привычное окружение. И в случае чего, удачные эксперименты могут быть бесшовно интегрированы в существующую систему...
Кроме того, С++ всё-таки позволяет делать зело производительные считалки. Так что эксперименты на С++ частенько ещё и сходятся быстрее...
E>>Правда им надо уметь свободно владеть. Для меня сложность кодирования какого-то уже известного алгоритма, представляется чем-то странным. Это же чисто технический вопрос. Он не требует исследований и всегда легко сходится
VD>Алгоритмы бывают весьма сложными. Например, алгоритм вывода типов в современном ЯП или алгоритм сжатия данных. Реализовывать их лопатой вроде С++, то реализация будет в десятки (а то и в сотни) раз сложнее спецификации. За тем и нужны более высокоуровневые и удобные языки, чтобы уменьшить разницу между спецификацией и реализацией. Кроме того обычно алгоритмы выражаются не четко и при их реализация почти всегда становится процессом творческим, что опять таки значительно проще осуществить используя удобный, мощный, высокоуровневый язык, нежели ассемблер с классами. Так что твои слова выглядят как хвастовства и бравада. Но понять ты это не сможешь если сам не освоишь хотя бы один более высокоуровневый язык.
И то и другое -- сравнительно простые алгоритмы. Сильный студент нужного направления, за полгодика тебе его разработает и не сильно напряжётся, даже. А есть системы с трудоёмкостью разработки десятки, если не сотни человеко-лет квалифицированных исследований...
Ты никак не можешь понять, что для действительно сложных ИИ алгоритмов (ну, например, алгоритм работы переводчика, работающего на качестве уровня человека), написать точную спецификацию и предоставить все необходимые данные =def= решить задачу. С++ уже достаточно хорош, для того, чтобы в таких задачах затраты на кодирование были несущественны... Во всяком случае для тех, кто его знает и использует по делу, а не для написания вычурной приплюсни...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, CreatorCray, Вы писали:
AVK>>MSDN Library и внутренняя справка VS. CC>при установке ТОЛЬКО C++ без MSDN.
Я болдом выделил.
AVK>>Как такового, отдельного .NET SDK в 2008 студии уже нет, есть Windows SDK 6.0A. CC>И тем не менее в процессе инсталляции 2008й нечто под таким названием пытается ставиться
Это просто часть инсталляции WIndows SDK.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, CreatorCray, Вы писали:
CC>Вот нафига мне при установке ТОЛЬКО C++ без MSDN.
Всё это безболезненно удаляется после установки студии. А вообще, MS Open Tools (распространение чисто компилятора с либами, как в WDK) никто не отменял, тем более, что новые компиляторы без особых проблем подключаются к "старым" студиям. Или нужна именно свежая студия?
Здравствуйте, CreatorCray, Вы писали:
CC>Из них быстрее всех работает 2003я
Не показатель: vc6 работает ещё быстрее Но, в принципе, наилучшее соотношение легковесность/функционал в 2к5 с компилятором vc10.
Здравствуйте, VladD2, Вы писали:
VD>Так что большой респект и уважуха всем тем кто пишет что-то отличное от потоковых конвертеров видио и высокооптимизированных графических библиотек! Так держать товарищи!
Дык, дело бывает не в прикладных областях, а технических подробностях реализации неких требований. Кому нафик нужно абстрактная "красота" решения? На выходе коммерческого продукта интересует лишь его качество, которое суть — удовлетворение кошмарному списку требований. Ну не в состоянии платформы типа .Net и Java на сегодня охватить все эти требования (хотя они и охватывают приличную их часть).
Например, сделать макет серверной стороны какого-нить сервиса на TCP — дело нескольких минут на .Net, а заставить адекватно работать затем — просто невозможно из-за нынешней реализации тех же сокетов в .Net, вот народ и пишет прилично кода на С/С++. И дело тут не просто в прослойке, вынужденная ориентация на "обычную память" в таком решении тянет за собой в бездну этой неуправляемой памяти всё приложение. (Тут есть куча тонкостей, могу более технически конкретно указать, почему не прокатывает связь managed/unmanaged наподобии pinned-arrays, и еще о быстрорастущей стоимости пина и падении производительности GC, когда запинненых хаотично в памяти GC объектов под десятки тысяч)
Про обработку массивов данных уже говорил — тут .Net сливает совершенно непотребно, хотя, казалось бы, не требуется оперировать понятиями типа "память" и "процессор". Не хочет никак .Net эффективно обрабатывать массивы информации, ибо не умеет достаточно оптимизировать обращение к массивам (кроме одного практически неиспользуемого простейшего сценария в цикле for).
В общем, за время серьёзного использования .Net в течении последних 6-ти лет всё больше убеждаюсь, что управляемые платформы — точно такие же нишевые инструменты, какими являются сегодня C/C++.
Здравствуйте, VladD2, Вы писали:
VD>Человек выбирающий С# или Java для подобных задач значительно более разумен. А высшие существа и отличается от планктона тем, что могут думать и принимать разумные решения. Другое дело, что есть разные стадии развития. То что человек может понять, что С++ не лучшее средство для офисной автоматизации — еще не означает, что он дальше не выключит мозг и не начнет закидывать задачи буденновками.
Не получилось проигнорировать в который раз этот неудачный пример с оффисной автоматизацией.
Влад, её во все времена делали на VB/VBA, и даже сейчас на VB.Net куда как удобней, чем на на C# или тем более на Java. Можно было бы переиначить фразу: "то, что C# не лучшее вр-во для офисной автоматизации ..." и далее по тексту.
Всего пару раз видел на С++ простейшие обращения к задачам оффиса. Но опять же, ты хоть представляешь, как это делается на С++? Думаешь, там кто-то дёргает COM-интерфейсы или проверяет HRESULT или пишет AddRef/Release? Напиши #pragma import и посмотри на результат.
Я уже молчу о том, что некоторые COM-структуры (не только оффисные) просто не в состоянии лечь на доступную маршаллизацию .Net, и тут без С/С++ просто никак, хотя бы даже в качестве реализаций доступных из .Net обёрток.
VD>На счет "говна" не надо. Там как большей частью код приемлемый. Не без маразма конечно, но до маразма С++-ных библиотек им все же долеко. К тому же их отличает внятный и логичный интерфейс. С++-ные библиотеки почему-то очень часто имеют настлько невнятный интерфейс, что код использующих их превращается в полную кашу.
Интересное утверждение... Пример можно, кроме MFC/ATL?
VD>В Windows 7 ядро Висты, в Висте ядро, ХРюши, в ХРюше ядро 2000-ных, ... VD>Намек ясен? Ядро как было на С, так и остается. Ну, иногда пара, тройка расширений из плеюсов. Но ты никогда не дождешся, чтобы в ОС экспортировался интерфейс на С++.
Валялся... и бинарное устройство COM-интерфейсов вовсе не из С++ сложилось, и все новые API виндов вовсе не в COM-виде идут... Ты, Влад, малость оторвался от реальности.
Здравствуйте, eao197, Вы писали:
E>По поводу сбора данных -- it depends. Насколько я помню, бывают счетчики с ограниченным диапазоном значений -- не успел вовремя вычитать, он уходит в ноль. Получается, что работа с таким оборудованием -- уже hard RT. Если сбор данных будет сопровождаться каким-то управлением (типа открывания/закрывания задвижек), то опять может быть hard RT (слишком позднее срабатывание задвижки черевато аварией). Если система строится на основе ОС, не предоставляющей hard RT гарантии, то все равно лучше soft RT может ничего не получится. И т.д.
Скажу даже более того — если есть хоть какая-то коммутация ( свитчи там, маршрутизаторы ) то о жестком Реалтайме можно и не заморачиваться. Ну, кроме более других железных решений по совершенно другим ценам.
А управление железом по телемеханике — это мягкий РТ, кроме систем ПАЗ — так там софт вообще не ставят
Здравствуйте, vdimas, Вы писали:
V>Не получилось проигнорировать в который раз этот неудачный пример с оффисной автоматизацией.
V>Влад, её во все времена делали на VB/VBA, и даже сейчас на VB.Net куда как удобней, чем на на C# или тем более на Java.
Каждый читает именно то, что ему хочется. Под офисом здесь понимается именно офис, а не программа МС Офис.
P.S. Офис по русски пишется с одной ф.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, VladD2, Вы писали:
VD>>>Речь шла о преобразовании финансовых данных на биржах, как я понял. Поверить в то, что скажем на Лиспе это было бы сделать в разы проще программист не захотел.
N>>При работе на бирже необходимо очень высокое быстродействие. Как для анализа данных, так и для банальных автоматических торговых систем. Да, их пишут на С++. И нейросети для предсказания курсов на фондовых и валютных рынках тоже. А это как-никак область ИИ (это про твои высказывания о непригодности для интеллектуальных задач).
бред поскипан.
Никто крутую программу-предсказатель не будет продавать.
Реальные хорошие предсказатели разрабатываются не для продажи, а исключительно для внутреннего использования, чтобы (сюрприз!) зарабатывать деньги.
Причем под жестким NDA.
Это также к вопросу о том, что Nuzhny только один откликнулся.
Здравствуйте, AndrewVK, Вы писали:
AVK>Каждый читает именно то, что ему хочется. Под офисом здесь понимается именно офис, а не программа МС Офис.
Тогда тем более не понимаю. Я ту самую офисную автоматизацию (которая не программа), обычно делал именно с помощью офисных Outlook/Word/Excel/Access+VBA + DCOM/COM+ либы на VB (очччень редко на С++ отдельные компоненты, которые и сейчас бы не стал на C# делать).
И мне трудно сходу придумать офисную задачу, которую невозможно решить даже этим небольшим списком инструментов, хоть и знаю о предмете почти всё, благо посвятил ему около 4-х лет в своё время.
А если еще взять Exchange/Sharepoint/LDAP/TAPI + новое клиентское SIP-решение в последних офисах + IM + конференции, аппшаринг и пр. (всё c полной COM-автоматицией, + экзотика навроде InfoPath/EDI/HIPPA), то придумать невписываемую в этот круг офисную задачку, претендующую на автоматизацию (не COM-автоматизации, а той, про которую твоя поправка ) — то это палец долго сосать надо, или небо им тыкать... тем более, что упомянута здесь лишь малость из доступного.
Что-то делать на C# — это разве что intranet какой-нить (который никто никогда на С++ и не делал, если вернуться к сути обсуждения), и то, большой еще вопрос, какова должна быть доля browser-based приложений, ибо юзабилити ни в красную армию, да и печатные формы как ни старайся, а такого кач-ва как в MSAccess Report или Word не получишь. Я бы оставил intranet для веб-вервисов и высокоуровневой навигации (тем более, что HTML-страницы ембеддятся в MS Access как родные в привязке к данным из SQL Server, начиная с 2000-о офиса как раз таких сценариев).
AVK>P.S. Офис по русски пишется с одной ф.
С COM в .NET все достаточно неплохо.
K>>Это довольно странно, ведь D позиционируется как замена C++. FR>Угу именно как замена, полноценную же подержку C++ можно реализовать только сделав C++ подмножеством D.
Да я понимаю, что корень проблем не столько в D, сколько в C++ — но проблемы-то это для D.
K>>Учитывая, что в .NET языках можно использовать библиотеки на C++ благодаря C++/CLI, кое-что написаное на Java, не говоря уже о всех библиотеках для .NET, а .NET библиотеки можно использовать, соотвественно из C++ и худо-бедно из Java, практически любой язык — CLS extender находится в гораздо менее глубокой ж..., как вы выразились, чем D. FR>Учитывая прозрачную связь с си http://www.digitalmars.com/d/2.0/interfaceToC.html и вышенаписанное у D в этом отношении все вполне нормально. FR>Ж.. же одинаковая не техническая а политическая, выражающаяся в близкой к нулю популярности обоих инструментов.
Ну, ломающие изменения и внезапное разделение на две ветки, одна из которых с точки зрения потенциального пользователя выглядит мертвой, а вторая обещает разнообразные переживания из-за своей волнующей нестабильности, популярности не добовляет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, VladD2, Вы писали:
VD>Не достаточно. Надо чтобы они везде валялись. К тому же по Лиспу нет ни одного хорошего учебника на русском. Это факт.
В SICP — не Lisp а Scheme. На самом деле, хотя идея одна, реализации сильно отличаются (например, Scheme сильнее поощряет ФП). Но это не учебник по Scheme, а учебник по программированию вообще. После его прочтения я много хорошего узнал, но практически не получил реальных знаний для написани чего-то "большого" на Lisp или Scheme.
)
