Давайте не будем отождествлять себя и массового юзера?
Я знаю примеры из жизни когда у кастомера есть собственные клиенты которые сидят под линуксами. При чём достаточно массово выходит, что проигнорировать ну никак нельзя.
Здравствуйте, vdimas, Вы писали:
F>> fopen годен чуть менее, чем всегда. V>Зачем он вообще нужен, при наличии open? По факту лишь имеем добавочный мьютекс, утяжеляющий вызовы и дурацкий самописный буфер, который на современных операционках лишний. По крайней мере до тех пор, пока не на надо извлекать по 1-му символу. Но это лучше делать в клиентском коде, без всех этих мьютексов.
Откуда мьютекс? Впрочем даже ежели так — то как бы пофиг. На винде гораздо раньше стоит заботится о том что FS пишет last access time и создаёт короткие имена, а не то, что ты говоришь. При этом куда более реальная проблема и реагирует и на CreateFile тоже.
Хотя может у тебя и не так, а мы пишем файлы тысячами. Такова наша реальность. Я не спорю, что может быть иначе.
В любом случае — критика тут в треде о том — что стандартные API на подобии fopen или berkley sockets должны работать одинаково хорошо везде, а не так, как схалтурири в нашей любимой компании.
За сим, разрешите откланяться.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, мыщъх, Вы писали:
A>вот допустим, есть хорошая удобная программа, у нее 1 миллион обычных юзеров. A>делаем версию под никсы — появляется еще сколько? пара тысяч юзеров?
про никсы я не говорил. если это программа не переводчик с русского на иврит и продается в сша, то поддержка мака по самым-самым скромным оценкам добавит еще 100,000 юзеров на данный момент (и еще больше в перспективе). пусть под мак она стоит $20. поддержка мака принесет два миллиона долларов.
A>программы для профессионального использования могут быть кроссплатформенными, а массовый юзер сидит только под одной платформой — win32(x32)
как минимум есть рынок смартфонов и планшетов. конечно, планшеты и смартфоны не для всех программ подходят, но это рынок. браузеры -- вполне себе платформа, куда сейчас пытаются засунуть и 3D графику и все остальное. кстати, для браузеров появляется множество кросс-платформенных сэндвичей с установкой приложений на серверной стороне. во всяком случае facebook очень активно работает в этом направлении. для гугла это похоже что-то вроде хобби (вы можете написать свой гаджет, загрузить на гугл и его увидят и установят миллионы, пусть он будет стоить $0.99, у вас уже набирается миллион спокойно).
даже если вы в танке и смотрите на мир через узкое забрало, то не можете отрицать, что за пределами win есть жизнь. причем, там весна и стремительное развитие, на котором делают деньги, а под win -- осень переходящая в зиму.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Abyx, Вы писали:
A>кроссплатформ не нужен. точка.
Это вас сильно занесло.
A>вот допустим, есть хорошая удобная программа, у нее 1 миллион обычных юзеров. A>делаем версию под никсы — появляется еще сколько? пара тысяч юзеров?
Речь о десктопе, насколько я понял?
Давайте глянем с вами на реальные цифры в штатах (которые являются основным потребителем этого рынка):
Рынок смартфонов — ~50% Android/Linux, ~30% Apple,..., ~5% Microsoft
Рынок планшетов — ~65% Apple, ~30% Android/Linux
Рынок ОС — ~15% Apple, 0.7-1% Linux, 83% Microsoft
Гуглил, старался для вас.
Если мобильные платформы будут продолжать свой взрывной рост, то win platform очень скоро придется потесниться, разделив первое место с Apple и Google.
Отсюда вывод — кроссплатформ хотя бы в ядре/бэкэнде очень важен, соотвественно будет спрос на таких специалистов (сейчас уже можно видеть по вакансиям)
A>кода станет больше, придется отказаться от удобных MSVS-specific фич, поддерживать код станет сложнее, тестировать надо будет под разные системы A>- и оно того стоит?
Стоит, если это достойно оплачивается
Здравствуйте, fddima, Вы писали:
F>В общем-то давайте вспомним VB в котором никого особо не парила сложность COM, многие и не знали что такое COM и опосредственно его использовали.
C VB и VBA история вообще отдельная. Привычный код на С++ со смарт-поинтерами примерно вдвое тормознутее, чем тот, который генерит VB/VBA, т.к. он исключает лишние парные Addref/Release и генерит такой код, какой был бы при ручном управлении COM без смарт-поинтеров. Я вообще одно время заинтересовался и просматривал ассемблерные листинги VB6 — очень неплохой ход генерится в случая полных аннотаций типов (без использования VARIANT или авто-определений переменных).
F>То что C++ как и другие языки не особо заточены под работу с ним — ну дык — вроде как никто ж и не обещал.
Вот, специально под WinRT заточили C++ новыми расширениями. Посмотрим, поможет ли это им нивелировать избыточные парные AddRef/Release.
Здравствуйте, a_g_99, Вы писали:
A>>кроссплатформ не нужен. точка. __>Это вас сильно занесло.
__>Речь о десктопе, насколько я понял?
__>Рынок смартфонов — ~50% Android/Linux, ~30% Apple,..., ~5% Microsoft __>Рынок планшетов — ~65% Apple, ~30% Android/Linux
__>Если мобильные платформы будут продолжать свой взрывной рост, то win platform очень скоро придется потесниться, разделив первое место с Apple и Google
А приложения для десктопов и смартфонов хоть как-то пересекаются?
Здравствуйте, vdimas, Вы писали:
V>Привычный код на С++ со смарт-поинтерами примерно вдвое тормознутее, чем тот, который генерит VB/VBA, т.к. он исключает лишние парные Addref/Release
Брр. "Привычный код" что нить кроме присваивания поинтеров делал?
Для меня привычный код львиную долю времени проводит в делании чего то полезного, и addref/release там случаются очень редко. Или там на каждый пук всё с нуля переполучается и пересоздаётся?
Здравствуйте, a_g_99, Вы писали:
НС>>По сравнению с WinAPI — ОО, изоляция от опасных вещей. __>Вы не могли бы пояснить конкретнее, о чем вы здесь? Речь идет о конкретных фичах типа hat pointers, boxing, type conversion или о FCL WinRT в общем? __>Просто если смотреть в целом то те же MFC и ATL/WTL имели продвинутую и устоявшуюся ОО иерархию над обширной частью winapi (особенно хороша на мой взгляд wtl).
MFC, и, в особенности ATL — это просто библиотеки. Никто не мешает мимо них ходить в Win32API. А вот WinRT мешает — ничем другим ты пользоваться не можешь.
>>существенно более гладкий интероп с дотнетом. __>так надо было делать в дотНете, а не придумывать еще один framework
Надо было. Но у Синовского идиосинкразия к нему.
__>У меня просто складывается ощущение что парни из MS движутся по кругу, вместо того чтобы включать голову.
Они не движутся по кругу, потому что нет такого специального человека типа Жопса. Есть целая куча разных команд и людей с разными идеями. В результате политических течений иногда власть сменяется, и приходят другие люди с другим пониманием того, что нужно делать. WinRT это не идея тех, кто придумал дотнет, WinRT это эволюция СОМ. И Синовский от СОМ никуда не уходил, так что и круга никакого нет.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Они не движутся по кругу, потому что нет такого специального человека типа Жопса. Есть целая куча разных команд и людей с разными идеями. В результате политических течений иногда власть сменяется, и приходят другие люди с другим пониманием того, что нужно делать. WinRT это не идея тех, кто придумал дотнет, WinRT это эволюция СОМ. И Синовский от СОМ никуда не уходил, так что и круга никакого нет.
А что плохого в WinRT? Очевидно, что идея полностью управляемых приложений не прошла. Так что сделали нормальный вариант — слизали дизайн с GTK/GNOME и сделали нативную объектную модель, которую удобно интегрировать с управляемыми языками.
Здравствуйте, Cyberax, Вы писали:
C>А что плохого в WinRT?
В нем самом — ничего. Плохое в NIH.
C>Очевидно, что идея полностью управляемых приложений не прошла.
Со слова "очевидно" как правило начинаются демагогические высказывания. Нет, не очевидно. Во-первых есть винфон, который демонстрирует что вопли про обязательную ресурсоемкость managed — не соответствуют действительности. Во-вторых можно было не СОМ на дотнет в очередной раз натягивать, а наоборот, чуть подправить ABI дотнета, чтобы с минимумом проблем можно было под него писать на разных языках, а не только на VC++. Это был бы существенно более логичный и понятный шаг. А с WinRT лично у меня есть серьезные опасения, что, если вдруг Синовский сольется (а такое вполне может быть, если, к примеру, восьмерка не пойдет), этот WinRT задвинут куда подальше. Чехарда в системных API до добра не доводит — и так каша из Win32, FCL и COM местами аццкая, а тут еще и WinRT.
C>Так что сделали нормальный вариант — слизали дизайн с GTK/GNOME
Да да да, верь. Это гнома с СОМ слизали, а у WinRT ноги из 99 года растут.
C> и сделали нативную объектную модель, которую удобно интегрировать с управляемыми языками.
Ага, я помню как "удобно" интегрироваться с GTK из Моно, накушался в свое время. К счастью, Синовскому такую свинью managed разработчикам все таки не дали подложить.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>В нем самом — ничего. Плохое в NIH. C>>Очевидно, что идея полностью управляемых приложений не прошла. НС>Со слова "очевидно" как правило начинаются демагогические высказывания. Нет, не очевидно. Во-первых есть винфон, который демонстрирует что вопли про обязательную ресурсоемкость managed — не соответствуют действительности.
Ну да. Винфон, в котором Скайп — с нативным кодом, как и некоторые игрушки.
C>>Так что сделали нормальный вариант — слизали дизайн с GTK/GNOME НС>Да да да, верь. Это гнома с СОМ слизали, а у WinRT ноги из 99 года растут.
А COM — с SOM. Там можно долго искать кто у кого слизал, вплоть до ЛИСП-овых машин.
C>> и сделали нативную объектную модель, которую удобно интегрировать с управляемыми языками. НС>Ага, я помню как "удобно" интегрироваться с GTK из Моно, накушался в свое время. К счастью, Синовскому такую свинью managed разработчикам все таки не дали подложить.
А что там не так? Те же объекты со счётчиком ссылок и рефлексией.
Здравствуйте, Cyberax, Вы писали:
C>Ну да. Винфон, в котором Скайп — с нативным кодом, как и некоторые игрушки.
Так нативный код совсем запрещать никто и не предлагает.
НС>>Да да да, верь. Это гнома с СОМ слизали, а у WinRT ноги из 99 года растут. C>А COM — с SOM. Там можно долго искать кто у кого слизал, вплоть до ЛИСП-овых машин.
Так ты первый поиски начал.
НС>>Ага, я помню как "удобно" интегрироваться с GTK из Моно, накушался в свое время. К счастью, Синовскому такую свинью managed разработчикам все таки не дали подложить. C>А что там не так?
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Ну да. Винфон, в котором Скайп — с нативным кодом, как и некоторые игрушки. НС>Так нативный код совсем запрещать никто и не предлагает.
Ну так ещё пример — Андроид. Там совершенствуют NDK, так как для многих приложений просто делать прослойку на Java только для интерфейса нет смысла и неудобно.
В общем, я поверю в сказки про нативный код как только увижу, что MS Office под него переписали.
НС>>>Да да да, верь. Это гнома с СОМ слизали, а у WinRT ноги из 99 года растут. C>>А COM — с SOM. Там можно долго искать кто у кого слизал, вплоть до ЛИСП-овых машин. НС>Так ты первый поиски начал.
Просто конкретно сейчас это как раз самый используемый архитектурный аналог WinRT.
НС>>>Ага, я помню как "удобно" интегрироваться с GTK из Моно, накушался в свое время. К счастью, Синовскому такую свинью managed разработчикам все таки не дали подложить. C>>А что там не так? НС>А ты попробуй.
Пробовал. Мне не особо API у GTK нравится сам по себе, но код на GTK# не особо отличим от кода на Python'е.
Здравствуйте, Трололоша, Вы писали:
V>>Привычный код на С++ со смарт-поинтерами примерно вдвое тормознутее, чем тот, который генерит VB/VBA, т.к. он исключает лишние парные Addref/Release Т>Брр. "Привычный код" что нить кроме присваивания поинтеров делал? Т>Для меня привычный код львиную долю времени проводит в делании чего то полезного, и addref/release там случаются очень редко. Или там на каждый пук всё с нуля переполучается и пересоздаётся?
"Что-то" полезное — это тоже оперирование интерфейсами. Если натравить импорт на библиотеку, то получение любого объекта превращается в возврат _com_ptr_t<> по значению, вместо подачи &ptr как последнего аргумента. В этих возвратах и сидят лишние парные AddRef/Release. Соответственно, пробежаться по какой-нить иерархии на плюсах вдвое дороже, чем на VB.
Здравствуйте, Cyberax, Вы писали:
C>Ну так ещё пример — Андроид. Там совершенствуют NDK
И пишут кучу кода самого андроида на жабе. При этом JVM в андроиде на редкость убога.
C>В общем, я поверю в сказки про нативный код как только увижу, что MS Office под него переписали.
Переписать офис под нативный код? Ты хотел сказать на managed? Никто ничего переписывать не будет, это не окупится.
НС>>Так ты первый поиски начал. C>Просто конкретно сейчас это как раз самый используемый архитектурный аналог WinRT.
Самый используемый архитектурный аналог WinRT называется СОМ.
C>Пробовал. Мне не особо API у GTK нравится сам по себе, но код на GTK#
GTK# это уже готовая обертка, причем совсем не тривиальная. Для WinRT такие обертки не нужны.
Здравствуйте, Abyx, Вы писали:
A>1. C устарел и не нужен
ИМХО язык программирования устаревает и не нужен, когда им практически не пользуются. А С используется поактивней многих "новых" "не устаревших" языков. Так что нужен.
Здравствуйте, vdimas, Вы писали:
V>>>Привычный код на С++ со смарт-поинтерами примерно вдвое тормознутее, чем тот, который генерит VB/VBA, т.к. он исключает лишние парные Addref/Release Т>>Брр. "Привычный код" что нить кроме присваивания поинтеров делал? Т>>Для меня привычный код львиную долю времени проводит в делании чего то полезного, и addref/release там случаются очень редко. Или там на каждый пук всё с нуля переполучается и пересоздаётся?
V>"Что-то" полезное — это тоже оперирование интерфейсами. Если натравить импорт на библиотеку, то получение любого объекта превращается в возврат _com_ptr_t<> по значению, вместо подачи &ptr как последнего аргумента. В этих возвратах и сидят лишние парные AddRef/Release.
Это архитектурный просчёт библиотеки поддержки импорта, а не C++. Сам С++ позволяет писать как тебе захочется.
Да и туда (_com_ptr_t) достаточно ИМХО добавить move-constructible чтоб убрать кучу лишних addref/release.
