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


Можно я покоментирую\поспорю, исключительно ради истины?

C>1.Проверки на bool. Везде пишете ==false, в C# для булевых переменных не принятно обычно
В с++ это как раз не тоже принято. Это я ошибся. Когда читал книжку там написано что в отличии от с++, в шарпе нельзя в логических выражениях использовать равенство нулю\не нулю, а надо явно проверять на значение. То есть вместо if (str.Length), надо писать if (str.Length > 0), мне это не понравилось и я запомнил. А когда писал код, почему-то решил что и bool b = true; if (b); тоже нельзя писать, а надо обязательно if (b = true) использовать. Но это каюсь моя ошибка просто, но не как не уши С++, где повторюсь так не пишут.

C>2.Привычка к for.
Чем это плохо? И какие конкретно for в моем коде надо заменить на другой типа цикла?

C>3.Привычка к ++i, а не i++.
это да, чисто из плюсов, ну это автоматически. В принципе при необходимости за неделю можно переучится.


C>4.Внутри lock вроде дополнительный Monitor.Wait не нужен.
ну это зависит от логики приложения В блокирующей очереди нужен иначе работать не будет.


C>5.Префиксы режут глаз.
Префиксы (если вы про _ у приватных полей)определены стандартом кодирования, мне тоже не нравятся, но пришлось сделать.


C>6.Названия переменных не слишком говорящие.
хм, чисто субъективно не согласен, мне все говорящие Но это субъективно, но в любом случае не говорит о том что программа написана "на с++, а не на с#" как сказали мне.


C>7.Смешение автосвойств и свойств с backing field. Сейчас в принципе наблюдается тенденция использовать автосвойства, если не нужна логика выставления/получения значений дополнительная.
Ну везде где было можно я использовал автосвойства, там где было нельзя — писал свои. Или стоило отказаться от автосвойств вообще, если я не могу сделать все свойства автоматическими?


C>8.Выход из вечного цикла по исключению — как-то не очень кошерно. В целом в C# не принято включать throw как стандартную ветку исполнения кода(вопрос дискуссионный).
Пример взят прямо из мсдн. При использовании Take() в блокирующей очереди нет другого свойства выйти из цикла.

C>9.Непонятен смысл метода CompleteAdding().
Видимо вы не писали или не работали с блокирующими очередями Я вот тоже еще 10 дней назад о них не слышал, но сейчас я понимаю зачем нужен CompleteAdding(). И кстати оно слизанно со стандартной реализации блокирующей очереди в .Net 4.0

C>10.Для многопоточной записи/выборки объектов используется ConcurrentQueue. При ее использовании куча локов уходит.
да, у меня первый класс (тут его не показывал) тоже реализовывал задание 5 строчками — был просто пустой класс наследник от стандартной блокирующей очереди, но я решил что такое за тестовое задание не защитают Да и C# попробовать хотелось, поэтому написал свой велосипед — все-таки это тестовое задание...

    public class BegBlockedQueue1<T> : BlockingCollection<T>
    {
        public BegBlockedQueue1() : base(new ConcurrentQueue<T>())
        {
        }

        public BegBlockedQueue1(int boundedCapacity) : base(new ConcurrentQueue<T>(), boundedCapacity)
        {
        }
    }

C>В целом код неплохой довольно.
это радует