в Objective-C стандарте они будут потому как его де-факто устанавливает Apple.
В стандарт С они будут его проталкивать. До того времени как это произойдет, они все-равно будут использовать Blocks, а для всех остальных буду писать предупреджения, мол поддерживается только нашим компилятором, будте осторожны.
В чем проблема помочь разработчикам gcc реализовывать стандарт (этот вопрос только по С++), а не писать свой (не совместимый со стандартом) патч или следовать практически принятому синтаксису ФП-выражений (по ссылке: The syntax of blocks and C++ lambdas are completely different)?
Для особо одаренных, объясняю еще раз:
1. в топике говорится про стороннюю реализацию. Что сделает Apple достоверно будет известно с выходом Snow Leopard
2. сторонняя реализация написана исключительно на Си(нечего специфически Си++сного там нет). Поскольку в C++ может использовать Си код, то эта реализация автоматически позволяет(но не заставляет) использовать блоки в С++
Apple нарушает совместимость кода, разбивая переносимость ПО — одного из основ разработки ПО, а вы этому и рады
нет, мы рады тому, что в Objective-C буду замыкания. И будут они по стандарту(дабы вас успокоить).
Будут ли они также в С и С++ мы не знаем. В сторонней реализации замыканий, описанной в этой статье, они присутствуют. Будут ли они в реализации от Apple — пока еще не знаем(или не говорим из-за NDA). Тем не менее, если они и будут, то Apple несомненно будет их проталкивать в новые стандарты.
ну возможно потому что использование раздельно Си и ObjC типов дает нихилое ускорение и возможность бесболезненного использования Сишного кода и библиотек. Хотя если бы написали правильный препроцессор с заменой Сишных типов на NSNumber в нужных местах, то было бы все ок.
Перегрузку операторов я считаю вредной :) Разве что для строк сделать какой-нибудь syntactic sugar.
ну всяко прятней писать myarray[15]
вместо [myarray objectAtIndex:15]
ведь необзяательно добавлять что-то в глубь языка, можно просто сделать на уровне syntax sugar
спасибо за новость, пойду наконец-то скачаю Snow Leopard.
Вот если бы Apple еще добавила в Objective-C возможность пользоваться базовыми сишными типами(int, float, ...) как классами-наследниками NSObject, чтобы можно было без проблем писать [myArray addObject:25], было бы вооще замечательно(про NSNumber знаю, но с ним возится долго)
чисто из интереса: а сколько WinMobile приложений(имеется ввиду более-менее серьезных) написано на CompactFramework? Просто я часто говорил с программерами под WinMobile, они юзать .Net сильно боялись, т.к. у большинства устройств мало памяти, и сама VM загрузит ее почти по полной?
конечно нужен мак. И конечно нужно заплатить $99 за iPhone Developer Program(хотя если вам нужно исключительно тестировать, то есть некоторые решения, правда только с джеилбрейком)
and can take advantage of the iPhone APIs as well as reusing both code and libraries that have been built for .NET
почему приводить аналогии неуместно? MonoTouch по смыслу такая же обвязка над Cocoa, как и PyQt над Qt.
Для моно есть AOT, для PyQt — GIT, разница не очень большая, но основной мой посыл был не в этом.
а пойти на офф сайт и почитать это невыполнимая задача?
To satisfy these technical and legal requirements, MonoTouch is delivered as a static compiler that turns .NET executables and libraries into native applications. There is no JIT or interpreter shipped with your application, only native code.
This is built on top of Mono's Ahead of Time Compilation technology
MonoTouch allows developers to create C# and .NET based applications that run on the iPhone and can take advantage of the iPhone APIs as well as reusing both code and libraries that have been built for .NET as well as existing skills.
Я уже писал выше, MonoTouch это обвязка CocoaTouch на C#, по идеологии точно такая же как и PyQt над Qt. В первом используется сборщик мусора Mono, во втором — Питона, они и сделяд за необходимостью удалять все объекты
Сейчас, в основном, использую внешний матовый монитор. Глаза устают меньше
В стандарт С они будут его проталкивать. До того времени как это произойдет, они все-равно будут использовать Blocks, а для всех остальных буду писать предупреджения, мол поддерживается только нашим компилятором, будте осторожны.
1. в топике говорится про стороннюю реализацию. Что сделает Apple достоверно будет известно с выходом Snow Leopard
2. сторонняя реализация написана исключительно на Си(нечего специфически Си++сного там нет). Поскольку в C++ может использовать Си код, то эта реализация автоматически позволяет(но не заставляет) использовать блоки в С++
что тут не ясно?
Будут ли они также в С и С++ мы не знаем. В сторонней реализации замыканий, описанной в этой статье, они присутствуют. Будут ли они в реализации от Apple — пока еще не знаем(или не говорим из-за NDA). Тем не менее, если они и будут, то Apple несомненно будет их проталкивать в новые стандарты.
Теперь Вы спокойны?
ну всяко прятней писать
myarray[15]вместо
[myarray objectAtIndex:15]ведь необзяательно добавлять что-то в глубь языка, можно просто сделать на уровне syntax sugar
Вот если бы Apple еще добавила в Objective-C возможность пользоваться базовыми сишными типами(int, float, ...) как классами-наследниками NSObject, чтобы можно было без проблем писать [myArray addObject:25], было бы вооще замечательно(про NSNumber знаю, но с ним возится долго)
Ну и перегрузку операторов неплохо бы…
почему приводить аналогии неуместно? MonoTouch по смыслу такая же обвязка над Cocoa, как и PyQt над Qt.
Для моно есть AOT, для PyQt — GIT, разница не очень большая, но основной мой посыл был не в этом.
Монодевелоп? под маком? Против XCode? Да не смешите меня