>давайте! пенсионеров не трогать и отдать ему должное - человек революционер Вай, сколько апломба. Лучше б столько же достижений было :)
>это политика мелкомягких - делать всё для себя и под себя
>их не волнует будет ли С# под линукс или мак ось
Тогда вполне честно если остальных не будут волновать продвигаемые ими стандарты. И я не вижу ни 1 причины почему кому-то надо упереться и ... помочь MS остаться в лидерах. Ну или зачем играть в заведомо проигрышную игру где стартовые условия неравные? Нахрена мне например осваивать MS-ориентированный рантайм и язык продвигаемый только MS или их шестерками? Я хочу со временем уйти от юзежа винды СОВСЕМ. Пингвины в качестве оси мне как-то куда больше доставляют. А вот быть отбросами второго сорта мне не улыбается. Приветы Майкрософту, ага. А нокия почему-то не делит на сорта юзеров своей либы.
>зато их волнует будет ли под амд или интел (вот понятие кросплатформенности)
А как насчет MIPS или ARM? А чтобы еще и не под виндами? Или в этом месте ус нечаянно отклеивается и кроссплатформеннсть оказывается лишь маркетинговым пщиком?
>новые альтернативные языки
Во всяком случае - я не вижу на кой бы хрен линуксоидам тратить силы на левые догонялки MS. Простите, а почему формат бинарей в "кроссплатформенной" среде не платформонейтральный а виндовое EXE пардон? Сани же вон сделали платформенно-нейтральные форматы файлов, например. А MS ... ну как обычно: гребут под себя делая так чтобы остальные соснули.
>повторюсь - на любой архитектуре под которую имеется винда (платформа нет) и
>компилятор С# - да будут работать
Да, только винда есть для не сильно многих архитектур, так что никакого спича о портабельности тут не иде. Ну нет винды для арм, мипс и ппц. Вообще. Поддержка полутора процессорных архитектур - не портабельность и не кроссплатформенность а жалкая пародия.
>мелкомягких не волнует линукс и мак ось
>любую архитектуру поддерживает ???? - значть кросплатформенный
Дык не любую. Где обычная винда для ARM, MIPS или PPC например? Не вижу.
>если в С++ только реализовали замыкания то в С# это было изначальной задумкой.
И чего?Как я уже сказал, для лично меня то что оно нигде толком кроме винды и i386/AMD64 не работает - уже отличная заявка на фэйл.
>непонял юмора как использовать одни и теже дрова при этом ихх переписывая ???
Если дрова на асме - их придется переписать. С нуля. Что гемор нереальный. А на сях ... простите, только перекомпилить. Что как-то ну совсем не гемор.
>достаточно изучит архитектуру каждого проца и всё а "ЮСБ он и в
>Африке ЮСБ" теже айэркю, димиэй, порты ввода-вывода и диапазон памяти.
Вы не поверите но в линухе зачастую достаточно пересобрать драйвер. Возможно с какими-то небольшими адаптациями, но основная масса логики - изменений не потребует. Например драйвер какогонить usb mass storage class - будет получен для мипсового или PPCшного линукса просто тупой компилежкой его сорса. Да, совсем платформоспецифичные вещи придется ессно переписать или написать. Те же IRQ, DMA и прочая разными процессорами понимаются по разному, факт. А вот какойнить usb mass storage с EHCI контроллером - он и в африке mass storage, с EHCI контроллером. И основная масса логики там останется неизменна. Ну а вы можете переписывать если вам не влом. Ну или шина PCI и логика работы с PCI девайсами как правило везде достатчно одинаковая например - ARM, MIPS или кто там еще обычно реализуют более-менее стандартные сущности. Переписывать с нуля дрова в свете этого было бы достаточно не умно.
>я не говорю что С плох и что я категорически против него.
>новые языки это метод облегчения труда программиста (незря ЛЕНЬ двигатель прогресса).
В итоге большая часть дотнетчиков не способны даже примитивный base64 декодер написать... и на все стандартные отмазы вида "для этого у MS нет класса". По-моему называть таких упырей программистами - сильно жирно. Это генераторы glue-кода между MSовскими классами. Не способные сами генерить никаких вменяемых алгоритмов.
>И программа на С не уступает программам на асм (ну немножко в скорости и гибкости)
Насчет скорости - да, при том иногда - не так уж и немножко. Скажем чисто-сишный XVID сливает си+асм варианту чуть ли не в разы. Просто потому что сишный компилер может сгенерить хрен знает какой код в узком цикле и человек зная что критичное место вон там - может вон там и написать оптимально, возможно чуть просадив этим оптимальность в месте где это имело куда меньшую цену. Насчет гибкости - на си такое заворачивают что диву даешься. Ткнуть сишный компилер "вот тут у нас readonly code в флеше, вот тут статичные данные в флеше, а вон там - переменные в оперативке" - совершенно не вопрос. Как не вопрос убедить его выдать эти блоки в каком угодно виде. То есть, по сути сишный компилер типа GCC может своим линкером чуть ли не готовый RAW образ фирмвари изобразить, пардон. И строго говоря - сишная программа написанная должным образом не нуждается в стандартных либах, файлах и прочая. Чисто-алгоритмические куски - весьма портабельны.
>и поэтому в С реализовали инлайн ассемблинг
Ну вы просто ARMовское ядро Cortex-M3 не видели :). Оказывается если чутка подыграть сям ... в этом ядре можно извините самые первые инструкции выполнять именно сгенеренные сишным компилером. Т.е. данное ядро при желании можно программить вообще без асма по сути. Нужно ли... думаю каждый сам найдет ответ на этот вопрос. Ради справедливости замечу что другие процессоры более капризны к последовательностям раннего старта и сразу после включения не предоставляют окружение годное для выполнения сишной программы. Но тем не менее какойнить CoreBOOT и то в основном писан на сях :).
>тока под какую ОС ???
А ни под какую. Bare metal там зачастую. Бывают RTOS но сие на любителя(чем сложнее система и больше сущностей, тем больше секаса с отладкой). И да, сишная программа может работать в окружении где...
- Нет printf, стандартного ввода-вывода, файловой системы, etc. Правда круто? В эмбеддед такое на каждом углу в мелких однокристальниках. А си позволяет и такое зафигачить. Это к вопросу о гибкости :)
- Нет malloc и подобных. Все статически, сразу на старте (попробуйте так в манагед языках изобразить, ага).
- Всякая там инициализация периферии и работа с ней напрямую - без вопросов.
В общем то вещей которые можно сделать на асме и нельзя на си - не так уж и много. Си изначально был задуман как язык системщиков и он с этой ролью справляется на 5 баллов имхо.
