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

PD>>Да, твой код выглядит очень просто. Мой будет несколько сложнее, поскольку такого класса под руками нет.
IT>Он будет не просто сложнее, он будет в десятки раз сложнее. Вместо одной строчки у тебя будет 33. А если у меня будет код в 1000 строк, то у тебя будет все 33,000?

Да ну?!

bool get_line(std::string *s, int n)
{
  std::ifstream istr("myfile.txt");
  while(n-- && std::getline(istr, *s));
  return n < 0;
}

Только STL.

IT>Но знаешь что я тебе скажу? Мне пофиг как оно там внутри работает. Оно работает, решает свою задачу с приемлемой для моих задач производительностью и мне этого достаточно. А вот то что я решаю это всё в одну строку — это огромный плюс, потому что строк у меня таких не одна, а десятки тысяч и увеличение объёма кода в 33 раза, как в твоём случае для меня неприемлемо.

Охренеть. И все десятки тысяч читают из файла строчки по номеру?

IT>Я не из тех, кто любит хвастаться проектами в миллионы бестолковых строк.

Особенно — мифических.

PD>>Это к вопросу о том "важно сколько кода у меня получится после пременения всего этого добра".
IT>Конечно важно. У меня это 1 (одна) строка.

Стыдюсь. Целых две! return не считаем, у тебя его нет.

PD>>Эх, ладно. Пропустим тест. Исходный файл имеет размер 12 Мб, состоит из повторяющегося фрагмента
IT>Тут ты явно перестарался. Речь шла о небольших файлах. Впрочем и с большими разница не существенная. Гигабайтные файлы тоже в своё время приходилось обрабатывать. Не таким образом, но тоже на C#. Если не ошибаюсь, парсинг 3-х гигабайтного файла занимал что-то около 20 секунд, а потом шла вставка в БД 11 миллионов строк. Так вот, внимание, вставка в БД занимала почти час. Теперь ответь мне какая разница будет между C++ и C#, если на C# это занимает 20 секунд и 1000 строк, а на C++ одну секунду и 20,000 строк?

Хм. Только что было 33:1, сейчас — 20:1. Тебя не разберёшь.

IT>А я тебе скажу. Написание всего того кода у меня заняло пару дней + нулевые усилия на сопровождение. Примерно в тоже время ко мне на интервью приходил чувак, которые точно такой же фигнёй занимался на C... теперь читаем внимательно... ЧЕТЫРЕ ГОДА!

Ну давай, зови сюда своего "чувака", пущай расскажет — почему. Вот тогда и видно будет, кто чего и почему написал.

PD>>Время колеблется от 0.5 сек до 2.5 сек. Берем по минимуму, 0.5 сек.
PD>>0.5/0.015 = 33 раза
IT>Я сейчас умру от смеха

Прежде "чувака" позови!

PD>>С чем тебя и поздравляю. Воистину бесплатный сыр бывает только в мышеловках!

IT>Этот сыр очень дорогого стоит. Небольшое падение производительности (которого, кстати, в моём случае на небольших файлах вовсе нет) — это ерунда. Мои продакшин сервера один фиг загружены максимум на 5%. А вот написание, отладка и поддержка кода, который в десятки раз больше — это существенный нюанс.

Уже просто "в десятки". Ладно, подождём следующей итерации.

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

PD>>А нельзя ли объяснить, какое отношение XXXString имеет к вводу/выводу ? Подмена объекта обсуждения — не лучший способ дискутировать.
IT>Это имеет прямое отношение к стандартным библиотекам.

А какой должна быть "строка" на все случаи жизни? И почему?

И ещё. Как я тебе писал года, эдак три назад, нет никакой проблемы с (LPCTSTR)(CString) и т.п. Шаблонные функции ещё никто не отменял... Ах, забыл. Отменяли по MSVC7 включительно. Вкупе с частичной специализацией.

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

PD>>Напиши код на C#, который решит ту же задачу за 0.015 сек, тогда и поговорим. Напиши, очень прошу

IT>Я его уже написал. На моей машине этот код выполняетя за 00:00:00.001000

Код в студию, please

IT>Но главное не это. Вот попробуй не просто ответить на вопрос, а подумать о нём хорошенько — зачем?

http://www.rsdn.ru/forum/message/1419711.1.aspx

Автор: Pavel Dvorkin
Дата: 05.10.05

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

IT>Редкостное дерьмо ваш STL, вы уж извините мне мой французский.

Редкостно корректный способ дискутировать, Вы уж извините мой русский.

IT>А я замечал пока писал на C/C++ и могу сказать, что нужно очень крепко зажмуриться, чтобы этого не замечать.

А все же, нельзя ли что-то конкретное сказать. А то пока одни общие слова... Плюс демагогия.

IT>

IT>У меня вообще подозрение, что если сравнивать код C++ и (Java, C#), по числу строк, то надо за одну строку на C++ 5 строк Java давать. Столько там чистого оверхеда...

IT>Твоё?

Да, конечно

PD>>Да, твой код выглядит очень просто. Мой будет несколько сложнее, поскольку такого класса под руками нет.

IT>Он будет не просто сложнее, он будет в десятки раз сложнее. Вместо одной строчки у тебя будет 33. А если у меня будет код в 1000 строк, то у тебя будет все 33,000?

Опять чистой воды демагогия. Если речь пойдет о програмировании чего-то, для чего нет никаких стандартных библиотек (по той простой причине, что этот код относится именно к данной задаче и ни к чему больше), то будет одно и то же. Ну а если речь идет именно о конструировании из кубиков, то вопрос лишь в том, какие кубики в наличии есть.


PD>>Итого — два буфера размером в исходный файл и чтение побайтно из этого файла.

IT>Ты, конечно, молодец, что так постарался и покопался в этом деле рефлектором.

Стараемся

>Но знаешь что я тебе скажу? Мне пофиг как оно там внутри работает. (Выделено мной- PD)

Вот это, боюсь самое главное и самое плохое. Мне неважно как оно работает внутри, пусть оно в 20 раз медленнее работает, пусть памяти ест в 3 раза больше, пусть... Лишь бы работало. Вот это то, с чем я категорически не согласен. Но развивать эту тему сейчас не буду, думаю, напишу об этом отдельную статью, и не в это форуме — мы и так приличный оффтопик устроили, прямо скажем.



>Оно работает, решает свою задачу с приемлемой для моих задач производительностью и мне этого достаточно. А вот то что я решаю это всё в одну строку — это огромный плюс, потому что строк у меня таких не одна, а десятки тысяч и увеличение объёма кода в 33 раза, как в твоём случае для меня неприемлемо. Я не из тех, кто любит хвастаться проектами в миллионы бестолковых строк.

No comments, ибо комменты потребовали бы много хоть и не бестолковых, но строк.

PD>>Это к вопросу о том "важно сколько кода у меня получится после пременения всего этого добра".

IT>Конечно важно. У меня это 1 (одна) строка.

Господи, да не говори ты ерунду хоть! У тебя это одна строка просто потому, что в классе имеется такой метод, отвратительно сделанный, но имеется. Поставить задачу иначе — и тебе придется писать все самому или же делать свой метод в классе-наследнике. Я без труда могу переписать свой код в виде метода класса и будет тоже одна строка. Чем ты хвалишься — тем, что в классе нашелся метод, который черт-те как это делает ?

PD>>Эх, ладно. Пропустим тест. Исходный файл имеет размер 12 Мб, состоит из повторяющегося фрагмента

IT>Тут ты явно перестарался. Речь шла о небольших файлах.

А откуда это следует ? Я такого нигде не утверждал.

>Впрочем и с большими разница не существенная. Гигабайтные файлы тоже в своё время приходилось обрабатывать. Не таким образом, но тоже на C#. Если не ошибаюсь, парсинг 3-х гигабайтного файла занимал что-то около 20 секунд,

Во-первых, что понимается здесь под парсингом ? Это понятие довольно растяжимое. А во-вторых, код в студию. Если не имеешь права сам код привести — изложи идею. Я свой код привел, а от тебя пока что слышу только заявления насчет одного кода, который работает 0.00 сек и другого, который 20 сек работает, и ни строчки кода. А та строчка, что ты привел, на 12 Мб файле работает 0.5 сек, а если ей подсунуть 3 Гб файл — боюсь, минуты, а то и больше понадобится, да и ОП скорее всего не хватит вместе со своп-файлом.


>а потом шла вставка в БД 11 миллионов строк. Так вот, внимание, вставка в БД занимала почти час. Теперь ответь мне какая разница будет между C++ и C#, если на C# это занимает 20 секунд и 1000 строк, а на C++ одну секунду и 20,000 строк? А я тебе скажу. Написание всего того кода у меня заняло пару дней + нулевые усилия на сопровождение. Примерно в тоже время ко мне на интервью приходил чувак, которые точно такой же фигнёй занимался на C... теперь читаем внимательно... ЧЕТЫРЕ ГОДА!

Слушай, это уже совсем на абсурд смахивает. 4 года некий чувак парсил текстовый файл. По-видимому, надо понимать, что он ничем больше не занимался, ибо если он просто модифицировал код , изменяя делали парсинга, то этим можно заниматься хоть десять лет, если задача требует, и тут ничего интересного нет. Но если он 4 года именно писал код парсинга и ничего больше не делал — это уже, извини, бред сивой кобылы. Или же его надо было уволить через месяц после того, как он этим начал заниматься. За полную профессиональную непригодность.



PD>>Время колеблется от 0.5 сек до 2.5 сек. Берем по минимуму, 0.5 сек.

PD>>0.5/0.015 = 33 раза

IT>Я сейчас умру от смеха

Что, с арифметикой проблемы ?

PD>>С чем тебя и поздравляю. Воистину бесплатный сыр бывает только в мышеловках!

IT>Этот сыр очень дорогого стоит. Небольшое падение производительности (которого, кстати, в моём случае на небольших файлах вовсе нет) — это ерунда. Мои продакшин сервера один фиг загружены максимум на 5%.

Во-во. Пока загрузка максимум 5%, пока файлы небольшие и т.д. — работает. Как только условия становятся чуть пожестче — все начинает тормозить со страшной силой.

Все, я эту дискуссию заканчиваю здесь. Разумеется, ты вправе ответить, но оставляю за тобой это последнее слово. Тем более, что Геннадий Васильев успел высказать несколько моих аргументов до меня


А вот написание, отладка и поддержка кода, который в десятки раз больше — это существенный нюанс.

ГВ>Стыдюсь. Целых две! return не считаем, у тебя его нет.

Ошибка. return у тебя есть. Следовательно — целых три! Шансы отстоять "десятки раз" резко повышаются!

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

IT>>Тут ты явно перестарался. Речь шла о небольших файлах.

PD>А откуда это следует ? Я такого нигде не утверждал.

например тут

В файле Пример.txt лежат 3 юникодные строки.

Только не надо флейм устраивать насчет того, почему я уверен, что 100 символов хватит.

твое?
сравнишь производительность на трех строчках?

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

PD>>А откуда это следует ? Я такого нигде не утверждал.

S>например тут

S>[q]
S>В файле Пример.txt лежат 3 юникодные строки.

А вот тут дочитать можно было ?

http://rsdn.ru/forum/message/2811970.1.aspx

Автор: Pavel Dvorkin
Дата: 25.01.08

Я ведь сначала вовсе не производительностью интересовался, а просто показал, как на С++ решается твоя задача. Но после этого разговор пошел уже о совсем другом, так что стоит вести дискуссию в контексте всего топика, а не прошлых ее частей.

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


S>вторым параметром в стремридере можешь указать кодировку если нужна, по умолчанию юникод ... ну как?

Да вот так. Внес маленькое изменение

using System;
using System.IO;

namespace ConsoleApplication2
{
    class Program
    {
        static void Main(string[] args)
        {
            DateTime dtStart = DateTime.Now;
            using (StreamReader reader = new StreamReader("D:\\Пример1.txt"))
            {
                while (!reader.EndOfStream)
                {
                    reader.ReadLine();
                }
            }
            DateTime dtEnd = DateTime.Now;
            Console.WriteLine(dtEnd - dtStart);
        }
    }
}

5 запусков

00:00:00.2656250
00:00:00.2343750
00:00:00.2343750
00:00:00.2812500
00:00:00.3281250

Так что я тебя поздравляю, конечно, по сравнению с тем, что тут IT предложил, в 2 раза примерно быстрее. Но по сравнению с 0.015 сек, что я сделал — это все же проигрывает более чем в 10 раз.

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

PD>Я ведь сначала вовсе не производительностью интересовался, а просто показал, как на С++ решается твоя задача. Но после этого разговор пошел уже о совсем другом, так что стоит вести дискуссию в контексте всего топика, а не прошлых ее частей.

Предлагаю отрезать эту ветку

Автор: Pavel Dvorkin
Дата: 18.01.08

, а потом перекинуть, например, в "Архитектуру". В автомодерилке уже я отметился.

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

PD>Я ведь сначала вовсе не производительностью интересовался, а просто показал, как на С++ решается твоя задача. Но после этого разговор пошел уже о совсем другом, так что стоит вести дискуссию в контексте всего топика, а не прошлых ее частей.

ее вообще никто не мерял кроме тебя, и о другом только ты заговорил ...
первоначальный посыл (твой) был в том, что из-за большого количества сущностей программа на шарпе будет больше и сложнее ... тебе не раз показали обратное, вместо того что бы принять, ты взялся производительность мерять ...

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

ГВ>Да ну?!

ГВ>

ГВ>bool get_line(std::string *s, int n)
ГВ>{
ГВ>  std::ifstream istr("myfile.txt");
ГВ>  while(n-- && std::getline(istr, *s));
ГВ>  return n < 0;
ГВ>}
ГВ>

ГВ>Только STL.

Unicode?

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

PD>Так что я тебя поздравляю, конечно, по сравнению с тем, что тут IT предложил, в 2 раза примерно быстрее. Но по сравнению с 0.015 сек, что я сделал — это все же проигрывает более чем в 10 раз.

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

ЗЫ: создал в 2005 студии проект вин32 консоль и вставил туда твой пример ... откомпилил ... запустил, че-то оно делало, при этом долгое время выдавая вопросы на консоль ... потом я это вырубил

ЗЫ2: Environment.TickCount

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

PD>Во-первых, что понимается здесь под парсингом ? Это понятие довольно растяжимое. А во-вторых, код в студию. Если не имеешь права сам код привести — изложи идею. Я свой код привел, а от тебя пока что слышу только заявления насчет одного кода, который работает 0.00 сек и другого, который 20 сек работает, и ни строчки кода. А та строчка, что ты привел, на 12 Мб файле работает 0.5 сек, а если ей подсунуть 3 Гб файл — боюсь, минуты, а то и больше понадобится, да и ОП скорее всего не хватит вместе со своп-файлом.

Вот именно в этом и заключается корень Ваших заблуждений. Дело в том, что далеко не всегда нужно бить на строчки 12Гб файл. Чаще всего точно известно, что данной программе никто и никогда не подсунет файл больше 50К (а если и подсунет, тормозить, будет что-нибудь другое, да так, что мало не покажется). Конечно, бывают исключительные ситуации. Но фреймворки для того и создаются, чтобы покрывать 99% тех случаев, на которые они расчитаны. А вот как раз то, что в System.IO куча классов — очень либерально со стороны фреймворка. Потому что при наличии подобной специфической задачи мы не станем юзать другой фреймворк или писать свой велосипед, а заюзаем TextReader или даже Stream, в зависимости от того, насколько низкоуровневым должно быть решение.

А делать решение-на-все-случаи жизни — это заведомо неправильный путь, потому что дав адекватное средство для решения задач меньшинства, мы заставим матерясь срывать сроки большинство.

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

IT>>Редкостное дерьмо ваш STL, вы уж извините мне мой французский.

PD>Редкостно корректный способ дискутировать, Вы уж извините мой русский.

Про фреймворк на-все-случаи-жизни я писал в другом посте. Так вот, как мне кажется, проблема STL как раз в том, что он является библиотекой на-все-случаи-жизни, а это не есть хорошо.

По поводу конструктивной критики STL — послушаем IT, но я уже сходу могу указать на один момент, который меня бесит. Когда надо пройтись по коллекции, пишут что-то вроде:

for (list<pair<foo, bar>>::iterator iter = v.begin(); iter != v.end(); ++iter)

Короче, необходимость делать аннотацию типа iter меня убивает. Конечно, можно свалить всю вину на C++, но и разработчики STL могли бы учесть... Ещё один пункт: много приходилось трахаться с std::map. Хотят пример тут не приведу, т.к. с STL дааавно не работал, но воспоминания остались нехорошие.

Кстати, я сейчас всё более склоняюсь к тому, что все эти коллекции а-ля STL сдизайнены неправильно. Например, если методу класса передаётся коллекция, которую он должен где-то внутри класса сохранить, то эту коллекцию (за исключением тех ситуаций, когда и так приемлемо) в целях сохранения инкапсуляции придётся копировать явно. Кроме того, эту коллекцию, может быть, захочется выставить наружу как read-only и т.п. Я поматерившись написал для себя библиотечку. Там на каждую коллекцию Foo в стиле STL или System.Collection.Generic приходится интерфейс IFooReader, иммутабельный класс Foo и мутабельный FooBuilder. Так вот: FooBuilder как правило в общем и целом повторяет Foo и STL, зато Foo из моей библиотечки изменить нельзя, потому параметры методов у меня будут типа Foo. Если есть FooBuilder — то никогда не долго вызвать у него Build. Зато если уже есть Foo, и надо передать его ещё куда-то, то получается положительный побочный эффект в виде экономии числа копирований. Это уж не говоря о том, что Foo можно использовать в качестве ключа словаря или спокойно создавать множество Foo. Вообще, библиотечка вроде как внутрикорпоративная, но если начальство разрешит, то могу её сделать более открытой

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

S>Unicode?

wstring, wfstream

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

K>Короче, необходимость делать аннотацию типа iter меня убивает. Конечно, можно свалить всю вину на C++, но и разработчики STL могли бы учесть... Ещё один пункт: много приходилось трахаться с std::map. Хотят пример тут не приведу, т.к. с STL дааавно не работал, но воспоминания остались нехорошие.

лечится typedef.
Вообще boost::range (http://www.boost.org/libs/range/doc/intro.html) конечно намного симпатичней чем пары итераторов.

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

SH>Да, проблему они хорошо обозначили. Я, правда, понятия не имею, насколько декларируемое падение уровня соответствует истине, но то, что они написали, как минимум, хорошая формулировка для проблемы.

SH>Но вот причину этой проблемы они ищут где-то не там. Имхо, им бы первые два пункта выправить, и с третьим сразу стало бы полегче. И с Явой это напрямую не связано. Они там жалуются, что студенты не врубаются в указатели.. В Scheme нет ни то что указателей, даже ссылок нет и самой операции присваивания. И ничего, как-то учатся, SICP считается классикой...

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

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

FR>Присваивание в Схеме есть.

(set! x y) ?
ну да, но этим стараются не пользоваться по возможности.

FR>Указателей нет, но есть списки, и за умение правильно с ними работать и понимать как они устроены, по моему отвечает та же часть мозга которая используется для работы с указателями

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

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

FR>>Присваивание в Схеме есть.

SH>(set! x y) ?

Угу

SH>ну да, но этим стараются не пользоваться по возможности.

Да хороший тон в схеме писать в функциональном стиле. Но никто не запрещает писать и императивно.
Я думаю схема очень хороший вариант для первого языка. И вообще для первоначального обучения по моему полезен любой язык для использования которого надо прилагать хоть какие-то умственные усилия, я вот например начинал с кодов для программируемого микрокалькультора

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

PD>P.S. Задачу, подобную этой , я студентам даю в качестве упражнения по memory-mapped файлам.

Павел, вы плохим вещам бедных наивных деток учите.

Если задача стоит так, что требуется максимальная скорость доступа к записи с произвольным номером, то что из этого следует? Из этого следует, что файл должен быть организован так, что произвольный доступ стоил бы O(1). Точка. Другие варианты не обсуждаются. Вы же издрючиваетесь хитрыми системнозависимыми подвыпердыхтами, оптимизируя до посинения свой O(n). Это плохо. Очень плохо. Не культурно. В приличном обществе такой код не демонстрируют, трусами стыдливо прикрывают.

Если скорость не важна, и надо просто в приемлимое время прочитать n-ю строку из простого текстового файла (и у нас ОС из разряда потомков Юникса, не знающая никаких RMS), то и выпендриваться не надо, решение многоуважаемого IT канает на раз-два. Если скорость принципиальна, то за использование плоского текстового файла надо карать жестоко, а при использовании правильной структуры скорость работы от языка реализации и используемой библиотеки зависеть не будет практически никак.