Mono 1.9 Released

Зачем лжешь? Mono - запустится. M$ Compact Framework на ARM только так работает. Так что ты дурак, однозначно.

>Зачем лжешь? Mono - запустится. M$ Compact Framework на ARM только так работает. Так что ты дурак, однозначно.

Mono!=MS.NET

>Зачем лжешь? Mono - запустится. M$ Compact Framework на ARM только так работает. Так что ты дурак, однозначно.

Mono!=MS.NET

MS.NET = mono + $$$

mono = MS.NET - $$$

mono < MS.NET

>Ты можешь обоснованно высказать претензии к .net? Не можешь. Убейся.

>Зачем лжешь? Mono - запустится. M$ Compact Framework на ARM только так работает. Так что ты дурак, однозначно.

Тебя уже послали. Сюда http://heroes2008.ru// Mono не .NET 1.0. И запусти мне Mono на Debian@PPC.

>Это тот анонимус что крыл меня "ламером" ??? Мне влом тебя просвещать.

Давай, объясняй, чем куча в ОЗУ от стека в ОЗУ отличается?

>>Или например тип DateTime, чтоб его можно было складывать, вычитать, и не писать все время clone().

>java.util.Calendar тоже складывается и вычитается

не помню интрефейса java.util.Calendar, я напишу что надо от даты:

DateTime a = new DateTime("31.12.2007");

DateTime b = a; b.day=27;

И после этого a.day должно остаться 31, а не стать 27. Как насчет этого в яве?

>И после этого a.day должно остаться 31, а не стать 27. Как насчет этого в яве?

есть, но только для примитивов

Ты инклюды не написал. Не могу проверить :-( а должен быть 12 байт объем.

>>И после этого a.day должно остаться 31, а не стать 27. Как насчет этого в яве?

>есть, но только для примитивов

А в моне (и .нет) это будет, если DateTime не класс, а структура.

>И после этого a.day должно остаться 31, а не стать 27. Как насчет этого в яве?

Противопоставлять передачу по ссылке передаче по значению не очень умно... Хотя на лоре соейдет

P.S. Ээээх тоже что ли потролить....

>А в моне (и .нет) это будет, если DateTime не класс, а структура.

зато в жабе меньше ключевых слов (см. бритву оккама) - нету всяикх override, virtual и пр.

>Ты инклюды не написал. Не могу проверить :-( а должен быть 12 байт объем.

#include <iostream> #include <memory>

А? Так структуры это просто immutable value objects? Ну и чо мешает использовать этот паттерн в жабе где надо? Отсутствие sintsugar? Мнда. Продолжайте в том же духе у Баллмера со--ть.

Супер! У меня всего 4 байта! gcc / cygwin

Щас отпишу код.

$ g++ cmd_adptr.cxx && ./a.exe
Handler invoked
sizeof(cmd)=4
sizeof(createCommandAdaptor(fooInst.get(), &Foo::handler))=4

____________________________________________________________


#include <iostream>
#include <memory>

class Command {
public:
	virtual void execute() = 0;
};

template<typename T> std::auto_ptr<Command> createCommandAdaptor(T* obj, void (T::*mem_ptr)() ){
	class CommandAdaptor : public Command {
		T *const _ptr;
		void (T::*_mem_ptr)();
	public:
		CommandAdaptor(T* ptr, void (T::*mem_ptr)())
			:_ptr(ptr)
			,_mem_ptr(mem_ptr)
		{}
		virtual void execute() {
			(_ptr->*_mem_ptr)();
		}
	};
	return std::auto_ptr<Command>(new CommandAdaptor(obj, mem_ptr));
}

class Foo {
public:
	void handler() {
		std::cout<<"Handler invoked\n";
	}
};


int main(int argc, char* argv[]) {
	std::auto_ptr<Foo> fooInst(new Foo);
	std::auto_ptr<Command> cmd(createCommandAdaptor(fooInst.get(), &Foo::handler));
	cmd->execute();
  std::cout << "sizeof(cmd)=" << sizeof(cmd) << "\n";
  std::cout << "sizeof(createCommandAdaptor(fooInst.get(), &Foo::handler))=" 
    << sizeof(createCommandAdaptor(fooInst.get(), &Foo::handler)) << "\n";
	return 0;
}

> А? Так структуры это просто immutable value objects? Ну и чо мешает использовать этот паттерн в жабе где надо?

О мудрейший, наклепай-ка 20 строчек и продемонстрируй нам свой великий паттерн... чтоб DateTime копировалась по значению.

>$ g++ cmd_adptr.cxx && ./a.exe

>Handler invoked

>sizeof(cmd)=4

>sizeof(createCommandAdaptor(fooInst.get(), &Foo::handler))=4

Ты измерил размер указателя Command*. А надо измерить количество кода которое будет генерироваться при каждом разворачивании шаблона createCommandAdaptor, и размер инстанса внутреннего анонимного класса CommandAdaptor.

>>Ты инклюды не написал. Не могу проверить :-( а должен быть 12 байт объем.

>#include <iostream> #include <memory>

А ты когда про 100 байт говорил, наверно имел в виду объем кода?

> Ты измерил размер указателя Command*. А надо измерить количество кода которое будет генерироваться при каждом разворачивании шаблона createCommandAdaptor, и размер инстанса внутреннего анонимного класса CommandAdaptor.

sizeof(CommandAdaptor)=16

Как ты предлагаешь мерить? написать пару одинаковых шаблонов?

А вообще надо посидеть подумать, че-то слишком сложно выглядит все это... вроде проще можно.

Задача в чем была?

>>>Ты инклюды не написал. Не могу проверить :-( а должен быть 12 байт объем.

>>#include <iostream> #include <memory>

>А ты когда про 100 байт говорил, наверно имел в виду объем кода?

Да, для каждого класса T к методу которого адаптируется интерфейс Command, будет сгенерировано одно тело функции createCommandAdaptor, содержащее локальный класс.

>А вообще надо посидеть подумать, че-то слишком сложно выглядит все это... вроде проще можно.

Иначе никак, по крайней мере стандартными средствами С++ без привлечения препроцессора. В boost::function & Loki::Functor интерфейс Command дополнительно завернут в объект-значение.

>Задача в чем была?

*Воспользоваться* такой замечательной фичей С++ как указатель на метод класса.

Задача твоя мне не ясна. Может тебе позарез надо именно

createCommandAdaptor(T* obj, void (T::*mem_ptr)() )

но я думаю что вполне можно сделать Т потомком класса с оператором () и не передавать void (T::*mem_ptr)()

В яве в основном такая задача стоит: при клике на кнопку вызвать функцию.

>>Задача в чем была?

>*Воспользоваться* такой замечательной фичей С++ как указатель на метод класса.

Такая задача решается СОВСЕМ по-другому :-)

Непонятно зачем класс CommandAdaptor прятать внутрь функции createCommandAdaptor? Наоборот:

CommandAdaptor cmd(fooInst.get(),&Foo::handler);

cmd.execute();

Не нужен нам вроде здесь анонимный класс, обычный как раз хорошо.

А насчет веса CommandAdaptor -- я думал он будет 12 байт весить, а он весит аж 16.

А остальное -- мелочи, в CommandAdaptor можно все сделать в inline. В яве тоже ведь байткод че-то весит.

Короче видимо я свой вариант слабаю...

http://www.microsoft.com/rus/msdn/magazine/2004/03/sciencecomputing.mspx

Упал и плакалъ под столом :D

Понял откуда лишние 4 байта -- Command виртуальные фунции имеет.

>Непонятно зачем класс CommandAdaptor прятать внутрь функции createCommandAdaptor?

Мне нужна только реализация интерфейса Command. CreateCommandAdaptor нужна чтобы делать переходники Command -> member method, очевидно чтобы не экстендить Command под каждый чих.

>>Непонятно зачем класс CommandAdaptor прятать внутрь функции createCommandAdaptor?

>Мне нужна только реализация интерфейса Command. CreateCommandAdaptor нужна чтобы делать переходники Command -> member method, очевидно чтобы не экстендить Command под каждый чих.

Если задача ставилась "одеть интерфейс Command на класс Foo", то все у тебя правильно, включая функцию createCommandAdaptor -- без нее template не сработает :-( или придется добавить <Foo>, т.е. CommandAdapter<Foo>(...)

Явовские анонимные классы в основном юзают вроде не для этого, почему я и тормозил сильно.

Сопоставлять надо что-то сопоставимое.

> очевидно чтобы не экстендить Command под каждый чих.

Ты его эктендишь в шаблоне, этакое наследование своими руками... может это и правильно.

А какие могут быть претензии кроме 16 байт? Ведь у тебя все в CommandAdaptor идет инлайн.

> Мне нужна только реализация интерфейса Command. CreateCommandAdaptor нужна чтобы делать переходники Command -> member method, очевидно чтобы не экстендить Command под каждый чих.

Если же мы будем писать гуи аппликуху, то я думаю Foo с самого начала будет потомком Command, и ничего одевать на него не придется.

Отрежь себе голову, идиот.

Mono - реализация .NET. И не колышет. Мнение красноглазой мрази мне не интрересно.

>Mono - реализация .NET. И не колышет. Мнение красноглазой мрази мне не интрересно.

Ага. А Windows Server 2008 это полностью POSIX совместимая ОС.

Ты не виталик. Выдыхай

>Если задача ставилась "одеть интерфейс Command на класс Foo", то все у тебя правильно, включая функцию createCommandAdaptor -- без нее template не сработает :-( или придется добавить <Foo>, т.е. CommandAdapter<Foo>(...)

Только у класса Foo может быть несколько хандлеров. Напрмер, если Foo - это панель с десятью кнопками, и в каждой кнопке надо зарегистрировать обработчик клика.

>Явовские анонимные классы в основном юзают вроде не для этого, почему я и тормозил сильно.

Нет, имеенно для этого - чтобы передать наружу некий инстанс Callback-интерфейса, за который тебя дергнут когда случится какое-то событие.

>> очевидно чтобы не экстендить Command под каждый чих.

>Ты его эктендишь в шаблоне, этакое наследование своими руками... может это и правильно.

А иначе почти невозможно С++ указатели на методы применить хотя бы для чего-нибудь. Это не делегаты. (T::*)() нельзя привести к (U::*)(), даже если U это субкласс T.

> http://www.microsoft.com/rus/msdn/magazine/2004/03/sciencecomputing.mspx

Дальше примера про перемножение матриц не смог читать. это какой-то пипец. На си это выглядит в 2 раза короче, работает в 10 раз быстрее и занимает в в 4 раза меньше памяти.

мда, мс усиленно плодит дебилов. ими управлять легче.

> мда, мс усиленно плодит дебилов. ими управлять легче.

Все проще. Этих дебилов можно не бояться. Они точно не напишут код который сможет конкурировать с Microsoft, а соответственно продукция от Microsoft будет работать
надежнее, быстрее, стабильнее. Чем сторонние разработки.

> пользы от этого проекта - ноль, так как никто приложения и близко не портирует

Всё вполне закономерно: зачем _портировать_ то, что изначально подразумевалось _совместимым_?
Я готов _немного_ допилить приложения (отказавшись от сугубо ВыньДОС фич), чтобы те работали в Линуксе, но заниматься костылями и обёртками целый месяц и по всему проекту - мне чисто лень.

> Платформа nono должна обладать какими-то выдающимися преимуществами перед Java и другими языками и платформами

Достаточно того, что ДотНЕТ + VS - это цельная, самодостаточная платформа для разработки. Будут под Линуксом эти оба - будет ВСЁ.

>Платформа nono должна обладать какими-то выдающимися преимуществами перед Java и другими языками и платформами, давно используемыми в Linux и даже переносимыми на Windows, чтобы всерьёз быть кому-то нужной и без следования за .NET.

А mono этим и обладает. Это идеальная VM, под которой эффективно работают самые разнообразные языки. Тогда как JVM это Java-only.

>Это идеальная VM

для идеально пустого мозга.

> кстати, нравиться мне эта здоровое веяния на лоре не поливать друг друга говном.

Всего лишь временное затишье - говна не завезли. :)))

Людям (особенно вчерашним студентам) очень трудно сдерживать свои эмоции. Если человек в силу недостаточного знания (а таковое есть у всех) порицает нечто, редко кто удержится, чтобы не макнуть его в говно и громко прокричать про свой любимый пакет/дистрибутив/язык. Внимание, правильный вопрос: А какого отношения к Линукс вы ждёте ПОСЛЕ этой реакции??! Что вы выдаёте, то обратно к вам и приплывает.

И если вместо чесания языков и тыканья в ссылки, ЛОРовцы затратят хотя бы 1% времени на документацию (типа HOWTO), пользы будет стократно больше.
Скажем, вот недавно возник спор по поводу среды разработки. Ну хорошо, НЕ МОГУТ все знать, что в Линуксе хорошо, что недоработано, а что вообще юзать нельзя. ТАК НАПИШИТЕ ОБ ЭТОМ! Сделайте мини-HOWTO, типа "Полная tool-chain для newLISP с GTk", или "C++ под Eclipse", или "D + СУБД + FLTK". Неважно, главное - чтобы человек мог реально по данным инструкциям собрать полноценную среду.
Учтите, что прогеры - это не хакеры и не админы, у них нет времени тестировать каждую перделку на пригодность. Тем более, что с "пригодностью" в Линуксе хорошо только для старых, отполированных программ. Так что не надо жаловаться на то, что прогеры бегут под винду (или не прибегают на Линукс) - сами же (бездействием) их и отпугиваете.
У меня всё. :)

CLR и CLI сертифицированы ECMA как ECMA-335 стандарт и отправлены в свободное от MS плавание.. поэтому и MONO смогли реализовать легально, кста..

"Windows.Forms использует родной бэкенд для Mac OS X"

Ну надо же!:) Только я уж лучше Cocoa + Objective C 2.0 использовать буду. Сравнивать уродство Windows.Forms и изящество NS-классов это все равно что кондовый "ровербук" с MacBook Air сравнивать. :))

> Да, и польза моно хотя бы в том, что яве наконец-то появился мощный конкурент.

...только на десктопах. На серверах Mono вряд ли запустят.

>>> структуры могут иметь перегруженные методы и конструкторы, статические поля и реализовывать интрефейсы.

>> И что же это тогда за структуры такие?

> Главное что они могут лежат на стэке, а не в куче. Такого в JVM нет.

В JVM 1.6 (Mustang) локальные объекты, область видимости которых ограничивается методом в котором они созданы, по возможности размещаются на стэке.

По-моему, это должно быть всем известно ещё из анонса этой JVM и Java 6.0.