Для 700-метровой башни в равновесной атмосфере воздух у вершины всего на 7 градусов холоднее чем у подножия. В пустыне там запросто может быть и 20 и 30 градусов. Вода при такой температуре испаряется достаточно интенсивно чтобы распыленная вода заметно охлаждала воздух. С холодной водой (скажем подземной) возможно охлаждающий эффект будет еще заметнее. Что не испарится сразу — испарится по пути вниз пока воздух будет прогреваться спуском.
Вытяжные трубы (для всевозможных печей и т.д.) работают за счет того что труба заполнена более горячим воздухом чем воздух снаружи. Более горячий воздух => плотность ниже => градиент давления меньше => на верхнем конце трубы имеем избыток давления по сравнению с окружающим воздухом.
Данная станция работает ровно наоборот заполняя трубу холодным воздухом. Для холодного воздуха та же труба по тому же принципу создаст тягу вниз.
Опускающийся вниз воздух обычно нагревается за счет возрастающего давления (которое возрастает за счет существования силы тяжести). Без трубы и при стабильной атмосфере градиент температур выравнивается таким образом что если какой-то участок воздуха спускается ниже, то он нагревается при спуске ровно до температуры окружающего воздуха на этой меньшей высоте. Если этот участок нагреется меньше чем окажется температура окружающего его воздуха, то он окажется плотнее и в силу этого тяжелее окружающего его воздуха и продолжит спуск.
Берем теперь высокую трубу изначально заполненную тем же воздухом. Начинаем распылять у её вершины воду. Испаряющаяся вода охлаждает воздух, его плотность растет (как за счет снижения температуры так и за счет добавления водяного пара) и он начинает опускаться вниз.
Допустим теперь что у нас с какого-то момента в башне установится равновесие. Т.к. башня заполнена более тяжелым (мокрым и холодным) воздухом, то градиент давления в ней окажется выше чем в окружающем воздухе и давление у основания башни внутри будет больше давления воздуха снаружи (столб воздуха в башне весит больше и следовательно «сильнее давит» на основание). Этот перепад давлений означает что воздух будет выходить из башни и этот перепад можно использовать для генерирования электроэнергии.
Правда отбор воздуха из низа башни означает что воздух должен в ней двигаться, а это даст чуть другую картину — давление «внизу» будет по башне чуть ниже чем предписано «статикой» и воздух будет из-за этого меньшего давления непрерывно разгоняться вниз. Это даст стабильный ветер в башне направленный вниз и снизит статическое давление внизу. И тут можно поиграть меняющимся сечением башни чтобы этот ветер максимально усилить. Не знаю что из этого можно по максимуму выжать, там уже не очень тривиальный расчет получается :)
>> Распыление воды снижает температуру градусов на 5-10, максимум — это можно посмотреть по психрометрической таблице.
Психрометрическая таблица показывает что на 40-градусной жаре и при нулевой влажности можно и 15 градусов получить в психрометре — и это не предельный результат, т.к. там мы охлаждаем до этой температуры целый термометр
Прикинем расчет для воздуха. 1 грамм воды при полном испарении забирает 2.25 кДж тепла. Для охлаждения 1 кг воздуха на 1 градус требуется примерно 1 кДж. Распылив 7 грамм воды на 1 кг воздуха, при полном испарении воды мы понизим температуру воздуха на 16 градусов. Если исходный воздух имел температуру t=30 градусов, то после охлаждения температура составит t=14 градусов. При такой температуре и нулевой начальной влажности воздуха распыленные 7 грамм воды на 1 кг воздуха дадут влажность воздуха на выходе ~70%. Это значительно меньше 100%, поэтому при достаточно большой трубе это вполне достижимый результат.
На практике впрочем надо учитывать гравитационные эффекты и там все будет чуть сложнее. Коротко говоря, для влажного воздуха температура с падением высоты будет расти гораздо медленнее => будет больше градиент давления => воздух будет разгоняться трубой. На выходе трубы будет наблюдаться отнюдь не избыток давления, а напротив, будет газ с меньшим давлением но большой кинетической энергией.
2) Было бы прописано — наверняка бы работало :). Для проверки можете записать имя файла запрошенного приложением, поиском отыскать этот файл, кинуть к нему в папочку какой-нибудь экзешник (скажем переименовать notepad.exe в test.exe) и попробовать из папочки приложения этот экзешник по имени позвать.
2.1) Иногда бывает что после прописывания новых environment variables нужно перезапустить приложение, т.к. уже запущенное использует старые env
4) Похоже на баг связанный с апгрейдом студии со старой на новую (2008->2010), но если дело не в апгрейде или не лечится выбором правильной версии студии в Qt, то пофиксить подобное тяжело, согласен. Возможно здесь косяк Qt Creator, но иногда у самой Студии бывают такие глюки, однажды в компании с похожим сталкивались
Эта фраза мне напоминает — вобщем надо уметь водить тогда с 9ки на BWM желаниея пересесть не возникнет.
Давайте все же подбирать адекватные примеры. «Надо уметь водить, тогда с BMW на механике желания пересаживаться на Хонду с автоматом не возникнет». C++ имеет ведь крупные преимущества, особенно в скорости? Имеет. Вот и давайте смотреть на ситуацию где вождение требует определенной квалификации но окупается уровнем этого вождения, а остальные детали отличаются не столь сильно. Лично я умею ездить на механике — и желания перелезать на менее быструю и менее управляемую машину у меня не возникает, а вот скажем, супруга не умеет — и для неё автомат получается на порядок удобнее :).
Теперь по остальным пунктам
1) Тулинг у C# лучше, согласен. Но грамотно настроенный C++ немногим хуже. Лично мне, честно говоря, вообще хватает большинства дефолтных возможностей студии, но если есть желание подтащить фичи ближе к уровню C#, то просто ставится Visual Assist
1.1) Управление зависимостями — да, согласен, одно из самых слабых мест. Сложно, требует привыкания, подвержено багам. Но по моим впечатлениям и C# там неидеален. У нас в сборке как я писал есть C# код, причем он растащен по нескольким солюшенам и часть кода импортирует что-то из других солюшнов. Когда время от времени объем импортируемого меняют а другой солюшн обновить забывают, то Студия выдает совершенно безумные сообщения об ошибках импорта, из которых совершенно неясно как их исправлять. Просто вот мол есть объект такой-то, а откуда он вообще берется, где объявлен, где ищется — загадка. Из космоса, видимо, приходит. Где-то глубоко в настройках проекта прописан HintPath, вот только по нему и можно, считай, догадаться, где должно лежать недостающее. В плюсах подобные ошибки выдают гораздо более понятное сообщение. Впрочем возможно это дело привычки.
2.1. Async-Await дали у нас откровенно хреново читаемый код. Вот предсказуемый — это да, ибо копи-паст. Но в целом по крайней мере у нас он дал плохой код. Лучше чем то что бы сделал для решения той же задачи на C++ новичок, но намного хуже того, как можно было бы реализовать код нормально
2.2. Generics — это же официально недотемплейты, вроде :)?
2.3. С LINQ и вообще в целом с БД дел не имел, так что верю на слово что удобно :)
3. У C++ есть Qt и в паре с boost ом из «библиотек на все случаи жизни» больше просто ничего не надо. Специализированные библиотеки на все случаи жизни на C++ вообще найти проще, на C/C++ профессионального кода написано гораздо больше чем на C#.
3.1. boost это вообще-то очень разнородная коллекция. Там есть конечно зубодробительные темплейты, но большая часть библиотеки вообще-то как раз очень понятна и логична. Особенно удивительно слышать о том что «boost слишком сложно задизайнен» на фоне того что «stl единственная нормальная библиотека»: STL, особенно микрософтовский, как раз очень сложно устроен «внутри», да и головоломных решений типа codecvt и locale там хватает.
Ох. Давайте пройдемся вначале по тезису «из коробки».
Во-первых, имеет смысл разделять два разных продукта: Qt Creator (IDE) и собственно Qt (библиотеки). Это две совершенно разных сущности. Хотя Creator и создавался теми же людьми и для облегчения разработки с Qt, но все же судить по нему о Qt-как-библиотеке, тем более в выражениях «Qt требует танцев с бубном» было изначально плохой идеей.
Во-вторых, «из коробки», насколько я помню, Qt Creator идет с MinGW. Собственно именно как обертка для GCC / GDB он и создавался, ИМХО. Кросс-платформенный же продукт. GCC-то есть везде, а MSVC — только под виндой, естественно что для Creator это не основной поддерживаемый вариант. А под MinGW, насколько я понимаю, Qt Creator у Вас прекрасно встал сразу.
В-третьих, Qt + MSVS обычно подразумевает что в качестве IDE используется MSVS, причем это долгое время был «платный» вариант, не знаю как сейчас. Qt Creator + MS compiler — это довольно необычное сочетание и с позиции разработчиков Creator-а было подвигом вообще сделать соответствующую поддержку. Сейчас правда в списке скачиваемых версий есть специальные сборки под VS 2010 / 2012, но я их не пробовал и не знаю как они работают. Вы хотя бы такую сборку использовали или что-то другое? Если что-то другое, то довольно странно было ожидать что там все заработает без настройки :).
Теперь пройдемся по поводу «квалификации».
Начнем с двух общих фактов:
1) Qt — это библиотека
2) Qt Creator — это IDE подключающаяся к стороннему компилятору / отладчику
Из первого факта вытекает что
1) библиотеки должны быть совместимы с runtime библиотеками используемыми в программе и линкером которым эта программа собирается. Т.е. если проект собирается в MSVS, использующим свой способ линковки и подлинковывающим микрософтовский рантайм (который еще и разный для разных версий Студии), то библиотеки Qt должны быть собраны в MS-совместимом формате и желательно — той же самой версией Студии. Это общая проблема для любых библиотек подключаемых к MS-компилируемому софту и скорее всего у Вас были проблемы именно с этим пунктом.
2) Вы можете использовать динамическую или статическую линковку. Статическая линковка подразумевает для MS-компилируемого софта опять же специальную версию библиотеки (ибо у MS статически-линкуемые и динамически-линкуемые библиотеки различаются). Qt по умолчанию идет в динамическом варианте, который подразумевает что код Qt не запихивается непосредственно в генерируемый .exe файл, а лежит себе отдельно в виде динамической библиотечки (DLL) подгружаемой в момент загрузки. Если .exe не может найти эту DLL-ку — то он, странное дело, сообщит об этом — причем довольно внятным сообщением. Догадываетесь к чему я клоню? Это опять же очень общий момент, с ним сталкивался любой, кто хотя бы какие-то сторонние библиотеки хоть раз подключал.
2.1.) У пункта 2 есть ньюанс: эти библиотеки, в принципе, можно прописать где-нибудь в системных путях, чтобы они находились виндой автоматически. и для Qt это без проблем тоже делается вручную за две минуты. Почему это не реализуется «из коробки»? А потому что это не очень хорошая практика, так как возникают проблемы с конфликтом разных версий этих библиотек aka DLL hell. MS из этой проблемы выкручивается тем что поставляет разные библиотеки для разных версий Студии, причем пара-тройка разных (!) версий этих библиотек включается в комплект поставки операционной системы (!). Однако как я уже писал в (1), такой подход приводит к тому что приходится собирать специальные версии всех сторонних библиотек (включая Qt) раздельно для любой версии студии (для 2010 — свои, для 2012 — свои...) а когда выходит 2013 студия то, сюрприз-сюрприз — сборок многих библиотек под эту студию просто не оказывается. Qt следует более юниксовым подходом и обеспечивает возможность работать с несколькими версиями Qt тем что просит явно указывать путь к библиотекам которые предполагается использовать — и в Creator это прекрасно обыграно, там это делается в два клика с автодетектированием. Я понимаю что когда на компьютере стоит лишь одна версия Qt то это выглядит «лишней работой», но эта работа невелика, а на мой взгляд, «Qt way» в отношении поддержки разных версий библиотек правильнее чем «MS way».
3) При этом если Вы бы занимались созданием инсталляторов, то Вы бы знали, что нужные MS библиотеки на компьютере тоже штатно бывают не всегда (особенно когда у пользователя из ОС стоит что-то старенькое типа Windows XP) — и то что «из коробки» (tm) работает на Вашей машине может ВНЕЗАПНО сообщить что ему не хватает какого-нибудь MSVCR110.dll на компьютере Вашего пользователя. Вам-то его инсталлятор студии поставил, а пользователю уже как повезет, включил эту библиотеку в ОС микрософт или нет. Qt в этом отношении где-то честнее, отладили на своей машине и приложили все нужные DLL-ки — работать будет везде. А с MS вечно думаешь, включать ли ms redistributable в инсталлятор или нет.
Из второго же факта вытекает что
4) Qt Creator-у нужно указать где и какими тулами пользоваться и сделать эти тулы для него доступными. Что подразумевает какую-никакую но все же настройку
Я вообще прошу прощения за слова про квалификацию, это было грубовато с моей стороны. Но Вам, право слово, не стоило писать тезисы типа
А еще, скомпилированный студией экзешник можно запустить и он запуститься. Скомпилированный в QtCreator'e — ругается на отсутствие Qt. Т.е. запускать его можно только через отладку в QtCreator. Я пока еще не разбирался, почему так, но это тоже оставляет неприятный осадок. Что с Qt обяхательно нужны танцы с бубном, даже для каких-то элементарных вещей совершенно.
Мда. Послушаешь такие комментарии и задумаешься, стоило ли Qt создавать Qt Creator :-/.
Все-таки когда Qt надо было ставить как обычную библиотеку это требовало некоторой минимальной квалификации от её пользователя.
Проект — 3D сканер и CAD система к нему. И что до UI то я безусловно согласен что проблема там не в C#, а в энтузиастах, которые решили его применить. Да, звезд они с неба не хватают, хотя код они выдают вполне рабочий. Я просто не понимаю какой толк от использования C#/WPF? С квалифицированными специалистами на C++ результат будет лучше — C# не имеет в квалифицированных руках преимуществ перед С++. Я предполагал что от C# будет толк хотя бы в плане того что на нём менее квалифицированные товарищи смогут приличный UI быстро сделать. Как оказалось — тоже нефига, те кто говнокод на C++ пишут, на C# генерят еще более страшный говнокод. Где тогда ниша у C# и WPF, в чем преимущества этой технологии?
Вот я смотрю на наш проект и думаю: два человека работали над UI почти год. UI пока сводится, по сути, к двум десяткам кнопок и менюшек, которые надо оформить согласно дизайн-макету. На C# / WPF два средней руки специалиста сгенерили под это дело монструозный код который — при всей простоте функционала! — мало кто может понять. На мой взгляд это — EPIC FAIL технологии. Если бы те же двое пользовались Qt, они сгенерили бы за тот же срок чуть лучший по качеству проект, который было бы намного легче понять и в котором не было бы геморроя с интеграцией C# + C++. Если бы на месте эти двоих был один отличный специалист, то он реализовал бы на порядок лучший код на Qt за два месяца. Может отличный специалист и на WPF выдал бы отличный код за два месяца — но выгоды-то все равно не было бы. Вот с MFC было бы хуже, да — там 6 месяцев ушло бы у отличного специалиста, а те двое вообще непонятно что бы выдали. Но так трудно придумать что-то страшнее чем MFC.
Поменяем C# на %язык% и вуаля!
В какой-то степени да. На плюсах можно писать все что угодно. Но для некоторых проектов некоторые специально заточенные под такие проекты языки дают какую-то выгоду.
К Python у меня смешанные чувства. Он удобен для простеньких скриптов и управления, но качество кода, по крайней мере у нас, хромает в результате скоростной разработки на обе ноги. Как только python разрастается в что-то большее — получается сложная в поддержке и отладке хреновина. Плюсы хуже подходят для мелочи, но они масштабируются до сколь угодно больших проектов без потери качества и понятности кода.
На PHP писал код когда-то ооочень давно и этот язык оставил смешанное впечатление. Тогда я был новичком и мне он показался удобным (пишем в плюс: подходит для малоквалифицированных персонажей), плюс интеграция с веб-сервером куда удобнее чем в плюсах. Но сейчас я подобного качества код мне писать будет стыдно, а как его на PHP улучшить я не представляю. Может и можно, впрочем — не рискну судить, очень давно не занимался. В высоконагруженных проектах, впрочем, как я слышал, он дохнет — не случайно google на плюсах и JS свои веб-сервисы пишет. Я конечно понимаю что сегодня модно просто поставить дохрена серваков на которые нагрузку будет разбрасывать C++-код написанный гораздо более профессиональными ребятами :D, но я не люблю подобных решений.
С Java дел не имел, ничего не скажу. Коллеги, впрочем, как-то сталкивались с героями, замутившими лет восемь назад на Java огромную enterprise-систему. Говорят сделано все было по коду очень красиво, но тормозило и память жрало совершенно безбожно. Но я так понимаю что производительность Явы с тех времен заметно шагнула вперед, так что сейчас, вероятно, для каких-то проектов типа «красивого интерфейса к БД» это очень правильный выбор.
А вот для C#/WPF я нишу что-то не вижу. Для работы с БД думаю Java будет лучше. Для производительных десктопных приложений — лучше C++/Qt (и это не только наш 3D сканер и прочие AutoCAD-ы, но и такие приложения как Word и Excel). Для высокопроизводительных серверных приложений лучше голый C++, если вопрос производительности менее приоритетен чем скорость разработки — то какой-нибудь специализированный язык, хоть бы и PHP. Разве что нативные shareware приложения под винду делать, чтобы look&feel был аутентично микрософтовским и библиотеки не надо было в инсталляторе таскать.
Делаем сейчас один проект, который является развитием старого кода написанного на C++ / MFC. Тоже вот нашлись, хм, энтузиасты C# / WPF, запоровшие идею реализации проекта на Qt. Но огромную существующую базу алгоритмического кода переписывать на C# было заведомо дохлым вариантом. Решили в итоге, значит, сделать вычислительное ядро на С++, остальное — на C#. Благо что плюсы все равно значительно превосходят C# по производительности, а для нас это было критично.
Ну что… написали мы этот гибрид. Получился откровенный отстой. UI написан хрен знает как, поддерживать его может только пара человек, которые сами этот код и писали, C# код представляет из себя жуткую кашу, которую нормально читать невозможно. Нет я знаю конечно что те же люди и на C++ / MFC воротили хреновый код, но даже там его было легче читать и менять. А на C# / WPF те же товарищи наворотили вообще нечто трудновыразимое — и это в простеньком в общем-то по UI приложении! Я уверен что был бы там Qt — код был бы на порядок читабельнее, там очень сложно писать UI плохо. Посмотрел я на это дело и что-то ни малейшего желания использовать C# у меня после этого не возникло. Да, там прикольная библиотека. Да, прикольные языковые возможности. Но библиотек и на C++ хороших много (и Qt — одна из лучших), а эти языковые возможности на практике были густо использованы для того чтобы намешать черти какой код. Ну и нафига мне C#? Если я умею писать код, то на C++ он получается не хуже по читаемости, надежности и скорости написания чем код на C#. А если некоторые мои коллеги пишут код абы как, то и на C# они создают непонятную и заполненную багами хрень. Приплюсуйте сюда разнообразные трудноразрешимые баги которые вылезают в проекте из-за совмещения C++ и C#. Особенно рельефно это все смотрится на фоне того что плюсовое ядро мы капитально переписали на совершенно новую технологию — и после создания своей библиотечки работать с высоконагруженым параллельным кодом работающим в реал-тайме в плюсах — одно удовольствие. Работает быстро, практически без багов (две штуки… и ни одного из них специфичного для C++), код красивый.
В общем, надо на C++ уметь работать — и тогда никакого желания на C# переходить не возникнет.
Хотя для простеньких проектов C# может и неплох — если, как Вы сами же пишете, таскать с собой с десяток велосипедов.
Но мне в таких проектах тоже проще с Qt работать, там и велосипедов тащить не нужно.
Взяли другую выборку и сразу качество рухнуло до 40% ошибок? А где гарантия что если взять третью выборку, то ситуация не повторится?
Для обучения использовалась контрольная выборка? Или как это часто бывает обучали на всей базе данных и указанные проценты — это результат по выборке после обучения на этой же выборке?
Интел купила команду разработчиков компилятора работавших над «Эльбрусом», все остальное осталось в МЦСТ, в том числе IP — в структурах зарегистрированных на Каймановых островах. МЦСТ не имеет отношения к Intel.
А выпустить процессор не нарушив патентов легко — во-первых многое лицензируется (и у МЦСТ есть лицензии на Sparc), а во-вторых еще больше давно уже открыто за истечением всех мыслимых сроков давности либо не патентовалось изначально.
Все-таки 57.6 GFLOPs у интела — это теоретический пик. 51 GFLOPs — честнее, да и тот достигается лишь на тщательно оптимизированном коде
Эльбрус, насколько я понимаю, реально способен осилить около 24 GFLOPs в тех же условиях.
Другой вопрос что Интел гораздо лучше справляется с обычным компилируемым кодом без его ручных оптимизаций.
Если исправить ошибку (globik сравнивает single-precision у эльбруса с double-precision у intel), то всего вдвое. Это на специально оптимизированном (в том числе вручную) коде. На просто скомпилированном разница меньше, intel часто даже быстрее в пересчете на такт. При этом у того же Интела как известно нарастить частоту у аналогичных Эльбрусу процессоров не получилось + с ростом частоты процессор начнет сильнее упираться в память и его эффективность снизится.
Это 50 GFLOPs в режиме single-precision, тогда как для Intel Вы приводите данные по double-precision, на которых Эльбрус достигает лишь 25 GFLOPS. То есть он примерно вдвое медленнее указанного процессора. Что тоже, в принципе, неплохо. К сожалению достигается этот пик производительности далеко не на всех задачах, в среднем отставание будет больше, а на неоптимизированном коде — намного больше.
Планируют запустить производство в России на Микроне в конце этого — начале следующего года
Но получится или нет — бабушка надвое сказала. Эльбрус-1С вон только в 2013 году на Микроне смогли сделать и серийно я так понимаю так и не стали производить.
Эльбрус на Тайване производится, раньше TSMC клепала, кто сейчас — неизвестно, но скорее всего производителя не меняли. Так что закладки вложить можно :). Обещают правда в этом году перенести производство в Россию на «Микрон», но получится или нет — еще неизвестно. Древний Эльбрус 1С например только в 2013 довели до готовности для производства на «Микроне» и, похоже, так это производство и не развернули (что, впрочем, может быть логично если 2S запустят)
Ну просто досадно что подобные ролики будут очень короткими. SkySat обещает всего 90 секунд видео и мне кажется что это несколько маловато, особенно когда между даже несколькими подобными роликами будут видимо десятки минут в течении которых видео данного участка поверхности будет недоступно.
По ролику хорошо заметны ограничения на длительность одного ролика (с одного спутника) — можно заметить как на глазах меняется ракурс съемки из-за быстрого движения спутника по низкой орбите. Скорее всего ~5 минут видео — абсолютный предел. Когда запустят множество спутников, возможно, видео с разных спутников сумеют на лету подклеивать. Но вообще навскидку даже 24 спутника для непрерывного покрытия всей Земли будет маловато.
Данная станция работает ровно наоборот заполняя трубу холодным воздухом. Для холодного воздуха та же труба по тому же принципу создаст тягу вниз.
Берем теперь высокую трубу изначально заполненную тем же воздухом. Начинаем распылять у её вершины воду. Испаряющаяся вода охлаждает воздух, его плотность растет (как за счет снижения температуры так и за счет добавления водяного пара) и он начинает опускаться вниз.
Допустим теперь что у нас с какого-то момента в башне установится равновесие. Т.к. башня заполнена более тяжелым (мокрым и холодным) воздухом, то градиент давления в ней окажется выше чем в окружающем воздухе и давление у основания башни внутри будет больше давления воздуха снаружи (столб воздуха в башне весит больше и следовательно «сильнее давит» на основание). Этот перепад давлений означает что воздух будет выходить из башни и этот перепад можно использовать для генерирования электроэнергии.
Правда отбор воздуха из низа башни означает что воздух должен в ней двигаться, а это даст чуть другую картину — давление «внизу» будет по башне чуть ниже чем предписано «статикой» и воздух будет из-за этого меньшего давления непрерывно разгоняться вниз. Это даст стабильный ветер в башне направленный вниз и снизит статическое давление внизу. И тут можно поиграть меняющимся сечением башни чтобы этот ветер максимально усилить. Не знаю что из этого можно по максимуму выжать, там уже не очень тривиальный расчет получается :)
Психрометрическая таблица показывает что на 40-градусной жаре и при нулевой влажности можно и 15 градусов получить в психрометре — и это не предельный результат, т.к. там мы охлаждаем до этой температуры целый термометр
Прикинем расчет для воздуха. 1 грамм воды при полном испарении забирает 2.25 кДж тепла. Для охлаждения 1 кг воздуха на 1 градус требуется примерно 1 кДж. Распылив 7 грамм воды на 1 кг воздуха, при полном испарении воды мы понизим температуру воздуха на 16 градусов. Если исходный воздух имел температуру t=30 градусов, то после охлаждения температура составит t=14 градусов. При такой температуре и нулевой начальной влажности воздуха распыленные 7 грамм воды на 1 кг воздуха дадут влажность воздуха на выходе ~70%. Это значительно меньше 100%, поэтому при достаточно большой трубе это вполне достижимый результат.
На практике впрочем надо учитывать гравитационные эффекты и там все будет чуть сложнее. Коротко говоря, для влажного воздуха температура с падением высоты будет расти гораздо медленнее => будет больше градиент давления => воздух будет разгоняться трубой. На выходе трубы будет наблюдаться отнюдь не избыток давления, а напротив, будет газ с меньшим давлением но большой кинетической энергией.
2.1) Иногда бывает что после прописывания новых environment variables нужно перезапустить приложение, т.к. уже запущенное использует старые env
4) Похоже на баг связанный с апгрейдом студии со старой на новую (2008->2010), но если дело не в апгрейде или не лечится выбором правильной версии студии в Qt, то пофиксить подобное тяжело, согласен. Возможно здесь косяк Qt Creator, но иногда у самой Студии бывают такие глюки, однажды в компании с похожим сталкивались
Давайте все же подбирать адекватные примеры. «Надо уметь водить, тогда с BMW на механике желания пересаживаться на Хонду с автоматом не возникнет». C++ имеет ведь крупные преимущества, особенно в скорости? Имеет. Вот и давайте смотреть на ситуацию где вождение требует определенной квалификации но окупается уровнем этого вождения, а остальные детали отличаются не столь сильно. Лично я умею ездить на механике — и желания перелезать на менее быструю и менее управляемую машину у меня не возникает, а вот скажем, супруга не умеет — и для неё автомат получается на порядок удобнее :).
Теперь по остальным пунктам
1) Тулинг у C# лучше, согласен. Но грамотно настроенный C++ немногим хуже. Лично мне, честно говоря, вообще хватает большинства дефолтных возможностей студии, но если есть желание подтащить фичи ближе к уровню C#, то просто ставится Visual Assist
1.1) Управление зависимостями — да, согласен, одно из самых слабых мест. Сложно, требует привыкания, подвержено багам. Но по моим впечатлениям и C# там неидеален. У нас в сборке как я писал есть C# код, причем он растащен по нескольким солюшенам и часть кода импортирует что-то из других солюшнов. Когда время от времени объем импортируемого меняют а другой солюшн обновить забывают, то Студия выдает совершенно безумные сообщения об ошибках импорта, из которых совершенно неясно как их исправлять. Просто вот мол есть объект такой-то, а откуда он вообще берется, где объявлен, где ищется — загадка. Из космоса, видимо, приходит. Где-то глубоко в настройках проекта прописан HintPath, вот только по нему и можно, считай, догадаться, где должно лежать недостающее. В плюсах подобные ошибки выдают гораздо более понятное сообщение. Впрочем возможно это дело привычки.
2.1. Async-Await дали у нас откровенно хреново читаемый код. Вот предсказуемый — это да, ибо копи-паст. Но в целом по крайней мере у нас он дал плохой код. Лучше чем то что бы сделал для решения той же задачи на C++ новичок, но намного хуже того, как можно было бы реализовать код нормально
2.2. Generics — это же официально недотемплейты, вроде :)?
2.3. С LINQ и вообще в целом с БД дел не имел, так что верю на слово что удобно :)
3. У C++ есть Qt и в паре с boost ом из «библиотек на все случаи жизни» больше просто ничего не надо. Специализированные библиотеки на все случаи жизни на C++ вообще найти проще, на C/C++ профессионального кода написано гораздо больше чем на C#.
3.1. boost это вообще-то очень разнородная коллекция. Там есть конечно зубодробительные темплейты, но большая часть библиотеки вообще-то как раз очень понятна и логична. Особенно удивительно слышать о том что «boost слишком сложно задизайнен» на фоне того что «stl единственная нормальная библиотека»: STL, особенно микрософтовский, как раз очень сложно устроен «внутри», да и головоломных решений типа codecvt и locale там хватает.
Во-первых, имеет смысл разделять два разных продукта: Qt Creator (IDE) и собственно Qt (библиотеки). Это две совершенно разных сущности. Хотя Creator и создавался теми же людьми и для облегчения разработки с Qt, но все же судить по нему о Qt-как-библиотеке, тем более в выражениях «Qt требует танцев с бубном» было изначально плохой идеей.
Во-вторых, «из коробки», насколько я помню, Qt Creator идет с MinGW. Собственно именно как обертка для GCC / GDB он и создавался, ИМХО. Кросс-платформенный же продукт. GCC-то есть везде, а MSVC — только под виндой, естественно что для Creator это не основной поддерживаемый вариант. А под MinGW, насколько я понимаю, Qt Creator у Вас прекрасно встал сразу.
В-третьих, Qt + MSVS обычно подразумевает что в качестве IDE используется MSVS, причем это долгое время был «платный» вариант, не знаю как сейчас. Qt Creator + MS compiler — это довольно необычное сочетание и с позиции разработчиков Creator-а было подвигом вообще сделать соответствующую поддержку. Сейчас правда в списке скачиваемых версий есть специальные сборки под VS 2010 / 2012, но я их не пробовал и не знаю как они работают. Вы хотя бы такую сборку использовали или что-то другое? Если что-то другое, то довольно странно было ожидать что там все заработает без настройки :).
Теперь пройдемся по поводу «квалификации».
Начнем с двух общих фактов:
1) Qt — это библиотека
2) Qt Creator — это IDE подключающаяся к стороннему компилятору / отладчику
Из первого факта вытекает что
1) библиотеки должны быть совместимы с runtime библиотеками используемыми в программе и линкером которым эта программа собирается. Т.е. если проект собирается в MSVS, использующим свой способ линковки и подлинковывающим микрософтовский рантайм (который еще и разный для разных версий Студии), то библиотеки Qt должны быть собраны в MS-совместимом формате и желательно — той же самой версией Студии. Это общая проблема для любых библиотек подключаемых к MS-компилируемому софту и скорее всего у Вас были проблемы именно с этим пунктом.
2) Вы можете использовать динамическую или статическую линковку. Статическая линковка подразумевает для MS-компилируемого софта опять же специальную версию библиотеки (ибо у MS статически-линкуемые и динамически-линкуемые библиотеки различаются). Qt по умолчанию идет в динамическом варианте, который подразумевает что код Qt не запихивается непосредственно в генерируемый .exe файл, а лежит себе отдельно в виде динамической библиотечки (DLL) подгружаемой в момент загрузки. Если .exe не может найти эту DLL-ку — то он, странное дело, сообщит об этом — причем довольно внятным сообщением. Догадываетесь к чему я клоню? Это опять же очень общий момент, с ним сталкивался любой, кто хотя бы какие-то сторонние библиотеки хоть раз подключал.
2.1.) У пункта 2 есть ньюанс: эти библиотеки, в принципе, можно прописать где-нибудь в системных путях, чтобы они находились виндой автоматически. и для Qt это без проблем тоже делается вручную за две минуты. Почему это не реализуется «из коробки»? А потому что это не очень хорошая практика, так как возникают проблемы с конфликтом разных версий этих библиотек aka DLL hell. MS из этой проблемы выкручивается тем что поставляет разные библиотеки для разных версий Студии, причем пара-тройка разных (!) версий этих библиотек включается в комплект поставки операционной системы (!). Однако как я уже писал в (1), такой подход приводит к тому что приходится собирать специальные версии всех сторонних библиотек (включая Qt) раздельно для любой версии студии (для 2010 — свои, для 2012 — свои...) а когда выходит 2013 студия то, сюрприз-сюрприз — сборок многих библиотек под эту студию просто не оказывается. Qt следует более юниксовым подходом и обеспечивает возможность работать с несколькими версиями Qt тем что просит явно указывать путь к библиотекам которые предполагается использовать — и в Creator это прекрасно обыграно, там это делается в два клика с автодетектированием. Я понимаю что когда на компьютере стоит лишь одна версия Qt то это выглядит «лишней работой», но эта работа невелика, а на мой взгляд, «Qt way» в отношении поддержки разных версий библиотек правильнее чем «MS way».
3) При этом если Вы бы занимались созданием инсталляторов, то Вы бы знали, что нужные MS библиотеки на компьютере тоже штатно бывают не всегда (особенно когда у пользователя из ОС стоит что-то старенькое типа Windows XP) — и то что «из коробки» (tm) работает на Вашей машине может ВНЕЗАПНО сообщить что ему не хватает какого-нибудь MSVCR110.dll на компьютере Вашего пользователя. Вам-то его инсталлятор студии поставил, а пользователю уже как повезет, включил эту библиотеку в ОС микрософт или нет. Qt в этом отношении где-то честнее, отладили на своей машине и приложили все нужные DLL-ки — работать будет везде. А с MS вечно думаешь, включать ли ms redistributable в инсталлятор или нет.
Из второго же факта вытекает что
4) Qt Creator-у нужно указать где и какими тулами пользоваться и сделать эти тулы для него доступными. Что подразумевает какую-никакую но все же настройку
Я вообще прошу прощения за слова про квалификацию, это было грубовато с моей стороны. Но Вам, право слово, не стоило писать тезисы типа
С учетом вышеизложенного — понимаете почему?
Все-таки когда Qt надо было ставить как обычную библиотеку это требовало некоторой минимальной квалификации от её пользователя.
Вот я смотрю на наш проект и думаю: два человека работали над UI почти год. UI пока сводится, по сути, к двум десяткам кнопок и менюшек, которые надо оформить согласно дизайн-макету. На C# / WPF два средней руки специалиста сгенерили под это дело монструозный код который — при всей простоте функционала! — мало кто может понять. На мой взгляд это — EPIC FAIL технологии. Если бы те же двое пользовались Qt, они сгенерили бы за тот же срок чуть лучший по качеству проект, который было бы намного легче понять и в котором не было бы геморроя с интеграцией C# + C++. Если бы на месте эти двоих был один отличный специалист, то он реализовал бы на порядок лучший код на Qt за два месяца. Может отличный специалист и на WPF выдал бы отличный код за два месяца — но выгоды-то все равно не было бы. Вот с MFC было бы хуже, да — там 6 месяцев ушло бы у отличного специалиста, а те двое вообще непонятно что бы выдали. Но так трудно придумать что-то страшнее чем MFC.
В какой-то степени да. На плюсах можно писать все что угодно. Но для некоторых проектов некоторые специально заточенные под такие проекты языки дают какую-то выгоду.
К Python у меня смешанные чувства. Он удобен для простеньких скриптов и управления, но качество кода, по крайней мере у нас, хромает в результате скоростной разработки на обе ноги. Как только python разрастается в что-то большее — получается сложная в поддержке и отладке хреновина. Плюсы хуже подходят для мелочи, но они масштабируются до сколь угодно больших проектов без потери качества и понятности кода.
На PHP писал код когда-то ооочень давно и этот язык оставил смешанное впечатление. Тогда я был новичком и мне он показался удобным (пишем в плюс: подходит для малоквалифицированных персонажей), плюс интеграция с веб-сервером куда удобнее чем в плюсах. Но сейчас я подобного качества код мне писать будет стыдно, а как его на PHP улучшить я не представляю. Может и можно, впрочем — не рискну судить, очень давно не занимался. В высоконагруженных проектах, впрочем, как я слышал, он дохнет — не случайно google на плюсах и JS свои веб-сервисы пишет. Я конечно понимаю что сегодня модно просто поставить дохрена серваков на которые нагрузку будет разбрасывать C++-код написанный гораздо более профессиональными ребятами :D, но я не люблю подобных решений.
С Java дел не имел, ничего не скажу. Коллеги, впрочем, как-то сталкивались с героями, замутившими лет восемь назад на Java огромную enterprise-систему. Говорят сделано все было по коду очень красиво, но тормозило и память жрало совершенно безбожно. Но я так понимаю что производительность Явы с тех времен заметно шагнула вперед, так что сейчас, вероятно, для каких-то проектов типа «красивого интерфейса к БД» это очень правильный выбор.
А вот для C#/WPF я нишу что-то не вижу. Для работы с БД думаю Java будет лучше. Для производительных десктопных приложений — лучше C++/Qt (и это не только наш 3D сканер и прочие AutoCAD-ы, но и такие приложения как Word и Excel). Для высокопроизводительных серверных приложений лучше голый C++, если вопрос производительности менее приоритетен чем скорость разработки — то какой-нибудь специализированный язык, хоть бы и PHP. Разве что нативные shareware приложения под винду делать, чтобы look&feel был аутентично микрософтовским и библиотеки не надо было в инсталляторе таскать.
Делаем сейчас один проект, который является развитием старого кода написанного на C++ / MFC. Тоже вот нашлись, хм, энтузиасты C# / WPF, запоровшие идею реализации проекта на Qt. Но огромную существующую базу алгоритмического кода переписывать на C# было заведомо дохлым вариантом. Решили в итоге, значит, сделать вычислительное ядро на С++, остальное — на C#. Благо что плюсы все равно значительно превосходят C# по производительности, а для нас это было критично.
Ну что… написали мы этот гибрид. Получился откровенный отстой. UI написан хрен знает как, поддерживать его может только пара человек, которые сами этот код и писали, C# код представляет из себя жуткую кашу, которую нормально читать невозможно. Нет я знаю конечно что те же люди и на C++ / MFC воротили хреновый код, но даже там его было легче читать и менять. А на C# / WPF те же товарищи наворотили вообще нечто трудновыразимое — и это в простеньком в общем-то по UI приложении! Я уверен что был бы там Qt — код был бы на порядок читабельнее, там очень сложно писать UI плохо. Посмотрел я на это дело и что-то ни малейшего желания использовать C# у меня после этого не возникло. Да, там прикольная библиотека. Да, прикольные языковые возможности. Но библиотек и на C++ хороших много (и Qt — одна из лучших), а эти языковые возможности на практике были густо использованы для того чтобы намешать черти какой код. Ну и нафига мне C#? Если я умею писать код, то на C++ он получается не хуже по читаемости, надежности и скорости написания чем код на C#. А если некоторые мои коллеги пишут код абы как, то и на C# они создают непонятную и заполненную багами хрень. Приплюсуйте сюда разнообразные трудноразрешимые баги которые вылезают в проекте из-за совмещения C++ и C#. Особенно рельефно это все смотрится на фоне того что плюсовое ядро мы капитально переписали на совершенно новую технологию — и после создания своей библиотечки работать с высоконагруженым параллельным кодом работающим в реал-тайме в плюсах — одно удовольствие. Работает быстро, практически без багов (две штуки… и ни одного из них специфичного для C++), код красивый.
В общем, надо на C++ уметь работать — и тогда никакого желания на C# переходить не возникнет.
Хотя для простеньких проектов C# может и неплох — если, как Вы сами же пишете, таскать с собой с десяток велосипедов.
Но мне в таких проектах тоже проще с Qt работать, там и велосипедов тащить не нужно.
Для обучения использовалась контрольная выборка? Или как это часто бывает обучали на всей базе данных и указанные проценты — это результат по выборке после обучения на этой же выборке?
А выпустить процессор не нарушив патентов легко — во-первых многое лицензируется (и у МЦСТ есть лицензии на Sparc), а во-вторых еще больше давно уже открыто за истечением всех мыслимых сроков давности либо не патентовалось изначально.
Эльбрус, насколько я понимаю, реально способен осилить около 24 GFLOPs в тех же условиях.
Другой вопрос что Интел гораздо лучше справляется с обычным компилируемым кодом без его ручных оптимизаций.
Но получится или нет — бабушка надвое сказала. Эльбрус-1С вон только в 2013 году на Микроне смогли сделать и серийно я так понимаю так и не стали производить.