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

AB>И вопрос тут не в том, что ребята решили создать новый COM. Может он и нужен для низкоуровневых работ, а именно в том, что они решили продлить агонию С++ превратив его из кошмарного франкенштейна (чего стоит синтаксис лямбд) с замусоренным синтаксисом в нечто совсем уж убожеское. Надо было создавать новый язык. Пусть низкоуровневый, но новый.

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

Главная проблема в том, что сейчас WinRT нет у 100% юзеров. Когда выйдет Win8, WinRT будет у тех кто поставит Win8. Может сделают WinRT для Win7, Vista, и даже xpsp3, это будет сколько-то десятков Мб которые надо будет скачать. Но у основной массы юзеров WinRT появится лет через 5.
ИМО будет проще потребовать чтоб юзера был .NET, чем WinRT.

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

КД>Я вообще сижу под VS2010 и генерирую код под NET4. А 2008 (NET3.5) я юзаю чисто как средство для доп. проверок. Привычка такая — чем нибудь еще откомпилировать и проверить. Вот и обнаруживаются такие вот забавные вещи.

А не пробовал использовать VS2010 и компилятор С#4 и собирать под 3.5 фреймворк?

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

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

То ли у тебя полная каша в голове насчет шарпа и фреймворка, то ли ты не можешь нормально объяснить, что хочешь:

public interface IKeyedItem<out TKey>
{
    TKey Key { get; }
}

public static class ListHelper
{
    public static int BinSearchByKey<TKey, TItem>(this List<TItem> list, TKey key, IComparer<TKey> comparer)
        where TItem : IKeyedItem<TKey>
    {
        return list.BinarySearch(default(TItem), new KeyComparer<TKey, TItem>(key, comparer));
    }

    private class KeyComparer<TKey, TItem> : IComparer<TItem>
        where TItem : IKeyedItem<TKey>
    {
        private readonly TKey _key;
        private readonly IComparer<TKey> _comparer;

        public KeyComparer(TKey key, IComparer<TKey> comparer)
        {
            _key = key;
            _comparer = comparer;
        }

        public int Compare(TItem x, TItem y)
        {
            return _comparer.Compare(x.Key, _key);
        }
    }
}

internal class Program
{
    class MyItem : IKeyedItem<string>
    {
        public string Key { get; set; }
    }

    private static void Main(string[] args)
    {
        var items =
            new List<MyItem>
                {
                    new MyItem { Key = "1" },
                    new MyItem { Key = "2" },
                    new MyItem { Key = "3" }
                };
        Console.WriteLine(items.BinSearchByKey("2", StringComparer.OrdinalIgnoreCase));
    }
}

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

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

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

Я же намекал — всё также как в стандартном C++. Контракт BinarySearch аналогичен схеме используемой binary_search\equal_range. Поэтому либо передаёте — прямо в BinarySearch — dummy-объект TData, у которого key проставлен в то что надо искать. Либо определяете некоторый выделенный объект TData — можно и null взять, лишь бы не встречался в качестве содержимого списка — и засовываете вместе с ключом для поиска в реализацию IComparer<TData>.

Понятно ? Или без кода не осилите ?

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

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

Ваш код кривой В Compare(TItem x, TItem y) Вы на ключ для поиска всегда маппите параметр y, тогда как сравнивающий может подавать тот объект что он ищет и в качестве x.

Хотя работать скорее всего будет, бо в текущей реализации потроха List<T>.BinarySearch передают искомый объект в Compare — ну как минимум на генерическом пути исполнения — в качестве второго параметра

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

AVK>То ли у тебя полная каша в голове насчет шарпа и фреймворка, то ли ты не можешь нормально объяснить, что хочешь

Охх, ну зачем так всё усложнять? Нужен только Ilspy и 10-15 минут времени:

    public static int BinarySearch<T, TKey>(
      this IList<T> values, TKey key, Func<T, TKey, int> comparison)
    {
      Code.NotNull(values, "values");
      Code.NotNull(comparison, "comparison");

      return BinarySearchCore(values, 0, values.Count, key, comparison);
    }

    public static int BinarySearch<T, TKey>(
      this IList<T> values, int startIndex, int count, TKey key, Func<T, TKey, int> comparison)
    {
      Code.NotNull(values, "values");
      Code.NotNull(comparison, "comparison");
      EnumerableCode.ValidIndex(startIndex, "startIndex", values.Count);
      EnumerableCode.ValidCount(count, "count", values.Count - startIndex);

      return BinarySearchCore(values, startIndex, count, key, comparison);
    }

    // BASEDON: System.Collections.Generic.ArraySortHelper<T>.InternalBinarySearch()
    private static int BinarySearchCore<T, TKey>(
      IList<T> values, int startIndex, int count, TKey key, Func<T, TKey, int> comparison)
    {
      bool succeed = false;
      int searchIndex = startIndex;
      int maxIndex = startIndex + count - 1;

      while (searchIndex <= maxIndex)
      {
        int newSearchIndex = searchIndex + ((maxIndex - searchIndex) >> 1); // searchIndex + ((maxIndex - searchIndex) / 2)
        int comparisonResult = comparison(values[newSearchIndex], key);

        if (comparisonResult == 0)
        {
          searchIndex = newSearchIndex;
          succeed = true;
          break;
        }
        else if (comparisonResult < 0)
        {
          searchIndex = newSearchIndex + 1;
        }
        else
        {
          maxIndex = newSearchIndex - 1;
        }
      }

      return succeed ? searchIndex : ~searchIndex;
    }

По-хорошему надо бы сделать отдельную перегрузку для массивов, но и так сойдёт.

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

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

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

D>Я же намекал — всё также как в стандартном C++. Контракт BinarySearch аналогичен схеме используемой binary_search\equal_range. Поэтому либо передаёте — прямо в BinarySearch — dummy-объект TData, у которого key проставлен в то что надо искать. Либо определяете некоторый выделенный объект TData — можно и null взять, лишь бы не встречался в качестве содержимого списка — и засовываете вместе с ключом для поиска в реализацию IComparer<TData>.

D>Понятно ? Или без кода не осилите ?

1. Мне не нужен dummy. А если TData — хрень с финализатором? Нафига такое счастье?
2. std::binary_search — это совсем не тоже самое что List.BinarySearch. Впрочем, std::lower_bound — тоже другое.

Надо просто по-другому думать. Если FW что-то предлагает делать через ... — то это не значит, что именно так нужно поступать.

Задача поиска в List<TData> по TKey решается с помощью таких конструкций:
IComparer2

	Скрытый текст
	//////////////////////////////////////////////////////////////////////////////// //interface IComparer2_Base public interface IComparer2_Base<T1,T2,tagID> { int Compare(T1 a,T2 b); };//interface IComparer2_Base //////////////////////////////////////////////////////////////////////////////// public class tagComparer2_Base_ID1<T1,T2>{}; public class tagComparer2_Base_ID2<T1,T2>{}; public class tagComparer2_Base_ID3<T1,T2>{}; public class tagComparer2_Base_ID4<T1,T2>{}; //////////////////////////////////////////////////////////////////////////////// //interface IComparer2 public interface IComparer2<T1,T2>:IComparer2_Base<T1,T2,tagComparer2_Base_ID1<T1,T2>>, IComparer2_Base<T2,T1,tagComparer2_Base_ID2<T1,T2>>, IComparer2_Base<T1,T1,tagComparer2_Base_ID3<T1,T2>>, IComparer2_Base<T2,T2,tagComparer2_Base_ID4<T1,T2>> { };//interface IComparer2

lower_bound

	Скрытый текст
	//////////////////////////////////////////////////////////////////////////////// //class lower_bound public static class lower_bound { static public int exec<TItem,TKey>(IList<TItem> container, TKey key, IComparer2<TItem,TKey> comparer) { Debug.Assert(container!=null); Debug.Assert(comparer!=null); int left=0; int right=container.Count; while(right>left) { int middle=left+(right-left)/2; Debug.Assert(right>middle); Debug.Assert(comparer.Compare(container[left],container[middle])<=0); if(comparer.Compare(container[middle],key)<0) { left=middle+1; continue; } right=middle; }//for[ever] return left; }//exec //----------------------------------------------------------------------- static public int exec<TKey>(IList<TKey> container, TKey key, IComparer<TKey> comparer) { Debug.Assert(container!=null); Debug.Assert(comparer!=null); int left=0; int right=container.Count; while(right>left) { int middle=left+(right-left)/2; Debug.Assert(right>middle); Debug.Assert(comparer.Compare(container[left],container[middle])<=0); if(comparer.Compare(container[middle],key)<0) { left=middle+1; continue; } right=middle; }//for[ever] return left; }//exec }//class lower_bound

t_search_result

	Скрытый текст
	public struct t_search_result<TPosition> { public TPosition position; public bool result; public t_search_result(TPosition pos,bool res) { this.position=pos; this.result =res; }//t_search_result };//struct t_search_result

lower_search

	Скрытый текст
	public static class lower_search { public static t_search_result<int> exec<TItem,TKey>(IList<TItem> container, TKey key, IComparer2<TItem,TKey> comparer) { Debug.Assert(container!=null); Debug.Assert(comparer!=null); int x=lower_bound.exec(container,key,comparer); Debug.Assert(x>=0); Debug.Assert(x<=container.Count); if(x<container.Count) { int c=comparer.Compare(key,container[x]); if(c==0) return new t_search_result<int>(x,true); Debug.Assert(c<0); }//if return new t_search_result<int>(x,false); }//exec //----------------------------------------------------------------------- public static t_search_result<int> exec<TKey>(IList<TKey> container, TKey key, IComparer<TKey> comparer) { Debug.Assert(container!=null); Debug.Assert(comparer!=null); int x=lower_bound.exec(container,key,comparer); Debug.Assert(x>=0); Debug.Assert(x<=container.Count); if(x<container.Count) { int c=comparer.Compare(key,container[x]); if(c==0) return new t_search_result<int>(x,true); Debug.Assert(c<0); }//if return new t_search_result<int>(x,false); }//exec };//class lower_search

Дарю. Код оттестирован.

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

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

AVK>То ли у тебя полная каша в голове насчет шарпа и фреймворка, то ли ты не можешь нормально объяснить, что хочешь:

Возможно, возможно.

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

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

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

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

D>>Я же намекал — всё также как в стандартном C++. Контракт BinarySearch аналогичен схеме используемой binary_search\equal_range. Поэтому либо передаёте — прямо в BinarySearch — dummy-объект TData, у которого key проставлен в то что надо искать. Либо определяете некоторый выделенный объект TData — можно и null взять, лишь бы не встречался в качестве содержимого списка — и засовываете вместе с ключом для поиска в реализацию IComparer<TData>.

D>>Понятно ? Или без кода не осилите ?

КД>1. Мне не нужен dummy.
Ага, тебе нужен Dictionary

КД>А если TData — хрень с финализатором? Нафига такое счастье?
И много у тебя такого?

КД>Надо просто по-другому думать. Если FW что-то предлагает делать через ... — то это не значит, что именно так нужно поступать.
Это ты предлагаешь делать через это самое место. Для поиска по ключу есть словари.

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

КД>IComparer2

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

Хотя, для использования в отладочном коде — вполне нормально.

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

AVK>>То ли у тебя полная каша в голове насчет шарпа и фреймворка, то ли ты не можешь нормально объяснить, что хочешь

S>Охх, ну зачем так всё усложнять? Нужен только Ilspy и 10-15 минут времени:

S>По-хорошему надо бы сделать отдельную перегрузку для массивов, но и так сойдёт.

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

Через делегат такую поддержку не протащишь.

Не люблю такой код

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

КД>Следуя своей любимой тактике, ну понятно какой, замечу, что твой алгоритм не позволяет (в отладочном режиме, естественно) контролировать упорядоченность исходного массива.

Это не мой алгоритм, честная копипаста из System.Collections.Generic.ArraySortHelper<T>.InternalBinarySearch().

Если требуется проверить сортировку массива — почему бы не делать этого отдельным методом и не городить тонну добавочных классов и интерфейсов?

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

S>Охх, ну зачем так всё усложнять?

Забавное понимание упрощения — написать код в несколько раз больше и сложнее.

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

D>Ваш код кривой В Compare(TItem x, TItem y) Вы на ключ для поиска всегда маппите параметр y, тогда как сравнивающий может подавать тот объект что он ищет и в качестве x.

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

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

S>>Охх, ну зачем так всё усложнять?

AVK>Забавное понимание упрощения — написать код в несколько раз больше и сложнее.
Зато он не опирается на недокументированное поведение и не требует промежуточных классов

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

AVK>>Забавное понимание упрощения — написать код в несколько раз больше и сложнее.
S>Зато он не опирается на недокументированное поведение и не требует промежуточных классов

Это все понятно. Но проще это назвать ну никак нельзя.

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


G>WinRT ... все это можно прочитать по ссылке выше (хотя информации пока немного, надеюсь будут обновлять оперативно). Но самое главное уже более-менее понятно. Перед нами новая версия COM.

Тут будет очень кстати вспомнить краткую историю программных революций от Microsoft:

История программных революций от Microsoft, вкратце: Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они!

Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.

Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через броузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).

Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции «System File Protection», исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java — её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.

Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.

К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс-релизов. Главное, что нужно очень четко понимать — .NET исключает DLL Hell.

В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.

Ну, что же, группа операционных систем (или это была группа COM?) громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к WinRT! Они в очередной раз нашли фатальный недостаток, на этот раз, в .NET и COM сразу. Ну, вы знаете какой!

ЗЫ

Всем запастись попкорном и ждать новых серий из цикла "краткие истории программных революций от Microsoft". Ведь WinRT наверняка революционно изменит Windows-программирование... примерно на год

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

x64>Всё же, я думаю, это в раздел Win32 надо было. Потому что вот меня, например, больше беспокоит вопрос: зачем это всё, в смысле, какую цель преследует этот WinRT и какие задачи/проблемы призван решить? ... Но внезапно я узнаю, что появился какой-то там ещё WinRT, а чем он лучше для моей задачи, — мне не понятно, что мне делать?

Наивный ты. Видимо ты никогда не читал краткую историю революций от Майкрософт

Автор: VladD2
Дата: 09.10.11

.

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


Смайлик, в основном, вот за это высказывание:

КД>Справа от моего имени есть ссылочка на нефиговый по размерам проект, где все это (COM/MT/ref count) согласованно работает вместе без каких либо проблем.

Не обижайся, но только использование КОМ и С++ позволило вам сделать из провайдера к СУБД "нефиговый по размерам проект". На самом же деле провайдер к БД это весьма примитивный и незначительный по размерам проект. Но для этого, правда, надо дружить с головой понимать с чем имеешь дело

Для примера объем кода одного из самых сложный языков программирования занимает около двух мегабайт.