V>namespace ConsoleApp2
V>{
V> public interface IMyEnumerable<T, out TEnumerator> //: IEnumerable<T>
V> where TEnumerator : struct, IMyEnumerator<T> {
V> TEnumerator GetEnumerator();
V> }
V> public interface IMyEnumerator<out T> {
V> T Current { get; }
V> bool MoveNext();
V> void Reset();
V> }
V>
В интерфейсе IMyEnumerable констрейнт struct для энумератора надо убрать, он не нужен на этому уровне, неоправданно жёсткое ограничение. При желании/необходимости его можно всегда можно навесить позже в алгоритмах, которые работают через IMyEnumerable. Чтобы для клиента, использующего эти абстракции, struct был опцией, а не требованием.
Интерфейс же IMyEnumerator можно пофиксить от родовой травмы, применив более идиоматичный заменитель maybe/опциона:
public interface IMyEnumerator<out T>
{
bool TryMoveNext(out T current);
void Reset();
}
Глаза у меня добрые, но рубашка — смирительная!
Re[3]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Это когда баг в Dеbug найти не удается (или он там почему-то не проявляется)
Память в дебаге обнуляется в MSVC++.
И это реальная неприятность.
Хорошо помогает этот же код отлаживать в Linux под valgrind-ом.
Сейчас можно прямо из Студии — всё то же самое: брейкпоинты, переменные, стеки, потоки и т.д.
Замечательно в дебаге все баги проявляются.
Докер, SSH на стороне контейнера, в Студии прописывается адрес/порт для подключения, создаётся проект для Linux (их несколько видов) и гоу.
Здравствуйте, Qbit86, Вы писали:
Q>В интерфейсе IMyEnumerable констрейнт struct для энумератора надо убрать, он не нужен на этому уровне, неоправданно жёсткое ограничение. При желании/необходимости его можно всегда можно навесить позже в алгоритмах, которые работают через IMyEnumerable. Чтобы для клиента, использующего эти абстракции, struct был опцией, а не требованием.
Тут на вкус и цвет.
В своём коде я часто делаю именно так для целей контроля, бо свои интерфейсы я чаще всего прописываю именно и только для value-типов и соотв. генерик-алгоритмов.
И мы как раз обсуждаем, как убежать от боксинга в Linq.
Я лишь хотел показать в каком месте linq навернётся.
От ограничения struct там ничего не меняется.
Q>Интерфейс же IMyEnumerator можно пофиксить от родовой травмы, применив более идиоматичный заменитель maybe/опциона: Q>
Здравствуйте, Qbit86, Вы писали:
Q>В интерфейсе IMyEnumerable констрейнт struct для энумератора надо убрать, он не нужен на этому уровне, неоправданно жёсткое ограничение.
Вдогонку — а какой тогда вообще в констрейне смысл, когда он один, если не для value-type? ))
Для ref-типов можно расписать прямо на интерфейсах — это будет в точности то же самое, что на констрейнах, только писанины поменьше.
Re[27]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, samius, Вы писали:
S>Специально перечитал посты Синклера. Идея сравнения скорости двумерного массива с одномерным — не его.
Его, его. ))
У двумерного массива для доступа к элементу вызываются специальные методы класса-массива.
А в случае одномерного массива компилятор подставляет тупо опкоды со смещением по индексу.
Вот Синклер и подменил одно на другое (в числе прочего).
Эта фишка известна еще с забытых 2003-х годов.
Здравствуйте, Danchik, Вы писали:
I>>>Расскажи лучше, из за чего Linq тормозит. А то vdimas, alex_public и многие другие уверены, что из-за рефлексии, но не могут ни показать, не доказать S>>Расскажи, в каком конкретно случае и с чем именно сравниваем. А то мне за весь Linq как-то сложно отдуваться. D>Думаю становится третим КО не стоит. Им толкуют об одном, а они обсусоливают очевидные вещи о другом.
О каком КО речь? Похоже, ты до сих пор не понял сути спора.
Так шта, давай уж я немного побуду для тебя КО — Синклер ускорил свой пример в основном за счёт оптимизации доступа к двумерному массиву.
Задача эта по-своему благородная, но не имеет отношения конкретно к Linq, на что я сразу же и указал: http://www.rsdn.org/forum/dotnet/7187266.1
Поэтому, далее я поэкпериментировал в этом же направлении, показав, что подобные техники могут быть полезны и при "обычной" записи алгоритма, безо-всякого Linq.
Теперь прояснилось? ))
Re[30]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, vdimas, Вы писали:
V>Память в дебаге обнуляется в MSVC++.
ЕМНИП не обнуляется, а туда какой-то код заносится, чтобы он по возможности исключение генерировал при попытке использовать неинициализированное значение. Помню, там что-то вроде 0xbdbdbdbd где-то было.
With best regards
Pavel Dvorkin
Re[28]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
V>>>Давай дождёмся когда развенчает. )) I>>Уже. Вдвое ускорил, это мало ?
V>Задачу зато не решил. V>Я не могу взять произвольный алгоритм из этого же класса и воспользоваться его "наработками".
Можешь.
Вот так записывается c8-усреднение:
from d in data select (d[-1, -1]+d[-1, 0]+d[-1, 1]
d[ 0, -1]+ d[ 0, 1]
d[-1, -1]+d[ 1, 0]+d[ 1, 1])/8;
А вот так — усреднение "по горизонтали":
from d in data select (d[0, -2]+d[0, -1]+d[0, 0]+d[0, 1]+d[ 0, 2])/5
Было бы интересно посмотреть на "произвольный алгоритм из этог же класса", который не получится взять и воспользоваться.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Qbit86, Вы писали:
Q>Интерфейс же IMyEnumerator можно пофиксить от родовой травмы, применив более идиоматичный заменитель maybe/опциона: Q>
Здравствуйте, Sharov, Вы писали:
S>Как это решит проблему?:xz:
Это смотря какую. Я думал, речь шла про сделать с нуля свою независимую иерархию базовых компонентов вместо существующей стандартной, и базировать алгоритмы на ней. Если так, то в новой переписанной версии нет смысла повторять ошибки существующей легаси.
Глаза у меня добрые, но рубашка — смирительная!
Re[31]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>ЕМНИП не обнуляется, а туда какой-то код заносится, чтобы он по возможности исключение генерировал при попытке использовать неинициализированное значение. Помню, там что-то вроде 0xbdbdbdbd где-то было.
Предлагаю прогнать на своей рабочей Студии вот это:
#include <iomanip>
#include <iostream>
class Base {
private:
size_t i;
};
class Derived : Base {};
template<typename T>
void test() {
using namespace std;
T * t = new T();
cout << "new T(): " << hex << setfill('0') << setw(sizeof(size_t) * 2) << *(size_t*)t << std::endl;
T * t1 = t;
delete t1;
cout << "delete t: " << hex << setfill('0') << setw(sizeof(size_t) * 2) << *(size_t*)t << std::endl;
t = new T;
cout << "new T: " << hex << setfill('0') << setw(sizeof(size_t) * 2) << *(size_t*)t << std::endl;
t1 = t;
delete t1;
cout << "delete t: " << hex << setfill('0') << setw(sizeof(size_t) * 2) << *(size_t*)t << std::endl;
}
int main()
{
using namespace std;
cout << "Base:" << std::endl;
test<Base>();
cout << std::endl;
cout << "Derived:" << std::endl;
test<Derived>();
return 0;
}
Мои результаты:
Debug:
Base:
new T(): 0000000000000000
delete t: dddddddddddddddd
new T: cdcdcdcdcdcdcdcd
delete t: dddddddddddddddd
Derived:
new T(): 0000000000000000
delete t: dddddddddddddddd
new T: cdcdcdcdcdcdcdcd
delete t: dddddddddddddddd
Release:
Base:
new T(): 0000000000000000
delete t: 0000000000000000
new T: 6e69575c32336d65
delete t: 6e69575c32336d65
Derived:
new T(): 0000000000000000
delete t: 0000000000000000
new T: 4620004300000000
delete t: 4620004300000000
Здравствуйте, Qbit86, Вы писали:
Q>Это смотря какую. Я думал, речь шла про сделать с нуля свою независимую иерархию базовых компонентов вместо существующей стандартной, и базировать алгоритмы на ней. Если так, то в новой переписанной версии нет смысла повторять ошибки существующей легаси.
Да ХЗ насчёт ошибок легаси.
В твоей версии значение берется всегда, даже когда оно не нужно на очередной итерации.
Re[29]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, vdimas, Вы писали:
V>Это у тебя сейчас рвануло, как обычно.
Ты так смешно ведешься, что не возможно удержаться =)
V>Иначе бы он не напорол ошибок еще в первом же сообщении.
Ошибок, кроме тебя, в этом топике пока никто не делал. А тебе удалось посадить их пяток в одном сообщении, от алгоритмических до синтаксических. И чем громче ты пытаешься перевести стрелки на Антона, тем заметнее становится, кто на самом деле налажал. А так как у тебя не хватает тормозов во время остановиться, то мы еще долго будем наблюдать за феерией "я вовсе не это имел ввиду", "да вы ни фига не понимаете" и "я тут один молодец", до тех пор, пока не надоест тебя стебать
V>Скажи, неужели бока обещанного "решения" не были тебе видны еще с самого первого поста?
С самого первого твоего поста в этот топик, отчетливо видно следующее:
— ты не умеешь внимательно читать или намеренно интерпретировал контекст так, чтобы было с чем докопаться до собеседника.
— ты намеренно скрываешь детали своих утверждений, чтобы потом оставалось пространство для маневра, а то как доходит до деталей, то сразу вылезают ошибки от которых сложно отмазаться.
V>В отличие от синклера я как раз решил именно ту задачу — покрыл целый класс похожих алгоритмов.
Задача была сформулирована даже не Антоном, а alex_public. Антон эту задачу процитировал в самом первом сообщении. И при решении этой задачи ты конкретно на косячил.
И ни какие отмазки этот факт не замажут. Так что, друг мой, да, в твоем решении алгоритмические ошибки, как бы ты не изворачивался.
V>Т.е. тебе опять двойка за неумение читать код.
От кого и хула похвала =)
V>Более того, ни в одном сообщении не указал, что у меня есть полный аналог кода Синклера, бо для соревнований нужны оба решения, ес-но, не только моё.
Для решения указаной задачи, чужой код не нужен. Можешь ее решить красиво? Код в студию, посмотрим, оценим и если твой подход действительно будет удачнее — признаем твою правоту.
V>Я наехал на Синклера за его нечестность.
Подозреваю, что тот Синклер в твоей голове с которым ты споришь, не имеет никакого отношения к Антону. Но то что тебе на самом деле просто "тон" не понравился, ты признался уже давно.
Натурально, как дурная девица в критические дни =)
Здравствуйте, vdimas, Вы писали:
V>В твоей версии значение берется всегда, даже когда оно не нужно на очередной итерации.
Зато нельзя обратиться к Current, не позвав TryMoveNext(). То есть их зависимость выражена синтаксически. В крайнем случае, можно добавить перегрузку TryMoveNext() без параметров.
Reset() я бы тоже выкинул.
Глаза у меня добрые, но рубашка — смирительная!
Re[30]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, vdimas, Вы писали:
V>Опять непонимающего включил... V>Так что там у нас с краевыми эффектами?
А что с ними не так? V>Один эффект на всех? ))
Конечно. Не требовать же вручную единички прибавлять.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: 2D-Linq и оптимизация цифровых фильтров - 3
Мы уже победили, просто это еще не так заметно...
