Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 62
Еще бы от MacOsX отделаться…
С каких пор можно генерировать хороший C# код в серьезных проектах с высокими требованиями по производительности и в условиях минимизации используемых ресурсов без того, чтобы «отвлекаться на то, как что-то реализовать»? Позвольте с вами не согласиться.
В целом, понимаю о чем вы, со многими пунктами согласен.
В целом, понимаю о чем вы, со многими пунктами согласен.
думать конечно надо, что ты делаешь, но забивать голову выделением памяти и сбором мусора в 2010 году имхо уже несолидно
а с производительностью сейчас какие проблемы, ну вынесите критичный код в отдельный поток, чтобы он ушел на другое ядро, или в сервис его обрамить и на другой сервер вынести
имхо проектирование здесь в первую очередь решает
ну все бывает конечно…
а с производительностью сейчас какие проблемы, ну вынесите критичный код в отдельный поток, чтобы он ушел на другое ядро, или в сервис его обрамить и на другой сервер вынести
имхо проектирование здесь в первую очередь решает
ну все бывает конечно…
«Забивать голову» точно не стоит, но контролировать со своей стороны процесс и разумно подходить ко многим моментам — имхо, имеет смысл. Может настолько привык помнить про выделенную память и жаждать ее освобождения, может быть не все действия garbage collector'a мне приятны.
Относительно архитектуры это да, проектирование всегда решает :) А с производительностью .Net на мобильных устройствах в ресурсоемких приложениях мне кажется всегда проблема была (то решение выносят за пределы managed-кода, то еще какой финт ушами).
Относительно архитектуры это да, проектирование всегда решает :) А с производительностью .Net на мобильных устройствах в ресурсоемких приложениях мне кажется всегда проблема была (то решение выносят за пределы managed-кода, то еще какой финт ушами).
на мобильных устройствах .net как такового нет, сборка компилится сразу в архитектуре процессора
но процессоры там слабые, одна операция может 10 тактов выполняться, то есть все эти мегагерцы дутые
а так да, на WM все довольно убого, и чуть что, сразу приходится с unmanaged кодом работать, структуры передавать и callbackwindow держать
сейчас говорят еще более-менее там что-то появилось, что с мультимедиа работает, а раньше так вообще ничего не было в Compact Framework, только стандартные офисные приложения и можно было лепить
просрали они конечно windows mobile, даже сказать нечего…
но процессоры там слабые, одна операция может 10 тактов выполняться, то есть все эти мегагерцы дутые
а так да, на WM все довольно убого, и чуть что, сразу приходится с unmanaged кодом работать, структуры передавать и callbackwindow держать
сейчас говорят еще более-менее там что-то появилось, что с мультимедиа работает, а раньше так вообще ничего не было в Compact Framework, только стандартные офисные приложения и можно было лепить
просрали они конечно windows mobile, даже сказать нечего…
Во! Нашли общий язык.
э-э-э, скажем так… для экономии энергии широко используется схематика достаточно простого процессора с длинным конвейером, что позволяет относительно беспроблемно наращивать его тактовую частоту, но почти все операции выполняются за существенно большее количество тактов, нежели в аналогичных десктопных процессорах
т.е. 1 ГГц процессор мобильного устройства совершенно не аналогичен по производительности 1 ГГц десктопного процессора, зато и кушает на порядок меньше
разумеется, прошли годы и очень многое сделано, в том числе с использованием специализированных схем в узких местах, типа ускорителей графики и звука на отдельном DSP, но суть остается та же самая, потому что планку задает энергопотребление
т.е. 1 ГГц процессор мобильного устройства совершенно не аналогичен по производительности 1 ГГц десктопного процессора, зато и кушает на порядок меньше
разумеется, прошли годы и очень многое сделано, в том числе с использованием специализированных схем в узких местах, типа ускорителей графики и звука на отдельном DSP, но суть остается та же самая, потому что планку задает энергопотребление
Кстати, пример автора (точнее его постскриптум) весьма эпичен и имеет широкое распространение. Однажды мне довелось видеть 5 попыток реализовать софтварный рендер достаточно большого количества полигонов на .Net CF. Это было жуткое зрелище [не отрицаю вины разработчиков, но они старались подойти достаточно грамотно и упирались в производительность технологии и накладные расходы самого фреймворка].
Очень интересное описание опыта, с выводами, пишите еще. Такой вопрос: а вы осознанно выбрали SharpDevelop, а не MonoDevelop? Если да, то по каким причинам?
>> удобство работы в SharpDevelop намного выше чем в Xcode.
Мне страшно представить, как же там в XCode-то, если в SharpDevelop лучше :)
>> удобство работы в SharpDevelop намного выше чем в Xcode.
Мне страшно представить, как же там в XCode-то, если в SharpDevelop лучше :)
Вы типа секретарь sashaeve? Мне стало интересно, я погуглил, тама (Xcode) интеллисенса (тм) или чего-нть похожего нету, например. Интересно, я прав?
Нет. Оно не называется IntelliSenseтм, конечно, но пользоваться этой штукой не менее удобно.
Есть там интеллисенс, только он не особо intelli )
Он работает больше по принципу подстановки всех похожих лексем, нежели по принципу выбора подходящих по семантике. В принципе, этот путь мне кажется оптимальным подходом для С/C++. Отмечу, кстати, что в контексте конструкций, специфичных для Objective-C (посылка сообщения, к примеру), интеллисенс намного более интеллектуален.
//
Единственное, чего я не могу понять — почему интеллисенс в XCode вызывается по нажатию на клавишу (какую бы вы думали?) ESCAPE!
Он работает больше по принципу подстановки всех похожих лексем, нежели по принципу выбора подходящих по семантике. В принципе, этот путь мне кажется оптимальным подходом для С/C++. Отмечу, кстати, что в контексте конструкций, специфичных для Objective-C (посылка сообщения, к примеру), интеллисенс намного более интеллектуален.
//
Единственное, чего я не могу понять — почему интеллисенс в XCode вызывается по нажатию на клавишу (какую бы вы думали?) ESCAPE!
А почему вы его считаете более оптимальным? Complete List в Xcode меня просто убивает. К примеру, если у меня при присвоении l-value имеет тип float, зачем мне в списке предлагать методы которые возвращают bool, void и т.п.? Я не хочу и не должен этого видеть, если захочу, то я перед этим могу сделать приведение типа, а так… почти бесполезная вещь получается (приходится постоянно отвлекаться на справку, скорость написания кода падает). Самая лучшая реализация которая мне встречалась была в Borland Delphi, причем еще в мохнатых 90-х, с тех пор ничего более или хотя бы настолько же удобного не встречал.
На самом деле вариантов вызова несколько, я к примеру частенько пользуюсь ctrl+,
Единственное, чего я не могу понять — почему интеллисенс в XCode вызывается по нажатию на клавишу (какую бы вы думали?) ESCAPE
На самом деле вариантов вызова несколько, я к примеру частенько пользуюсь ctrl+,
Оптимальным — поскольку для реализации полноценного интеллисенса в С++ нужно очень много ресурсов, и такой парсер будет очень медленно работать из-за сложности грамматики. Я лично не знаю интеллисенсов в мире С++, по возможностям сравнимых с мощью решарпера или intellij IDEA, которые работают с языками C# и Java. Поэтому, на мой взгляд, имеет смысл ограничиться только самым необходимым функционалом (подстановка уже имеющихся в контексте литералов, автокомплит имен функций итд).
В Delphi грамматика попроще и построже, поэтому и хороший autocomplete — явление закономерное.
В Delphi грамматика попроще и построже, поэтому и хороший autocomplete — явление закономерное.
У Borland был еще и Builder, где использовался не паскаль, а с++. Там так же не было проблем и он ничем не отличался от delphi реализации. Да и мне лично тоже не видится каких-то больших проблем из-за перехода на Obj-С. Тут просто страдает именно что реализация. К примеру как можно объяснить такое поведение:
1. я решил изменить код и вместо drawAtPoint послать drawAtRect, перемешаю курсор на конец слова draw, вызываю complete list и получаю вот это недоразумение:
2. чтобы получить нужный мне список, нужно переместить курсор, к примеру в начало строки, вызвать complete list там, далее сново вернутся в конец draw и только теперь можно получить то, что ожидается:
Причем этот список закешируется и чтобы его сбросить нужно опять где-то вызвать «самый полный».
Вообще подобных странностей, недоделок и просто неудобств полным полно, своей IDE в Apple, как мне кажется, совершенно не уделяют внимания. Уж лучше бы они ее платной сделали, может хоть тогда уровень подтянули бы.
1. я решил изменить код и вместо drawAtPoint послать drawAtRect, перемешаю курсор на конец слова draw, вызываю complete list и получаю вот это недоразумение:
2. чтобы получить нужный мне список, нужно переместить курсор, к примеру в начало строки, вызвать complete list там, далее сново вернутся в конец draw и только теперь можно получить то, что ожидается:
Причем этот список закешируется и чтобы его сбросить нужно опять где-то вызвать «самый полный».
Вообще подобных странностей, недоделок и просто неудобств полным полно, своей IDE в Apple, как мне кажется, совершенно не уделяют внимания. Уж лучше бы они ее платной сделали, может хоть тогда уровень подтянули бы.
Я лично не знаю интеллисенсов в мире С++, по возможностям сравнимых с мощью решарпера или intellij IDEA, которые работают с языками C# и Java.
Visual Assist X. Это я говорю как человек, пользовавшийся самыми разными IDE очень долгое время.
Времена Borland Delphi — это Золотой Век программирования (пустил слезу), нынешние среды разработки и языки программирования фрустрируют.
Мне очень стыдно, но я признаюсь, что перепутал SharpDevelop с MonoDevelop (исправил с тексте). Действительно, использовалась последняя IDE, а ошибка произошла потому, что с SharpDevelop я работал немного раньше и я остался ней доволен.
… но, тем не менее, вы ведь не будете отрицать что подошли к вопросу несколько предвзято?
Хе-хе. По-вашему, все, кому нравится CLR (ms.net, mono), и он это не скрывает, обязательно предвзяты? :)
Ну что вы=) Я всего лишь говорю о настроении, которое легко читается между строк этой статьи.
Тем более, что сдержанность и мотивированность высказываний делает автору честь, и не дает повода для холивара — а это само по себе уже достижение при обсуждении двух конкурирующих систем/платформ=)
Тем более, что сдержанность и мотивированность высказываний делает автору честь, и не дает повода для холивара — а это само по себе уже достижение при обсуждении двух конкурирующих систем/платформ=)
Субъективность в статье, конечно, есть и я об этом честно заявил вначале. Но думаю, что моя ситуация очень распространенная, ведь «чистых» специалистов по Objective-C и iPhone SDK очень мало. И даже понимаю, что у сишников данный пост может вызвать улыбку на лице :)
Я именно об этом;) Хорошо, что вы это признаете=)
Ага, а какой смысл это скрывать? :)
А это, что называется, подите спросите=)
Фанатичность нашего брата айтишника если еще не стала притчей, то не за горами это.
К сожалению, редко кто готов признать, скажем так, «неабсолютность», да часто даже субъективность собственных взглядов.
Хабрахабр сообщество молодое, основную масссу составляет народ амбициозный, горячий, максимализма у которого хватит на армию;)
Фанатичность нашего брата айтишника если еще не стала притчей, то не за горами это.
К сожалению, редко кто готов признать, скажем так, «неабсолютность», да часто даже субъективность собственных взглядов.
Хабрахабр сообщество молодое, основную масссу составляет народ амбициозный, горячий, максимализма у которого хватит на армию;)
* удобство работы в SharpDevelop намного выше чем в Xcode.
Высказывания вида «Продукт1 лучше, чем Продукт2» бесспорны, поскольку субъективны. Кому-то нравится поп-музыка, кому-то death metal.
вы видимо мало писали на шарпе, если считаете, что в .net не нужно думать об освобождении памяти( это к вопросу, как реализовывать).
Нужно и еще как нужно. И конструкции using не зря были придуманы.
Об ограничении кол-ва графических дескрипторов вы наверное тоже не слыхали, впрочем как об RCW.
Все эти крутые штуки, со сборщиком мусора, хорошо работают на достаточно мелких решениях(проектах), взять что-то посерьезнее — все тот же самый гемморой, что и с++.
Нужно и еще как нужно. И конструкции using не зря были придуманы.
Об ограничении кол-ва графических дескрипторов вы наверное тоже не слыхали, впрочем как об RCW.
Все эти крутые штуки, со сборщиком мусора, хорошо работают на достаточно мелких решениях(проектах), взять что-то посерьезнее — все тот же самый гемморой, что и с++.
тем не менее, 80% черновой работы с памятью оно за тебя сделает
в сложных случаях имхо архитектура решает
с unmanaged объектами разумеется надо учитывать, что происходит на той стороне, сказок не бывает
сам удивляюсь, сколько же вокруг com-объектов до сих пор…
в сложных случаях имхо архитектура решает
с unmanaged объектами разумеется надо учитывать, что происходит на той стороне, сказок не бывает
сам удивляюсь, сколько же вокруг com-объектов до сих пор…
Using не предназначена для управления памятью; это для управления unmanaged ресурсами. Память — не unmanaged ресурс.
У меня возможно глупый вопрос будет, но всё равно задам: для запуска этого приложения на iphone, не нужно будет ставить какие-то либы от mono? т.е. будет тот же бинарник как при использовании Obj-C?
конечно писать на .net быстрее и удобней, чем на Obj-C, но вот как потом клиенты будут? им как?
конечно писать на .net быстрее и удобней, чем на Obj-C, но вот как потом клиенты будут? им как?
MonoTouch компилирует приложения сразу в бинарный код, который запускается на iPhone, поэтому ничего от mono в итоге не остается. Клиенты могут и не знать (если вы им об этом не скажите), что приложение написано на C#.
> Silverlight на макоси — это уже Moonlight
Moonlight — это реализация для Linux. Под Mac OS Silverlight поддерживается официально Microsoft.
Moonlight — это реализация для Linux. Под Mac OS Silverlight поддерживается официально Microsoft.
Я могу ошибаться, но Silvelight для Mac OS X нужен для отображения Silverlight-приложений, а для разработки используются именно Moonlight.
то есть получается, что если я приложение на ASP.Net переведу под Mono, с помощью тех же MonoTools для обычной VS, и потом могу его развернуть на Linux под тем же апачем, не переплачивая за хостинг?
Да, вы можете хостить asp.net приложения (+ ASP.NET AJAX) под апачем, как это сделать описано здесь. Кроме того, уже есть поддержка asp.net mvc.
MonoTouch — это который 400$ минимум стоит?
А почему заказчик отказался? Просто интересно…
И есть ли разница в скорости между приложениями написанными на xcode и mono?
Как в AppStore относятся к таким приложениям?
И есть ли разница в скорости между приложениями написанными на xcode и mono?
Как в AppStore относятся к таким приложениям?
1. Нужна была интеграция с другим кодом, написанном на Obj-С.
2. В обоих случаях код компилируется в нативный код iPhone, в обоих случаях используется библиотеки iPhone SDK, поэтому теоретически скорость должна быть сравнимо одинаковой, хотя точную статистику не видел.
3. AppStore нормально относится, например есть уже проекты, написание на CocosNet (порт cocos2d на MonoTouch), XNATouch (разработка XNA приложений на MonoTouch).
2. В обоих случаях код компилируется в нативный код iPhone, в обоих случаях используется библиотеки iPhone SDK, поэтому теоретически скорость должна быть сравнимо одинаковой, хотя точную статистику не видел.
3. AppStore нормально относится, например есть уже проекты, написание на CocosNet (порт cocos2d на MonoTouch), XNATouch (разработка XNA приложений на MonoTouch).
А почему на MonoTouch легче писать, чем на Obj-C? Кроме синтаксиса. Ведь GC вроде отсутствует?
Присутствует.
Вот тут список фич
Вот тут список фич
Синтаксиса вполне достаточно. Он у Objective C малось избыточен. А если кроме синтаксиса то еще стандартные библиотеки. Те, которые работают со строками, временем и прочим. Идщее в комплекте также предполагает написание больше кода чем это обычно требуется на .NET
Так вот, почему я люблю .NET и C#, что мне не нужно отвлекаться на то, как что-то реализовать, а можно сконцентрироваться на то, что мне нужно реализовать.
Как-то не логично :)
Спасибо за информацию! +
можете поделиться информацией как сделали или намекнуть, а если не жалко поделиться исходником :)гг
Необходимо было разработать красивый эффект перелистывания страниц для одного iPhone приложения. Хороший пример того, что нужно было сделать, был найден в интернете в виде Silverlight-приложения.
Если мне не изменяет память, то что-то подобное я видел в сэмплах или сдк silverligth, ещё с версии 1.х там что-то такое было.
К сожалению, исходниками поделиться не могу, все таки это коммерческий заказ, но получилось что-то на подобии этого. А Вот как сделали — думаю поделись после окончательного завершения работ.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Mono, MonoTouch + C# vs. iPhone SDK + Objective-C