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

КД>Вообщем, я плюнул, и накатал свои алгоритмы для IntPtr.

М-да...

Начинать постижение идей managed-платформы с ковыряния в кишках interop'а это нечто. Представляю Ваши впечатления при переезде с С на C++:

"Что они там курят ??? Конструкторы\деструкторы вызывает непонятно кто, непонятно когда, и код ошибки из них нормально не прокинуть... А виртуальные функции это вообще капец, там какой-то фатальный pure virtual function call на каждый чих вылезает — придётся кучу защитной обвязки писать, а то вдруг... А уж с указателями совсем бардак — почему моему обычному C'ишному указателю на функцию нельзя просто присвоить указатель на функцию-член класса ???"

...и т.д. и т.п.

*Вы на .NET собрались писать mission critical приложения для исполнительных устройств атомных электростанций ???

КД>Сегодня разбирался с сериализацией. Опять какая-та лажа. Нафига мне нужно указывать (километровые) типы — выводите из значений параметров! C# же позволяет. Опять свой код.

Позволяет C# 2.0 и выше. А код той сериализации был написан ещё во времена самой первой версии .NET\C#

КД>Во. Меня еще заколбасило от того, что StringBuilder.Clear появился только в NET4. Это жесть



КД>Нормальных алгоритмов поиска по ключу в List я не нашел. Нужны алгоритмы которые бы работали с (а-ля) IComparer<T1,T2>. Плохо искал? Опять свой код.

У List<T> есть куча Find'ов от предиката, например. Внутри предиката Вам никто не мешает позвать какой Вашей душе угодно IComparer... И это ещё не касаясь LINQ to Objects...

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

D>Конечно же это C++. В него просто добавлен нормальный синтаксис\система типов — вместо всяких макросно-шаблонных извращений предыдущей эпохи — для поддержки компонентных систем. Причём с практически полным сохранением совместимости с C++\CLI по "буковкам".

Это не C++, потому что он не соответствует стандартам ни 2003, ни 2011 года и не компилируется другими компиляторами, кроме микрософтовского.

Да, и "макросно-шаблонные извращения" в новом стандарте уже являются частью стандартной библиотеки.

Вообще, если я буду разрабатывать софт для винды у меня два юзкейса:

1) у меня есть большая кодовая база на C++ и винапи, WinRT не нужен (не переписывать же все?);

2) я собираюсь начать новое приложение, выберу, естественно, дотнет (WPF, WinForms), ну или, на худой конец, QT, так как он мощный и еще и кроссплатформенный, а нафига мне ни с чем не совместимый и убогий (по сравнению с C#) WinRT с его кривым недосиплюсплюсом в этом случае?

Не, не понимаю, хоть убейте. Глупость и все тут.

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

А>>Главные вопросы, которые у меня возникают: "WTF?" и "нафига?", а также "нафига?!", "нафига?!!" и "нафига?!!!".
D>Да прекрасно понятно. Планете давно нужен нормальный язык\платформа для натива. И если комитет забивает болт, то в игру приходится вступать Microsoft'у.
Мне не очень понятно в чём тут плюсы по сравнению с классическим решением на умных указателях. Генерация метаинформации — ну ладно, ещё можно простить.

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

А>Это не C++, потому что он не соответствует стандартам ни 2003, ни 2011 года и не компилируется другими компиляторами, кроме микрософтовского.

Вы так говорите, как-будто в предыдущих версиях реализации C++ от Microsoft не было никаких их "личных" языковых расширений. Тогда как килотонны... нет, килотонны это мало... мегатонны существующего кода оные во всю используют, и ничем кроме MSVC никогда не скомпилируются.

А>Да, и "макросно-шаблонные извращения" в новом стандарте уже являются частью стандартной библиотеки.

Да ну ? С интересом послушаю, как Вы на этих "частях" будете делать поддержку системы типов WinRT.

А>1) у меня есть большая кодовая база на C++ и винапи, WinRT не нужен (не переписывать же все?);

Зачем переписывать ??? Там прямой interop аналогичный схеме C++\CLI. Новые внешние интерфейсы делаете на WinRT, а в потрохах всё тот же старый добрый legacy C++.

А>2) я собираюсь начать новое приложение, выберу, естественно, дотнет (WPF, WinForms),

А если платформа это Windows Phone ? И приложение это какой-нибудь навороченный ГИС-клиент ? Для которого опять-таки куча C++ кода уже есть ? Тоже .NET выберете ?

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

C>Мне не очень понятно в чём тут плюсы по сравнению с классическим решением на умных указателях.

Ну расскажите, как Вы собираетесь реализовывать полную поддержку системы типов WinRT исключительно на smart-pointer'ах. Лично я с большим интересом послушаю.

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

D>Вы так говорите, как-будто в предыдущих версиях реализации C++ от Microsoft не было никаких их "личных" языковых расширений. Тогда как килотонны... нет, килотонны это мало... мегатонны существующего кода оные во всю используют, и ничем кроме MSVC никогда не скомпилируются.

Ну это неправда. У MSVC есть некоторые расхождения со стандартом в том плане, что он компилирует невалидный с точки зрения стандарта код, но это все не такие большие проблемы и довольно легко допиливаются при портировании. В то время, как в WinRT с его "крышками" это вообще считай другой язык.

А>>Да, и "макросно-шаблонные извращения" в новом стандарте уже являются частью стандартной библиотеки.
D>Да ну ? С интересом послушаю, как Вы на этих "частях" будете делать поддержку системы типов WinRT.

Дык примерно так я и пишу все программы на C++, с reference counting'ом.

А>>1) у меня есть большая кодовая база на C++ и винапи, WinRT не нужен (не переписывать же все?);

D>Зачем переписывать ??? Там прямой interop аналогичный схеме C++\CLI. Новые внешние интерфейсы делаете на WinRT, а в потрохах всё тот же старый добрый legacy C++.

А в чем профит перед C++/CLI, учитывая идентичный поганый синтаксис? Ну и для дотнета я бы скорее использовал автоматическую генерацию оберток, чем писать это уродство на C++/CLI. Хотя, это, конечно, лучше, чем делать COM-обертки, спору нет.

А>>2) я собираюсь начать новое приложение, выберу, естественно, дотнет (WPF, WinForms),

D>А если платформа это Windows Phone ? И приложение это какой-нибудь навороченный ГИС-клиент ? Для которого опять-таки куча C++ кода уже есть ? Тоже .NET выберете ?

Не понял эту реплику. А WinRT что дает для Windows Phone? C#-то вроде как раз и дает общую кодовую базу с Windows Phone (кроме UI).

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

C>>Мне не очень понятно в чём тут плюсы по сравнению с классическим решением на умных указателях.
D>Ну расскажите, как Вы собираетесь реализовывать полную поддержку системы типов WinRT исключительно на smart-pointer'ах. Лично я с большим интересом послушаю.
А какие сложности? Проблемы только с синтаксисом свойств и событий/делегатов. Их можно с помощью препроцессора реализовать (см. QT MOC).

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

Поскипал — что-то много вроде для простых вещей, да и поздно.

КД>Нормальные указатели — это в unsafe. Так? Или я что то пропустил?
Да, это в unsafe. Но, незачем его так избегать, ничего в нём плохого нет. Использование IntPtr не менее unsafe, чем unsafe который ключевое слово, если его применять так же как указатели, или с такими наворотами. Более того, использование нормальных указателей — позволяет получить типо-безопасный код, в отличии прыжков с IntPtr.

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

D>М-да...

D>Начинать постижение идей managed-платформы с ковыряния в кишках interop'а это нечто.

Ну, вообще говоря, постижение я начал с того, что вдумчиво прочитал Рихтера. Главы типа "автоматическая сборка мусора" — несколько раз. Ну еще Троелсена почитал. Так что тут все путем

Практику это не заменило, но какой-то стартовый багаж знаний сформировало.

D> Представляю Ваши впечатления при переезде с С на C++:

Не угадал — я переехал с паскаля (в 96. тесноват стал, для моих задумок) на плюсы. Я конечно тогда тоже конкретно попарился, но по-большому счету из за глобального непонимания. И того, что многие базовые вещи (типа подсчета ссылок) пришлось выводить самому. Прорыв (в управлении объектами) произошел летом 2001, когда я сам допер, что у объекта может быть больше одного счетчика. Это было ночью. Утром я напился

D>*Вы на .NET собрались писать mission critical приложения для исполнительных устройств атомных электростанций ???

Нет, просто надежный и, по-возможности, красивый код. Это долго, дорого и мутно, но в конечном итоге — быстрее и дешевле чем ...

КД>>Сегодня разбирался с сериализацией. Опять какая-та лажа. Нафига мне нужно указывать (километровые) типы — выводите из значений параметров! C# же позволяет. Опять свой код.

D>Позволяет C# 2.0 и выше. А код той сериализации был написан ещё во времена самой первой версии .NET\C#

Дык, надо трясти базовый код. Прикольно в FW4 обнаруживать использование атрибутов, которые "не рекомендуется" использовать с NET4 Правда, это они наверное нам не рекомендуют.

КД>>Нормальных алгоритмов поиска по ключу в List я не нашел. Нужны алгоритмы которые бы работали с (а-ля) IComparer<T1,T2>. Плохо искал? Опять свой код.

D>У List<T> есть куча Find'ов от предиката, например. Внутри предиката Вам никто не мешает позвать какой Вашей душе угодно IComparer...
Find-ы я не смотрел, потому что линейный поиск не интересовал. А вот BinarySearch-а по предикату не наблюдается.
int BinarySearch(int index, int count, T item, IComparer<T> comparer)
int BinarySearch(T item)
int BinarySearch(T item, IComparer<T> comparer)

как мне искать не T, а TKey? Я не хочу делать словари TKey->TItem. Поскольку TKey и так хранится в TItem.

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

КД>>Нормальные указатели — это в unsafe. Так? Или я что то пропустил?
F> Да, это в unsafe. Но, незачем его так избегать, ничего в нём плохого нет. Использование IntPtr не менее unsafe, чем unsafe который ключевое слово, если его применять так же как указатели, или с такими наворотами. Более того, использование нормальных указателей — позволяет получить типо-безопасный код, в отличии прыжков с IntPtr.

Спасибо, я прислушаюсь к этому совету

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

КД>Нет, просто надежный и, по-возможности, красивый код. Это долго, дорого и мутно, но в конечном итоге — быстрее и дешевле чем ...
Суд по постам — идешь ровно к обратному.

КД>Дык, надо трясти базовый код. Прикольно в FW4 обнаруживать использование атрибутов, которые "не рекомендуется" использовать с NET4 Правда, это они наверное нам не рекомендуют.
Есть набор "внутрениих" атрибутов, которые есть в mscorlib и system и не рекомендуется их использовать в своих либах. Это нормально.
Есть также устаревшие атрибуты, которые использовались в .NET1, а .NET4 достались по наследству. Это тоже нормально.

КД>>>Нормальных алгоритмов поиска по ключу в List я не нашел. Нужны алгоритмы которые бы работали с (а-ля) IComparer<T1,T2>. Плохо искал? Опять свой код.

D>>У List<T> есть куча Find'ов от предиката, например. Внутри предиката Вам никто не мешает позвать какой Вашей душе угодно IComparer...
КД>Find-ы я не смотрел, потому что линейный поиск не интересовал. А вот BinarySearch-а по предикату не наблюдается.
КД>int BinarySearch(int index, int count, T item, IComparer<T> comparer)
КД>int BinarySearch(T item)
КД>int BinarySearch(T item, IComparer<T> comparer)

КД>как мне искать не T, а TKey? Я не хочу делать словари TKey->TItem. Поскольку TKey и так хранится в TItem.
Неубедительный аргумент.

Ты хочешь быстрый поиск, поэтому тебе не подходит обычный Find по предикату , но не хочешь делать словарь который даст тебе максимальную скорость поиска по ключу.

Вопрос: чего ты хочешь добиться?

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

КД>>Нет, просто надежный и, по-возможности, красивый код. Это долго, дорого и мутно, но в конечном итоге — быстрее и дешевле чем ...
G>Суд по постам — идешь ровно к обратному.

G>Ты хочешь быстрый поиск, поэтому тебе не подходит обычный Find по предикату , но не хочешь делать словарь который даст тебе максимальную скорость поиска по ключу.

Я смотрю на все эти вещи под другим углом И я уже не стесняюсь говорить то, что я о них думаю на самом деле

>Вопрос: чего ты хочешь добиться?
Откуда такой недетский интерес к моим милым развлечениям?

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

F>> Да, это в unsafe. Но, незачем его так избегать, ничего в нём плохого нет. Использование IntPtr не менее unsafe, чем unsafe который ключевое слово, если его применять так же как указатели, или с такими наворотами. Более того, использование нормальных указателей — позволяет получить типо-безопасный код, в отличии прыжков с IntPtr.
КД>Спасибо, я прислушаюсь к этому совету
Тут всё же надо изучать вопрос поплотнее. Из очевидных недостатков — PEVerify будет ругаться, типа unexpected type on stack. Даёт ли это какие-то конкретные ограничения — я честно говоря не знаю, сам проблем не замечал, но этот вопрос нужно рассматривать внимательнее, или кто подскажет? По идее это делает код неверифицируемым, и насколько я понимаю что, что бы его выполнится — понадобится скип проверок — тут надо смотреть где и как твоя сборка будет использоваться и подходит ли это тебе. Я так понимаю что локальные сборки (загруженные с локального диска) не проверяются, и не ограничиваются в плане выполнения неверифицируемого кода. (Повторюсь — проверять / изучать).
Сам я их использую достаточно активно, потому как без информации о типе легко запутаться, и это мне уже сэкономило массу времени. Да и когда-никогда я получаю указатель на массив указателей — вот и адресная арифметика, в нормальном синтаксисе. И это максимально близко к реально происходящим процессам.

PS: Да, с IntPtr они и правда перемудрили, String.Format до сих пор в 32-х битном процессе форматируя IntPtr иногда может выдать 9 знаков.

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

КД>Ну, вообще говоря, постижение я начал с того, что вдумчиво прочитал Рихтера.

Вопрос не в этом. Вопрос в том, зачем Вам interop

КД>Не угадал — я переехал с паскаля

Я ничего и не угадывал. Это всего лишь перенос стиля Ваших вопросов по .NET на случай миграции с C на C++.

КД>Нет, просто надежный и, по-возможности, красивый код.

Так пишите его. Только вот зачем Вам для этого interop ???

D>>Позволяет C# 2.0 и выше. А код той сериализации был написан ещё во времена самой первой версии .NET\C#

КД>Дык, надо трясти базовый код.

Конечно же не надо. Этот код уже используют миллионы приложений\библиотек. Любая, даже самая минимальная, правка там — потенциальные массовые грабли с их совместимостью. И именно поэтому нормальные люди базовые библиотеки практически не изменяют, а только расширяют.

КД>Find-ы я не смотрел, потому что линейный поиск не интересовал.

List совершенно не обязан быть отсортированным, да ещё и по какому-то левому оператору. Формулируйте вопросы точнее.

КД>как мне искать не T, а TKey?

List<T> хранит объекты типа T. Причём здесь какой-то левый TKey ???

КД>Я не хочу делать словари TKey->TItem. Поскольку TKey и так хранится в TItem.

Ну так и реализуйте соответствующий IComparer<T>, который будет сравнивать T, используя его поля\свойства с этим Вашим TKey.

*И эти люди ~15 лет писали на С++

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

А>Ну это неправда. У MSVC есть некоторые расхождения

Какие ещё "некоторые расхождения" ??? Я об intrinsic'ах, всяких хренях типа __declspec, атрибутах и т.д. и т.п.

А>Дык примерно так я и пишу все программы на C++, с reference counting'ом.

Опять двадцать пять. Система типов это не подсчёт ссылок.

А>А в чем профит перед C++/CLI, учитывая идентичный поганый синтаксис?

В том, что на выходе нативный код. Это interop реализованный с другой стороны.

А>Не понял эту реплику. А WinRT что дает для Windows Phone?

Открывает платформе путь для запуска стороннего нативного кода. WinRT это новый binding для системных API, нормально типизированный и контролируемый.

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

G>>Ты хочешь быстрый поиск, поэтому тебе не подходит обычный Find по предикату , но не хочешь делать словарь который даст тебе максимальную скорость поиска по ключу.

КД>Я смотрю на все эти вещи под другим углом
Под каким?


>>Вопрос: чего ты хочешь добиться?
КД>Откуда такой недетский интерес к моим милым развлечениям?

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

x64>... Но зачем нужен новый C++? Зачем нужен COM (не важно в каком виде), если есть .Net? Короче, может кто-нибудь вразумительно ответить на эти вопросы? ... Но внезапно я узнаю, что появился какой-то там ещё WinRT, а чем он лучше для моей задачи, — мне не понятно, что мне делать?
Появилась не просто среда WinRT, а переписывается на нем весь API винды, а реально напишут сколько успеют. И теперь можно использовать весь этот API из обычных проектов на C#, делая ссылки как на .NET сборки, и не возиться с обертками.
Думаю новый WinCPP они делали в первую очередь для себя, но чтоб добро не пропадало выложили как продукт.
Подразделение занимающееся виндой отвергло .NET как вариант на чем можно переписать WinAPI, из-за проблем с производительностью.

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

D>Ну так и реализуйте соответствующий IComparer<T>, который будет сравнивать T, используя его поля\свойства с этим Вашим TKey.

class TData
{
 string key;

 //а здесь много много больших данных.
};

List<TData> list;

А теперь покажи мне реализацию стандартного IComparer<T>, которая позволит искать в list по string

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

S_S>Подразделение занимающееся виндой отвергло .NET как вариант на чем можно переписать WinAPI, из-за проблем с производительностью.
Лучше бы они вместо отвержения, продавили оптимизацию .Net. Ну, ладно. Если фича с простым подключением натива, как сборок, будет работать, то круто.

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

MM>Лучше бы они вместо отвержения, продавили оптимизацию .Net.

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