Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alexkro, Вы писали:
AVK>>>Зачем мне PDC-шные слайды если у меня PDC-шный видби есть.
A>>А за тем, что в Whidbey PDC еще нет тех изменений, которые будут в релизе Whidbey C++.
AVK>Очень сомнительно. Тем более что про дату выхода C++/CLI где то упоминалось что в мае 2004 только появиться первая альфа. В это время у Видби во всю будет идти бета-тестирование, а следовательно никаких серьезных изменений не будет.
Здравствуйте, AndrewVK, Вы писали:
AVK>Тебе и сейчас ничего не мешает. В базовом Stream реализованы только асинхронное чтение/запись и ReadByte/WriteByte, которые по сути просто обертки над Read/Write.
Нет батенька, базовая абстракция отсуствует и я уже не могу делать "чистые" реализации. Грамотнее было бы ввести интерфейс, а в Stream реализовать некоторые его методы.
VD>>Например, можно было бы Сделать обертку над КОМ-овским IStream-ом.
AVK>Оно и сейчас вроде как можно.
Сейчас я вынужден отталкиваться от имеющейся реализации.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
S> А зачем дизасемблером в роторе есть исходники и реализуют он только ассинхронные вызовы.
Да по фигу. Можно и в Роторе.
VD>>С другой стороны то, что нет IStream — это явный промох дизайна. Что поделаешь? Драли с ранних версий Явы.
S> Если объект создан от Stream то передавай его целиком. Если же нужна другая функциональность то просто внедряется класс наследник от Stream и делается импликит на него.
В общем, ты так и не понял.
VD>>Наличие IStream позволило бы другим делать реализации стрима координально отличные от Stream. Например, можно было бы Сделать обертку над КОМ-овским IStream-ом. S> Ком это прошлый век и не стоит на него оборачиваться, а для совместимости с ним в Delphi например есть классы хэлперы TStreamAdapter и TOleStream.
Я тебе говорю о дизайне. Все эти TOleStream — это реализации. Обстракция же одна.
S> Еще раз повторю интерфейсы нужны только для расширения функциональности где простого наследования не хватает. Представь если бы все наследники от Component были реализованы чере IComponent.
А я тебе еще раз повротрю, что интерфейсы — это средство дизайна. И смотреть на них так примитивно не стот.
S> Большое спасибо за совет. Тот же Рихтер говорит, что абстрактные классы предпочтительней там где есть явное наследование и предпочтитель интерфейсы где это невозможно.
Рихтер никогда не занимался дизайном. Он описывает технологии. Наследование же может пригодиться для других целей. Не факт, что не потребуется реализовать поведение описнное в товем абстрактом классе в классе который следовало бы сделать произовдным от другого класса.
Посмотри на коллекции в дотнете. Они все реализуют стандартные интерфейсы.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Очень сомнительно. Тем более что про дату выхода C++/CLI где то упоминалось что в мае 2004 только появиться первая альфа. В это время у Видби во всю будет идти бета-тестирование, а следовательно никаких серьезных изменений не будет.
По слухам на PDC показывали версию более-менее поддерживающую эти фичи. Даже эта версия поддерживает чуть-чуть (тот же ^). Так что совершенно реально, что в бэте как раз появится чистично-реализованный C++/CLI.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Посмотри на коллекции в дотнете. Они все реализуют стандартные интерфейсы.
Влад в Моем случае только 2 уровня самый нижний и верхние. Зачем мне там интерфейсы????
Кроме всего прочего кастомный предок имеет общие поля которые легче описать в базовом классе. А поле Child имеет кастомный вид. Эти два вспомогательныз класса больше нигде не будут использоваться кроме их публичного владельца. А уж в приватных классах я как хочу так и ворочу.
По поводу TStreamAdapter он просто оболочка доступа к Stream через интерфейс IStream. Т.К. IStream нужен в СОМ Нужен для совместимости. Хотя классы Delphi и C++ могут использовать абстрактные классы во всяком случае в Delphi 3.
Но абстрактные классы и Интерфейсы не одно и то же.
Ты бы лучше разъяснил разницу интерфейсов в Net и COM. Во всяком случае в Вашем же журнале была статья про интерфейсы и там четко написано, что интерфейсы это ссылка на VMT а в ней хранятся ссылки на функции оболочки которые помоему в EAX запихивают адресс объекта забитый в них и вызывают реальные функции объекта.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Влад в Моем случае только 2 уровня самый нижний и верхние. Зачем мне там интерфейсы????
Ты делаешь реализацию общего алгорима/струкутры данных. Сделать человеческий интерфейс в данном случае просто необходимо.
Такие вщи тяжело обяснять. Нужно прочуствовать к чему ведет обратный подход.
S> Кроме всего прочего кастомный предок имеет общие поля которые легче описать в базовом классе.
Содай интерфейс и унаследуй от него абстрактый класс реализующий нужные методы.
Как миниум тот кому будет нужно сможет сделать чистую реализацию так как он считает нужным.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
VD>Как миниум тот кому будет нужно сможет сделать чистую реализацию так как он считает нужным.
Может я уже плох совсем но зачем internal классам интерфейсы и интрнальные интерфейсы???? Ведь их никто не видит.
Единственно что мне не хватает в Net это видимости NameSpace, а там уж как хочу так и ворочу.
А вот кому нужно сделать чистую реализацию ( в чем в данном случае я сильно сомневаюсь, что кому то это понадобиться) пусть поступает как я — все переписываю под себя, и практически только очень тяжеловесные классы не трогаю, да и то добавляю нужную функциональность дописывая и изменяя исходники, там где простым наследованием сделать это невозможно.
А сделать класс реализующий аналогичный интерфейс на базе внедренного объекта недолго как тот же TStreamAdapter. Но в данном случае это совсем ненужно и приводить класс к интерфейсу вместо передачи собсвенно класса, так как он является наследником от обявленного.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Может я уже плох совсем но зачем internal классам интерфейсы и интрнальные интерфейсы????
А почему они должны быть интернал? Их как раз очень даже полезно публичными делать. А для дженериков вообще очень удачным решением является использование интерфейсов, так как тогда можно делать ручные специализации.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
VD>>Как миниум тот кому будет нужно сможет сделать чистую реализацию так как он считает нужным.
S> Может я уже плох совсем но зачем internal классам интерфейсы и интрнальные интерфейсы????
А кто говорил про internal интерфейсы? Суть в том что ты предоставляешь свой класс, реализующий вобщем то обобщенную функциональность без какой либо возможности заменить его на свою реализацию, что есть кривой дизайн. Базовый класс вполне может быть internal, но вот интерфейс обязательно должен быть паблик.
S> А вот кому нужно сделать чистую реализацию ( в чем в данном случае я сильно сомневаюсь, что кому то это понадобиться)
Ты в принципе не можешь этого знать и надеяться на подобное по меньшей мере самонадеянно.
S>пусть поступает как я — все переписываю под себя,
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AndrewVK, Вы писали:
AVK>>Тебе и сейчас ничего не мешает. В базовом Stream реализованы только асинхронное чтение/запись и ReadByte/WriteByte, которые по сути просто обертки над Read/Write.
VD>Нет батенька, базовая абстракция отсуствует и я уже не могу делать "чистые" реализации.
Давай все таки не перегибать палку. Кому они нужны, эти псевдочистые реализации, если то что реализовано вобщем то никому ничем не мешает. Просто бесплатный асинхронный доступ и ничего более.
VD> Грамотнее было бы ввести интерфейс, а в Stream реализовать некоторые его методы.
Возможно. Но говорить о том что тебе Stream не позволяет сделать обертку над UCOMIStream по меньшей мере несерьезно.
AVK>>Оно и сейчас вроде как можно.
VD>Сейчас я вынужден отталкиваться от имеющейся реализации.
Нет там никакой реализации, касающейся непосредственно самого стрима. Ты бы вместо того чтобы спорить посмотрел что в Stream реализовано. А то эдак можно докатиться до требования реализации собственного формата VMT.
AVK>>Тебе и сейчас ничего не мешает. В базовом Stream реализованы только асинхронное чтение/запись и ReadByte/WriteByte, которые по сути просто обертки над Read/Write.
VD>Нет батенька, базовая абстракция отсуствует и я уже не могу делать "чистые" реализации. Грамотнее было бы ввести интерфейс, а в Stream реализовать некоторые его методы.
Stream достаточно для всех случаев. Так что грамотнее не плодить лишние сущности.
VD>>>Например, можно было бы Сделать обертку над КОМ-овским IStream-ом.
AVK>>Оно и сейчас вроде как можно.
VD>Сейчас я вынужден отталкиваться от имеющейся реализации.
Что стоит за этими словами "вынужден отталкиваться"? Что конкретно тебе нужно делать и что неправильно?
Вообще, абстрактный класс предпочтительнее интерфейса в том случае, когда нужно обеспечить стандартное поведение для объектов-потомков. Некоторые методы можно сделать виртуальными, а некоторые — просто public, потому что не все методы нужно перегружать. А интерфейсы подобного контроля не дают.
VD> Будем надяеться, что к выходу релиза дотнета 1.2 он будет соотвествовать спецификации на тот же Шарп 2.0 и при вызовах методов интерфейсов у вэлью-типов не будет произход боксинга (как сейчас).
А как это вообще можно реализовать?
1. Физически в структуре нет метаданных, только поля. Как её без "обёртывания" можно в интерфейс превратить?
2. Кто будет боксить при вызове ToString на интерфейсе, полученном от структуры?
VD> На стороне шаблонов: VD>1. Гибкость. VD>2. Производительность.
VD>На стороне дженириков: VD>1. Поддрежка технологии Интели-сенс. VD>2. Распростронение в виде промежуточного кода, а стло быть, возможность использования без наличия исходного кода.
Кроме того, возможности генериков существенно ограничены синтаксисом. Слава богу, хоть в C# гениальные провидцы (вроде Александреску) не будут делать из наших мозгов котлету.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Может я уже плох совсем но зачем internal классам интерфейсы и интрнальные интерфейсы????
VD>А почему они должны быть интернал? Их как раз очень даже полезно публичными делать. А для дженериков вообще очень удачным решением является использование интерфейсов, так как тогда можно делать ручные специализации.
Честно говоря хотел их сделать вообще внутри основного класса, т.к. это вспомогательные классы, но т.к. еще рука не набита то вынес их по обыкновению в NameSpace. На самом то деле это вообще приватные классы и кроме их владельца никто их видеть и использовать напрямую и не должен. Просто в Delphi внутри NameSpace видимы все поля, а в Net ограничение сборкой, что неудобно когда используешь исходник и переделываешь его под себя, а отдельную сборку под него как то не очень то и хочется городить, т.к. это одноразовое решение.
и солнце б утром не вставало, когда бы не было меня
Re[17]: Generic в C# и C++?
От:
Аноним
Дата:
25.11.03 11:50
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
VD>>>Как миниум тот кому будет нужно сможет сделать чистую реализацию так как он считает нужным.
S>> Может я уже плох совсем но зачем internal классам интерфейсы и интрнальные интерфейсы????
AVK>А кто говорил про internal интерфейсы? Суть в том что ты предоставляешь свой класс, реализующий вобщем то обобщенную функциональность без какой либо возможности заменить его на свою реализацию, что есть кривой дизайн. Базовый класс вполне может быть internal, но вот интерфейс обязательно должен быть паблик.
Да это вообще приватные классы и доступ к ним извне не нужен.
Это сыр бор тянется от http://www.rsdn.ru/Forum/Message.aspx?mid=447720&only=1
Здравствуйте, mihailik, Вы писали:
M>Кроме того, возможности генериков существенно ограничены синтаксисом. Слава богу, хоть в C# гениальные провидцы (вроде Александреску) не будут делать из наших мозгов котлету.
AVK>Где было ясно написано AVK>public class BTIndexPP<K,V>
Правильно, только
internal abstract class BTCustomLevel<K,V>
internal sealed class BTNullLevel<K,V>: BTCustomLevel<K,V>
internal sealed class BTParentLevel<K,V>: BTCustomLevel<K,V>
BTIndexPP<K,V> класс используе внутри себя и
public class BTIndexPP<K,V>
{
internal IKeyComparer<K> Comp;
internal BTCustomLevel<K,V> Ind; /// !!!!
internal BTNullLevel<K,V> NullLevel; // !!!!
internal int RecordCount;
internal NullItem<K,V> NullItemAsNull;
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alexkro, Вы писали:
AVK>>>Зачем мне PDC-шные слайды если у меня PDC-шный видби есть.
A>>А за тем, что в Whidbey PDC еще нет тех изменений, которые будут в релизе Whidbey C++.
AVK>Очень сомнительно. Тем более что про дату выхода C++/CLI где то упоминалось что в мае 2004 только появиться первая альфа. В это время у Видби во всю будет идти бета-тестирование, а следовательно никаких серьезных изменений не будет.
Здравствуйте, mihailik, Вы писали:
M>А как это вообще можно реализовать?
Это ты у кого спрашиваешь? Я его не реализую. Открой стандарт на Шарп 2.0 и прочти пунк "20.7.3. Type parameters and boxing"
M>1. Физически в структуре нет метаданных, только поля. Как её без "обёртывания" можно в интерфейс превратить?
Причем тут метаданные? Вызов функции интерфейса — это вызов по указателю. Если внутри метода не лезть к ОО-модели, то его спокойно можно заменить на прямой вызов.
Так как вэлью-типы принципиально унаследованы только от System.Object, да и то виртуально, то нет особых проблем делать прямой вызов вместо вызова интерфейса. Внтури вэлью-типов все вызовы к методам обжекат оптимизируются и делаются не виртуально. Значит и другие можно соптимизировать.
Пока что происходит боксинг. Но в стандарте уже четко записано, что его не будет. Вопрос только в том, не соврут ли.
M>2. Кто будет боксить при вызове ToString на интерфейсе, полученном от структуры?
А он и так не боксится. Просто закладваюет адрес переменной из стека и делают вызов. Декомпилируй подобный код и убедись сам.
M>Кроме того, возможности генериков существенно ограничены синтаксисом. Слава богу, хоть в C# гениальные провидцы (вроде Александреску) не будут делать из наших мозгов котлету.
Котлету делают в виду того что в языке нет нужных возможностей. К сожалению в шарпе тоже кое чего нет. И отсуствие возможностей что есть в шаблонах ставят крест на рсширении языка всеми кроме МС.
Потом у шаблонов было очень удобное применение и без Александревсковских наворотах. Вернее без его наворотов в области метапрограммирования. Та же идея полиси-бэйзед-классов я лично с удовольствием применял. В дотнете для организации подобных фич придется пользоваться нартайм-кодом и виртуальными вызовами. А это тормоза и блее громоздкий код. Ничего хорошего в этом нет.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Давай все таки не перегибать палку. Кому они нужны, эти псевдочистые реализации, если то что реализовано вобщем то никому ничем не мешает. Просто бесплатный асинхронный доступ и ничего более.
А я и не перегибаю. Чем бы помешал интерфейс в данном случае? Был бы и интерфейс и базовый абстрактый класс.
AVK>Возможно. Но говорить о том что тебе Stream не позволяет сделать обертку над UCOMIStream по меньшей мере несерьезно.
Я эту обертку могу сделать из без Stream. Вопрос в том, что если мне по каким-то причинам неподойдет реализация от МС, я не смогу применять все что использует Stream. А промазать при разработке Stream и сделать нечто кривенькое очень просто. То что Stream не взывает проблем это счастливое совподение. Обратных вариантов тоже придостаточно.
AVK>Нет там никакой реализации, касающейся непосредственно самого стрима. Ты бы вместо того чтобы спорить посмотрел что в Stream реализовано. А то эдак можно докатиться до требования реализации собственного формата VMT.
Факт в том, что там уже что-то реализовано. И нет никакой гарантии, что это что-то не окажется лишним/вредным.
Дело не в конкретном случае. Дело в принципе. Если ты делаешь некую абстракцию — не соеденяй ее с реализацией. Пусть даже абстрактной и насквозь виртуальной. Иначе рано или поздно наступишь на грабли кривого дизайна.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
