Здравствуйте AndrewVK, Вы писали:

AVK>Самое интересное — в разных языках доступ по умолчанию разный. В Дельфи это паблик, в джаве интернал, в c# прайват, в С++ зависит от того class это или struct. На эту тему целое исследование написать можно.

И что характерно, ни в одно языке не сделано так как бы я хотел. Сделали бы хоть ключик у компилятора...

AVK>>>Проверка на возврат значение мешает?
VD>>Иногда. Можно добавить прагму отключающую ее и ключ компилятора.
AVK>Зато дисциплинирует.

Ага. В С++ еще есколько завечательных вещей было... Сильно дисциплинировали.

Например: прямой проход case-а в swithe или присваения в if-е.

AVK>Тут самое главное не перегнуть палку. А то вон в джаве компилятор принудительно заставляет обработать все возможные исключения. Когда пишешь первые прикидки необходимость обрабатывать все возможные ошибки просто бесит. Хотя точно не забудешь их обработать.

Дык я не с этим не сопрю. Но протектед по дефолту логичнее. Да и времени много на написание модификатора не нужно. Ты же ведь не споришь с мем что тип функции нужно обязательно объявлять? А ведь в первых версиях С был дефолтный int (моежет и сейчас остался...).

AVK>>> GC мешает?
VD>>Иногда. Но если его малость доработать, то и отключать не надо будет (как в предыдущем случае).
AVK>Я думаю дорабатывать придется совсем не малость.

Ну, как скажишь... Главное шоб было быстро и удобно.

AVK>>>Необходимость обязательной имплементации объявленных интерфейсов мешает?
VD>>Мне нет. Делигаты эту проблему снимают очень красиво.
AVK>Это как? Ты имеешь ввиду то что интерфейс можно составить из делегатов и просто не присваивать им значение?

Эта проблема в основном встечалась при реализации событий. Теперь их можно делать на делегатах. Да и в других случаях если нужно добавить избирательный полиморфизм, делегаты очень даже помогают.

AVK>>>Дальше продолжать?
VD>>Давай.
AVK>Зачем?

А чё спрашиваешь?

Здравствуйте AndrewVK, Вы писали:

VD>>Кто же заставляет отказыватся от чего-то? Дефолты надо поправить, только и всего.
AVK>Да нет, тут народ предлагал ввести модификаторы отмены прайват. А дефолтовый модификатор конечно поправить можно.

Я конечно радикал, но не да такой степени. Хотя если народ хочет и если его предупредили о последствиях, то... Демократия однако.

Здравствуйте VladD2, Вы писали:

VD>"ты можешь предусмотреть все возможные глюки" романтик ты. Причем предумсотрительный. Да и шуток не понимаешь.

Не, просто на работе так достают что не до шуток. Надоело блин хуже горькой редьки. Пора новую работу искать.

Здравствуйте VladD2, Вы писали:

VD>И что характерно, ни в одно языке не сделано так как бы я хотел. Сделали бы хоть ключик у компилятора...



VD>Например: прямой проход case-а в swithe или присваения в if-е.

Кстати, еще один прикол. Прямые проходы в свитче запретили, но необходимость брека осталась. Шли бды уж до конца и делали как в паскале, без всяких брейков.

VD>Дык я не с этим не сопрю. Но протектед по дефолту логичнее. Да и времени много на написание модификатора не нужно.

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

VD>Ну, как скажишь... Главное шоб было быстро и удобно.

Несмотря на твои заверения, я пока пути существенно улучшить GC не теряя универсальности и гарантированности удаления не вижу.

VD>Эта проблема в основном встечалась при реализации событий. Теперь их можно делать на делегатах. Да и в других случаях если нужно добавить избирательный полиморфизм, делегаты очень даже помогают.

Да нет, я не так умно думал. Начинающих программеров сильно раздражает необходимость описания всех функций интерфейса.

Здравствуйте Mishka<T>, Вы писали:

MT>Здравствуйте VladD2,

VD>>Нодо добавить прагму:
VD>>#pragma trust me... knowing i'm do...

MT>#pragma Take that fucking compiler away from my clumsy hands

Предлагаю добавить оба варианта.

Здравствуйте IVaNС, Вы писали:

IVNС>Ну да, постраничное выделение никто не отменял.Но вот перемещение блоков вовсе не всегда происходит. Смысл тусовать память, если не изменился адрес ?

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


VD>>Да нафиг там не нужно знать ничего просто новое занчение нужно получать умножениме старого на два. 100 лет назад проверенный метод... Но это так к слову.

IVNС>Да не, на 2 не всегда хорошо умножать. Зависит от характера использования массива. Если, конечно, хочешь_экономить память. Проверенно практикой — для экономии памяти лучше добавлять блоками динамического размера.

Это тоже самое, что слова о том, что QuickSort не всегда самый эффективный алгоритм сортировки. Да. Так и есть, но на практике другие варианты встречаются не часто. Реально лучше только чистый радикс, но он ограничен максимальным значением чисел. Короче, время на поиска более оптимального выбора лучше использовать на что-нибудь более полезное. И вообще 2-а в компьютерах обычно счастливое число. Но это уже демагогия.

VD>>Шринк массивам вооще делать не нужно. Проще полностью очистить и заполнить по новой.

IVNС>Да нет, не проще. Сначала накапливаю данные в один массив, другой, на основании этх делаю третий, и т.д. Этот подход неэффективен по производительности, но очень удобен. Добавление производится в конец. Так что, даже обычный эррэйлист не сильно тормозит, все-таки, там реализовано предварительное выделение.

Память дешевеет и ее становится больше. Процессорное же время всегда в цене. Так что...

IVNС>Блин, ну и реализация у этого ArrayList ...
IVNС>System.Array работает с использованием класса COMArrayInfo, написанного на с++.

Как я понимаю COMArrayInfo там для совместмости с SAFEARRAY. Первые версии .Net были полностью основаны на COM-а, но дальше они пошли в сторону Явы. ArrayList это вообще клон Явовского класса.

Поскольку ArrayList использует System.Array, разумно было бы предположить, что ресайз они реализовали именно в COMArrayInfo. Но ни хрена ! Они при каждой вставке тупо вызывают Array.Copy ...

А как ты себе предполагал эту операцию? Там же неприрывный участок памяти. Хвос нужно сдвинуть... Мы делали такой же класс на С++. И вставк ничем не отличалась от этой. Только массив был типизированным (на шаблонах).

IVNС>Ну, M$, 5 баллов. Список с кэшированием элементов, блин

ArrayList — означает, что это реализация метафоры List с помощью массива (Array). Подразумевается, что если самой частой операцией будет вставка в середину списка, то нужно использовать LinkedList. Который просто забыли реализовать. По этому поводу уже возмущался AVK. MS я понимаю. LinkedList хотя и позволяет быстро вставлять и удалять элементы из середины списка, но проигрывает во всех остальных случаях (и занчительно). На коротких списках (коих большинство) назница в скорости копирования и перепихивания в LinkedList-е нивелируется. Ну, и к тому же MS делала первую версию. ArrayList в Яве тоже не сразу появился. Сначала был кривой vector.

IVNС>Какого они это чудо вообще списком назвали- непонятно. ((

Вообще-то список это абстракция. И массив это наиболее полная реализация списка, ну, не всегда самая эффективная.

IVNС>Как-нить портирую свой ATL-овский динамический массив и список на .НЕТ. Это будет правильно.

Без шаблонов (или хотя-бы инклюдов) это будет безполезно. Нужно будет создавать новый тип массива для каждого типа данных.

Здравствуйте IVaNС, Вы писали:

IVNС>Дык уже есть. А доку можно сгенерить по комментам ///
IVNС>Вообще, этот враппер удобства добавляет, так что смысл, есть, наверное.
IVNС>А вообще, лучше бы просто изменить стандартный DateTime, и пользоваться им. Если бы микрософт еще бы слушал, что ему говорят !

Если можно, что-то не делать, то нужно это не делать.

Здравствуйте AndrewVK, Вы писали:

AVK>Не, просто на работе так достают что не до шуток. Надоело блин хуже горькой редьки. Пора новую работу искать.

А сколько денег хочешь? И может проблема, в том что ты весь день в форумах точишь?

Здравствуйте AndrewVK, Вы писали:

AVK>Кстати, еще один прикол. Прямые проходы в свитче запретили, но необходимость брека осталась. Шли бды уж до конца и делали как в паскале, без всяких брейков.

Так они же обеспечили безболезненную компиляцию "грамотного" С/С++-ного кода. И привычек меныть не надо. В бетах запрещалиь даже:

case 1:
case 2:
...
break;

VD>>Дык я не с этим не сопрю. Но протектед по дефолту логичнее. Да и времени много на написание модификатора не нужно.

AVK>Вся проблема в том что язык должен быть универсален. А в каждой конкретной задаче модификатор по умолчанию может быть разным.

Тогда вообще запретить.

AVK>Несмотря на твои заверения, я пока пути существенно улучшить GC не теряя универсальности и гарантированности удаления не вижу.

А вот уменя етсь идейка. Вместо GC использовть пулл (стью скоро выложу) а паорат рефлекшена будет заниматься переодическим укампакчиванием (с изменениме ссылок как в GC) При этом пул будет давть зверскую производительность и уменьшать надобность в Коллектах. Наметки получаются очень заманчивые. Только жаль в С++ тайп-инфо никуда не годится. А то я бы и на С++ прототипчик сворганил. Если будем курочить .Net попробую махнуть GC на эту идею.

AVK>Да нет, я не так умно думал. Начинающих программеров сильно раздражает необходимость описания всех функций интерфейса.

Дык в VS это делается влет, а по умолчанию можно и исключение кидатью.

Здравствуйте VladD2, Вы писали:

AVK>>Не, просто на работе так достают что не до шуток. Надоело блин хуже горькой редьки. Пора новую работу искать.

VD>А сколько денег хочешь? И может проблема, в том что ты весь день в форумах точишь?

Бери его к себе и сделай это занятие для его главной служебной обязанностью

Здравствуйте VladD2, Вы писали:

VD>А как ты на том же месте болше памяти выделишь? Только если до этого зарезирвируешь больше.
Если за блоком памяти, который надо ресайзить, идет свободный блок, от последнего откусывается нужный кусок и присоединяется к ресайзируемому. Иначе — создание нового блока, копирование, освобождение старого.
Токо не пинай меня за то, что говорю общеизвестные вещи :)

VD>Память дешевеет и ее становится больше. Процессорное же время всегда в цене. Так что...
Я тоже купил 512 памяти, когда 128 стоили 10 баков. Но винда свопит, даже если памяти достаточно. И это абсолютно правильно.

И вот когда твоя серьезная, большая прога начнет свопеть во всю глотку, а при таком подходе — обязательно начнет, тогда ты ощутишь что винты пока что немного медленнее оперативки :) На определение оптимального размера блока не нужно много процессорного времени, а делать это в некоторых случаях стоит.

IVNС>>Блин, ну и реализация у этого ArrayList ...

VD>Поскольку ArrayList использует System.Array, разумно было бы предположить, что ресайз они реализовали именно в COMArrayInfo.

VD>А как ты себе предполагал эту операцию? Там же неприрывный участок памяти. Хвос нужно сдвинуть...

Я вообще предполагал, что микрософт реализовал классический список с кэшированием адресов элементов в массиве (только этот массив и надо ресайзить), сами элементы хранятся где угодно, и никакого хвоста нет. Как раз тот LinkedList, которого нет :)

VD>Мы делали такой же класс на С++. И вставк ничем не отличалась от этой. Только массив был типизированным (на шаблонах).
Да, ничем.

VD>Вообще-то список это абстракция. И массив это наиболее полная реализация списка, ну, не всегда самая эффективная.

Вообще-то, ты немного путаешь термины. Классический список — цепочка элементов, хранящихся непоследовательно, и имеющих указатели на следующий (а, возможно, и предыдущий) элементы. Это уже потом стали использовать кэширование адресов элементов, чтоб всю цепочку не просматривать.
Такой список просто необходим при частом удалении и сортировке, которая получается намного быстрее, чем для массива — переставляются же только адреса, а не сами элементы.

IVNС>>Как-нить портирую свой ATL-овский динамический массив и список на .НЕТ. Это будет правильно.

VD>Без шаблонов (или хотя-бы инклюдов) это будет безполезно. Нужно будет создавать новый тип массива для каждого типа данных.

Так я же и сказал "Как-нить" :)

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

Либо отправить письмецо в проект "моно". Чтоб они реализовали. Пацаны вроде серьезные. Все-таки, они пишут компилер на шарпе, ИМХО в шарповых исходниках поприятнее копаться.

Здравствуйте VladD2, Вы писали:

VD>Здравствуйте IVaNС, Вы писали:

IVNС>>Дык уже есть. А доку можно сгенерить по комментам ///
IVNС>>Вообще, этот враппер удобства добавляет, так что смысл, есть, наверное.
IVNС>>А вообще, лучше бы просто изменить стандартный DateTime, и пользоваться им. Если бы микрософт еще бы слушал, что ему говорят !

VD>Если можно, что-то не делать, то нужно это не делать. ;)
Да ладно, чего там, не буду пока :)

Здравствуйте VladD2, Вы писали:

AVK>>Не, просто на работе так достают что не до шуток. Надоело блин хуже горькой редьки. Пора новую работу искать.

VD>А сколько денег хочешь?

Много !!!
А если серьезно то > 800

VD> И может проблема, в том что ты весь день в форумах точишь?
Это я весь день торчу? Я вот только за комп первый раз присел. Просто административная работа не предполагает особого за ним сидения. Поэтому я специально программингом занимаюсь чтобы квалификацию не потерять, ибо работать начальником мне не интересно. Как между двух огней. С одной стороны начальство, с другой подчитненные и все чего то хотят .
А форум нужен потому что в Коломне на проф. темы мне пообщаться просто не с кем.

Здравствуйте VladD2, Вы писали:

VD>Здравствуйте AndrewVK, Вы писали:

VD>Так они же обеспечили безболезненную компиляцию "грамотного" С/С++-ного кода. И привычек меныть не надо. В бетах запрещалиь даже:
VD>

VD>case 1:
VD>case 2:
VD>...
VD>break;
VD>

А сейчас разве разрешено?

AVK>>Вся проблема в том что язык должен быть универсален. А в каждой конкретной задаче модификатор по умолчанию может быть разным.

VD>Тогда вообще запретить.
Чего запретить? Модификатор по умолчанию? Может быть.

VD>А вот уменя етсь идейка. Вместо GC использовть пулл (стью скоро выложу) а паорат рефлекшена будет заниматься переодическим укампакчиванием (с изменениме ссылок как в GC) При этом пул будет давть зверскую производительность и уменьшать надобность в Коллектах. Наметки получаются очень заманчивые. Только жаль в С++ тайп-инфо никуда не годится. А то я бы и на С++ прототипчик сворганил. Если будем курочить .Net попробую махнуть GC на эту идею.
Выкладывай, посмотрим. Может чего подскажу.

AVK>>Да нет, я не так умно думал. Начинающих программеров сильно раздражает необходимость описания всех функций интерфейса.
VD>Дык в VS это делается влет, а по умолчанию можно и исключение кидатью.
Так может тогда проще мастера для VS написать который бы принудительно везде нужный модификатор расставлял бы?

Здравствуйте IVaNС, Вы писали:

IVNС>Здравствуйте VladD2, Вы писали:

VD>>А как ты на том же месте болше памяти выделишь? Только если до этого зарезирвируешь больше.
IVNС>Если за блоком памяти, который надо ресайзить, идет свободный блок, от последнего откусывается нужный кусок и присоединяется к ресайзируемому. Иначе — создание нового блока, копирование, освобождение старого.
IVNС>Токо не пинай меня за то, что говорю общеизвестные вещи :)

Вот так именно разные malloc-и и делают. Производиетльность при этом ни к черту, а вероятность тго что за твоим попадется блок нужного размера уменьшается с каждым тактом программы (и обычно колеблется в рамках 10-2 процентов). В конечном итоге для блоков до пары сотен байт зачастую проще скопировать память, а для больше 4 кил вообще занимать с избытком. К тому, же операторы new/delet вообще не рпедусатривают подобные фени.

IVNС>И вот когда твоя серьезная, большая прога начнет свопеть во всю глотку, а при таком подходе — обязательно начнет

Домыслы. Реально всегда есть некий уровнь которого хватает, чтобы не сидеть на винте. На сегодня гиг памяти — это совершенно реальная вещь. 90% програм таких объемов не требут.

IVNС>, тогда ты ощутишь что винты пока что немного медленнее оперативки :) На определение оптимального размера блока не нужно много процессорного времени, а делать это в некоторых случаях стоит.

Ошибаешься. На поиски свободных блогов и то уходит море времени, а уж на определение оптимума... Конечно, иногда случается, что человек заранее его знает. В этом случае спору нет. А в остальных умножение на 2 дает (в среднем) наиболее оптимальный результат. Причем всегда известно, что памяти в среднем нужно на четверть больше чем при оптимальном распределении (в крайнем, не реальном, случае в двое). А скорость работы программы резко увеличивается (в десятки, а то и сотни раз), по сравнению с линейным приращением.

IVNС>Я вообще предполагал, что микрософт реализовал классический список с кэшированием адресов элементов в массиве (только этот массив и надо ресайзить)

Ну, так оно и есть, так как object — это всегда ссылка, но массив от этого массивом быть не перестает!

IVNС>, сами элементы хранятся где угодно, и никакого хвоста нет. Как раз тот LinkedList, которого нет :)

Если есть массив, то есть и хвост. LinkedList это чистой води связанный список у которого доступ по индексу достигается перебором.

IVNС>Вообще-то, ты немного путаешь термины. Классический список — цепочка элементов,

Пока верно.

IVNС>хранящихся непоследовательно, и имеющих указатели на следующий (а, возможно, и предыдущий) элементы.

А вот это детали реализации. Которых может и не быть. Массив это тоже список.

IVNС>Это уже потом стали использовать кэширование адресов элементов, чтоб всю цепочку не просматривать.

Ты разных Кнутов читал? Гсподи о чем это я? Какие кнуты? Общепринятое определение списка:
Письменный перечень кого-чего-нибудь. Аричем нигде не говорится что список связанный. Вот это что не список:
* Элемент один
* Элемент пять
* Элемент три
:???:

IVNС>Такой список просто необходим при частом удалении и сортировке, которая получается намного быстрее, чем для массива — переставляются же только адреса, а не сами элементы.

Во первых для общего списка понятие середина не применимо. Когда речь идет о середине, то речь идет о подвиде списков — упорядоченном списке. Если вставка удаление в середину упорядоченного списка является наиболее частой операцией, то несомненно подвид упорядоченного списка LinkedList является оптимальным выбором. Но в реальных программах обычно к списку чаще побращаются на чтение и связанный список становится не эффективным. По этому чаще используются массивы (пусть даже с переменной длинной). Но конечно LinkedList-а это не отменяет. Если бы ты до этого читал книги по той же Яве (1.2 и выше), то для тебя такое название не было бы странным. Sun драл название у классических писателей про алгоритмы, а MS у сана, ну, и за одно у тех же классиков. :)

IVNС>Причем итоги лучше определить голосованием. после этого можно будет что-то начинать делать.

А какие итоги? То что MS не додумался создать реализацию LinkedList, а ты путаешь LinkedList и ArrayList? Или что список не равно связанный список?

Первое прискорбно но известно. Еще AKV возмущался по этому поводу. Причем возмущался неделю, а написал свой вариант минут за пятнадцать. :)

Второе? Ну, наверно по этому поводу нужно писать статьи, раз из книг не ясно.

Ну, а последнее можно выяснить в любом толковом словаре.

IVNС>Либо отправить письмецо в проект "моно". Чтоб они реализовали. Пацаны вроде серьезные. Все-таки, они пишут компилер на шарпе, ИМХО в шарповых исходниках поприятнее копаться.

Безтолку. После выхода CLI в моно нет никакого смысла. Они и на 1% не наработали относительно CLI.

Ну, а линкед лист пищется за пол часа.

class LinkedList

{
  LinkedListElem m_root;
  AddAt(LinkedListElem prev, LinkedListElem ins)
  {
    LinkedList cur = m_root;
    while(cur != null)
    {
      if(cur = prev)
      {
        ins.m_next = cur.m_next;
        cur.m_next = ins;
      }
      cur = cur.m_next;
    }
  }
}

class LinkedListElem
{
  LinkedList m_next;
}

ну, и так далее...

Обидно конечно, что MS такой простой вещи не сделала, но не смертельно.

Все равно в большинстве случаев связанные списки замечательно заменяются хэшами или массивами.

Здравствуйте AndrewVK, Вы писали:

AVK>А форум нужен потому что в Коломне на проф. темы мне пообщаться просто не с кем.

Да... живешь ты далековато... И вредничаешь больше меня. А то можно было бы тебя взять к нам. Нам такие боевые нужны.

Здравствуйте AndrewVK, Вы писали:

VD>>В бетах запрещалиь даже:
VD>>

VD>>case 1:
VD>>case 2:
VD>>...
VD>>break;
VD>>

AVK>А сейчас разве разрешено?

Да. Я сам по началу начал лепить горбатого с goto case, но потом понял, что запрещается только:

case 1:
...
case 2:

VD>>Тогда вообще запретить.
AVK>Чего запретить? Модификатор по умолчанию? Может быть.

Да. В смысле отменить к чертям умолчание в этом вопросе. Отменили же перетекание(publuc:)?

VD>>А вот уменя етсь идейка. Вместо GC использовть пулл (стью скоро выложу) а паорат рефлекшена будет заниматься переодическим укампакчиванием (с изменениме ссылок как в GC) При этом пул будет давть зверскую производительность и уменьшать надобность в Коллектах. Наметки получаются очень заманчивые. Только жаль в С++ тайп-инфо никуда не годится. А то я бы и на С++ прототипчик сворганил. Если будем курочить .Net попробую махнуть GC на эту идею.
AVK>Выкладывай, посмотрим. Может чего подскажу.

Смотри в таск-листе (или напрямую http://www.rsdn.ru/article/preview/vlad/QuickHeap.zip).

AVK>Так может тогда проще мастера для VS написать который бы принудительно везде нужный модификатор расставлял бы?

Лучше было бы C# поправить.

Здравствуйте VladD2, Вы писали:

VD>Здравствуйте AndrewVK, Вы писали:

AVK>>А форум нужен потому что в Коломне на проф. темы мне пообщаться просто не с кем.

VD>Да... живешь ты далековато...
Ну на самом деле не так уж и далеко, полтора часа до Москвы. В любом случае буду в Москву перебираться. Здесь ловить уже нечего.

VD> И вредничаешь больше меня.
А как же

VD> А то можно было бы тебя взять к нам. Нам такие боевые нужны.
А чем вы занимаетесь?

Здравствуйте VladD2, Вы писали:

VD>А вот это детали реализации. Которых может и не быть. Массив это тоже список.
Ладно, проехали.

VD>Если бы ты до этого читал книги по той же Яве (1.2 и выше), то для тебя такое название не было бы странным. Sun драл название у классических писателей про алгоритмы, а MS у сана, ну, и за одно у тех же классиков. :)

Да ну ее нафиг, эту яву. Ошибка природы. Ясное дело, не читал :)

IVNС>>Причем итоги лучше определить голосованием. после этого можно будет что-то начинать делать.

VD>А какие итоги? То что MS не додумался создать реализацию LinkedList, а ты путаешь LinkedList и ArrayList? Или что список не равно связанный список?

Какое непонимание, господа ! :(
(с) Помещик Федяшин (насколько я помню), х/ф "Формула любви"

НЕЕЕЕЕЕ !!! Я говорил вовсе не про список, это вообще отвлеченная тема ! Про компилятор ! Про _тему_топика_ ! Прикручивание тэмплэйтов, наследования, отмена ключевых слов и тд ! Хотя, у меня сложилось впечатление, что никого это уже не интересует :(

VD>Второе? Ну, наверно по этому поводу нужно писать статьи, раз из книг не ясно.
Да у меня вообще проблем нет в этом плане :) Я просто связанный список всегда называл списком, а массив — массивом, только и всего. Так логичнее. Опять же, это не принципиально :)
Статей не надо :) И без них уже все отлично написано и работает

IVNС>>Либо отправить письмецо в проект "моно". Чтоб они реализовали. Пацаны вроде серьезные. Все-таки, они пишут компилер на шарпе, ИМХО в шарповых исходниках поприятнее копаться.
VD>Безтолку. После выхода CLI в моно нет никакого смысла. Они и на 1% не наработали относительно CLI.

Да, ты прав. Да и пока их компилер не все компиляет.

Здравствуйте VladD2,

VD>Да... живешь ты далековато... И вредничаешь больше меня. А то можно было бы тебя взять к нам. Нам такие боевые нужны.

И меня, меня возьми — я тоже вредничать умею