Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>Рекомендую на досуге ознакомиться с определением IEnumerable и глупостей больше не писать.
Я, конечно, виноват, что перепутал IEnumerable с IEnumerator . В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны. Их на С/C++ нет и без них я до сих пор вполне обходился там и буду дальше.
PD>>Дело не в исчерпании пространства, а в том, что невозможно для больших файлов уложить их целиком в это АП. Поэтому придется это делать по частям, то есть иметь 2 view — один текущий, другой для конца. И текущий будешь переоткрывать и двигать. S>(Вздыхает).
Тебе только это и остается.
S>1. Павел, а кто тебе сказал, что всё АП принадлежит твоей функции?
О господи! Если уж АП начало принадлежать функциям... приехали.
>Поэтому слово "больших" тут не нужно. Речь идёт об исчерпании АП, и вовсе не обязательно иметь пятигигабайтный файл, чтоб на него нарваться.
М-да. Глубокая мысль. Как говорил Воланд, "без тебя мы никак бы не догадались"...
Поясняю. Работая с mmf файлами, вполне достаточно иметь на один view 4 Кбайта (регион будет, правда, 64 Кбайта). Независимо от длины файла. Передвигая это окно, можно пройти весь файл, не затратив больше ни одного байта.
S>2. Не вижу никакой причины иметь два view. IEnumerable во view вообще не нуждается. Иди посмотри, как он устроен.
Как устроен IEnumerable — мне сейчас не важно. Но для если для реализации Next и Last через mmf ты можешь обойтись без view — код в студию.
А теперь по существу. Если ты будешь иметь только один view, то для того, чтобы спозиционироваться на конец файла в то время, когда ты итерируешь его от начала и где-то внутри этого процесса, тебе придется этот view закрыть, переоткрыть его заново на конец файла, предварительно запомнив текущую позицию, а потом выполнить обратное действие. Это далеко не так дешево. Так что советую познакомиться еще раз с тем, как устроены memory-mapped файлы и как с ними работают. Хоть с IEnumerable, хоть без него — mmf эти примочки безразличны.
S>Логика действий — неумолимая. Я реализую класс, который предоставляет доступ к строкам файла как к коллекции.
Можно пример кода для 10 Гб файла ? С методами Next (следующая строка) и Last (последняя). На базе mmf.
S>И я могу сделать одинаково эффективный доступ как по очереди, так и с конца. Вот только логика чтения файла тут изолирована от алгоритма, который ею пользуется.
И что ? Ты упорно пытаешься вломиться в открытую дверь. Если мне это будет нужно, я сделаю то же самое, без всяких IEnumerable и т.д. Или ты уж впрямь думаешь, что на С++, где этого добра нет и в помине, так-таки невозможно сделать логику чтения файла независимой от алгоритма, который ею пользуется ? Если да — спешу тебя разочаровать. Это еще в 60-е год на Фортране умели.
S>Алгоритму важно сказать Last() и не париться — может, там все данные уже в памяти построчно сидят.
Ну вот и сделай для 10 Гб файла, чтобы там все данные построчно лежали. В x86
>Реализация при этом, как видишь, никак в эффективности не проигрывает.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны.
Аргумент.
S>>2. Не вижу никакой причины иметь два view. IEnumerable во view вообще не нуждается. Иди посмотри, как он устроен.
PD>Как устроен IEnumerable — мне сейчас не важно. Но для если для реализации Next и Last через mmf ты можешь обойтись без view — код в студию.
У рыбы чешуя, а не шерсть, поэтому у нее нет блох. А вот блохи это ...
... << RSDN@Home 1.2.0 alpha 4 rev. 1435 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны.
AVK>Аргумент.
При цитировании рекомендуется цитировать полностью, дабы не исказить высказывание оппонента. Поскольку ты это не сделал, сделаю за тебя.
PD>В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны. Их на С/C++ нет и без них я до сих пор вполне обходился там и буду дальше.
Так что, как видишь, аргумент вполне обоснованнный. Если не согласен — поясни, как их к обычному С++ прикрутить.
А вот твой способ дискутировать — вырвать часть фразы — я бы назвал не очень политкорректным.
PD>>В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны. Их на С/C++ нет и без них я до сих пор вполне обходился там и буду дальше.
PD>Так что, как видишь, аргумент вполне обоснованнный. Если не согласен — поясни, как их к обычному С++ прикрутить.
Да нормально они к C++ прикручиваются, я подобные классы еще когда NET не было использовал:
class Enum
{
public:
//.....bool Next();
void Reset(size_t Begin = 0);
bool End() const;
operator bool() const;
//..........
};
Часто они удобней чем STL итераторы или даже boost::range
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, FR, Вы писали:
FR>>Да нормально они к C++ прикручиваются, я подобные классы еще когда NET не было использовал:
PD>Речь идет об интерфейсах. Их в языке С++ нет.
В языке С++ есть чисто абстрактные классы, также есть шаблоны с утиной типизацией, так что не вижу
проблем чтобы прикрутить.
Здравствуйте, FR, Вы писали:
PD>>Речь идет об интерфейсах. Их в языке С++ нет.
FR>В языке С++ есть чисто абстрактные классы, также есть шаблоны с утиной типизацией, так что не вижу FR>проблем чтобы прикрутить.
Еще раз — элемента языка под названием "интерфейс" в С++ нет. Моделировать можешь как угодно.
PD>>В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны. Их на С/C++ нет и без них я до сих пор вполне обходился там и буду дальше.
PD>Так что, как видишь, аргумент вполне обоснованнный.
Ну если твои личные сексуальные пристрастия это обоснованный аргумент ... Такими аргументами можно доказать все что угодно. Вот не использую я, к примеру IOCP, ну нафик оно на моих задачах не нужен. Значит IOCP бесполезное гавно. Вместо IOCP можно подставить по вкусу.
Да, в C++ итераторы таки есть, пусть и в несколько корявом виде.
PD> Если не согласен — поясни, как их к обычному С++ прикрутить.
Здравствуйте, AndrewVK, Вы писали:
PD>>Если у тебя кроме пошлости аргументов иных нет — остается только посожалеть о твоей невоспитанности.
AVK>По остальной части возражений нет? Я так и знал.
Высказывать их желания нет — неприятно с тобой дискутировать.
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>Рекомендую на досуге ознакомиться с определением IEnumerable и глупостей больше не писать.
PD>Я, конечно, виноват, что перепутал IEnumerable с IEnumerator . В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны. Их на С/C++ нет и без них я до сих пор вполне обходился там и буду дальше.
А как же итераторы из STL от C++?
Та же ведь суть, только в профиль.
Ну и "я без них обходился" — вообще не аргумент. Некоторые люди всю жизнь писали программы в машинных кодах и отлично себя чувствовали. Но это совсем не значит, что никакие языки программирования никому не нужны.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Я, конечно, виноват, что перепутал IEnumerable с IEnumerator . В оправдание свое могу сказать, что , честно говоря, мне они оба даром не нужны. Их на С/C++ нет и без них я до сих пор вполне обходился там и буду дальше.
>>Поэтому слово "больших" тут не нужно. Речь идёт об исчерпании АП, и вовсе не обязательно иметь пятигигабайтный файл, чтоб на него нарваться. PD>М-да. Глубокая мысль. Как говорил Воланд, "без тебя мы никак бы не догадались"...
Я вижу. Ничего — вы спрашивайте, если что.
PD>Поясняю. Работая с mmf файлами, вполне достаточно иметь на один view 4 Кбайта (регион будет, правда, 64 Кбайта). Независимо от длины файла. Передвигая это окно, можно пройти весь файл, не затратив больше ни одного байта.
Молодец. Вижу, ты наконец начинаешь понимать, как можно и нужно писать программы.
S>>2. Не вижу никакой причины иметь два view. IEnumerable во view вообще не нуждается. Иди посмотри, как он устроен. PD>Как устроен IEnumerable — мне сейчас не важно. Но для если для реализации Next и Last через mmf ты можешь обойтись без view — код в студию.
Павел, ты по прежнему демонстрируешь чудеса невнимательности и неумения читать. Я написал, что ненужно два view. Ты продолжаешь, тем не менее, жить в своём воображаемом мире и спорить с воображаемыми утверждениями.
PD>А теперь по существу. Если ты будешь иметь только один view, то для того, чтобы спозиционироваться на конец файла в то время, когда ты итерируешь его от начала и где-то внутри этого процесса, тебе придется этот view закрыть, переоткрыть его заново на конец файла, предварительно запомнив текущую позицию, а потом выполнить обратное действие.
Отвечаю специально для тех, кому "не важно, как устроен IEnumerable".
Cамое простое и очевидное (для тех, кто в курсе, как устроен IEnumerable) решение — это открывать отдельный view на каждый IEnumerator.
Таким образом, для кода типа
string s = new MMFEnumerable(filePath).Last();
будет открыто ровно столько view, сколько здесь енумераторов (то есть — ноль), плюс один view для выполнения Last.
Итого — один. PD>И что ? Ты упорно пытаешься вломиться в открытую дверь. Если мне это будет нужно, я сделаю то же самое, без всяких IEnumerable и т.д. Или ты уж впрямь думаешь, что на С++, где этого добра нет и в помине, так-таки невозможно сделать логику чтения файла независимой от алгоритма, который ею пользуется ?
Я верю тому, что ты пишешь. А судя по тому, что ты никак не в состоянии представить себе мало-мальски приличную реализацию разделённого алгоритма на шарпе, то ни плюсы, ни фортран тебе тоже не помогут.
S>>Алгоритму важно сказать Last() и не париться — может, там все данные уже в памяти построчно сидят. PD>Ну вот и сделай для 10 Гб файла, чтобы там все данные построчно лежали. В x86
Павел, в отличие от тебя, большинство программистов решают не одну и ту же задачу, а всё время разные. И файлы у них тоже будут разные. Иногда — 10кб, иногда — 10gb. Поэтому никого, кроме тебя, не интересует решение, которое вычисляет последнюю строку конкретного файла на конкретной архитектуре. Интересует возможность писать библиотеки повторно используемого кода.
И с этой точки зрения вот этот воображаемый MMFEnumerable — гораздо лучше любого из решений, которые ты сразу кинешься писать в теле функции main.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: S>>>2. Не вижу никакой причины иметь два view. IEnumerable во view вообще не нуждается. Иди посмотри, как он устроен. PD>>Как устроен IEnumerable — мне сейчас не важно. Но для если для реализации Next и Last через mmf ты можешь обойтись без view — код в студию. S>Павел, ты по прежнему демонстрируешь чудеса невнимательности и неумения читать. Я написал, что ненужно два view. Ты продолжаешь, тем не менее, жить в своём воображаемом мире и спорить с воображаемыми утверждениями.
Код в студию — без двух view. С одним. Мне просто интересно, что ты напишешь
S>Cамое простое и очевидное (для тех, кто в курсе, как устроен IEnumerable) решение — это открывать отдельный view на каждый IEnumerator. S>Таким образом, для кода типа S>
S>string s = new MMFEnumerable(filePath).Last();
S>
S>будет открыто ровно столько view, сколько здесь енумераторов (то есть — ноль), плюс один view для выполнения Last. S>Итого — один.
Не подменяй. Ты же обещал, что и для Last и для Next будет один view.
S>Павел, в отличие от тебя, большинство программистов решают не одну и ту же задачу, а всё время разные. И файлы у них тоже будут разные. Иногда — 10кб, иногда — 10gb. Поэтому никого, кроме тебя, не интересует решение, которое вычисляет последнюю строку конкретного файла на конкретной архитектуре.
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>будет открыто ровно столько view, сколько здесь енумераторов (то есть — ноль), плюс один view для выполнения Last. S>>Итого — один.
PD>Не подменяй. Ты же обещал, что и для Last и для Next будет один view.
Он такого не говорил — он говорил, что не нужно иметь 2 view, если работать придется либо с Next, либо с Last, можно обойтись и одним. В данном примере как раз Next же ни разу не дергали, его view просто и не создалось. Зачем его создавать заранее, если можно создать при первом вызове?
P.S. Лично я бы, кстати, не стал делать дополнительный редко нужный метод Last() в прямом энумераторе, а лучше бы сделал альтернативный енумератор, перечисляющий строки файла в обратном порядке. И пользовался бы им в случае если нужна последняя строка, или 5 с конца строка, или "последняя строка, удовлетворяющая условию", и прямым энумератором, если бы требовалось то же самое с началом файла.
И было бы уж, думаю, любому соверешнно очевидно, что там не более 1 view (0 до начала реальной работы с энемератором).
Здравствуйте, fmiracle, Вы писали:
F>Он такого не говорил — он говорил, что не нужно иметь 2 view, если работать придется либо с Next, либо с Last, можно обойтись и одним.
Исключительно глубокая мысль. Если придется работать либо только с Next, либо только с Last, то второй view прикрутить при всем желании некуда и незачем. А вот если в цикле по Next требуется дать возможность вызвать Last, то либо второй view, либо не очень приятный код с unmap и map опять и перевычислением адресов, так как гарантии, что получишь тот же адрес, нет никакой.
В данном примере как раз Next же ни разу не дергали, его view просто и не создалось. Зачем его создавать заранее, если можно создать при первом вызове?
F>P.S. Лично я бы, кстати, не стал делать дополнительный редко нужный метод Last() в прямом энумераторе, а лучше бы сделал альтернативный енумератор, перечисляющий строки файла в обратном порядке.
Да мне хоть так, хоть этак, хоть с энумератором, хоть вообще без него. Я просто говорю — если по ходу прямого перебора строк нужно вдруг получить последнюю, придется делать новый view. А обертку делай какую хочешь.
>И пользовался бы им в случае если нужна последняя строка, или 5 с конца строка, или "последняя строка, удовлетворяющая условию", и прямым энумератором, если бы требовалось то же самое с началом файла.
F>И было бы уж, думаю, любому соверешнно очевидно, что там не более 1 view
На каждый энумератор ? Если да — то это очевидно. Если на оба энумератора — код в студию.
>(0 до начала реальной работы с энемератором).
А вот это далеко не очевидно. ИМХО лучше view открыть до начала реальной работы. Если его будешь открывать при каждой энумерации — потратишь время на вызов ядра (Map/UnmapViewOfFile) при каждой энумерации.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да мне хоть так, хоть этак, хоть с энумератором, хоть вообще без него. Я просто говорю — если по ходу прямого перебора строк нужно вдруг получить последнюю, придется делать новый view. А обертку делай какую хочешь.
Да, я в курсе, что ты любишь менять и усложнять задачу по ходу дела. Просто последнюю строку брать уже неинтересно (описали же уже не раз как это можно) — начит надо собеседникам подкинуть какое-угодно усложнение.
