Отсутствие множ. наследования и тэмплэйтов на CS - Философия программирования

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

IT>C#'вский копилятор лежит в исходниках ротора в полной красе. Там же JScript. Шаблоны к C# может и можно прикрутить, трудно сказать, но вот множественное наследование вряд ли. Его должен поддерживать CLR.

Темплэйты однозначно можно привинтить, с множественным наследованием могут возникнуть некоторые трудности, но:
я скачал книгу микрософта "Inside MS .Net IL Assembler" (ссыла у меня где-то осталась)
Там написано так:
"The common language runtime object model supports only single type inheritance, and multiple inheritance is simulated through implementation of multiple interfaces"
Надо копать детально, но навскидку вроде мона сказать, что реализация возможна.

Теперь нам нужно:
1)создать проект под контролем версий, исходники уже есть :)))
2)набрать команду
3)создать и утвердить новый стандарт языка C##, отличия от C#.
4)собрать все идеи людей по этому поводу, чтобы новый язык получился максимально совместимым с тем, что может выдать микрософт в обозримом светлом будущем, и тогда переход на их компилер будет примерно таким, как со студии .нет бэта1 --- релиз :)
Мне пока вот что нужно
а)темплейты
б)множ. насленование
в)методы с дефолтными параметрами
г)хочу, чтоб можно было отменять действия модификаторов типа sealed. Блин, как мне эта гадость несколько раз помешала ! Это вот надо сделать типа как в visual c++ c mutable :)
д)деструкторы поумнее (это нужно детально ___обсудить___ !!!!)
е)аспекты (как и Mishka)

____Ваши предложения____, господа !!!!

5)собрать всю литературу (у меня уже кой-какая подборочка есть !, по МСИЛ тоже )

И вперед — :user: :user: :user: :user: :user:

IT>К тому же надо помнить о том, что всё что пишется на одном языке должно быть запросто доступно в других.

:???:

Здравствуйте IVaNС,

IVNС>Темплэйты однозначно можно привинтить, с множественным наследованием могут возникнуть некоторые трудности, но:
IVNС>я скачал книгу микрософта "Inside MS .Net IL Assembler" (ссыла у меня где-то осталась)

Если не жалко скинь книжку (или ссылку) мне на mchashchin@imsmaxims.com. Буду очень признателен.

Видимо у народа куча свободного времени и нечем заняться. В NET есть масса мест, куда можно приложить руки с большей пользой для ума и кошелька. Особенно это касается WinForms. Хотя бы самую малость того, что есть под Дельфи сделать в NET.
А по поводу компилятор смастерить, есть старая рекомендация "Программисту следует воздержаться от написания своих операционных систем и компиляторов". На SourceForge масса проектов, уже не первй год пребывающих в стадии PreAlpha/Planning.

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

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

IVNС> г)хочу, чтоб можно было отменять действия модификаторов типа sealed. Блин, как мне эта гадость несколько раз помешала ! Это вот надо сделать типа как в visual c++ c mutable :)
Тут ты ничего не сделаешь — это уже не язык а CLR. А переписывать CLR бессмысленно. Да и ввели sealed не от хорошей жизни. Пометка таким модификатором здорово убыстряет работу таких объектов.

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

SKO>Видимо у народа куча свободного времени и нечем заняться. В NET есть масса мест, куда можно приложить руки с большей пользой для ума и кошелька. Особенно это касается WinForms. Хотя бы самую малость того, что есть под Дельфи сделать в NET.
SKO>А по поводу компилятор смастерить, есть старая рекомендация "Программисту следует воздержаться от написания своих операционных систем и компиляторов". На SourceForge масса проектов, уже не первй год пребывающих в стадии PreAlpha/Planning.

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

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

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

IVNС>>Темплэйты однозначно можно привинтить, с множественным наследованием могут возникнуть некоторые трудности, но:
IVNС>>я скачал книгу микрософта "Inside MS .Net IL Assembler" (ссыла у меня где-то осталась)

MT>Если не жалко скинь книжку (или ссылку) мне на mchashchin@imsmaxims.com. Буду очень признателен.

Ссылу надо искать :( Подожди немного, если не найду ссылу (я ее подсмотрел на www.soft-forum.ru), кину книгу на мыло (1.5м)

Здравствуйте Аноним, Вы писали:

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

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

IVNС>> г)хочу, чтоб можно было отменять действия модификаторов типа sealed. Блин, как мне эта гадость несколько раз помешала ! Это вот надо сделать типа как в visual c++ c mutable :)
А>Тут ты ничего не сделаешь — это уже не язык а CLR. А переписывать CLR бессмысленно. Да и ввели sealed не от хорошей жизни. Пометка таким модификатором здорово убыстряет работу таких объектов.

Что убыстряет — это точно, а вот как-нить поборороть sealed — хотелось бы

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

MT>Если не жалко скинь книжку (или ссылку) мне на mchashchin@imsmaxims.com. Буду очень признателен.

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

Ожидаю начала проекта и готов участвовать.

Здравствуйте Аноним,

А>Ссылу надо искать

Подожди немного, если не найду ссылу (я ее подсмотрел на www.soft-forum.ru), кину книгу на мыло (1.5м)

Коллеги, поделитесь сабжем плз.

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

ND>Здравствуйте Аноним,

А>>Ссылу надо искать :( Подожди немного, если не найду ссылу (я ее подсмотрел на www.soft-forum.ru), кину книгу на мыло (1.5м)

ND>Коллеги, поделитесь сабжем плз.

Хорошо, и тебе вышлю

Здравствуйте Аноним, Вы писали:

А>Мона, в принципе, было бы написать с нуля шарповый компилер, но это сильно громоздкая задача, никто, скорее всего, не возьмется

Так исходники Шарпового компилятора уже почти месяц как валяются на сайте MS (http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/msdn-files/027/001/901/msdncompositedoc.xml). Так, что остается только дописать деструкторы, шаблоны, агрегацию и все остальное...

Кстати, MS-ресерчь во времена бэты 2 даже вроде создали вариант C#-компиялтора поддерживающего шаблоны (сам не видел).

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

MT>У меня есть идеи и некие наработки в области аспектно-ориентированного программирования. Так что было бы не плохо и аспектную ориентацию туда прикрутить. Получиться что-то вроде Aspect C# (по аналогии с Aspect Java). Если есть желание я могу Влада и IT попинать насчёт открытия проекта.

Места на сайте достаточно. Главное, чтобы люди заинтерисованные нашлись.

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

IT>...но вот множественное наследование вряд ли. Его должен поддерживать CLR. К тому же надо помнить о том, что всё что пишется на одном языке должно быть запросто доступно в других.

Так множественное наследование на фиг не сдалось. Его можно с успехом заменить агрегацией. Преставь пишешь код вроде этого:

class MyClass : SomeBaseCalss, ISomeInterface1, ISomeInterface2
{
   [ImplementInterface]
   ISomeInterface1 Itf1 = new ISomeInterface1Impl();

   [ImplementInterface]
   ISomeInterface1 Itf2;

   SomeBaseCalss(bool bCondition)
   {
      if(bCondition)
         Itf2 = new ISomeInterface1ImplVer1();
      else
         Itf2 = new ISomeInterface1ImplVer2();
   }
}

Ну, а компилятор делает легкий перемап vtbl. Главное решить проблему с приведением this.

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

IVNС>5)собрать всю литературу (у меня уже кой-какая подборочка есть !, по МСИЛ тоже )

А не хочешь обнародовать информацию по MSIL. В виде статейки конечно... Думаю, народу было бы интересно.

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

IVNС>Что убыстряет — это точно, а вот как-нить поборороть sealed — хотелось бы

А вот я думаю, что в большинстве случаев sealed ускорения не даст. Ну, а побороть можно все что хочешь если есть исходники.

Дизасемблер для MSIL уже сделали. Пока, что кривенький, но работает.

Здравствуйте Аноним, Вы писали:

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

На одном из PDC раздавали CD с неофициальной версией C# поддерживающей шаблоны. Так, что... Просто MS по соображениям времени не мог сделать протестированного варианта. В том проекте ведь подразумевалось изменить MSIL. К тму же при этом пришлось бы переписывать все базовые библиотеки. Иначе полезность шаблонов сильно уменьшится. Ведь производительность сильно страдает от универсальных контейнерных классов основанных на object.

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

VD>Так исходники Шарпового компилятора уже почти месяц как валяются на сайте MS (http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/msdn-files/027/001/901/msdncompositedoc.xml). Так, что остается только дописать деструкторы, шаблоны, агрегацию и все остальное... :)

VD>Кстати, MS-ресерчь во времена бэты 2 даже вроде создали вариант C#-компиялтора поддерживающего шаблоны (сам не видел).

Да, это и есть "ротор". Я уже скачал и даже скомпилял :) Исходники, из-за того, что выполнены в кроссплатформенном виде, выглядят несколько некрасиво, но другого у нас нет, так что и это сгодится.

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

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

IVNС>>5)собрать всю литературу (у меня уже кой-какая подборочка есть !, по МСИЛ тоже )

VD>А не хочешь обнародовать информацию по MSIL. В виде статейки конечно... Думаю, народу было бы интересно.

Пока обещать ничего не буду, ладно ? Надо бы довести до ума C## :)
А вот книгу по МСИЛ могу куда-нить на ваш сайт закинуть, чтоб все могли скачать

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

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

IVNС>>Что убыстряет — это точно, а вот как-нить поборороть sealed — хотелось бы

VD>А вот я думаю, что в большинстве случаев sealed ускорения не даст. Ну, а побороть можно все что хочешь если есть исходники. :) Дизасемблер для MSIL уже сделали. Пока, что кривенький, но работает.

Угу :) Хотя, это просто так не получится :(

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

VD>Здравствуйте Аноним, Вы писали:

VD>На одном из PDC раздавали CD с неофициальной версией C# поддерживающей шаблоны. Так, что... Просто MS по соображениям времени не мог сделать протестированного варианта.

Интересно, получит ли это дальнейшее развитие ?

VD>В том проекте ведь подразумевалось изменить MSIL.
К тму же при этом пришлось бы переписывать все базовые библиотеки. Иначе полезность шаблонов сильно уменьшится. Ведь производительность сильно страдает от универсальных контейнерных классов основанных на object.

Я думаю, базовые библиотеки нужно попереписывать. Например, DateTime. Он НЕФУНКЦИОНАЛЕН. Мне пришлось написать для него враппер для выполнения примитивных операций типа изменения дня/месяца/года, перехода на след. месяц и т.д.

Или вот обычные массивы. Чтобы добавить/удалить элементик, приходится использовать нетипизированный и тормозной ArrayList, а потом конвертить его обратно в System.Array. Куда это годится ? Почему они забыли про обычный realloc() ?
И таких неприятных мелочей много.

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

VD>Так множественное наследование на фиг не сдалось. Его можно с успехом заменить агрегацией. Преставь пишешь код вроде этого:

VD>

VD>class MyClass : SomeBaseCalss, ISomeInterface1, ISomeInterface2
VD>{
VD>   [ImplementInterface]
VD>   ISomeInterface1 Itf1 = new ISomeInterface1Impl();

VD>   [ImplementInterface]
VD>   ISomeInterface1 Itf2;

VD>   SomeBaseCalss(bool bCondition)
VD>   {
VD>      if(bCondition)
VD>         Itf2 = new ISomeInterface1ImplVer1();
VD>      else
VD>         Itf2 = new ISomeInterface1ImplVer2();
VD>   }
VD>}
VD>

VD>Ну, а компилятор делает легкий перемап vtbl. Главное решить проблему с приведением this.

Влад, кое-что непонятно. Что это за атрибут ImplementInterface, который говорит компилеру делать перемап vtbl ?

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

Здравствуйте Аноним, Вы писали:

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

VD>>Так множественное наследование на фиг не сдалось. Его можно с успехом заменить агрегацией. Преставь пишешь код вроде этого:

VD>>

VD>>class MyClass : SomeBaseCalss, ISomeInterface1, ISomeInterface2
VD>>{
VD>>   [ImplementInterface]
VD>>   ISomeInterface1 Itf1 = new ISomeInterface1Impl();

VD>>   [ImplementInterface]
VD>>   ISomeInterface1 Itf2;

VD>>   SomeBaseCalss(bool bCondition)
VD>>   {
VD>>      if(bCondition)
VD>>         Itf2 = new ISomeInterface1ImplVer1();
VD>>      else
VD>>         Itf2 = new ISomeInterface1ImplVer2();
VD>>   }
VD>>}
VD>>

VD>>Ну, а компилятор делает легкий перемап vtbl. Главное решить проблему с приведением this.

А>Влад, кое-что непонятно. Что это за атрибут ImplementInterface, который говорит компилеру делать перемап vtbl ?

ImplementInterface- это у него мечты о светлом будущем.
Динамическое присобачивание имплементации это конечно полезная штука, только как бы не появились подводные камни. При изменении таких вещей где все тесно повязано (как в языках программирования), всплывают всякие связанные проблемы в неожиданных местах.
Если от такого хитрого класса унаследоваться и переопределять виртуальные функции в имплементации интерфейса,которая еще не известна во время компиляции (неизвестно даже виртуальные там методы или нет), здесь прийдется попыхтеть чтобы реализовать без глюков. Кроме того не ясно как быть с keyword override, т.к. функция может быть виртуальной, а может и не быть.

Раз уж все загадывают желания, что бы им хотелось в новом языке, тоже выскажусь.
Хотелось бы чтобы появилось динамическое связывание.
Хотя в CLR оно есть а в C# его нет.

Чтобы в C# динамически подключиться к assembly нужно шаманить в таком направлении

Assembly a=Assembly.LoadFrom(assemblyPathName);
Type type=a.GetTypes()[0];
MethodInfo methodInf=type.GetMethod(codeName);
object[] params=...
...//проверяем соответствие типов в params и в methodInf
methodInf.Invoke(null,params);

А хотелось бы что то наподобии:

Type type= ...GetTypes....
runtime_type obj=runtime_type.CreateInstance(type); //в конструктор бы еще параметры передавать
obj.Method(param);

Можно было бы сделать такой тип runtime_type из которого можно вызывать любые методы с любыми параметрами, а проверки типов и существования методов только во время runtime. Другими словами вариант с Invoke но гораздо меньше мусора в коде. И существовал бы такой тип вместе с остальными и никому бы не мешал (ни чего бы переделывать бы не пришлось).

В .NET Васике есть же такое динамическое связывание, почему бы в C# не сделать, как альтернативу остальным тимам.

Может это не так часто и нужно, но я уже столкнулся с такой задачей в которой это необходимо.

VD>>>Ну, а компилятор делает легкий перемап vtbl. Главное решить проблему с приведением this.

SS>ImplementInterface- это у него мечты о светлом будущем.

Чтобы компилятор делал перемап, надо его изменить :) А если менять, так уже лучше добавить множ. наследование

SS> Динамическое присобачивание имплементации это конечно полезная штука, только как бы не появились подводные камни. При изменении таких вещей где все тесно повязано (как в языках программирования), всплывают всякие связанные проблемы в неожиданных местах.
SS> Если от такого хитрого класса унаследоваться и переопределять виртуальные функции в имплементации интерфейса,которая еще не известна во время компиляции (неизвестно даже виртуальные там методы или нет), здесь прийдется попыхтеть чтобы реализовать без глюков. Кроме того не ясно как быть с keyword override, т.к. функция может быть виртуальной, а может и не быть.

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

SS> Раз уж все загадывают желания, что бы им хотелось в новом языке, тоже выскажусь.
SS>Хотелось бы чтобы появилось динамическое связывание.
SS>Хотя в CLR оно есть а в C# его нет.

SS>Чтобы в C# динамически подключиться к assembly нужно шаманить в таком направлении

SS>

SS>Assembly a=Assembly.LoadFrom(assemblyPathName);
SS>Type type=a.GetTypes()[0];
SS>MethodInfo methodInf=type.GetMethod(codeName);
SS>object[] params=...
SS>...//проверяем соответствие типов в params и в methodInf
SS>methodInf.Invoke(null,params);
SS>

SS>А хотелось бы что то наподобии:

SS>

SS>Type type= ...GetTypes....
SS>runtime_type obj=runtime_type.CreateInstance(type); //в конструктор бы еще параметры передавать

Можно создать экземпляр объекта с вызовом конструктора с помощью Activator.CreateInstance(Type _Type, object[] param)
param - параметры конструктора (выбирается подходящий)

SS>obj.Method(param);
SS>

Так не получится — не скомпиляется. Но вот типа такого — реально:
obj.Methods["Method"](param);

SS>Можно было бы сделать такой тип runtime_type из которого можно вызывать любые методы с любыми параметрами, а проверки типов и существования методов только во время runtime. Другими словами вариант с Invoke но гораздо меньше мусора в коде. И существовал бы такой тип вместе с остальными и никому бы не мешал (ни чего бы переделывать бы не пришлось).

SS>В .NET Васике есть же такое динамическое связывание, почему бы в C# не сделать, как альтернативу остальным тимам.

SS>Может это не так часто и нужно, но я уже столкнулся с такой задачей в которой это необходимо.

Так вперед, в чем проблема ? Я уже давно примерно такое експлуатирую. Компилятор для этого не нужно менять :)
Достаточно написать класс, который расковыривает в реатайме любой тип.

Здравствуйте Аноним, Вы писали:

А>Угу

Хотя, это просто так не получится

Дык, а мы легких путей не ищем.

Здравствуйте Аноним, Вы писали:

VD>>На одном из PDC раздавали CD с неофициальной версией C# поддерживающей шаблоны. Так, что... Просто MS по соображениям времени не мог сделать протестированного варианта.

А>Интересно, получит ли это дальнейшее развитие ?

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

А>Я думаю, базовые библиотеки нужно попереписывать. Например, DateTime. Он НЕФУНКЦИОНАЛЕН. Мне пришлось написать для него враппер для выполнения примитивных операций типа изменения дня/месяца/года, перехода на след. месяц и т.д.

Ну, это ерунда... приводишь его к double, а там обычные арефметические операции. К тому же здесь речь шла бы о банальном расширении путем наследования.

А>Или вот обычные массивы. Чтобы добавить/удалить элементик, приходится использовать нетипизированный и тормозной ArrayList

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

А>, а потом конвертить его обратно в System.Array. Куда это годится ? Почему они забыли про обычный realloc() ?

Потому, что в природе не существует алгоритмов realloc-а. При realloc-е просто занимается новый массив, данные копируются, а старый освобождается. Такой realloc я и сам за пять минут сворганю. Только он будет еще более медленный чем ArrayList (при условии частого изменения размера массива).

Здравствуйте Аноним, Вы писали:

VD>>Ну, а компилятор делает легкий перемап vtbl. Главное решить проблему с приведением this.

А>Влад, кое-что непонятно. Что это за атрибут ImplementInterface, который говорит компилеру делать перемап vtbl ?

Это все мечты, которые можно было бы воплотить в жизнь.

Общий смысл такой. Этот атрибут указывает компилятору, что реализацию интерфейса присвоеную в переменную помечанную этим атрибутом (или чем угодно еще) нужно использовать для реализации интерфейса (который должен к тому же быть перечислен в списке наследования).

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

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

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

Вообще-то это реализовано. Я, напримен, пароль каждый раз не заполняю. Слышал, что такая проблема есть при использовании RSDN Desktop, но вроде он пока не доступен открыто.

Так, что общайся с IT сам.

Здравствуйте Аноним, Вы писали:

SS>>А хотелось бы что то наподобии:

SS>>

SS>>Type type= ...GetTypes....
SS>>runtime_type obj=runtime_type.CreateInstance(type); //в конструктор бы еще параметры передавать

А>Можно создать экземпляр объекта с вызовом конструктора с помощью Activator.CreateInstance(Type _Type, object[] param)
А>param - параметры конструктора (выбирается подходящий)

SS>>obj.Method(param);
SS>>

А>Так не получится — не скомпиляется.
obj.Method(param); — Я имел ввиду, если поддержку на уровне языка сделать.

А> Но вот типа такого — реально:
А>obj.Methods["Method"](param);

Да наверное можно сделать класс оболочку более менее юзабельную не меняя языка, если еще использовать передачу переменного числа параметров

А>Так вперед, в чем проблема ? Я уже давно примерно такое експлуатирую. Компилятор для этого не нужно менять

А>Достаточно написать класс, который расковыривает в реатайме любой тип.

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

Здравствуйте Аноним, Вы писали:

А>Чтобы компилятор делал перемап, надо его изменить :) А если менять, так уже лучше добавить множ. наследование

Во-первых, агрегация круче. Она в рантайме пашет. Правда, медленнее, но не на столько, чтобы обратно возвращаться к геморрою с множественным наследованием. Думаю агрегации и шаблонов будет достаточно.

К тому же, множественное наследование не поддерживается CLR-ом. И это принципиально. Им нужен единый корень. Причем на этом базируется куча системных кусков. Так, что можно ждать только сделать только эмуляцию в виде раскрутки наследования, но при этом все равно корень будет один и вся множественность будет всего лишь удобством для реализации интерфейсов. Реальное МН видимо так и останется только в С++.

А>По-моему, это тупиковый путь. во-первых, отсутствуют проверки на этапе компиляции.

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

А>Во-вторых, атрибуты придется разгребать в реалтайме и на основании этого генерить код.

Ничего в рантайме генерировать не придется. Все решается очень просто. Почти как в COM. У агрегируемого объекта подменяется функции привидения типов. В следствии чего появляется возможность приводить указатель на интерфейс реализуемый агрегируемым объектом к указателю на агрегирующий объект. Далее так же модифицируется приведение типов у агрегирующего объекта и при попытке привести его к указателю на интерфейс реализуемый внешним объектом берется указатель на него и возвращается вместо своего. Любая попытка привести (изменить) указатель на интерфейс должна проходить через агрегирующий объект. При этом все неверные приведения должны пресекаться на корню.

Задача реализуемая причем реализуемая в рамках сегодняшнего MSIL-а и CLR-а (по крайней мере мне так кажется).

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

А> Это жутко геморройно и некрасиво, а ведь наша задача — получить красивую реализацию !

Что геморройно? Что некрасиво?

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

Оооочень интересно, что ты понимаешь под "обычной агрегацией"? Ана была только в COM. Причем именно там она была геморроем еще тем. Тут же предлагается стройная идеология. Пара строчек кода и ты подключаешь готовую реализацию интерфейса. Да еще вдобавок можно делать это на лету (в рантайме).

SS>> Раз уж все загадывают желания, что бы им хотелось в новом языке, тоже выскажусь.

Вот тогда перед каждым таким вызовом нужно ставить идентификатор вроде "dinamic", а то в VB6 половину кода пишется таким образом. Но, там хоть в этом нужда есть. Ведь там это единственный простой способ сделать полиморфизм. И то лучше интерфейсами обходится, если можно.

Иначе обычная лень будет приводить к куче рантайм-ошибок. :(

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

SS>Динамическое присобачивание имплементации это конечно полезная штука, только как бы не появились подводные камни. При изменении таких вещей где все тесно повязано (как в языках программирования), всплывают всякие связанные проблемы в неожиданных местах.

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

SS>Если от такого хитрого класса унаследоваться и переопределять виртуальные функции в имплементации интерфейса, которая еще не известна во время компиляции

Так. Еще разок. Не функция, а интерфейс. Улавливаешь разницу?

SS> (неизвестно даже виртуальные там методы или нет)

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

SS>, здесь прийдется попыхтеть чтобы реализовать без глюков.

Хотел бы я видеть задачу которую можно не пыхтя без глюков реализовать.

SS> Кроме того не ясно как быть с keyword override, т.к. функция может быть виртуальной, а может и не быть.

А тут ничего не меняется. Если класс унаследован от агригирующего класса (в прочем как и от обычного), то он получит свой втбл и нужно только обеспечить, что если объект не перебивает метод, при подключении реализации чтобы или делать временный втбл копируя туда все что нужно, или придумать иную идеологи вызова методов из базового втбл-а.

Вот примерная картина втбл-ов:

Интерфейс  Агрегирующий   Агрегриуемый   Наследник
           класс          класс         
f1 = 0     -              f1             -
f2 = 0     -              f2             f2

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

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

VD>Задача реализуемая причем реализуемая в рамках сегодняшнего MSIL-а и CLR-а (по крайней мере мне так кажется).

Задача нормально реализуемая в одну сторону. В том же COM (CoCreateInstance) есть pUnkOuter — указатель на агрегирующий объект, пока непонятно куда его запихать агрегируемому объекту. Хотя можно на это забить, автоматического преобразования в одну сторону к интерфейсам членов класса было бы уже достаточно для большинства задач. Возможно будут проблемы со всякими неоднозначностями типа когда два члена класса реализуют один и тот же интерфейс, но это можно было бы регилировать параметрами атрибутов.

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

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

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

VD>А вот я думаю, что в большинстве случаев sealed ускорения не даст.

The sealed modifier is primarily used to prevent unintended derivation, 
but it also enables certain run-time optimizations. In particular, 
because a sealed class is known to never have any derived classes, 
it is possible to transform virtual function member invocations on 
sealed class instances into non-virtual invocations.

А вобще непонятно. Если дизайнер библиотеки захотел чтобы от класса нельзя было отнаследоваться — зачем это побарывать? Чтобы глюки поиметь?

Здравствуйте Аноним, Вы писали:

А>Я думаю, базовые библиотеки нужно попереписывать. Например, DateTime. Он НЕФУНКЦИОНАЛЕН. Мне пришлось написать для него враппер для выполнения примитивных операций типа изменения дня/месяца/года, перехода на след. месяц и т.д.
А как же его методы AddXXX?

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

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

Так компилятор и должен проверять такие вещи. Описал двойную реализацию, будь добр совершить пешую прогулку с эротическим уклоном.

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

IT>В данном случае можно вполне обойтись ключевым словом. Возможно, это даже лучше, т.к. ключевые слова понимаются только компилятором на этапе компиляции, а атрибуты должны восприниматься любыми языками. Т.е. в случае с атрибутами существует проблема совместимости.

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

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

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

IT>>В данном случае можно вполне обойтись ключевым словом. Возможно, это даже лучше, т.к. ключевые слова понимаются только компилятором на этапе компиляции, а атрибуты должны восприниматься любыми языками. Т.е. в случае с атрибутами существует проблема совместимости.

VD>Здесть не все так однозначно. Лучше подумать еще. Дело в том, что информация о типах все равно нужно, а так как это надстройка над CLR, то без атрибутов информация о агрегации просто исчезнет.

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

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

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

VD>>А вот я думаю, что в большинстве случаев sealed ускорения не даст.

AVK>The sealed modifier is primarily used to prevent unintended derivation, but it also enables certain run-time optimizations. In particular, because a sealed class is known to never have any derived classes, it is possible to transform virtual function member invocations on sealed class instances into non-virtual invocations.

Недадо код для цитат использовать! Текст при этом не переностится.

Ну, а по делу... Кто-нибудь эксперементировал? Я почти уверен, чно этот сэйлед ничего не даст супратив обычных методов. Возможно если объявить сэйледом виртуальную функцию, то что-нибудь и выйдет, но тоже сомнительно.

AVK>А вобще непонятно. Если дизайнер библиотеки захотел чтобы от класса нельзя было отнаследоваться — зачем это побарывать? Чтобы глюки поиметь?

А это как с виртуальными функциями и private-членами. Программист не думая делает, а потом другой вынужден вместо наследования (с целью чуть-чуть подправить функциональность) полностью переписывать весь код.

Замечательный пример реализация меню в WinForms более глупую объектную модель придумать очень не просто. Например, метод Show у ContextMenu не виртуальный. В нем ошибка (неверно заданы флаги для TrackPopupMenuEx). Да и вообще может я хочу как-то по своему меню показать или делать при это что-нибудь. Далее в класс Control жестко вшито свойство типа ContextMenu. Изменить функциональность невозможно. Суда бы еще сэйледов по напихать.

Короче, но один обдуманный случай применения saled, не virtual и private приходится 1000 необдуманных. К тому же, ничего страшного в большинстве случаев не произошло бы если поставить не saled, virtual и protected. Лучше бы качественнее документацию писали.

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

VD>>Здесть не все так однозначно. Лучше подумать еще. Дело в том, что информация о типах все равно нужно, а так как это надстройка над CLR, то без атрибутов информация о агрегации просто исчезнет.

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

А как ты себе видишь описание этого? Метоинформацию? Так по атрибутам можно будет спокайно понять, что имеет место агрегация, а ключевое слово будет выкинуто в прщессе компиляции (она же не CLR-ное).

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

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

VD>А как ты себе видишь описание этого? Метоинформацию? Так по атрибутам можно будет спокайно понять, что имеет место агрегация, а ключевое слово будет выкинуто в прщессе компиляции (она же не CLR-ное).

В случае с ключевым словом необходимо будет наделить объект каким-нибудь виртуальным методом (можно через интерфейс типа ICastable или IAggregatable), компилятор будет просто генерировать этот метод.

В случае с атрибутами это может быть один на всех метод, который будет прочёсывать все члены объекта и выполнять при необходимости кастинг.

Вот и думай что лучше? Я пока затрудняюсь сказать. Первый вариант будет явно производительнее, второй будет работать сразу для всего CLR, т.е. компиляторы править не надо будет.

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

А, кстати, нельзя ли сделать это просто перебив операторы приведения типов?

Кто-нибудь смотрел CLI на предмет того как там типы приводятся? И как там работают (физически) операторы типа is и as?

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

VD>>>А вот я думаю, что в большинстве случаев sealed ускорения не даст.

AVK>>The sealed modifier is primarily used to prevent unintended derivation, but it also enables certain run-time optimizations. In particular, because a sealed class is known to never have any derived classes, it is possible to transform virtual function member invocations on sealed class instances into non-virtual invocations.

VD>Ну, а по делу... Кто-нибудь эксперементировал? Я почти уверен, чно этот сэйлед ничего не даст супратив обычных методов. Возможно если объявить сэйледом виртуальную функцию, то что-нибудь и выйдет, но тоже сомнительно.
Я в свое время экспериментировал с джавовским final. Эффект в плане быстродействия при вызове очень существенный. Но там все функции виртуальные. В дотнете наверное проще функции сделать невиртуальными.

AVK>>А вобще непонятно. Если дизайнер библиотеки захотел чтобы от класса нельзя было отнаследоваться — зачем это побарывать? Чтобы глюки поиметь?
VD>А это как с виртуальными функциями и private-членами. Программист не думая делает, а потом другой вынужден вместо наследования (с целью чуть-чуть подправить функциональность) полностью переписывать весь код.
Ну от кривых рук защиты пока не придумали.

VD>Замечательный пример реализация меню в WinForms более глупую объектную модель придумать очень не просто.
Мне честно говоря вся объектная модель windows.forms крайне не понравилась. Она очень похожа на VCL, но это, извините, 1992 год, а на дворе уже 2002. И это на фоне вполне передовых в этом плане частей, например того же ремоутинга.

VD> Например, метод Show у ContextMenu не виртуальный. В нем ошибка (неверно заданы флаги для TrackPopupMenuEx). Да и вообще может я хочу как-то по своему меню показать или делать при это что-нибудь. Далее в класс Control жестко вшито свойство типа ContextMenu. Изменить функциональность невозможно. Суда бы еще сэйледов по напихать.

А еще ... Какого у tree view и list view они убрали owner draw? У listbox и combobox оно есть. И нифига тут не сделаешь, поскольку они виндовые.

VD>Короче, но один обдуманный случай применения saled, не virtual и private приходится 1000 необдуманных. К тому же, ничего страшного в большинстве случаев не произошло бы если поставить не saled, virtual и protected. Лучше бы качественнее документацию писали.
Вобще то прежде чем ставить sealed человек должен подумать. Вот sealed был по умолчанию, тогда да, это бага. А так — при желании такого можно наворотить.

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

AVK>Я в свое время экспериментировал с джавовским final. Эффект в плане быстродействия при вызове очень существенный. Но там все функции виртуальные. В дотнете наверное проще функции сделать невиртуальными.

Дык, это разные вещи... Понятно, что если функци не виртуальная, то и работать она будтет быстрее.

AVK>

А еще ... Какого у tree view и list view они убрали owner draw? У listbox и combobox оно есть. И нифига тут не сделаешь, поскольку они виндовые.

Думаю, эту пролему обойти можно. Именно потому что они виндовые. Вскгда можно забраться на системный уровень и сделать все как нужно.

Ну, а почему не сделали? Думаю они пакт с разработчиками компонентов (вроде Infragistoс) заключили. Те не пишут ОС, а MC делает недоделанные кривые компонетнты.

AVK>Вобще то прежде чем ставить sealed человек должен подумать. Вот sealed был по умолчанию, тогда да, это бага. А так — при желании такого можно наворотить.

К сажалению многие лепят все что подруку попадется. А приват и вовсе сделан по умолчанию. Один налпит другой уже ничего не исправит. Была бы моя воля я по умолчанию протектед поставил.

И вообще я много читал умных книжет кде пугают тем что мол если будешь все публик делать, то проблем будет много. М вон тонну COM-объектов написали в основном весь код паблик, все равно через COM-интерфейс ничего видно не будет.

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

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

AVK>>Я в свое время экспериментировал с джавовским final. Эффект в плане быстродействия при вызове очень существенный. Но там все функции виртуальные. В дотнете наверное проще функции сделать невиртуальными.
VD>Дык, это разные вещи... Понятно, что если функци не виртуальная, то и работать она будтет быстрее.
Ну так sealed как раз и делает виртуальные функции статическими.

AVK>>

А еще ... Какого у tree view и list view они убрали owner draw? У listbox и combobox оно есть. И нифига тут не сделаешь, поскольку они виндовые.

VD>Думаю, эту пролему обойти можно. Именно потому что они виндовые. Вскгда можно забраться на системный уровень и сделать все как нужно.
Не, писать нативный код это уже не то. Нехочу.

VD>Ну, а почему не сделали? Думаю они пакт с разработчиками компонентов (вроде Infragistoс) заключили. Те не пишут ОС, а MC делает недоделанные кривые компонетнты.

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

AVK>>Вобще то прежде чем ставить sealed человек должен подумать. Вот sealed был по умолчанию, тогда да, это бага. А так — при желании такого можно наворотить.
VD>К сажалению многие лепят все что подруку попадется.
А стоит ли на таких язык править?

VD>А приват и вовсе сделан по умолчанию. Один налпит другой уже ничего не исправит. Была бы моя воля я по умолчанию протектед поставил.
Приват по умолчанию правильно. А под кривые руки язык затачивать не стоит.

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

SS>>Если от такого хитрого класса унаследоваться и переопределять виртуальные функции в имплементации интерфейса, которая еще не известна во время компиляции
VD>Так. Еще разок. Не функция, а интерфейс. Улавливаешь разницу?
SS>> (неизвестно даже виртуальные там методы или нет)

VD>В интерфейсах все функции по поределению виртуальные. Более того у каждого класса свой vtbl строится.

Да я чуток погорячился насчет того что при имплементации интерфейса можно делать невиртуальные функции. Просто там есть то ли глючок то ли фича, — если при имплементации метода интерфейса не указать kw virtual, то в производных классах этот метод переопределить уже нельзя никак (только new). Может это фича C# а не CLR, но это сложно назвать виртуальной функцией.
Может эту багу подправим в новом языке.

Чтобы действительно все методы в интерфейсах были по умолчанию виртуал.

SS>>, здесь прийдется попыхтеть чтобы реализовать без глюков.

VD>Хотел бы я видеть задачу которую можно не пыхтя без глюков реализовать.

Я думаю сложность даже не в реализации компилятора, а в создании непротиворечивой спецификации самого стандарта языка. Так как стандарт языка вещь очень монолитная, трудно туда что-то впихнуть не нарушив остальное.

VD>В конце концов придется создавать динамический втбл и копировать туда указатели на методы. Можно вообще запритить переопределение у таких классов и переопределять методы у агрегируемых объектов. Короче, есть над чем подумать.

Наверно прийдется сделать такой класс sealed. Т.к тут проглядывается концептуальная проблема. Наследоваться надо во время compiletime и нужно уже все знать о классе, а реализация определяется
только в runtime, да еще и может меняться.

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

VD>Дык, а мы легких путей не ищем. ;)

Слова прирожденнго программиста ! Но я все-таки ищу легких путей, иначе накакого времени не хватит !

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

VD>А это как с виртуальными функциями и private-членами. Программист не думая делает, а потом другой вынужден вместо наследования (с целью чуть-чуть подправить функциональность) полностью переписывать весь код.
Угу. Уже приходилось :( :maniac:

VD>Замечательный пример реализация меню в WinForms более глупую объектную модель придумать очень не просто. Например, метод Show у ContextMenu не виртуальный. В нем ошибка (неверно заданы флаги для TrackPopupMenuEx). Да и вообще может я хочу как-то по своему меню показать или делать при это что-нибудь. Далее в класс Control жестко вшито свойство типа ContextMenu. Изменить функциональность невозможно. Суда бы еще сэйледов по напихать. :maniac:

У меня все сильнее складывается впечатление, что непродуманность некоторых вещей заставит микрософт в новой версии библиотек сделать несовместимости со старыми :)

VD>Короче, но один обдуманный случай применения saled, не virtual и private приходится 1000 необдуманных. К тому же, ничего страшного в большинстве случаев не произошло бы если поставить не saled, virtual и protected. Лучше бы качественнее документацию писали.

Эт точно. Хотя мсдн на высоте, лучше миксософта док никто не пишет !

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

AVK>А вобще непонятно. Если дизайнер библиотеки захотел чтобы от класса нельзя было отнаследоваться — зачем это побарывать? Чтобы глюки поиметь?

Глюки- не глюки — это одно, а вот такие нехорошие ограничения — другое. Если я хочу наследоваться, зачем мне это запрещать ? Это анархия какая-то, а не хваленая американськая демократия :) . Дерьмократия, я бы сказал.

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

AVK>Здравствуйте Аноним, Вы писали:

А>>Я думаю, базовые библиотеки нужно попереписывать. Например, DateTime. Он НЕФУНКЦИОНАЛЕН. Мне пришлось написать для него враппер для выполнения примитивных операций типа изменения дня/месяца/года, перехода на след. месяц и т.д.
AVK>А как же его методы AddXXX?

Это-то есть. Но хотелось типа такого:
DateTime d;
d.Day = 1;
d.Year = 2002;

А хрен ! Эти проперти рид-онли. Приходится через парсер_строкИ заполнять.

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

SS>>>obj.Method(param);
SS>>>[/ccode]
А>>Так не получится — не скомпиляется.
SS>obj.Method(param); — Я имел ввиду, если поддержку на уровне языка сделать.

А смысл ? Тогда придется вводить ключевое слово, помечающее класс, типа dynamic, отключающее проверки на этапе компиляции

А>> Но вот типа такого — реально:
А>>obj.Methods["Method"](param);

SS>Да наверное можно сделать класс оболочку более менее юзабельную не меняя языка, если еще использовать передачу переменного числа параметров

А>>Так вперед, в чем проблема ? Я уже давно примерно такое експлуатирую. Компилятор для этого не нужно менять :)
А>>Достаточно написать класс, который расковыривает в реатайме любой тип.

SS> :( Жалко в библиотеке нет такого класса, каждый теперь будет пользоваться самоделками.

Можно сообча создать хорошую библиотеку, выложить ее на рсдэне, чтобы все пользовались. Наработки уже есть :)

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

VD>Здравствуйте IVaNС, Вы писали:
VD>Вообще-то это реализовано. Я, напримен, пароль каждый раз не заполняю. Слышал, что такая проблема есть при использовании RSDN Desktop, но вроде он пока не доступен открыто. :???: Так, что общайся с IT сам.

Не, никакого десктопа я не юзаю. Оби,свяжусь с ним как-нить.

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

VD>>Здравствуйте IVaNС, Вы писали:
VD>>Вообще-то это реализовано. Я, напримен, пароль каждый раз не заполняю. Слышал, что такая проблема есть при использовании RSDN Desktop, но вроде он пока не доступен открыто.

Так, что общайся с IT сам.

IVNС>Не, никакого десктопа я не юзаю. Оби,свяжусь с ним как-нить.
А ты cookies разрешил принимать browser'у.

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

VD>Во-первых, агрегация круче.

В чем же преимущества ?
Я согласен, что иногда динамическая имплементация может быть полезна. Но ! Во-первых, это несколько другая фича, чем множ. наследование, во-вторых, то, что ты предлагаешь, реализуется в компиляторе как частный случай множественного наследования.
Так что, наш спор, наверное, не по существу :)

Чем тебе не нравится множ насл ? Геморрой может возникнуть, когда наследуешься от нескольких классов, имеющих общих предков. Но и тут — объяви себе базовый класс виртуальным — и чики-пуки :)
А вообще никто тебя и не заставляет такое делать :) Подобные трюки не являются необходимостью, но иногда полезны. Ничто не должно ограничивать полет фантазии программиста !

VD>Думаю агрегации и шаблонов будет достаточно.

Начать с чего-то надо. Хотя бы с шаблонов и дефолтных параметров функций !!!

VD>К тому же, множественное наследование не поддерживается CLR-ом.

не поддерживается CLR-ом, но эмулируется с проблемами, но однозначно.

VD>Реальное МН видимо так и останется только в С++
Это от нас зависит ! :)

А>>По-моему, это тупиковый путь. во-первых, отсутствуют проверки на этапе компиляции.
VD>Это ж почему? На этапе компиляции будет проверяться, что агрегируемый класс реализует интерфейс. Этого более чем достаточно.
Все равно, компилер придется доделывать. Ты начинаешь чувствовать, что предлагаешь всего лишь _нестандартный_вариант_ множ наследования ??? :)

А>>Во-вторых, атрибуты придется разгребать в реалтайме и на основании этого генерить код.

VD>Задача реализуемая причем реализуемая в рамках сегодняшнего MSIL-а и CLR-а (по крайней мере мне так кажется).

Да, теоретически это возможно.

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

А>> Это жутко геморройно и некрасиво, а ведь наша задача — получить красивую реализацию !

VD>Что геморройно? Что некрасиво?
Я имею в виду, что если не изменять компилятор, придется лепить кучу лишнего, некрасивого кода, а это никуда не годится. А если уж изменять компилятор, нужно уже реализовать _стандартное_, обкатанное еще в прошлом тысячелетии множ. наследование !!!

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

VD>Оооочень интересно, что ты понимаешь под "обычной агрегацией"?
Обычная агрегация — то, что было до кома :) Класс-агрегат содержит в себе переменные, содержащие экземпляры других классов, и не более того :)))

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

VD>После того как о шаблонах заговорили в Sun, я думаю, что у MS просто не будет выбора.

Они даже читать не будут :( Мой приятель заботает в фирме-подписчике МСДН. Он несколько раз высказывал M$ конструктивные предложения, на которые они благополучно наплевали.

А>>Я думаю, базовые библиотеки нужно попереписывать. Например, DateTime. Он НЕФУНКЦИОНАЛЕН.

VD>Ну, это ерунда... приводишь его к double, а там обычные арефметические операции. К тому же здесь речь шла бы о банальном расширении путем наследования.

Да, расширении. Вроде, обычное применение наследования :) А приводить каждый раз к доубель-неудобно. Я написал враппер, который непосредственно приводится к датетиме.

А>>Или вот обычные массивы. Чтобы добавить/удалить элементик, приходится использовать нетипизированный и тормозной ArrayList

VD>Вот об этом и речь. Только, я бы сформулировал так: Динамические массивы доступны только для общего класса object, что рпиводит к тормозам при использовании value-типов и невозможности проверок на стадии компиляции из-за ненужного здесь полиморфизма.

Хорошо это более правильно, с дополнением: arraylist — все-таки список, и работает медленнее, и, к тому же, при приобразовании в массив производится ненужное поэлементное копирование.

А>>, а потом конвертить его обратно в System.Array. Куда это годится ? Почему они забыли про обычный realloc() ?

VD>Потому, что в природе не существует алгоритмов realloc-а. При realloc-е просто занимается новый массив, данные копируются, а старый освобождается. Такой realloc я и сам за пять минут сворганю. Только он будет еще более медленный чем ArrayList (при условии частого изменения размера массива).

Заметь одну вещь: копирование производится только тогда, когда винда не может увеличить размер блока памяти при оставлении его непрерывным. А умные реализации эффективных динамических массивов — дело хитрое, но разрешимое. Например, такая: выделяешь динамически массив с запасом. При его заполнении проверяется свободное место, и при достижении % заполненности этот массив ресайзится, добавляя блок пустых элементов. Если примерно знать число элементов и интенсивность добавления, производительность получается очень высокой. С удалением — хуже, но и тут есть трюки, чтоб копирование участков памяти производить не сразу, а при выполнении опред. условий. Также приходится создавать спец. итераторы.
Какая выгода от такого массива ? Во-первых, если тебе не нужно добавлять/убирать элементы, то производительность ТАКАЯ ЖЕ, как у обычного массива. Во-вторых, во многих задачах требуется добавление элементов, а удаление вообще не используется. Если много удалений — конечно, лучше аррэйлист, тем более, что адреса элементов там кешируются (нет поиска при обращении к элементу, ф смотрел в исходниках)
В-третьих, System.Array реализован с использованием ComArray, который, естественно, создается динамически.
Так что ты согласен, что разумно было бы сделать такой массив системным ?

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

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

VD>>>Здравствуйте IVaNС, Вы писали:
VD>>>Вообще-то это реализовано. Я, напримен, пароль каждый раз не заполняю. Слышал, что такая проблема есть при использовании RSDN Desktop, но вроде он пока не доступен открыто. :???: Так, что общайся с IT сам.

IVNС>>Не, никакого десктопа я не юзаю. Оби,свяжусь с ним как-нить.
SS>А ты cookies разрешил принимать browser'у.

Ясное дело, стоит на аксепт олл кукиз.

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

IVNС>Эт точно. Хотя мсдн на высоте, лучше миксософта док никто не пишет !
Скажем так — ты не совсем прав.

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

IVNС>Глюки- не глюки — это одно, а вот такие нехорошие ограничения — другое. Если я хочу наследоваться, зачем мне это запрещать ?
Да. Это как private — если поставили значит доступ извне закрыт. Даже еще хуже, если private ставится по умолчанию, то sealed ставят преднамеренно, когда хотят чтобы ты не смог отнаследоваться. Так что все претензии не к языку, а к писателю библиотеки.

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

А>>>Я думаю, базовые библиотеки нужно попереписывать. Например, DateTime. Он НЕФУНКЦИОНАЛЕН. Мне пришлось написать для него враппер для выполнения примитивных операций типа изменения дня/месяца/года, перехода на след. месяц и т.д.
AVK>>А как же его методы AddXXX?

IVNС>Это-то есть. Но хотелось типа такого:
IVNС>DateTime d;
IVNС>d.Day = 1;
IVNС>d.Year = 2002;

IVNС>А хрен ! Эти проперти рид-онли. Приходится через парсер_строкИ заполнять.
И здесь ты не до конца разобрался

DateTime Constructor (Int32, Int32, Int32)

Initializes a new instance of the DateTime structure to the specified year, month, and day.

[Serializable]
public DateTime(
   int year,
   int month,
   int day
);

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

IVNС>Можно сообча создать хорошую библиотеку, выложить ее на рсдэне, чтобы все пользовались. Наработки уже есть :)
Я давно предлагал организовать проект вроде RXLib на Дельфи. Уж больно многого не хватает.

Здравствуйте Аноним, Вы писали:

А>Если много удалений — конечно, лучше аррэйлист
Если много удалений лучше написать свой связанный список. Быстрее будет раз в 10.

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

IVNС>>А хрен ! Эти проперти рид-онли. Приходится через парсер_строкИ заполнять.
AVK>И здесь ты не до конца разобрался
AVK>[ccode]
AVK>DateTime Constructor (Int32, Int32, Int32)

Да нет, я до конца разобрался, ты не понял, что я хочу сказать :) Что такое конструктор, я вроде как знаю. Я имел в виду чтоб можно было устанавливать Day, Year, Month _по отдельности_.

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

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

IVNС>>Глюки- не глюки — это одно, а вот такие нехорошие ограничения — другое. Если я хочу наследоваться, зачем мне это запрещать ?
AVK>Да. Это как private — если поставили значит доступ извне закрыт. Даже еще хуже, если private ставится по умолчанию, то sealed ставят преднамеренно, когда хотят чтобы ты не смог отнаследоваться. Так что все претензии не к языку, а к писателю библиотеки.

Именно к языку, поскольку это позволяет ограничивать программиста !

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

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

IVNС>>Эт точно. Хотя мсдн на высоте, лучше миксософта док никто не пишет !
AVK>Скажем так — ты не совсем прав.
Почему ? Как по информативности, так и по удобству микрософт впереди. Если ты видел, с переходом на новый стандарт hxi/hxs, им удалось на 3 копмакта уместить то, что раньше было на 5 :) А апрельском 2002 они вообще напихали, что только могли :)

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

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

IVNС>>>А хрен ! Эти проперти рид-онли. Приходится через парсер_строкИ заполнять.
AVK>>И здесь ты не до конца разобрался
AVK>>

AVK>>DateTime Constructor (Int32, Int32, Int32)

IVNС>Да нет, я до конца разобрался, ты не понял, что я хочу сказать

Что такое конструктор, я вроде как знаю. Я имел в виду чтоб можно было устанавливать Day, Year, Month _по отдельности_.
Ты специально издеваешся?

 DateTime data1 = ...;
 DateTime data2 = new DateTime(1,date1.Month,date1.Year-1);

И никаких строковых парсеров не надо

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

AVK>>Да. Это как private — если поставили значит доступ извне закрыт. Даже еще хуже, если private ставится по умолчанию, то sealed ставят преднамеренно, когда хотят чтобы ты не смог отнаследоваться. Так что все претензии не к языку, а к писателю библиотеки.

IVNС>Именно к языку, поскольку это позволяет ограничивать программиста !
Ну хорошо, давай твою идею, так сказать разовьем. private,protected,internal мешает программисту? Мешает. Убиваем нафик. Проверка на возврат значение мешает? Проверка на инициализацию мешает? GC мешает? Необходимость обязательной имплементации объявленных интерфейсов мешает? Мешает. Удаляем.

Дальше продолжать?

Здравствуйте Аноним, Вы писали:

А>Почему ? Как по информативности, так и по удобству микрософт впереди.
Впереди планеты всей?

А много ли ты видел не MS документации?

А> Если ты видел, с переходом на новый стандарт hxi/hxs, им удалось на 3 копмакта уместить то, что раньше было на 5

А апрельском 2002 они вообще напихали, что только могли

На начхать на формат документации. Главное содержимое. А содерживое MS'овской документации иногда хромает. Я тут где то месяц назад кида пример из доки. Мне удалось уменьшить его раза так в три, при увеличении его понятности.

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

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

AVK>>>Да. Это как private — если поставили значит доступ извне закрыт. Даже еще хуже, если private ставится по умолчанию, то sealed ставят преднамеренно, когда хотят чтобы ты не смог отнаследоваться. Так что все претензии не к языку, а к писателю библиотеки.

IVNС>>Именно к языку, поскольку это позволяет ограничивать программиста !
AVK>Ну хорошо, давай твою идею, так сказать разовьем. private,protected,internal мешает программисту? Мешает. Убиваем нафик. Проверка на возврат значение мешает? Проверка на инициализацию мешает? GC мешает? Необходимость обязательной имплементации объявленных интерфейсов мешает? Мешает. Удаляем.

Все-таки лучше было сделать protected & private (особенно private) не жесткими ограничениями, а просто предупреждениями, т.к. я еще не встречал ни одного класса, у которого нельзя было немного расширить функциональность.

Т.е. по умолчанию, я не могу вызвать protected & private, но если сильно хочу (и отвечаю за свои действия), то могу.

Тоже самое можно сделать и с остальными вещами, т.е. если программись явно написал, что он хочет извратнутся, то пусть извращается.

Что-то такое, синтаксис, конечно, можно сделать более удобным

class A
{
private void Method ();
};

A.<public>Method(); //в этом случае, я беру на себя все проблемы по использованию protected Method-а

//или
class B:
  public A
{
  void Method ()
  {
    A.<public>Method();
  }
};

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

DG>Все-таки лучше было сделать protected & private (особенно private) не жесткими ограничениями, а просто предупреждениями, т.к. я еще не встречал ни одного класса, у которого нельзя было немного расширить функциональность.

DG>Т.е. по умолчанию, я не могу вызвать protected & private, но если сильно хочу (и отвечаю за свои действия), то могу.
Лично я считаю что то что я могу полагаться что никто снаружи не доступится к классу это очень хорошо. А сделать возможность доступа к закрытым полям не так то просто. Очень многое в фреймворке на это заточено. К примеру тот же ремоутинг — в прокси включаются только публичные поля. Вызвать private метод нельзя просто потому что он физически отсутствует в метаданных. И и т.д.

Здравствуйте Аноним, Вы писали:

DG>>Все-таки лучше было сделать protected & private (особенно private) не жесткими ограничениями, а просто предупреждениями, т.к. я еще не встречал ни одного класса, у которого нельзя было немного расширить функциональность.

DG>>Т.е. по умолчанию, я не могу вызвать protected & private, но если сильно хочу (и отвечаю за свои действия), то могу.
А>Лично я считаю что то что я могу полагаться что никто снаружи не доступится к классу это очень хорошо.

Так полагайся на это и дальше, так как человек вызвавщий protected &private метод делает это на свой страх и риск. Если ты о безопасности от хака, то protected&private тебя не спасут, так как их можно обойти с большим или меньшим геморром.

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

A>А сделать возможность доступа к закрытым полям не так то просто. Очень многое в фреймворке на это заточено. К примеру тот же ремоутинг — в прокси включаются только публичные поля. Вызвать private метод нельзя просто потому что он физически отсутствует в метаданных. И и т.д.

На самом деле мне мешает только спецификатор private, т.к. я совсем не могу расширить класс сторонних разработчиков. А при наследование проблем будет меньше, и их можно было решить.

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

DG>>>Т.е. по умолчанию, я не могу вызвать protected & private, но если сильно хочу (и отвечаю за свои действия), то могу.
А>>Лично я считаю что то что я могу полагаться что никто снаружи не доступится к классу это очень хорошо.

DG>Так полагайся на это и дальше, так как человек вызвавщий protected &private метод делает это на свой страх и риск. Если ты о безопасности от хака, то protected&private тебя не спасут, так как их можно обойти с большим или меньшим геморром.
Нет, я о безопасности от глюка. Я вобще не понимаю — если это твой код, то никаких проблем поменять прайват на паблик нет, если нормально написанная либа, то там все что нужно будет открыто, а если ненормально написаная — так нафига ей пользоваться?

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

AVK>Ты специально издеваешся?
Ты зря кипятишься :) Все, что я хотел — чтоб проперти дня, месяца, года можно было изменить по-отдельности, не вызывая ни конструкторов, ни парсеров :) Ты же все время хочешь задавать дату целиком.

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

AVK>Здравствуйте Аноним, Вы писали:

А>>Почему ? Как по информативности, так и по удобству микрософт впереди.
AVK>Впереди планеты всей? :) А много ли ты видел не MS документации?
Пользовался доками по программизмам QNX, Linux, Solaris, BeOS, Oracle.
Хорошие доки у соляриса, самые худшие — у кьюникса

AVK>На начхать на формат документации. Главное содержимое. А содерживое MS'овской документации иногда хромает. Я тут где то месяц назад кида пример из доки. Мне удалось уменьшить его раза так в три, при увеличении его понятности.

Вовсе не начхать. Формат предусматривает наличие средств просмотра и поиска. У не-микрософтовских док обычное средство просмотра — текстовый редактор, кривой просмотрщик, или, в лучшем случае, хтмл, поэтому времени на поиск инфы тратится куда больше.
Согласись, что я прав.

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

AVK>Ну хорошо, давай твою идею, так сказать разовьем. private,protected,internal мешает программисту? Мешает. Убиваем нафик. Проверка на возврат значение мешает? Проверка на инициализацию мешает? GC мешает? Необходимость обязательной имплементации объявленных интерфейсов мешает? Мешает. Удаляем.

Блин, вовсе не надо удалять !
Ты в неправильном направлении развиваешь мою мысль.
Просто нужно добавить ключевое слово, отменяющее действие другого. Например, злосчастного sealed. А использовать ли unsealed, или нет — личное дело. Так было бы гибче.

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

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

DG>>Так полагайся на это и дальше, так как человек вызвавщий protected &private метод делает это на свой страх и риск. Если ты о безопасности от хака, то protected&private тебя не спасут, так как их можно обойти с большим или меньшим геморром.
AVK>Нет, я о безопасности от глюка. Я вобще не понимаю — если это твой код, то никаких проблем поменять прайват на паблик нет, если нормально написанная либа, то там все что нужно будет открыто, а если ненормально написаная — так нафига ей пользоваться?

Дык, "ненормально" написанных библиотек большинство (в том числе от Microsoft), в которых этих protected & private просто немеренно натыкано.

Здравствуйте Аноним, Вы писали:

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

AVK>>Ты специально издеваешся?
А>Ты зря кипятишься

Все, что я хотел — чтоб проперти дня, месяца, года можно было изменить по-отдельности, не вызывая ни конструкторов, ни парсеров

Ты же все время хочешь задавать дату целиком.
Видишь ли какое дело — дата хранится в переменной типа double и в любом случае будет меняться целиком. Ты мне объясни — чем написание собственного wrapper лучше приведенного мною способа?

Здравствуйте Аноним, Вы писали:

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

AVK>>Здравствуйте Аноним, Вы писали:

AVK>>Впереди планеты всей?

А много ли ты видел не MS документации?
А>Пользовался доками по программизмам QNX, Linux, Solaris, BeOS, Oracle.
А>Хорошие доки у соляриса, самые худшие — у кьюникса
Ну линукса понятно, там хороших док не будет. У BeOS были очень хорошие доки, получше MS'овских. У оракля таки да, доки поганенькие. Остального не видел.

А>Вовсе не начхать. Формат предусматривает наличие средств просмотра и поиска. У не-микрософтовских док обычное средство просмотра — текстовый редактор, кривой просмотрщик, или, в лучшем случае, хтмл, поэтому времени на поиск инфы тратится куда больше.
Большинство док сейчас в формате html. Который легко и непринужденно переделывается в столь любимый тобой chm.

А>Согласись, что я прав.
Неа

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

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

IVNС>Блин, вовсе не надо удалять !
IVNС>Ты в неправильном направлении развиваешь мою мысль.
IVNС>Просто нужно добавить ключевое слово, отменяющее действие другого. Например, злосчастного sealed. А использовать ли unsealed, или нет — личное дело. Так было бы гибче.
Не, это блин маразм какой то получается. Один классы закрывает, а другой с упорством их обратно разрешает. Нафига тогда вобще sealed если его можно отменить?

IVNС>DarkGray, как я считаю, прав — это повысило бы гибкость языка. Когда нужно расковырять чужое, а кода нет — это самое то.
Не, не понимаю я этого маниакального стремления расковыривать что то чужое. Проще все переписать.

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

А>>Вовсе не начхать. Формат предусматривает наличие средств просмотра и поиска. У не-микрософтовских док обычное средство просмотра — текстовый редактор, кривой просмотрщик, или, в лучшем случае, хтмл, поэтому времени на поиск инфы тратится куда больше.
AVK>Большинство док сейчас в формате html. Который легко и непринужденно переделывается в столь любимый тобой chm.

Так главное-то не txt/html/chm, а хорошая структуризация материала, в MSDN-е я нашел через поиск что-то похожее на то, что я ищу, нажал locate и наслаждаюсь топиками, близкими к моей проблеме.
А том же Man-е/VB-хелпе/stl-хелпе, если я не знаю конкретно, что искать, то и не найду, т.к. это просто плоский хелп, никак не структурированный.

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

DG>Дык, "ненормально" написанных библиотек большинство (в том числе от Microsoft), в которых этих protected & private просто немеренно натыкано.
Да нет, натыкано там все специально. Особенно sealed. Просто надо повнимательнее читать доку, там все нормальные способы сделать то или иное описаны, а не пытаться тоже самое сделать через задницу. Вот например — делаю я синглтон, конструктор естественно объявляю private. Потом появляется такой вот чел, который не разобравшись начинает вопеть — как так конструктор приватный, какая кривая либа. И вызывает приватный конструктор. Получает естественно набор труднотлавливаемых глюков где то внутри библиотеки и начинает орать что либа кривая.
Разработчики библиотек в массе как правило грамотнее их пользователей, поэтому отмена модификаторов доступа принесет больше проблем чем пользы.

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

AVK>Видишь ли какое дело — дата хранится в переменной типа double и в любом случае будет меняться целиком. Ты мне объясни — чем написание собственного wrapper лучше приведенного мною способа?

В long, если точнее. А смысл во враппере такой, что, кроме того, что по-отдельности работаю с полями, добавил во враппер методы для работы с датами — назв месяцев на нескольких языках, переходы на следующие/предыдущие дни/месяца/года (хотя можно писать d = AddMonths(1), удобнее d.NextMonth()), получение всех месяцев периода и тд.
sealed здесь только помешал.

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

AVK>Не, не понимаю я этого маниакального стремления расковыривать что то чужое. Проще все переписать.

А оплачивать кто все это будет? И время откуда брать?
Так берешь/покупаешь чужую реализацию, не много ее расковыриваешь, делаешь пару хелперов, несколько нашлепок на чужие классы и работаешь, потихоньку заменяя чужой код на свой или оставляя чужой, если он "достаточно хороший".

При отсутствии anti-private/anti-protected/anti-sealed все это делается очень сложно и не оптимально, так как остается использовать только ту узкую щелку, которую оставил разработчик библиотеки.

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

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

DG>Так главное-то не txt/html/chm, а хорошая структуризация материала, в MSDN-е я нашел через поиск что-то похожее на то, что я ищу, нажал locate и наслаждаюсь топиками, близкими к моей проблеме.
Ты знаешь, лично я поиском пользуюсь крайне редко. Обычно знаю где что лежит.

DG>А том же Man-е/VB-хелпе/stl-хелпе, если я не знаю конкретно, что искать, то и не найду, т.к. это просто плоский хелп, никак не структурированный.
Но ведь этими плоскими хелпами весь мир не ограничивается. Чем тебе не нравится хелп Дельфи? Или Java?

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

AVK> Вот например — делаю я синглтон, конструктор естественно объявляю private. Потом появляется такой вот чел, который не разобравшись начинает вопеть — как так конструктор приватный, какая кривая либа. И вызывает приватный конструктор. Получает естественно набор труднотлавливаемых глюков где то внутри библиотеки и начинает орать что либа кривая.
AVK>Разработчики библиотек в массе как правило грамотнее их пользователей, поэтому отмена модификаторов доступа принесет больше проблем чем пользы.

Ты правильно заметил, что в массе грамотнее, а как быть тем пользователем, которые грамотнее разработчика библиотеки или имеют, хотя бы такой же уровень.
Вот захочу я немного расширить твой singleton, добавить пару простых функций и опа, компилятор мне говорит "а не фиг", пользуйся тем, что дают.
Хотя я мог полностью понимать, что хотел сказать этим private-ом разработчик либы, мне это ничем не поможет.
Придется все равно выдирать весь код из либы, переписывать и т.д., что в дальнейшем для меня сильно затруднит переход на следующую версию твоей библиотеки.

Здравствуйте Аноним, Вы писали:

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

AVK>>Видишь ли какое дело — дата хранится в переменной типа double и в любом случае будет меняться целиком. Ты мне объясни — чем написание собственного wrapper лучше приведенного мною способа?

А>В long, если точнее.
Да нет, именно в double. В целой части хранится дата, в дробной время.

А> А смысл во враппере такой, что, кроме того, что по-отдельности работаю с полями, добавил во враппер методы для работы с датами — назв месяцев на нескольких языках,
И это тоже можно сделать стандартными средствами. Причем на таком количестве языков что тебе ни за что самому не сделать.
А> переходы на следующие/предыдущие дни/месяца/года (хотя можно писать d = AddMonths(1), удобнее d.NextMonth()),
Ни чуть не удобнее. И и мелочь все это. Не на том внимание заостряешь.

А>sealed здесь только помешал.
Тут я тебе могу объяснить к чему sealed. Фреймворк очень сильно завязан на DateTime. И во многих случаях если ты подсунешь своего наследника это приведет к глюкам. К примеру в ADO.NET осуществляется автоматическое преобразование стандартных типов к sql типам. Представь что будет если ты впихнешь свой DateTime. В лучшем случае она просто выкинет исключение. А в худшем она сериализует твой объект и запихает его в блоб. И ты долго будешь глюки вылавливать.
Это только один пример. Таких моментов в фреймворке масса. Поэтому все стандартные типы объявлены как sealed. Если же очень приспичило свой DateTime — используй агрегацию и реализуй IConvertible.

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

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

DG>А оплачивать кто все это будет? И время откуда брать?
DG>Так берешь/покупаешь чужую реализацию, не много ее расковыриваешь, делаешь пару хелперов, несколько нашлепок на чужие классы и работаешь, потихоньку заменяя чужой код на свой или оставляя чужой, если он "достаточно хороший".
О как — достаточно хороший. Так не бывает — либо хороший, либо плохой. Если вы будете отменять модификаторы то такой код становится крайне плохим. Сейчас эта либа работает, потом очередная версия что то внутри себя меняет и твоя прога начинает глючить по черному, причем ошибки сыпятся внутри чужого кода (который без исходников).

DG>При отсутствии anti-private/anti-protected/anti-sealed все это делается очень сложно и не оптимально, так как остается использовать только ту узкую щелку, которую оставил разработчик библиотеки.

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

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

DG>Ты правильно заметил, что в массе грамотнее, а как быть тем пользователем, которые грамотнее разработчика библиотеки или имеют, хотя бы такой же уровень.
DG>Вот захочу я немного расширить твой singleton, добавить пару простых функций и опа, компилятор мне говорит "а не фиг", пользуйся тем, что дают.
Синглтонами как правило реализуется ядро системы. И наследовать от них без исходного кода крайне нежелательно. Если же такая возможность есть то я объявлю конструктор как protected.

DG>Придется все равно выдирать весь код из либы, переписывать и т.д., что в дальнейшем для меня сильно затруднит переход на следующую версию твоей библиотеки.
Вот как раз пользование private членами и затруднит переход на новую версию, ибо я имею полное право вобще прайват-член прибить. Блин, ну что я тут основы ООП рассказываю. Вы специально издеваетесь, либо мы друг друга просто не понимаем.

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

AVK>Вот как раз пользование private членами и затруднит переход на новую версию, ибо я имею полное право вобще прайват-член прибить. Блин, ну что я тут основы ООП рассказываю. Вы специально издеваетесь, либо мы друг друга просто не понимаем.

Не горячись

Просто ООП — это не панацея. Вопрос в том, что если писать язык только для профессионалов, то можно сделать такие изменения в языке, если думать о том, что чайники тоже захотят пользоваться языком, то есть только два пути: первый — запретить им делать то, что делать в большинстве случаев не нужно, второй — разрешить, но повесить красную табличку: "если вы используете это, то мы не несём никакой ответсвенности". Для профи второй вариант явно лучше.

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

MT>Не горячись

MT>Просто ООП — это не панацея. Вопрос в том, что если писать язык только для профессионалов, то можно сделать такие изменения в языке, если думать о том, что чайники тоже захотят пользоваться языком, то есть только два пути: первый — запретить им делать то, что делать в большинстве случаев не нужно, второй — разрешить, но повесить красную табличку: "если вы используете это, то мы не несём никакой ответсвенности". Для профи второй вариант явно лучше.

Спорный вопрос. Человек не автомат — кое где и дурака может свалять, даже наикрутейший профи.

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

AVK>>>Видишь ли какое дело — дата хранится в переменной типа double и в любом случае будет меняться целиком. Ты мне объясни — чем написание собственного wrapper лучше приведенного мною способа?

А>>В long, если точнее.
AVK>Да нет, именно в double. В целой части хранится дата, в дробной время.
Да нет, именно в long. В тиках. Хотя это не принципиально :) Только не надо меня бить :) :maniac:

А>> А смысл во враппере такой, что, кроме того, что по-отдельности работаю с полями, добавил во враппер методы для работы с датами — назв месяцев на нескольких языках,
AVK>И это тоже можно сделать стандартными средствами. Причем на таком количестве языков что тебе ни за что самому не сделать.
А>> переходы на следующие/предыдущие дни/месяца/года (хотя можно писать d = AddMonths(1), удобнее d.NextMonth()),
AVK>Ни чуть не удобнее. И и мелочь все это. Не на том внимание заостряешь.
Из мелочей складывается полная картина. Если какая-то логика используется вне класса неоднократно, имеет смысл поместить ее в класс

А>>sealed здесь только помешал.
AVK>Тут я тебе могу объяснить к чему sealed. Фреймворк очень сильно завязан на DateTime. И во многих случаях если ты подсунешь своего наследника это приведет к глюкам. К примеру в ADO.NET осуществляется автоматическое преобразование стандартных типов к sql типам. Представь что будет если ты впихнешь свой DateTime.

Если криво его написать, конечно. А так — все отлично конвертится.

В лучшем случае она просто выкинет исключение. А в худшем она сериализует твой объект и запихает его в блоб. И ты долго будешь глюки вылавливать.
AVK>Это только один пример. Таких моментов в фреймворке масса. Поэтому все стандартные типы объявлены как sealed. Если же очень приспичило свой DateTime — используй агрегацию и реализуй IConvertible.

Да я так и сделал.

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

AVK>Вот как раз пользование private членами и затруднит переход на новую версию, ибо я имею полное право вобще прайват-член прибить.

Тут ты абсолютно прав !

Блин, ну что я тут основы ООП рассказываю. Вы специально издеваетесь, либо мы друг друга просто не понимаем.

AVK>Вовсе не издеваюсь. Мы ведь не просто так тут динаму крутим, а обсуждаем, что нужно для нового компилятора.
Если что-то закрыто преднамеренно, это сделано явно не просто так-это и ежу понятно. То, что новые ключевые слова нарушают все устои оопа и увеличивают вероятность глюка — факт.
Так что, если делать выводы — обойдемся без возможности отмены sealed, и, тем более, всего остального.
Оценки за ответы уже могу выставить :)

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

DG>>А оплачивать кто все это будет? И время откуда брать?
DG>>Так берешь/покупаешь чужую реализацию, не много ее расковыриваешь, делаешь пару хелперов, несколько нашлепок на чужие классы и работаешь, потихоньку заменяя чужой код на свой или оставляя чужой, если он "достаточно хороший".
AVK>О как — достаточно хороший. Так не бывает — либо хороший, либо плохой.

"Достаточно хороший"(good enough) — это не моя концепция, это концепция почти всей западной программиской тусовки. Если код/программа удовлетворяет мои 80% потребностей, оставляя 20% остальных не решенными, то это "good enough".
Нельзя же тот же Word, назвать, ни хорошим, ни плохим, он просто "good enough".

AVK>Если вы будете отменять модификаторы то такой код становится крайне плохим. Сейчас эта либа работает, потом очередная версия что то внутри себя меняет и твоя прога начинает глючить по черному, причем ошибки сыпятся внутри чужого кода (который без исходников).

Все-таки новые версии либ выходят не каждый день, а раз так в год. И я уж как-нибудь разбирусь раз в год, что надо сделать чтобы перейти на новую либу, или решу, что не надо переходить, и так уже все работает.

Инкапсуляции в ООП-е это палка о двух концах, она очень сильно мешает делать, если пользоваться терминами БД, "не заплананированные запросы", т.е. те вещи, которые разработчик либы не предусмотрел.

Нельзя сделать "вертикальную" оптимизацию, например, групповую инициализацию, групповые операции.

struct A
{
  private void Method ()
  {
    Lock();
    ChangeGlobalResource();
    Unlock();
  }
};

//будет только так
foreach (A a in list)
{
  a.Method();
}

//А хотелось бы:
Lock();
foreach(A a in list)
{
  a.MethodWithoutLock();
}
Unlock();

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

DG>>Так главное-то не txt/html/chm, а хорошая структуризация материала, в MSDN-е я нашел через поиск что-то похожее на то, что я ищу, нажал locate и наслаждаюсь топиками, близкими к моей проблеме.
AVK>Ты знаешь, лично я поиском пользуюсь крайне редко. Обычно знаю где что лежит.

Это возможно только при совпадении двух вещей: малая заинтересованность новыми(неизвестными еще) вещами и опять же, хорошей структуризации хелпа.

DG>>А том же Man-е/VB-хелпе/stl-хелпе, если я не знаю конкретно, что искать, то и не найду, т.к. это просто плоский хелп, никак не структурированный.
AVK>Но ведь этими плоскими хелпами весь мир не ограничивается. Чем тебе не нравится хелп Дельфи? Или Java?

После MSDN хелп Delphi мне очень не понравился, теперь я в Builder-е/Delphi пользуюсь их хелпом, только если надо прочитать, что делает данная функция данного класса, если то же самое можно посмотреть в MSDN, то я пользуюсь MSDN-ом.

На Java-е я писал только небольшие проекты, поэтому за их Хелп ничего не скажу.

В MSDN-е для каждой темы есть разделы, "About/introduction", "Using", "Reference", остальные хелпы ограничиваются в основном только частью Reference.

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

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

MT>>Не горячись

MT>>Просто ООП — это не панацея. Вопрос в том, что если писать язык только для профессионалов, то можно сделать такие изменения в языке, если думать о том, что чайники тоже захотят пользоваться языком, то есть только два пути: первый — запретить им делать то, что делать в большинстве случаев не нужно, второй — разрешить, но повесить красную табличку: "если вы используете это, то мы не несём никакой ответсвенности". Для профи второй вариант явно лучше.

AVK>Спорный вопрос. Человек не автомат — кое где и дурака может свалять, даже наикрутейший профи.

Но это уже его проблемы, и он на это сознательно шел, и ему без этого было не обойтись.

А так получается все пользователи подводятся под одну гребенку, прямо коммунизм какой-то, в самой жесткой форме его проявления (либо ты с нами, либо одно из двух).

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

AVK>Спорный вопрос. Человек не автомат — кое где и дурака может свалять, даже наикрутейший профи.

Нато профи и деньги платят, чтоб дурака не валял

А так, известный же закон — за всё надо платить. С другой стороны можно сделать так, чтоб язык поддерживал два уровня: Professional и Expert.

P.S. Кстати, вспомнилось: если в С++ переменная объявлена как private, то это не означает, что её можно менять только изнутри класса. Достаточно выдать её адрес и вся ОО-эпопея закончиться.

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

IVNС>>Просто нужно добавить ключевое слово, отменяющее действие другого. Например, злосчастного sealed. А использовать ли unsealed, или нет — личное дело. Так было бы гибче.
AVK>Не, это блин маразм какой то получается. Один классы закрывает, а другой с упорством их обратно разрешает. Нафига тогда вобще sealed если его можно отменить?

Да сделать вобще наследование от sealed в виде error который в warning можно превратиь через опции компилятора. Если у него не более глубокие корни и он не произрастает от IL. Кому надо тот отключит ошибки.

AVK>Не, не понимаю я этого маниакального стремления расковыривать что то чужое. Проще все переписать.

Помнится когдато я давным давно я писал прогу на CBuilder (Delphi), это была не коробочная комерческая прога, а можно сказать для для временного использования (да на CBuilder только такие и пишут), но очень была нужна.
Так вот надо было конвертировать изображения в jpg и сохранять. В той версии VCL jpg можно было читать с помощью какого то недокументированного класса но отконвертировать в jpg не было возможности так как все нужные методы были private. Я долго тыркался ища обходные пути, а потом совершил "преступление" в *.h файлах библиотеки убрал private. И готов бы был ... :maniac: если бы мне кто-то сказал тогда что этого делать нельзя. Ну очень надо было быстро все сделать.
И мне было наплевать у кого там были руки кривые или склероз( забыли private убрать) или хотели как лучше- заботились чтобы я на глюки не напоролся. Я сэкономил кучу времени, не писать же самому конвертер jpg, когда он на диске лежит.
Под .NET все более серьезно в двоичных файлах так просто private не снимишь.

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

IVNС>Да нет, именно в long. В тиках. Хотя это не принципиально

Только не надо меня бить

Да, здесь я наврал

AVK>>Тут я тебе могу объяснить к чему sealed. Фреймворк очень сильно завязан на DateTime. И во многих случаях если ты подсунешь своего наследника это приведет к глюкам. К примеру в ADO.NET осуществляется автоматическое преобразование стандартных типов к sql типам. Представь что будет если ты впихнешь свой DateTime.

IVNС>Если криво его написать, конечно. А так — все отлично конвертится.
Да не напишешь ты прямо просто потому что не будеш точно знать как и где он используется.

AVK>>Это только один пример. Таких моментов в фреймворке масса. Поэтому все стандартные типы объявлены как sealed. Если же очень приспичило свой DateTime — используй агрегацию и реализуй IConvertible.
IVNС>Да я так и сделал.
Ну вот и молодец. Хотя я думаю что это излишне. Все что ты перечислил можно было сделать и без этого. И уж тем более без парсинга строки.

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

DG>Все-таки новые версии либ выходят не каждый день, а раз так в год. И я уж как-нибудь разбирусь раз в год, что надо сделать чтобы перейти на новую либу, или решу, что не надо переходить, и так уже все работает.
Тут ты совсем не прав. Мне вон к примеру апдейты 1Совских конфигураций чуть ли не каждую неделю сыпются. Ребята изначально не подумали что обновлять придется, а теперь каждое обновление, из-за того что часть конфигурации ручками писана, превращается в такой гемморой.

DG>Нельзя сделать "вертикальную" оптимизацию, например, групповую инициализацию, групповые операции.
Таки можно. Но это тема уже совсем другого разговора.

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

DG>После MSDN хелп Delphi мне очень не понравился, теперь я в Builder-е/Delphi пользуюсь их хелпом, только если надо прочитать, что делает данная функция данного класса, если то же самое можно посмотреть в MSDN, то я пользуюсь MSDN-ом.
А ты знаешь что хелп по платформе не Борландом писан а просто взят у MS? Так что претензии к MS.

DG>В MSDN-е для каждой темы есть разделы, "About/introduction", "Using", "Reference", остальные хелпы ограничиваются в основном только частью Reference.
Не все.

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

MT>Нато профи и деньги платят, чтоб дурака не валял :))) А так, известный же закон — за всё надо платить. С другой стороны можно сделать так, чтоб язык поддерживал два уровня: Professional и Expert.

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

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

AVK>>Спорный вопрос. Человек не автомат — кое где и дурака может свалять, даже наикрутейший профи.

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

DG>А так получается все пользователи подводятся под одну гребенку, прямо коммунизм какой-то, в самой жесткой форме его проявления (либо ты с нами, либо одно из двух).
Просто акцент в языках вроде C# или Java переносится немножко на другое.

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

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

AVK>>Спорный вопрос. Человек не автомат — кое где и дурака может свалять, даже наикрутейший профи.

MT>Нато профи и деньги платят, чтоб дурака не валял

А так, известный же закон — за всё надо платить. С другой стороны можно сделать так, чтоб язык поддерживал два уровня: Professional и Expert.
Профи как раз не будет пытаться похачить чужой код без исходников. Ибо время — деньги. А то что переписать код проще чем разобраться в чужом (а у нас еще и исходников нет) — давно известный факт.

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

SS>Да сделать вобще наследование от sealed в виде error который в warning можно превратиь через опции компилятора. Если у него не более глубокие корни и он не произрастает от IL. Кому надо тот отключит ошибки.
Да неважно как это реализовать. Я пытаюсь доказать что отключение sealed принесет больше вреда чем пользы. Даже наикрутейшему профи.

SS>Под .NET все более серьезно в двоичных файлах так просто private не снимишь.
Ну если ну очень хочется то можно вызвать через рефлекшен, выставив в конфиге соотв. права.

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

AVK>Я пытаюсь доказать что отключение sealed принесет больше вреда чем пользы. Даже наикрутейшему профи.

Это тоже верно. Ведь порой даже профи не может видеть всей картины.

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

AVK>Ну так sealed как раз и делает виртуальные функции статическими.

Да? А что по твоему будет если этот метод был виртуальным в трех подклассах, а в четвертом его пометили как sealed? Что же если я приведу указатель к базовому классу и вызову метод, то виртуальность испарится и вызовется метод базового класса?

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

А ты что хочешь запускать WinForm-ный код на платформах отличных от Windows? А тогда о чем речь. Или ты имеешь убожество вроде Swing-а или платформно-зависимый код облаченный в обертку. Я вично не вижу проблем в том, что в библиотеках будет зашит этот код. Зато результат на порядки лучше.

VD>>Ну, а почему не сделали? Думаю они пакт с разработчиками компонентов (вроде Infragistoс) заключили. Те не пишут ОС, а MC делает недоделанные кривые компонетнты.

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

Ты хоть эти контролы видел? Тебе и в жизни не удастся их написать (или только этим и будеш заниматься), и Sun с MS тоже никогда подобного качества продуков не выпустят. Ява еще даже под стол пешком не ходила, а куча команд клепала VBX-ы отменного качества. Ты сталкивался с самопалами, которые действительно низкого качества. Хотя вот глянь, менюшки с табами для нет: http://www.dotnetmagic.com . Тоже самопал, но давольно высокого качества и с исходниками. Если в этом проекте не использовался бы Win32 API то их качество было бы куда ниже. Как минимум все сильно тормозило бы.

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

Очень даже стоит. Их слишко много.

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

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

VD>А ты что хочешь запускать WinForm-ный код на платформах отличных от Windows?
Думаю это пока нереально.

VD> А тогда о чем речь. Или ты имеешь убожество вроде Swing-а
В каком плане? В плане архитектуры он на порядок лучше WF. В плане быстродействия еще неизвестно с какой скоростью будут работать компоненты на этом тормозном GDI+.

VD> или платформно-зависимый код облаченный в обертку. Я вично не вижу проблем в том, что в библиотеках будет зашит этот код. Зато результат на порядки лучше.
Влад, давай не будем по новой.

VD>Очень даже стоит. Их слишко много.
Вот как раз невозможность отмены sealed и есть заточка под кривые руки. Чтобы по этим рукам надавать когда они лезут куда не следует.

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

IVNС>Но я все-таки ищу легких путей, иначе накакого времени не хватит !

Дык, это никакого времени не хватит искать этих легких путей.

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

AVK>Да. Это как private — если поставили значит доступ извне закрыт. Даже еще хуже, если private ставится по умолчанию, то sealed ставят преднамеренно, когда хотят чтобы ты не смог отнаследоваться.

Вот еще бы компилятор при компиляции выдавал бы окошко с текстом: "А ты хорошо подумал?!".

AVK>Так что все претензии не к языку, а к писателю библиотеки.

Я бы даже сказал, к создателям библиотек. Но от этого не лугче.

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

AVK>Да. Это как private — если поставили значит доступ извне закрыт. Даже еще хуже, если private ставится по умолчанию, то sealed ставят преднамеренно...

Нееее это намного лучше private. Я вон по своему опыту сужу... на сэйлед я плевался раза два, а на private все его жизнть. Так что можно сказаь, что в некотором смысле sealed является обвинительным актом к private.

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

AVK>Ну хорошо, давай твою идею, так сказать разовьем. private,protected,internal мешает программисту?

Нет. Мешает private по умолчанию. Логичнее было бы по умолчанию делать protected.

AVK>Проверка на возврат значение мешает?

Иногда. Можно добавить прагму отключающую ее и ключ компилятора.

AVK> Проверка на инициализацию мешает?

Нет. Причем никогда. Если она делается программистом, компилятор это отслеживает и все пучечком.

AVK> GC мешает?

Иногда. Но если его малость доработать, то и отключать не надо будет (как в предыдущем случае).

AVK>Необходимость обязательной имплементации объявленных интерфейсов мешает?

Мне нет. Делигаты эту проблему снимают очень красиво.

AVK>Дальше продолжать?

Давай.

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

DG>Все-таки лучше было сделать protected & private (особенно private) не жесткими ограничениями...

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

DG>Т.е. по умолчанию, я не могу вызвать protected & private, но если сильно хочу (и отвечаю за свои действия), то могу.

Ну, на асме (или повыпендривавшись с указателями) это и так можно. Но ооочень геморройно и дышит наладом, так как при сдвифке переменной или метода пойдут AV.

Здравствуйте Аноним, Вы писали:

А>А сделать возможность доступа к закрытым полям не так то просто. Очень многое в фреймворке на это заточено. К примеру тот же ремоутинг — в прокси включаются только публичные поля. Вызвать private метод нельзя просто потому что он физически отсутствует в метаданных. И и т.д.

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

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

AVK>если нормально написанная либа

Во-во. Только практика показывает, что MS и Борланд нормально с первого раза писать не умеют. В Дельфи хоть все исходники были...

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

MT>...второй — разрешить, но повесить красную табличку: "если вы используете это, то мы не несём никакой ответсвенности". Для профи второй вариант явно лучше.

Я с тобой полностью согласен. Я бы еще добавил, что желательно делать дефолты так, тобы когда ламер или неряха (вроде меня) гепит по быстрому код, чтобы эти дефолты приводили к минимальному числу проблем, а лучше даже позволяли бы их избегать. Мы же не спорим по поводу того, что контроль типов во время компиляции (если это возможно) лучше аналогичного в рантайме?!

Была бы моя воля я вообще дефолты для private запретил бы. Пусть все думают, что делают!

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

AVK>А почему не сделать так чтобы он без них обошелся.

А ты знаешь как?

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

Кто же заставляет отказыватся от чего-то? Дефолты надо поправить, только и всего.

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

MT>Нато профи и деньги платят, чтоб дурака не валял

А так, известный же закон — за всё надо платить. С другой стороны можно сделать так, чтоб язык поддерживал два уровня: Professional и Expert.

Нодо добавить прагму:

#pragma trust me... knowing i'm do...

Или как там по англицки?

Ну, и после этой прагмы творим что хотим.

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

AVK>Профи как раз не будет пытаться похачить чужой код без исходников. Ибо время — деньги. А то что переписать код проще чем разобраться в чужом (а у нас еще и исходников нет) — давно известный факт.

Ну, попробуй переписать тот же WinForms...

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

IVNС>Это-то есть. Но хотелось типа такого:
IVNС>DateTime d;
IVNС>d.Day = 1;
IVNС>d.Year = 2002;

IVNС>А хрен ! Эти проперти рид-онли. Приходится через парсер_строкИ заполнять.

Так унаследуй свой класс... добавь все что считаешь нужным... напиши доку... и выкладывай на rsdn.

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

VD>>Во-первых, агрегация круче.
IVNС>В чем же преимущества ?

IVNС>Я согласен, что иногда динамическая имплементация может быть полезна. Но ! Во-первых, это несколько другая фича, чем множ. наследование, во-вторых, то, что ты предлагаешь, реализуется в компиляторе как частный случай множественного наследования.

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

IVNС>Так что, наш спор, наверное, не по существу

В таком ракурсе, да. Но самого множественного наследования я бы хотел бы избежать.

IVNС>Чем тебе не нравится множ насл ?

Ошибками, неоднозначностями, тем что убивает идею одного корня и тем самым делает не эффективным всю компонентную сущьность CLR.

IVNС>А вообще никто тебя и не заставляет такое делать

Подобные трюки не являются необходимостью, но иногда полезны. Ничто не должно ограничивать полет фантазии программиста!

А я вообще хочу избежав трюков иметь удобный и эффективный язык.

IVNС>Начать с чего-то надо. Хотя бы с шаблонов и дефолтных параметров функций !!!

Я бы остановился на шаблонах. Без дефолтных параметров функций пока можно пережить.

VD>>К тому же, множественное наследование не поддерживается CLR-ом.

IVNС>не поддерживается CLR-ом, но эмулируется с проблемами, но однозначно.

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

VD>>Реальное МН видимо так и останется только в С++
IVNС>Это от нас зависит !

Нет. Иначе придется написать свою CLR. А это неподемная задача даже если весе посетители сайта будут заниматься ее решением.

Да и нет большой необходимости. Подключение реализций меня бы устроило.

IVNС>Все равно, компилер придется доделывать.

То компилятор, а то всю CLR.

IVNС>Ты начинаешь чувствовать, что предлагаешь всего лишь _нестандартный_вариант_ множ наследования ???

Нет. Это его безопастный подвид.

VD>>Что геморройно? Что некрасиво?
IVNС>Я имею в виду, что если не изменять компилятор, придется лепить кучу лишнего, некрасивого кода, а это никуда не годится.

Так речь и шла об изменении компилятора.

IVNС>А если уж изменять компилятор, нужно уже реализовать _стандартное_, обкатанное еще в прошлом тысячелетии множ. наследование !!!

Большинство светлых умов сходится во мнении, что МН в С++ было проволом. Я так не считаю, но считаю, что если заменить его на подключение реалзиаци, то довольны будут 90% людей и можно будет избежать много геморроя. Кстати, в MC++ МН доступно и сейчас. Просто его нельзя применять для создания CLR-совместимого кода.

IVNС>Обычная агрегация — то, что было до кома

Класс-агрегат содержит в себе переменные, содержащие экземпляры других классов, и не более того

Ну, ды, а я предлагаю вообще осовбодить программиста от этих проблем...

Здравствуйте Аноним, Вы писали:

А>Они даже читать не будут

Мой приятель заботает в фирме-подписчике МСДН. Он несколько раз высказывал M$ конструктивные предложения, на которые они благополучно наплевали.

Дык, у нас вроде были свои люди гдето там.

А>arraylist — все-таки список

Реализован он на обычном массиве, но object-ов. От того и тормозит.

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

Это ерунда по стравнению с боксингом/анбоксингом который происходит при добавлении/извлечении туда/от туда value-нипов.

А>>>, а потом конвертить его обратно в System.Array. Куда это годится ? Почему они забыли про обычный realloc() ?

VD>>Потому, что в природе не существует алгоритмов realloc-а. При realloc-е просто занимается новый массив, данные копируются, а старый освобождается. Такой realloc я и сам за пять минут сворганю. Только он будет еще более медленный чем ArrayList (при условии частого изменения размера массива).

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

Да винда может виделить память размером в 4 кила. И не фига больше. Реалоки всегда создают новый массив и копируют туда содержимое старого.

А>А умные реализации эффективных динамических массивов

А кто тебе говорит о "умных реализациях". Тот же ArrayList использует опережащющее занятие памяти. Вот тольо он с object-ами оперирует и из-за этого тормозит по страшному. А без шаблонов, ну или хотябы на худой конец #includ-а сделать реализации для каждого типа слишком сложно.

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

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

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

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

А>Если много удалений — конечно, лучше аррэйлист, тем более, что адреса элементов там кешируются (нет поиска при обращении к элементу, ф смотрел в исходниках)

Блин ты что действительно считашь что ArrayList на не на обычном массиве сделан? Залезь глянь исходники. Там внути обычный массив. И вставки в начало там так же не эффективны как и в обычном массиве. Правда в обычный массив вообще уставлять ничего нельзя... только помещать в имеющуюся ячейку и сдвигать все остальное. Дык внутри ArrayList делает тоже самое.

А>В-третьих, System.Array реализован с использованием ComArray, который, естественно, создается динамически.

Ты полностью неправ. Возьми исходники и убедить в своеей не правоте сам.

А>Так что ты согласен, что разумно было бы сделать такой массив системным ?

Ничего не понял.

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

AVK>>Да. Это как private — если поставили значит доступ извне закрыт. Даже еще хуже, если private ставится по умолчанию, то sealed ставят преднамеренно, когда хотят чтобы ты не смог отнаследоваться.

VD>Вот еще бы компилятор при компиляции выдавал бы окошко с текстом: "А ты хорошо подумал?!".

А толку то — ты всерьез полагаешь что влазя в приватные поля чужой библиотеки, или наследуясь и подсовывая затем свой класс без ее исходных кодов ты можешь предусмотреть все возможные глюки?

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

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

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

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

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

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

Зачем?

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

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

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

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

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

#pragma Take that fucking compiler away from my clumsy hands

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

VD>Дык, у нас вроде были свои люди гдето там. :)
Они так же не шевелятся.

VD>Это ерунда по стравнению с боксингом/анбоксингом который происходит при добавлении/извлечении туда/от туда value-нипов.
Да, но тут ничего не поделаешь, пока нет темплейтов.

VD>Да винда может виделить память размером в 4 кила. И не фига больше. Реалоки всегда создают новый массив и копируют туда содержимое старого.
Ну да, постраничное выделение никто не отменял.Но вот перемещение блоков вовсе не всегда происходит. Смысл тусовать память, если не изменился адрес ?

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

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

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

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

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

А>>В-третьих, System.Array реализован с использованием ComArray, который, естественно, создается динамически.
VD>Ты полностью неправ. Возьми исходники и убедить в своеей не правоте сам.

Смотрю.Не полностью.
Блин, ну и реализация у этого ArrayList ...
System.Array работает с использованием класса COMArrayInfo, написанного на с++. Поскольку ArrayList использует System.Array, разумно было бы предположить, что ресайз они реализовали именно в COMArrayInfo. Но ни хрена ! Они при каждой вставке тупо вызывают Array.Copy ... Ну, M$, 5 баллов. Список с кэшированием элементов, блин :maniac:
Какого они это чудо вообще списком назвали- непонятно. :(((

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

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

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

AVK>>Да. Это как private — если поставили значит доступ извне закрыт. Даже еще хуже, если private ставится по умолчанию, то sealed ставят преднамеренно, когда хотят чтобы ты не смог отнаследоваться.

VD>Вот еще бы компилятор при компиляции выдавал бы окошко с текстом: "А ты хорошо подумал?!". :)

Да не. Вот это уже излишне. Достаточно, чтоб компилер выдавал ворнинг уровня 1 или 2. А то запаришься при каждой компиляции окошко закрывать :)

А вот насчет режима компилятора, который разрешает наши новые фичи — здравая идея.
Причем, это надо реализовать в виде опции компилера. Прагмой не получится — ее в шарпе нет :) , хотя было бы разумнее ее в каждом файле выписывать. Хотя, и прагму мона добавить, это как раз легче всего :)

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

VD>Так унаследуй свой класс... добавь все что считаешь нужным... напиши доку... и выкладывай на rsdn. ;)

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

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

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

VD>Не совсем так. Множественное наследование вещь статическая. Агрегация динамическая. Но наверное статическая реализация тоже нужно. Это ведь скорее всего окажется эффективнее. Да и можно будет реализовывать невиртуальные функции, т.е. реализация как таковая не интерфейса, а просто некой фичи.

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

IVNС>>Чем тебе не нравится множ насл ?

VD>Ошибками, неоднозначностями, тем что убивает идею одного корня и тем самым делает не эффективным всю компонентную сущьность CLR.
Весь смысл в том, наследование долно производиться от замкнутых классов, реализующих _разную_ функциональность. Тут все зависит от продуманности иерархии классов. Например, WTL. Как удобно там, например, получить диалог с ресайзом контролов, хостингом эктивиксов, DDX-ом, наследуя класс диалога от CDialogResize, CAxDialogImpl, CWinDataExchange. Абсолютно безглючно, удобно, а, главное, изначально не замешано в одном базовом классе. Добавляешь только то, что нужно.
Вот если ты еще отнаследуешься от CDialogImpl, который реализует то же, что CAxDialogImpl — получится черт_и_что. Ну дык кто в таком случае виноват ? :)

Причем в данном случае динамическая имплементация АБСОЛЮТНО не нужна.
И компонентная сущность CLR вовсе не пострадает, если думать, что пишешь. Тем более, что в динамической реализации нехуже напутать можно.
Так что, множ наследование нужно _однозначно_

IVNС>>Начать с чего-то надо. Хотя бы с шаблонов и дефолтных параметров функций !!!

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

VD>>>Реальное МН видимо так и останется только в С++
IVNС>>Это от нас зависит ! :)

VD>Нет. Иначе придется написать свою CLR. А это неподемная задача даже если весе посетители сайта будут заниматься ее решением. :( Да и нет большой необходимости. Подключение реализций меня бы устроило.

Переписывать CLR глупо — тяжело и ненужно, и обратно-несовместимо. Все, что в CRL имеется, достаточно, чтоб реализовать то, что мы хотим.

IVNС>>Ты начинаешь чувствовать, что предлагаешь всего лишь _нестандартный_вариант_ множ наследования ??? :)

VD>Нет. Это его безопастный подвид.
Вот именно, что подвид. Обрезанный вариант в динамической форме. Много ли ты приведешь примеров, где _нельзя_ обойтись без динамической реализации ???? Не думаю. Может, просто получше продумать иерархию классов ?
К тому же можно обычное наследование реализовать с ограничениями / предупреждениями, которые не позволят программисту сделать глюки, которых ты так боишься. При этом будет использован _стандартный_ синтаксис, никаких атрибутов.

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

AVK>А толку то — ты всерьез полагаешь что влазя в приватные поля чужой библиотеки, или наследуясь и подсовывая затем свой класс без ее исходных кодов ты можешь предусмотреть все возможные глюки?

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

Да и шуток не понимаешь.

Здравствуйте 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>Если можно, что-то не делать, то нужно это не делать. ;)
Да ладно, чего там, не буду пока :)

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>Да... живешь ты далековато... И вредничаешь больше меня.

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

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

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

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

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

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

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

А у меня вредности это просто УХ!

AVK>А ты знаешь что хелп по платформе не Борландом писан а просто взят у MS? Так что претензии к MS.

Не просто взят, а переделан в формат .hlp с потерей качества (т.е. contents'a).
Переделан чёрти в каком лохматом году и с тех пор не обновлялся, так и идёт от версии к версии всё больше устаревая. Видать сама Борланд поняла, что всё равно никто этим уродством не пользуется, так нечего и ж..у рвать.
Да и свой собственный дельфийский хелп абсолютно ублюдочный. Как-то я два часа искал функцию-обёртку для SHBrowseForFolder... наткнулся чисто случайно. В msdn это бы заняло минуту.

VD> В Дельфи хоть все исходники были...

Ой-ли? Если бы все... Парочки файлов там не хватало. Т.е. скомпилить ничё незя было. Близок локоть — да не укусишь. Видишь глюк — да не исправишь.

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

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

Если так дело пойдет, то в России за пределами Москвы и Питера вообще программистов не останится.

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

AVK>А как же

Ну, вообще-то это довольно редкое явление.

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

http://www.optim.ru/Software/rus/newsoft.asp + http://www.optim.ru/cs + http://www.rsdn.ru/mag/main.htm

Здравствуйте Аноним, Вы писали:

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

Вообще-то в последнее время с выходом ХотСпота она стала значительно быстрее и класс задач где она может применяться сильно расширился. Ну, а для общего развития изучить ее концепции вообще полезно.

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

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

проект на rsdn-е...

VD>>Второе? Ну, наверно по этому поводу нужно писать статьи, раз из книг не ясно.
А>Да у меня вообще проблем нет в этом плане

Я просто связанный список всегда называл списком, а массив — массивом, только и всего. Так логичнее.

Не логичнее. Но проще. Хотя в первом случае ты несколько частно подходил к понятию.

А>Опять же, это не принципиально

Термины есть термины иначе можно год спорить подразумевая под одним термином разные вещи.

А>Статей не надо

И без них уже все отлично написано и работает

С ними обычно работает быстрей и надежней.

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

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

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

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

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

Всех с рсдн-а мы конечно взять не сможим, но возможно в сентябре нам понадобится один дополнительный программист. Единственное 900-1000 это у нас предел, и для этого нужно немало знать и уметь. А ты, кстати, где живешь?

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

AVK>>А ты знаешь что хелп по платформе не Борландом писан а просто взят у MS? Так что претензии к MS.

Z2>Не просто взят, а переделан в формат .hlp с потерей качества (т.е. contents'a).

Это исходная версия. Тогда (это чтото оголо 1995-1996 года) .hlp был единственным форматом.

Z2>Переделан чёрти в каком лохматом году и с тех пор не обновлялся, так и идёт от версии к версии всё больше устаревая. Видать сама Борланд поняла, что всё равно никто этим уродством не пользуется, так нечего и ж..у рвать.

Их тогда послали на ... по поводу включения MFC в их продукты. Предложили лицензировать. Видимо с MSDN и PSDC та же история. К тому же если Борланд начнет свежий хелп класть, то им же придется все PSDK отслеживать.

Z2>Да и свой собственный дельфийский хелп абсолютно ублюдочный. Как-то я два часа искал функцию-обёртку для SHBrowseForFolder... наткнулся чисто случайно. В msdn это бы заняло минуту.

Ты видимо не видел хелп от Delphi 2! Вот это был ублюдок так ублюдок! А искать у них нужно не по хелпу, а по исходникам. Так и проще и эффективнее.

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

VD>Всех с рсдн-а мы конечно взять не сможим, но возможно в сентябре нам понадобится один дополнительный программист. Единственное 900-1000 это у нас предел, и для этого нужно немало знать и уметь. А ты, кстати, где живешь?

Так живу я в Ирландии. Но как только меня отсюда выпрут поеду в Москву. Так что, можно сказать, заранее ищу куда соломинки подстелить

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

MT>Так живу я в Ирландии. Но как только меня отсюда выпрут поеду в Москву. Так что, можно сказать, заранее ищу куда соломинки подстелить

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

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

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

Флоридскую. Попрошу не путать.

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

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

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

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

VD>Ну, дык вроде даже народ собирается по этому поводу открыть открытый :) проект на rsdn-е...

Нет его. И те, кто вроде хотел, уже не показываются :(

VD>Термины есть термины иначе можно год спорить подразумевая под одним термином разные вещи.
Угу :)))

А>>Статей не надо :) И без них уже все отлично написано и работает

VD>С ними обычно работает быстрей и надежней. ;)
Я считаю, что хорошая статья всегда полезна. Но разжевывать то, что до нас писалось неоднократно — бессмысленно, лучше что-нибудь более полезное сделать :) Времени всегда не хватает.

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

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

Буду и постараюсь

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

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

В яве 90% это библиотеки. Там без них вообще ничего поутного сделать нельзя. Это на С++ все самому можно...

VD>>Ну, дык вроде даже народ собирается по этому поводу открыть открытый :) проект на rsdn-е...

IVNС>Нет его. И те, кто вроде хотел, уже не показываются :(

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

VD>>Термины есть термины иначе можно год спорить подразумевая под одним термином разные вещи.
IVNС>Угу :)))

А>>>Статей не надо :) И без них уже все отлично написано и работает
VD>>С ними обычно работает быстрей и надежней. ;)
IVNС>Я считаю, что хорошая статья всегда полезна. Но разжевывать то, что до нас писалось неоднократно — бессмысленно, лучше что-нибудь более полезное сделать :) Времени всегда не хватает.

Я вот тоже думал, что списки и варианты их реализации — это классика, но ты сам меня в этом рзубедил.

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

VD>В яве 90% это библиотеки. Там без них вообще ничего поутного сделать нельзя. Это на С++ все самому можно...

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

Надо же ! Не думал ! Все-таки взялись ! Молодцы ! Я готов тоже внести свое посильное участие.

VD>Я вот тоже думал, что списки и варианты их реализации — это классика, но ты сам меня в этом рзубедил.

:))) Все-таки, любое обсуждение — вещь однозначно полезная :)

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

VD>>В яве 90% это библиотеки. Там без них вообще ничего поутного сделать нельзя. Это на С++ все самому можно...

VD>>Народ просто перешел к реализации задуманного. У рсдн есть скрытая конференция гед и обуждаются все эти вещи. Если ты хочешь присоедениться к проекту, то могу сказать, чтобы тебя тоже призвали на службу отечеству.

IVNС>Надо же ! Не думал ! Все-таки взялись ! Молодцы ! Я готов тоже внести свое посильное участие.

IT! Обясни товарищу как можно подключится к группе. Или как мы будем эти самые проекты развивать?

VD>IT! Обясни товарищу как можно подключится к группе. Или как мы будем эти самые проекты развивать? :???:

Спасибо, VladD2, спасибо, IT. Я скоро буду в деле.

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

VD>IT! Обясни товарищу как можно подключится к группе. Или как мы будем эти самые проекты развивать?

Влад, я наверно крепко спал

вы где там группу успели организовать

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

VD>>IT! Обясни товарищу как можно подключится к группе. Или как мы будем эти самые проекты развивать?

MT>Влад, я наверно крепко спал

вы где там группу успели организовать

До тебя не доходят яховские сообщения?

... Информация очень простая зачиньщиками было обещано создать кратенькое описание... название вроде уже даже придумали... Но сам понимаешь у все есть свои дела (пьянки, бабы, драки...).

VD>До тебя не доходят яховские сообщения?

VD>... Информация очень простая зачиньщиками было обещано создать кратенькое описание... название вроде уже даже придумали... Но сам понимаешь у все есть свои дела (пьянки, бабы, драки...). :)

Влад, ничего, наверное, еще не сделано :( Кроме небольшого обсуждения, (в котором, кстати, предлагается присоединиться к данному форуму :) ), я больше ничего не увидел. Да и неудобный этот яху, нет разделения по темам. Рыться надо, чтоб все мессаги одного обсуждения найти. Кроме того, как я понимаю, ваш закрытый форум на то и был закрытым, чтоб обсуждать вопросы, связанные с журналом и внутренними проблемами сайта. Я думаю, что _обсуждение_ лучше продолжить здесь (поддерживаю людей, говоривших об этом в яху), а открытый проект пусть лежит на яху, для избранных :) Пусть всезнающий олл конструктивно высказывается !

Я чувствую, что если я не возьму координацию этого дела в свои руки, никто дальше даже чухаться не будет !

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

IVNС>Влад, ничего, наверное, еще не сделано

Кроме небольшого обсуждения, (в котором, кстати, предлагается присоединиться к данному форуму

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

Пусть всезнающий олл конструктивно высказывается !

Я ж предлагал орагнизовать отдельную ветку для проекта, предлагал. Да хоть бы и форум новый открыть, специально для этого дела, уже дело бы сдвинулось. Вопросов уйма, обсудить всё надо. Вот в форуме и пообсуждаем. А если потом ничего не выйдет грохнем форум и концы в воду, а если получиться, то перенесём форум в форум проекта.

IVNС>Я чувствую, что если я не возьму координацию этого дела в свои руки, никто дальше даже чухаться не будет !

Верно говоришь

Я б занялся, да только вот карьеру тоже надо делать иногда

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

VD>... Информация очень простая зачиньщиками было обещано создать кратенькое описание... название вроде уже даже придумали... Но сам понимаешь у все есть свои дела (пьянки, бабы, драки...).

Да я-то начал писать, а потом подумалось, вот сделаю всё как я вижу, разнесёте всё в пух и прах, а я человек тяжёлый...

Так что давай-те ка отдельный форум хоть на пару недель откроем, чтоб всё обсудить и родить некий документ, с которого всё и начнём.

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

IVNС>Влад, ничего, наверное, еще не сделано

Кроме небольшого обсуждения, (в котором, кстати, предлагается присоединиться к данному форуму

Пусть всезнающий олл конструктивно высказывается !

Ну, ты на нашу яху не шли напраслину. Ее просто фильтровать не нужно.

Читай себе... и отвечай если нужно.

IVNС>Я чувствую, что если я не возьму координацию этого дела в свои руки, никто дальше даже чухаться не будет !

Это всегда пожайлуста. Мне вот например, сейчас даже чихнуть некогда.

После лета возьмемся по шибче...

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

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

VD>>... Информация очень простая зачиньщиками было обещано создать кратенькое описание... название вроде уже даже придумали... Но сам понимаешь у все есть свои дела (пьянки, бабы, драки...).

MT>Да я-то начал писать, а потом подумалось, вот сделаю всё как я вижу, разнесёте всё в пух и прах, а я человек тяжёлый...

Мы разносим только для дела. Сформулировать идеи наврено все же нужно. А то люди даже не поймут, что за форум (?).

MT>Так что давай-те ка отдельный форум хоть на пару недель откроем, чтоб всё обсудить и родить некий документ, с которого всё и начнём.

Это к IT. Он главный форумооткрыватель.

Господа, прошу прощения за долгое отсутствие. Очень у меня много работы сейчас :(
Желание доделать компилятор все еще имею, но сильно уж многое сейчас на меня навалилось :( К тому же я сейчас в гордом одиночестве (уехал в командировку мой приятель, на помощь которого я надеялся)

Что мной уже сделано — коряво и недоделочно привинчены параметры к функциям по умолчанию. Даже реализация такой простой вещи требует усилий :) Как приведу это дело в надлежащий вид, выложу на всеобщее обозрение, глядишь, у кого-нить интузиазм появится, и присоединится.
С множ. наследованием сложновато получается. Я прихожу к мысли, что нужно начать с его урезанной реализации (без полиморфизма, виртуальных базовых классов и т.д.)
Но то, что реализовать м.н. можно — факт, основанный на изучении мной MSIL и исходников компилера. Хотя за это еще никто не брался, даже M$ :) Но, как говорил Влад, мы легких путей не ищем :)

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

Здравствуйте IVaNС,

IVNС>В общем, разгребу свою работу, и тогда открою форум и открытый проект. Я надеюсь, что никто на меня не обидится за такую задержку.

Никто не обидиться. Если не влом, то напиши ещё короткое описание проекта, чтоб народ примерно понимал о чём речь пойдёт.

http://www.rsdn.ru/forum/newmsg.asp?mid=74132

M.NET>Если не влом, то напиши ещё короткое описание проекта, чтоб народ примерно понимал о чём речь пойдёт.

Хорошо.
Микрософт написал — "цшарп — прост как VB, силен как C++". Наврали. От васика шарпец недалеко ушел

Так вот, мы это хотим исправить, доделать компилятор C# до уровня C##. _Не_предполагается_ переписывать фреймворк и системные библиотеки. Это уж слишком радикально !
Исходники — "ротор" от микрософта. Исходники компилера обрезанные (он не компиляет ресурсы, придется родным компилером для этих целей пользоваться)
Прежде всего хочется добавить:
1)дефолтные параметры методов. Запаривает выписывать по нескольку одинаковых методов. До недавлего времени я поступал так: писал метод, сожержащий все параметры, и кучу других, вызавающих его с определенными параметрами. Некрасиво и извратно. Так что дефолтные параметры нужны, с этого я и начал. Очень удобно

2)тэмплэйты. Господин TK нашел полезную ссылу http://research.microsoft.com/projects/clrgen/
Там конкретно проработана реализация тэмплэйтов для дотнета в болтологической форме. Там убедительно, с примерами, продемонстрировали, что с тэмпелэйтами круче

Я с господами, которые это понаписывали, пытался связаться, пока безуспешно. Еще напишу.
3)самое главное и трудное — множественное наследование
4)макроопределения
5)модификаторы доступа к членам классов сделать по умолчанию protected
6)очень спорный вопрос — отмена модификаторов доступа типа sealed, private и т.д.

И т.д. Читайте форум, высказывайтесь, господа (и дамы, если это интересно) ! Обсуждение не закончено, оно, фактически, только начато

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

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

Вообще, мне казалось, что CLI — довольно жесткая вещь.. там же совершенно четкие структуры метаданных и уж коль не предусмотрено "параметров по умолчанию" — то как их можно доделать???

Единственное, что приходит в голову — компилятор генерящий методы с разными комбинациями не-дефолтных параметров на основе одного метода с дефолтными параметрами.... Или как?

Кстати, мне, например, очень не нравится то, что у класса-потомка нужно дублировать все конструкторы предка, чтобы они были... Ну, то есть отсутствие наследования конструкторов... Может, и тут можно что-то придумать? ;)

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

IT>Вообще, мне казалось, что CLI — довольно жесткая вещь.. там же совершенно четкие структуры метаданных и уж коль не предусмотрено "параметров по умолчанию" — то как их можно доделать???

IT>Единственное, что приходит в голову — компилятор генерящий методы с разными комбинациями не-дефолтных параметров на основе одного метода с дефолтными параметрами.... Или как?

Если не ошибаюсь, в голову MS-программистов пришло пометить дефолтные параметры атрибутами. В MSDN даже была статья (ссылку не дам) касказывающая как читать или задавать дефолтные параметры из C#.

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

IVNС>Микрософт написал — "цшарп — прост как VB, силен как C++". Наврали. От васика шарпец недалеко ушел

Ну, тут ты палку круто перегнул.

Или имелось в виду от VB.Net?

IVNС>2)тэмплэйты. Господин TK нашел полезную ссылу http://research.microsoft.com/projects/clrgen/
IVNС>Там конкретно проработана реализация тэмплэйтов для дотнета в болтологической форме. Там убедительно, с примерами, продемонстрировали, что с тэмпелэйтами круче

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

Можно попытаться сделать это через русское представительство MS. Вероятность тоже не большая, но все же больше чем ничего.

PS

Проблема только в том, что у зачинщиков все больше и больше пропадает интузиазм.

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

IT>Здравствуйте IVaNС, Вы писали:
IT>Вообще, мне казалось, что CLI — довольно жесткая вещь.. там же совершенно четкие структуры метаданных и уж коль не предусмотрено "параметров по умолчанию" — то как их можно доделать???

Предусмотрено. Я подсмотрел в васике. В книге, к сожалению, плохо эти вещи документированы, но они есть

Для деф. параметров исп-ся метаданные метода — opt

IT>Единственное, что приходит в голову — компилятор генерящий методы с разными комбинациями не-дефолтных параметров на основе одного метода с дефолтными параметрами.... Или как?

Не. все куда проще. Для метода с дефолтным параметром
void DoSome(string sName = "sdfdf") {
.......
}

пишешь (на асме, ясное дело) типа такого

.method public instance void  DoSome([opt] string sName) cil managed
{
  .param [1] = "sdfdf"

   .......

}

Это большая часть того, что надо

У меня кой-какие трудности возникли из-за того, что я пошел чуть дальше, чем позволено синтаксисом C++ — я реализовал возможность _пропуска_ дефолтного параметра, и сделал необязательным условие, что после появления описания одного дефолтного параметра должны следовать только дефолтные параметры. То есть, имеем метод void DoSome(string s1, string s2 = "s2", string s3)
В моем синтаксисе допустимо писать такой вызов: DoSome("s1", , "s3");
То есть, для того, чтоб указать третий параметр, не нужно указывать второй, который будет взят по дефолту.

IT>Кстати, мне, например, очень не нравится то, что у класса-потомка нужно дублировать все конструкторы предка, чтобы они были... Ну, то есть отсутствие наследования конструкторов... Может, и тут можно что-то придумать?

Можно, ясное дело

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

Вот с реализацией остального — похужей будет. Особенно с множ. наследованием. Компилер конкретно калечить придется

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

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

IVNС>>Микрософт написал — "цшарп — прост как VB, силен как C++". Наврали. От васика шарпец недалеко ушел

VD>Ну, тут ты палку круто перегнул.

Или имелось в виду от VB.Net?

Да не, вроде не перегнул

Хотя, ясен пень, от VB.Net

Совсем недавно мне захотелось перевести один порядочно большой проект с VB.Net на шарп. Никаких трудностей не возникло — написал небольшой макрос, который подменяет языковые конструкции васика на шарповые. Практически ничего ручками не пришлось править

Да и у VB.Net есть кой-какие приколы, отсутствующие в шарпе. Так что, если бы не кривой с точки здения потомственного сишника синтаксис (ну воротит меня от васика, Васиковцы, не обижайтесь

), можно было бы сказать, что васик в чем-то помощнее будет.

IVNС>>Там конкретно проработана реализация тэмплэйтов для дотнета в болтологической форме. Там убедительно, с примерами, продемонстрировали, что с тэмпелэйтами круче

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

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

Можно им сказать, что есть люди, готовые бесплатно поучаствовать ради торжества науки

VD>PS

VD>Проблема только в том, что у зачинщиков все больше и больше пропадает интузиазм.

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

Я и так сейчас без выходных работаю

IVNС>пишешь (на асме, ясное дело) типа такого

IVNС>[asm]
IVNС>.method public instance void DoSome([opt] string sName) cil managed
IVNС>{
IVNС> .param [1] = "sdfdf"

Ну, если есть [opt] — тогда другое дело... Странно, из каких соображений они не включили дефолтные пар-ры в C#. Совсем непонятно.

IVNС>В моем синтаксисе допустимо писать такой вызов: DoSome("s1", , "s3");
IVNС>То есть, для того, чтоб указать третий параметр, не нужно указывать второй, который будет взят по дефолту.

Ну, это, имхо, не очень красиво...

Кстати, а не является ли сабж философским? Если да, то хотелось бы его видеть в соотв. форуме.

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

IVNС>>В моем синтаксисе допустимо писать такой вызов: DoSome("s1", , "s3");
IVNС>>То есть, для того, чтоб указать третий параметр, не нужно указывать второй, который будет взят по дефолту.

IT>Ну, это, имхо, не очень красиво...

Почему ? Кстати, кроме того, я ввел специальное ключевое слово defparam, если не хочется оставлять пропуски (все-таки, они ухудшают читабельность)

Здравствуйте Anton V. Kolotaev, Вы писали:

AVK>Кстати, а не является ли сабж философским? Если да, то хотелось бы его видеть в соотв. форуме.

Пока не реализовано, является. Так что, создавай топик.

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

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

AVK>>Кстати, а не является ли сабж философским? Если да, то хотелось бы его видеть в соотв. форуме.

IVNС>Пока не реализовано, является. Так что, создавай топик.

А может просто замодерировать его туды?

IT>>Ну, это, имхо, не очень красиво...
IVNС>Почему ? Кстати, кроме того, я ввел специальное ключевое слово defparam, если не хочется оставлять пропуски (все-таки, они ухудшают читабельность)

Ну вот сам и ответил — почему

Еще может удобным был бы синтаксис DoSome (Value1, Value2, DefParam1 = Value3, DefParam5 = Value4), но только тут смысл двоится — то-ли параметру задаешь знаечение, то ли локальной пеерменной... напутать можно.

Здравствуйте Anton V. Kolotaev, Вы писали:

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

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

IVNС>>Пока не реализовано, является. Так что, создавай топик.

AVK>А может просто замодерировать его туды?

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

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

IVNС>>Почему ? Кстати, кроме того, я ввел специальное ключевое слово defparam, если не хочется оставлять пропуски (все-таки, они ухудшают читабельность)

IT>Ну вот сам и ответил — почему

Вовсе не ответил

IT>Еще может удобным был бы синтаксис DoSome (Value1, Value2, DefParam1 = Value3, DefParam5 = Value4), но только тут смысл двоится — то-ли параметру задаешь знаечение, то ли локальной пеерменной... напутать можно.
Да ну, это ты предложил изврат какой-то

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

IT>>Ну вот сам и ответил — почему

IVNС>Вовсе не ответил

Ну как же? Действительно
DoSome(123, "abc", defparam, true) выглядит лучше, чем
DoSome(123, "abc", , true)

IT>>Еще может удобным был бы синтаксис DoSome (Value1, Value2, DefParam1 = Value3, DefParam5 = Value4), но только тут смысл двоится — то-ли параметру задаешь знаечение, то ли локальной пеерменной... напутать можно.
IVNС>Да ну, это ты предложил изврат какой-то

Ну вот еще сравниваем
SaveToFime(FileName, defparam, defparam, defparam, defparam, true, defparam, defparam)
и
SaveToFime(FileName, SaveAsUnicode = true)

Что читабельнее?

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

IT>>Ну вот еще сравниваем
SaveToFime(FileName, defparam, defparam, defparam, defparam, true, defparam, defparam)
и
SaveToFime(FileName, SaveAsUnicode = true)

IT>>Что читабельнее?

Читабельнее, вроде бы как, второе. Но 1)в моем случае я при прописывании вызова метода пользуюсь IntelliSence, а, поскольку позиции параметров фиксированы, я сразу вижу, что данный defparam представляет дефолтное значение определенного параметра.
2)ты предлагаешь реализовать непозиционное указание параметров методов. Нечто немного похожее уже реализовано — при указании атрибутов можно устанавливать переменные атрибута именно таким образом (вне конструктора, конечно —
[SaveToFime(FileName), SaveAsUnicode = true])
Подход при нумерации defparam не годится, потому что при добавлении еще одного параметра в метод вся нумерация летит к черту.

Можно сделать вот что: ввести еще одно ключевое слово — param.

SaveToFime(FileName, param.SaveAsUnicode = true)

Фактически, это ключевое слово представляет собой структуру. Кстати, это кл. слово поможет при разрешении конфликтов имен параметров и переменных
Представь себе:

class Class1 {
  string s1;
  void DoSome(string s1, string s2 = "bgbfgf") {
     // local s1
     string s1;
     // local s1 = param s1
     s1 = param.s1;
     // class member s1 = local s1
     this.s1 = s1;
  }
}

По-моему, неплохо. Единственное — компилер должен ругаться, если встретит в одной строке после описания первого непозиционного параметра позиционный, или слово defparam.

Получается очень гибко и красиво.

	От:	IVaNС
	Дата:	13.06.02 07:42
	Оценка:

	От:	Mishka<T>
	Дата:	13.06.02 08:35
	Оценка:	9 (1)

От:	Nikita Dolgov	http://nikitadolgov.narod.ru/
Дата:	13.06.02 09:04
Оценка:

От:	TK	кывт.рф
Дата:	13.06.02 09:36
Оценка:

	От:	Аноним
	Дата:	13.06.02 10:09
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	14.06.02 23:16
Оценка:

От:	IT	linq2db.com
Дата:	16.06.02 04:07
Оценка:	6 (1)

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	16.06.02 06:46
Оценка:

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	17.06.02 09:13
Оценка:	6 (1)

	От:	Anton V. Kolotaev
	Дата:	19.07.02 06:00
	Оценка:

	От:	Silver_s
	Дата:	15.06.02 11:30
	Оценка: