Здравствуйте, VladD2, Вы писали:
VD>>>Менялся, но это не важно. Ввели инлайн-массивы (для ускорения работы с интеропом).
AVK>>Интероп это не ансейф.
VD>Ага. А бутылка не ложка. И? VD>Я говорю о то для на что было расчитано расширение языка. Хотя конечно кроме интеропа это дело кое-где еще может пригодиться.
Только это не имеет никакого отношения к тому что я написал, а именно в плане unsafe никакого изменения в 2.0 не было. А inline массивы вполне можно использовать и в safe-коде.
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Только это не имеет никакого отношения к тому что я написал, а именно в плане unsafe никакого изменения в 2.0 не было. А inline массивы вполне можно использовать и в safe-коде.
Нет. Ты ошибашся. Почитай спецификацию.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали: AVK>Ну типа размеры сборок уменьшали. по байту на команду — можно много съэкономить.
Совершенно верно. Причем, что характерно, всего команд в первом FW — 224. Т.е. выкинув "лишние" опкоды ничего сэкономить бы не получилось — вряд ли опкоды размером меньше байта завоевали бы популярность.
Мне лично мсил показался как раз очень продуманным в том смысле, что самые частые команды типа ldarg.0 и ldc.0 занимают по одному байту вместе со всеми аргументами.
Это как раз показывает, что авторы думали не только в стиле "бывает 0, 1, и много". А сравнивали частоты различных значений аргументов. С учетом отсутствия в дотнете встроенной поддержки компрессии байт-кода это — достаточно нормальное решение. Полная версия команды загрузки целой константы жрет пять байт — в пять раз больше ldc.0. А этих ldc.0 больше, чем любых других (for int i=0...).
Опять же, ведь никто не принуждает тебя использовать шорткаты. Можешь всегда пользоваться полной формой, если тебе это проще.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Только это не имеет никакого отношения к тому что я написал, а именно в плане unsafe никакого изменения в 2.0 не было. А inline массивы вполне можно использовать и в safe-коде.
В спецификации направленной в ECMA я этот понкт не нашел. Или плохо искал, или просто пока не добавили. Но в языке фича есть и поддерживается еще с бэты 1.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Это как раз показывает, что авторы думали не только в стиле "бывает 0, 1, и много". А сравнивали частоты различных значений аргументов. С учетом отсутствия в дотнете встроенной поддержки компрессии байт-кода это — достаточно нормальное решение. Полная версия команды загрузки целой константы жрет пять байт — в пять раз больше ldc.0. А этих ldc.0 больше, чем любых других (for int i=0...).
А по моему это изврат. Если они хотели экономить то пусть бы они делали это при записи в фаил.
ИМХО лучше считать что бывает только 1, 0 и много (а то и просто бывает только много) чем плодить опкоды.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Sinclair, Вы писали:
S>>Это как раз показывает, что авторы думали не только в стиле "бывает 0, 1, и много". А сравнивали частоты различных значений аргументов. С учетом отсутствия в дотнете встроенной поддержки компрессии байт-кода это — достаточно нормальное решение. Полная версия команды загрузки целой константы жрет пять байт — в пять раз больше ldc.0. А этих ldc.0 больше, чем любых других (for int i=0...). WH>А по моему это изврат. Если они хотели экономить то пусть бы они делали это при записи в фаил. WH>ИМХО лучше считать что бывает только 1, 0 и много (а то и просто бывает только много) чем плодить опкоды.
Не понимаю тех, кто говорит про нелогичность. Можно подумать, что вы программируете в шестнадцеричном редакторе, а не на C#/Visual Basic. Меня абсолютно не колышет логичность/не логичность MSIL кода, я его и не вижу.
А то, что он получается чуть поменьше — это здорово, это объективный профит, в отличие от "логичности".
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, _Winnie, Вы писали:
_W>Не понимаю тех, кто говорит про нелогичность. Можно подумать, что вы программируете в шестнадцеричном редакторе, а не на C#/Visual Basic. Меня абсолютно не колышет логичность/не логичность MSIL кода, я его и не вижу.
Хотя конечно можно просто мысленно забыть о существовании сокращенных команд и пользоваться только полными.
_W>А то, что он получается чуть поменьше — это здорово, это объективный профит, в отличие от "логичности".
Дык, речь и идет о том, что расширенный набор команд могли бы порождать райтеры пишушие код в поток.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
CC>Огромное сорри за оффтоп, но сколько уже периодически читаю ответы в эту ветку, каждый раз механически читаю ее название как "попИсал на С++... долго думал ".
Я только хотел написать про это...
... << А писал я этот бред на RSDN@Home 1.1.4 stable rev. 510, под звуки Алиса — Все в наших руках>>
Здравствуйте, srggal, Вы писали:
PD>>С врапперами вокруг хендлов не так все просто. Дело в том, что многие хендлы имеют ассоциированный с ними счетчик. Например, LoadLibrary-FreeLibrary, Create/OpenXX — CloseHandle. И если кто-то в этом случае будет вызывать исходные функции Win API напрямую, то без проблем не обойдется.
S>Да, проблемы могут возникнуть, но в кривых — не умелых или неопытных, а может и просто в невнимательных руках
S>Но ведь можно использовать подобную функциональность правильно ?
Мы-то можем, но где гарантия. что эту Library кто-то не загрузит еще раз из ненашего кода ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, srggal, Вы писали:
PD>>>С врапперами вокруг хендлов не так все просто. Дело в том, что многие хендлы имеют ассоциированный с ними счетчик. Например, LoadLibrary-FreeLibrary, Create/OpenXX — CloseHandle. И если кто-то в этом случае будет вызывать исходные функции Win API напрямую, то без проблем не обойдется.
S>>Да, проблемы могут возникнуть, но в кривых — не умелых или неопытных, а может и просто в невнимательных руках
S>>Но ведь можно использовать подобную функциональность правильно ?
PD>Мы-то можем, но где гарантия. что эту Library кто-то не загрузит еще раз из ненашего кода ?
Нет гарантий. Нелюблю праноидальность , где гарантии, что Предоставленный Вами класс не разрушат дважды ?
class Foo{};
int main()
{
Foo pFoo = new Foo;
delete pFoo;
delete pFoo;
return 0;
}
Здравствуйте, Павел Кузнецов, Вы писали:
>> Если бы для С++ существовали в настоящий момент ср-ва рефакторинга, типа тех, что мы имеем для Java и C# <...>
ПК>Xrefactory пробовал?
(Вернее, пробовал последний раз 4 года назад всевозможные плагины макросы и настройки, но это все было, мягко говоря, не совсем с человеческим лицом, поэтому отказывался и всерьез не использовал... Сделаю еще один заход...)
Здравствуйте, Sinclair, Вы писали:
S>Мне лично мсил показался как раз очень продуманным в том смысле, что самые частые команды типа ldarg.0 и ldc.0 занимают по одному байту вместе со всеми аргументами.
Сегодня вчерне как раз дописал миникомпилятор. Вобщем, кое где эти ldc_i4_0 и ldnull довольно удобны, например при работе с bool. Единственное, наличие ldc_i4_2 — ldc_i4_8 меня несколько удивляет.
А IT понятно почему ругается, он на br/br.s словил в RFD презабавнейшую багу в крайне неудачный момент (ИМХО потому что документацию невнимательно читал ).
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Павел Кузнецов, Вы писали:
>>> Если бы для С++ существовали в настоящий момент ср-ва рефакторинга, типа тех, что мы имеем для Java и C# <...>
ПК>>Xrefactory пробовал?
V>EMacs для С++ всерьез не пробовал, но обязательно попробую после этих обсуждений http://www.rsdn.ru/Forum/Message.aspx?mid=1428475&only=1
.
V>(Вернее, пробовал последний раз 4 года назад всевозможные плагины макросы и настройки, но это все было, мягко говоря, не совсем с человеческим лицом, поэтому отказывался и всерьез не использовал... Сделаю еще один заход...)
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, AndrewVK, Вы писали:
IT>>>Ну разве что только "в отличии от x86".
AVK>>А что тебе там не понравилось?
IT>Экономия места мне там не понравилась. Систему команд можно было сделать в два раза проще выкинув короткие версии команд и все эти ldarg.0, .1, .2, .3. С примитивными типами тоже намудрили. ldc команд почему-то 4, а conv и ldind по полной схеме. Можно было иметь вообще по одной команде, если сопроводить её целевым типом или брать его со стека. Загрузка самого типа делается через задницу — ldtoken с последующим вызовом Type.RuntimeTypeHandle. Нельзя для этого было команду отдельную сделать? ldarg и ldloc — это суть одно и тоже. В общем, хватает там косяков. Видно, что делали не "выразительную и удобную" систему команд, а просто экономили байты, захломляя саму систему команд всяким мусором.
Обычное дело в системе команд — наиболее частоиспользуемые вещи должны иметь наиболее короткую кодировку.
Мне понравилась сама стековая направленность системы команд, т.е. общий принцип. Т.е. уходим от специфичных регистров АЛУ, ибо их наличие уже просто необоснованно, и служит скорее, ограничением. В реальных процах все-равно этих регистров давно нет (имеется ввиду одноименных и с тем же функционалом), а есть конвееры и планировщики ОПЕРАЦИЙ.
Здравствуйте, AndrewVK, Вы писали:
VD>>Какой Ремоутинг? Речь о КОРБА.
AVK>Он наверное имел ввиду Transparent/RealProxy
Нет, я имел ввиду ChannelServices и RemotingServices, использующих эти прокси и IMessage заодно.
Речь ведь шла о реализации CORBA на дотнете, и Влад спрашивал, при чем тут структуры и сериализация. Я показал, как они связаны.
CORBA-channel должен сделать то же самое как и любой channel — всего навсего передать IMessage (MethodCallMessage и пр. шушеру), и восстановить этот IMessage на другой стороне для вызова инфраструктурой .Net.
По сути, CORBA-channel можно назвать всего-навсего форматтером канала. На обоих сторонах канала полностью используется .Net Remoting фреймворк. По проводу "текут" данные в формате GIOP/IIOP.
В случае "обычного" .Net Remoting по проводу текут данные в формате .Net Binary Serialization, например.
GIOP/IIOP не содержит метаинформации, при вызове методов всегда точно должна быть известна сигнатура. Поэтому не поддерживаются перезагрузки сигнатур.
----------
Что касается самой сериализации, то разные поставщики CORBA под дотнет делают ее по-разному. Например — генерить из IDL сразу двоичную сборку, содержащую интерфейсы и типы данных, размеченных аттрибутами, управляющими маппингом сложных .Net типов на CORBA типы (простые мапятся легко, ибо обе платформы имеют фиксированное представление простых чисел).
Некоторые генерят исходники Transparent/RealProxy, которые выполняют эту сериализацию/маппинг.
Есть правда и такие решения CORBA под .Net, которые полностью все делают сами и несут в себе собственный фреймворк. Такая архитектура мне кажется самой неудачной.
Выполнен в виде форматтера канала. IDL-компилятор генерит интерфейсные .Net-сборки, которые можно будет потом использовать и для обычного Remoting. Т.е. сервак может выставить одни и те же интерфейсы на разных портах для разных подсистем , например, для дотнета — слушать по родному TCP Remoting, а для Java/C++ открыть понятный им IIOP.
Есть так же утилита, которая берет дотнетную сборку и генерит IDL на ее основе. Именно так можно открывать интерфейс для С++/Java к имеющимся .Net приложениям.
Здравствуйте, Cyberax, Вы писали:
C>vdimas wrote:
>> _W>Напиши аналог boost::optional или boost::variant. >> Хм.. для variant необходимо что-то типа union.
C>Нет. Внутри boost::optional/variant просто используется буффер, который C>по разному интерпретируется.
Да ну? Память ЭВМ — это буфер, который по разному интерпретируется. Мы ведем речь о безопасности и удобстве. Двигаемся далее.
>> В общем, сделать размеченный union частью языка, примерно как в >> спецификациях CORBA.
C>Кхм. Вы доку на boost::variant смотрели?
variant — Safe, generic, stack-based discriminated union container, from Eric Friedman and Itay Maman.
Прошу заметить, что память в variant не то, чтобы реинтерпретируется как угодно, она там инициализируется, т.е. для сохраняемых значений вызывается new(address) Type(); Таким образом, не существует возможности значению попасть туда кроме как через конструктор (копирования в т.ч.), что и требуется для безопасной работы.
И нет вообще никакой возможности прочитать значение не того типа, которое хранится в данный момент. А какой тип хранится — узнать нельзя, потому как типы нумеруются в CompileTime и variant хранит порядковый номер типа текущего значения из листа типов (т.е. variant<int, long> не одно и то же что variant<long, int>, что правильно с т.з. С++, но не совсем правильно семантически). Не зря рекомендуют использовать визитор для извлечения данных.
А вот отрывок из раздела Motivation по разработке variant, читаем внимательно:
Clearly another approach is required. Typical solutions feature the dynamic-allocation of objects, which are subsequently manipulated through a common base type (often a virtual base class [Hen01] or, more dangerously, a void*). Objects of concrete type may be then retrieved by way of a polymorphic downcast construct (e.g., dynamic_cast, boost::any_cast, etc.).
However, solutions of this sort are highly error-prone, due to the following:
— Downcast errors cannot be detected at compile-time. Thus, incorrect usage of downcast constructs will lead to bugs detectable only at run-time.
— Addition of new concrete types may be ignored. If a new concrete type is added to the hierarchy, existing downcast code will continue to work as-is, wholly ignoring the new type. Consequently, the programmer must manually locate and modify code at numerous locations, which often results in run-time errors that are difficult to find.
К сожалению, текущая версия variant прямо-таки провоцирует на вот это:
variant<int, long, std::string> v;
v = "Hello World!";
switch(*(char*)&v) {
case 0: // int
case 1: // long
case 2; // string
};
Но исходный посыл это не меняет. Безопасный union мог бы быть частью языка. В том виде, что мы имеем сейчас, С++ унаследовал от C очередную опасную конструкцию.
В общем, продолжаю рекомендовать посмотреть синтаксис и семантику описания union в CORBA. Мне гораздо более нравится явный диспечеризатор, чем неявный compile-time перечислитель типов, который к тому же недоступен для опроса. Бустовским вариантом в итоге неудобно пользоваться, потому как необходимо диспечеризатор писать самому, за счет побочного эффекта:
------------
одно продолжает радовать в С++ — это самодостаточность. Если чего-то в языке нет, то это "что-то" можно дописать самому. Пока что это уникальная фича, примера которой я еще не видел.
Здравствуйте, VladD2, Вы писали:
VD>>>Стабы наверно все же генерируеются генераторами кода idl2xxx. Но причем тут ОРБ? Он то скорее всего на плюсах написан.
V>>Нет, написанны они на дотнете, и выполнены как форматтеры каналов или же в виде самих каналов (у кого как), т.е. используют инфраструктуру .Net Remoting,
VD>Какой Ремоутинг? Речь о КОРБА.
Блин, я уже который раз пропагандирую это интересное сочетание, только проснулись...
1.1.4 stable rev. 510
"Всё что не убивает нас, делает нас сильнее..."
ldarg и ldloc — это суть одно и тоже. В общем, хватает там косяков. Видно, что делали не "выразительную и удобную" систему команд, а просто экономили байты, захломляя саму систему команд всяким мусором.
