Serginio1,
> Я так понимаю что T% > T% Get() == void Get(ref T t)
Имхо, это разные вещи: в первом случае клиенту возвращается managed указатель, пользуясь которым он может модифицировать объект типа T. Во втором случае клиент передает managed указатель на что-то, чем он обладает, и что сможет модифицировать функция Get.
Кроме того, различается характер возможных модификаций: в первом случае можно модифицировать объект, но нельзя заменить его на другой. Во втором, если T — ref class, можно как модифицировать сам объект, так и изменить ссылку, которую передали, так что она начнет указывать на другой объект.
Т.е. разницу в возможностях модификаций для ref классов на C++/CLI можно продемонстрировать так:
void Get(T%); // можно модифицировать только сам объект, "перепривязать" ссылку нельзя
void Get(T^%); // можно модифицировать как объект, так и "перепривязать" ссылку
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
GlebZ,
> 2. Что означает, что C++/CLI никогда не будет C++? > Ответ ты дал сам — T^, T%, разница в T& и т.д.
ОК. Т.е. говоря "C++/CLI никогда не будет C++" ты имел в виду, что C++/CLI будет продолжать оставаться отдельным языком, и с ISO С++ не сольется? Согласен, это маловероятно. Но не вижу, как это мешает использованию C++/CLI на платформе .Net.
> 1. Есть в Net два понятия. Первое — то что можно компилируется в MSIL, второе — то что этот код является CLS совметимым и может использоваться из других языков. Сейчас обсуждаемый T% таковым не является (точнее не всегда является). Он может содержать как ссылку на unmanagment, он может содержать ссылку на boxed значение — доступ к которому невозможно обработать CLS языком. Или он вообще не может быть null.
Насколько я понимаю, CLS-compliant относится не к коду, а к внешним "интерфейсам" сборки (интерфейс в более широком смысле, чем, скажем, interface в C#, а именно: набор доступных типов, набор сигнатур функций-членов классов и т.п.). Соответственно, не вижу никаких проблем в том, чтобы выставить из сборки "наружу" CLS-compliant "интерфейс", а "внутри" использовать большее количество возможностей платформы.
Кроме того, тот же C# в этом отношении исключением не является. Скажем, насколько я понял, во второй версии планируется добавление возможности задания разного доступа к accessors of properties:
Q: When do you plan to allow different scope keywords for property get and set blocks? I.e. public getters with protected/private setters? A: The next release (Whidbey or VS 2005) should have it. The current beta 1 and various "Community Tech Preview" releases should already have it...
Эта возможность является non CLS-compliant:
CLS Rule 25: The accessibility of a property’s accessors shall be identical. (§8.11.3)
Для меня вопрос скорее в том, какое количество возможностей платформы доступно для использования в реализации. То, что используемые возможности нужно будет ограничивать в "интерфейсе", предназначенном для использования в других языках, меня заботит очень мало.
> CLS языки не умеют работать с box value типами
Ага, уже разобрался:
CLS Rule 3: Boxed value types are not CLS-compliant. (§8.2.4.)
> Поэтому return value_object без копирования в CLS невозможно.
T% вовсе не означает боксинга, это managed pointer. И я не вижу в спецификации правила делающего возврат managed указателя non CLS-compliant, кроме случая с properties, что оговорено отдельно:
CLS Rule 27: The type of a property shall be the return type of the getter and the type of the last argument of the setter. The types of the parameters of the property shall be the types of the parameters to the getter and the types of all but the final parameter of the setter. All of these types shall be CLS-compliant, and shall not be managed pointers (i.e., shall not be passed by reference). (§8.11.3)
> 1. С++/CLI позволяет делать not CLS код. В некоторых случаях это может делать и C# (в unsafe например), но здесь это проявлено особо. В результате потеря межязыковой совместимости.
Потеря языковой совместимости была бы в случае, если бы C++/CLI не позволял делать CLS-compliant "интерфейсы". Т.к. он делать CLS-compliant типы, методы и т.п. позволяет, то я проблемы не вижу.
> 2. Может компилировать unmanage код. В результате потеря межязыковой и межплатформенной совместимости.
Может. Но по умолчанию весь код managed, хотя и не обязательно CLS-compliant. В частности, использование unmanaged типов не приводит к тому, что код становится unmanaged. Точно также сам по себе не становится unmanaged код, полученный в результате переноса исходного кода из native приложения, если этот код перекомпилируется, а не используется в виде unmanaged библиотеки. Т.е. если мы, допустим, возьмем готовую библиотеку на C++ и перекомпилируем в режиме /clr, то мы получим managed код, который можно будет использовать в новом проекте на C++/CLI, и при этом соответствующая проекту сборка вполне может быть как managed (как mixed, так и pure или safe), так и CLS-compliant.
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Странно... Видимо, у тебя что-то со шрифтами.
У меня все в пордяке. Но италик на экране читается фигово. Лучше его не испоьзовать. Выразительных средств и без него достаточно.
>> МС++, даже причесанный — это все равно море "шума". Все эти ->, ^, %, ref class, interface class, array<XXX>... все это всего лишь мусор.
ПК>Влад, аргументация такого уровня — несерьезно. Это из серии споров, что лучше: begin ... end или { ... }. Особенно на фоне того, что эти дополнительные обозначения таки дают дополнительные возможности.
Что я тебе могу сказать? Может тебе это и наормально. Для меня это грязь и шум. Думаю, для большинства тоже. Ну, а то что тебе не нарвится аргументация. Было бы страно если было бы на оборот.
>> через Х итераций большинство просто пересядят на Шарп и скажет — "Один хрен я в основном ограничен не языком, а платформой.
ПК>Это не так: ограничен ты только в том, что выставляешь "наружу". В этом (межязыковом взаимодействии) всегда были ограничения. Главная разница в использовании C++ и C# — возможности, доступные тебе "внутри" сборок.
Это так, Пашь. И через пару лет ты это прочувствуеш в лучшем виде.
>> Шарп позволяет все что нужно для этой платформы
ПК>(1) Смотря, что делать. (2) Ряд вещей проще делать на C++/CLI: шаблоны, управление ресурсами, и т.п.
Да не нужно никому твое управление ресурсами. Все эти навороты делаются чтобы привлечь таких как ты. Кто еще не привык к тому, что память больше не ресурс. Скачай те же исходники R#-а. Погляди какие там проблемы с управлением ресурсами. Потом скачай Янус...
ПК>Это оттого, что я не знал, какой синтаксис нужен. Перепиши в виде индексированного свойства — и все пироги.
Пашь, ссылки сами по себе не CLS-совместимы.
ПК>Ты явно проигнорировал упоминание встроенных массивов. Они работают именно так, как нужно.
Что ты называешь встроенными массивами?
ПК>В примере в MSDN было именно так. Посмотрел в тест, который написал, пока игрался (и это работало в C++/CLI)... Именно так, как написано
Я вот попробовал, и не работает.
ПК>Это, если я правильно понимаю, unmanaged указатель.
Неправильно понимашь. Это мнедедеж-указатель.
ПК>В том-то и дело, что в C# это unsafe. В C++ указанное выше safe (по крайней мере, компилируется с ключом /clr:safe без вопросов), хотя и не CLS-compliant. Забавно, что cледующее, если я правильно понимаю, является CLS-compliant: ПК>
ПК>во всяком случае, я не нашел в стандарте CLI или C++/CLI упоминаний обратного. Правда, C# это дело потреблять отказался
Если C#, то можешь смело считаь это не CLS-совместимым. Весь смысл CLS-compliant в том, чтобы можно было экспортировать методы и типы в другие языки. Причем Шарп — это своеобразная лакмусова бумажка, так как этот язык ближе всего к CLS-compliant.
Короче, я декомпильнул код и получил вот такое описание гетера:
То есть это не только не CLS-совместимо, но и ансэйф.
ПК>Не надо брать адрес свойства. Достаточно, чтобы оно для модификаций возвращало/принимало managed pointer.
Блин, вся идея упрвляемого кода заключаетс в надежности. Указатели — это приговор надежности. Так что для дотнета — это дурь.
ПК>Немного не понял. Что именно не получается сделать?
Чтобы сементика была как при модификации по месту, а на самом деле бы производилось бы вынимание вэлью-типа, его модификация и помещение его обратно. Ну, например, как при инкременте свойства:
obj.Prop++;
ПК>Дык, ты ж никогда не пробовал C++/CLI в том же объеме, что и C# — так что это не практика, это теория
Я его посмотрел (в том объеме что он реализован во второй бэте). Не думаю, что мне нужно пол года на нем писать, чтобы понять, что это и что я получу от него.
Наоборот получил некоторое количество огорчения. Так попытка создать вектор менеджед-ссылок обламалась:
std::vector<A^> vector;
Сказали, что немогут использовать new для A^ и указали на:
template<class _T1,
class _T2> inline
void _Construct(_T1 _FARQ *_Ptr, const _T2& _Val)
{ // construct object at _Ptr with value _Valvoid _FARQ *_Vptr = _Ptr;
::new (_Vptr) _T1(_Val);
}
ПК>Не все затевается для C# Много вещей предназначены для "внутреннего" использования. И не хочется их ограничивать, только из-за того, что кто-то вовне чего-то там "не поймет"
И ты будишь сифонить мужду внутренним и внешним миром? И чем это отличается от создания оберток в сегодняшнем МС++?
ПК>Это кому как.
Да всем кто не прикипел к стл-ным. По карайней мере большинство разумных программистов когда поймут, что им прийдется исключительно ради своих предпочтений использовать два разных набора контейнеров (один для внутреннего, а другой для внешнего испоьзования), то они скажут — "А на фига козе баян?".
ПК>Для "наружных" пользователей те же контейнеры STL/CLI можно будет отдавать как IList<T> и т.п.
Пока-что я даже не смог положить ссылочный тип в эти контейнеры. А уж как они смогут из сурового анменеджеда сделать менеджед IList<T> я вообще не представляю.
Это вообще в какой версии должно появиться? А то у меня бэта два и все эти сказки так сказками и остались.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Нет, это не так. И /clr:pure, и /clr:safe замечательно "едят" unmanaged типы. Например, в таком виде: ПК>
ПК> struct Unmanaged { };
ПК> public value struct S
ПК> {
ПК> int x;
ПК> int y;
ПК> Unmanaged u;
ПК> };
ПК>
Ага. Но не в этой жизни. А в этой:
d:\MyProjects\Tests\CppAsm\CppAsm\CppAsm.h(15) : error C4368: cannot define 'u' as a member of managed 'CppAsm::S': mixed types are not supported
>> Первый потому как обязан быть польньстью дотнетным,
ПК>Явно не соответствует действительности: /clr:pure означает, что код будет только managed. Это вовсе не означает, что нельзя использовать unmanaged классы.
Ну, возможно. Но "сэйф" точно не должно позволять никаких вольностей вроде стл.
ПК>Unmanaged типы вовсе не означают отсутствие контроля типизации. /clr:safe означает, что код будет managed и verifiable. Это точно так же не исключает использования unmanaged типов.
При попытке вставить пустую анменеджед-структуру компилятор выдает:
d:\MyProjects\Tests\CppAsm\CppAsm\CppAsm.h(9) : error C4959: cannot define unmanaged struct 'CppAsm::Unmanaged' in /clr:safe because accessing its members yields unverifiable code
Короче, "сэйф" — это аналог сэйф в Шарпе. Т.е. верефицируемый код не содержаций опасных конструкций. Кстати, возврат ссылки таки прокатил в этом режиме и компилятор снял с него атрибут ансэйф.
>> Ведь даже банальный контроль типов требует отаказаться от анменеджед-тиопв.
ПК>Не требует. Запрещены только "опасные" преобразования и т.п.
Не, Пашь. Сэйф — это значит "все анменеджед-типы идут лесом, так как их нельзя проверить". Типизация С++ тут идет лесом. Исполняться ведь код будет под управлением CLR, а ему о знаниях С++ ничего не известно. Собвстенно компилятор это и рассказал.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Вчера общался с разработчиками. Сказали, что отложена, т.к. не получилось придумать легкий в реализации синтаксис (вспоминаем о тяжелом наследии древнего кода в VC++, плюс о конечности ресурсов разработчиков).
Чё там придумывать то? Содрали бы Шарповский и все. Бред какой-то.
Думаю, врут нагло. Скорее всего просто проблем по горло вот и не до таких мелочей. Но без этого же возможности создания дженериков на С++ будут ограниченными. И опять получится уродец.
ПК>Если фичу будут требовать многие пользователи беты — сделают.
Гы. Бете жить то всего ничего. В общем, я тут схожусь во мнении со Станиславским.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>То есть это не только не CLS-совместимо, но и ансэйф.
Тебе-ж вроде сказали, что /clr:safe это компилирует. А что там какой-то декомпилятор выдаст — это уже его личное дело.
...
ПК>>Дык, ты ж никогда не пробовал C++/CLI в том же объеме, что и C# — так что это не практика, это теория
VD>Я его посмотрел (в том объеме что он реализован во второй бэте). Не думаю, что мне нужно пол года на нем писать, чтобы понять, что это и что я получу от него.
VD>Наоборот получил некоторое количество огорчения. Так попытка создать вектор менеджед-ссылок обламалась: VD>
VD>std::vector<A^> vector;
VD>
VD>Сказали, что немогут использовать new для A^ и указали на:
...
Если у тебя только до этого руки дошли, то считай что ты на уровне 3 в игре из 200.
...
ПК>>Для "наружных" пользователей те же контейнеры STL/CLI можно будет отдавать как IList<T> и т.п.
VD>Пока-что я даже не смог положить ссылочный тип в эти контейнеры. А уж как они смогут из сурового анменеджеда сделать менеджед IList<T> я вообще не представляю.
VladD2,
>>> Шарп позволяет все что нужно для этой платформы
> ПК> (1) Смотря, что делать. (2) Ряд вещей проще делать на C++/CLI: шаблоны, управление ресурсами, и т.п.
> Да не нужно никому твое управление ресурсами. Все эти навороты делаются чтобы привлечь таких как ты. Кто еще не привык к тому, что память больше не ресурс.
Память (хоть и не согласен) — байт с ней. В данном случае речь шла об остальных ресурсах, которые нужно освобождать/закрывать вовремя. В C++/CLI для автоматизации управления ресурсами возможностей больше.
> ПК> Это оттого, что я не знал, какой синтаксис нужен. Перепиши в виде индексированного свойства — и все пироги.
> Пашь, ссылки сами по себе не CLS-совместимы.
Это не так. Ссылки не CLS-совместимы только в случае использования внутри properties. Но в данном случае это все равно. Ты говорил, что этот класс unmanaged. Это не так, он будет managed, если исправить синтаксис, но, как и сразу упоминалось, останется не CLS-compliant.
> ПК>Ты явно проигнорировал упоминание встроенных массивов. Они работают именно так, как нужно. > > Что ты называешь встроенными массивами?
T[] в C#.
> ПК> В примере в MSDN было именно так. Посмотрел в тест, который написал, пока игрался (и это работало в C++/CLI)... Именно так, как написано
> Я вот попробовал, и не работает.
На C++/CLI? Может, нужно скачать какой-нибудь beta refresh
> ПК> во всяком случае, я не нашел в стандарте CLI или C++/CLI упоминаний обратного. Правда, C# это дело потреблять отказался
> Если C#, то можешь смело считаь это не CLS-совместимым. Весь смысл CLS-compliant в том, чтобы можно было экспортировать методы и типы в другие языки. Причем Шарп — это своеобразная лакмусова бумажка, так как этот язык ближе всего к CLS-compliant.
Не факт. В этом отношении я верю только спецификации CLI или любой "стандартной" утилите, верифицирующей этот факт (должна же быть такая?). В спецификации я такого не нашел. Найдешь — будет так. До тех пор, по умолчанию, считаем, что просто C# это решил не поддерживать, не ставя CLS-compliance выше своих внутренних целей. А то что это так, видно как минимум из того, в C# 2.0 вводят non CLS-compliant возможность (разный доступ к accessors of properties); наверное, и раньше такие возможности в C# были, просто мне они неизвестны.
> Короче, я декомпильнул код и получил вот такое описание гетера: >
> То есть это не только не CLS-совместимо, но и ансэйф.
Пока не найдена цитата из спецификации, я склонен полагать это артефактом декомпиляции, т.к. в C# нет способа выразить то, что нужно. Вот что дает Reflector в виде IL:
никаких unsafe, & — обычный unmanaged указатель.
> ПК> Не надо брать адрес свойства. Достаточно, чтобы оно для модификаций возвращало/принимало managed pointer.
> Блин, вся идея упрвляемого кода заключаетс в надежности. Указатели — это приговор надежности. Так что для дотнета — это дурь.
Это твое личное мнение. Спецификация CLI managed указатели не запрещает. И даже не говорит, что код, их содержащий, является не type-safe или не verifiable.
>
> std::vector<A^> vector;
>
> Сказали, что немогут использовать new для A^ и указали на:
Нужно использовать stdcli::vector<A^> (#include <cli/vector>). Не уверен, что он доступен в beta, в релизе точно будет.
> ПК> Не все затевается для C# Много вещей предназначены для "внутреннего" использования. И не хочется их ограничивать, только из-за того, что кто-то вовне чего-то там "не поймет"
> И ты будишь сифонить мужду внутренним и внешним миром? И чем это отличается от создания оберток в сегодняшнем МС++?
Тем, что код будет managed, а если есть желание, то и safe.
> ПК>Для "наружных" пользователей те же контейнеры STL/CLI можно будет отдавать как IList<T> и т.п.
> Пока-что я даже не смог положить ссылочный тип в эти контейнеры.
Ты пробовал другие контейнеры.
> А уж как они смогут из сурового анменеджеда сделать менеджед IList<T> я вообще не представляю.
VladD2,
> ПК> Вчера общался с разработчиками. Сказали, что отложена, т.к. не получилось придумать легкий в реализации синтаксис (вспоминаем о тяжелом наследии древнего кода в VC++, плюс о конечности ресурсов разработчиков).
> Чё там придумывать то? Содрали бы Шарповский и все. Бред какой-то.
Далеко не факт, что синтаксис, принятый в C# легок в текущей реализации VC++.
> Скорее всего просто проблем по горло вот и не до таких мелочей.
И это тоже.
> Но без этого же возможности создания дженериков на С++ будут ограниченными.
System::Activator::CreateInstance<T> спасет отца русской демократии Плюс, в C++, учитывая наличие шаблонов, есть и другие способы легкого разрешения проблемы.
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
> ПК>Нет, это не так. И /clr:pure, и /clr:safe замечательно "едят" unmanaged типы. Например, в таком виде: > ПК>
> ПК> struct Unmanaged { };
>
> ПК> public value struct S
> ПК> {
> ПК> int x;
> ПК> int y;
> ПК> Unmanaged u;
> ПК> };
> ПК>
> Ага. Но не в этой жизни. А в этой: >
d:\MyProjects\Tests\CppAsm\CppAsm\CppAsm.h(15) : error C4368: cannot define 'u' as a member of managed 'CppAsm::S': mixed types are not supported
У тебя, вероятно, более старая версия VC++ (у меня — 14.00.40607.85).
>>> Первый потому как обязан быть польньстью дотнетным,
> ПК> Явно не соответствует действительности: /clr:pure означает, что код будет только managed. Это вовсе не означает, что нельзя использовать unmanaged классы.
> Ну, возможно. Но "сэйф" точно не должно позволять никаких вольностей вроде стл.
Это еще почему? Для managed режима там специальная STL/CLI есть, #include <cli/vector> и т.п. Смотри соседнее сообщение
на предмет ссылок.
> ПК>Unmanaged типы вовсе не означают отсутствие контроля типизации. /clr:safe означает, что код будет managed и verifiable. Это точно так же не исключает использования unmanaged типов.
> При попытке вставить пустую анменеджед-структуру компилятор выдает: <...>
У меня компилирует на ура:
. . .
namespace cpp_cli
{
struct Unmanaged { };
public value struct S
{
int x;
int y;
Unmanaged u;
};
. . .
d:\MyProjects\Tests\CppAsm\CppAsm\CppAsm.h(9) : error C4959: cannot define unmanaged struct 'CppAsm::Unmanaged' in /clr:safe because accessing its members yields unverifiable code
> ПК>Не требует. Запрещены только "опасные" преобразования и т.п.
> Не, Пашь. Сэйф — это значит "все анменеджед-типы идут лесом, так как их нельзя проверить".
пока я думаю, что более старая версия VC++ у тебя
> Типизация С++ тут идет лесом. Исполняться ведь код будет под управлением CLR, а ему о знаниях С++ ничего не известно.
Известно-известно: C++ компилируется в IL.
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
P.S.
> Пока не найдена цитата из спецификации, я склонен полагать это артефактом декомпиляции, т.к. в C# нет способа выразить то, что нужно. Вот что дает Reflector в виде IL: >
> никаких unsafe, & — обычный unmanaged указатель.
Насчет CLS-compliance пока ничего не видно (т.к. набор правил небольшой, все-таки полагаю, что это на CLS-compliance не влияет), но уже ясно, что вызов данного метода не verifiable (т.е. таки unsafe):
III.1.8.1.2.1 A method can be defined as returning a managed pointer, but calls upon such methods are not verifiable.
Правда, не потому что это нельзя было сделать, а просто решили не заморачиваться:
[Rationale: Some uses of returning a managed pointer are perfectly verifiable (e.g., returning a reference to a field in an object); but some not (e.g., returning a pointer to a local variable of the called method). Tracking this in the general case is a burden, and therefore not included in this standard. end rationale]
Posted via RSDN NNTP Server 2.0 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, alexeiz, Вы писали:
A>Тебе-ж вроде сказали, что /clr:safe это компилирует. А что там какой-то декомпилятор выдаст — это уже его личное дело.
Смотри сообщение рядом. С /clr:safe метка анэсэйф снелась. Вилимр у крмпиоятора глюки.
A>Если у тебя только до этого руки дошли, то считай что ты на уровне 3 в игре из 200.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Память (хоть и не согласен) — байт с ней. В данном случае речь шла об остальных ресурсах, которые нужно освобождать/закрывать вовремя. В C++/CLI для автоматизации управления ресурсами возможностей больше.
Я по этому поводу уже все сказал и не раз. Высасываешь проблему из пальца.
ПК>Это не так. Ссылки не CLS-совместимы только в случае использования внутри properties. Но в данном случае это все равно. Ты говорил, что этот класс unmanaged. Это не так, он будет managed, если исправить синтаксис, но, как и сразу упоминалось, останется не CLS-compliant.
Ссылки возращать нельзя. А сами по себе они конечно допустимы. ref и out — это они и есть.
>> ПК>Ты явно проигнорировал упоминание встроенных массивов. Они работают именно так, как нужно. >> >> Что ты называешь встроенными массивами?
ПК>T[] в C#.
И что с ними? Синтаксис на индексеры похож? Ну, дык у полей тоже синтаксис похож на свойства. Однако поля по ссылке можно передавать, а свойства нет.
ПК>На C++/CLI? Может, нужно скачать какой-нибудь beta refresh
Пока вроде нет. Ну, да подождем офицальную бэту 2. В марте вроде обещали.
ПК>Не факт.
Факт.
ПК> В этом отношении я верю только спецификации CLI или любой "стандартной" утилите, верифицирующей этот факт (должна же быть такая?).
Ага. csc.exe называется. Даже придумали такой атрибут ClsComplane (или что-то вроде). Если на сборку задать, то должен материться на все места специально не помеченные этим атрибутом с фолсом.
ПК> В спецификации я такого не нашел. Найдешь — будет так.
И искать не будут. Все что не совместимо с Шарпом автоматом несовместимо. Впрочем как и с ВБ. Вся суть этой совместимости в том, чтобы совместимые сборки были видны в любых языках без ограничений. ВБ и Шарп этому требованию удолветворяют. В МС++ были проблемы.
ПК>Нужно использовать stdcli::vector<A^> (#include <cli/vector>). Не уверен, что он доступен в beta, в релизе точно будет.
И где его взять? Пока такой не пробегал.
ПК>Тем, что код будет managed, а если есть желание, то и safe.
Геморрой будет. И если, есть желание то крупный.
ПК>Ты пробовал другие контейнеры.
А нету их. Видимо статья на совсем внутренних билдах основана.
ПК>stdcli::vector и т.п. — полностью managed код. safe and verifiable.
Ну, будем надеяться. Хотя конечно изврат еще тот. Код не совместим, библиотеки дублиются за то "по нашему" по стльному.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>У тебя, вероятно, более старая версия VC++ (у меня — 14.00.40607.85).
Агащасблин 14.00.41115.19
Это у гого старя еще нужно выяснить. Я потому и смотреть начал, что хоть что-то из сказок заработало. Хотя бы менеджед-объекты с диспозом в стэке стали жить.
>> Ну, возможно. Но "сэйф" точно не должно позволять никаких вольностей вроде стл.
ПК>Это еще почему? Для managed режима там специальная STL/CLI есть, #include <cli/vector> и т.п. Смотри соседнее сообщение
Со специльным — нет вопросов. Ты же о антенеджед-типах речь вел. Так вот они отменяются.
ПК>У меня компилирует на ура: ПК>
ПК>. . .
ПК>namespace cpp_cli
ПК>{
ПК> struct Unmanaged { };
ПК> public value struct S
ПК> {
ПК> int x;
ПК> int y;
ПК> Unmanaged u;
ПК> };
ПК> . . .
ПК>
Значит баг... уже исправленный в новой версии.
ПК> пока я думаю, что более старая версия VC++ у тебя
Ну, думай. У тебя вообще похоже бэта 1.
>> Типизация С++ тут идет лесом. Исполняться ведь код будет под управлением CLR, а ему о знаниях С++ ничего не известно.
ПК>Известно-известно: C++ компилируется в IL.
Я тебе вроде уже показал сообщение? Да и сточки зрения логики бред это — сэйф с анменеджед-данными.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Далеко не факт, что синтаксис, принятый в C# легок в текущей реализации VC++.
Ну, если весь компилятор в заплатках, то конечно проблемы возможны. Я например, встроил в прасер R# констрэйны часа за два.
ПК>System::Activator::CreateInstance<T> спасет отца русской демократии Плюс, в C++, учитывая наличие шаблонов, есть и другие способы легкого разрешения проблемы.
А причем тут это? Констрэйн на структуры — это совсем другое. Это ограничение применимости дженерика только вэлью-типами.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alexeiz, Вы писали:
A>>У тебя Beta 2? Что-то слабо верится .
VD>Твои проблемы.
Какой build?
A>> В Beta 2 это должно появиться.
VD>Может к офицальному выходу в марте и появится. А сейчас точно хрен. Я сделал поиск по подкаталогам нашел только:
Промежуточные build'ы в этом смысле мало значения имеют.
VD>ЗЫ
VD>Вообще, забавно было бы глянуть как они извернулись.
Понятно, как:
namespace cli {
template < typename T >
ref class vector : public System::Collections::Generic::IList< T >, ...
{ ... }; }
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>У тебя, вероятно, более старая версия VC++ (у меня — 14.00.40607.85).
VD>Агащасблин 14.00.41115.19
Эта версия собрана в середине ноября. До марта как-то далековато будет.
Законтачил с разработчиками. Сказали, что пришлось эту возможность оставить за бортом. Изначально было реализовано в виде набора правил для FxCop, но из-за проблем с интеграцией сего инструмента с VC++ эту дорожку пришлось оставить, и текущих планов реализовывать эту функциональность для VS2005 нет. Возможно, набор правил для FxCop будет доступен в дальнейшем для скачивания.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2,
>>> ПК> Ты явно проигнорировал упоминание встроенных массивов. Они работают именно так, как нужно.
>>> Что ты называешь встроенными массивами?
> ПК>T[] в C#.
> И что с ними?
С ними то, что операция [] возвращает managed указатель. Если бы это приводило к проблемам с производительностью, как ты утверждал, то вряд ли было бы принято такое решение.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>GlebZ,
GZ>> аттрибут CLSCompiliant
ПК>Законтачил с разработчиками. Сказали, что пришлось эту возможность оставить за бортом.
А вот это действительно плохо. Оссобенно для C++/CLI. ПК>Изначально было реализовано в виде набора правил для FxCop, но из-за проблем с интеграцией сего инструмента с VC++ эту дорожку пришлось оставить, и текущих планов реализовывать эту функциональность для VS2005 нет. Возможно, набор правил для FxCop будет доступен в дальнейшем для скачивания.
Самое смешное, что в текущих проектах первым делом FxCop очень ругался — почему у вас не проставлен аттрибут CLSCompliant
Много вещей предназначены для "внутреннего" использования. И не хочется их ограничивать, только из-за того, что кто-то вовне чего-то там "не поймет" 
Чё там придумывать то? Содрали бы Шарповский и все. Бред какой-то.
